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.
Pacs.008.001.02 (SCT)
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).
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 watch the presentation and get the ebook on this page.
pacs.002 are ‘Payment Status Report’ and as such can also be used to positively confirm a payment, especially in the context of Instant Payments.
Hi, Thanks for your comment. Very appreciated. What you say in totally right. The Pacs.002 is a Payment status report.
Therefore it can be used to provide a positive or negative status report. And the Pacs.002 is used in Instant Payments to provide positive and negative status reports.
This article is about the classic SEPA Credit Transfer, Not SEPA Instant Payments. Sorry if that is not very clear.
If you read the SCT classic Implementation Guidelines (EPC115-06 Interbank CTIG V8.0 Approved) in Chapter 2.3 Inter-bank Credit Transfer Reject Dataset (pacs.002.001.03), you find the pacs.002 detailed description. There the pacs.002 is used only for negative reports. In reality though, CSM and banks do exchange positive status reports among themselves. But they have to use specific messages for that, messages that you do not find in the SCT classic Implementation Guidelines. This shows that the standard is sometimes incomplete and some solutions must be developped outside the standard to fulfill needs that it does not address. Just continue to follow this blog. I am planning to write articles on Instant payments and to share my own thoughts about the standards later.
Hi Jean Paul,
If I understood well pacs.002 is not mandatory for the beneficiary banks. Can this though become mandatory for an indirect participant if their direct participant requests so ? If yes, what is the “status reason” for positive answer ?
Tnx
Beneficiary bank does not send pacs.002 to the CSM because the CSM is always right. 🙂
But the beneficiary bank must implement a pacs.002 as requested in the implementation guidelines.
The pacs.002 can be used between direct and indirect participant. Note that in SEPA Scheme, the Pacs.002 is used only for rejection.
If you use it to send positive answer, you go beyond the scope of SEPA. Many do that in practice.
Now what to use if you want to send a positive answer? It is TS01. You find it in the ExternalStatusReason1Code sheet of the External Code Sets available on the ISO 20022 website. The sheet contains all the possible codes that be used as Status Reason either for positive answer or reject answer.
BR, Jean Paul
Hi!
I have some questions for you regarding Instant Payments.
What do you mean here “But they have to use specific messages for that, messages that you do not find in the SCT classic Implementation Guidelines.” ?
Furthermore please help me tell the difference between the pacs002 and the http202 accepted messages. Regarding instant payments the http202 is required for the banks to know the status of the transaction for sure…according to banks.
So both of them is required? They are used for different purposes, if yes, what are these?
Thanks!
Hi,
Sorry, I don’t know any http202 message in the context of SCT or SCT Inst. Could you please elaborate more?
“But they have to use specific messages for that, messages that you do not find in the SCT classic Implementation Guidelines.” ?
There are many messages in the standard ISO 20022 that you do not find in the SCT guidelines. Many. And some messages of the SCT guidelines can be used, but in another way. That is the world of ISO 20022.
Yes both of them are required. First one is techical one (that CSM accepted your pacs002), second one pacs002 is final one that tells you confirmation or rejection of payment.
What is value date in pacs.008?
The value date is not available in the Pacs.008. For the beneficiary, it is the settlement date as requested by the Payment Service Directive.
For the Debtor, it is usually the day before the settlement day, but it can also be the settlement day in case of same day settlement.
What is Pacs.002s2 rsf report ? Where an I get the this information ?
I understood that rsf report will be shared from CSM to bank with status of payment… this pacs.002s2 contains details for camt56 and camt29, pacs.004 status details or pacs002s2 contains only about pacs.008 ?
Hi, can you advise pacs.008 is request for credit transfer in interbank space then what will be the response messageto pacs.008 and payment initiation pain.001
Hi,
what is the meaning of xs:ComplexType, xs:choice, xs:sequence in pacs.002.001.11.xsd?
Which fields in Pacs002 indicate the exact reason for cancellation/rejection