Standards:Les règles métier (DIAMOND)

Standards:Les r†gles m€tier (DIAMOND) 138
Standards:Les règles métier (DIAMOND)
{{TOC DIAMOND}}
Objet du document
Ce document d€crit le m€canisme global du syst†me SEPAmail de demande de v€rification d'identifiants bancaires
de type IBAN. Il est destin€ ƒ des interlocuteurs fonctionnels, les €l€ments techniques figurant dans les directives
correspondantes (implementation guidelines).
Présentation générale
DIAMOND vise ƒ €tablir un ensemble de r†gles et d'outils permettant de g€rer des demandes de v€rification
d'identifiants bancaires:
Š cr€ation des demandes de v€rification par l'€metteur
Š application de l'algorithme communautaire de contr‹le d'identifiant bancaire
Š cr€ation des r€ponses aux demandes de v€rification par la banque teneur du compte objet de la v€rification
Messages de la famille DIAMOND
DIAMOND est l'application SEPAmail utilisant l'€cosyst†me identification.verification.
Dans cet €cosyst†me, deux messages ont €t€ d€finis ƒ ce jour•:
Š VerificationRequest
Š VerificationReport
Le message de demande de vérification
Ce message est utilis€, ƒ l'initiative d'un utilisateur SEPAmail (€metteur), pour demander la v€rification d'un
identifiant bancaire de type IBAN.
Le message est fond€ sur le message acmt.023.001.01 de la norme ISO 20022,
IdentificationVerificationRequestV01, auquel sont ajout€es des informations sp€cifiques ƒ DIAMOND.
L'€metteur du message ma‰trise par les champs qu'il compl†te dans son message de demande les crit†res qu'il
souhaite voir contr‹ler par l'adh€rent destinataire (sous r€serve de l'offre effective de cet adh€rent sur la totalit€ des
crit†res de l'algorithme communautaire).
Le message de réponse à demande de vérification
Ce message est utilis€, ƒ l'initiative de la banque teneur du compte objet de la v€rification, pour r€pondre ƒ la
demande de v€rification d'un identifiant bancaire qu'elle a re„ue.
Le message est fond€ sur le message acmt.024.001.01 de la norme ISO 20022, IdentificationVerificationReportV01,
auquel sont ajout€es des informations sp€cifiques ƒ DIAMOND.
Dans le message de r€ponse, le r€sultat est fourni par:
Š un indicateur de r€ponse global valoris€ ƒ TRUE ou FALSE:
Š TRUE lorsque tous les champs soumis sont int€gralement corrects, c'est-ƒ-dire qu'ils sont vrais dans le cas des
contr‹les €l€mentaires, €gaux ƒ la note la plus €lev€e dans le cas des calculs de note de pertinence et que le
dernier champ test€ par l'algorithme avant la d€termination de l'indicateur de r€ponse global n'aboutit pas ƒ un

Standards:Les r†gles m€tier (DIAMOND) 139
r€sultat "test impossible"
Š FALSE dans tous les autres cas avec n€cessit€ de lire les codes raisons en compl€ment.
Š un code raison par donn€e test€e construit sur 5 positions (fourni dans la partie non ISO) indiquant:
Š en positions 1 et 2•: le n‘ du contr‹le effectu€
Š 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 idcard / pass
Š en positions 3, 4 et 5•: le r€sultat obtenu sur ce contr‹le
Ce r€sultat est soit une note de pertinence pour les contr‹les n€cessitant une r€ponse nuanc€e (ex•: contr‹le de nom),
soit un indice pour les contr‹les plus €l€mentaires (ex•: contr‹le de date de naissance).
Š 000 FAUX
Š 001 VRAI
Š 002 FAUX sur une donn€e de repli
Š 003 VRAI sur une donn€e de repli
Š 020 contr‹le impossible
Š XXX note de pertinence comprise entre 0 et 400
Il est restitu€ ƒ l'€metteur du message autant de codes raison par IBAN que de donn€es effectivement test€es. En
revanche, compte tenu de la d€pendance de certains tests entre eux, toutes les donn€es fournies pour contr‹le ne
seront pas obligatoirement test€es, conform€ment ƒ l'algorithme ci-dessous.
Liste exhaustive: cf ici.
L'algorithme communautaire de fiabilisation IBAN
Contexte d'utilisation
L'algorithme permet de fiabiliser l'identit€ du titulaire du compte dont l'IBAN est fourni. Il compare les donn€es
fournies par l'€metteur du message et celles dont l'adh€rent r€cepteur du message dispose. L'€metteur du message
doit donc prendre en compte les contraintes suivantes :
Š les donn€es bancaires sont g€n€ralement bas€es sur les pi†ces d'identit€, et de ce fait, il est pr€f€rable pour
l’€metteur de message d'utiliser lui aussi des donn€es venant de pi†ces d'identit€
Š en aucun cas l'adh€rent teneur du compte contr‹l€ ne communiquera les €l€ments d'identification du compte dont
elle dispose (nom, date/lieu de naissance, SIREN..etc..)
Š il est ƒ la charge de l'€metteur du message de bien choisir les €l€ments transmis surtout si le signataire du contrat
n'est pas celui qui est cens€ r€gler les factures du contrat.
Si un €metteur de message poss†de un relev€ d'identit€ SEPAmail ou bancaire s€curis€, par 2D-DOC par exemple,
l'utilisation de l'algorithme sera sans valeur ajout€e, except€ sur le contr‹le des op€rations autoris€es sur le compte.
Cet algorithme pr€voit des contr‹les diff€rents pour les particuliers et pour les personnes morales.

