Les mécanismes d'échange

Précisions sur les échanges

Dans son acceptation initiale, SEPAmail gère uniquement une interface interbancaire, c'est à dire celle des flux échangés entre les banques.

Dans la pratique, il se peut qu'une banque utilise soit le protocole SEPAmail, soit la structure SEPAmail (missive), soit les 2 dans ses échanges avec ses propres clients (interface client). Plus généralement, une banque peut aussi utiliser en interne (interface intrabancaire) les normes SEPAmail.

Trois mécanismes d'échanges ont été définis : courriel, web service, fichier.

Parmi ces mécanismes d'échange disponibles, seul le canal courriel est obligatoire, et doit être supporté par tous les adhérents à SEPAmail en interbancaire. Le mécanisme d'échange interbancaire fondé sur les Web services est facultatif (même si c'est celui mis en œuvre dans l'expérimentation).

Par ailleurs, SEPAmail est un système asynchrone par architecture. De ce fait, l'acheminement des messages ne peut être soumis à aucun engagement absolu quant au temps de transit. Les délais liés aux priorités des missives sont donc à mettre en perspective du canal utilisé – par exemple, une missive en priorité HIGHEST envoyée par courriel risque fort de ne pas être acquittée dans les délais prévus par ce niveau de priorité.

Un troisième mécanisme (fichier) a été défini pendant la phase d'expérimentation, initialement pour des besoins intrabancaires, et ne concerne JAMAIS l'interface interbancaire. Il peut être utilisé pour l'interface client ou l'interface intrabancaire.

La description donnée ici des mécanismes d'échange est essentiellement fonctionnelle, et légèrement technique. Des spécifications techniques complètes, traitant notamment des problématiques d'adressage, sont disponibles ici.

Le courrier électronique

Principe

Le mécanisme d'échange fondé sur le courrier électronique a été le premier implémenté, et le système SEPAmail en tire d'ailleurs son nom. Le principe en est simple : tous les éléments sont acheminés comme des messages mail.

Le contenu du mail doit donc être conforme au RFC 3851, le corps du mail étant obligatoirement une missive SEPAmail, apparaissant comme un attachement au format S/MIME (RFC 5321).

L'expéditeur et le destinataire du mail sont obligatoirement de la forme :

 <ecosystem>@<bic>.sepamail.eu

<ecosystem> correspond à un ensemble de messages acheminés.

Cinq écosystèmes sont actuellement supportés :

• direct.debit, qui est utilisé par l'application GEMME
• payment.activation, qui permet la création de virements de proximité, et est utilisé par l'application RUBIS
• identification.verification, pour la vérification d'identifiants bancaires, en rapport avec l'application DIAMOND
• secure, qui permet l'échange d'éléments de sécurité (certificats ou messages) entre tous les intervenants du système SEPAmail
• test, destiné comme son nom l'indique à des tests de configuration et/ou de communication

<bic> est le BIC de l'expéditeur (ou du destinataire). Dans le cas d'un échange interbancaire, les deux adresses doivent présenter ce BIC. Dans le cas d'un échange entre client et banque, l'adresse de l'expéditeur peut comporter un IBAN au lieu du BIC.

Les messages doivent être d'abord signés en utilisant la clé privée de signature de l'expéditeur, puis chiffrés en utilisant la clé publique de chiffrement du destinataire.

Les adresses IP des serveurs de mail doivent être déposées au préalable auprès du Scheme SEPAmail, ainsi que les certificats utilisés pour le chiffrement et la signature des messages.

Utilisation du canal courriel

En-dehors de l'utilisation d'adresses IP fixes et pré-déclarées pour router les messages, les messages acheminés par ce canal suivent les règles habituelles du courriel. Il est donc de la responsabilité de l'expéditeur de s'assurer de la bonne émission des messages qu'il envoie : les notifications d'erreur ou de non-remise sont acheminées par le canal standard entre MTA, et l'expéditeur doit prendre en charge la réexpédition éventuelle dans ce cas.

