PAIN.002 Explained: A Complete Guide to the ISO 20022 Customer Payment Status Report

Introduction — Picking Up Where PAIN.001 Left Off

It is 8:47 AM on a Tuesday. ABC Manufacturing Ltd’s treasury manager has just hit send on their monthly supplier payment run — a PAIN.001 file carrying five payments totalling €98,000, submitted to Standard Chartered. Five European suppliers are waiting. The file is gone.

And now the treasury system is waiting too.

The PAIN.001 Complete Guide covers how that file was built — every field, every block, every rule. This article picks up the moment it arrives at Standard Chartered’s payment gateway.

The bank now has to process the instruction. ABC Manufacturing needs to know what happens next. That is where PAIN.002 comes in.

PAIN.002 — formally the CustomerPaymentStatusReport — is the bank’s structured reply. It does not move money. It reports on what happened, or what is happening, to the instruction that was submitted. For every outcome in the payment lifecycle — accepted, rejected, in progress, partial — there is a PAIN.002 carrying that information in machine-readable ISO 20022 format.

[ VISUAL 1: PAIN.002 position in the payment lifecycle — PAIN.001 flows right from corporate to bank, PAIN.002 returns left as the status report ]

PAIN.002 is the only PAIN message that flows in reverse — from the Debtor Agent back to the corporate.

What Existed Before PAIN.002

In the MT world, there was no equivalent message. That sentence is worth sitting with. It explains everything that follows.

When a corporate sent an MT101 or MT103, status feedback depended entirely on the bank and what had been bilaterally agreed. Some banks sent nothing until the MT940 end-of-day statement. If something went wrong mid-journey, the bank might send a free-format MT199 or MT299 — plain text, no standard reason codes, no structure, no machine-readability.

Format, timing, and content varied bank by bank. For treasury teams, monitoring payment status meant calling your relationship manager or waiting for the overnight statement.

ISO 20022 changed this by introducing a standardised, structured, machine-readable status lifecycle. PAIN.002 formalises what was previously an afterthought.

That gap between the MT world and ISO 20022 is precisely why PAIN.002 is the most overlooked message in most implementations today. There was nothing to map it from. So it was frequently skipped.

What Is PAIN.002?

PAIN.002 — formally CustomerPaymentStatusReport, XML message name pain.002.001.14 — is the ISO 20022 message sent by the Debtor Agent back to the corporate or initiating party.

In ABC Manufacturing’s story: Standard Chartered received the PAIN.001. Standard Chartered is the Debtor Agent. Every status message that comes back to ABC Manufacturing will travel inside a PAIN.002 generated by Standard Chartered. Not the Creditor Agent. Not any intermediary. Not a clearing system. Standard Chartered alone is responsible.

Three things make PAIN.002 unique:

• It flows in reverse. Every other PAIN message goes from corporate to bank. PAIN.002 is the only one that comes back.
• It is a reporting message, not an execution message. It does not move funds. It tells you the status of the instruction that did.
• It reports at three levels simultaneously. A single PAIN.002 can carry status at the file level, the payment block level, and the individual transaction level — all in one message.

PAIN.002 vs PACS.002 — The Distinction You Must Know

This is the most common source of confusion in the payments domain. Both messages report status. Both can carry RJCT. But they operate in completely different layers of the payment chain.

Dimension	PAIN.002	PACS.002
Full name	CustomerPaymentStatusReport	FIToFIPaymentStatusReport
Space	Customer-to-bank (C2B)	Bank-to-bank (interbank)
Sender	Debtor Agent → Corporate	One bank → another bank or clearing system
References back to	PAIN.001 MsgId	PACS.008 MsgId
Audience	Corporate treasury, ERP, TMS	Payment engine, SWIFT participant
Connection	Stands alone as C2B message	Can be converted into PAIN.002 by the Debtor Agent

The critical insight: these two messages are sequential, not alternative. A PACS.002 rejection in the interbank network does not stay in the interbank world. The Debtor Agent receives it, converts it, and sends it upstream as a PAIN.002 RJCT to the corporate. Understanding this conversion is what separates surface-level knowledge from a complete understanding.

How PAIN.002 Is Born — The Debtor Agent as Generator

The Debtor Agent — and only the Debtor Agent — generates PAIN.002. If any other agent in your implementation is generating a PAIN.002, the design is wrong. That agent should be generating a PACS.002. This is the most commonly blurred line I have seen across implementation teams. It took me longer than I would like to admit to get it perfectly clear in my own head the first time.

[ VISUAL 2: How PAIN.002 is born at Standard Chartered — six processing steps from file receipt to ACSC, with PACS.002 conversion path ]

Each processing stage at the Debtor Agent can independently trigger a PAIN.002 back to the corporate.

The Six-Step Process

1. Technical validation. Standard Chartered’s gateway receives the PAIN.001. It validates the XML: well-formed? Schema-compliant? All mandatory fields present? This takes seconds.
2. First PAIN.002 fires: ACCP. If format and syntax are valid, Standard Chartered immediately sends PAIN.002 with status ACCP (Accepted Customer Profile). Translation: “We received your file. It is technically correct. Processing begins.” This fires before any business logic runs.
3. Business and compliance validation. AML screening, sanctions checks, duplicate detection, beneficiary account validation, balance check, value date validation. This takes longer — sometimes minutes, sometimes hours.
4. Second PAIN.002: ACSP or RJCT. If business validation passes, Standard Chartered sends ACSP (Accepted Settlement in Progress). If something fails — say, Txn 4 has insufficient funds — it sends RJCT with an ISO reason code.
5. Payment execution. For accepted transactions, Standard Chartered debits ABC Manufacturing’s account and forwards a PACS.008 into the interbank network toward Deutsche Bank Frankfurt.
6. Final PAIN.002: ACSC. Once settlement is confirmed, Standard Chartered sends ACSC (Accepted Settlement Completed). The payment is done.

  In practice, RJCT is the only mandatory PAIN.002 under CBPR+. Positive statuses — ACCP, ACSP, ACSC — are sent only where bilaterally agreed. Most banks send 1–2 messages per payment. The six-step model above is the full theoretical picture.

When the Bank Does NOT Send PAIN.002

Some banks send all six stages. Others send only RJCT. Some deliver final confirmation via CAMT.054 instead of ACSC. The governing document is always the bilateral service agreement — agreed during onboarding.

