Contrary to the messages used in the customer to bank space which are recommended, messages exchanged in the interbank space are mandatory. It means banks must comply with all the underlying SEPA rules. This is to insure that their messages can be received and processed by any participant to the interbank space. Banks can exchange messages directly between themselves or through a Clearing and Settlement Mechanism. In this article, pacs.008 and pacs.002 messages used in the interbank space will be presented and analyzed.
The Financial Institution To Financial Institution Customer Credit Transfer message is used to move the money from the sending bank to the destination bank. When the bank of the debtor sends the pacs.008, it is like it is saying to the bank of the beneficiary: “Here is money I have debited to my customer. Please take the money and credit your customer whose account information is available in the payment.” But the real movement of money happens only after clearing and settlement. Therefore the credit transfer must have a settlement date, which is the date where the funds transfer is done from the originator bank to the beneficiary bank.
The pacs.008 is by far the message with the highest volumes in the interbank space. In an ideal world where nothing unwanted would happen during the processing of those messages, the other messages would not be needed at all. But we know that it is not the right way of thinking. Don’t we? There is no process without exception. Indeed, many exceptions can happen during the processing of the credit transfer either at Debtor bank or at Creditor bank. When an exception occurs, banks should be able to handle it properly and provide the correct information to their peers or customers.
The exceptions! The exceptions! Our lives would be much easier in the payment world without them. One message is required to move the money, but many messages are needed to handle the exceptions. All the messages except the pacs.008 are exception handling messages. They are also called related transactions or r-transactions because they all relate to the original pacs.008. The pacs.002 and the messages that we will consider in the next article are all related messages. Now let’s talk about the pacs.002.
Pacs.002.001.03 (Payment Status Report or Reject SCT)
SEPA Credit Transfer and R-transactions messages can be rejected for many reasons: the message is not readable because the XML format is invalid. The IBAN or the BIC specified in the message is invalid, and so on. Rejections of pacs.008 messages can happen at many levels as we will see later. The pacs.002 provides the information about the level and the original message which has been rejected.
For two banks that exchange transactions through a CSM, the credit transfer message first has to go through the CSM. The CSM rejects the message if it fails the checks, and sends a pacs.002 to the originator Bank. For most of the time, the reject message is sent by the CSM and not by the beneficiary Bank. If a CSM creates a pacs.002, the rejected pacs.008 will obviously not be settled at settlement date.
A direct participant bank sends a pacs.002 to indirect participants to inform them about transactions that have been rejected. When that happens, the related transactions do not reach the CSM and thus cannot be settled.
According to the SCT rulebook, the CSM or the Bank, that sends a pacs.002 message, has to do it either the same day where the pacs.008 was received or at the latest on the next business day.
The next article will be about the other messages in the interbank space: Pacs.004, Camt.056 and Camt.029
For your information, I have published an ebook about SEPA Credit Transfer where one full chapter is dedicated to SEPA Credit Transfer messages.
Below are the links on amazon (Check if the book is on the amazon site of your own country).
You can download the sample for free. Here is the link to download the sample of the SEPA Credit Transfer eBook.
You can watch the presentation and get the ebook on this page.