Outils personnels

SMIRK MIS1202, la missive dans les échanges interbancaires

De documentation SEPAmail.

(Redirigé depuis Standards 1206:SMIRK MIS1202)
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.


Introduction et généralités

La missive est la seule entité permettant l'échange d'informations dans le système SEPAmailmessagerie bancaire sécurisée., où elle joue un rôle d'enveloppe pour les données confidentielles. Pour pouvoir acheminer efficacement les différentes informations du système, quatre types de missives ont été définis :

  • la missive nominale, acheminant un message
  • la missive d'acquittement, à but essentiellement protocolaire

ainsi que :

  • la missive de service, permettant un dialogue de nature « commande - réponse » entre deux systèmes, réservée à l'espace compétitif hors réseau des adhérents SEPAmailmessagerie bancaire sécurisée., donc non utilisé dans les échanges entre les adhérents du réseau SEPAmailmessagerie bancaire sécurisée.
  • la missive SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. (SEPAmailmessagerie bancaire sécurisée. API), accessible exclusivement en intrabancaire, et permettant à un éditeur SEPAmailmessagerie bancaire sécurisée. de fournir un accès direct à certains éléments de sa plateforme.

La missive SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. est en bordure de la norme SEPAmailmessagerie bancaire sécurisée. : son existence fait partie de la norme, mais le contenu exact des messages SMAPISepaMail Application Programming Interface, missive permettant à un éditeur SEPAmail de proposer des fonctions non SEPAmail, notamment d'administration. est laissé à la discrétion des éditeurs.

SEPAmailmessagerie bancaire sécurisée. se sert de la missive pour :

  • l'adressage de l'information (qui est 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., qui est l'émetteur)
  • le routage de l'information (comment j'achemine l'information)
  • la réception de l'information (l'information est-elle arrivée)
  • l'intégrité de l'information (est-ce la bonne information)
  • l'authentification des parties (l'émetteur 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. sont-ils ceux qu'ils prétendent être)
  • l'horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) de l'information (quand l'information est-elle émise et reçue)

Les principes

La missive est un flux XML respectant le schéma sepamail_missive[1], qui fait partie des spécifications du système. Cet élément sert à transporter toutes sortes de messages ou autres contenus. Elle joue le rôle d'enveloppe et peut être acheminée par divers moyens.

La missive peut être de deux types :

  • une missive nominale, enveloppe pour toute forme de contenu (mais en particulier pour un message Sepamail),
  • une missive d'acquittement, qui permet d'accuser réception d'une missive nominale.

Remarque : La missive de service est une notion à ne pas utiliser dans l'espace interbancaire. Elle ne fait donc pas partie de ce SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail.. Un lexique des termes utilisés se trouve sur la documentation de la communauté SEPAmail[2].

Le routage

Le routage se sert d'un adressage de type « courriel » sur le domaine sepamail.eu[3] de la forme :

   <ecosystem>@<bic>.sepamail.eu

ou

   <ecosystem>@<xx.scheme>.sepamail.eu

où :

  • <ecosystem> est une famille SEPAmailmessagerie bancaire sécurisée. valide du référentiel ecosystem@scheme
  • <bic> est un BICBank Identifier Code, norme ISO 9362:1994 valide du référentiel bic@scheme
  • <xx.scheme> représente un nœud du réseau appartenant au scheme et administré par lui (xx est facultatif, c'est un code représentant le gestionnaire au sein du scheme, par exemple fr.scheme pour le QXOOBureau local opérationnel du SCHEME (QX Operational Office) français.[4])

Le routage est réalisé par les adhérents SEPAmailmessagerie bancaire sécurisée. et au sein du scheme à l'aide d'automates qui implémentent les règles de routage suivantes :

Règles de routage à la réception

  • Un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). n'accepte des missives que pour les BICs qu'il représente. Un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). ne fait donc pas de relais pour un autre adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs)..
  • Un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). n'accepte des missives qu'en provenance d'un BICBank Identifier Code, norme ISO 9362:1994 lié à un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmail. Le réseau SEPAmailmessagerie bancaire sécurisée. est donc un réseau réservé à ses seuls adhérents et fermé au reste du monde.

