pain.001 and pain.002: The Payment Initiation and Status Reference

Every corporate payment that reaches a bank as a SWIFT pacs.008 message or a SEPA credit transfer started somewhere upstream, as an instruction the payer's own system sent to its own bank. That upstream leg has its own ISO 20022 message pair: pain.001 (Customer Credit Transfer Initiation) — the file or API call a treasury system, ERP, or corporate banking portal sends to request a payment — and pain.002 (Customer Payment Status Report) — the bank's structured reply. This reference covers both together because they are two ends of one exchange, not two separate subjects. For what happens once pain.001 becomes an interbank message, see SWIFT payment processing. This piece is about the initiation leg itself: what a corporate actually sends, what its bank sends back, and where operators most often misread the vocabulary.

Payments Initiation vs. Payments Clearing and Settlement

ISO 20022 organizes its message catalogue into business areas, and the one distinction that explains almost everything else about pain.001 and pain.002 is which area they sit in. pain.001 and pain.002 belong to Payments Initiation — the customer-to-bank space, governed for SEPA traffic by the European Payments Council's own implementation guidelines. pacs.008, pacs.002, and the rest of the interbank family belong to Payments Clearing and Settlement — the bank-to-bank space, governed separately (for SWIFT cross-border traffic) by CBPR+.

pain.001 is not a peer message to pacs.008 inside the same rulebook — it is the message that precedes and triggers one. A corporate never sends a pacs.008; a corporate sends a pain.001, and if the corporate's bank does not hold the beneficiary's account, that bank debits the corporate and sends a pacs.008 onward to move the funds the rest of the way. The distinction matters operationally: a treasury team investigating a rejected file is arguing with its own bank about the Payments Initiation rulebook — pain.002 status codes, CGI-MP or bank-specific field rules. A treasury team investigating a stalled cross-border wire after funds left the account is in pacs.008/pacs.002 territory instead, governed by a different rulebook the corporate's own bank did not author alone.

Who Sends What, and When

The exchange is straightforward once the business-area split is clear. The account owner — or a party the account owner has authorised — sends pain.001 to their bank. The bank replies with pain.002, reporting whether the file, or an individual transaction inside it, was accepted, rejected, or is still pending. Some corporate structures forward the pain.001 through an intermediate bank first: a Forwarding Agent that does not hold the debtor's account but relays the instruction on to the bank that does, typically because a corporate concentrates its payment initiation through one primary banking channel even when the accounts to be debited actually sit at several different banks. In that relay pattern, the reply travels back through the same chain — the debtor's bank sends pain.002 to the forwarding bank, and the forwarding bank sends its own pain.002 back to the corporate.

The reply is not always a single message. A bank can, and often does, send more than one pain.002 for the same file: an early one confirming the file passed technical and syntactical validation, and a later one — sometimes hours afterward — confirming the payment actually reached execution or final settlement. Treasury teams that treat the first pain.002 as the final word are the ones most often surprised when a payment they believed was confirmed turns out to have failed further downstream.

pain.001 Structure at a Glance

A pain.001 message is built from three nested blocks, and the split matters because it separates information that is true for the whole file from information that is true for one payment.

