PAIN.002 status message guide

PAIN.002.001.03 is an XML-based message format defined by the ISO 20022 standard. It is used by financial institutions to report back the processing status of a previously submitted payment instruction message—typically a PAIN.001 (payment initiation) file.

The PAIN.002 status message informs the initiating party (usually a corporate client) whether the payment file or its individual transactions have been accepted, rejected, or are still being processed. It plays a central role in payment lifecycle transparency and exception management.

Structure of a PAIN.002 message

A PAIN.002 message consists of three hierarchical levels, each capable of carrying its own status and explanatory details:

1. Group header (<GrpHdr>)

• Provides metadata on the status message itself.

• Contains:

  • <MsgId>: message identifier

  • <CreDtTm>: creation date and time

  • <InitgPty>: initiating party details

2. Original group information and status (<OrgnlGrpInfAndSts>)

• Refers to the original payment file submitted.

• Contains:

  • <OrgnlMsgId>: original message ID

  • <OrgnlMsgNmId>: always pain.001.001.03 for SEPA payments

  • <GrpSts>: overall status of the message

  • Control totals (<OrgnlNbOfTxs>, <OrgnlCtrlSum>) if provided in the original message

  • <StsRsnInf>: status reason information, if applicable

3. Original payment information and status (<OrgnlPmtInfAndSts>)

• Describes the status per payment batch and individual transaction.

• Contains:

  • <PmtInfSts>: status at the payment instruction level

  • <TxInfAndSts>: list of individual payment transaction statuses

  • References, rejection reasons, and values from the original file

Common status codes and their meaning

These standardized codes are used across all three reporting levels. Their interpretation depends on context: group, payment, or transaction.

Each status code can optionally include:

• <Rsn><Cd>: a standardized reason code (e.g., AM04 for insufficient funds)

• <AddtlInf>: additional textual explanation

These fields are critical for understanding why a payment or file failed.

Common rejection reason codes

Practical processing examples

Case 1: Entire file rejected

• <GrpSts> = RJCT

• Cause: schema validation error, invalid format, or duplicate message ID

• Result: none of the transactions were processed

• Action: review and resubmit the corrected PAIN.001 file

Case 2: Partial acceptance

• <GrpSts> = PART or <PmtInfSts> = PART

• Some transactions accepted, others rejected

• Action: identify rejected transactions using <TxSts>, review reasons in <StsRsnInf>, and correct where needed

Case 3: Pending status

• <TxSts> = PDNG

• Payment is under review or being processed

• Action: monitor for updates or check with your banking partner if status remains unchanged beyond expected processing time

Key tags used for reconciliation and troubleshooting

integration into treasury operations

Exception handling

• Automate detection of RJCT and PART statuses

• Trigger workflows to investigate and resolve failed payments

• Update ERP systems with rejection codes for audit trails

Monitoring pending items

• Identify transactions in PDNG state

• Set alerts or review mechanisms if they do not update within the expected time window

Reporting and dashboards

• Use the detailed structure of PAIN.002 for reconciliation dashboards

• Track acceptance rates per bank, currency, or geography

Use with platforms like Cobase

When used in combination with a payment hub or aggregation platform such as Cobase:

• PAIN.002 messages can be automatically ingested, interpreted, and visualized

• Users can access status messages in an intuitive dashboard without handling XML directly

• Exceptions can be routed to specific team members with relevant metadata

• Insights can feed into forecasting models by confirming actual vs expected execution timelines

Summary of key actions

Final recommendations

• Always monitor PAIN.002 files alongside acknowledgments (e.g., ACK/NACK).

• Build exception-based workflows rather than manual reviews.

• Ensure your TMS or ERP system can interpret both structured and unstructured status reasons.

• Train finance and treasury staff to interpret the codes and tags most relevant to their workflows.

ISO 20022 - Rejection reason codes

Want to find out what Cobase can do for you?

Frequent Asked Questions (FAQs)

1. What does the “pain.” prefix stand for in pain.002?
“pain.” stands for “Payments Initiation.” Each pain. message (like pain.001, pain.008) addresses a different part of the payment initiation process, and pain.002 focuses on status reporting.

2. Is pain.002 mandatory for all financial institutions?
While not universally mandated, pain.002 is widely adopted because it provides vital feedback on payment status. Many banks encourage its use to facilitate more transparent transactions and reduce errors.

3. How often are pain.002 messages generated?
The frequency varies depending on the bank or payment system. Some generate them in real time as payments are processed, while others might send them in batches at specific intervals.

4. Can pain.002 be used for both domestic and international payments?
Absolutely. pain.002 is part of the ISO 20022 standard, which is designed to support both domestic and cross-border payments. The same message structure can accommodate multiple currencies and banking details.

5. Do I need special software to read or generate pain.002 files?
Typically, yes. Many ERP systems and banking software solutions come with built-in ISO 20022 support. If not, you may need a specialized tool or a custom integration layer to parse and produce XML files according to the pain.002 specification.