Règles de routage à l'émission

  • Un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). n'envoie des flux au sein du réseau SEPAmailmessagerie bancaire sécurisée. qu'à un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. pour un BICBank Identifier Code, norme ISO 9362:1994 déclaré et valide du référentiel bic@scheme.

L'acquittement d'une missive

L'acquittement vise à informer l'émetteur de la réception, bonne ou mauvaise, de la missive émise et d'un horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) de cette réception.

C'est l'émetteur qui pilote l'envoi d'information et non 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.. L'acquittement est obligatoire et systématique, il ne dépend pas de l'historique de la séquence.

La classe de l'acquittement ne dépend que des contrôles implémentés par 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.. On trouve les codes retour dans une directive d'implémentation spécifique.

L'acquittement se fait selon les règles suivantes :

  • seules les missives nominales sont acquittées
  • toute missive nominale reçue (quelque soit son ordre) doit être acquittée.
  • l'acquittement doit être mis en œuvre selon la priorité et en respectant les délais maximaux de la priorité.

Le séquencement

La séquence naturelle d'un échange de missives est :

séquencement des missives

  • un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). A émet une missive nominale destinée à un adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). B depuis un système source de la missive
  • l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). B reçoit la missive nominale provenant de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). A dans un système cible de la missive
  • l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). B émet une ou plusieurs missives d'acquittement destinée à l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). A en réponse à la missive nominale
  • l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). A reçoit la ou les missives d’acquittement

Nous donnons ci-dessous les règles à implémenter sur le séquencement :

  • 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. de toute missive nominale reçue doit mettre en œuvre l'acquittement de cette missive nominale par au moins une missive d'acquittement
  • aucune missive de type autre que « nominale » ou « acquittement » n'est émise
  • aucune missive de type autre que « nominale » n'est acquittée
  • aucune missive de type « acquittement » n'est émise sans avoir reçu au préalable une missive de type « nominale »

Renvoi d'une missive

Un système de renvoi d'une missive peut être implémenté.

Il fonctionne ainsi :

  • il n'est mis en œuvre qu'avec les missives nominales,
  • la missive est renvoyée avec un ordre incrémenté de 1 ; l'émetteur s'interdit de changer le contenu de la missive renvoyée, à l'exception du numéro d'ordre
  • la signature S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels de l'émetteur est donc différente.

Dans le cas où une missive nominale n'est pas acquittée après un certain temps, les règles suivantes sont implémentées :

  • l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans un temps supérieur aux minima définis pour la priorité de la missive peut renvoyer la missive avec un numéro d'ordre incrémenté ; il s'interdit de le faire avant ; il n'est pas obligé de le faire
  • le renvoi d'une missive ne peut pas intervenir plus d'un certain temps, précisé dans le tableau ci-après, après l'émission de la missive précédente
  • l'émetteur de toute missive nominale dont l'acquittement n'est pas constaté dans le laps de temps maximal autorisé pour la priorité de la missive et qui a renvoyé au moins une fois la missive peut alors mettre en œuvre le procédé d'escalade prévu ; il s'interdit de le faire avant ; il n'est pas obligé de le faire.

Le système d'incrément de l'ordre des missives nominales n'est pas destiné à permettre d'envoyer plusieurs fois une même missive pour obtenir des acquittements différents. Ce système n'est utilisé que pour obtenir un acquittement si celui-ci n'est pas arrivé.

On a donc les règles suivantes :

  • un système de réception et de contrôle des acquittements doit être mis en place,
  • le renvoi d'une missive n'est pas possible si elle est déjà acquittée sauf si la classe d'acquittement est 4 (erreur transitoire).
