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.

Beneficiary bank incoming and outgoing mandatory messages

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.

4 Responses to Focus on SCT beneficiary bank messages in the interbank space

  1. Sreevithya March 25, 2019 at 7:12 am #

    Hi Mr. Jean

    Will any accounting entry get generated while generating PACS.002 for an incoming PACS.008. or is it just a rejection message for an incoming PACS.008? Please clarify

    • Jean Paul March 26, 2019 at 1:11 pm #

      In the case a pacs.002 is generated for an incoming pacs.008, there is usually no need to generate any accounting entry.
      The pacs.002 is then used as a status report to inform the sending party about the outcome of the pacs.008 processing.
      That being said, each case is different. So do not take this as a rule.

  2. Sreevithya April 2, 2019 at 1:09 pm #

    Thanks jean. Could you please tell me the system behaviour in terms of the accounting entries when a pacs.002 is generated as a negative acknowledgement? because in this case though the amount has not been credited to the customer’s account the fund needs to be credited back to the sender’s account.

    • Jean Paul April 5, 2019 at 11:22 pm #

      Basically all the accounting that you did before sending the pacs.008 must be undo when you receive the pacs.002.
      You should do exactly the reverse. If you debited account A and credited account B, now you must debit account B and credit account A.

Leave a Reply