SEPAmail: onze principes

Voici quelques principes qui, à mon sens, fondent l'approche SEPAmail et structurent le standard:

• SEPAmail est une messagerie au minimum 4 coins, 2 utilisateurs, 2 adhérents, couverts par au moins trois contrats
• SEPAmail permet des échanges de dialogues structurés formalisés au sein d'applications, qui, lorsqu'elles sont éditées par la norme, ont une portée globale (à tous les adhérents)
  
• SEPAmail met en œuvre un procédé d’accusé de réception systématique (l'acquittement) qui est garanti par les adhérents. Cet accusé de réception induit l'authentification des adhérents et l'intégrité des messages échangés
  
• SEPAmail permet de garantir l'authentification des personnes physiques liés à un identifiant (le qxban). Le transcodage entre un IBAN et un QXBAN est toujours assuré par l'adhérent émetteur du QXBAN. L'IBAN est ainsi protégé dans le dialogue entre les utilisateurs, même lorsque un message articule un paiement
• SEPAmail permet, par la vertu du modèle 4 coins et de la chaîne contractuelle, à un adhérent de proposer à son client, l'utilisateur SEPAmail, des services autour du flux quand ce flux est vu par l’adhérent : enrichissement du flux, vérification, articulation d'un paiement (le rôle des établissements de paiement est un plus pour l'utilisateur)
  
• SEPAmail garantit à l'utilisateur que l'adhérent doit respecter des règles et qu'il y a un juge arbitre de ces règles quand le protocole ne permet pas d'exclure intrinsèquement les tricheurs. Le juge arbitre est la Banque de France quand on parle de la loi française et c'est le scheme quand on parle de la charte des adhérents SEPAmail.
• tous les messages constitutifs d'une application sont autoporteurs de l'information pour qu'une partie du dialogue permette de réaliser l'action suivante
• SEPAmail ne présume pas le canal d'échange de l'information entre un adhérent et son client, l'utilisateur et notamment le moyen de l'authentification de l'utilisateur par l'adhérent
  
• l'extension de norme à la relation "pair à pair" doit être possible
• le modèle 4 coins peut devenir un modèle 5,6 coins ou plus mais pas un modèle 2 ou 3 coins dans le cadre communautaire, car c'est lui qui garantit beaucoup des principes ci-dessus et ces modèles qui rendent la confiance à l'utilisateur (les avocats, les médecins, les notaires) et oblige à un juge arbitre clair protégeant les utilisateurs
• sepamail doit pouvoir fonctionner nativement en mode canonique avec les infrastructures et les protocoles de messageries électroniques standards

SEPAmail et mon client de messagerie

Puis-je recevoir un contenu SEPAmail dans mon client de messagerie habituel ?

A priori, l'idée est assez naturelle.

Mon client de messagerie (Mail User Agent ou MUA) sait :

• récupérer et transmettre un courriel à son facteur usuel (Mail Transfert Agent ou MTA)
• chiffrer/déchiffrer un contenu au format S/MIME
• afficher un courriel
• stocker, classer, indexer un contenu SMTP dans un format unitaire ou globalisé

Bref, il sait lire, écrire, stocker, récupérer et transmettre pour envoi une enveloppe SEPAmail.

Que lui manque-t-il alors pour qu'il devienne mon client SEPAmail (Interface Homme Machine IHM) ?

Pas grand chose à vrai dire...

Il faut juste que je puisse :

• ne voir que l'information utile dans la missive (format xml) et le message (format xml)
• voir cette information sous une forme lisible
• être aidé dans la mise en œuvre du protocole SEPAmail, et notamment pour l'acquittement automatique et obligatoire

Comment faire cela simplement ?

Je peux par exemple imaginer installer une extension qui puisse mettre en œuvre les fonction suivantes autour de la missive :

• affichage à l'utilisateur humain de l'entête de la missive pour les champs importants :
• horodatage
• expéditeur
• destinataire
• priorité
• type de missive
• affichage à l'utilisateur humain du contenu de la missive selon son type
• possibilité d'acquitter la missive nominale de façon manuelle (voire automatique) avec un code d'acquittement validant au moins la bonne distribution

Je peux aussi imaginer qu'il y ait une extension pour chaque application SEPAmail (RUBIS, GEMME, JADE, ...) qui me fournisse les fonctions suivantes :

• affichage à l'utilisateur humain du contenu du message selon son type, sous une forme à trouver, à défaut une table de type formulaire
• affichage des binaires contenus dans le messages sous forme de pièces jointes classiques après vérification antivirale locale
• possibilité de mettre en œuvre le message suivant s'il existe au sein de la séquence liée à l'application SEPAmail en reprenant les informations du message précédent

En extension de norme, je peux me servir de mon adresse de courriel classique avec mon relais d'acheminement (ma banque ou l'adhérent SEPAmail qui me fournit le service SEPAmail) et il me faudra alors associer à cette adresse de courriel un biclé certifié et insérer les certificats de mon relais d'acheminement.

Quelques petits schémas pour illustrer

exemple d'architecture autour d'un MUA

Voici ce que pourrait être l'architecture applicative autour de mon client de messagerie habituel :

• trois acteurs :
• l'adhérent SEPAmail qui fournit le service, par exemple ma banque
• l'utilisateur SEPAmail qui utilise le service, par exemple, moi, client de ma banque ayant souscrit le service SEPAmail RUBIS
• mon fournisseur d'accès internet qui m'a également fourni une adresse de courriel et les services de son MTA
• cinq composants :
• la plate-forme de l'adhérent, que je ne connais pas et accessible via par des adresses de courriels fournies par l'adhérent
• le MTA de mon FAI, que j'utilise sans vraiment le savoir en ayant configuré au démarrage mon client de messagerie (configurations smtp et imap/pop)
• le parefeu de mon réseau (ma Box) ou mon système d'exploitation, configuré le plus souvent nativement pour permettre le passage de courriel
• mon client de messagerie (MUA) préféré et utilisé qui va accueillir des extensions SEPAmail pour être compatible avec ce service
• un anti-virus que mon MUA sait appeler si nécessaire, notamment quand une extension SEPAmail extrait une pièce jointe et me l'expose à l'ouverture ou l'exécution
• trois zones :
• le SI de l'adhérent SEPAmail, inconnu pour moi
• internet, également peu connu de moi
• mon réseau domestique ou de travail, symbolisé sur le schéma par le carré en pointillé autour de mon MUA

Voici ce que pourrait être l'architecture applicative au sein de mon client de messagerie :

• un composant de cryptographie pour permettre la gestion des certificats avec le coffre-fort de mon système d'exploitation ainsi que la mécanique cryptographique autour du chiffrement et de la signature
• un composant permettant la vérification d'une authentification sous un protocole type SAPPhire
• une extension commune autour de la missive
• des extensions pour chacune des applications SEPAmail que j'ai contractées.

  

  composants du client de messagerie

   

Que reste-t-il donc à faire pour que cela fonctionne ?

Il faut simplement que des éditeurs développent des extensions pour les clients de messagerie usuels (Outlook, Thunderbird, Mail)...

Vocabulaire SEPAmail : l'ICQX

A partir de la version 1206, SEPAmail utilise un nouvel identifiant dénommé ICQX, pour "Identifiant Créancier QX" -- rappelons que QX est le pseudo-code pays identifiant le Scheme SEPAmail, utilisé notamment dans les QXBAN.

Voici quelques éléments répondant aux principales questions se rapportant à cet identifiant.

1. Qui peut disposer d'un ICQX ?

Toute personne morale. Toutefois, cet identifiant n'a réellement de sens que si cette personne morale intervient comme créancier dans l'une des applications de SEPAmail.
Bien que l'ICQX soit inspiré de l'ICS (Identifiant Créancier SEPA), il ne lui est aucunement relié. Il n'est d'ailleurs pas nécessaire d'avoir un ICS pour demander un ICQX, ni inversement.

2. Que contient un ICQX ?

Techniquement, c'est un identifiant de 35 caractères alphanumériques, contenant une référence au pays d'appartenance (légale) du créancier. Sémantiquement, il ne contient rien d'autre. Toutefois, en son rôle d'identifiant (cf. l'intéressant point de vue de Michel Volle à ce sujet dans un autre article), il permet d'accéder à toutes les informations significatives pour un créancier personne morale : identification de la personne morale, éléments bancaires ....

3. Comment obtenir un ICQX ?

Seul le Scheme, ou sa déclinaison locale, le QXOO, peut attribuer un ICQX. Toutefois, le créancier souhaitant en obtenir un doit obligatoirement passer par sa banque -- ou l'une de ses banques, qui jouera le rôle d'intermédiaire avec le Scheme ou le QXOO. Pour obtenir un ICQX, l'entreprise doit fournir des éléments d'identification légaux (RCS, adresse du siège ...), dont la banque a la responsabilité de vérifier l'exactitude (authentification), et qui constituent une ICQXCard.
La création de l'ICQX entraîne l'inscription du créancier dans le référentiel ICQX@SCHEME de SEPAmail, à partir duquel le Scheme fournira, à leur demande, les informations nécessaires aux membres du réseau.

4. J'ai un ICQX -- et maintenant ?

Maintenant, cet ICQX sert d'identifiant unique dans l'ensemble du système SEPAmail. Il est sûr, puisqu'il ne correspond à rien en-dehors de SEPAmail. Il est fiable, puisque votre banque a validé votre identité. Il vous permet donc de transmettre, grâce à un seul identifiant, une "carte d'identité" complète. Vous pouvez maintenant vous abonner aux services proposés par SEPAmail (inscription RUBIS, GEMME émission ...) en fournissant simplement cet ICQX. Pour chaque service, vous disposerez d'une ServiceCard, strictement interne à SEPAmail, qui servira à vous mettre en relation avec les autres utilisateurs de ce service.

5. J'ai plusieurs banques. Dois-je avoir plusieurs ICQX ? Puis-je en avoir plusieurs ?

Non. L'ICQX est unique, et vous devez donc choisir la banque par le biais de laquelle vous le demandez. Si vous changez de banque, vous devrez demander une mise à jour à la nouvelle banque.
En revanche, lorsque vous vous inscrivez à un nouveau service, vous pouvez choisir le QXBAN associé, qui peut donc ne pas correspondre à la même banque.

6. Mon ICQX est-il éternel ? Puis-je le supprimer ?

L'ICQX a une durée de validité, prévue contractuellement entre votre banque et vous. A l'issue de cette durée, il devra être prorogé, ce qui implique notamment une nouvelle vérification des éléments d'identité.
Il n'est pas possible de supprimer un ICQX. En revanche, vous pouvez désactiver tous les services associés, ce qui, dans la pratique, reviendra au même.

7. Mon ICQX va-t-il être revendu à d'autres sociétés ?

Non, l'ICQX sert uniquement de façon interne à SEPAmail, et n'a pas vocation à être fourni ou vendu à qui que ce soit.

Vocabulaire SEPAmail : l'écosystème

Définition

Un écosystème SEPAmail est un ensemble de types de message ayant le même sujet.
Par exemple, les messages autour du mandat de prélèvement sont regroupés au sein de l'écosystème direct.debit.

Un type de message SEPAmail doit et ne peut appartenir qu'à un seul écosystème.

L'ensemble des écosystèmes SEPAmail forme donc une partition des messages SEPAmail.

Utilité

Les écosystèmes sont utilisés pour l'organisation de la messagerie :

• le routage avec un aiguillage des enveloppes SEPAmail, d'après une adresse de courriel liée à l'écosystème selon le masque [ecosystem]@[bic].sepamail.eu
• la sécurité avec des bi-clés liées à l'adresse de courriel de l'écosystème
• les interfaces avec les systèmes d'information des adhérents SEPAmail et des utilisateurs SEPAmail selon l'écosystème
• le classement des types de messages et des schémas selon l'écosystème

Les écosystèmes SEPAmail

Il a été défini à ce jour dix écosystèmes :

• credit.activation, autour de l'avis de virement
• digital.signature, autour de la signature numérique
• direct.debit, autour du prélèvement
• generic, autour du message générique
• identification.verification, la vérification d'identité bancaire
• payment.activation, autour de la demande de règlement
• scheme, tout ce qui concerne l'organisation, notamment les référentiels
• secure, tout ce qui concerne la sécurité, notamment l'inscription aux services et la mise en place des espaces de confiance
• test , pour réaliser des tests
• trade.service, autour des services commerciaux, dont la transmission de la facture

Le nom d'un écosystème est toujours en langue anglaise et les mots le composant sont séparés par le délimiteur point [.].

L'écosystème s'appelait de 2008 à 2011 la famille, ce qui n'avait pas d'équivalent naturel en anglais, d'où le changement de vocabulaire fin 2011, proposé par le groupe de travail "fonctionnel et études" de la communauté SEPAmail.

Lien avec les applications SEPAmail.

Trois écosystèmes correspondent à des fonctions transverses : scheme, test et secure.
Les autres sont liés chacun à une application SEPAmail selon la correspondance :

• credit.activation ~ JADE
  
• digital.signature ~ JASPE
  
• direct.debit ~ GEMME
  
• generic ~ AGATE
  
• identification.verification ~ DIAMOND
  
• payment.activation ~ RUBIS
  
• trade.service ~ IOLITE

Il est possible que plusieurs applications utilisent des messages du même écosystème mais ce n'est pas le cas pour le moment.

Par nature, un écosystème regroupe les messages autour du même sujet alors que plusieurs applications peuvent voir le jour selon les besoins de la communauté.

Le concept de l'application SEPAmail est donc orienté "besoin métier" alors que le concept de l'écosystème est orienté "organisation de la messagerie".

La norme ISO UNIFI 20022, norme de référence de SEPAmail

L'ISO 20022, c'est quoi ?

ISO 20022 est une norme qui succède à l'ISO 15022 dénommée aussi UNIFI ou "Financial Services - Universal financial industry message scheme".
Avec la norme ISO 20022, les prestataires de services financiers simplifient les transactions nationales et internationales en partageant une série de messages unifiés, des représentations communes de processus métier par grand segment.

On y trouve notamment les segments :

• acmt "Account Management" Gestion de compte
• admi "Administration" Administration
• auth "Authorities" Autorités
• caaa  "Acceptor to Acquirer Card Transactions" Transactions de l'accepteur à l'acquéreur
• camt "Cash Management" Gestion de trésorerie
• catm  "Terminal Management"
• pacs  "Payments Clearing and Settlement"
• pain  "Payments Initiation" Initiation du règlement
• reda  "Reference Data" Données de référence
• seev  "Securities Events" 
• semt  "Securities Management" Gestion des titres
• sese  "Securities Settlement" 
• setr  "Securities Trade"
• trea  "Treasury" Trésor
• tsin  "Trade Services Initiation"
• tsmt  "Trade Services Management"
  

SEPAmail et l'ISO 20022

SEPAmail est fondé sur le principe de ne rien inventer qui existe déjà et d'utiliser le plus possible des standards déjà largement répandus.
Il était donc naturel d'utiliser les messages de l'ISO 20022 pour décrire les échanges d'information dans les applications SEPAmail.

Toutes les applications SEPAmail qui sont des applications de paiement documentaire sont accrochées à un segment de l'ISO 20022 et plus particulièrement à quelques messages.
Ainsi, RUBIS utilise le pain.013 et le pain.014.

Afin d'intégrer des besoins que n'a pas encore prévu l'organisme de normalisation, la plupart des messages SEPAmail encapsulent le message de l'ISO tel quel et les autres besoins dans une partie dite non-ISO bien distincte.

La liaison entre les applications SEPAmail et l'ISO 20022

On retrouve ci-dessous un tableau récapitulatif des applications SEPAmail et le segment et les messages d'UNIFI qui sont utilisés.

Application SEPAmail	Description	iso 22022
RUBIS	la demande de règlement	pain.013 pain.014
GEMME	le mandat de prélèvement	pain.009 pain.012
DIAMOND	vérification d'identifiant bancaire	acmt.023 acmt.024
JADE	l'avis de virement	pain.001
IOLITE	la transmission de facture	tsin.xxx

Références

 On trouvera tout ce qu'il faut savoir sur l'ISO 20022 sur son site à l'adresse http://www.iso20022.org.

Vocabulaire SEPAmail : la messagerie SEPAmail, les applications SEPAmail

Il ne faut pas confondre la messagerie SEPAmail et les applications SEPAmail qui utilisent la messagerie SEPAmail.

 

La messagerie SEPAmail

La messagerie SEPAmail est un dispositif permettant à deux entités économiques européennes de s'échanger de l'information de façon sécurisée.
Ce dispositif est mis en place par un réseau d'adhérents, essentiellement des banques européennes.
Il repose sur des standards de l'internet (IP, DNS, SMTP, S/MIME, syslog).
Un modèle en couches (enveloppe/missive/message) est proposé comme standard par la communauté SEPAmail. Ce modèle permet de spécifier de façon assez élégante des règles autour de l'échange, de l'adressage, du routage et de la sécurité.

 

Les applications SEPAmail

Les applications SEPAmail ont des noms de pierres précieuses.
A ce jour, on compte 7 applications :

• AGATE, la pièce jointe générique
• DIAMOND, la vérification d'identifiant bancaire
• GEMME, le mandat de prélèvement
• IOLITE, la transmission de facture
• JADE, l'avis de virement
• JASPE, la signature de document
• RUBIS, la demande de règlement

Une application SEPAmail utilise la messagerie SEPAmail pour échanger des messages structurés entre les parties dans un dialogue de type question/réponse avec la possibilité de joindre des documents. Comme la banque est un relais de cet échange, elle peut, si le contrat avec son client le précise, enrichir les flux et automatiser des opérations, notamment de paiement (carte, virement, prélèvement).

Avec cette messagerie sécurisée et des applications partagées entre les adhérents SEPAmail, la dématérialisation, l'automatisation et la sécurisation sont beaucoup plus aisées à mettre en œuvre pour les entités économiques.

La mise en place de SEPAmail  dans les relations entre les entités économiques présage ainsi des réductions de coûts très importantes.

 

Pour aller plus loin :

• présentation de la messagerie SEPAmail
• présentation de la notion d'application (SMIRK APP1103 en discussion)