IG Diamond VerificationReport

From documentation SEPAmail
Jump to navigation Jump to search
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


<svnig conversion="none" date="Wed Aug 29 15:38:08 CEST 2012" last="" repository="Diamond" revision="192" source="VerRep_Intro.txt">

Introduction

This document describes the contents of the SEPAmail/DIAMOND message used to reply to a Diamond VerificationRequest message.

It is used only in response to this message.

The full name of this message is sepamail_message_identification.verification_IdentificationVerificationReport. </svnig>

<svnig conversion="none" date="Fri Apr 20 13:00:32 CEST 2012" last="" repository="Diamond" revision="86" source="VerRep_Abstract.txt">

Internal abstraction level

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

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

<svnig conversion="tab" date="Wed Aug 29 15:38:08 CEST 2012" last="" repository="Diamond" revision="192" source="VerRep_Abstract.tab">

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

</svnig>

<svnig conversion="none" date="Mon Oct 08 15:08:12 CEST 2012" last="" repository="Diamond" revision="209" source="VerRep_Body.txt">

Message Body

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

<svnig conversion="tab" date="Mon Oct 08 15:08:12 CEST 2012" last="" repository="Diamond" revision="209" source="VerRep_Body.tab">

Ref Mult Message Element SEPAmail requirement
A [1..1] + Report IdentificationVerificationReportV01, as per ISO acmt.024
B [1..1] + Complement Non-ISO part.

</svnig>

<svnig conversion="none" date="Fri Apr 20 13:00:32 CEST 2012" last="" repository="Diamond" revision="86" source="VerRep_ISO.txt">

ISO part : IdentificationVerificationReportV01

Please note : this whole part is directly copied from ISO20022 documents, and is only 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>

<svnig conversion="tab" date="Thu Mar 21 20:05:05 CET 2013" last="" repository="Diamond" revision="241" source="VerRep_ISO.tab">

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 Designates the party which initially created the message.
1.4 {or ++++ Party
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 Must match the Assignee from the “Demande de Vérification” (1.9)
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 Must match the Assigner from the “Demande de Vérification” (1.6)
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 [0..1] ++ OriginalAssignment Mandatory
2.1 [1..1] +++ MessageIdentification
2.2 [1..1] +++ CreationDateTime
3.0 [1..n] ++ Report One such block (and only one) must be present for each Verification block (2.0) in the Diamond VerificationRequest message
3.1 [1..1] +++ OriginalIdentification
3.2 [1..1] +++ Verification True iff all fields are correct. False in all other cases, details in non-ISO part.
3.3 [0..1] +++ Reason
3.4 [0..1] {Or ++++ Code
3.5 [0..1] Or} ++++ Proprietary
3.6 [0..1] +++ OriginalPartyAndAccountIdentification
3.7 [0..1] ++++ Party
3.8 [0..1] ++++ Account
3.9 [0..1] ++++ Agent
3.9.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
3.9.2 [0..1] +++++ BranchIdentification
3.10 [0..1] +++ UpdatedPartyAndAccountIdentification
3.11 [0..1] ++++ Party
3.12 [0..1] ++++ Account
3.13 [0..1] ++++ Agent
3.13.1 [1..1] +++++ FinancialInstitutionId Usage rule : only BIC is allowed
3.13.2 [0..1] +++++ BranchIdentification

</svnig>

<svnig conversion="none" date="Wed Aug 29 22:00:34 CEST 2012" last="" repository="Diamond" revision="197" source="VerRep_NonISO.txt">

Non-ISO part

This part is used to indicate additional information about the performed checks. </svnig>

<svnig conversion="tab" date="Tue Oct 30 10:45:24 CET 2012" last="" repository="Diamond" revision="223" source="VerRep_NonISO.tab">

Ref Mult Message Element SEPAmail requirement
B1 [1..1] ++ CheckVersion Indicates which version of the checking algorithm was used. MUST be between the incoming MinCheckVersion (B1) and MaxCheckVersion (B2) of the request message, inclusively, if these elements were present.
B2 [1..n] ++ VrfReportCompl One such element must be present for each Verification (2.0) in the incoming message.
B2.1 [1..1] +++ VerifId Verification identifier. MUST match one of the identifiers of the incoming message (2.1).
B2.2 [1..n] +++ ReturnCode One such element must be present for each 5-digit code returned by the performed checks.
B2.3 [0..1] +++ BusRef Must be present if it was provided by the Creditor in the request message (B3.2).
B2.3.1 [1..1] ++++ Type Type of this reference. Can be "RUM" or "other".
B2.3.2 [1..1] ++++ Value Value of this reference.
B2.4 [0..n] +++ TrsInfo One such element must be present for each TrsTest element in the Diamond VerificationRequest message, except if the check could not be performed.
B2.4.1 [1..1] ++++ Transaction Type of transaction, see TrsTest element in Diamond VerificationRequest message for possible values.
B2.4.2 [1..1] ++++ Allowed Contains true or false to indicate whether or not this transaction is allowed on checked account. Repeat B2.4.1 and B2.4.2 as needed. A transaction that could not be checked must be absent from the TrsInfo element.

</svnig>

<svnig conversion="none" date="Fri Apr 26 14:53:49 CEST 2013" last="" repository="Diamond" revision="245" source="VerRep_Codes.txt">

Verification codes

Here is the full list of allowed verification codes (index B2.2).

The codes are built as follows :

  • chars 1 and 2 indicate the data being verified
    • 01 IBAN
    • 02 customer type
    • 03 SIREN
    • 04 SIRET
    • 05 TVA intracomm
    • 06 birth date
    • 07 birth city
    • 08 birth country
    • 09 name
    • 10 other_name
    • 11 id card / pass
  • chars 3 to 5 indicate the result of the verification
    • for a simple check, 0 indicates false and 1 indicates true
    • for a more complex check, these chars will hold a score between 0 and 400

The detailed algorithm can be found here. </svnig>

Reason codes

<svnig conversion="tab" date="Fri Apr 26 14:53:49 CEST 2013" last="" repository="Diamond" revision="245" source="VerRep_Codes.tab">

Code Meaning
01000 invalid or non existant IBAN
01001 existant and valid IBAN
02000 incorrect customer type
02001 correct customer type
02020 impossible check of customer type
03000 incorrect SIREN
03001 correct SIREN
04000 incorrect SIRET
04001 correct SIRET
04002 incorrect SIRET, and included SIREN incorrect
04003 incorrect SIRET, but included SIREN correct
05000 incorrect TVA intracomm
05001 correct TVA intracomm
06000 incorrect birth date
06001 correct birth date
07000 incorrect birth city
07001 correct birth city
07020 impossible check of birth city
08000 incorrect birth country
08001 correct birth country
08020 impossible check of birth country
09XXX name control, XXX is a score between 0 and 400 (see above)
10XXX other name control, XXX is a score between 0 and 400 (see above)
11000 all provided identity documents incorrect
11001 at least one of the provided identity documents correct
11020 impossible check of identity documents

</svnig>