ISO 20022 Message Builder

MT → MX training aid · CBPR+ rules

A quick orientation to the ISO 20022 payment messages, how they fit together, and exactly what the rules in this builder are based on. Switch back with the Guide button to start building.

High-level workflow

1 · Initiate

pain.001

A customer (or corporate) instructs their own bank to make a payment. Customer-to-bank — the payment hasn't entered the interbank world yet.

2 · Clear & settle

pacs.008pacs.009pacs.009 COV

Bank-to-bank. The money actually moves — serially (each agent forwards it) or by the cover method (customer detail one way, funds another).

3 · Confirm or fix

pacs.002pacs.004camt.056camt.029

Status back, or something went wrong. Timing decides the message: reject before settlement, return after, recall to request cancellation.

4 · Report

camt.052camt.053camt.054

What hit the account — intraday reports, end-of-day statements and single-entry notifications, used to reconcile the nostro.

🔗 One UETR threads every step. The Unique End-to-end Transaction Reference assigned at step 2 reappears as OrgnlUETR in every exception message and in the statement entry — it is what lets ops link a recall, a return and a statement line back to the original payment automatically.

The messages, briefly

Message	Full name	What it does	MT equivalent
Initiation — customer to bank
pain.001built	CustomerCreditTransferInitiation	A customer instructs their bank to pay someone. Carries the debtor, creditor, amount and requested execution date.	MT101
Clearing & settlement — bank to bank
pacs.008built	FIToFICustomerCreditTransfer	The workhorse cross-border payment: a customer payment moving between banks. Debtor and creditor are customers.	MT103
pacs.009built	FinancialInstitutionCreditTransfer	A bank moving its own funds. Debtor and creditor are financial institutions, not customers.	MT202 / MT205
pacs.009 COVbuilt	…with UndrlygCstmrCdtTrf	The cover leg that funds a customer transfer, carrying the underlying customer details inside it — so screening can still see them.	MT202COV
Exceptions & investigations
pacs.002built	FIToFIPaymentStatusReport	Reports the status of a payment. RJCT rejects it (before settlement); ACSP/ACSC/ACCC confirm progress.	—
pacs.004built	PaymentReturn	Sends the money back after it has settled, often net of a return charge, with the chain reversed.	MT103 RETN
camt.056built	FIToFIPaymentCancellationRequest	Asks to cancel/recall a payment. Opens a case — it does not itself move any money.	MT192 / MT292
camt.029built	ResolutionOfInvestigation	Answers a camt.056: CNCL (cancelled), RJCR (refused) or PDCR (pending). The funds themselves come back via pacs.004.	MT196 / MT296
pacs.028reference	FIToFIPaymentStatusRequest	Chases a payment whose status you haven't seen — "where is it?". The answer arrives as a pacs.002.	—
Cash management & reporting
camt.052reference	BankToCustomerAccountReport	Intraday / interim report. Balances may still be provisional.	MT941 / MT942
camt.053reference	BankToCustomerStatement	End-of-day statement — the definitive booked position. Carries the UETR into the entry, which is the reconciliation prize.	MT940 / MT950
camt.054reference	BankToCustomerDebitCreditNotification	Advice of a single debit or credit as it happens.	MT900 / MT910
camt.057reference	NotificationToReceive	"Expect these funds" — pre-advice so the receiver can manage liquidity.	MT210

built = you can generate it here. reference = defined for context; not generated by this tool.

What this is based on

Standard & scheme

ISO 20022 is the base standard — it defines each message's elements, data types and cardinality (the MDR and XSD schema published on iso20022.org).
CBPR+ (Cross-Border Payments and Reporting Plus) is the SWIFT community usage guideline that restricts the base for cross-border traffic — removing elements, tightening cardinality and subsetting code lists.
This builder targets CBPR+ SR2025. The mandatory markers (*) reflect the CBPR+ rules, which are stricter than base ISO — e.g. UETR, settlement date and structured Town/Country are required here but optional in the raw standard.
Every message is wrapped by a Business Application Header (head.001) carrying Fr/To, the message definition and the business service.

Versions generated

pain.001: pain.001.001.09
pacs.008: pacs.008.001.08
pacs.009 / COV: pacs.009.001.08
pacs.002: pacs.002.001.10
pacs.004: pacs.004.001.09
camt.056: camt.056.001.08
camt.029: camt.029.001.09
Header: head.001.001.02
Service: swift.cbprplus.03

Taken from SWIFT's official SR2025 sample messages. Use the version selector if your scheme or validator expects different ones.

Scope & accuracy. This is a training aid. It generates well-formed, CBPR+-shaped messages with a practical subset of fields — not every element in the full usage guideline. ISO 20022 versions, scheme deadlines and mandatory-field rules change with each annual Standards Release, so confirm anything version- or date-sensitive against iso20022.org, SWIFT MyStandards or your scheme rulebook, and validate production messages in the SWIFT Readiness Portal before relying on them.

version

ℹ️ Mandatory (*) reflects CBPR+ usage-guideline rules, which tighten the base ISO standard (e.g. UETR, settlement date and structured Town/Country become required). The output is a valid single-root Document; the AppHdr is a separate view (they travel together but aren't one XML root). If your validator rejects a version, switch it with the version selector. Teaching aid — validate production messages in the SWIFT Readiness Portal.

—

required 0/0 errors 0

Select a message type and fill the fields…

Output is the Document (single well-formed root); switch to AppHdr or Envelope in the output bar. Defaults use the coherent CBPR+ set (pain.001.001.09 · pacs.008.001.08 · pacs.009.001.08 · BAH head.001.001.02 · BizSvc swift.cbprplus.03) — use the version selector to match your validator/scheme. Confirm the current release on MyStandards. [VERIFY]