SMIRK MES1102, le message dans le réseau interbancaire

Introduction et généralités

Le message SEPAmail est l'information élémentaire transmise.

Dans l'espace coopératif interbancaire, il est utilisé pour faire transiter une information standardisée avec un minimum obligatoire et une scalabilité permettant des services dans l'espace compétitif.

Un message appartient à un unique écosystème et il répond toujours aux règles suivantes :

• Il est typé.
• Il est composé d'informations au format XML.
• Il contient de l'information structurée selon son type, définie par un schéma XML.
• Toute information autre que celle servant au bon routage est intégrée dans un message SEPAmail et il n'y a donc aucune information qui transite en dehors d'un message dans le réseau SEPAmail.

Cependant, chaque fois que c'est possible au sein d'une application bancaire, la modélisation des échanges préfère le « Question/Réponse » simple et sobre.

Le message SEPAmail fait le plus souvent partie d'une Application SEPAmail, qui fait l'objet d'un SMIRK séparé.

Les principes

Non confidentialité

Le message n'est pas chiffré. Par contre, il est toujours inclus dans une enveloppe sécurisée (missive).

La confidentialité « technique » de l'intégralité du message échangé n'est donc pas possible, vis-à-vis de la banque s'entend : la banque peut toujours voir les données contenues dans un message.

Elle est « fonctionnelle » par le seul secret bancaire et l'accord de confidentialité du Scheme envers son réseau d'adhérents.

La confidentialité de bout en bout, vis-à-vis des tiers, est toujours garantie.

Intégrité

L'intégrité d'un message est assurée par deux mécanismes facultatifs de la missive l'enveloppant :

• la signature du message, qui assure l'origine mais aussi l'intégrité puisque que la signature est réalisée sur un condensat du message.
• une somme de contrôle sur l'ensemble du message en en-tête de la missive.

Seul le message EnrollRequest peut transiter sans signature, tous les autres doivent impérativement être signés.

Structuration de l'information

Le message SEPAmail répond aux règles suivantes :

• Il est typé (ActivationRequest, MandateAcceptanceReport ...).
• Il est composé d'informations au format XML.
• Il contient de l'information structurée selon son type, définie par un schéma XML.

Nommage du type

Le type d'un message SEPAmail

• a son nom composé de mots clés anglais, à la norme CamelCase
• reprend les normes du SEPA sur le nommage des grandes fonctions : Request, Report, Reply.

Écosystème

Un message fait toujours partie d'un écosystème de messages (ecosystem en anglais).

L'écosystème est une notion ensembliste permettant de regrouper des schémas XML.

L'écosystème est donc différent de l'application SEPAmail.

Complétude de l'information

Toute information autre que celle servant au bon routage est intégrée dans un message SEPAmail.

Il n'y a aucune information métier qui transite en-dehors d'un message dans le réseau SEPAmail.

Plus généralement, il n'y a aucune information qui transite en-dehors d'une missive dans le réseau SEPAmail.

Durée de validité du message

Le message possède une date de péremption, date après laquelle son sens informatif est périmé.

Cette date est définie par une borne absolue (date heure universelle).

Le dépassement de la date n'est pas le déclencheur exclusif de la péremption du message. En effet, un message peut être périmé aussi par d'autres événements tels :

• la réponse au message
• l'apparition d'une clause suspensive
• toute autre cause définie par le contenu du message (se reporter aux IG correspondantes)

Le dialogue « Question/Réponse » au cœur de l'échange SEPAmail

Le message SEPAmail permet essentiellement de faire transiter de l'information entre deux utilisateurs du réseau dans les deux sens, afin de composer un dialogue entre deux utilisateurs indéfiniment connectés.

La plupart des messages sont conçus dans une logique de question/réponse (Request/Report ou Request/Reply).

La messagerie peut s'étendre à plus de deux utilisateurs et permettre d'autres combinaisons que la simple paire de messages Question/Réponse.

Cependant, chaque fois que c'est possible au sein d'une application bancaire, la modélisation des échanges préfère le « Question/Réponse » simple et sobre.

Le contenu

Un message SEPAmail est composé de deux éléments :

• un en-tête (obligatoire),
• un corps (obligatoire).

Le message valide le schéma XML sepamail_message.xml

L'en-tête

L'en-tête est toujours composé des éléments :

• un identifiant de message unique (obligatoire),
• un type de message (obligatoire),
• une référence à un ou plusieurs messages précédents (facultative),
• une date/heure de péremption (faculative),
• une référence de redirection (facultative).

L'identifiant de message doit être unique pour un doublet (émetteur, message) dans le réseau SEPAmail. Il est de la responsabilité de l'émetteur de s'assurer de cette unicité.

Le type de message permet de s'assurer que le message est conforme à un type défini et structuré au sein d'une famille de message. C'est un type parmi une liste définie dans les schémas XML.

La date/heure de péremption a été décrite plus haut dans les principes. Il s'agit d'une date/heure universelle. Elle permet d'assurer, si elle est renseignée, que le sens informatif du message est périmé. Cette notion permet au relais de l'émetteur d'informer l'émetteur de l'éventuelle absence de réponse ou de proposer du service autour de ce jalon. Cela permet aussi au relais du destinataire d'archiver le message si besoin, et de ne pas conserver indéfiniment un message dans la queue des messages mis à disposition du destinataire.

La référence de redirection permet de rediriger le message vers ses lecteurs finaux dans le système destinataire si besoin (numéro de téléphone, poste, personne, URL etc...)

Le corps

Le corps du message dépend du type de message.

Il existe un schéma XML pour chaque type de message

Les pièces jointes (incluses dans le corps du message)

Dans SEPAmail, il y a un élément « data » qui est utilisé dans trois éléments parents :

• une image (élément « Image »),
• une pièce jointe au sens MIME (élément « Attachment »),
• une signature (élément « Signature »).

L'image est utilisée chaque fois que l'élément doit pouvoir être affiché en ligne dans une interface homme/machine.

La pièce jointe est plutôt utilisée lorsque l'élément doit pouvoir être téléchargé dans les interfaces homme/machine.

Remarque : le RIS2D et le Document utilisent la pièce jointe « Attachment », ce qui est logique car le RIS2D doit pouvoir se télécharger.