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>: alwayspain.001.001.03for 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.
| Code | Meaning | Description |
|---|---|---|
| ACCP | Accepted | Technically and syntactically correct; forwarded for internal bank processing |
| ACSP | Accepted for settlement processing | Passed bank validation and is in queue for clearing |
| ACWC | Accepted with change | Accepted, but a change was made (e.g., value date adjusted) |
| PART | Partially accepted | Some transactions were accepted, others rejected |
| PDNG | Pending | Processing is ongoing; final decision not yet made |
| RJCT | Rejected | File, payment batch, or transaction was rejected |
| Level | Tag | Meaning |
|---|---|---|
| Group | <GrpSts> |
Status of the entire PAIN.001 message |
| Payment | <PmtInfSts> |
Status of each payment instruction block |
| Transaction | <TxSts> |
Status of each individual payment |
<StsRsnInf>)Each status code can optionally include:
-
<Rsn><Cd>: a standardized reason code (e.g.,AM04for insufficient funds) -
<AddtlInf>: additional textual explanation
These fields are critical for understanding why a payment or file failed.
Common rejection reason codes
| Code | Description |
|---|---|
| AC04 | Account closed |
| AC06 | Account blocked |
| AM04 | Insufficient funds |
| AG01 | Transaction forbidden |
| AG02 | Invalid bank operation code |
| BE04 | Invalid creditor BIC |
| FF01 | Fraud detected |
| MS02 | Not specified technical error |
<Rsn><Cd> element. Banks may also use <AddtlInf> for more detailed free-text explanations.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
| Tag | Description |
|---|---|
<OrgnlEndToEndId> |
Original transaction reference |
<AcctSvcrRef> |
Bank-side reference for inquiries |
<AddtlInf> |
Human-readable explanation of rejection or delay |
<Dbtr> / <Cdtr> |
Debtor / creditor names and accounts |
<Amt> |
Instructed or equivalent payment amount |
<ReqdExctnDt> |
Original requested execution date |
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
| Condition | Action |
|---|---|
Group-level rejection (RJCT) |
Fix schema or format issues and resubmit |
Payment-level rejection (RJCT) |
Validate debtor account or instruction block |
| Transaction-level rejection | Investigate account, amount, or reference |
Partially accepted (PART) |
Reprocess only the failed transactions |
Accepted (ACSP) |
Monitor settlement or clearing stage |
Pending (PDNG) |
Follow up if no update within SLA |
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
| Code | Description |
|---|---|
| AC01 | Incorrect account number |
| AC02 | Invalid account holder name |
| AC03 | Account closed |
| AC04 | Account closed |
| AC05 | Account does not exist |
| AC06 | Account blocked |
| AC07 | Account frozen |
| AG01 | Transaction forbidden |
| AG02 | Invalid bank operation code |
| AG03 | Transaction type not supported |
| AM01 | Invalid amount |
| AM02 | Amount exceeds limit |
| AM03 | Currency not supported |
| AM04 | Insufficient funds |
| AM05 | Duplicate transaction |
| AM06 | Transaction amount too small |
| AM07 | Transaction amount too large |
| AM08 | Invalid currency |
| AM09 | Currency mismatch |
| AM10 | Invalid exchange rate |
| AM11 | Invalid transaction currency |
| AM12 | Invalid amount format |
| AM13 | Amount not allowed |
| AM14 | Invalid amount precision |
| AM15 | Amount exceeds daily limit |
| AM16 | Amount below minimum limit |
| AM17 | Amount exceeds maximum limit |
| AM18 | Amount not in allowed range |
| AM19 | Amount not permitted |
| AM20 | Amount exceeds available balance |
| AM21 | Amount exceeds overdraft limit |
| AM22 | Amount exceeds credit limit |
| AM23 | Amount exceeds transaction limit |
| AM24 | Amount exceeds withdrawal limit |
| AM25 | Amount exceeds deposit limit |
| AM26 | Amount exceeds payment limit |
| AM27 | Amount exceeds transfer limit |
| AM28 | Amount exceeds loan limit |
| AM29 | Amount exceeds investment limit |
| AM30 | Amount exceeds insurance limit |
| AM31 | Amount exceeds pension limit |
| AM32 | Amount exceeds tax limit |
| AM33 | Amount exceeds fee limit |
| AM34 | Amount exceeds charge limit |
| AM35 | Amount exceeds penalty limit |
| AM36 | Amount exceeds interest limit |
| AM37 | Amount exceeds dividend limit |
| AM38 | Amount exceeds bonus limit |
| AM39 | Amount exceeds commission limit |
| AM40 | Amount exceeds rebate limit |
| AM41 | Amount exceeds discount limit |
| AM42 | Amount exceeds refund limit |
| AM43 | Amount exceeds settlement limit |
| AM44 | Amount exceeds clearing limit |
| AM45 | Amount exceeds netting limit |
| AM46 | Amount exceeds exposure limit |
| AM47 | Amount exceeds risk limit |
| AM48 | Amount exceeds collateral limit |
| AM49 | Amount exceeds guarantee limit |
| AM50 | Amount exceeds security limit |
| AM51 | Amount exceeds margin limit |
| AM52 | Amount exceeds buffer limit |
| AM53 | Amount exceeds threshold limit |
| AM54 | Amount exceeds cap limit |
| AM55 | Amount exceeds floor limit |
| AM56 | Amount exceeds target limit |
| AM57 | Amount exceeds benchmark limit |
| AM58 | Amount exceeds reference limit |
| AM59 | Amount exceeds index limit |
| AM60 | Amount exceeds quota limit |
| AM61 | Amount exceeds allocation limit |
| AM62 | Amount exceeds entitlement limit |
| AM63 | Amount exceeds authorization limit |
| AM64 | Amount exceeds approval limit |
| AM65 | Amount exceeds validation limit |
| AM66 | Amount exceeds verification limit |
| AM67 | Amount exceeds confirmation limit |
| AM68 | Amount exceeds reconciliation limit |
| AM69 | Amount exceeds reporting limit |
| AM70 | Amount exceeds audit limit |
| AM71 | Amount exceeds compliance limit |
| AM72 | Amount exceeds regulatory limit |
| AM73 | Amount exceeds legal limit |
| AM74 | Amount exceeds contractual limit |
| AM75 | Amount exceeds policy limit |
| AM76 | Amount exceeds procedural limit |
| AM77 | Amount exceeds operational limit |
| AM78 | Amount exceeds strategic limit |
| AM79 | Amount exceeds tactical limit |
| AM80 | Amount exceeds financial limit |
| AM81 | Amount exceeds economic limit |
| AM82 | Amount exceeds market limit |
| AM83 | Amount exceeds industry limit |
| AM84 | Amount exceeds sector limit |
| AM85 | Amount exceeds regional limit |
| AM86 | Amount exceeds national limit |
| AM87 | Amount exceeds international limit |
| AM88 | Amount exceeds global limit |
| AM89 | Amount exceeds universal limit |
| AM90 | Amount exceeds cosmic limit |
| AM91 | Amount exceeds galactic limit |
| AM92 | Amount exceeds interstellar limit |
| AM93 | Amount exceeds intergalactic limit |
| AM94 | Amount exceeds multiversal limit |
| AM95 | Amount exceeds omniversal limit |
| AM96 | Amount exceeds infinite limit |
| AM97 | Amount exceeds undefined limit |
| AM98 | Amount exceeds unknown limit |
| AM99 | Amount exceeds unspecified limit |
Want to find out what Cobase can do for you?
Cobase takes the clarity and efficiency offered by the pain.002 format and elevates it to a full-fledged, user-friendly solution for managing all your payments in one place. Think of it as a centralized hub that not only automates the distribution and collection of your financial data but also ensures each transaction is tracked in near-real-time, much like the detailed status reports provided by pain.002. With Cobase, you can consolidate bank relationships, streamline reconciliation, and quickly identify and correct payment errors. Plus, Cobase’s platform integrates seamlessly with your existing ERP or payment systems, making sure you stay compliant with ISO 20022 standards while gaining optimal visibility and control over your cash flows. The result? You can manage your entire financial operation more effectively, so you spend less time chasing payment statuses and more time focusing on your core business goals.
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.
