SEPA messages: what they are and how they work
SEPA messages and ISO 20022
ISO 20022 is a standard for data exchange between financial institutions, and is the messaging standard used for SEPA payments. Both PSPs (payment service providers) and CSMs (clearing and settlement mechanisms) send payment data using ISO 20022.
The ISO 20022 standard covers business processes as well as message formats, and ISO 20022 messages are text files that use the XML syntax.
The European Payments Council has enforced the use of ISO 20022 messages throughout the SEPA zone to harmonise payment - and account-related data. As a result, the SEPA has led the way in terms of adoption, with major countries such as the United Kingdom, the United States, Canada, and Australia in the early stage of adopting ISO 20022 too.
Understanding ISO 20022 XML messages used in SEPA
The first four letters represent the message category. Combined with the following three digits, it represents the message identifier. The last five digits represent the message version.
SEPA uses three message categories:
| Message Category Code | Message Category Name | Description |
|---|---|---|
| PAIN | Payment initiation | Messages used by corporate customers to send payment instructions to their banks. |
| PACS | Payment clearing and settlement | Messages used by SEPA direct and indirect participants to send and receive payment instructions and related operations to and from their banks and / or CSMs. |
| CAMT | Cash management | Messages used by banks to send account reports, including balances and transactions, to their customers. Messages also used by customers to request the cancellation of a payment by their banks. |
Payments
SEPA payments are sent and received using PAIN and PACS ISO 20022 XML messages. PAIN and PACS messages include information regarding the account holder, the payment, and the beneficiary. More than 25 fields must be populated to send a single payment, including multiple technical IDs and payment scheme-specific details.
Different PAIN and PACS messages are used depending on the payment method used as well as customer type. PAIN messages are used by corporates, while PACS are used by SEPA indirect and direct participants. A pain.008.001.02 message used by a corporate customer to send a SEPA direct debit instruction will contain payment scheme-specific details, such as the creditor identifier and the unique reference mandate.
| Category | Payment Method | Corporate Customer | SEPA Participant |
|---|---|---|---|
| Payments | SEPA Credit Transfer | pain.001.001.03 | pacs.008.001.02 |
| SEPA Credit Transfer Instant | pain.001.001.03 | pacs.008.001.02 | |
| SEPA Direct Debit Core | pain.008.001.02 | pacs.003.001.02 | |
| SEPA Direct Debit B2B | pain.008.001.02 | pacs.003.001.02 | |
| Related transactions | Return (SCT / SDD) | N/A | pacs.004.001.02 |
| Reversal (SDD) | pain.007.001.02 | pacs.007.001.02 | |
| Recall (SCT) | N/A | camt.056.001.01 | |
| Recall request positive response | N/A | pacs.004.001.02 | |
| Recall request negative response | N/A | camt.029.001.03 | |
| Inquiries | Payment status request | N/A | pacs.028.001.03 | Non-receipt claim | N/A | camt.027.001.03 |
| Resolution of investigation | N/A | camt.029.001.03 |
Payment Status Reports
In addition to payment files, SEPA payments rely on payment status report (or PSR) files. PSRs are generated and sent by banks to their customers to notify customers of the processing status of their payment files.
Two common types of PSRs are file status reports and payment status reports. Both types of PSRs use the pain.002.001.03 ISO 20022 message format.
PSR support and capabilities are not standardised and vary from bank to bank. Some banks only partially support PSRs or may not support PSRs at all. When this happens, customers are forced to perform indirect reconciliations to update the status of their payments. Such reconciliations can include marking a payment as:
-
Executed if it has not been explicitly rejected
-
Executed if it can be reconciled with a transaction posted on the account
-
Rejected if it cannot be reconciled with a transaction posted on the account after a certain period
File Status Report
A file status report (FSR) indicates if the payment file could be processed or has been rejected by the bank because of an invalid format. An FSR is mostly meant for technical controls and format validations.
Payment Status Reports
A payment status report (PSR) indicates if and how the payments contained in the payment file have been processed by the bank. Common processing statuses include:
| Status Code | Description |
|---|---|
| ACCP | Payments have passed technical and functional validations. |
| Payments have been accepted and processed. | |
| Payments have been put on hold. A reason is included. | |
| Payments have been accepted and processed. For instant payments only. | |
| ACSC | Payments have been accepted and processed. For instant payments only. |
| PART | At least one payment of the file is accepted and processed, and at least one payment of the file is rejected. |
PSRs contain status updates at payment group and individual payment levels. Statuses can either be final or non-final. A final status means that the payment cannot be changed to another status later on. A non-final status means that the status of the payment will likely evolve later on.
If all the payments of a PSR have the same status, then the whole group can be tagged with this status. Conversely, if the group contains payments that have different statuses, the group status will be PART and every payment details will contain the individual payment status. The following table summarises the different statuses payments can have and whether the status is at a payment group or individual payment level:
| Status Code | Payment Group Level | Individual Payment Level |
|---|---|---|
| ACCP | ✅ Yes | ✅ Yes |
| ACSP | ✅ Yes | ✅ Yes |
| PNDG | ✅ Yes | ✅ Yes |
| RJCT | ✅ Yes | ✅ Yes |
| ACSC | ✅ Yes | ✅ Yes |
| PART | ✅ Yes | ❌ No |
Integrating ISO 20222 messaging in your payments operations
SEPA uses the ISO 20222 standard to good effect, but integrating ISO 20022 messaging into your payments operations can be challenging. Numeral’s API-driven integration delivers a simplified approach.
Subscribe to our newsletter and stay in touch with us to see how you can use the Numeral API to integrate SEPA messaging into your payments workflow.
.svg)
Other articles you might like
Not sure where to start?
Let’s talk about how we can work together to accelerate your payment flows. Get a demo of our platform, explore our pricing, or get started right away.
.svg)