Temps d'attente avant renvoi selon la priorité de la missive
Priorité Délai maximal acquittement Délai minimal avant renvoi Délai maximal avant renvoi Nombre maximal de renvois
1 la plus haute 20 sec 30 sec 1 min 3
2 haute 3 min 5 min 10 min 5
3 normale 4 h 4 h 8 h 4
4 basse 12 h 12 h 24 h 3
5 la plus basse 48 h 48 h 96 h 3

Les délais de renvoi sont remis à zéro à chaque renvoi de la missive. Ainsi, si une missive de priorité "haute" est envoyée à l'instant T pour la première fois (ordre 1), celle d'ordre 2 pourra être envoyée entre T+5mn et T+10mn. Si elle est envoyée à T+7mn, la missive d'ordre 3 (toujours en l'absence d'acquittement évidemment) pourra être envoyée entre T+12mn et T+17mn, et ainsi de suite.

Le délai maximal d'acquittement, le délai minimal avant renvoi et le nombre maximal de renvois indiqué ici sont des valeurs par défaut. Si deux adhérents concluent un accord bilatéral, ils peuvent librement convenir de délais différents et/ou d'un plus grand nombre de renvois.


Temps d'attente avant escalade selon la priorité de la missive
Priorité Délai minimal avant escalade
1 la plus haute 10 min
2 haute 30 min
3 normale 16 h
4 basse 36 h
5 la plus basse 120 h

Rappel : ce délai est calculé à partir de l'émission de la première missive (ordre 1), il n'est pas remis à zéro à chaque rémission, contrairement aux délais de renvoi ci-dessus.

Le procédé d'escalade

Dans le cas où une missive ne serait pas acquittée, même après un renvoi, l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). peut procéder à l'escalade prévue par le scheme dès qu'un délai minimal est passé après le dernier renvoi (voir tableau ci-dessus).

Cette escalade est spécifiée par le Scheme dans un SMIRK spécifique.

Le contenu

Selon les règles métier de SEPAmailmessagerie bancaire sécurisée., une missive contient obligatoirement :

Contenu facultatif et obligatoire d'une missive

  • un identifiant unique,
  • un type,
  • un ordre de présentation,
  • un en-tête,

et selon le type de missive :

  • un acquittement pour une missive de type acquittement,
  • un message SEPAmailmessagerie bancaire sécurisée. pour une missive de type nominal,

et facultativement :

  • une signature du message, à ne pas confondre avec le cachet électronique apposé à la missive au sein de l'enveloppe S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels. Cette signature sert essentiellement à pouvoir adjoindre une signature électronique du signataire, client de la banque et émetteur du message.

Il faut noter que, du strict point de vue de la conformité au schéma XML, les blocs message et acquittement sont facultatifs (cf. schéma ci-contre).

L'en-tête de la missive respecte trois principes :

  • le principe de symétrie entre 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. et l'émetteur du message, car l'un et l'autre peuvent avoir les deux fonctions
  • le principe de priorité, qui permet à chaque entité de gérer l'affluence en priorisant les flux
  • le principe d'intégrité des informations générées par les automates qui est assuré par des sommes de contrôle sur le contenu dont on veut vérifier l'intégrité

L'enveloppe

La missive est encapsulée dans une enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)-S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels. Cette enveloppe contient :

  • des entêtes:
    • FROM, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>
    • TO, adresse de courriel comme spécifié dans ce document, valide avec un nom de domaine déclaré au niveau des DNSDomain Name System, service permettant d'établir une correspondance entre une adresse IP et un nom de domaine<ref name="dns">http://fr.wikipedia.org/wiki/Domain_Name_System</ref>
    • X-priority, priorité selon la spécification de ce document
    • SUBJECT vide par défaut, sans information signifiante sur le contenu du message
  • un corps reprenant deux parties
    • la missive, chiffrée avec la clé privée du certificat S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels liée à l'adresse FROM
    • une signature S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, obligatoire

