Outils personnels

Les mécanismes d'échange

De documentation SEPAmail.

Cette page contient des modifications qui ne sont pas marquées pour la traduction.

SEPAmail – Norme 1206

Cette page fait partie de la version 1206 de la norme.

Sauf indication contraire, elle a été validée par les instances concernées et s'impose à tous les adhérents SEPAmail.
ATTENTION ! La version 1606 de la norme est disponible, vérifiez si cette page est toujours valable.

La messagerie

Présentation et principes

Les missives

Les messages

Les applications


Précisions sur les échanges

Dans son acceptation initiale, SEPAmailmessagerie bancaire sécurisée. 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 SEPAmailmessagerie bancaire sécurisée., soit la structure SEPAmailmessagerie bancaire sécurisée. (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 à SEPAmailmessagerie bancaire sécurisée. 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, SEPAmailmessagerie bancaire sécurisée. 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 SEPAmailmessagerie bancaire sécurisée. 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[1], le corps du mail étant obligatoirement une missive SEPAmailmessagerie bancaire sécurisée., apparaissant comme un attachement au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels (RFC 5321[2]).

L'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. et le destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement. 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'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail GEMMEGlobal European Mandate Management & Exchange (Application SEPAmail)
  • payment.activation, qui permet la création de virements de proximité, et est utilisé par l'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail RUBISRèglement Universel Bancaire Immédiat & SEPA (application SEPAmail)
  • identification.verification, pour la vérification d'identifiants bancaires, en rapport avec l'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail DIAMONDApplication SEPAmail permettant la vérification d'un IBAN et des données associées, acronyme de Direct Identity control for Account Management ON Demand
  • secure, qui permet l'échange d'éléments de sécurité (certificats ou messages) entre tous les intervenants du système SEPAmailmessagerie bancaire sécurisée.
  • test, destiné comme son nom l'indique à des tests de configuration et/ou de communication


<bic> est le BICBank Identifier Code, norme ISO 9362:1994 de l'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. (ou du destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement.). Dans le cas d'un échange interbancaire, les deux adresses doivent présenter ce BICBank Identifier Code, norme ISO 9362:1994. Dans le cas d'un échange entre client et banque, l'adresse de l'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. peut comporter un IBANInternational Bank Account Number, norme ISO 13616:2003 au lieu du BICBank Identifier Code, norme ISO 9362:1994.

Les messages doivent être d'abord signés en utilisant la clé privée de signature de l'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement., puis chiffrés en utilisant la clé publique de chiffrement du destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement..

Les adresses IP des serveurs de mail doivent être déposées au préalable auprès du Scheme SEPAmailmessagerie bancaire sécurisée., 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éditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. 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 MTAacronyme de Mail Transfer Agent, logiciel pour serveur de transmission de courrier électronique, et l'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. doit prendre en charge la réexpédition éventuelle dans ce cas.

constitution de l'enveloppe SEPAmail échangée dans le cas du courrier électronique ou du service WEB

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/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, contenant une missive SEPAmailmessagerie bancaire sécurisée., signée puis chiffrée.

Dans l'en-tête comme dans la missive, l'identifiant de l'expéditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. peut être une adresse mail quelconque, gérée par le créancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail., mais doit correspondre précisément au certificat utilisé pour chiffrer la missive. À défaut, la transmission sera rejetée. Le destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement., lui, est de la même forme que pour le canal mail : <ecosystem>@BICBank Identifier Code, norme ISO 9362:1994.sepamail.eu où le BICBank Identifier Code, norme ISO 9362:1994 est celui de la banque du créancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail..

La connexion avec le Web service se fait au travers du protocole HTTPHyperText Transfer Protocol ou HTTPS. Les données binaires sont encodées au travers du protocole MTOMacronyme de Message Transmission Optimization Mechanism du W3C, est une méthode d'envoi de données binaires par services Web. 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éditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement., d'autre part chiffrés en utilisant la clé publique de chiffrement du destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement.. 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 ...) à SEPAmailmessagerie bancaire sécurisée., 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 SEPAmailmessagerie bancaire sécurisée.

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éancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail.-banque du créancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail. notamment), l'utilisation de la missive de service sur le Web Service peut se substituer entièrement à la connexion SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »). Le serveur SEPAmailmessagerie bancaire sécurisée. 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éancierle créancier est une entité économique (secteur privé, associatif ou institutionnel), soit disposant d'un ICS au niveau SEPA, soit inscrit comme créancier SEPAmail. :

  • 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 SEPAmailmessagerie bancaire sécurisée. n'assure qu'un rôle de stockage et non d'exploitation, sauf pour les données concernant strictement le système SEPAmailmessagerie bancaire sécurisée. (é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 SEPAmailmessagerie bancaire sécurisée., dont la vocation n'est pas à proprement parler de servir des messages.

Précisons que l'archivage est assuré par SEPAmailmessagerie bancaire sécurisée. 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.

Le mécanisme d'échange

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 BICBank Identifier Code, norme ISO 9362:1994. Pour un fichier entrant, c'est le BICBank Identifier Code, norme ISO 9362:1994 de l'émetteur et, pour un fichier sortant, c'est celui du destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement..
  • 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éditeurc'est le client final qui émet les données vers un destinataire final. Il est associé au créancier dans le cadre de GEMME et de RUBIS (celui qui veut recevoir les fonds) et aussi au bénéficiaire dans le cadre de RUBIS en tant que bénéficaire du virement. 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 SEPAmailmessagerie bancaire sécurisée., 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 SEPAmailmessagerie bancaire sécurisée. :

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>_<BICBank Identifier Code, norme ISO 9362:1994>.<applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail>.<direction>.xml

  • <date> est la date de création sous la forme aaaammjj
  • <heure> est l'heure de création sous la forme HHMM
  • <BICBank Identifier Code, norme ISO 9362:1994> est le BICBank Identifier Code, norme ISO 9362:1994 de l'émetteur ou du destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement., selon les cas
  • <applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail> est l'applicationune application SEPAmail est liée à un service bancaire proposé. Elle peut se définir comme une séquence de messages utilisant le dispositif technique SEPAmail 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 SEPAmailmessagerie bancaire sécurisée., donc produit par un tiers
    • out s'il est produit par SEPAmailmessagerie bancaire sécurisée., 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 SEPAmailmessagerie bancaire sécurisée. 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 destinatairele destinataire est le client final (client d'un adhérent) qui reçoit les informations de l'expéditeur. Il est associé au débiteur dans le cadre de GEMME et de RUBIS car son compte va être débiteur. Il peut aussi être associé au donneur d'ordre dans le cadre de RUBIS car c'est le donneur d'ordre du virement de règlement. à 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 SEPAmailmessagerie bancaire sécurisée. 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.

SEPAmailmessagerie bancaire sécurisée. 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 SEPAmailmessagerie bancaire sécurisée., afin d'éviter l'engorgement du système.

le lien entre les enveloppes, les missives et les messages

Références

  1. http://www.ietf.org/rfc/rfc3851.txt
  2. http://www.ietf.org/rfc/rfc5321.txt
Autres langues :English 100% • ‎Français 100%