IG Diamond VerificationRequest

SEPAmail – Norme 1206
Cette page fait partie de la version 1206 de la norme. Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail. ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.

These implementation rules shall be applied in accordance with ISO20022 and SEPA own implementation rules. Thus, unless explicitly specified, data contained within a field or XML structure of a SEPAmail message must comply with the constraints related to the equivalent field or XML structure in ISO20022 or SEPA messages.
for an explanation of the color coding used in the tables below, see this page
for general rules applying to all fields, see this page
for business rules directing these IG, see this page

Introduction

This document describes the contents of the SEPAmail/DIAMOND message used to request verification of an identity.

The full name of this message is sepamail_message_identification.verification_IdentificationVerificationRequest.

</svnig>

Internal abstraction level

To facilitate upgrades, an abstraction level has been inserted at the root of this element.

The actual contents of the VerificationRequest element must be any one of the sepamail_verification_request_xxx structures. </svnig>

Mult	Message Element	SEPAmail requirement
[1..1]	sepamail_verification_request_001	First version of the message

</svnig>

Message Body

This message contains a mandatory ISO part and an optional non-ISO part. </svnig>

Ref	Mult	Message Element	SEPAmail requirement
A	[1..1]	+ Request	IdentificationVerificationRequestV01, as per ISO acmt.023
B	[0..1]	+ Complement	Non-ISO part. Must be present only if transaction verifications are requested.

</svnig>

ISO part : IdentificationVerificationRequestV01

The general guiderule in this message is : among optional fields, only fill in those that you want checked. For instance, even if you know your customer's birth date, but don't want it checked, don't fill in field 3.1.23.

In any case, actual checking of all fields is directed by the general algorithm, described here.

Please note : the ISO part is mostly copied from ISO20022 documents, and is provided here for ease of reference. The indices in first column match the ones in this document.

However, the rules described in the last column, which complement the ISO rules, refer to actual SEPAmail/DIAMOND usage. </svnig>