Remarque : la missive doit être chiffrée dans tous les cas, même dans le cas d'un parcours flash (webservice sur couche HTTPS), afin de permettre une non adhérence des couches applicatives de production de l'enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») et de son transport.

La sécurité : authentification, confidentialité et horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti)

La sécurité est assurée à plusieurs niveaux :

  • l'authentification des deux parties
  • la confidentialité de l'information transmise
  • l'horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) des opérations d'émission et de réception des missives

SEPAmailmessagerie bancaire sécurisée. utilise des procédés de cryptographie asymétrique.

Les adhérents disposent de façon certaine et sécurisée des clés publiques de chaque adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs)..

L'authentification de l'émetteur (adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée.) est alors assurée par une signature du condensat du contenu intégral de la missive avec la clé privée de l'émetteur. 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. pourra alors vérifier que le condensat de la missive qu'il a généré est le même que celui de la signature qu'il a déchiffré.

La confidentialité est assurée par le chiffrement de la missive par l'émetteur avec la clé publique 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.. Ainsi, seul 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. pourra déchiffrer le flux avec sa clé privée.

La missive est horodatée en émission et en réception par une marque de temps de type date/heure. Les principes détaillés d'horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) applicables à SEPAmailmessagerie bancaire sécurisée., inspirés des bonnes pratiques de la FNTC [5], sont décrits dans cette page.

Si un horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) de type « contremarque de temps signée » est nécessaire, alors cet horodatagel'horodatage est une donnée métier importante de SEPAmail ; il s'agit d'une date/heure. L'ensemble des mécanismes de SEPAmail horodatant doivent être synchronisés fréquemment sur une source de temps via le protocole NTP (le protocole sécurisé S/TIME n'a pas encore abouti) est réalisé sur l'enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») (et non seulement la missive) par un service tiers certifié, juste avant l'émission ou juste après la réception.

Le protocole d'échange des missives

la place des protocoles d'échange dans l'architecture protocolaire

L'échange des missives se fait nativement sur le réseau IP via la couche de transport TCP.

Sur ces couches, SEPAmailmessagerie bancaire sécurisée. implémente deux parcours avec deux protocoles de communication différents :

  • SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)
  • HTTPS+SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML


Remarque : Cet échange fait l'objet de recommandations d'implémentation et sort du cadre normatif de ce document.

Remarque : Une étude est en cours pour permettre un parcours flash sur la base de HTTPHyperText Transfer Protocol+RESTREpresentational State Transfer, architecture distribuée simple, n'utilisant pas d'états<ref>http://fr.wikipedia.org/wiki/REST</ref>

La qualité de service

La qualité du service est soumise à un cadre faisant l'objet d'un document séparé [6].

Fonctionnement

Voici les schémas fonctionnels de la réception et de l'émission d'une missive, à réaliser par les automates des adhérents bancaires.

Les actions sur les données à effectuer sont en bleu, les tests en vert.

Les opérations se succèdent selon une série temporelle représentée de haut en bas.


Réception d'une missive nominale

la séquence fonctionnelle autour de la réception de missive

Réception enveloppe SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels

Le récepteur de missive réceptionne des enveloppes au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels, quelque soit le canal d'entrée de cette enveloppe (SOAPancien acronyme de Simple Object Access Protocol, c'est un protocole de RPC orienté objet bâti sur XML ou SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier »)).

Vérification de l'intégrité S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels

Il faut vérifier que l'enveloppe reçue est bien au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels.

Il doit y avoir également :

  • le champ FROM renseigné
  • le champ TO renseigné
  • une partie chiffrée ou non
  • une signature au format S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels

Remarque : le sujet SMTPSimple Mail Transfer Protocol (littéralement « Protocole simple de transfert de courrier ») peut être absent ou vide.

Extraction de l'en-tête MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels et des deux parties

On extrait l'adresse FROM, l'adresse TO et les deux parties jointes à l'enveloppe, normalement le contenu XML de la missive et une signature de ce contenu.

