pain.001 Structure: The Fields That Actually Matter

A pain.001 file has exactly three levels — a GroupHeader that identifies the message, one or more PaymentInformation blocks that carry the debit side, and inside each of those one or more credit transfer transactions that carry the credit side — and once that shape clicks, most of the mapping work becomes deciding which level each piece of your payment data belongs to. This is the field-level companion to the pain.001 and pain.002 overview: that post explains what the messages are; this one opens the file. I've mapped this format against enough bank implementation guides to know that the ISO definition is the easy half — so alongside the standard structure I'll show where a real bank guide (Nordea's, one of the few you can actually read without an NDA) narrows, repurposes or rejects what the schema allows.

The three levels

The message is CustomerCreditTransferInitiation — root element <CstmrCdtTrfInitn>. Nordea's implementation guide describes the shape exactly as the standard has it: one message per file, built from three blocks.

• GroupHeader <GrpHdr> — occurs once (1..1). Identifies the message as a whole: who sent it, when, how many transactions, checksum.
• PaymentInformation <PmtInf> — occurs one or more times (1..n). The debit side: which account pays, at which bank, on which date, by which method. Everything shared by a group of payments lives here.
• CreditTransferTransactionInformation <CdtTrfTxInf> — occurs one or more times (1..n) inside each PaymentInformation. The credit side: who gets paid, how much, in what currency, with what reference and remittance detail.

The mental model that survives contact with real files: the envelope, the debit, the credits. One file can pay 3 invoices from your EUR account today and 200 salaries from your SEK account on Friday — that's one GroupHeader, two PaymentInformation blocks, 203 transactions. A message can even mix several debtors and accounts, one PmtInf each.

Here is an illustrative skeleton assembled from the elements in Nordea's pain.001.001.03 guide. It is not a bank-ready file — mandatory identifiers, agreement references and country rules are omitted — but every tag name is real:

<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pain.001.001.03">
  <CstmrCdtTrfInitn>
    <GrpHdr>
      <MsgId>ACME-20260802-0001</MsgId>
      <CreDtTm>2026-08-02T09:30:00+02:00</CreDtTm>
      <NbOfTxs>2</NbOfTxs>
      <CtrlSum>15000.00</CtrlSum>
      <InitgPty><Nm>ACME TREASURY</Nm></InitgPty>
    </GrpHdr>
    <PmtInf>
      <PmtInfId>ACME-20260802-0001-01</PmtInfId>
      <PmtMtd>TRF</PmtMtd>
      <BtchBookg>true</BtchBookg>
      <ReqdExctnDt>2026-08-03</ReqdExctnDt>
      <Dbtr><Nm>ACME Oy</Nm></Dbtr>
      <DbtrAcct><Id><IBAN>FI0000000000000000</IBAN></Id></DbtrAcct>
      <DbtrAgt><FinInstnId><BIC>NDEAFIHH</BIC></FinInstnId></DbtrAgt>
      <ChrgBr>SLEV</ChrgBr>
      <CdtTrfTxInf>
        <PmtId>
          <InstrId>INV-4711-P2P</InstrId>
          <EndToEndId>INV-4711</EndToEndId>
        </PmtId>
        <Amt><InstdAmt Ccy="EUR">7500.00</InstdAmt></Amt>
        <CdtrAgt><FinInstnId><BIC>NDEADKKK</BIC></FinInstnId></CdtrAgt>
        <Cdtr><Nm>Supplier A/S</Nm></Cdtr>
        <CdtrAcct><Id><IBAN>DK0000000000000000</IBAN></Id></CdtrAcct>
        <RmtInf><Ustrd>Invoice 4711</Ustrd></RmtInf>
      </CdtTrfTxInf>
      <!-- more <CdtTrfTxInf> blocks -->
    </PmtInf>
    <!-- more <PmtInf> blocks -->
  </CstmrCdtTrfInitn>
</Document>

One detail worth noticing before any field: the namespace is the version. Nordea's guide is explicit that the xmlns value — urn:iso:std:iso:20022:tech:xsd:pain.001.001.03 — is what identifies the pain.001 version of the message. If your file says one version and your mapping was built for another, nothing else on this page matters yet.

GroupHeader: the fields banks validate first

Four elements do the work here, and they're the ones a status report will quote back at you.

• <MsgId> (MessageIdentification, 1..1, max 35 characters) — your identifier for the whole message. Textbook: a unique reference. Reality: it's your idempotency key. Nordea requires it to be unique per customer for a minimum of 90 calendar days and uses it for duplicate control — send the same MsgId twice and the second file is treated as a duplicate, which is precisely the behaviour you want when a host-to-host channel retries an upload. Generate it from your payment run, not from a timestamp someone can regenerate.
• <CreDtTm> (CreationDateTime, 1..1) — when the message was created, as an ISO date-time. Not free of validation either: Nordea accepts values back to current date minus 30 calendar days. A test file with last quarter's timestamp fails before anyone looks at a payment.
• <NbOfTxs> (NumberOfTransactions, 1..1) and <CtrlSum> (ControlSum, 0..1) — the transaction count and the hash total of the instructed amounts, irrespective of currency. The count is validated and the whole message is rejected if it's wrong; the control sum is optional, but if you send it, it's checked with the same consequence. Send it anyway. A rejected file at the gate is cheap; a half-imported one is not.
• <InitgPty> (InitiatingParty, 1..1) — who initiated the message, which can be the debtor or a party acting on its behalf: this is where a shared-service centre or payment factory sending on behalf of subsidiaries identifies itself. At Nordea it identifies the signer of the message and comes back in the status report.

PaymentInformation: the debit side

This level answers: from which account, at which bank, on what date, by what method — for every transaction grouped under it.

• <PmtInfId> (1..1, max 35) — the batch reference. Same 90-day uniqueness and duplicate control at Nordea as MsgId, and it's echoed in the pain.002 status report and — if you use the bank's reporting — on the account statement. That echo is what stitches a statement debit back to a payment run, so treat the naming scheme as reconciliation design, not as a filler field.
• <PmtMtd> (PaymentMethod, 1..1) — TRF for credit transfer; Nordea also accepts CHK for cheque payments, with country-specific rules about when each is allowed. If you're wondering who still pays by cheque: the field exists because someone does.
• <BtchBookg> (BatchBooking, 0..1) — true requests one batch booking for the transactions under this PmtInf; false requests single bookings. Omit it and the bank's default applies — at Nordea, batch booking for domestic payments, with the cross-border behaviour in a country appendix, and no batch booking at all for relayed Request for Transfer instructions. This single optional flag decides whether your statement shows one consolidated debit or two hundred lines, which is to say it decides how your reconciliation works. Agree it per bank, explicitly.
• <ReqdExctnDt> (RequestedExecutionDate, 1..1) — the date the payment should be debited and processed, funds permitting. All transactions under one PmtInf share it — which is the main reason files get split into multiple PmtInf blocks in the first place.
• <Dbtr> / <DbtrAcct> / <DbtrAgt> — debtor, debtor account, debtor agent, all 1..1. The trio looks trivial and is where the bank-specific rules cluster. Nordea requires the debtor's name but then replaces it with the account holder name from its own records for payments it executes. The account is IBAN or a local format under <Othr> — except Finland, where only IBAN is allowed — and the account currency must be present. The debtor agent takes a BIC — except Sweden, where a clearing-system code is an alternative. Three fields, three asterisks, one bank.
• <ChrgBr> (ChargeBearer, 0..1) — who pays the charges: DEBT, SHAR or SLEV in Nordea's guide (the schema also knows CRED; this guide doesn't offer it — an example of a MIG narrowing the standard). Two rules worth memorising: it belongs on either the payment level or the transaction level but not both, and within the EU/EEA only SHAR or SLEV are accepted — send DEBT on an intra-EU payment and it's a rejection, not a warning.