Ref	Mult		Message Element	SEPAmail requirement
1.0	[1..1]		++ Assignment
1.1	[1..1]		+++ MessageIdentification
1.2	[1..1]		+++ CreationDateTime
1.3	[0..1]		+++ Creator	Mandatory. Designates the party which initially creates the request, ie the requesting creditor.
1.4		{or	++++ Party	See below for full details about this element.
1.5		or}	++++ Agent
1.5.1	[1..1]		+++++ FinancialInstitutionId	Usage rule : only BIC is allowed
1.5.2	[0..1]		+++++ BranchIdentification
1.6	[1..1]		+++ Assigner	Designates the party from which the current message originates (point-to-point)
1.7		{or	++++ Party
1.8		or}	++++ Agent
1.8.1	[1..1]		+++++ FinancialInstitutionId	Usage rule : only BIC is allowed
1.8.2	[0..1]		+++++ BranchIdentification
1.9	[1..1]		+++ Assignee	Designates the party for which this messags is intended (creditor's bank when the message is created by the creditor, debtor's bank when it is created by the creditor's bank ...)
1.10		{or	++++ Party
1.11		or}	++++ Agent
1.11.1	[1..1]		+++++ FinancialInstitutionId	Usage rule : only BIC is allowed
1.11.2	[0..1]		+++++ BranchIdentification
2.0	[1..n]		++ Verification
2.1	[1..1]		+++ Identification
2.2	[1..1]		+++ PartyAndAccountIdentification
2.3	[0..1]		++++ Party
3.1.0	[0..1]		+++++ Name	For a private person, first name + last name. In other cases, legal name or commercial name.
3.1.1	[0..1]		+++++ PostalAddress
3.1.12	[0..1]		+++++ Identification
3.1.13	[1..1]	{Or	++++++ OrganisationIdentification	MUST be used if the party is not a private person.
3.1.14	[0..1]		+++++++ BICOrBEI
3.1.15	[0..n]		+++++++ Other
3.1.16	[0..1]		++++++++ Identification	Use this to store identification numbers (cf. 3.1.20)
3.1.17	[0..1]		++++++++ SchemeName
3.1.18	[1..1]	{{Or	+++++++++ Code
3.1.19	[1..1]	Or}}	+++++++++ Proprietary
3.1.20	[0..1]		++++++++ Issuer	Type of data. Allowed values : SIREN SIRET TVA_intracomm
3.1.21	[1..1]	Or}	++++++ PrivateIdentification	MUST be used if the party is a private person
3.1.22	[0..1]		+++++++ DateAndPlaceOfBirth
3.1.23	[1..1]		++++++++ BirthDate
3.1.24	[0..1]		++++++++ ProvinceOfBirth
3.1.25	[1..1]		++++++++ CityOfBirth
3.1.26	[1..1]		++++++++ CountryOfBirth
3.1.27	[0..n]		+++++++ Other	Use one or several such elements to indicate values to be checked.
3.1.28	[1..1]		++++++++ Identification	Data itself
3.1.29	[0..1]		++++++++ SchemeName
3.1.30	[1..1]	{{Or	+++++++++ Code
3.1.31	[1..1]	Or}}	+++++++++ Proprietary
3.1.32	[0..1]		++++++++ Issuer	Type of data. Allowed values : other_name (first name + last name, possibly prepended by civility) pass_number pass_location pass_date idcard_number idcard_location idcard_date
3.1.33	[0..1]		+++++ CountryOfResidence
3.1.34	[0..1]		+++++ ContactDetails
2.4	[0..1]		++++ Account	Mandatory
2.4.1	[1..1]	{{Or	+++++ IBAN
2.4.2	[1..1]	Or}}	+++++ Other
2.5	[0..1]		++++ Agent
2.5.1	[1..1]		+++++ FinancialInstitutionId	Usage rule : only BIC is allowed
2.5.2	[0..1]		+++++ BranchIdentification

</svnig>

<svnig conversion="none" date="Fri Apr 26 15:07:44 CEST 2013" last="" repository="Diamond" revision="246" source="VerReq_ISO_Cdtr.txt"> This is the detail of fields under Creator element (1.3 above). </svnig>

Ref	Mult		Message Element	SEPAmail requirement
4.1.0	[0..1]		++++ Name
4.1.1	[0..1]		++++ PostalAddress
4.1.2	[0..1]		+++++ AddressType
4.1.3	[0..1]		+++++ Department
4.1.4	[0..1]		+++++ SubDepartment
4.1.5	[0..1]		+++++ StreetName
4.1.6	[0..1]		+++++ BuildingNumber
4.1.7	[0..1]		+++++ PostCode
4.1.8	[0..1]		+++++ TownName
4.1.9	[0..1]		+++++ CountrySubDivision
4.1.10	[0..1]		+++++ Country
4.1.11	[0..7]		+++++ AddressLine
4.1.12	[0..1]		++++ Identification	Mandatory
4.1.13	[1..1]	{Or	+++++ OrganisationIdentification
4.1.14	[0..1]		++++++ AnyBIC
4.1.15	[0..*]		++++++ Other	Must contain the ICQX (first occurrence) and, if applicable, an ICS (second occurrence).
4.1.16	[1..1]		+++++++ Identification	ICQX / ICS.
4.1.17	[0..1]		+++++++ SchemeName
4.1.18	[1..1]	{{Or	++++++++ Code
4.1.19	[1..1]	Or}}	++++++++ Proprietary	Must contain the value "SEPA" if 4.1.16 contains an ICS, and "SEPAMAIL.EU" if it contains an ICQX.
4.1.20	[0..1]		+++++++ Issuer
4.1.21	[1..1]	Or}	+++++ PrivateIdentification
4.1.22	[0..1]		+++++ DateAndPlaceOfBirth
4.1.23	[1..1]		++++++ BirthDate
4.1.24	[0..1]		++++++ ProvinceOfBirth
4.1.25	[1..1]		++++++ CityOfBirth
4.1.26	[1..1]		++++++ CountryOfBirth
4.1.27	[0..*]		+++++ Other
4.1.28	[1..1]		++++++ Identification
4.1.29	[0..1]		++++++ SchemeName
4.1.30	[1..1]	{{Or	+++++++ Code
4.1.31	[1..1]	Or}}	+++++++ Proprietary
4.1.32	[0..1]		++++++ Issuer
4.1.33	[0..1]		++++ CountryOfResidence
4.1.34	[0..1]		++++ ContactDetails

</svnig>

Non-ISO part

This part allows the requester to add complementary test conditions. It is optional, and SHOULD never be included if it is empty. </svnig> <svnig conversion="tab" date="Tue Oct 30 10:45:24 CET 2012" last="" repository="Diamond" revision="223" source="VerReq_NonISO.tab">

Ref	Mult	Message Element	SEPAmail requirement
B1	[0..1]	++ MinCheckVersion	Minimum version of name-checking algorithm. If absent, any version is accepted.
B2	[0..1]	++ MaxCheckVersion	Maximum version of name-checking algorithm. If absent, the most recent version is accepted.
B3	[0..n]	++ VrfComplement	One such element may be present for each Verification (2.0) in the ISO part.
B3.1	[1..1]	+++ VerifId	Identifier of the associated Verification element. MUST match one of the VerificationIdentification (2.1) indices.
B3.2	[0..1]	+++ BusRef	Business reference provided by the creditor to ascertain its relation with the debtor.
B3.2.1	[1..1]	++++ Type	Type of this reference. Can be "RUM" or "other".
B3.2.2	[1..1]	++++ Value	Value of this reference.
B3.3	[0..n]	+++ TransactionTest	One such element for each operation to be checked. Can be (meaning: is the account allowed to) : in_trf ('credits by incoming transfer) out_trf (debits by outgoing transfer) out_sepamail_trf (debits by outgoing SEPAmail transfer) out_dd (debits by incoming direct debit) in_dd_return (credits by direct debit return) in_all (credits) out_all (debits) inout_all (all operations)

</svnig>

IG Diamond VerificationRequest

Introduction

Internal abstraction level

Message Body

ISO part : IdentificationVerificationRequestV01

Non-ISO part

Navigation menu

Search