Vérification des BICBank Identifier Code, norme ISO 9362:1994

Il faut extraire les sous-domaines des adresses FROM et TO.

Ces deux sous-domaines doivent être ceux d'un BICBank Identifier Code, norme ISO 9362:1994 appartenant à bic@scheme.

Celui correspondant au 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. (TO) doit également être l'un des BICs rattachés à l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). 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 référentiel member@scheme.

Vérification de l'écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail.

L'écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. fourni par l'adresse de courriel doit être un ensemble de messages géré par le réseau SEPAmailmessagerie bancaire sécurisée., appartenant à ecosystem@scheme.

Déchiffrement

La première partie de l'enveloppe MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels est chiffrée (Content-Type: multipart/encrypted), et doit donc être déchiffrée avec la clé privée 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. (BICBank Identifier Code, norme ISO 9362:1994 extrait de l'adresse TO (protocole défini par l'attribut protocol de l'en-tête Content-Type). La chaîne ainsi déchiffrée est considérée comme la missive à vérifier.

Calcul du condensat de la missive

Un condensat du contenu de la missive est calculé selon la méthode déclarée dans les propriétés S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels (attribut micalg de l'en-tête Content-Type).

Vérification de la signature S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). émetteur

La signature de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. émetteur est vérifiée en comparant le condensat calculé précédemment avec le résultat du déchiffrement de la signature.

Vérification de la conformité du XML

La missive est un document XML dont on vérifie qu'il est bien formé (la syntaxe est correcte)[7].

Vérification de la validité du XML

La missive est un document XML dont on vérifie :

  • qu'il contient une référence à l'espace de nom SEPAmailmessagerie bancaire sécurisée.,
  • qu'il est valide (il valide le schéma XML qu'il référence).

Extraction en-tête

On extrait l'en-tête de la missive afin de permettre les vérifications suivantes.

Horodatage

La missive est horodatée en réception, ce qui consiste à enrichir le contenu XML en renseignant le champ « RcvDtTm » de l'en-tête de la missive avec la date et heure du système.

Vérification champ Rcv

Le champ Rcv contient au moins :

  • un identifiant d'un utilisateurun utilisateur de SEPAmail est un client d'un adhérent à SEPAmail, qui utilise les services proposés. Ce peut être indifféremment un débiteur ou un créancier (ou les deux), et indifféremment une personne physique ou morale. SEPAmailmessagerie bancaire sécurisée. (généralement un identifiant bancaire IBANInternational Bank Account Number, norme ISO 13616:2003, PANacronyme de Primary Account Number ou numéro de carte bancaire, QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code). ...),
  • un identifiant de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. (BICBank Identifier Code, norme ISO 9362:1994 ou code entité SCHEME)

Cet identifiant doit correspondre à un utilisateurun utilisateur de SEPAmail est un client d'un adhérent à SEPAmail, qui utilise les services proposés. Ce peut être indifféremment un débiteur ou un créancier (ou les deux), et indifféremment une personne physique ou morale. valide pour le service SEPAmail.

Il doit donc représenter un utilisateurun utilisateur de SEPAmail est un client d'un adhérent à SEPAmail, qui utilise les services proposés. Ce peut être indifféremment un débiteur ou un créancier (ou les deux), et indifféremment une personne physique ou morale. actif dans l'un des référentiels d'identifiants gérés par l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). 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. de la missive : QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).@BICBank Identifier Code, norme ISO 9362:1994, IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994, PANacronyme de Primary Account Number ou numéro de carte bancaire@BICBank Identifier Code, norme ISO 9362:1994.

Acquittement

L'acquittement fait l'objet d'une émission de missive avec des règles qui ont été définies plus haut.

Routage interne de la missive

La missive est routée vers 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 bancaire ou le dispositif technique lié à l'écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. SEPAmailmessagerie bancaire sécurisée. concerné.