One absolute rule: if a payment is rejected at any point — at Standard Chartered’s own processing or as a result of an interbank failure — a PAIN.002 RJCT must be sent. No exceptions under CBPR+.

The Four Building Blocks of PAIN.002

[ VISUAL 3: The four building blocks — Block A and B mandatory [1..1], Block C optional and repeatable [0..*], Block D nested inside Block C ]

Block D is where the real reconciliation work happens — the most granular and operationally critical level.

Block A — Group Header  <GrpHdr>  [1..1]

Mandatory. Appears exactly once. Identifies the PAIN.002 message itself — not the original payment instruction. Think of it as Standard Chartered’s envelope for this status report.

Field	XML Tag	Card.	Description
Message Identification	<MsgId>	[1..1]	Unique ID of this PAIN.002. Generated by Standard Chartered. Max 35 chars. NOT the PAIN.001 MsgId.
Creation Date Time	<CreDtTm>	[1..1]	When Standard Chartered created this message. ISO 8601 format.
Initiating Party	<InitgPty>	[0..1]	The party that initiates the status message — Always Debtor Agent of PAIN.001.
Forwarding Agent	<FwdgAgt>	[0..1]	Present when PAIN.002 is relayed via a concentrating bank. Used in CBPR+ relay scenarios.
Debtor Agent	<DbtrAgt>	[0..1]	Standard Chartered — the bank generating this PAIN.002.
Creditor Agent	<CdtrAgt>	[0..1]	Deutsche Bank Frankfurt — the beneficiary bank. Included where contextually relevant.

The MsgId in Group Header is Standard Chartered’s own reference for this PAIN.002. New, unique — not the one ABC Manufacturing assigned in the PAIN.001.

Block B — Original Group Information and Status  <OrgnlGrpInfAndSts>  [1..1]

Mandatory. Appears exactly once. Primary link between the PAIN.002 and the original PAIN.001. Reports status at the file or group level. OrgnlMsgId is the first reconciliation key Standard Chartered sends back.

Field	XML Tag	Card.	Description
Original Message Identification	<OrgnlMsgId>	[1..1]	The MsgId from the original PAIN.001. For ABC Manufacturing: ABC-BATCH-20241015-001. Primary file-level reconciliation key.
Original Message Name ID	<OrgnlMsgNmId>	[1..1]	The original message type — e.g. pain.001.001.14.
Original Creation Date Time	<OrgnlCreDtTm>	[0..1]	Timestamp of the original PAIN.001. Useful for disambiguation.
Original Number of Transactions	<OrgnlNbOfTxs>	[0..1]	Total transactions in the original batch. For ABC Manufacturing: 5.
Original Control Sum	<OrgnlCtrlSum>	[0..1]	Total instructed amount. For ABC Manufacturing: 98000.
Group Status	<GrpSts>	[0..1]	Status at file level. Values: ACCP, ACSP, ACSC, RJCT, PART, PDNG.
Status Reason Information	<StsRsnInf>	[0..*]	Reason for the status. Mandatory when GrpSts = RJCT.
Number of Transactions Per Status	<NbOfTxsPerSts>	[0..*]	Breakdown of transaction counts by status code. Populated only when GrpSts = PART.

ISO Rule: NbOfTxsPerSts should only be present when Group Status is PART. If the entire batch is accepted or rejected uniformly, this field is not needed.

Block C — Original Payment Information and Status  <OrgnlPmtInfAndSts>  [0..*]

Optional and repeatable. Reports status at the Payment Information block level — one entry per <PmtInf> block in the original PAIN.001. In ABC Manufacturing’s batch there was one PmtInf block — PMTINF-EUR-001 — so there will be one Block C instance in the PAIN.002 response.

Field	XML Tag	Card.	Description
Original Payment Information ID	<OrgnlPmtInfId>	[1..1]	The PmtInfId from the original PAIN.001. For ABC Manufacturing: PMTINF-EUR-001.
Original Number of Transactions	<OrgnlNbOfTxs>	[0..1]	Number of transactions in this payment block.
Original Control Sum	<OrgnlCtrlSum>	[0..1]	Total amount for this block.
Payment Information Status	<PmtInfSts>	[0..1]	Status code at payment block level. Same code set as GrpSts.
Status Reason Information	<StsRsnInf>	[0..*]	Reason for status. Mandatory when PmtInfSts = RJCT.
Number of Transactions Per Status	<NbOfTxsPerSts>	[0..*]	Breakdown by status within this block. Used when PmtInfSts = PART.
Transaction Information and Status	<TxInfAndSts>	[0..*]	Nested transaction-level status records — Block D.

Block D — Transaction Information and Status  <TxInfAndSts>  [0..*]

The most operationally critical block. Reports status at individual transaction level. This is where ABC Manufacturing’s treasury system and ERP do the real reconciliation work — matching each incoming status entry back to a specific payment in the original PAIN.001.

Field	XML Tag	Card.	Description
Status Identification	<StsId>	[0..1]	Bank-assigned ID for this status entry. Optional.
Original Instruction Identification	<OrgnlInstrId>	[0..1]	Maps to InstrId in the original PAIN.001. Bank-to-bank reference.
★ Original End To End Identification	<OrgnlEndToEndId>	[0..1]	Maps to EndToEndId from the PAIN.001. ABC Manufacturing’s own reference, echoed back. Primary reconciliation field at transaction level.
Original UETR	<OrgnlUETR>	[0..1]	Unique End-to-End Transaction Reference — UUID format. Connects PAIN.001, PACS.008, PACS.002, and PAIN.002.
Transaction Status	<TxSts>	[0..1]	Status code at individual transaction level.
Status Reason Information	<StsRsnInf>	[0..*]	Mandatory when TxSts = RJCT. Contains Reason Code and Additional Information.
Charges Information	<ChrgsInf>	[0..*]	Details of any charges applied. Informational.
Tracker Data	<TrckrData>	[0..1]	SWIFT GPI tracker data. Used in CBPR+ scenarios.
Acceptance Date Time	<AccptncDtTm>	[0..1]	When Standard Chartered accepted this transaction for processing.
Account Servicer Reference	<AcctSvcrRef>	[0..1]	Standard Chartered’s internal reference. Essential for investigations.
Clearing System Reference	<ClrSysRef>	[0..1]	Reference from the clearing system (e.g. STEP2, TARGET2).
Original Transaction Reference	<OrgnlTxRef>	[0..1]	Mirrored key transaction data from the original PAIN.001. Allows reconciliation without retrieving the original file.

