Payment Message Explorer
Click any highlighted value in the message to see what it means and why it actually matters — not just its technical name. Everything runs in your browser; nothing here is sent anywhere.
Version matters. This is pain.001.001.03 (ISO 20022 Customer Credit Transfer Initiation, message definition version 3) — a version still widely accepted by European banks, though many have since moved on to later versions such as .09. The official ISO 20022 catalog publishes multiple versions of every message. A generic example like this one is for learning the structure — always confirm the exact version and rulebook your bank actually requires before building an interface against it.
<Document>
<CstmrCdtTrfInitn>
<GrpHdr>
<MsgId>MSG-2026-03-14-0091</MsgId>
<CreDtTm>2026-03-14T09:12:03+01:00</CreDtTm>
<NbOfTxs>1</NbOfTxs>
<InitgPty><Nm>Acme Treasury Center BV</Nm></InitgPty>
</GrpHdr>
<PmtInf>
<PmtInfId>PMTINF-0091-001</PmtInfId>
<PmtMtd>TRF</PmtMtd>
<ReqdExctnDt>2026-03-16</ReqdExctnDt>
<Dbtr><Nm>Acme Manufacturing Europe BV</Nm></Dbtr>
<DbtrAcct><Id><IBAN>NL91ABNA0417164300</IBAN></Id></DbtrAcct>
<DbtrAgt><FinInstnId><BICFI>ABNANL2A</BICFI></FinInstnId></DbtrAgt>
<CdtTrfTxInf>
<PmtId><EndToEndId>INV-2026-4471</EndToEndId></PmtId>
<Amt><InstdAmt Ccy="EUR">12450.00</InstdAmt></Amt>
<CdtrAgt><FinInstnId><BICFI>RABONL2U</BICFI></FinInstnId></CdtrAgt>
<Cdtr><Nm>Bergman Freight & Logistics NV</Nm></Cdtr>
<CdtrAcct><Id><IBAN>BE68539007547034</IBAN></Id></CdtrAcct>
<RmtInf><Ustrd>Invoice 4471 / PO 88213</Ustrd></RmtInf>
</CdtTrfTxInf>
</PmtInf>
</CstmrCdtTrfInitn>
</Document>Synthetic example — no real account, name, or reference.
A unique identifier your system assigns to this entire file, not to one payment.
Why it matters: Your bank uses this to acknowledge or reject the whole batch. If you resend a file, reusing this ID can get it rejected as a duplicate — that's often the first thing to check when a bank says "already received."
When your system generated the file — not when it was sent, and not when payments execute.
Why it matters: Banks sometimes reject files where this is too far in the past or future relative to their receipt time. Worth asking your bank what tolerance they allow.
A count of how many individual payments are in this file.
Why it matters: The bank validates this against what it actually finds in the file. A mismatch here is a common, blunt reason for a whole-file rejection — worth checking first if a batch bounces.
The legal entity or shared service center that is submitting the file — not necessarily the account holder.
Why it matters: In a payment factory or SSC setup, this is often different from the debtor further down. If your bank's portal shows an unexpected "submitted by" name, this is the field to check.
An identifier for one batch of payments inside the file that share the same debtor account and execution date.
Why it matters: One file can carry several of these blocks — e.g. one per paying account or per value date. If only part of a file fails, it usually fails at this level, not the whole message.
The instruction type — TRF means a standard credit transfer (as opposed to e.g. a direct debit collection).
Why it matters: pain.001 is built for credit transfers. If you need direct debits, that's a different message (pain.008) — a common early confusion when a TMS vendor says "we support ISO 20022" without saying which message.
The date you are asking the bank to execute the payment — a request, not a guarantee.
Why it matters: Cut-off times, currency, and cross-border routing can all push actual execution later. Worth confirming your bank's cut-off rules for this payment type before assuming this date holds.
The account holder the money is paid from — the legal owner of the debit account below.
Why it matters: Must match what the bank has on file for that account. A mismatch (e.g. an old legal name after a merger) is a frequent, easily-missed rejection cause.
The account the payment is debited from, in IBAN format.
Why it matters: This is the account your bank actually charges — worth double-checking it's the account you think it is, especially in multi-entity or pooling structures where several accounts look similar.
The BIC of the debtor's own bank — usually the bank you're sending this file to.
Why it matters: Redundant with who you sent the file to, but the bank still validates it. A stale BIC (e.g. after a bank merger) is a real, if uncommon, source of straight-through-processing failures.
An identifier that is meant to survive the entire payment chain, bank to bank, unchanged — often your own invoice or reference number.
Why it matters: This is what usually comes back on the bank statement (camt.053) so you can automatically match the payment to what you sent. If reconciliation keeps needing manual matching, check whether this value is actually surviving the trip.
The amount and currency you are instructing to be paid — before any deduction of charges.
Why it matters: If the beneficiary receives less than this, that's a charges/fee question (who absorbs bank charges), not a data error in this field. Worth checking the separate charge-bearer field, not shown here, if that comes up.
The BIC of the beneficiary's bank.
Why it matters: For cross-border or non-SEPA payments this can also carry routing/correspondent information not shown in a plain pain.001 example — one reason international payments need more upfront clarification than domestic ones.
The beneficiary — who the bank believes it is paying.
Why it matters: Some banks and payment schemes now run automated "confirmation of payee" name-matching against the IBAN below. A near-miss name (abbreviation, trading name) can trigger a warning or delay.
The account the payment is credited to.
Why it matters: The single field most worth a second pair of eyes before release — it's also the field targeted by invoice-fraud schemes that ask you to "update our bank details."
Free-text (unstructured) information about what the payment is for, passed through to the beneficiary.
Why it matters: This is what the beneficiary's AR team sees, and often what your own reconciliation tooling parses to match a payment to an invoice. There's also a structured remittance option (not shown here) — ask your bank and TMS vendor which one they actually support end to end.