Réception d'une missive d'acquittement

L'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. n'est pas tenu dans l'absolu d'effectuer un traitement en réception de l'acquittement, sauf

  • pour obtenir les statistiques demandées par le Schemele Scheme, ou Scheme SEPAmail, est l'entité au sein de laquelle les adhérents SEPAmail sont regroupés et qui a pour mission de maintenir la norme SEPAmail et les référentiels.
  • pour se conformer aux obligations de la Charte de l'adhérent

S'il souhaite traiter ces missives, il devra implémenter la même procédure que celle utilisée pour la réception d’une missive nominale, à la différence qu’une missive d’acquittement n’est pas elle-même acquittée.

Remarque : dans le cas d'erreurs au sein de la missive d'acquittement lors des vérifications (XML non conforme ou valide, en-têtes non valides), on ne peut donc pas signaler ces erreurs. Le mécanisme de renvoi de la missive nominale ou le procédé d'escalade doivent alors être utilisés, pour ne pas faire boucler le système.

Vérification antécédent missive d'acquittement

A ce stade, on peut vérifier si la missive d'acquittement possède déjà un antécédent :

  • en réception : existe-t-il d'autres acquittements sur la même missive nominale ?
  • en émission : existe-t-il une missive nominale ?

Routage interne de la missive vers le SI

La missive est routée vers 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 bancaire ou le dispositif technique lié à l'écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. SEPAmailmessagerie bancaire sécurisée. si lalogique du SI bancaire le nécessite.

Émission d'une missive nominale

la séquence fonctionnelle autour de l'émission de missive

Récupération ordre émission/information

Une missive nominale est émise sur ordre d'émission d'une 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 bancaire.

La missive peut être récupérée telle quelle, auquel cas elle est vérifiée avant signature/chiffrement et envoi.

La missive peut être construite par l'automate.

Dans les deux cas, les vérifications suivantes sont réalisées.

Vérification des BICBank Identifier Code, norme ISO 9362:1994

Il faut extraire les BICBank Identifier Code, norme ISO 9362:1994 des informations transmises ou les déduire d'un référentiel IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994. Les deux BICBank Identifier Code, norme ISO 9362:1994 doivent appartenir à member@scheme ou être SCHEME.

Celui correspondant à 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. (FROM) doit également être un BICBank Identifier Code, norme ISO 9362:1994 possédé par l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs)..

Vérification de l'ecosystème

L'écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. peut-être déduit du message contenu dans la missive ou transmis 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 bancaire (souhaitable). Ce doit être un écosystèmeanciennement appelé famille, l'écosystème SEPAmail est un ensemble de messages transportant des informations métier, regroupés de façon logique. De façon générale, un Écosystème correspond à une Application SEPAmail. géré par le réseau SEPAmailmessagerie bancaire sécurisée., appartenant à ecosystem@scheme.

Vérification MsvSnd

Le champ MsvSnd contient un identifiant (IBANInternational Bank Account Number, norme ISO 13616:2003, QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code)., PANacronyme de Primary Account Number ou numéro de carte bancaire, ICQXidentifiant unique d'un créancier dans le réseau SEPAmail. Cet identifiant est géré par le SCHEME. Il est unique pour une entité économique et pérenne./BICBank Identifier Code, norme ISO 9362:1994, BICBank Identifier Code, norme ISO 9362:1994)

Cet identifiant doit correspondre à un utilisateurun utilisateur de SEPAmail est un client d'un adhérent à SEPAmail, qui utilise les services proposés. Ce peut être indifféremment un débiteur ou un créancier (ou les deux), et indifféremment une personne physique ou morale. valide pour le service SEPAmail.