OrgnlTxRef is particularly valuable for automated reconciliation. When Standard Chartered rejects a transaction, ABC Manufacturing’s system can read the full payment details directly from the PAIN.002 — without retrieving the original PAIN.001 file. In high-volume batch environments, this saves significant processing time.

Fields at a Glance

Section	Field Name	XML Tag	Cardinality	Data Type	XML Path	Description
CUSTOMER PAYMENT STATUS REPORT	Group Header	GrpHdr	[1..1]	Parent	/Document/CstmrPmtStsRpt/GrpHdr	Identifies the PAIN.002 message itself
Group Header	Message Identification	MsgId	[1..1]	Max35Text	/GrpHdr/MsgId	Unique ID of this PAIN.002. Generated by Debtor Agent. NOT the PAIN.001 MsgId.
Group Header	Creation Date Time	CreDtTm	[1..1]	ISODateTime	/GrpHdr/CreDtTm	When Debtor Agent created this message. ISO 8601 format.
Group Header	Initiating Party	InitgPty	[0..1]	PartyIdentification	/GrpHdr/InitgPty	The party that initiates the status message — Always Debtor Agent of PAIN.001.
Group Header	Forwarding Agent	FwdgAgt	[0..1]	AgentIdentification	/GrpHdr/FwdgAgt	Present when PAIN.002 is relayed via a concentrating bank. Used in CBPR+ relay scenarios.
Group Header	Debtor Agent	DbtrAgt	[0..1]	AgentIdentification	/GrpHdr/DbtrAgt	The bank generating this PAIN.002.
Group Header	Creditor Agent	CdtrAgt	[0..1]	AgentIdentification	/GrpHdr/CdtrrAgt	The beneficiary bank. Included where contextually relevant.
CUSTOMER PAYMENT STATUS REPORT	Original Group Information And Status	OrgnlGrpInfAndSts	[1..1]	Parent	/Document/CstmrPmtStsRpt/OrgnlGrpInfAndSts	Primary link between the PAIN.002 and the original PAIN.001. Reports status at the file or group level.
Original Group Information And Status	Original Message Identification	OrgnlMsgId	[1..1]	Max35Text	/OrgnlGrpInfAndSts/OrgnlMsgId	The MsgId from the original PAIN.001. Primary file-level reconciliation key.
Original Group Information And Status	Original Message Name Identification	OrgnlMsgNmId	[1..1]	Max35Text	/OrgnlGrpInfAndSts/OrgnlMsgNmId	The original message type — e.g. pain.001.001.14.
Original Group Information And Status	Original Creation Date Time	OrgnlCreDtTm	[0..1]	ISODateTime	/OrgnlGrpInfAndSts/OrgnlCreDtTm	Timestamp of the original PAIN.001. Useful for disambiguation.
Original Group Information And Status	Original Number Of Transactions	OrgnlNbOfTxs	[0..1]	Max15NumericText	/OrgnlGrpInfAndSts/OrgnlNbOfTxs	Total transactions in the original pain.001.
Original Group Information And Status	Original Control Sum	OrgnlCtrlSum	[0..1]	DecimalNumber	/OrgnlGrpInfAndSts/OrgnlCtrlSum	Total instructed amount in pain.001.
Original Group Information And Status	Group Status	GrpSts	[0..1]	CODE	/OrgnlGrpInfAndSts/GrpSts	Status at file level. Values: ACCP, ACSP, ACSC, RJCT, PART, PDNG. ISO Code Set “ExternalPaymentGroupStatus1Code”
Original Group Information And Status	Status Reason Information	StsRsnInf	[0..*]	Parent	/OrgnlGrpInfAndSts/StsRsnInf	Reason for the status. Mandatory when GrpSts = RJCT.
Original Group Information And Status	Originator	Orgtr	[0..1]	PartyIdentification	/OrgnlGrpInfAndSts/StsRsnInf/Orgtr	Party that issues the status
Original Group Information And Status	Reason	Reason	[0..1]	CODE	/OrgnlGrpInfAndSts/StsRsnInf/Rsn	Status Reason in ISO Coded form “ExternalStatusReason1Code”
Original Group Information And Status	Additional Information	AddtlInf	[0..*]	Max105Text	/OrgnlGrpInfAndSts/StsRsnInf/AddtlInf	Additional Information in Plain Format. Mandatory for “NARR” Code
Original Group Information And Status	Number Of Transactions Per Status	NbOfTxsPerSts	[0..*]	Parent	/OrgnlGrpInfAndSts/NbOfTxsPerSts	Breakdown of transaction counts by status code. Populated only when GrpSts = PART.
CUSTOMER PAYMENT STATUS REPORT	Original Payment Information And Status	OrgnlPmtInfAndSts	[0..*]	Parent	/Document/CstmrPmtStsRpt/OrgnlPmtInfAndSts	Reports status at the Payment Information block level
Original Payment Information And Status	Original Payment Information Identification	OrgnlPmtInfId	[1..1]	Max35Text	/OrgnlPmtInfAndSts/OrgnlPmtInfId	The PmtInfId from the original PAIN.001.
Original Payment Information And Status	Original Number Of Transactions	OrgnlNbOfTxs	[0..1]	Max15NumericText	/OrgnlPmtInfAndSts/OrgnlNbOfTxs	Number of transactions in this payment info block.
Original Payment Information And Status	Original Control Sum	OrgnlCtrlSum	[0..1]	DecimalNumber	/OrgnlPmtInfAndSts/OrgnlCtrlSum	Total amount for this block.
Original Payment Information And Status	Payment Information Status	PmtInfSts	[0..1]	CODE	/OrgnlPmtInfAndSts/PmtInfSts	Status code at payment block level. Same code set as GrpSts.
Original Payment Information And Status	Status Reason Information	StsRsnInf	[0..*]	Parent	/OrgnlPmtInfAndSts/StsRsnInf	Reason for status. Mandatory when PmtInfSts = RJCT.
Original Payment Information And Status	Originator	Orgtr	[0..1]	PartyIdentification	/OrgnlPmtInfAndSts/StsRsnInf/Orgtr	Party that issues the status
Original Payment Information And Status	Reason	Reason	[0..1]	CODE	/OrgnlPmtInfAndSts/StsRsnInf/Rsn	Status Reason in ISO Coded form “ExternalStatusReason1Code”
Original Payment Information And Status	Additional Information	AddtlInf	[0..*]	Max105Text	/OrgnlPmtInfAndSts/StsRsnInf/AddtlInf	Additional Information in Plain Format. Mandatory for “NARR” Code
Original Payment Information And Status	Number Of Transactions Per Status	NbOfTxsPerSts	[0..*]	Parent	/OrgnlPmtInfAndSts/NbOfTxsPerSts	Breakdown by status within this block. Used when PmtInfSts = PART.
Original Payment Information And Status	Transaction Information And Status	TxInfAndSts	[0..*]	Parent	/OrgnlPmtInfAndSts/TxInfAndSts	Reports status at individual transaction level.
Transaction Information And Status	Status Identification	StsId	[0..1]	Max35Text	/TxInfAndSts/StsId	Bank-assigned ID for this status entry. Optional.
Transaction Information And Status	Original Instruction Identification	OrgnlInstrId	[0..1]	Max35Text	/TxInfAndSts/OrgnlInstrId	Maps to InstrId in the original PAIN.001. Bank-to-bank reference.
Transaction Information And Status	Original End To End Identification	OrgnlEndToEndId	[0..1]	Max35Text	/TxInfAndSts/OrgnlEndToEndId	Maps to EndToEndId from the PAIN.001. Corporate’s own reference, echoed back. Primary reconciliation field at transaction level.
Transaction Information And Status	Original UETR	OrgnlUETR	[0..1]	UUID	/TxInfAndSts/OrgnlUETR	Unique End-to-End Transaction Reference — UUID format. Connects PAIN.001, PACS.008, PACS.002, and PAIN.002.
Transaction Information And Status	Transaction Status	TxSts	[0..1]	CODE	/TxInfAndSts/TxSts	Status code at individual transaction level. ISO Code Set “ExternalPaymentTransactionStatus1Code”
Transaction Information And Status	Status Reason Information	StsRsnInf	[0..*]	Parent	/TxInfAndSts/StsRsnInf	Mandatory when TxSts = RJCT. Contains Reason Code and Additional Information.
Transaction Information And Status	Originator	Orgtr	[0..1]	PartyIdentification	/TxInfAndSts/StsRsnInf/Orgtr	Party that issues the status
Transaction Information And Status	Reason	Reason	[0..1]	CODE	/TxInfAndSts/StsRsnInf/Rsn	Status Reason in ISO Coded form “ExternalStatusReason1Code”
Transaction Information And Status	Additional Information	AddtlInf	[0..*]	Max105Text	/TxInfAndSts/StsRsnInf/AddtlInf	Additional Information in Plain Format. Mandatory for “NARR” Code
Transaction Information And Status	Charges Information	ChrgsInf	[0..*]	Parent	/TxInfAndSts/ChrgsInf	Details of any charges applied. Informational.
Transaction Information And Status	Tracker Data	TrckrData	[0..1]	Parent	/TxInfAndSts/TrckrData	SWIFT GPI tracker data. Used in CBPR+ scenarios.
Transaction Information And Status	Acceptance Date Time	AccptncDtTm	[0..1]	ISODateTime	/TxInfAndSts/AccptncDtTm	When Debtor Agent accepted this transaction for processing.
Transaction Information And Status	Account Servicer Reference	AcctSvcrRef	[0..1]	Max35Text	/TxInfAndSts/AcctSvcrRef	Debtor Agent’s internal reference. Essential for investigations.
Transaction Information And Status	Clearing System Reference	ClrSysRef	[0..1]	Max35Text	/TxInfAndSts/ClrSysRef	Reference from the clearing system
Transaction Information And Status	Original Transaction Reference	OrgnlTxRef	[0..1]	Parent	/TxInfAndSts/OrgnlTxRef	Mirrored key transaction data from the original PAIN.001. Allows reconciliation without retrieving the original file.
Transaction Information And Status	Supplementary Data	SplmtryData	[0..1]	Envelope	/TxInfAndSts/SplmtryData	Additional information that cannot be captured in the structured elements and/or any other specific block.
CUSTOMER PAYMENT STATUS REPORT	Supplementary Data	SplmtryData	[0..1]	Envelope	/Document/CstmrPmtStsRpt/SplmtryData	Additional information that cannot be captured in the structured elements and/or any other specific block.

