pain.002

pain.002 is the ISO 20022 message called the Customer Payment Status Report. A bank sends it to a customer, usually a business, to report on the status of payment instructions the customer has submitted, most often in a pain.001 credit transfer file or a pain.008 direct debit file. A pain.002 can confirm that a file passed the bank's checks, list payments that were rejected and explain why, or report that some payments are still pending. It allows companies to find and fix problems quickly instead of waiting for a bank statement or a phone call.

The message belongs to the "pain" business area of ISO 20022, which covers exchanges between customers and their banks. It is the customer-facing counterpart of pacs.002, which banks and payment systems exchange between themselves. Together with camt statements and notifications, it forms the feedback loop of corporate payment processing.

A pain.002 can report status at three levels, mirroring the structure of the original file:

• Group level. The status of the whole message, for example accepted after technical validation, or rejected because the file failed schema checks or was a duplicate.
• Payment information level. The status of a batch within the file, such as all payments from one account with one execution date.
• Transaction level. The status of each individual payment, identified by references from the original file such as the end-to-end identification.

Banks differ in which levels they report and when. Some send one pain.002 after technical validation and another after the payments are executed or rejected later in processing, while others report only rejections.

Status values are taken from an external ISO 20022 code list. Common examples include ACTC (accepted after technical validation), ACCP (accepted after customer profile checks), ACSP (accepted, settlement in process), ACSC (accepted, settlement completed), PART (partially accepted, when some payments in a group were rejected), PDNG (pending) and RJCT (rejected). Rejected items carry a reason code, such as AC01 for an incorrect account number, AC04 for a closed account, AM04 for insufficient funds, FF01 for an invalid file format or DU01 for a duplicate message identification, with optional free-text detail.

Each bank's implementation guide sets out which statuses and reasons it uses, so companies must map them into their own systems carefully.

Treasury and accounts payable teams use pain.002 reports to:

• Confirm receipt. Check that every payment file reached the bank and passed validation, avoiding silent failures.
• Correct rejections. Identify payments that failed because of wrong account details or missing data and resubmit them after correction.
• Update records. Mark payments as sent or failed in the enterprise resource planning or accounts payable system, so that suppliers can be told accurately when to expect funds.
• Support reconciliation. Combine status reports with camt.054 notifications and camt.053 statements to complete payment reconciliation.

For direct debit collections, such as SEPA Direct Debit, pain.002 messages report collections rejected before settlement, for example because a mandate reference was invalid. Collections returned after settlement are generally reported through other messages and statements.

Payment service providers that send files on behalf of many clients use pain.002 in the same way, passing statuses back to their own customers through dashboards or APIs. Where a provider aggregates payments into one file, it must map each transaction-level status back to the right client, which makes accurate references essential.

Businesses increasingly expect the same visibility for bank payments that they have for parcel deliveries. pain.002 is one building block of that visibility, alongside tracking services in cross-border payments and real-time status reporting through bank APIs. A clear transaction status at each stage and a reliable payment confirmation help reduce customer enquiries, failed or duplicate payments and late payment penalties.

Not all banks send pain.002 for every stage, and the meaning of statuses such as "accepted" can vary: acceptance after technical validation does not mean the payment has reached the beneficiary. Companies should agree with each bank which reports will be sent, what each status means and how quickly reports will arrive. They should also make sure their systems process pain.002 files automatically and alert staff to rejections, since a status report that no one reads gives little protection. Monitoring the absence of an expected report is as important as reading the reports that arrive, because a missing pain.002 may be the first sign that a file was never received.