Focus on SCT beneficiary bank messages in the interbank space

In this article, we will look at all the messages exchanged by the beneficiary bank in the interbank space. If you are starting your journey in SEPA, you will think immediately that is the bank that receives credit transfers. And that is true. Yes it receives the credit transfers. But it does much more that. It sends all the messages resulting from exception handling like the payment return or the responses to a cancellation request. The beneficiary bank may also receive a cancellation request. And if it happens, it must of course handle it and reply correctly.

So as a beneficiary bank, it is not sufficient just to receive the credit transfer. The beneficiary bank must be able to send and receive all the other messages, which are mandatory in the interbank space. A beneficiary bank that can only receive credit transfers, but not send payment returns is not SEPA compliant and cannot adhere to the Scheme. What will happen if such a bank receives a credit transfer that cannot be credited on a customer account because the account is close for instance? Keeping the money is not acceptable and sending the money back through another credit transfer is not what the Scheme expects. A return message must be sent back to the originator bank. Handling the exceptions is a must to become participant to the Scheme.

Another interesting thing to note when we look at the interbank space is the symmetry of messages exchanges between originator bank and beneficiary bank. All messages sent by the originator bank are received by the beneficiary bank and vice versa. The debtor bank does exactly the opposite of what the creditor bank is supposed to do.

The debtor bank and only the debtor bank sends the pacs.008. It never receives it. But the beneficiary bank does. The debtor bank and only the debtor bank sends the camt.056. It never receives it. But the creditor bank does. The beneficiary bank and only the beneficiary bank sends the pacs.004. It never receives it. I am insisting on this to help you grasp a very important point in SCT and SEPA payment in general: The roles of debtor bank and beneficiary bank can be completely decoupled in the implementation, since they don’t do the same thing.

It is possible to process the debtor bank’s messages in one IT application and to have another completely different application handle the beneficiary bank’s messages. If you see the same application sending and receiving credit transfers at the same time (and the messages for exceptions handling of course), then it means that the application is handling both debtor bank and beneficiary bank messages. Many CSM see participants as Debtor and Creditor bank at the same time. When a CSM bulks pacs.008 and pacs.004 in the same file and delivers it to a direct participant, the direct participant handles the received pacs.008 as beneficiary bank, but the received pacs.004 as debtor bank.

For your information, I have published a book about SEPA Credit Transfer where one full chapter is dedicated to the messages exchanged in SEPA Credit Transfer Scheme.

Below are the links on amazon.

Kindle edition

Paperback edition

You can download the sample for free. Here is the link to download the sample of the SEPA Credit Transfer eBook.

You can buy the ebook and get a free access to a content rich webinar on this page.

With this we end our analysis of the SCT scheme messages. I am sure you have all heard that SEPA messages are based on ISO 20022. What is ISO 20022 and why is it so important in SEPA and payment world in general? To get the answers, just get continue to visit this blog.