# pain.002 Status and Reject Codes: Reading the Bank's Reply Source: https://gravam.com/blog/pain-002-status-and-reject-codes Author: Tan Gravam Published: 2026-08-03 Updated: 2026-10-11 Reviewed: 2026-10-11 Summary: How to read a pain.002 status report: group, payment and transaction level, the ACTC/ACCP/ACSC status codes, and reject reasons like AC01, AC04 and AM04. **A pain.002 answers your pain.001 at up to three levels — the whole file, each payment batch, each transaction — and every answer is a four-letter status code plus, when the status is RJCT, a reason code that tells you why.** The status codes and the reason codes come from two different lists, live at different depths of the message, and are the difference between "the bank said no" and knowing at 9:05 that one supplier IBAN is dead while the other 199 salaries are fine. This is the response-side companion to the [pain.001 field walkthrough](https://gravam.com/blog/pain-001-structure-and-fields): that post builds the instruction, this one decodes the reply. As there, I'll keep two sources open side by side — the official ISO 20022 External Code Sets, which own the code meanings, and a real bank's pain.002 implementation guide (Nordea's, again one of the few public ones), which shows how much of the standard a bank actually sends. > Have a pain.002 in front of you? Paste it into the free [**Bank File Reader**](https://gravam.com/tools/bank-file-reader): it shows each status down to the single payment, with the reason code explained. Nothing you paste leaves your browser. The page also has [a sample status report](https://gravam.com/tools/bank-file-reader#samples-heading) to test an importer against. ## Three levels of answer The message is `CustomerPaymentStatusReport` — root element ``. Its shape mirrors the pain.001 it answers: - **GroupHeader ``** — the bank's own envelope: its MsgId, its CreationDateTime. Nothing about your payments yet. - **OriginalGroupInformationAndStatus ``** — the verdict on your _message_: `` echoes the MsgId of your pain.001, `` names the message type it's answering, and `` carries the group status. - **OriginalPaymentInformationAndStatus ``** — the verdict on each _batch_: `` echoes your PmtInfId, `` carries the payment-level status. Inside it, **TransactionInformationAndStatus ``** answers each _payment_: `` and `` echo your references, `` carries the transaction status, and `` carries the reason. This is the payoff of the identifier discipline from the pain.001 side: [MsgId, PmtInfId and EndToEndId](https://gravam.com/blog/payment-references-endtoendid-uetr) each come back at exactly one level of the pain.002 — Nordea's guide maps them index by index — so a status finds its payment without any matching heuristics. If your EndToEndIds are lazy, this is the message where you pay for it. An illustrative skeleton — real tag names from Nordea's pain.002.001.03 guide, not a bank-ready file — answering the pain.001 from the sibling post, with one transaction bounced: ```xml BANK-STATUS-20260803-42 2026-08-03T10:12:00Z ACME-20260802-0001 pain.001.001.03 ACME-20260802-0001-01 PART INV-4711-P2P INV-4711 RJCT AC04 ISO Account number specified has been closed ``` One rule saves a lot of confused parsing: **check the group level first**. Nordea's guide states it plainly — a group-level `RJCT` means the whole file is rejected and will not be processed, while a group-level `ACTC` means technical validation passed and content validation follows. If the file died at the gate, no payment- or transaction-level statuses are coming, ever, and your monitor shouldn't sit waiting for them. ## The status codes: a lifecycle, not a list The official meanings live in ISO's External Code Sets — `ExternalPaymentGroupStatus1Code` for the group level (13 codes in the 1Q2026 edition) and `ExternalPaymentTransactionStatus1Code` for transactions (25 codes). In older message versions like the .03 that Nordea implements, the same codes sit as embedded schema enumerations (typed `TransactionGroupStatus3Code` and `TransactionIndividualStatus3Code` in its guide); the external list is where ISO maintains the definitions now. Read in order, the core codes are a pipeline: | Code | Official meaning (condensed from the ISO external code sets) | | --- | --- | | **RCVD** | Payment initiation has been received by the receiving agent. | | **ACTC** | Authentication and syntactical and semantical validation are successful. | | **ACCP** | Preceding check of technical validation was successful; customer profile check was also successful. | | **ACSP** | All preceding checks such as technical validation and customer profile were successful; accepted for execution. | | **ACSC** | Settlement on the debtor's account has been completed (group set); settlement completed (transaction set). | | **ACCC** | Settlement on the creditor's account has been completed. | | **ACWC** | Instruction is accepted but a change will be made, such as date or remittance not sent. | | **PART** | A number of transactions have been accepted, whereas another number have not yet achieved 'accepted' status. | | **PDNG** | Payment instruction is pending; further checks and status update will be performed. | | **RJCT** | Payment instruction has been rejected. | The A-codes are stages, not synonyms: ACTC says the file _parsed_, ACCP says the bank also recognises _you_, ACSP says it's going to _execute_, and only ACSC/ACCC talk about _settlement_ — the ISO set even flags ACSC as usable only under bilateral agreement, because settlement confirmation is what your [statement](https://gravam.com/blog/bank-statement-formats-mt940-camt053-bai2) is for. A payment can die after any of them. Treat every A-status short of settlement as "so far, so good", not as "done". Three codes deserve a closer look than their four letters suggest. **ACWC** means the bank changed something and processed anyway — date shifted past a cut-off, remittance dropped — and if you file it under "accepted" without reading the change, your books and the bank's diverge silently. **PART** at payment level is the one that should page someone: some transactions in the batch made it, some didn't, so a blanket retry re-pays the successful ones. **PDNG** means the story isn't over; another pain.002 follows. The transaction set has a longer tail — ACFC (funds check passed), ACWP (accepted without posting to the creditor's account yet), BLCK (a previously-ACWP payment is now blocked in both directions), PATC (multi-authorisation flows where some approvals are still outstanding), CANC (cancelled — the set marks it for API contexts), even CPUC for cash physically picked up. The newest additions are the RCVC/RVCM/RVNC family for Verification of Payee outcomes — the code list is a living document, and the quarterly external-set publication is where it lives. You will not meet most of these; Nordea's guide, for instance, sends exactly two codes at group level (ACTC, RJCT) and five at payment level (ACCP, ACWC, PART, PDNG, RJCT). Same pattern as on the pain.001 side: **the standard defines the vocabulary, the MIG tells you which words the bank actually speaks.** ## When it's RJCT: the reason codes RJCT alone tells you nothing actionable. The _why_ sits in `` — a `` holding a code from **`ExternalStatusReason1Code`**, plus optional `` free text. This is the list behind every "sepa reject reason code" search: 302 codes in the 1Q2026 edition (315 by 2Q2026 — [the full list](https://gravam.com/blog/iso-20022-status-reason-codes-full-list) has every one, with ISO's definition), of which a corporate treasury meets perhaps twenty-five. What follows is that curated subset with the official meanings, condensed from the ISO external code sets — for anything rarer, go to [the official list](https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets) rather than a forum thread. The third column in these tables is not ISO's. It is where to look first when the code comes back — a starting point for the person who has to act on it, which a bank's own implementation guide outranks wherever the two differ. **Account codes — the wrong-IBAN family:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **AC01** | Account number is invalid or missing. | The IBAN or account number in the payee record: its length and check digits. Correct the record, then issue the payment again. | | **AC02** | Debtor account number invalid or missing. | Your own account in the file (the debtor account): the house-bank account this payment run is mapped to. | | **AC03** | Creditor account number invalid or missing. | The beneficiary's account number as it is stored in the payee record. | | **AC04** | Account number specified has been closed on the bank of account's books. | New account details from the payee — through a channel you already trust, not the message that announces the change. Then update the record. | | **AC06** | Account specified is blocked, prohibiting posting of transactions against it. | Nothing in your file. The account holder has to resolve the block with their bank; do not send to the same account again until they confirm. | AC01 vs AC04 is the distinction worth automating: AC01 is bad master data you can fix today; AC04 means the account existed and is gone — you need a new IBAN from the beneficiary, and retrying is pointless. **Funds and amount codes:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **AM01** | Specified message amount is equal to zero. | Zero-amount lines in the payment run, such as items that net to nil. Leave them out before the file is built. | | **AM02** | Specific transaction/message amount is greater than allowed maximum. | Which limit applies: per payment, per file or per day, set by the bank or the scheme. Split the payment or have the limit changed. | | **AM04** | Amount of funds available to cover specified message amount is insufficient. | The balance of the paying account at the time of execution, and the cut-off for funding it. | | **AM05** | Duplication. | Whether the earlier instruction was executed — before anything is sent again. | AM04 is the insufficient-funds code — on the initiation side that's _your_ account short, which makes it a [cash positioning](https://gravam.com/blog/how-to-build-a-daily-cash-position) failure wearing a format costume. AM02 usually means you tripped a limit in the bank agreement, not the scheme. **Routing and agent codes:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **RC01** | Bank identifier code specified in the message has an incorrect format. | The format of the BIC in the payee record: eight or eleven characters. | | **RC02** | Bank identifier is invalid or missing. | Whether the BIC exists and is the one for that account's bank. | | **AGNT** | Agent in the payment workflow is incorrect. | Which agent the bank means: read the additional information, then the intermediary or correspondent details in the instruction. | | **CNOR** | Creditor bank is not registered under this BIC in the CSM. | Whether the creditor's bank can be reached in this scheme under that BIC. If not, the payment needs another payment type, not a resend. | | **DNOR** | Debtor bank is not registered under this BIC in the CSM. | Your own bank's BIC in the file, and the scheme the file was sent for. | **File, date and timing codes — the ones test phases are made of:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **FF01** | File format incomplete or invalid. | The file against the bank's implementation guide: message version, mandatory elements, character set. A format fix, not a data fix. | | **DT01** | Invalid date (e.g. wrong or missing settlement date). | The dates in the file: a requested execution date that is missing or not a day the bank will accept. | | **DT02** | Invalid creation date and time in Group Header (e.g. historic date). | The creation date and time in the group header: a file built earlier and sent late, or a system clock. | | **CH03** | Value in Requested Execution Date is too far in the future. | The requested execution date against the bank's window for future-dated payments. | | **CH04** | Value in Requested Execution Date is too far in the past. | The requested execution date: usually a file that waited for approval past its date. | | **TM01** | Message, payment information block or transaction received after agreed processing cut-off time. | The bank's cut-off for this payment type against the time the file arrived, not the time it was created. Then whether the bank moved it to the next day or dropped it. | | **DUPL** | Payment or charge is a duplicate of another payment or charge. | Whether the first one was executed — before anything is sent again. | | **RF01** | Transaction reference is not unique within the message. | How references are generated: the same reference has been used twice in one message. | If the [pain.001 walkthrough](https://gravam.com/blog/pain-001-structure-and-fields) is the instruction manual, this table is its error page: the stale CreationDateTime, the reused MsgId, the execution date outside the window — each has its own code, and each is fixable on your side without calling anyone. When a reject traces back to the file, the fix belongs before the next send, not in this report. [BankLint](https://gravam.com/products/banklint) does not read pain.002. It validates the corrected pain.001 first: the ISO 20022 schema and, for pain.001.001.09, the SEPA Credit Transfer rules. Your bank's own rules can still reject a file that passes. **Party and regulatory codes:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **BE01** | Identification of end customer is not consistent with associated account number. | The payee's name in your record against the name the account is held in. | | **BE04** | Specification of creditor's address, required for payment, is missing or not correct. | The creditor's address in the payee record: present, and in the form the bank requires. | | **MD07** | End customer is deceased. | Not a data fix. Stop, and take it to whoever owns the relationship. | | **RR01** | Regulatory: debtor account or unique identification insufficient or missing. | The debtor's account or identification in the file — complete in the message, not only in the master data. | | **RR02** | Regulatory: debtor name and/or address insufficient or missing. | The debtor's name and address in the file. | | **RR03** | Regulatory: creditor name and/or address insufficient or missing. | The creditor's name and address in the file. | | **RR04** | Regulatory reason. | Ask the bank. The code says a regulatory reason exists and nothing more; do not resend until it is explained. | | **AM07** | Amount specified in message has been blocked by regulatory authorities. | Ask the bank. Nothing in the file changes it. | | **CURR** | Currency of the payment is incorrect. | The currency of the payment against what the account and the scheme accept. | BE04 and the RR-family are the structured-address era in code form: address data that used to be tolerated as missing is increasingly a hard reject. **The catch-alls — where the code stops helping:** | Code | Official meaning | First thing to check | | --- | --- | --- | | **CUST** | Cancellation requested by the Debtor. | Who on your own side asked for the cancellation: the debtor is the one who requested it. | | **MS02** | Reason has not been specified by end customer. | The customer gave no reason. Whoever owns the relationship has to ask. | | **MS03** | Reason has not been specified by agent. | The bank gave no reason. Ask it; in some countries the silence is deliberate. | | **NARR** | Reason is provided as narrative information in the additional reason information. | The additional information beside the code: the reason is written there. | Two of these are traps. **CUST** gets glossed in the wild as "customer error" or "customer decision"; the official definition in the status-reason list is narrower — a cancellation the debtor asked for. And **MS03** is the bank formally declining to give you a coded reason — often because a sanctions or fraud screen is involved and the bank won't say so. When your reject feed is dominated by MS03 and NARR, the information you need is in `` or on the phone, not in the code — Nordea's guide, for instance, commits to filling AdditionalInformation for every non-ACCP status, prefixing it `ISO` when the text comes from the external code list and `CAP` when it's the bank's own commentary. And banks repurpose codes too, documented in plain sight: the same guide uses **MS02** with an ACWC status to signal a _changed creditor account_ in Finland — a meaning you would never derive from the official definition. When bank usage and the official list disagree, print the official meaning and read the MIG for the local dialect. ## The SEPA direct debit set: MD01, MD06, AG01 and the rest Everything above is what a credit transfer file gets back. A creditor collecting by SEPA direct debit — a [pain.008](https://gravam.com/blog/pain-008-direct-debit-initiation) — meets a narrower dialect, and the European Payments Council publishes it: the reason codes its two direct debit rulebooks allow, with the kind of R-transaction each may appear in. Most are already in the tables above (AC01, AC04, AC06, AM04, AM05, CNOR, DNOR, FF01, MD07, MS02, MS03, RC01, RR01–RR04). These nine are not: | Code | Official name | What the rulebook means by it | Arrives as | | --- | --- | --- | --- | | **AC13** | Invalid Debtor Account Type | Debtor account is a consumer account. B2B collections only. | Reject, return | | **AG01** | Transaction Forbidden | Direct debit forbidden on this account for regulatory reasons — the EPC's example is a savings account. | Reject, return | | **AG02** | Invalid Bank Operation Code | Operation code, transaction code or sequence type incorrect; invalid file format. | Reject, return | | **BE05** | Unrecognised Initiating Party | Identifier of the creditor incorrect. | Reject, return | | **ED05** | Settlement Failed | Settlement of the collection failed. | Reject | | **MD01** | No Mandate | No valid mandate (Core). No mandate, or no confirmation of it from the debtor (B2B). Unauthorised transaction, on a refund. | Reject, return, refund | | **MD02** | Missing Mandatory Mandate Information In Mandate | Mandate data missing or incorrect. | Reject | | **MD06** | Refund Request By End Customer | Disputed authorised transaction. Core collections only. | Refund | | **SL01** | Specific Service Offered By Debtor Agent | Due to a specific service offered by the debtor's bank: creditor blocking, amount limits, frequency limits. | Reject, return | Four things in the EPC's notes are worth more than the definitions. - **MD01 and MD06 are the two refunds, on two clocks.** MD06 is the unconditional refund of a Core collection, available until eight weeks after the debit date; nothing is alleged, the debtor simply asked. MD01 on a refund is the claim that the transaction was never authorised, and it runs until thirteen months after the debit date. The same code on a reject or return means something duller: no mandate on file, a B2B mandate the debtor has not yet confirmed to its bank, or a mandate the debtor's bank cancelled after 36 months without a collection. - **AC13 is not AG01.** A B2B collection presented to a consumer's account must come back as AC13; the guidance says in so many words that AG01 cannot be used for it. AG01 is the account that may not be debited at all. - **AG02 is usually the sequence type.** The use-cases the EPC lists are a recurrent collection after a one-off and a one-off after a recurrent — the FRST/RCUR/OOFF/FNAL field in the pain.008 saying something the mandate's history contradicts. - **MS03 can be a privacy rule, not a secret.** The guidance reserves MS03 for countries whose law — data protection, typically — does not allow the debtor's bank to send AC04, AM04, MD07 or the RR codes. So a market where every failed collection is MS03 may simply be one where "insufficient funds" may not be said out loud. And SL01 is the debtor's own hand: every consumer-invoked block — this creditor, this amount, this often — comes back under it. There is nothing to repair in the file. The conversation is with the customer. ## A reject is not a return One distinction keeps reconciliation honest: pain.002 RJCT happens **before** your money moves — validation or execution failed and nothing settled. When a payment settles and then comes back (beneficiary account closed at the far end, funds recalled), that's a **return**, and it reaches you through your statement and reporting flow, carrying reason codes from a _sibling_ list, `ExternalReturnReason1Code`. The two lists overlap heavily — AC04, AM04, MD07 appear in both with essentially the same meanings — but not perfectly, and the wording is set-specific: AC01 officially means "Account number is invalid or missing" as a status reason but "Format of the account number specified is not correct" as a return reason. Practical consequence: don't build one lookup table for "SEPA reject codes" and feed it both message families; key your code tables by code set, not by four letters — and if you also run US ACH, the [Nacha return codes](https://gravam.com/blog/nacha-ach-file-format-and-return-codes) are a third list again. ## Misreading pain.002 status codes - **Treating pain.002 as optional.** The [overview post](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002) makes this point strategically; here's the operational version: a payment run without status handling means your first reject notification is an angry supplier. - **Waiting for transaction statuses after a group-level RJCT.** The file is dead; nothing below the group level will arrive. Check `` first. - **Mapping every A-status to "paid".** ACTC, ACCP and ACSP are checkpoints. Settlement is ACSC/ACCC at best, and your statement in practice. - **Blanket-retrying a PART batch.** Some of those payments went through. Retry the RJCT transactions by EndToEndId, or pay people twice. - **One reason-code table for rejects and returns.** Same letters, different code sets, set-specific wording. Key by set. - **Ignoring ``.** For MS03 and NARR it's the only content you get; for bank-specific dialects (Nordea's `CAP`-prefixed lines) it's where the real explanation lives. > Build your reject handling as triage buckets keyed on reason-code families, not individual codes: data errors you can fix and resend (AC01, RC01, DT01, CH03/CH04, RF01), funds problems for cash management (AM04), beneficiary problems needing outreach (AC04, AC06, MD07, BE04), and opaque rejects for a human queue (MS03, NARR, RR04). New codes then land in a bucket by prefix instead of in an unhandled-exception log. Rejects and the statement lines they never became meet in reconciliation, and that is the step worth redesigning rather than staffing up. The [bank reconciliation teardown](https://gravam.com/blog/ai-workflow-teardown-bank-reconciliation) splits it into what stays deterministic (the reason code, the amount, the reference), what an AI step can read (the free-text `` a bank puts beside a code), and what stays with a named human (the decision to repair, re-route or write off). The reply side of the payment conversation is smaller than the instruction side — three levels, one status vocabulary, one reason-code list — but it's the half that runs at 2 a.m. when nobody's watching. Wire the codes to actions once, against the official list, and a bounced payment becomes a work item instead of an investigation. *** _See also the [pain.001 field walkthrough](https://gravam.com/blog/pain-001-structure-and-fields), the [pain.008 direct debit walkthrough](https://gravam.com/blog/pain-008-direct-debit-initiation), the [ISO 20022 message catalogue](https://gravam.com/blog/iso-20022-payments-pain-001-pain-002), and the [camt.053 statement walkthrough](https://gravam.com/blog/camt-053-structure-and-fields)._ ## Primary sources Status and reason code usage is version- and bank-specific: the official code meanings below come from the ISO 20022 External Code Sets (1Q2026 edition, which lists 302 status reason codes), and the bank behaviour follows a pain.002.001.03 implementation guide (Nordea, CGI aligned), while the ISO catalogue is at CustomerPaymentStatusReportV15. Verify which statuses and reasons your banks actually send against their own MIGs. - ISO 20022 — External Code Sets (1Q2026) — accessed 2026-08-03 — https://www.iso20022.org/catalogue-messages/additional-content-messages/external-code-sets - Nordea — Message Implementation Guidelines, pain.002.001.03 (Corporate Access Payables, MIG v1.6) — accessed 2026-08-03 — https://www.nordea.com/en/doc/mig-cap-pain002-001-03-status-v1-6.pdf - European Payments Council — Guidance on Reason Codes for SDD R-transactions (EPC173-14, version 8.0, 28 November 2024) — accessed 2026-10-10 — https://www.europeanpaymentscouncil.eu/sites/default/files/kb/file/2024-11/EPC173-14%20v8.0%20Guidance%20on%20Reason%20Codes%20for%20SDD%20R-transactions.pdf - ISO 20022 — Message definitions catalogue (Payments Initiation) — accessed 2026-08-03 — https://www.iso20022.org/iso-20022-message-definitions ## Questions this article answers **Q: What is the difference between ACTC, ACCP and ACSP in pain.002?** ACTC, ACCP and ACSP are successive acceptance stages, each defined in the ISO 20022 external status code sets. ACTC means authentication and syntactical and semantical validation succeeded — the file parsed and passed schema-level checks. ACCP adds that the customer profile check also passed — the bank recognises the account and agreement behind the payment. ACSP means all preceding checks succeeded and the instruction has been accepted for execution. A payment can die after any of them, so none of the three means 'paid' — for settlement you're waiting for ACSC or ACCC, or in practice for the account statement. **Q: What does reject reason code AC01 mean?** In the ISO 20022 ExternalStatusReason1Code list — the code set pain.002 reason codes come from — AC01 officially means 'Account number is invalid or missing'. In practice it's the classic wrong-IBAN reject: the account number failed validation. One subtlety: the sibling return-reason code set defines AC01 as 'Format of the account number specified is not correct', so the same four letters carry set-specific wording depending on whether you're reading a reject or a return. Related codes: AC02 and AC03 pin the invalid account to the debtor or creditor side, and AC04 means the account has been closed. **Q: What does MD01 mean on a SEPA direct debit?** MD01 is 'No Mandate'. On a reject or return it means there is no valid mandate for the collection — none on file, a B2B mandate the debtor has not confirmed to its bank, or one the debtor's bank cancelled after 36 months without a collection. On a refund of a Core collection it is the debtor's claim that the transaction was unauthorised, which the European Payments Council's guidance allows until thirteen months after the debit date. It is different from MD06, the unconditional refund of an authorised Core collection within eight weeks. **Q: Can a pain.002 reject a whole file?** Yes. A pain.002 can answer at group level via GroupStatus in OriginalGroupInformationAndStatus, and a group-level RJCT kills the entire original message. Nordea's pain.002 implementation guide is explicit: when it sends RJCT as the group status, the whole file is rejected and will not be processed, whereas ACTC at group level means technical validation passed and content validation continues in the back end. That's why status handling has to check the group level first — if the file died there, no payment or transaction level statuses are coming. **Q: What do MS03 and NARR mean in a payment rejection?** MS03 and NARR both come from the ISO external status reason code list and both are catch-alls. MS03 officially means 'Reason has not been specified by agent' — the bank rejected the payment and is not telling you why in coded form; its sibling MS02 is the same with the end customer as the silent party. NARR means the reason is provided as narrative information in the additional reason information — free text instead of a code, so your automation has to surface the AdditionalInformation element to a human. If your rejects are dominated by MS03 and NARR, the useful detail is usually in AdditionalInformation or in a phone call, not in the code.