Status Codes — The Heart of PAIN.002

Every decision ABC Manufacturing’s treasury system makes — re-submit, release a supplier hold, escalate, close the batch — is driven by the status code “ExternalPaymentTransactionStatus1Code” inside the PAIN.002. Understanding each code precisely is not optional. It is operational.

[ VISUAL 4: Status code lifecycle flow — ACCP → ACSP → ACSC happy path, PDNG branch, RJCT exit at any stage, PART at group level ]

ACSP is not the finish line — a RJCT can still arrive days later from the interbank network.

The Status Code Table

Code	Full Name	What It Means	When It Appears
ACCC	AcceptedSettlementCompleted	Settlement on the creditor’s account has been completed.	Sent by Creditor Agent to confirm the settlement on the creditor’s account
ACCP	AcceptedCustomerProfile	Preceding check of technical validation was successful. Customer profile check was also successful.	Sent by any Agent in the payment chain to confirm acceptance prior to technical validation.
ACFC	AcceptedFundsChecked	Preceding check of technical validation and customer profile was successful and an automatic funds check was positive.	Sent by any Agent in the payment chain to confirm the technical validation/ profile was positive and automatic funds check was positive.
ACIS	AcceptedandChequeIssued	Payment instruction to issue a cheque has been accepted, and the cheque has been issued but not yet been deposited or cleared.	Sent by any Agent in the payment chain to confirm a cheque has been issued as requested.
ACSC	AcceptedSettlementCompleted	Settlement has been completed.	Sent by the Any Agent to confirm settlement of a payment message leg.
ACSP	AcceptedSettlementInProcess	All preceding checks such as technical validation and customer profile were successful and therefore the payment initiation has been accepted for execution.	Sent by any Agent to the to confirm the payment is accepted following technical validations being successfully completed.
ACTC	AcceptedTechnicalValidation	Authentication and syntactical and semantical validation are successful	Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following technical validations being successfully completed.
ACWC	AcceptedWithChange	Instruction is accepted but a change will be made, such as date or remittance not sent.	Sent by any Agent in the payment chain to the previous Agent to confirm the payment is accepted following amendments being made.
ACWP	AcceptedWithoutPosting	Payment instruction included in the credit transfer is accepted without being posted to the creditor customer’s account.	Sent by Creditor Agent to the previous Agent to confirm the acceptance of payment without settlement on the creditor’s account,
CPUC	CashPickedUpByCreditor	Cash has been picked up by the Creditor.	Sent by Creditor Agent to the previous Agent to confirm that the cash collection has been picked up by the Creditor,
PDNG	Pending	Payment initiation or individual transaction included in the payment initiation is pending. Further checks and status update will be performed.	Sent by any Agent in the payment chain to the previous Agent as an interim status whilst other validations are performed.
RCVD	Received	Payment initiation has been received by the receiving agent.	Sent by Any Agent to the previous Agent as confirmation that their Customer Credit Transfer initiation request has been received by the payment engine.
RJCT	Rejected	Payment initiation or individual transaction included in the payment initiation has been rejected.	Sent by Any Agent to inform the previous Agent that their Customer Credit Transfer has been rejected.

