Les mécanismes d'identification

Le BIC et l’IBAN

La problématique de l’adressage dans une messagerie repose sur le partage des identifiants. SEPAmail a apporté une double réponse, non dans une approche technique, mais dans une vision métier :

• La messagerie étant plutôt pour une sécurisation au travers de banques, le BIC est l’identifiant du ‘‘fournisseur d’accès SEPAmail’’
• L’identifiant du client de la banque peut être choisi parmi plusieurs (numéro de compte, numéro de carte, identifiant dédié banque en ligne) mais la proximité du SEPA et la promesse de services autour des paiements rendent le choix de l’IBAN, paneuropéen, une évidence.

Même si le sigle IBAN@BIC est utilisé, il ne correspond qu’à une vue métier et non à une vue technique. Du point de vue métier :

• Le BIC, identifiant des banques, n’est pas sensible et donc circule en clair
• l’IBAN, identifiant des clients, est par nature une donnée sensible et doit être protégée. Il ne peut donc circuler que sous un format confidentiel

le BIC : des contraintes pour les clients

De plus, la première expérimentation avec SFR a mis en évidence :

• le créancier peut facilement retrouver l'IBAN à partir du numéro de compte client (BBAN en anglais), par un algorithme connu
• le créancier ne dispose pas de moyen fiable de trouver un BIC.

Prenant en compte la réalité du terrain, anticipant aussi la pression réglementaire et projetant la norme SEPAmail dans une utilisation client-banque, SEPAmail a proposé de ne pas obliger le client à fournir de BIC mais uniquement un IBAN, charge à la banque SEPAmail de fournir l'enrichissement.

Une identification non figée

Dés le début de SEPAmail, les standards et la mise en œuvre se sont attachés à ne pas solidifier l’usage du BIC et de l’IBAN pour être en mesure d’utiliser d’autres types d’identification pouvant répondre à des besoins complémentaires à ceux du SEPA. En effet dans le SEPA, l'utilisation de l’IBAN ne couvre que les paiements par virement ou prélèvement.

De manière plus générale, toute identification de type identifiant@bic peut devenir intéressante pour SEPAmail. Cette caractéristique, couplée à la notion précédente d'enrichissement, permet de proposer toute une gamme d'identifiant dans SEPAmail.

Identification par PAN : Primary Account Number, ou tout simplement numéro de carte bancaire

le numéro de carte est un identifiant au moins aussi, voire plus, connu que l'IBAN. Il a aussi l'avantage d'être souvent présent avec le client, le porteur de carte, plus que le Relevé d'identité bancaire !

le PAN peut être facilement utilisé pour :

• identifier le BIN (bank identification number) à partir du PAN. Dans la plupart des cas, prendre les 6 premiers caractères suffit
• associer le BIC au BIN : ceci se fait à partir du fichier des établissements géré par Cartes Bancaires ou par d'autres organismes pour d'autres places européennes
• formater les envois SEPAmail avec
  • le BIC et le PAN, ce dernier remplaçant l'IBAN pour identifier le client destinataire
  • le BIC et l'IBAN pour le client émetteur de l'envoi
• associer, au niveau de la banque destinataire de l'envoi, le PAN avec soit l'IBAN soit le compte référence du client. Par définition, tout émetteur de carte sait associer un numéro de carte avec un numéro de compte, ne serait-ce que pour débiter son client !

L'utilisation du PAN pourrait servir à une extension des avis de paiement aux paiements monétiques : JADE pour la monétique !

QXBAN : une identification SEPAmail

Même si l'IBAN devient couramment utilisé, il pose un souci de sécurité car c'est un élément sensible du client. Il peut être utilisé par certains fraudeurs, soit comme mode d'identification auprès d'un centre d'appel peu regardant sur les procédures d'authentification, soit pour générer des prélèvements y compris sans mandats préalables.

Dans le cadre de l'expérimentation RUBIS et de l'expérimentation SAPPHIRE, il est apparu les contraintes suivantes :

