ISO 20022 Messages exchanged in the SDD schemes

After looking at the different SDD schemes, the involved players and their roles, the next thing to consider is the messages exchanged in the schemes. Which messages do the different players exchange and for what purpose? To find out which messages are exchanged in the schemes, the documents to consult are the SDD implementations guidelines published by the European Payments Council. There are three implementations guidelines documents for each scheme:

• Customer-to-Bank Implementation guidelines: it lists the messages exchanged between the customer and its bank, therefore the name customer-to-bank
• InterBank Implementation guidelines: it lists the messages exchanged in the interbank space, either between Bank and CSM or between 2 Banks directly like a direct participant and a sub participant.
• e-Mandate Service Implementation guidelines: it lists the messages exchanged between Creditor, Creditor Bank and Debtor Bank about the mandate.
  

The figure below depicts the Customer-to-bank space and the Interbank space and the messages available in the C2B and IB implementations guidelines. The messages for the e-mandate services will be considered in the next article.

In the SDD implementation guidelines, two types of messages are found: PAIN and PACS messages. PAIN stands for PAyment INitiation and PACS for PAyment Clearing and Settlement as defined by the standard ISO 20022.

Important for each message is the direction in which it flows. The next figure provides an overview of all the messages mentionned in the implementation guidelines and their direction, if it is from customer to bank or from bank to customer or if it is from Creditor Bank to Debtor Bank or vice versa. Note that when it comes to message flows, the CSM in between mostly like a bridge. However, it must be able to handle exceptions and reject a message for example if it is not properly formatted.

We have 7 messages in total. Messages in bleu are the ones exchanged in happy cases. The red are the ones are foreseen for the unhappy cases. You certainly agree with me that there are quite many. If we think in terms of ratio, we are using 30% of the messages (2/7) for the happy cases and 70% (5/7) for the exceptions. Sometimes, I hope we could flip the ratio and have 70% for the happy And 30% for the exceptions. But in payments like in life the exceptions are what make the things a bit more complex to handle. In payments, we spent most of our time handling exceptions. Now I am used to it :-). The ratios are even worse for other schemes like the SEPA Credit Transfer or in Cross Border payments.

Now let’s look at the messages. The messages are based on the standard ISO 20022. And they have a specific nomenclature. To get the details aboute nomenclature, please refer to this previous article where you get keys to understand SEPA Messages names. Initially Customer-to-Bank messages were recommended and interbank messages were mandatory. But nowadays, Customer-to-Bank messages are mandatory as well.

Customer-to-bank Messages

Pain.008.001.02: The Creditor sends this message to the Creditor Bank. It carries the Direct Debit Collection instructions.  The Creditor expects his Bank to credit his account after successful processing of the instructions. When the account to debit is with another Bank (It can be with the creditor bank as well.), the creditor bank must forward the instructions to the debtor bank through the CSM. According to rulebook, the Pain.008 can be sent at the soonest 14 days before due date and at the latest one day before due date. But Creditor Bank may accept to receive the instructions from its customer many months before due date. That is why we read in the rulebook: “14 Calendar Days unless otherwise agreed between the Creditor Bank and the Creditor”. Note that a creditor may initiate Direct Debit Collection instructions from its bank web portal and via other means as agreed with his Bank. All creditors do not send Pain.008 files to their banks.

Pain.002.001.03: The Creditor Bank sends this message to the Creditor to inform him that instructions could not be processed successfully and have been rejected.  Rejects are sent immediatthons from the CSM or the Debtor bank. Rejects must be made available to the Creditor at the latest on the next business day after the rejection occurence. In general, the Creditor receives them few minutes after the collection rejections.

Pain.007.001.02: The Creditor may send a Direct debit collection intruction and then realize after settlement that he made a mistake. He should never have sent it. This message is foreseen for those cases. The Creditor sends it to his Bank to reverse the funds to the debtor. This message can therefore be considered as a Credit Transfer. The Creditor expects his Bank to debit his account (so funds must be available) and credit the account of the debtor with him or with another bank. The reversal can be sent up to 5 days after settlement.

Interbank messages

Pacs.003.001.02: The Creditor Bank uses this message to transport the Direct Debit Collection instructions to the Debtor Bank, directly or through intermediaries like a CSM. It must be sent at the latest one day before due date and not earlier than 14 Calendar Days before the Due Date. The CSMs receive the instructions and save them until execution at due date. This message may follow a Pain.008.001.02 message that was processed successfully and “transformed” if the creditor sends Pain.008.

Pacs.002.001.03: Many exceptions can happen during the processing of a Direct Debit Collection instruction either by the CSM or by the Debtor Bank. Something may be wrong with the format or the content of the message. In the first case, it is a technical issue and in the second, it is a functional issue. When an exception occurs, a Pacs.002.001.03 is generated and sent back to the Creditor Bank. Up to the creditor Bank to forward that message to its customer, the creditor. This message contains the reason code ‘RJCT’ indicating that it is a reject.

Pacs.004.001.02: The Debtor Bank sends this message to the creditor bank, through the CSM or not, to get back the funds that were previously debited at settlement date. The same message is used either as a return or as a refund. In the first case, the debtor is the initiatior of the message and it can be sent up to five business days after interbank settlement. In the second case, when pacs.004 is used as refund, the debtor is in the initiator and we distinguish two types of refunds:

• The no-questions-asked refund which can be sent up to 8 weeks after SDD settlement. The debtor bank should process the refund request without investigating if the mandate is valid or not.
• The Refund for Unauthorised transaction which can be sent up to 13 months after SDD Settlement. The debtor bank forwards the claim to the creditor through ist bank and issues the refund only if the mandate was invalid.

Pacs.007.001.02: The message is sent by the Creditor bank to the Debtor bank, through the CSM or not, to credit the debtor’s account that was unduly debited at settlement date. The funds are then reversed to the debtor. By the way, a reason code must be provided in the reversal. It can take the values AM05, MS02 and MS03 according to the implementation guidelines. But are these  the only values allowed by the standard ISO 20022? Please leave a comment if you have the answer.

The next article will be about the messages listed in the e-Mandate Service Implementation guidelines.