pain.002 Status and Reject Codes: Reading the Bank's Reply

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: 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.

Three levels of answer

The message is CustomerPaymentStatusReport — root element <CstmrPmtStsRpt>. Its shape mirrors the pain.001 it answers:

• GroupHeader <GrpHdr> — the bank's own envelope: its MsgId, its CreationDateTime. Nothing about your payments yet.
• OriginalGroupInformationAndStatus <OrgnlGrpInfAndSts> — the verdict on your message: <OrgnlMsgId> echoes the MsgId of your pain.001, <OrgnlMsgNmId> names the message type it's answering, and <GrpSts> carries the group status.
• OriginalPaymentInformationAndStatus <OrgnlPmtInfAndSts> — the verdict on each batch: <OrgnlPmtInfId> echoes your PmtInfId, <PmtInfSts> carries the payment-level status. Inside it, TransactionInformationAndStatus <TxInfAndSts> answers each payment: <OrgnlInstrId> and <OrgnlEndToEndId> echo your references, <TxSts> carries the transaction status, and <StsRsnInf> carries the reason.

This is the payoff of the identifier discipline from the pain.001 side: MsgId, PmtInfId and EndToEndId 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:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.002.001.03">
  <CstmrPmtStsRpt>
    <GrpHdr>
      <MsgId>BANK-STATUS-20260803-42</MsgId>
      <CreDtTm>2026-08-03T10:12:00Z</CreDtTm>
    </GrpHdr>
    <OrgnlGrpInfAndSts>
      <OrgnlMsgId>ACME-20260802-0001</OrgnlMsgId>
      <OrgnlMsgNmId>pain.001.001.03</OrgnlMsgNmId>
    </OrgnlGrpInfAndSts>
    <OrgnlPmtInfAndSts>
      <OrgnlPmtInfId>ACME-20260802-0001-01</OrgnlPmtInfId>
      <PmtInfSts>PART</PmtInfSts>
      <TxInfAndSts>
        <OrgnlInstrId>INV-4711-P2P</OrgnlInstrId>
        <OrgnlEndToEndId>INV-4711</OrgnlEndToEndId>
        <TxSts>RJCT</TxSts>
        <StsRsnInf>
          <Rsn><Cd>AC04</Cd></Rsn>
          <AddtlInf>ISO Account number specified has been closed</AddtlInf>
        </StsRsnInf>
      </TxInfAndSts>
    </OrgnlPmtInfAndSts>
  </CstmrPmtStsRpt>
</Document>

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:

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 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 <StsRsnInf> — a <Rsn><Cd> holding a code from ExternalStatusReason1Code, plus optional <AddtlInf> 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 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 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:

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:

AM04 is the insufficient-funds code — on the initiation side that's your account short, which makes it a cash positioning failure wearing a format costume. AM02 usually means you tripped a limit in the bank agreement, not the scheme.

Routing and agent codes:

File, date and timing codes — the ones test phases are made of:

If the pain.001 walkthrough 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 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:

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:

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 <AddtlInf> 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 — 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:

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 are a third list again.

Misreading pain.002 status codes

• Treating pain.002 as optional. The overview post 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 <GrpSts> 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 <AddtlInf>. 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.

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 splits it into what stays deterministic (the reason code, the amount, the reference), what an AI step can read (the free-text <AddtlInf> 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, the pain.008 direct debit walkthrough, the ISO 20022 message catalogue, and the camt.053 statement walkthrough.