RJCT and the Status Reason Information Block

RJCT tells ABC Manufacturing that something went wrong. The StatusReasonInformation block — <StsRsnInf> — tells them what. Mandatory whenever TxSts = RJCT. Three components work together:

• Originator <Orgtr>: the party that determined the rejection. Usually Standard Chartered. Often omitted since the PAIN.002 sender is already known.
• Reason <Rsn>: either an ISO standard reason code (<Cd>) or a proprietary code (<Prtry>). ISO standard codes “ExternalStatusReason1Code” are mandatory in CBPR+ scenarios.
• Additional Information <AddtlInf>: free-text explanation. Mandatory when the reason code is NARR — i.e. when no suitable ISO code exists.

ISO Rule: A reason code must always be provided when Transaction Status is RJCT. When the code is NARR, Additional Information must also be present.

The Most Common Rejection Reason Codes

Code	Meaning	What It Tells ABC Manufacturing
AC01	Incorrect account number	Beneficiary account number format is invalid. Check account structure for the destination country.
AC04	Closed account number	Beneficiary’s account has been closed. Contact the supplier for a new account. Cannot be resolved by re-submission.
AC06	Blocked account	Account exists but is frozen or restricted. Cannot be resolved by re-submission.
AG01	Transaction forbidden	This transaction type is not permitted. May be a regulatory restriction.
AM01	Zero amount	Instructed amount is zero. Data entry error in the original PAIN.001.
AM04	Insufficient funds	Cannot debit ABC Manufacturing’s account. Check funding.
AM05	Duplication	Detected as a duplicate of a previously submitted instruction.
DT01	Invalid date	Value date is in the past or falls on a non-business day. Re-submit with corrected date.
FF01	Invalid file format	File format does not conform to expectations. Technical issue.
RC01	BIC invalid	BIC provided is not a valid registered BIC. Verify with beneficiary bank.
RR01	Missing debtor account	Debtor account or identification is missing.
RR04	Regulatory reason	Payment blocked for regulatory or compliance reasons. Investigate with Standard Chartered.
NARR	Narrative	No suitable ISO code. Full reason in AdditionalInformation free text.

A Critical Point About ACSP

ACSP means settlement is in progress — not that settlement has completed. ABC Manufacturing’s treasury system must not book the payment as done on receipt of ACSP. The payment has been submitted to the interbank network. But a great deal can still go wrong at the interbank layer. A rejection at the Creditor Agent’s end will come back as a PACS.002 — and Standard Chartered will convert that into a PAIN.002 RJCT, which may arrive days after the original ACSP.

  System design rule: Mark a payment complete ONLY on receipt of ACSC — or on confirmation in the CAMT.053/CAMT.054 bank statement. ACSP means “we have sent it forward.” It does not mean “it has arrived.”

Three-Level Reconciliation Logic

When a PAIN.002 arrives in ABC Manufacturing’s treasury system, the system must answer one question: which payment does this relate to? The answer lives across three nested levels, each with its own matching field. Get this hierarchy right and reconciliation is automatic. Get it wrong and the treasury team is doing manual lookups.

[ VISUAL 5: Three-level reconciliation hierarchy — OrgnlMsgId at file level, OrgnlPmtInfId at payment block level, OrgnlEndToEndId as the golden thread ]

The EndToEndId is the golden thread — it survives the full journey from PAIN.001 through PACS.008 and back via PAIN.002.

Level 1 — File / Group Level

Matching field: PAIN.001: GrpHdr/MsgId  ↔  PAIN.002: OrgnlGrpInfAndSts/OrgnlMsgId

ABC Manufacturing’s system reads OrgnlMsgId. The value must match the MsgId in the original PAIN.001 Group Header: ABC-BATCH-20241015-001. This links the entire status report to the correct payment file.

Level 2 — Payment Information Block Level

Matching field: PAIN.001: PmtInf/PmtInfId  ↔  PAIN.002: OrgnlPmtInfAndSts/OrgnlPmtInfId

The system matches OrgnlPmtInfId to the corresponding PmtInfId from the PAIN.001. For this batch: PMTINF-EUR-001. If the original PAIN.001 had multiple PmtInf blocks, this level separates which block the status refers to.

Level 3 — Individual Transaction Level

Primary matching field: PAIN.001: CdtTrfTxInf/PmtId/EndToEndId  ↔  PAIN.002: TxInfAndSts/OrgnlEndToEndId

At transaction level, the EndToEndId is the single most important reconciliation field. ABC Manufacturing assigned it in the PAIN.001:

• E2E-ABC-001 → XYZ Components GmbH — €40,000
• E2E-ABC-002 → Precision Parts Ltd — €22,500
• E2E-ABC-003 → Tech Supplies SA — €18,750
• E2E-ABC-004 → Rapid Tools BV — €10,000   [RJCT: AM04 — Insufficient Funds]
• E2E-ABC-005 → Global Metals NV — €6,750   [RJCT: AC04 — Closed Account — via PACS.002 from Deutsche Bank]

The EndToEndId survives not just the PAIN.002 — it also travels inside the PACS.008 that Standard Chartered sends into the interbank network. This makes it the golden thread across the full payment chain: PAIN.001 → PAIN.002 → PACS.008 → PACS.002 → back to PAIN.002 again.

Index the EndToEndId at payment submission time. Use it as the primary lookup key for every incoming PAIN.002. Any ERP that reconciles only at MsgId level is missing the granularity it needs for batch processing. The MsgId tells you which file. The EndToEndId tells you which payment.

