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.
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.
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.
I am Srikanth from India. I want to know what are the technologies required to implement sepa ISO 20022 in my java application.
Thanks and regards
Should the Dr. bank send any response message after receipt of pacs.007?
The scheme does not expect the debtor bank to send another message after receiving the pacs.007. Of course, things like (technical) acknowledgements can be sent. But that depends on the protocol used to exchange the messages, and it is independent of the scheme rules.
Have another query. When a request for refund is initiated by the Dr. bank in the form of a pacs.004 and sent to the Creditor Bank – will the Creditor bank acknowledge the request positively if they are accepting to refund?
If yes, which message is used to intimate about the payment reversal? – Is it pacs.007?
What message is sent in case if they refuse to refund?
No the creditor bank does not accept the pacs.004. According to the scheme, when a pacs.004 is sent and processed correctly, creditor bank account is debited and debtor bank account is credited in the CSM at settlement date. The creditor then debits the account of the creditor and the debtor bank credits the debtor account. So the debtor has the final word according to the scheme. The creditor bank does not have the choice, but to accept and process the pacs.004.
Second question: the reversal is sent in a completely different context. It is to give the money back when the pacs.003 should not have been sent. So it is the creditor/creditor bank that takes the initiative of sending it. And when the debtor bank receives it, it just processes it and credits the debtor account.
Happy payments Journey, 🙂
Hey Jean, Could you please please explain me the difference between return as pacs 004 and refund as pacs 004?
Your blogs are extremely useful and informative. Thanks for making payments interesting to learn. I have few questions:
If something goes wrong in the Debtor bank side, how will the Dr bank decide to send a Pacs.002 message or a Pacs.004? What is the difference between these scenarios?
Also could you explain the difference between Authorized and Unauthorized refund?
Your blog are very useful for people who are starting in SEPA projects like me.
I have a doubt with pacs.002. I dont know the differences between a message when it is sent with rejections o simply to report a complete acceptance.
Would be the same versión of pacs.002, isnt it?
Jorge David Villafafila
you need to check the pacs.002 reason codes. The reason code tells you how to interpret the pacs.002, if it is full acceptance, partial or full rejection.
I hope this helps.
when it is pre settlement , meaning in case of rejection / refusal from debtor bank/ debtor , does money already debited from account ?
I am really not properly understood this sdd flow can someone explain to me
I have a question regarding the mandate amendment. Based on rulebook when a mandate is amended, its data should be sent from creditor to creditor bank with the next collection.
But what happens if based on the timeplan the next scheduled collection has already been sent with mandate’s previous version data? Should creditor bank request for cancellation (or reversal according to due date)?
– If yes, then the creditor bank should send a new collection with the same due date and the amended mandate?
– If no, do we assume that this collection will be handled properly by CSM and debtor bank, and it is sufficient for the creditor bank to send the amendment with the next collection?
Hi Jean, thanks for this wonderful sight as this is my first comment here 🙂
One question, PACS.004 is used for both refund and return. My understanding is if it is originated by debtor then it is called refund and if it is via debtor bank then it will be called return. Is my understanding right?
Moreover, is it a typo here when we called Debtor in both case,
In the first case, the debtor is the initiator 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
Thanks for putting this up. Very informative and useful.
For pacs004 message below line is mentioned :
“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. ”
I believe you need to correct it to “In the first case , the debtor bank is the initiator of the message”
in case of return i believe debtor bank is the initiator and in case of refund debtor is the initiator.
Please correct or advise if this understanding is not correct.
Fiirst of all, I really appreciate your articles. They are so technical and precise. However, I would like to know the three layers of mx messages. My email; firstname.lastname@example.org