• il n'est pas acceptable de donner directement l'IBAN au créancier
  • il est difficile de promouvoir l'IBAN pour les clients dont le souci principal reste la communication de l'IBAN et donc qui continuent avec le chèque (car le prélèvement nécessite de communiquer l'IBAN)
  • il apparaît une augmentation de la sensibilité des bases de données « créanciers » dès lors que l'on y ajoute des numéros IBAN
• il n'est pas pratique d'échanger un IBAN entre 2 personnes.

SEPAmail a donc créé le QXBAN :

• un format d'IBAN (ou presque) pour rester compatible avec les développements et normes SEPAmail
• une utilisation interdite en compensation, donc pas de prélèvements possibles
• une utilisation peu ergonomique (grand nombre de caractères) pour éviter une utilisation dans des procédures d'authentification
• une utilisation réservée au réseau SEPAmail

Le format du QXBAN suit presque la norme des IBAN avec quelques spécificités :

• le country code est QX ce qui est le seul NON RESPECT de la norme des IBAN. Le code pays QX n'existant pas, il ne peut y avoir de compensation avec un tel code.
• le code banque DOIT être le BIC de la banque, ou tout du moins celui de routage SEPAmail des flux
• le numéro de compte DOIT être un tirage aléatoire sous la responsabilité de la banque du client
• le numéro de compte DOIT utiliser la longueur maximale pour augmenter le niveau d'aléa du QXBAN.

Il est bien entendu que la banque qui a émis un QXBAN s'engage à traiter sa réception, et donc à prévoir la correspondance interne entre le QXBAN et l'IBAN du client.

On trouve ici l'algorithme de génération du QXBAN

Relevé d'identité SEPAmail : RIS2D

Il est apparu une synergie intéressante des travaux sur le QXBAN et des travaux du projet 2D-DOC. Ceci a conduit à définir la notion de RIS2D ou relevé d'identité SEPAmail reprenant :

• la logique de relevé de compte bancaire mais adapté à l'identification d'un "compte SEPAmail"
• la matérialisation sous forme de code-à-barre 2D tant pour une simplification de la lecture qu'au vu du nombre de données à gérer.

Le RIS2D reprend les informations de NOM, PRENOM, QXBAN et une signature de ces données au format 2D-DOC.

Il n'est pas prévu de représentation du Relevé d'Identité SEPAmail hors de celle en format RIS2D.

Le format intègre, outre le code-à-barre :

• les étoiles apportant un rappel du logo SEPAMAIL
• un début de mention du prénom et du nom en clair pour pouvoir s'y retrouver.

Protection des identifiants pour le paiement par virement

Le schéma suivant montre comment il est possible d'éviter de communiquer son IBAN pour le paiement par virement et donc de protéger cette donnée sensible.

1. A l'inscription de son client au service, la banque du client génère le QXBAN, maintient la base de données {QXBAN->IBAN} et le remet à son client sous forme de RIS2D (puce 1)
2. le client a ainsi donc tout le loisir de mettre à disposition du créancier ce fichier image facilement lisible et dont le créancier peut extraire le QXBAN, le nom et le prénom (puce 2)
3. le créancier peut démarrer la séquence de demande de règlement en utilisant exclusivement le QXBAN de son client (flux bleu)
4. la banque recevant la demande peut identifier son client grâce à sa base de données {QXBAN->IBAN} (puce 4) et proposer le service de validation à son client. Notons au passage que le compte qui sera débité peut être un compte quelconque de ce client si la banque offre ce service.
5. le flux de retour (flux rouge) se fait en utilisant le QXBAN du client débiteur
6. le virement utilise l'IBAN du donneur d'ordre. Cependant cet IBAN reste dans l'enceinte de la banque du créancier car celle-ci n'a pas le droit de remettre l'IBAN du donneur d'ordre à un bénéficiaire.

Protection des identifiants pour le paiement par prélèvement

Le prélèvement pose une problématique certaine du fait de l'obligation de donner son IBAN au créancier. Une utilisation des identifiants (RIS2D-QXBAN) et des flux SEPAmail pourrait permettre de s'affranchir de cette contrainte. En effet la norme SEPA DIRECT DEBIT impose une référence unique de mandat (RUM) que l'on peut mettre à profit.

1. comme précédemment, la banque du débiteur a généré et mis à disposition un RIS2D (puce 1)
2. le client débiteur donne son RIS2D ou son QXBAN au créancier tout en demandant un paiement par prélèvement. Notons au passage que cela pourrait pousser plus de clients à ce mode de paiement.
3. le créancier génère une demande de mandat avec le service GEMME@SEPAMAIL en utilisant le QXBAN et la RUM, référence unique du mandat (flux bleu)
4. la banque du débiteur identifie son client grâce à la base de données {QXBAN->IBAN}, fait choisir le compte de prélèvement désiré par son client et renvoie (flux rouge) le mandat de prélèvement accepté par son client et avec le véritable IBAN du client. En parallèle, la banque du débiteur mémorise les RUM acceptées par son client et en gère la validité.
5. la banque du créancier constitue une base de données {créancier/RUM -> IBAN} et indique à son client créancier que le mandat est accepté
6. il suffira au créancier de fournir la RUM comme identifiant de paiement dans ses fichiers d'initiation de prélèvement (flux noir)
7. la banque du créancier complète la RUM avec l'IBAN trouvé dans la base de données {créancier/RUM -> IBAN} et émet en compensation.

Ainsi les identifiants sensibles (IBAN) restent dans les enceintes bancaires pour une meilleure protection des clients et une plus grande simplicité de gestion par le créancier.

De plus le mécanisme précédent ne crée pas de lien fort entre la banque du créancier et le créancier. Celui-ci peut changer de banque assez simplement :

1. le créancier envoie des avenants de mandats en utilisant le couple QXBAN/RUM en passant par sa nouvelle banque
2. la banque du débiteur peut répondre immédiatement sans validation nécessaire par le débiteur puisque nous sommes dans le cas d'un amendement
3. la nouvelle banque du créancier constitue la base de données {créancier/RUM -> IBAN} et pourra ainsi compléter les flux de prélèvements

ICQX

l'ICQX est un identifiant des personnes morales participant à SEPAmail. La normalisation de l'ICQX est dérivée de celle de l'ICS.