What Is pain.002? The SEPA Payment Status Report

When you send a bulk payment or a single transfer in SEPA, your accounting software or banking channel produces a pain.001 message in the background — this is the "make these payments" instruction you give to your bank. But sending the instruction is only half the job: you also need to know whether the bank has accepted it, whether it has taken it into processing, or whether it has rejected it. This feedback comes with the pain.002 message. This page explains what pain.002 is, which status codes it carries, where the reason is hidden in the case of a rejection, and what you should do in the next step.

What is pain.002?

The official ISO 20022 name of the pain.002 message is CustomerPaymentStatusReport. "pain" is the abbreviation of the payment initiation group in the ISO 20022 message family; the same family also contains pain.001, which carries the payment instruction, and pain.008, which is the direct debit instruction. pain.002 is the status report member of this family: a bank's structured reply to a payment initiation instruction sent to it.

That is, pain.002 is not a money movement; it is a notification. It conveys, in a machine-readable format, the replies a bank can give such as "I received your instruction", "it complies with the format rules, I accepted it", "I took it into processing" or "I rejected it for such-and-such a reason". In corporate and bulk payment flows this message is critical, because it lets you track — automatically rather than by hand — which line of a bulk file with hundreds of lines went through and which got stuck.

The pain.001 → pain.002 flow

The basic flow is like a one-way question and answer:

• Customer → Bank: The payment instruction (pain.001) is sent. "Make these transfers."
• Bank → Customer: The status report (pain.002) comes back. "Your instruction is in such-and-such a state."

As the processing of the instruction progresses, the bank can send more than one pain.002 too: first "received/accepted", then "taken into processing", finally "settlement completed", and so on. Each new pain.002 reports the current state of the transaction.

A frequently confused point here: do not confuse pain.002 with pacs.008. pain.002 is the status report between the customer and their bank (customer-to-bank). pacs.008, on the other hand, is the bank-to-bank SEPA credit transfer message — the format used when your instruction is passed by your bank to the counterparty bank. pacs messages (pacs.008 the transfer, pacs.002 the bank-to-bank status, pacs.004 the return) flow between banks in the background; you normally see only the pain.002 that comes to you. In short: pain = you ↔ your bank, pacs = bank-to-bank.

pain.002 status codes: two levels

pain.002 reports the status at two separate levels:

• Group status — GrpSts (Group Status): A single summary status for the whole instruction. For example, if the whole of a bulk file was accepted, ACCP appears at the group level.
• Transaction status — TxSts (Transaction Status): A separate status for each payment line in the file. In a bulk file some lines can go through and some can be rejected; this distinction appears at the transaction level.

The frequently used status codes and their meanings are in the table below. Keep the most critical distinction in mind: the states other than RJCT are not an error — most are normal intermediate stages on the path to success.

The code set comes from the ISO 20022 status codes set, and the subset shown can vary by bank/rulebook version. Always assess the final result of a transaction together with the explanation in your bank's channel.

I see RJCT: where is the reason for the rejection?

This is the point where users get stuck the most. The RJCT status code only tells you "rejected"; it does not say why it was rejected. The real reason for the rejection is carried within pain.002 in a separate field — StatusReasonInformation — as a reason code. That is, when a transaction is rejected, two pieces of information come together: status = RJCT, reason = for example AC01.

Frequently seen reason codes:

• AC01 — the account number / IBAN is wrong or formally invalid.
• AC04 — the account is closed.
• AM04 — insufficient funds.
• MD01 — there is no valid authorisation (mandate) — frequently seen in direct debit.
• RR04 — rejection for regulatory reasons.

Behind the "payment rejected" explanation you see in your bank's channel there is usually one of these codes. To enter the status or reason code you have and see its meaning and the step you need to take, you can use the tool below.

Who uses pain.002?

pain.002 comes to the fore mostly in corporate and bulk payment scenarios: payroll payments, supplier payments, accounting/ERP integrations. An individual user making a single transfer from their bank's online banking does not see pain.002 with the naked eye — the bank processes this message in the background and shows you a plain "your transaction was received / rejected" screen. But on the machine side, the structure that turns is mostly this. If you want to check the formal validity of your pain.001 file before sending it, our pain.001 generator and validator tool helps, and for the whole ISO 20022 message family our ISO 20022 messages page helps.

Summary and warning

pain.002 is the reply message reporting the state, at the bank, of the pain.001 payment instruction you sent; it carries the status at the group (GrpSts) and transaction (TxSts) levels and follows the RCVD → ACCP → ACSP → ACSC path to success. The states other than RJCT are not an error; when RJCT comes, the real reason is hidden in a separate reason code. The information on this page is for informational purposes: the binding structure of ISO 20022 messages is defined by the ISO 20022 Registration Authority, and their SEPA-specific uses in the European Payments Council rulebooks, and it is updated over time. For a critical payment, always confirm the final state of the transaction with your bank.