Partial Acceptance — The Scenario Most Systems Get Wrong

ABC Manufacturing submitted five payments in one PAIN.001 batch. Standard Chartered runs validation. Three payments pass cleanly. Two fail — Txn 4 (Rapid Tools BV) is rejected immediately for insufficient funds. Txn 5 (Global Metals NV) initially passes Standard Chartered’s checks but is later rejected deep in the interbank network.

The result is PART — Partially Accepted. This is arguably the most dangerous status in PAIN.002 processing — not because it is technically complex, but because most ERP implementations handle it incorrectly.

[ VISUAL 6: Partial acceptance — ABC Manufacturing’s 5-transaction batch produces PART status. Three ACSC, two RJCT. ]

PART is not a failure. It is a mixed outcome. Treat each transaction on its own merits.

How PART Is Reported Across Three Levels

At Group Level (Block B): GrpSts = PART. The NbOfTxsPerSts breakdown shows 3 × ACSC and 2 × RJCT. First signal to drill into transaction level.

At Payment Info Level (Block C): PmtInfSts = PART. Same breakdown repeated for PMTINF-EUR-001.

At Transaction Level (Block D): Five separate TxInfAndSts entries. Three carry TxSts = ACSC. Two carry TxSts = RJCT — E2E-ABC-004 with AM04, and E2E-ABC-005 with AC04.

What ABC Manufacturing’s System Must Do

Most ERP systems assume all-or-nothing outcomes. PART breaks that assumption. The correct process:

1. Read GrpSts. If PART — do not stop here. Do not mark the batch as failed. Drill into transaction level.
2. Loop through every TxInfAndSts entry. For each, read OrgnlEndToEndId to identify the specific payment.
3. For RJCT entries, read the StsRsnInf reason code. Determine whether the rejection is correctable or final.
4. Correctable rejections: AM04 (insufficient funds) — check balance, re-submit once funded. DT01 (invalid date) — correct date, re-submit. AC01 (wrong account) — get correct account from supplier, re-submit.
5. Final rejections: AC04 (closed account) — cannot re-submit to same account. Contact supplier for new account. AC06 (blocked account) — investigate with Standard Chartered.
6. For correctable rejections: create a new PAIN.001 containing only the failed transactions. New MsgId, new PmtInfId. Keep the same EndToEndId values.
7. For ACSC  transactions: mark as accepted. Do not re-submit.

  The most common ERP failure: seeing PART status and re-submitting the entire original batch. This creates duplicate payments for the three transactions already accepted. Standard Chartered will process them again — ABC Manufacturing will have paid XYZ Components, Precision Parts, and Tech Supplies twice.

How PACS.002 Is Converted into PAIN.002

Here is the scenario that surprises most payment professionals when they encounter it for the first time.

ABC Manufacturing received ACSP from Standard Chartered — the payment to Global Metals NV was accepted and in progress. The treasury system noted it. All seemed well.

Three days later, a PAIN.002 RJCT arrives. Reason code: AC04 — Closed Account. The payment to Global Metals NV has failed.

The rejection did not occur at Standard Chartered. It occurred at Deutsche Bank Frankfurt — the Creditor Agent — deep inside the interbank network. The message that carried that rejection was a PACS.002. Standard Chartered received it, converted it into a PAIN.002, and forwarded it to ABC Manufacturing.

The Debtor Agent is the translation layer between the interbank world and the customer world.

[ VISUAL 7: PACS.002 to PAIN.002 conversion bridge — Standard Chartered receives PACS.002 from Deutsche Bank and generates PAIN.002 RJCT for ABC Manufacturing ]

The corporate never sees the PACS.002. They only ever see PAIN.001 references — the Debtor Agent handles the translation.

The Conversion — Step by Step

1. Standard Chartered sends PACS.008 into the interbank network toward Deutsche Bank Frankfurt.
2. Deutsche Bank Frankfurt attempts to credit Global Metals NV’s account. It finds the account is closed.
3. Deutsche Bank sends PACS.002 RJCT back to Standard Chartered, carrying reason code AC04 and the original UETR.
4. Standard Chartered receives the PACS.002. It reads the UETR and looks up the corresponding payment in its own records — tracing it back to the original PAIN.001.
5. Standard Chartered re-credits ABC Manufacturing’s account — reversing the earlier debit.
6. Standard Chartered constructs a new PAIN.002 with TxSts = RJCT, reason code AC04, and populates OrgnlEndToEndId (E2E-ABC-005) and OrgnlMsgId (ABC-BATCH-20241015-001).
7. Standard Chartered sends the PAIN.002 RJCT to ABC Manufacturing.

The Field Mapping — PACS.002 to PAIN.002

PACS.002 Field	Maps to PAIN.002 Field	Notes
StsRsnInf / Rsn / Cd (AC04)	TxInfAndSts / StsRsnInf / Rsn / Cd	Reason code passed through unchanged.
TxInfAndSts / OrgnlUETR	TxInfAndSts / OrgnlUETR	UETR is the connecting thread across both message families.
StsRsnInf / AddtlInf	TxInfAndSts / StsRsnInf / AddtlInf	Free text reason preserved for ABC Manufacturing.
★ OrgnlGrpInf / OrgnlMsgId (PACS.008 ref)	★ OrgnlGrpInfAndSts / OrgnlMsgId (PAIN.001 ref)	Critical re-mapping. Standard Chartered uses the UETR to trace back and substitute the PAIN.001 MsgId. The corporate never sees the PACS.008 reference.
TxInfAndSts / OrgnlEndToEndId	TxInfAndSts / OrgnlEndToEndId	E2E-ABC-005 preserved from the original PAIN.001.

The PACS.002 carries the PACS.008 MsgId — not the PAIN.001 MsgId. Standard Chartered must re-map this using the UETR to trace through its own payment records. The corporate’s ERP never sees the PACS.008 reference.

The UETR — The Connecting Thread Across Message Families

The Unique End-to-End Transaction Reference (UETR) is a UUID-format reference (e.g. b2c3d4e5-f6a7-8901-bcde-f12345678901) that travels unchanged through every message in the payment chain:

• PAIN.001 — created here by ABC Manufacturing’s ERP (or assigned by Standard Chartered)
• PACS.008 — Standard Chartered carries it into the interbank network
• PACS.002 — Deutsche Bank echoes it back in the rejection
• PAIN.002 — Standard Chartered echoes it back to ABC Manufacturing

The Timing Gap

