pain.002 — Customer Payment Status Report
Reports the status of a previously sent initiation message — usually a pain.001 — back to the party that sent it. It can accept or reject a whole file, a payment block, or individual transactions, and carries coded reasons explaining negative outcomes. It reports; it never moves money.
DIRECTION: Sent by the debtor agent (or a forwarding agent) back to the initiating party that submitted the original pain.001.
WHO IS INVOLVED
- Debtor agentValidates the received pain.001 and reports acceptance, rejection, or intermediate statuses at file, block, or transaction level.
- Initiating partyConsumes the status report, updates its own records, and repairs and resubmits rejected payments where appropriate.
- Forwarding agentWhere present, relays status reports between the executing bank and the initiating party.
KEY FIELDS
This is a curated teaching subset — the full pain.002 message definition contains many more elements, including original transaction references and charges information. Requirement flags summarise the single context named on each field; check the official ISO 20022 message definition and the reporting profile your bank actually implements.
| FIELD | NAME | PRESENCE | WHAT IT MEANS |
|---|---|---|---|
GrpHdr/MsgId | Message identification | MANDATORYBase ISO 20022 message definition | A unique reference for this status report itself, assigned by the bank sending it.Distinct from the original message's identification — a single pain.001 can generate several pain.002 messages over its life as statuses evolve. |
GrpHdr/CreDtTm | Creation date and time | MANDATORYBase ISO 20022 message definition | When this status report was created. Ordering matters when several reports about the same file arrive.⚠ Processing status reports out of order can overwrite a final status with an earlier interim one. |
OrgnlGrpInfAndSts/OrgnlMsgId | Original message identification | MANDATORYBase ISO 20022 message definition | The MsgId of the pain.001 this report is about — the pointer back to what is being answered.⚠ If your systems do not store outbound MsgIds, incoming status reports cannot be matched automatically and end up in manual queues. |
OrgnlGrpInfAndSts/OrgnlMsgNmId | Original message name identification | MANDATORYBase ISO 20022 message definition | The message type being answered, for example pain.001, including its version — so the receiver knows exactly which definition the original followed. |
OrgnlGrpInfAndSts/GrpSts | Group status | OPTIONALBase ISO 20022 message definition | A status for the original message as a whole — for example accepted, rejected, or partially accepted — before drilling into individual transactions.A partial status at group level means you must read the transaction level to know which payments survived.⚠ Treating a group-level acceptance as final for every transaction. Individual payments can still fail later in processing. |
OrgnlPmtInfAndSts/OrgnlPmtInfId | Original payment information identification | CONDITIONALBase ISO 20022 message definition — required within the payment-block level when that level is reported | Identifies which payment block (PmtInf) of the original pain.001 this part of the report refers to.Rejections at this level typically mean a block-wide problem — a bad debtor account or an invalid requested execution date — rather than a single bad payment. |
OrgnlPmtInfAndSts/TxInfAndSts/OrgnlEndToEndId | Original end-to-end identification | CONDITIONALBase ISO 20022 message definition — used when individual transactions are reported | The EndToEndId of the specific payment being reported on, so the initiating party knows exactly which payment a status belongs to.⚠ If the original EndToEndIds were not unique within the file, a transaction-level status may be ambiguous. |
OrgnlPmtInfAndSts/TxInfAndSts/TxSts | Transaction status | CONDITIONALBase ISO 20022 message definition — every practical usage guideline requires a status on each reported transaction | The status code for one payment. Common values from the ISO external code set include ACCP (accepted after profile checks), ACSP (accepted, settlement in process), ACSC (accepted, settlement completed), PDNG (pending), and RJCT (rejected).Which statuses a bank actually sends varies a lot: some report only rejections, others report the full positive lifecycle. Confirm the bank's reporting policy rather than inferring from silence.⚠ Treating ACSP as 'done'. Settlement in process is not settlement completed. |
OrgnlPmtInfAndSts/TxInfAndSts/StsRsnInf/Rsn/Cd | Status reason code | CONDITIONALBase ISO 20022 message definition — expected whenever the status is negative | A coded reason from the ISO external code sets explaining a rejection or pending status — for example an account problem or a regulatory hold.Reason codes drive automated repair routing. A payment engine that reads only the status and ignores the reason forces every reject into one manual queue.⚠ Some banks put the substance in a narrative element with a generic code. Capture both code and narrative in your workflow. |
COMMON ERRORS
- Treating no news as good news — assuming a payment succeeded because no pain.002 arrived.Consequence: Failed payrolls or supplier runs are discovered days later by the beneficiary chasing funds, rather than the same day from the status feed.Avoid it: Agree the bank's reporting policy explicitly, monitor for expected acknowledgements per file, and alert on missing ones — silence should raise a flag, not comfort.
- Not correlating status reports back to original identifiers (OrgnlMsgId, OrgnlPmtInfId, OrgnlEndToEndId).Consequence: Statuses land in a manual queue, and rejected payments are repaired against the wrong transaction or missed entirely.Avoid it: Persist every outbound identifier at send time and build matching on the original references, not on amounts and dates.
- Mishandling partial acceptance — reading the group status and stopping there.Consequence: The accepted part of a file is processed while the rejected transactions are silently lost, because nobody read the transaction-level detail.Avoid it: Whenever the group status indicates partial processing, iterate every transaction-level status and route each rejected item to repair.
- Ignoring status reason codes and acting on the status alone.Consequence: A payment rejected for a fixable data issue is retried unchanged and rejects again; a payment held for compliance reasons is retried when it should not be.Avoid it: Map the ISO external status reason codes into distinct repair, retry, and escalate workflows, and include the narrative text for investigators.
USAGE CONTEXTS
- SEPA customer status reportingIn the SEPA schemes, pain.002 is the customer-to-PSP status leg defined in the EPC implementation guidelines: the debtor agent uses it to tell the initiating party whether instructions were accepted or rejected before or during scheme processing. Interbank rejects travel separately, as pacs.002 between PSPs.
- Cross-border relay (CBPR+)CBPR+ defines pain.002 usage between financial institutions for the relay scenario, reporting the status of a forwarded pain.001 across the Swift network.
- Bank-proprietary reporting policiesOutside scheme rules, banks decide how much of the status lifecycle to report. Some send pain.002 only for rejections; others send positive interim and final statuses. Never treat the absence of a pain.002 as confirmation of success.
SEE IT IN A PLAYABLE FLOW
Sources for this reference4
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pain.002 CustomerPaymentStatusReport message definition
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Official requirement
ISO 20022 External code sets ↗ — ISO 20022 Registration Authority · Payment transaction status and status reason code sets
Updated quarterly (end of February, May, August, and November) in XLSX, XSD, and JSON formats; always check the latest published version for valid codes.
- Scheme-specific rule2025 version 1.0 (EPC115-06)
SEPA Credit Transfer Inter-PSP Implementation Guidelines ↗ — European Payments Council · Customer-to-PSP implementation guidelines for SEPA credit transfers
Based on version 1.1 of the 2025 SCT rulebook. Companion Customer-to-PSP guidelines cover the pain.001 initiation leg.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: The key-field list is a curated subset and the status lifecycle shown (ACCP, ACSP, ACSC, PDNG, RJCT) names only the most commonly encountered codes from a longer external code set. Bank reporting policies vary more than any single description can capture.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.