Les règles métier (DIAMOND)

Objet du document

Ce document décrit le mécanisme global du système SEPAmail de demande de vérification de coordonnées bancaires.

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 de coordonnées bancaires:

• création des demandes de vérification par le donneur d'ordre
• application de l'algorithme communautaire de contrôle de coordonnées bancaire
• création des réponses aux demandes de vérification par le Prestataire de Services de Paiement (PSP) teneur du compte du titulaire

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 : message de demande de vérification
• VerificationReport : message de réponse à une demande de vérification

Le message de demande de vérification

Ce message est utilisé, à l'initiative d'un utilisateur SEPAmail (le donneur d'ordre), pour demander la vérification de coordonnées bancaires du titulaire.

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.

Le donneur d'ordre maîtrise par les champs qu'il complète dans son message de demande les critères qu'il souhaite voir contrôler par le PSP teneur du compte (sous réserve de l'offre effective de ce PSP 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 du PSP teneur du compte du titulaire, pour répondre à la demande de vérification de coordonnées bancaires qu'il 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 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, en fonction des contrôles, soit une note de pertinence, comprise entre 0 et 400, pour les contrôles nécessitant une réponse nuancée (contrôles 09 et 10), soit un indice pour les contrôles plus élémentaires (contrôles autres que 09 et 10) avec les valeurs suivantes :

• 000 FAUX
• 001 VRAI
• 002 FAUX sur une donnée de repli
• 003 VRAI sur une donnée de repli
• 020 contrôle impossible

Il est restitué au donneur d'ordre 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.

La liste exhaustive des codes retours est décrite dans le guide d'implémentation.

L'algorithme communautaire de fiabilisation

Contexte d'utilisation

L'algorithme permet de fiabiliser les coordonnées bancaires du titulaire du compte dont l'IBAN est fourni. Il compare les données fournies par le donneur d’ordre et celles dont le PSP teneur du compte du titulaire de compte dispose. Le donneur d’ordre 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 le donneur d’ordre d'utiliser lui aussi des données venant de pièces d'identité
• en aucun cas le PSP teneur du compte du titulaire ne communiquera les éléments d'identification du compte dont il dispose (nom, date/lieu de naissance, SIREN..etc..)
• il est à la charge du donneur d’ordre de transmettre les éléments liés aux seules coordonnées bancaires de domiciliation et non les coordonnées commerciales.

Si le donneur d’ordre dispose, pour le titulaire, d’un relevé d'identité bancaire sécurisé, par 2D-DOC par exemple, l'utilisation de l'algorithme permettra essentiellement le contrôle des opérations autorisées sur le compte et le statut de ce compte (ouvert/fermé).

Cet algorithme prévoit par ailleurs des contrôles différents pour les particuliers et pour les personnes morales.

Caractéristiques de l'algorithme

• Tous les adhérents SEPAmail utilisent le même algorithme pour avoir une cohérence vis-à-vis des donneurs d’ordre. Néanmoins :

1. l'algorithme est susceptible d'évoluer
2. les adhérents 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 titulaire
  • 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

1ère étape, commune à tous types de titulaires de compte : Contrôle IBAN valide et existant, compte non soldé

Le 1^er 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 titulaires de compte : Contrôle du type de titulaire

Le 2^ème contrôle vérifie que le type de titulaire transmis (entreprise/pro ou particulier) est identique à celui enregistré dans la base Tiers du PSP tenant le compte. Ce contrôle est binaire. Il ne s'appuie pas directement sur une donnée "type de titulaire du compte" fournie par le donneur d’ordre 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 titulaire 'entreprise/professionnel/association'.
• La présence de PrivateIdentification est considérée comme un type de titulaire 'particulier'.

Ce type est contrôlé avec la base Tiers du PSP tenant le compte.

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.

---

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 du PSP tenant le compte.

En cas de SIRET fourni et résultat KO, un contrôle de repli sur le SIREN est effectué.

---

3ème étape, concernant les particuliers - sous-étape A : Contrôle de l'une des pièces d'identité

Concernant les particuliers, le contrôle de fiabilité se fait sur une pièce d'identité. Ce contrôle inclut:

• le type de la pièce

• le n° de la pièce

• la date de délivrance de la pièce (la date de délivrance peut être communiquée; sa présence renforce la fiabilité du contrôle pour le donneur d’ordre mais n’est pas obligatoire)

(L'IG du message VerificationRequest prévoit à ce jour ces données pour le passeport (pass_number; pass_date) et la carte nationale d'identité (idcard_number; idcard_date)).

Ce contrôle effectué sur le titulaire principal du compte doit également être effectué par le PSP sur les pièces d'identité enregistrées dans sa base Tiers pour l'ensemble des co-titulaires du compte en cas de compte joint. Le résultat du contrôle du ou des triplet(s) (type; n°; date- la date pouvant être non renseignée) est rendu sous une et une seule catégorie (la catégorie 11) et un seul code sur 5 positions.

Sur ce contrôle:

• Le code résultat 'VRAI' (001) est attribué si au moins un des triplets fournis par le donneur d’ordre correspond à un des triplets présents dans la base Tiers du PSP tenant le compte, pour ce compte.

• Le code résultat 'FAUX' (000) est attribué si aucun des triplets fournis par le donneur d’ordre ne correspond à l'un des triplets présents dans la base Tiers du PSP tenant le compte, pour ce compte.

• Le code résultat 020 est attribué si aucun triplet n'est fourni ou bien si le contrôle est impossible par le PSP teneur du compte.

• En cas de code 001 ou 000, l'étape 3 est terminée.

• En cas de code 020, l'étape 3 se poursuit par un contrôle sur le nom du titulaire du compte.

3ème étape, concernant les particuliers - sous-étape B : Contrôle des noms

Algorithme spécifique de contrôle du nom

Les données gérées par l'algorithme sont :

• le nom
• le prénom
• un autre nom (qui inclut le cas du nom d'usage / nom marital)
• le nom joint et le prénom joint (nom et prénom du co-titulaire du compte dans le cas d'un compte joint)

l'algorithme suppose :

• que les adhérents SEPAmail gèrent dans leur base Tiers des champs distincts pour la zone NOM et la zone PRENOM (ceci s'appliquant au titulaire principal mais également aux autres titulaires: champs distincts pour la zone AUTRE NOM, la zone NOM JOINT et la zone PRENOM JOINT etc..).
• que le donneur d’ordre envoie une zone unique (champ Name ISO 20 022) contenant le nom et le prénom.

le PSP tenant le compte du titulaire effectue successivement trois comparaisons pour chacune desquelles il calcule une note de pertinence :

• le champ Name ISO, ci-après dénommé champ CLIENT avec les champs NOM et PRENOM de sa base Tiers
• le champ CLIENT avec les champs AUTRE NOM et PRENOM de sa base Tiers
• le champ CLIENT avec le NOM JOINT et PRENOM JOINT de sa base Tiers

Par souci d'optimisation, les comparaisons sont interrompues dès la note de pertinence maximale obtenue.

Principes de la note de pertinence

• la note de pertinence ne dépend pas du nombre de mots ou de lettres contrôlés
• la note de pertinence est identique suivant qu'un nom composé soit écrit tout attaché ou avec des espaces
  • Le Goff donne le même résultat que Legoff
  • de La Fontaine donne le même résultat que delafontaine
• l'ordre des mots est important :
  • Goffle ne donne pas le même résultat que Legoff
  • la fontaine de ne donne pas le même résultat que delafontaine
• la note de pertinence ne dépend pas de la casse des mots : de La Fontaine donne le même résultat que DELAFONTAINE
• la note de pertinence donne le même résultat lorsque le nom et le prénom sont inversés

= Définitions =

• Le champ CLIENT correspond au champ envoyé par le donneur d’ordre.
• Le champ NOM correspond au champ lu dans la base Tiers du PSP tenant le compte.
• Le champ PRENOM correspond au champ lu dans la base Tiers du PSP tenant le compte.

= Etapes préalables au calcul =

1. Normalisation du champ CLIENT

• le champ CLIENT est transformé en lettres CAPITALES non accentuées
• le champ CLIENT doit être séparé en mots signifiants
  • un mot signifiant est une chaîne de caractères séparée par un caractère de ponctuation . { : / \ , ; - _ " " (espace)} ou tout autre caractère utilisé pour mettre en évidence une séparation
  • Jean-françois.Le-Goff devient {JEAN ; FRANCOIS ; LE ; GOFF}
• à l'issue de ce traitement le champ CLIENT devient une liste de mots signifiants que nous allons identifier sous forme CLIENT_i (i variant de 1 à n), n étant le nombre de mots trouvés dans le champ CLIENT

2. Concaténation du champ NOM

• le champ NOM est transformé en lettres CAPITALES non accentuées
• les caractères de ponctuation (les mêmes que ceux identifiés pour la normalisation du champ CLIENT) sont supprimés
• LE GOFF devient LEGOFF

3. Concaténation du champ PRENOM

• le champ PRENOM est transformé en lettres CAPITALES non accentuées
• les caractères de ponctuation (les mêmes que ceux identifiés pour la normalisation du champ CLIENT) sont supprimés
• Jean_Francois devient JEANFRANCOIS

= calcul de la note =

La note de pertinence est mise à zéro en début de procédure

Chaque mot CLIENT_i est comparé au champ NOM dans l'ordre croissant de l'index i

• en cas de correspondance, le champ NOM (correspondance stricte) ou les lettres du champ NOM (correspondance par inclusion) sont mis de côté
• si l'ensemble des lettres du champ NOM a été mis de côté à la fin de la procédure (pour i=n) alors la note de pertinence est augmentée de +200
• si seulement une partie des lettres a été mise de côté, alors la note de pertinence est augmentée au prorata : (nombre de lettres mises de côté)*200/(nombre de lettres totales du champ NOM)
• Ainsi, dans notre exemple,
  • JEAN (CLIENT₁) est comparé à LEGOFF => +0
  • FRANCOIS (CLIENT₂) est comparé à LEGOFF => +0
  • LE (CLIENT₃) est comparé à LEGOFF => (les lettres LE sont mises de côté)
  • GOFF (CLIENT₄) est comparé à GOFF => (les lettres GOFF sont mises de côté)
  • toutes les lettres du champ NOM (L E G O F F) ont été mises de côté => +200

Chaque mot CLIENT_i est comparé au champ PRENOM dans l'ordre croissant de l'index i

• en cas de correspondance, le champ PRENOM (correspondance stricte) ou les lettres du champ PRENOM (correspondance par inclusion) sont mis de côté
• si l'ensemble des lettres du champ PRENOM a été mis de côté à la fin de la procédure (pour i=n) alors la note de pertinence se voit augmentée de +200
• si seulement une partie des lettres a été mise de côté, alors la note de pertinence est augmentée au prorata : (nombre de lettres mises de côté)*200/(nombre de lettres totales du champs PRENOM)
• Ainsi, dans notre exemple,
  • JEAN (CLIENT₁) est comparé à JEANFRANCOIS => (les lettres JEAN sont mises de côté)
  • FRANCOIS (CLIENT₂) est comparé à FRANCOIS => (les lettres FRANCOIS sont mises de côté)
  • LE (CLIENT₃) est comparé à vide => +0
  • GOFF (CLIENT₄) est comparé à vide => +0
  • toutes les lettres du champ PRENOM ont été mises de côté => +200

Pour chaque mot CLIENT_i restant,

• soustraire 50 de la note de pertinence
• Ainsi, dans notre exemple,
  • tous les CLIENT_i ont été utilisés donc aucune soustraction
  • la note de pertinence est alors égale à 400

Calcul de la note de pertinence sur les champs "AUTRE NOM" et "PRENOM" de la base Tiers

Les étapes préalables et l'algorithme décrits précédemment sont appliqués à l'identique en remplaçant le champ NOM par le champ AUTRE NOM, mais en gardant le champ PRENOM original.

Une nouvelle note de pertinence est déterminée.

Calcul de la note de pertinence sur le champs "NOM JOINT" et "PRENOM JOINT" de la base Tiers

Les étapes préalables et l'algorithme décrits précédemment sont appliqués à l'identique en remplaçant le champ NOM par le NOM JOINT et le PRENOM par le PRENOM JOINT. Une nouvelle note de pertinence est déterminée.

Note retenue en cas de comparaison multiple

Selon les notes réellement calculées, le code de réponse fourni au donneur d’ordre sera le maximum des notes des comparaisons respectives entre les champs (NOM, PRENOM), (AUTRE NOM, PRENOM) et (NOM JOINT, PRENOM JOINT). Ce code est fourni sous la catégorie 09.

Extension de contrôle du nom en cas de champ supplémentaire complété par l'émetteur

Lorsque le donneur d’ordre renseigne en complément du champ NOM, les champs Identification et Issuer pour le type de donnée "other_name", les 3 types de comparaison précédemment identifiés sont appliqués en remplaçant le CLIENT par la donnée présente sous "other_name" dénommée CLIENT B.

Une note de pertinence est calculée pour chacune des 3 comparaisons.

le code de réponse fourni au donneur d’ordre sera le maximum des notes des comparaisons respectives des champs (NOM, PRENOM), (AUTRE NOM, PRENOM) et (NOM JOINT, PRENOM JOINT).

Ce code est fourni sous la catégorie 10.

Impact des catégories 09 et 10 dans la détermination de l'indicateur de réponse global

Dans le cas où un code a été déterminé sous la catégorie 09 et sous la catégorie 10, le code concourant à la détermination de l'indicateur de réponse globale est le maximum de la note obtenue sous chaque catégorie.

3ème étape, concernant les particuliers - sous-étape C : contrôle de la date et lieu de naissance

Le contrôle du nom peut être complété par un contrôle sur:

• la date de naissance
• la ville de naissance
• le pays de naissance

NB: l'utilisation de l'index ISO DateAndPlaceOfBirth dans le message VerificationRequest rend obligatoire (schéma ISO) le renseignement des sous-index BirthDate, CityOfBirth et CountryOfBirth. Chacun de ces 3 éléments correspond à une catégorie réponse (respectivement 06, 07 et 08).

Attention, ces données doivent être contrôlées par le PSP tenant le compte avec celles attachées au nom pour lequel il a obtenu la note de pertinence maximale.

4ème étape, commune à tous types de titulaires : Contrôle des opérations autorisées sur le compte

Le 4^ème contrôle vérifie que le n° de compte (IBAN) transmis est ouvert aux opérations mentionnées par l'émetteur dans sa requête (partie NON ISO):

• virements reçus (crédit du compte objet du contrôle IBAN)
• virements émis (débit du compte objet du contrôle IBAN)
• demandes de paiement RUBIS (débit du compte objet du contrôle IBAN)
• prélèvements / SDD (débit du compte objet du contrôle IBAN)
• prélèvements / SDD retour (crédit du compte objet du contrôle IBAN)
• crédits : virements reçus et retour de prélèvement
• débits : virements émis, présentation de pied de factures et prélèvements/SDD
• débits et crédits

Il existe un contrôle par catégorie d'opération mentionnée par le donneur d’ordre dans sa requête. Attention, ces contrôles ne concourent pas à la détermination de l'indicateur de réponse global et n'aboutissent pas à un code raison sur 5 positions à la différence des autres contrôles de l'algorithme. Chaque contrôle effectué sur une catégorie d'opération fait l'objet d'une réponse spécifique true/false dans la partie non ISO du Report.