Le Web service

Principe

Cette méthode d'échange a été initialement prévue pour permettre à un émetteur de gérer ses messages de façon plus synchrone et plus directe que le courrier électronique.

Dans l'état actuel du système, il est déployé pour les échanges entre banques (connecteur interbancaire) et pour les échanges entre les entreprises et leurs banques (connecteur entreprise).

Le principe du Web service est similaire à celui du courrier électronique : le message envoyé comporte un en-tête basique, et un corps, respectant le format S/MIME, contenant une missive SEPAmail, signée puis chiffrée.

Dans l'en-tête comme dans la missive, l'identifiant de l'expéditeur peut être une adresse mail quelconque, gérée par le créancier, mais doit correspondre précisément au certificat utilisé pour chiffrer la missive. À défaut, la transmission sera rejetée. Le destinataire, lui, est de la même forme que pour le canal mail : <ecosystem>@BIC.sepamail.eu où le BIC est celui de la banque du créancier.

La connexion avec le Web service se fait au travers du protocole HTTP ou HTTPS. Les données binaires sont encodées au travers du protocole MTOM. Comme pour tous les autres mécanismes d'échange pouvant être ouverts vers l'extérieur, les messages doivent être, d'une part signés en utilisant la clé privée de signature de l'expéditeur, d'autre part chiffrés en utilisant la clé publique de chiffrement du destinataire. Tous les types de missives peuvent figurer dans un message WebService.

Ceci ouvre donc de nombreuses possibilités à l'entreprise utilisant ce canal :

• envoyer des nouveaux éléments (mandats, notifications ...) à SEPAmail, en utilisant des missives nominales
• se connecter pour gérer les messages reçus (acquittements, modifications de coordonnées bancaires ...), par le biais de missives de service
• dans des versions futures, modifier ses informations ou sa relation avec le système SEPAmail

Dans tous les cas, le Web service n'est prévu que pour fonctionner en mode "pull" : un client doit se connecter au Web service à son initiative pour communiquer.

Utilisation du Web service

Dans un cadre intrabancaire (communication créancier-banque du créancier notamment), l'utilisation de la missive de service sur le Web Service peut se substituer entièrement à la connexion SMTP. Le serveur SEPAmail joue alors le rôle de serveur de messagerie pour ses clients, ce qui n'est pas son rôle fondamental.

Dans ce cadre, il est donc de la pleine et entière responsabilité de l'entreprise ou du créancier :

• de se connecter à intervalles suffisamment fréquents pour recevoir les nouveaux messages.
• de gérer correctement une éventuelle absence de réponse de la part du serveur (time-out)
• d'exploiter ces messages, étant entendu que SEPAmail n'assure qu'un rôle de stockage et non d'exploitation, sauf pour les données concernant strictement le système SEPAmail (état des mandats dans la base de données interne, par exemple)
• de gérer les messages présents sur le serveur, notamment en supprimant ceux qui ne sont plus utiles. Ceci a pour but, d'une part de faciliter la gestion des messages restants en réduisant leur nombre, d'autre part de limiter la place occupée sur les serveurs SEPAmail, dont la vocation n'est pas à proprement parler de servir des messages.

Précisons que l'archivage est assuré par SEPAmail de façon interne. Le fait de supprimer un message par le biais du Web service le rend donc inaccessible par ce même canal, mais ne le détruit pas entièrement des données de SEPAmail.

L'échange de fichiers

Principe

Ce troisième canal d'échange est conçu pour être utilisé uniquement sur une interface interne à la banque, notamment parce que les données sont transférées sans être chiffrées. Il est donc avant tout destiné à s'interfacer avec des systèmes d'informations bancaires partageant tout ou partie de l'infrastructure avec celle de SEPAmail. Dans ce canal, les éléments à acheminer sont stockés dans des fichiers, aussi bien en entrée qu'en sortie. Ceci permet donc d'organiser des traitements en batch des données. Les fichiers seront au format XML, conformément au schéma fourni par SEPAmail.

