pain.002 – Pain for companies with VOP?

The ISO 20022 message formats pain actually stand for Payments Initiation, but pain.002 is used to confirm payment orders. With Verification of Payee, pain.002 takes on a new meaning.

pain.002 Definition in ISO 20022

The pain.002.001.xx message has the official name “Customer Payment Status Report“. It informs the submitter of a payment order (usually a company) about the status of this transaction – for example, whether it has been accepted, rejected or partially processed. Both an overall status and a status per individual transaction (e.g. for collective transfers) are returned.

pain.002 contains:

• References to the original pain.001 order (e.g. Message ID, Payment Information ID)
• Status information at order and transaction level
• Error codes and optional error message texts (e.g. “ACCP”, “RJCT”, “PDNG”)

Different use of pain.002

A frequent stumbling block: the meaning and use of pain.002 is not the same everywhere. This leads to uncertainty, especially for corporate customers: What does an “ACCP” response signal to me – is the order booked or just accepted? Answer: Unfortunately, it depends on how the bank interprets it.

Standard vs. real-time credit transfer: differences with pain.002

There are also differences between classic SEPA credit transfers and SCT Inst payments: most banks do not give a positive confirmation for a standard credit transfer, but only report a rejection as pain.002.

With the increasing importance of real-time payments (SEPA Instant Payments), companies often also want immediate confirmation of the transfer, but this is not mandatory for banks either as pain.002 or as a comparable message. The regulations for SEPA Instant Payments stipulate that the amount must be available to the recipient immediately, but the payer is not entitled to an active notification.

pain.002 usage at Verification of Payee (VoP)

Verification of Payee will be mandatory in the Eurozone from October 2025 and pain.002 will also be used here:

• Many VoP processes use the status report to signal rejected payments due to a lack of name match (similar to ID matching) (close match, no match). A positive name match leads to a positive pain.002.
• The confirmation can take place at individual level (per payment) – this leads to complex processing for bulk transfers. Banks in Germany usually reject the bulk as a whole if the VoP results of individual transactions are negative.
• The pain.002 analysis is simpler for individual transactions as CCUs, but further processing in the ERP system must also be coordinated here.

For corporates, this means:

• pain.002 must be analysed if VoP is active
• the handling of VoP must be checked and harmonised for each bank account
• mismatch in a transaction must not block the entire file
• Implementation often requires customised interfaces or scripts

Conclusion: pain.002 – Pain is avoidable

The pain.002 is a powerful but complex tool. In an ideal world, it provides reliable feedback on all payments – in reality, its usefulness depends on many factors:

• Implementation by the bank
• Channel (EBICS, API, web portal)
• Payment type (SCT vs. SCT Inst)
• VoP utilisation and processing depth in the company

Corporates that are preparing for VoP or real-time payments should plan for the processing of pain.002 at an early stage so as not to experience any “pain” in accounting.

Do you have questions about integrating pain.002 into your customs processes?
Our experts at CPG Finance Systems will be happy to support you in analysing, mapping, testing and automating your SEPA interfaces and look forward to hearing from you.