ABC Manufacturing received ACSP on Tuesday morning. The PAIN.002 RJCT arrived Thursday afternoon. Two and a half days passed between a positive status and a rejection.

The explanation is simple: Standard Chartered’s ACSP reflected the status at the time it was sent — the payment had passed all of Standard Chartered’s checks and was in the interbank network. The rejection happened at Deutsche Bank’s end, after the payment had already left Standard Chartered’s systems. Cross-border payments involve multiple parties, time zones, and cut-off times. Rejections at the far end take time to propagate back.

Never mark a payment complete on ACSP. The correct moment: receipt of ACSC, or confirmation in the CAMT.053/CAMT.054 bank statement.

Who Actually Receives PAIN.002? The Three Use Cases

[ VISUAL 8: Three PAIN.002 use cases — standard relay, authorised party liquidity sweeps, and FI as debtor ]

The Forwarding Agent relays PAIN.002 unchanged — it does not regenerate or modify the message.

Use Case 1 — Standard Relay (Most Common)

The corporate (ABC Manufacturing) instructs its bank (Standard Chartered) via a PAIN.001 through a Forwarding Agent — a concentrating bank. The Forwarding Agent relays the PAIN.001 to Standard Chartered and relays the PAIN.002 back unchanged.

CBPR+ rule: RJCT with an ISO reason code must always be relayed. No bilateral agreement can override the obligation to notify the corporate that their payment was rejected.

Use Case 2 — Authorised Party (Liquidity Sweeps)

A Financial Institution (Agent I) has been given a Debit Authorisation by a corporate to move money from the corporate’s account. Agent I sends the PAIN.001 itself. The Debtor Agent sends PAIN.002 back to Agent I, not to the corporate.

Most common real-world example: multi-bank liquidity sweeps — a treasury management bank monitoring intraday balances via CAMT.052 and triggering sweeps via PAIN.001, with PAIN.002 status flowing back to that treasury bank.

Use Case 3 — Financial Institution as Debtor to Non-FI

The standard also provides for a Financial Institution that holds an account at another bank and initiates a payment from that account using PAIN.001. The pain.002 message is sent by the Debtor Agent to the Debtor (Financial Institution) who requested to initiate a payment from their account with the Debtor Agent to move funds to a non-Financial Institution Creditor. In practice, FI-to-FI own-account movements more commonly use the PACS.009 channel — but the PAIN framework accommodates this pattern in a specific case.

SWIFT GPI for Corporates (g4c) — The Visibility Alternative

PAIN.002 gives ABC Manufacturing structured status updates — but only for the statuses Standard Chartered has agreed to send. SWIFT GPI for Corporates (g4c) offers a complementary path — direct access to the SWIFT GPI Tracker for real-time chain visibility.

Dimension	PAIN.002	SWIFT g4c (GPI Tracker)
How status arrives	Bank pushes to Initiating Party	Corporate pulls from Tracker
Coverage	Only bilaterally agreed statuses	Full chain visibility at every hop
Rejection handling	Mandatory for RJCT — formal status channel	Complement, not replacement for RJCT
Connectivity	Standard ISO 20022 messaging	SWIFT membership + GPI subscription
Best for	Standard B2B payment status flows	Treasuries needing real-time global chain visibility

g4c adoption remains sparse. SWIFT connectivity requirements and budget approval cycles mean this tends to be a Tier 1 and large multinational corporate conversation. As ISO 20022 becomes the native standard for all messages, adoption is likely to grow.

A Practical XML Example — Partial Acceptance

Below is a simplified PAIN.002 from Standard Chartered to ABC Manufacturing covering the partial acceptance scenario. Two transactions are shown: one accepted (Txn 1, XYZ Components GmbH) and one rejected via PACS.002 conversion (Txn 5, Global Metals NV).

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.14">
  <CstmrPmtStsRpt>

    <!-- Block A: Group Header -->
    <GrpHdr>
      <MsgId>SCB-STATUS-20241018-007</MsgId>
      <!-- SCB own reference -- NOT the PAIN.001 MsgId -->
      <CreDtTm>2024-10-18T14:22:00</CreDtTm>
      <InitgPty><Nm>ABC Manufacturing Ltd</Nm></InitgPty>
    </GrpHdr>

    <!-- Block B: Link back to PAIN.001 -->
    <OrgnlGrpInfAndSts>
      <OrgnlMsgId>ABC-BATCH-20241015-001</OrgnlMsgId>
      <!-- Must match PAIN.001 GrpHdr/MsgId exactly -->
      <OrgnlMsgNmId>pain.001.001.14</OrgnlMsgNmId>
      <OrgnlNbOfTxs>5</OrgnlNbOfTxs>
      <GrpSts>PART</GrpSts>
      <!-- PART = mixed outcome -- drill to transaction level -->
      <NbOfTxsPerSts>
        <DtldNbOfTxs>3</DtldNbOfTxs><DtldSts>ACSC </DtldSts>
      </NbOfTxsPerSts>
      <NbOfTxsPerSts>
        <DtldNbOfTxs>2</DtldNbOfTxs><DtldSts>RJCT</DtldSts>
      </NbOfTxsPerSts>
    </OrgnlGrpInfAndSts>

    <!-- Block C: Payment Info Level -->
    <OrgnlPmtInfAndSts>
      <OrgnlPmtInfId>PMTINF-EUR-001</OrgnlPmtInfId>
      <PmtInfSts>PART</PmtInfSts>

      <!-- Block D: Accepted -- Txn 1, XYZ Components GmbH, EUR 40,000 -->
      <TxInfAndSts>
        <OrgnlInstrId>INSTR-XYZ-001</OrgnlInstrId>
        <OrgnlEndToEndId>E2E-ABC-001</OrgnlEndToEndId>
        <!-- Golden thread: ABC Manufacturing own reference -->
        <OrgnlUETR>a1b2c3d4-e5f6-7890-abcd-ef1234567890</OrgnlUETR>
        <TxSts>ACSC </TxSts>
        <!-- ACSC : accepted. Mark as done. Do NOT re-submit. -->
        <AccptncDtTm>2024-10-15T09:38:00</AccptncDtTm>
      </TxInfAndSts>

      <!-- Block D: Rejected -- Txn 5, Global Metals NV, EUR 6,750 -->
      <!-- This RJCT was triggered by PACS.002 from Deutsche Bank -->
      <TxInfAndSts>
        <OrgnlInstrId>INSTR-GBL-005</OrgnlInstrId>
        <OrgnlEndToEndId>E2E-ABC-005</OrgnlEndToEndId>
        <OrgnlUETR>b2c3d4e5-f6a7-8901-bcde-f12345678901</OrgnlUETR>
        <TxSts>RJCT</TxSts>
        <StsRsnInf>
          <Rsn><Cd>AC04</Cd></Rsn>
          <!-- AC04 from Deutsche Bank -- SCB passes reason unchanged -->
          <AddtlInf>Account closed. Contact Global Metals NV for new account.</AddtlInf>
        </StsRsnInf>
        <AccptncDtTm>2024-10-15T09:38:00</AccptncDtTm>
      </TxInfAndSts>

    </OrgnlPmtInfAndSts>
  </CstmrPmtStsRpt>