Same either-level-but-not-both logic applies to <PmtTpInf> (PaymentTypeInformation — service level, instruction priority, category purpose such as SALA for salaries, which at Nordea is payment-level only) and <UltmtDbtr> (UltimateDebtor — on-behalf-of payments; supplying it on both levels gets the file rejected). The pattern to internalise: anything at PaymentInformation level applies to every transaction beneath it, and banks police the redundancy.

CreditTransferTransactionInformation: the credit side

One block per payment. The fields your accounts-payable data actually populates:

• <PmtId> with <InstrId> (0..1) and <EndToEndId> (1..1) — two references with different lifespans. InstructionIdentification is your point-to-point reference to the bank. EndToEndIdentification travels with the payment: it comes back in the pain.002 status report, in camt.054 debit notifications, and on statements — it's the single field that lets a status or a statement line find its way back to an invoice. Nordea requires it unique per customer for 90 calendar days and runs transaction-level duplicate control on it. The honest caveat, straight from the same guide: it is not forwarded on every domestic or international rail, because some local clearings and SWIFT-era infrastructure can't carry it. Design your reconciliation to prefer it, not to depend on it existing everywhere.
• <Amt> (1..1) — one of two shapes: <InstdAmt Ccy="...">, the amount in the currency the beneficiary should receive, or <EqvtAmt> — amount plus <CcyOfTrf> — for "debit my account for the equivalent of X in transfer currency Y", which Nordea allows only for cross-currency payments. Negative amounts are rejected; decimal and digit limits vary by payment type and country. If you've never seen EquivalentAmount used, you haven't done a cross-currency payment run where the budget was fixed in the debit currency.
• <CdtrAgt> (0..1 here — conditional, not blindly mandatory) — the beneficiary's bank, as a <BIC> or as a clearing-system code plus bank name: Nordea's list includes USABA (US routing number), GBDSC (UK sort code), AUBSB, CNAPS and others. And a rule that surprises people: for SEPA payments identified by IBAN, the creditor agent is ignored — the IBAN already routes the payment.
• <Cdtr> / <CdtrAcct> — the beneficiary and their account. Name and country are required; cross-border payments need the town as well, and since the structured-address push you should assume address rules are tightening everywhere, not just here. The account is an <IBAN> — mandatory within the EU/EEA for cross-border and SEPA payments in Nordea's guide — or an <Othr> identification for local schemes, including proprietary codes like BGNR (Swedish bankgiro) and OCR (Denmark). If you thought pain.001 abolished local account formats, the schema disagrees.
• <RmtInf> (RemittanceInformation, 0..1) — what the beneficiary sees, and the field with the widest gap between schema and reality. Structurally: <Ustrd> free text (each occurrence max 140 characters) or <Strd> with referred documents (CINV invoice / CREN credit note, with number and amount) or a creditor reference (SCOR, e.g. an ISO 11649 RF reference). The schema says 0..n occurrences; Nordea's per-country reality says: Denmark up to 1,435 characters of free text, Norway 875, Sweden 140, international payments one occurrence of 140 — and if structured remittance is present, unstructured is dropped. Whatever your ERP exports, the rail decides what arrives. This is exactly the "richer data" that makes ISO 20022 worth adopting — when you actually populate the structured elements instead of pasting invoice lists into free text that gets truncated at the border.

