SEPA 101

SEPA messages: what they are and how they work

Victor Mithouard
November 2022
min read

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 CodeMessage Category NameDescription
PAINPayment initiationMessages used by corporate customers to send payment instructions to their banks.
PACSPayment clearing and settlementMessages used by SEPA direct and indirect participants to send and receive payment instructions and related operations to and from their banks and / or CSMs.
CAMTCash managementMessages 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.


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.

CategoryPayment MethodCorporate CustomerSEPA Participant
PaymentsSEPA Credit Transferpain.001.001.03pacs.008.001.02
SEPA Credit Transfer Instantpain.001.001.03pacs.008.001.02
SEPA Direct Debit Corepain.008.001.02pacs.003.001.02
SEPA Direct Debit B2Bpain.008.001.02pacs.003.001.02
Related transactionsReturn (SCT / SDD)N/Apacs.004.001.02
Reversal (SDD)pain.007.001.02pacs.007.001.02
Recall (SCT)N/Acamt.056.001.01
Recall request positive responseN/Apacs.004.001.02
Recall request negative responseN/Acamt.029.001.03
InquiriesPayment status requestN/Apacs.028.001.03
Non-receipt claimN/Acamt.027.001.03
Resolution of investigationN/Acamt.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 CodeDescription
ACCPPayments 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.
ACSCPayments have been accepted and processed. For instant payments only.
PARTAt 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 CodePayment Group LevelIndividual 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.

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.

Contact us