</Document>

Reading This Example

• OrgnlMsgId = ABC-BATCH-20241015-001 — links this PAIN.002 to the correct PAIN.001 in ABC Manufacturing’s ERP.
• GrpSts = PART — immediate signal to drill into transaction level. Do not close the batch.
• E2E-ABC-001 → TxSts = ACSC  — XYZ Components payment accepted. Mark as done. Do not re-submit.
• E2E-ABC-005 → TxSts = RJCT, AC04 — Global Metals NV account is closed. This RJCT was triggered by Deutsche Bank’s PACS.002, converted by Standard Chartered. Contact the supplier for a new account.
• OrgnlUETR on E2E-ABC-005 — enter this into the SWIFT GPI Tracker to see the full lifecycle of this payment.

Common Questions and Misconceptions

Does PAIN.002 always come back immediately after submitting PAIN.001?

No. An ACCP may arrive within seconds. ACSP may arrive minutes to hours later. ACSC may arrive the next business day. A PACS.002-triggered RJCT may arrive days later. ABC Manufacturing’s treasury system must receive PAIN.002 asynchronously, at any time, and process it correctly regardless of when it arrives.

What if we receive a PAIN.002 with no GrpSts, no PmtInfSts, and no TxSts?

Valid scenario. ISO 20022 does not require all three status levels to be populated simultaneously. Standard Chartered may choose to report only at the transaction level (Block D), leaving Blocks B and C status fields empty. Your reconciliation logic must handle status being present at only one or two of the three levels.

Can the same PAIN.001 generate both ACSP and RJCT PAIN.002 messages?

Yes — exactly what happened in ABC Manufacturing’s scenario. Multiple PAIN.002 messages for the same PAIN.001 file are entirely normal. The MsgId in each PAIN.002 Group Header will be different. The OrgnlMsgId in Block B will be the same for all — always pointing back to ABC-BATCH-20241015-001.

Is PAIN.002 the same as a bank statement?

No. A bank statement (CAMT.053) confirms that money has actually been debited or credited. PAIN.002 reports on the status of a payment instruction — it is about the processing journey. Both are needed for complete reconciliation. PAIN.002 closes the instruction loop. CAMT.053 closes the accounting loop.

What if we never receive a PAIN.002 for a payment?

If Standard Chartered does not send PAIN.002 for positive statuses (valid when not bilaterally agreed), rely on CAMT.054 for individual transaction confirmations and CAMT.053 for end-of-day reconciliation. If a PAIN.002 RJCT is not received within the agreed service window, initiate a payment investigation with Standard Chartered — using the UETR as the primary reference.

My Take — What No One Tells You About PAIN.002

When I was designing PAIN.002 handling in a CBPR+ rail on Volante, the biggest challenge was not the message structure. The message structure is straightforward. The challenge was orchestration — specifically, figuring out how many times the message could arrive, under what conditions, and how the system should respond to each variant.

The second challenge was a design principle I now treat as non-negotiable: PAIN.002 is only ever sent by the Debtor Agent. Full stop. If any other agent in your implementation is generating a PAIN.002, the design is wrong. This distinction — between who operates in the payment initiation space and who operates in the interbank clearing space — is the most commonly blurred line I have seen across implementation teams.

The deeper issue is structural. PAIN.002 is seldom implemented well because it had no MT equivalent. When ISO 20022 migration began, teams mapped every MT message to its MX counterpart and built from there. PAIN.002 had nothing to map to. The free-format MT199 and MT299 messages were the closest thing — entirely bilateral and unstructured. So PAIN.002 gets no port and no priority in migration projects.

That is changing. As ISO 20022 becomes the native standard for all messages — not just cross-border payments — PAIN.002 will get the attention it deserves. Understanding it now gives you a genuine edge.

Key Takeaways

• PAIN.002 is Standard Chartered’s structured reply to ABC Manufacturing’s PAIN.001. It reports on the processing status of the instruction — it does not move funds itself.
• PAIN.002 has two triggers: Standard Chartered’s own processing stages and interbank rejections via PACS.002. Both produce a PAIN.002 sent to the corporate.
• The Debtor Agent is the translation layer. It converts PACS.002 interbank rejections into PAIN.002 customer-facing notifications — re-mapping the MsgId reference, preserving reason code and UETR.
• RJCT is the only mandatory status under CBPR+. Positive statuses — ACCP, ACSP, ACSC — are sent only when bilaterally agreed. Build systems to handle their absence.
• Reconciliation works at three levels: OrgnlMsgId (file), OrgnlPmtInfId (block), OrgnlEndToEndId (transaction). The EndToEndId is the golden thread — always index it.
• PART is not the same as RJCT. Always drill to transaction level. Never re-submit the whole batch — duplicates result.
• A RJCT arriving after an ACSP is normal. It means the interbank leg failed after the bank had already accepted the instruction. ACSP is never final confirmation.
• As a BA or Architect: RJCT is the floor, not the ceiling. Lock in bilateral agreements for positive status codes at the requirements phase — not in UAT, not after go-live.

What’s Next

Now that PAIN.002 is fully covered — including how it connects to the interbank PACS layer — the next article in the PaymentTalks ISO 20022 series is PACS.008: the FinancialInstitutionCreditTransfer.

PACS.008 is the message Standard Chartered sends into the interbank network after processing ABC Manufacturing’s payment instruction. Understanding it will show you exactly how the same payment flows at the bank-to-bank layer — and how the UETR connects the PAIN and PACS message families together.

Last reviewed: May 2026  |  Based on ISO 20022 CBPR+ User Handbook and CustomerPaymentStatusReportV14 (pain.002.001.14)