Where banks fight over the same schema

Everything above came from one bank's implementation guide, and that's the point: pain.001 is a schema, but a payable file is a schema plus a MIG. Nordea's guide states openly that elements the service doesn't use are left out of the guide entirely, even when the ISO message definition and the CGI-MP implementation guide include them. Every bank does a version of this. The recurring fight zones, all visible in this walkthrough:

• Identification style. BIC vs clearing codes vs IBAN-only routing; which local account formats are allowed where.
• Level discipline. Charge bearer, payment type information and ultimate debtor accepted at payment level, transaction level, or either-but-not-both — with rejection as the penalty for both.
• Defaults. Batch booking, service levels and charge codes all have bank defaults that apply when you're silent, and they differ per bank and per country.
• Field length and content. Remittance limits per country; characters like ¤, - and / that Nordea warns it will convert to spaces to avoid clearing rejections. Your reference format survives some rails and not others.
• Regulatory add-ons. <RgltryRptg> (RegulatoryReporting) is optional in the schema and mandatory at Nordea for international payments above 100,000 NOK from Norway or 150,000 SEK from Sweden. The schema can't tell you that; only the MIG can.

And it isn't only banks: schemes layer rules on top too. In SWIFT's CBPR+ Standards Release 2026, change request CR 3014 formalises a rule that the PaymentInformationIdentification must match the MessageIdentification in the GroupHeader for the interbank pain.001 relay — a constraint no schema validator would ever tell you about. CGI-MP exists precisely to shrink this variation in the corporate-to-bank space, and guides like Nordea's are written against it; it narrows the fight, it doesn't end it.

Versions, and the pain.002 echo

Two closing facts that save arguments. First, versions: Nordea's guide implements pain.001.001.03, the CustomerCreditTransferInitiationV03 defined in the 2009 payments maintenance that CGI-MP built its recommendations on — while the ISO 20022 catalogue is now at pain.001.001.13 (CustomerCreditTransferInitiationV13), with older versions kept in the message archive and communities encouraged toward recent ones. In the corporate-to-bank world you will meet old versions for years; the namespace tells you which one you're holding, and your bank's MIG tells you which one to send. The interbank world moves on its own clocks — including the MT101 relay's retirement into a pain.001 relay in November 2026.

Second, the identifiers are the contract with pain.002. Nordea's reference table maps them one-to-one: MsgId, PmtInfId and EndToEndId each come back at the corresponding level of the status report, and PmtInfId and EndToEndId flow onward into camt.054 debit notifications. That's the field-level answer to "pain.001 vs pain.002": the same three references, outbound and inbound. Design them well in the pain.001 and the status handling builds itself; design them lazily and every rejection becomes a research project.

What usually goes wrong

• Timestamps and counts treated as decoration. CreationDateTime outside the accepted window, NbOfTxs off by one, a stale MsgId — all message-level rejections before a single payment is looked at.
• Duplicated levels. Charge bearer or ultimate debtor on both payment and transaction level; some banks reject the file for redundancy the schema happily allows.
• Assuming EndToEndId always arrives. It's the backbone reference, and some rails still drop it. Check per payment type, not per bank.
• One mapping for all banks. The schema is shared; the MIGs aren't. Budget a mapping-and-test cycle per bank, same as any connectivity project.
• Remittance built for the schema, not the rail. 999 structured occurrences validate beautifully and arrive as 140 truncated characters.

The structure is genuinely simple — envelope, debit, credits. The craft is in respecting what each bank's guide does to it.

See also the pain.001 and pain.002 overview, the ISO 20022 migration from MT to MX, and MT101 vs MT103 vs MT202.