La vision métier

L'émetteur et le destinataire

Du point de vue technique, il y a bien un émetteur de l'envoi et un destinataire. Du point de vue métier, l'envoi est surtout important pour sa réponse. De ce fait, l'émetteur de l'envoi devient le destinataire de la réponse.

Dans les premiers services envisagés, il sera donc toujours préféré l'utilisation des identifiants métiers : créancier, débiteur, donneur d'ordre, bénéficiaire.

Néanmois pour une présentation générale, nous utiliserons les expressions « émetteur initial » et « destinataire initial » en lieu et place des expressions « émetteur » et « destinataire » ayant un double sens.

Les échanges métiers se structurent donc suivant le schéma précédent :

• une initialisation d'un envoi réalisée par l'émetteur initial
• la transmission de l'envoi vers la banque du destinataire. Dans la structure SEPAmail, cette transmission est nommée REQUEST (payment-request, mandate-request,...)
• la mise à disposition par la banque du destinataire, suivant le ou les canaux proposés par cette banque
• la validation par le destinataire initial. Au même titre que pour l'initialisation, les règles d'authentification peuvent être adaptées au service sous-jacent.
• Une fois la validation effectuée et contrôlée, la réponse est nommée REPORT (mandate-report, payment-report,...)

Principes d’acquittement

Pour assurer le bon fonctionnement de la messagerie à un niveau métier, chaque envoi interbancaire (missive nominale) doit faire l'objet par la banque du destinataire d'une missive d'acquittement. Celle-ci peut comporter des éléments sur le niveau de service mais doit éviter les données métiers. Ces dernières sont censées faire l'objet d'une missive nominale transportant un message de type REPORT.

La missive d’acquittement n'est pas acquittée.

Il n'y a aucune obligation que la missive d'acquittement passe par le même canal d'échange que la missive nominale. En particulier, il est tout à fait possible d'utiliser uniquement le canal SMTP pour toutes les missives d'acquittement.

Principes de desserte (reachability)

SEPAmail étant une initiative privée, il n'est pas envisageable que tous les acteurs adhérents démarrent le même jour, et ceci à chaque nouvelle application ou nouvelle évolution.

De ce constat, il est important que la banque de l'émetteur gère la desserte à 2 niveaux :

• niveau global par information qu'un réseau bancaire destinataire a ouvert le service (information qui sera organisée au niveau de la structure de gouvernance)
• niveau transaction en mettant à disposition une réponse intermédiaire (puce 2) indiquant si la banque est desservie.

La banque de l'émetteur peut profiter de cette gestion de la desserte pour offrir un service complémentaire. Dans le cadre de l'expérimentation GEMME, le service consiste à :

• recevoir l'ensemble des flux de mandats,
• répondre suivant que le mandat est transmis ou non (banque non desservie)
• stocker les mandats non desservis
• automatiser l'envoi ultérieur de ces stocks chaque fois qu'une nouvelle banque rejoindra le réseau SEPAmail

Il est évident qu'un tel service n'est pas très utile dans le cas de RUBIS dont les demandes de règlement ont une période d'utilisation réduite.