Dans cet article, nous poursuivons notre étude du virement SEPA instantané avec l’analyse des messages échangés pour l’exécution du transfert. Il s’agit des messages présentés dans les rulebooks et décrits les Implementations Guidelines (Guides d’implémentation) disponibles sur le site de l’EPC. Notez que de nombreux autres messages peuvent être échangés tant que le cadre du SEPA reste appliqué et que les différentes parties ont convenu de le faire.
Il existe deux documents pour les guides d’implémentations su SCT Inst (Virement SEPA instantané):
- EPC121-16 SCT Inst C2B IG 2017 V1.0.pdf pour les échanges client-banque et
- EPC122-16 SCT Inst Interbank IG 2017 V1.2.pdf pour les échanges entre banques et entre banques et CSMs.
Sur le schéma suivant que nous avons déjà vu dans un précédent article, les messages ont été ajoutés dans les espaces où ils sont utilisés et échangés. Un article sera rédigé très prochainement pour vous aider à comprendre la signification des noms des messages SEPA. Pour l’instant, nous allons juste nous contenter de voir à quoi ils servent.
Les messages – décrits dans les rulebooks SCT Inst – échangés pour le virements SEPA instantané
Dans le premier document (EPC121-16 SCT Inst C2B IG 2017 V1.0.pdf), on trouve les deux messages suivants: pain.001.001.03 et pain.002.001.03.
pain.001.001.03 (Ordres de SCT Inst)
Les ordres de virements SEPA instantané peuvent être transmis à la Banque par ce message. Le message peut contenir un ordre unitaire (aussi appelé ordre mono-bénéficiaire) ou un ordre groupé (multi-bénéficiaire). Il est important de noter que tous les clients ne transmettent pas un message pain.001.001.03 à leur banque.
En fait, la plupart des clients ne savent même pas ce que c’est. Ils se contentent de transmettre les informations demandées par la banque pour l’exécution d’un virement unitaire comme les informations du bénéficiaire, le montant et le motif. Et cette dernière se charge d’utiliser ces informations pour créer les messages à envoyer aux confrères.
Les messages pain.001.001.03 sont générés et transmis par des applications (ERP) d’entreprises ou associations de tailles moyennes ou grandes à leurs banques.
pain.002.001.03 (Payment Status Report)
Ce message est utilisé pour information le client donneur d’ordre sur le status de l’exécution de son ordre. D’après les rulebooks, il est obligatoire pour la banque d’informer son client si l’ordre est rejeté et le transfert de fonds ne peut donc être effectué. Dans le cas où tout se passe bien, la banque n’est pas obligée d’informer le donneur d’ordre. Mais cette information est importante pour le donneur d’ordre et cela s’est imposé comme bonne pratique.
Ici également, il faut noter que les banques n’envoient pas un message pain.002 à tous leurs clients. Ce message est envoyé aux entreprises et associations qui envoient eux-mêmes des messages d’ordres. Pour les autres clients, les banques envoient une notification de bonne exécution (avec mise à disposition des fonds au bénéficiaire) ou de rejet.
Dans le second document (EPC122-16 SCT Inst Interbank IG 2017 V1.2.pdf), on trouve les messages suivants: pacs.008.001.02, pacs.002.001.03, pacs.028.001.01, camt.056.001.01, pacs.004.001.02 et camt.029.001.03.
pacs.008.001.02 (SCT Inst – Règlement interbancaire)
Ce message est utilisé pour le règlement du montant du virement SEPA instantané entre banques. Il peut être transmis de la banque du donneur d’ordre à la banque du bénéficiaire directement ou par un CSM (système de compensation et règlement). Le pacs.008 est transmis directement quand on est dans une relation de participant direct – participant indirect. Quand il y a un CSM entre les deux banques, le CSM vérifie à la réception du message que la provision est suffisante sur le compte de la banque du donneur d’ordre avant d’accepter et transmettre l’ordre à la banque du bénéficiaire. Comme nous l’avons vu dans l’article précédent, le règlement se fait de façon instantanée.
pacs.002.001.03 (Confirmation positive ou négative)
Ce message est émis soit la banque du bénéficiaire à destination du CSM ou de la banque du donneur d’ordre, soit par le CSM à destination de la banque du donneur d’ordre ou de la banque du bénéficiaire. Il est donc important de noter que la banque du donneur d’ordre attend toujours la confirmation des autres acteurs et n’émet jamais de message de confirmation. La confirmation positive, par contre, n’est émise que par la banque du bénéficiaire. Le CSM se contente de le faire suivre à la banque du donneur d’ordre.
Une confirmation peut être émise pour des raisons techniques ou fonctionnelles. Dans le cas où la banque du donneur d’ordre envoie un message pacs.008 mal formaté avec une donnée obligatoire manquante (comme par exemple le montant), le CSM ou la banque du bénéficiaire émet une confirmation négative et le transfert est immédiatement rejeté. Ceci est une confirmation négative pour une raison technique.
Il peut arriver que le message soit correctement formaté, mais que la banque du bénéficiaire ne puisse pas traiter le virement parce que le compte du bénéficiaire est clos et ne peut donc être crédité. On est alors dans un cas de confirmation négative pour une raison fonctionnelle.
Dans le cas où tout se passe bien, c-à-d qu’il n y a aucun souci technique ou fonctionnelle, la banque du bénéficiaire émet une confirmation négative indiquant que le message a été reçu et que tous les contrôles sont OK pour le crédit du compte du bénéficiaire.
Un time-out de 20 secondes a été défini dans les rulebooks. Le CSM ou la banque du bénéficiaire peut rejeter le virement et envoyer une confirmation négative si les délais de traitement du virement instantané ne peuvent être tenus. Le CSM émet une confirmation négative à chacune des deux banques.
Enfin, le pacs.002 est émis par certains CSM pour confirmer à la banque du bénéficiare que la confirmation positive a bien été reçue et traitée.
pacs.028.001.01 (Trx status Investigation Message)
La banque du donneur d’ordre peut émettre ce message si elle n’a pas reçu de confirmation positive ou négative 25 secondes après avoir horodaté et émis le SCT instantané vers les CSM. Peut émettre parce que ce n’est pas obligatoire de le faire d’après le rulebook. Par contre, le rulebook oblige les banques et CSMs à recevoir ce message et à le traiter pour informer la banque émettrice du statut de la transaction. La banque ou le CSM (re)émet ou alors le message de confirmation positive ou négative vers la banque du donneur d’ordre.
camt.056.001.01 (Recall – demande d’annulation)
Un virement instantané peut être envoyé de façon érronée,
- soit par le donneur d’ordre s’il s’est trompé de bénéficiaire ou de montant par exemple
- soit par la banque du donneur d’ordre si elle a émis le virement deux fois
Dans le guide d’implémentation, on trouve les raisons pour lesquelles une banque peut émettre un recall sous le paragraphe 2.4.2 Message Element Specifications. C’est curieux qu’on y trouve pas la liste des raisons pour lesquelles une banque peut émettre un recall. Pourtant ces raisons sont évoquées dans le rulebook (EPC004-16 2017 SCT Instant Rulebook v1.1) sous l’attribut 52 (AT-52) à la page 57.
Le recall est donc un message envoyé pour annuler un SCT instantané qui n’aurait pas dû être émis et récupérer les montants transférés à tort. A la réception d’une demande d’annulation, la banque bénéficiaire à deux possibilités: répondre positivement à la demande et retourner les fonds ou répondre négativement et conserver les fonds. Cela nous mène aux deux derniers messages.
pacs.004.001.02 (Positive Response to Recall)
Ce message est émis par la banque du bénéficiaire vers la banque donneur d’ordre pour répondre positivement à une demande d’annulation. Les règles SEPA autorise la banque du bénéficiaire à prélever une commission et donc à retourner une partie du montant seulement.
camt.029.001.03 (Negative Response to Recall)
Ce message est émis par la banque du bénéficiaire vers la banque donneur d’ordre pour répondre négativement à une demande d’annulation. La banque doit indiquer dans ce message pour quelle raison la demande d’annulation a été rejetée.
Chaque message a été présenté mais nous n’avons pas vu dans quelle séquence ces messages sont échangés. Nous préparons quelques schémas à ce sujet et nous en parlerons de façon détaillée dans le prochain article. Abonnez-vous à la newsletter si vous trouvez cet article intéressant. Vous aurez alors une notification lorsque les prochains articles seront en mis en ligne.
Bonjour,
Merci pour cet article qui me semble très intéressant mais un peu difficile à comprendre (pour moi en tout cas). Il contient un grand nombre d’informations que je n’arrive pas ingurgiter, et donc je lis le texte sans vraiment arriver à l’associer aux noms et la constitution des messages.
Permettez-moi donc de vous faire des propositions si ce n’est pas déplacé et impertinent:
1- Il serait peut-être plus facile à comprendre si vous expliquiez d’abord la signification (constitution) des noms des messages. Par exemple, dans le message pain.001.001.03, expliquer ce que veut dire « pain », ce que représente le premier « 001 », puis le second et enfin le « 03 ». Vous avez dit qu’il y a un article la dessus, dans ce il serait peut-être bien d’intervertir l’ordre des articles.
2- Ensuite diviser le présent article en plusieurs autres, chacun expliquant les différents types de messages échangés
3- Enfin faire un article séparé présentant cette belle cinématique d’échanges comme vous le faites ici
Merci par avance.
Cordialement,