Il doit donc être actif dans l'un des référentiels d'identifiants gérés par l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). émetteur de la missive : QXBANle QXBAN est une instance alias de l'IBAN (International Bank Account Number) interne au système SEPAmail. Il est créé pour un BIC à l'aide d'un algorithme spécifié par le Scheme, en conformité avec la définition et les règles génériques de création d'un IBAN pour un code pays « QX » (pas de pays avec ce code).@BICBank Identifier Code, norme ISO 9362:1994, IBANInternational Bank Account Number, norme ISO 13616:2003@BICBank Identifier Code, norme ISO 9362:1994, PANacronyme de Primary Account Number ou numéro de carte bancaire@BICBank Identifier Code, norme ISO 9362:1994.

Vérification de la conformité du XML du message

Le message à envelopper dans la missive est un document XML dont on vérifie la conformité.

Vérification de la validité du XML du message

Le message est un document XML dont on vérifie :

  • qu'il contient une référence à un schéma XML de la famille de 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 demandée,
  • qu'il est valide.

Construction de la missive

On construit la missive à partir du message et des informations précédemment vérifiées ou, dans le cas d'une transmission initiale de missive, par un enrichissement de cette missive.

Horodatage

La missive est horodatée en émission, ce qui consiste à enrichir le contenu XML en renseignant le champ « SndDtTm » de l'en-tête de la missive avec la date et heure du système.

Vérification de la conformité du XML de la missive

La missive construite à l'étape précédente est un document XML dont on vérifie la conformité.

Vérification de la validité du XML de la missive

La missive est un document XML dont on vérifie :

  • qu'il contient une référence au schéma XML sepamail_missive[8]
  • qu'il est valide.

calcul du condensat de la missive

Un condensat de la missive est calculé selon une méthode valide qui est déclarée dans les propriétés S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels (attribut micalg de l'en-tête Content-Type).

signature S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). émetteur

La signature du condensat créé précédemment est réalisée à partir à l'aide de la clé privée de l'adhérentun adhérent à SEPAmail est nécessairement connu et identifié auprès du scheme. Ce sera généralement un prestataire de services de paiement. Il émet et reçoit des missives conformément à la norme SEPAmail, en particulier il assure la sécurité et l'authentification des clients finals (utilisateurs). SEPAmailmessagerie bancaire sécurisée. émetteur, dédiée à l'envoi de missives.

Chiffrement

Le chiffrement de la missive est réalisé à l'aide de 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..

Constitution de l'enveloppe MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels

Une enveloppe MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels est constituée. Elle contient :

  • le champ FROM,
  • le champ TO,
  • une première partie contenant la missive éventuellement chiffrée,
  • une seconde partie contenant la signature S/MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels de la missive.

Remarque: les pièces jointes éventuelles du message sont jointes au message et donc incluses dans le XML comme du binaire. Le mécanisme MIMEMultipurpose Internet Mail Extensions est un standard internet qui étend le format de données des courriels des pièces jointes n'est donc pas utilisé pour celles-ci, mais seulement pour la missive ET la signature.

Envoi selon priorité

La priorité de la missive est reprise pour le transport

Émission d'une missive d'acquittement

Le cas d'une missive d'acquittement est similaire. Seul le message est remplacé par la structure d'acquittement, contenant le code d'acquittement.

Références

  1. http://xsd.sepamail.eu/1206/sepamail_missive.xsd
  2. Permalien http://documentation.sepamail.eu/wiki/Lexique
  3. Le nom de domaine sepamail.eu est géré par le scheme SEPAmailmessagerie bancaire sécurisée.
  4. Pour une compréhension de l'organisation du scheme, consulter le SMIRKacronyme SEPAmail SepaMail Internal Request for Komment, équivalent d'un RFC pour SEPAmail. sur son organisation SMIRK ORG1110
  5. Guide des bonnes pratiques en matière de datation d’événements ou d'objets électroniques, http://www.fntc.org/, section guide (utilisateurs enregistrés)
  6. SMIRK escalade ESC1108
  7. Voir la définition du W3C que l'on retrouve [1]
  8. http://xsd.sepamail.eu/1206/sepamail_missive.xsd
Autres langues :English 99% • ‎Français 100%