Dans l’article précédent, nous nous sommes intéressés aux messages échangés dans le cadre du virement SEPA instantané pour le cas passant c.-à-d. le cas où tout se passe bien. Il n’y a pas d’échec lors de la réalisation des contrôles techniques et fonctionnels. Les messages sont transportés sans aucune perte. Les comptes de clients existent et peuvent être débités et crédités. Les contrôles de fraude et de conformité sont OK. Etc.
Ce serait génial si les choses se passaient toujours ainsi. Mais nous savons tous que la réalité est toute autre. Il y a toujours un truc qui ne marche pas comme on le souhaiterait. Pour avoir des processus robustes, ces cas doivent également être gérés correctement. Ce sont les cas d’exceptions.
Dans le rulebook du SCT Inst, quelques cas d’exceptions sont présentés. Et le but de cet article est d’en parcourir quelques-uns de ces cas. Veuillez noter que les cas d’exception dont nous allons parler ne sont pas exhaustifs. Il existe de nombreux autres cas et il serait difficile de tous les identifier et analyser dans un article. Nous allons nous concentrer sur les trois cas d’exception en particulier:
- Cas de confirmation négative émise soit par le CSM, soit par la banque du bénéficiaire.
- Cas de confirmations négatives émises par le CSM vers chacune des banques
- Procédure d’investigation initiée par la banque du donneur d’ordre
Si on veut être strict, ces cas d’exception pourraient être séparés en plusieurs sous cas. Mais nous avons choisi de les laisser ainsi afin de donner un aperçu général des cas d’exception et de leurs conséquences.
Confirmation négative émise soit par le CSM, soit par la banque du bénéficiaire
Le schéma suivant présente l’ordre dans lequel les messages sont échangés dans ce cas.
Ordre des Messages échangés SCT Inst – Cas exception – Confirmation négative CSM ou Banque du bénéficiaire
Comme on peut le voir sur le schéma ci-dessus, un virement SEPA instantané peut être rejeté soit par le CSM, soit par la banque du bénéficiaire. L’entité qui rejette le virement émet alors un message de confirmation négative destinée à la banque du donneur d’ordre.
Le rejet est la conséquence d’un contrôle non passant entrainant l’arrêt de l’exécution du virement. Il peut s’agir aussi d’un virement instantané qui est arrivé hors délai. Lorsque la banque du donneur d’ordre reçoit un rejet de SCT Inst, elle a l’obligation de transmettre l’information au donneur d’ordre. Cela se fait par un message pain.002.001.03 si la banque a reçu un pain.001.001.03 du donneur d’ordre ou tout simplement par une notification (un SMS par exemple).
Confirmations négatives émises par le CSM vers les banques du donneur d’ordre et du bénéficiaire
Le schéma suivant présente l’ordre dans lequel les messages sont échangés dans ce cas.
Ordre des Messages échangés SCT Inst – Cas exception – Confirmations négatives CSM
Le rulebook prévoit un cas d’exception où le CSM ne reçoit aucune confirmation de la part de la banque du bénéficiaire après un time-out de 20 secondes. Dans ce cas, le CSM peut rejeter le SCT inst en émettant un message de confirmation négative vers la banque du donneur d’ordre et un autre vers la banque du bénéficiaire.
A réception du message, la banque du donneur notifie le donneur d’ordre du reject du SCT Inst comme déjà evoqué ci-dessus.
Procédure d’investigation par la banque du donneur d’ordre
Le schéma suivant présente l’ordre dans lequel les messages sont échangés lors d’une procédure d’investigation.
Ordre des Messages échangés SCT Inst – Cas exception – Procédure d’investigation
Le SCT Inst Rulebook prévoit un autre cas d’exception intéressant : la procédure d’investigation. Cette procédure est initiée par la banque du donneur d’ordre dans le cas où elle n’a reçu aucune confirmation (positive ou négative) après un time-out de 25 secondes.
La banque du donneur d’ordre émet alors un message pacs.028.001.01 pour s’enquérir du statut du virement auprès du CSM et de la banque du bénéficiaire. A réception de ce message par le CSM :
- si le CSM avait déjà transmis une confirmation (positive ou négative), alors il doit à nouveau émettre ce message vers la banque du donneur d’ordre. Le CSM peut donc émettre un message de confirmation positive ou négative à réception d’un pacs.028. C’est pourquoi il est en pointillé dans le schéma.
- Si le CSM n’avait pas encore transmis de message de confirmation, alors il fait suivre le message d’investigation à la banque du bénéficiaire. La banque du bénéficiaire émet ou reémet un message de confirmation selon les résultats des traitements effectués sur le pacs.008 (SCT inst). La banque du bénéficiaire peut donc émettre un message de confirmation positive ou négative à réception d’un pacs.028. C’est pourquoi il est en pointillé dans le schéma. Le CSM n’émet l’accusé de réception positif (Delivery report) que si c’est un message de confirmation positive. Ce message est également transmis par le CSM à la banque du donneur d’ordre. Si c’est un message de confirmation négative, le CSM se contente de le faire suivre à la banque du donneur d’ordre.
Bien ceci termine notre analyse des cas d’exception. Elle est brève, mais je pense utile et vous pourrez vous en inspirer sur vos projets pour modéliser des processus ou préparer des cas de tests.
Dans le prochain article, nous allons nous intéresser à un message échangé dans le SCT Inst : le pacs.008.001.02. N’hésitez à laisser des commentaires pour poser des questions ou faire des remarques. Merci d’avance.
No comments yet.