L'en-tête du fichier contient trois éléments, tous obligatoires :

• la date et heure de constitution du fichier.
• l'identification du tiers avec lequel l'échange se déroule. Dans tous les cas, c'est un BIC. Pour un fichier entrant, c'est le BIC de l'émetteur et, pour un fichier sortant, c'est celui du destinataire.
• le nombre de missives contenues dans le fichier.

Si le nombre de missives effectivement présentes après l'en-tête du fichier est différent de celui indiqué dans l'en-tête, une erreur protocolaire sera déclenchée, aucune des missives ne sera traitée, et elles feront toutes l'objet d'un acquittement négatif.

Un fichier non conforme à la norme ou au schéma peut être purement et simplement ignoré : aucun acquittement protocolaire, au niveau fichier, n'existe dans ce canal. Comme pour les autres canaux, l'expéditeur qui ne reçoit pas les missives d'acquittement correspondant à ses missives nominales doit prendre en charge leur renvoi.

Utilisation du canal fichiers

L'organisation du canal fichiers et ses détails précis sont laissés à l'initiative de l'éditeur de solutions SEPAmail, notamment en ce qui concerne :

• les noms des fichiers
• les emplacements où ils se trouvent
• la fréquence de leur intégration et/ou de leur production
• l'obligation ou non de produire un fichier si aucun élément ne doit être transmis.

Exemple de fonctionnement

A titre d'exemple, nous décrivons ici un mode de fonctionnement de ce canal adopté lors de l'une des expérimentations, avec l'une des implémentations de SEPAmail :

Chaque tiers souhaitant utiliser un connecteur fichiers dispose d'un répertoire spécifique pour ses échanges de fichiers. Ce répertoire comportera deux sous-répertoires, l'un pour les fichiers entrants et l'autre pour les fichiers sortants, afin de séparer clairement les deux flux.

Le nom des fichiers sera de la forme <date><heure>_<BIC>.<application>.<direction>.xml

• <date> est la date de création sous la forme aaaammjj
• <heure> est l'heure de création sous la forme HHMM
• <BIC> est le BIC de l'émetteur ou du destinataire, selon les cas
• <application> est l'application associée aux messages contenus dans ce fichier, par exemple gemme, rubis, test ... Elle peut également prendre la valeur ALL si le fichier contient des messages destinés à (ou provenant de) plusieurs applications.
• <direction> peut prendre deux valeurs :
  • in si le fichier est entrant dans SEPAmail, donc produit par un tiers
  • out s'il est produit par SEPAmail, donc à destination d'un tiers.

Un fichier peut contenir un nombre quelconque de missives, y compris 0. Il sera donc composé d'un en-tête, puis d'un nombre quelconque de missives, de type Missive.

Il est recommandé que la date de création figurant dans l'en-tête du fichier corresponde au nom du fichier lui-même, mais ceci n'est pas obligatoire.

Le système SEPAmail vérifiera le contenu du sous-répertoire des fichiers entrants toutes les heures, à 5 minutes après l'heure juste. Il produira ensuite un fichier dans le répertoire des fichiers sortants, contenant toutes les missives disponibles pour ce destinataire à ce moment. Ce fichier sera disponible chaque heure, au plus tard 35 minutes après l'heure juste. Un fichier devra être généré à chaque heure, aussi bien par le système SEPAmail que par le tiers, et ce, même s'il n'y a aucune missive à transmettre.

Chaque partie a la responsabilité de supprimer ou d'archiver les fichiers après traitement.

SEPAmail archivera les fichiers entrants, et le tiers gèrera les fichiers sortants. En tout état de cause, un fichier datant de plus de quatorze jours pourra être purement et simplement supprimé par SEPAmail, afin d'éviter l'engorgement du système.