ISO 20022 pain.001 Explained + Builder

The message behind modern payments

When a business initiates a credit transfer — payroll file, supplier payment, SEPA batch — the instruction increasingly travels as an ISO 20022 pain.001 message: an XML document whose name literally means "payment initiation." It is replacing the decades-old SWIFT MT format across the world's payment systems: SEPA in Europe, CHAPS in the UK, FedNow and the ISO migration in the US, RTGS systems across Asia and the Gulf.

The structure is hierarchical and worth internalizing once:

<Document>
  <CstmrCdtTrfInitn>
    <GrpHdr>      — message-wide: ID, creation time, number of transactions, control sum
    <PmtInf>      — payment block: method, batch booking, requested execution date
      <PmtTpInf>  — service level (SEPA, URGP), local instrument
      <Dbtr>      — the payer: name, IBAN, BIC
      <DbtrAgt>   — the payer's bank (BIC)
      <CdtTrfTxInf> — one per payment:
        <Amt>     — amount and currency
        <CdtrAgt> — beneficiary bank
        <Cdtr>    — beneficiary name and IBAN
        <RmtInf>  — remittance reference (what the beneficiary sees)

The fields that actually cause rejections

GrpHdr/CtrlSum and NbOfTxA must match the sum and count of the transactions below. A mismatch is an automatic schema rejection — and the easiest bug to introduce when generating files by hand.
IBAN checksums. Every beneficiary IBAN carries a mod-97 checksum; a typo is caught by the bank, but catching it before submission saves a day of payment ops ping-pong.
Service level vs. currency. SEPA service level with a non-EUR currency is rejected. URGP (instant) has amount caps per scheme that change periodically.
Character sets. pain.001 has a restricted business character set — some valid XML characters are invalid in names and remittance text, and banks differ in strictness.
Dates. ReqdExctnDt in the past bounces; some schemes require it to be a business day.

Build one without uploading your payment data

Payment files describe your company's money movements — counterparties, amounts, payroll patterns. Generating them through a web service means handing that picture to a third party. A browser-based builder changes the trust model: fill in debtor, creditor, amount, and purpose; the XML generates in your tab and goes nowhere except your clipboard.

The pain.001 Builder does exactly this — SEPA service levels, purpose codes, and valid XML out. Validate existing messages with schema-aware checks in the ISO 20022 Validator before they go to the bank. Both run 100% client-side.