Standards:Les r†gles m€tier (DIAMOND) 140
Caractéristiques de l'algorithme
Š Tous les adh€rents SEPAmail utilisent le mˆme algorithme pour avoir une coh€rence vis-ƒ-vis des €metteurs de
message. N€anmoins :
1. l'algorithme est susceptible d'€voluer
2. les banques ne seront pas ƒ mˆme de faire les migrations le mˆme jour
Il en r€sulte que l'algorithme poss†de un num€ro de version qui est v€hicul€ dans les messages retour (partie non
ISO).
Š Les donn€es g€r€es par l'algorithme sont :
Š IBAN
Š type de client
Š SIREN, SIRET, N‘ de TVA Intracommunautaire
Š N‘ d'une pi†ce d'identit€ et date de d€livrance
Š noms
Š date, ville et pays de naissance
Š op€rations autoris€es sur le compte
Contenu de l'algorithme
400px|thumb|right|contr‹les g€n€raux
1ère étape, commune à tous types de clients : Contrôle IBAN valide et existant, compte non
soldé
Le 1er contr‹le v€rifie que l’IBAN transmis est correctement constitu€ (MOD 97-10, cf ISO7604) et que le compte
existe. Ce contr‹le int†gre le contr‹le de compte sold€ ou cl‹tur€.
2ème étape, commune à tous types de clients : Contrôle du type de client
Le 2†me contr‹le v€rifie que le type de client transmis (entreprise/pro ou particulier) est identique ƒ celui enregistr€
dans la base Tiers de l'adh€rent. Ce contr‹le est binaire. Il ne s'appuie pas directement sur une donn€e "type de client
du compte" fournie par l'€metteur mais il v€rifie le type transmis en fonction de la pr€sence des index
OrganisationIdentification ou PrivateIdentification.
Š La pr€sence de OrganisationIdentification est consid€r€e comme un type de client
'entreprise/professionnel/association'.
Š La pr€sence de PrivateIdentification est consid€r€e comme un type de client 'particulier'.
Ce type est contr‹l€ avec la base Tiers de l'adh€rent SEPAmail.
Si aucun de ces 2 index n'est pr€sent, l'algorithme se poursuit par une €tape €quivalente ƒ la 3†me €tape concernant
les particuliers - sous-€tape B.
400px|thumb|right|contr‹les pour les personnes morales
3ème étape, concernant les entreprises, professionnels et associations quand elles possédent
un SIREN, SIRET ou N° de TVA Intracommunautaire: Contrôle du SIREN/SIRET ou N°
de TVA Intracommunautaire
Le 3†me contr‹le, concernant les entreprises, professionnels et associations quand elles poss€dent un SIREN, SIRET
ou N‘ de TVA Intracommunautaire, v€rifie que le SIREN, SIRET ou N‘ de TVA Intracommunautaire transmis est
identique ƒ celui enregistr€ dans la base Tiers de l'adh€rent SEPAmail. En cas de SIRET fourni et r€sultat KO, un
contr‹le de repli sur le SIREN est effectu€.