Group Header — one per message. Carries the message-level identifier (MsgId), the creation timestamp, an optional Authorisation element (relevant in relay and third-party-initiation scenarios, where it identifies the initiating party's authority to debit), the declared number of transactions, and a control sum used to catch transmission or truncation errors.

Payment Information — one or more per message, and this is the block that actually authorizes the debit. It carries PaymentInformationIdentification, a PaymentMethod fixed to TRF (credit transfer — the only value SEPA's implementation guidelines permit), an optional BatchBooking indicator that tells the bank whether to post the group as one lump entry or one entry per transaction, the requested execution date, and the debtor's identity, account, and bank.

Credit Transfer Transaction Information — one or more per Payment Information block, carrying the actual payment: InstructionIdentification (a point-to-point bank reference), EndToEndIdentification (the originator's own reference, meant to survive unchanged through the whole payment chain — including into the pacs.008 that pain.001 becomes), the amount, the charge-bearer code, and the creditor's identity, account, and bank.

Corporate file formats can pack many Payment Information and Credit Transfer Transaction Information blocks into a single pain.001 — this is exactly what enables payroll runs and supplier-payment batches. That freedom disappears the moment the instruction crosses into CBPR+ territory: under CBPR+'s usage guideline, both pain.001 and pacs.008 are restricted to a single transaction per message. A bulk pain.001 headed for cross-border execution does not survive as one message — it is decomposed into one pacs.008 per transaction on the far side.

pain.002: The Status-Code Lifecycle

pain.002 is where existing coverage of this message pair tends to stop short, and it deserves real depth because a corporate that only knows a bank rejected something — without knowing at what level — cannot fix the right thing.

A pain.002 message reports status at three separate levels, and a bank can report at any or all of them depending on what happened:

• Group Status — the whole file, inside OriginalGroupInformationAndStatus. If the entire file fails technical validation, this is the only level populated.
• Payment Information Status — one PaymentInformation block within the file, inside OriginalPaymentInformationAndStatus. Relevant when part of a batch fails while the rest proceeds.
• Transaction Status — one individual transaction, inside TransactionInformationAndStatus. The level operators usually care about most, since it tells a treasury team which specific payment in a large batch actually failed.

The codes themselves are drawn from ISO 20022's shared external Payment Transaction Status code list — the same list pacs.002 uses on the interbank side — and the set that actually appears in pain.002 traffic includes:

That last row is the one to remember: RJCT is the only status code any rulebook actually requires a bank to send. Everything else — ACTC, ACCP, ACWC, PDNG, ACSP, ACCC — is sent by bilateral agreement between the corporate and the bank, or dictated by what a specific bank's corporate portal chooses to expose. A bank is fully compliant if the only pain.002 status it ever sends is a reject; positive and interim statuses are a service-level choice, not a mandate. Do not assume a specific bank will report ACSP before ACCC, or report an interim status at all — check that bank's own implementation guide, not the ISO 20022 base standard, for what it actually sends.

The one status code the EPC's own SEPA rulebook governs in real detail is RJCT — because the EPC's Customer-to-PSP Implementation Guidelines scope pain.002 usage narrowly, as a reject-only dataset. When a SEPA payment is rejected, Original Message Name Identification must begin with pain.001, the relevant status field is set to RJCT, and Status Reason Information becomes mandatory so the corporate learns why. Positive SEPA status reporting back to the corporate is not something the EPC rulebook prescribes at all; banks that provide it — most do, in practice — are going beyond the SEPA scheme's own minimum requirement.

Where pain.001 Goes Next: The Handoff to pacs.008

Once a bank debits the account named in a pain.001, the instruction stops being a pain.001. If that bank also holds the beneficiary's account, it settles the payment internally and no interbank message is generated at all — an in-house book transfer. If it does not, the bank sends a pacs.008 to move the payment the rest of the way, and from that point the payment is governed by an entirely different rulebook — Payments Clearing and Settlement, CBPR+ for cross-border traffic — with its own status message, pacs.002, and its own field structure. For what specifically survives that handoff field-by-field — EndToEndId, UETR, charge-bearer codes — see the MT103 to pacs.008 field mapping reference; this article deliberately does not re-derive that mapping.

MT101, CBPR+, and the Relay Migration

Before pain.001, the SWIFT-network equivalent for a corporate requesting a bank transfer was MT101 — Request for Transfer. The MT to ISO 20022 equivalence tool tags this pair "close-functional" rather than "direct" for a specific reason: pain.001 is not a peer replacement inside the same rulebook the way pacs.008 replaced MT103. It sits in a different business area entirely, and the migration deadlines that apply to it are narrower than the blanket November 2025 CBPR+ cutover that retired MT103.

The deadline that actually binds is 14 November 2026, and it applies specifically to MT101 used as interbank relay traffic — the scenario where a forwarding bank passes an MT101 on to the debtor's own bank over the SWIFT network. Genuine corporate-to-bank MT101 origination — the SCORE and MA-CUG channels corporates use to reach their own bank directly — is not covered by that deadline at all; corporates using it are strongly encouraged, not required, to move to pain.001. Multi-instruction (bulk) MT101 relay traffic does not survive the cutover in translated form; from November 2026 it simply reaches end-of-life. Only single-instruction MT101 gets an automatic contingency conversion to pain.001, and that conversion carries its own additional validation and fees — not a clean like-for-like substitute.

Operators migrating file production from an older pain.001 version (v03, still common in legacy bank MIGs) to the CBPR+-designated v09 hit a specific, well-documented rejection cause: the BIC element renamed from <BIC> in v03 to <BICFI> from v09 onward. A payment engine still emitting the old tag name against a bank expecting v09 fails validation — not because the BIC value itself is wrong, but because the wrapping element name changed between versions. The other rejection source tied to this migration is address format: from 14 November 2026, a fully unstructured address is a rejection outright. The minimum a corporate needs to supply is a structured town name and country, or a hybrid format using up to two 70-character free-text address lines — free text alone no longer clears validation after that date.

Common Misunderstandings

"pain.001 is PSD2 payment initiation." It is not, and the two senses of "payment initiation" that share this phrase describe unrelated things. pain.001 is an ISO 20022 message format — a corporate or its ERP system builds a pain.001 file and sends it to a bank it already holds an account with, using whatever channel that bank offers. PSD2's payment initiation is a regulatory category: a licensed Third-Party Provider — specifically a PISP — initiates a payment from a customer's account at a different bank, using open banking APIs that bank is legally required to expose, typically without the customer ever handling a pain.001 file themselves. One is a message schema used inside a banking relationship a corporate already has; the other is a regulated third-party access right that exists precisely because the initiator does not have that relationship. Confusing the two sends an integration conversation toward the wrong specification entirely — a treasury team asking a bank about "payment initiation" almost certainly means pain.001 file specifications; a merchant asking a PSP about "payment initiation" almost certainly means PISP-based pay-by-bank checkout.

"pain.001 is a SEPA-only format." It isn't. SEPA's implementation guidelines are one profile of pain.001 among several — a corporate's file is just as validly a pain.001 addressed at a SEPA credit transfer, a CBPR+ cross-border correspondent-banking flow, a domestic Nordic payment, or a worldwide Request for Transfer routed through a bank's correspondent relationships. Bank corporate-access platforms document pain.001 usage across exactly that range of scope, not SEPA traffic alone.

Corporate and ERP Practical Implications

Batching. The Payment Information block's BatchBooking indicator tells the receiving bank whether to book the group as a single ledger entry or one entry per underlying transaction — a genuine choice with real reconciliation consequences, not just an operational nicety. Leave it unset and pre-agreed customer-to-bank conditions with that specific bank apply by default, which is its own reconciliation risk if treasury assumes a behaviour the bank never actually agreed to. And remember the CBPR+ ceiling above: batching only survives on the domestic/file-based leg. A bulk pain.001 destined for cross-border settlement gets decomposed into individual single-transaction pacs.008 messages regardless of how it was batched on the way in.

CGI-MP as the vendor-neutral layer. Banks do not implement raw ISO 20022 pain.001 — every bank publishes its own Message Implementation Guideline (MIG) layered on top of the base standard, and those MIGs are themselves built as an extension of the Common Global Implementation - Market Practice (CGI-MP) recommendations, a cross-bank effort to keep corporate-to-bank pain.001/pain.002 usage from fragmenting into as many dialects as there are banks. A corporate integrating with more than one bank should expect the base ISO structure to be identical and the bank-specific MIG layer — which fields are mandatory versus optional, which codes are actually supported — to differ, sometimes significantly, even between two banks that both claim CGI-MP conformance.

Common rejection causes. Beyond the version-migration BICFI/BIC rename and the pre-2026 address-format cutover already covered above, the recurring pattern across bank MIGs is consistent: PaymentMethod must be exactly TRF; NumberOfTransactions and the control sum must match what the file actually contains, or the whole group fails Group Status validation before a single transaction is even evaluated; and structured remittance references, when used, must match the specific document-type codes (CINV for a commercial invoice, CREN for a credit note) a bank's back office actually recognises rather than free-text equivalents. Every one of these fails at the Group or Payment Information level — meaning a single malformed field can reject an entire multi-transaction batch, not just the transaction it belongs to.

Related References

• SWIFT Payment Processing: MT103, ISO 20022, and gpi Explained — the cluster pillar for SWIFT mechanics and the broader ISO 20022 migration context
• MT103 to pacs.008 Field Mapping: The Operator Reference — the interbank leg pain.001 hands off to, field-by-field
• SEPA Credit Transfer, Instant, and Direct Debit: Operator Guide — where pain.001 sits inside SEPA scheme mechanics
• MT to ISO 20022 Equivalence Lookup — the MT101/pain.001 pair, and every other MT-to-ISO mapping, each tagged with an honest equivalence tier

For term definitions — ISO 20022, PSD2, TPP — see the Payments Glossary.