MT103 vs pacs.008
The legacy Swift MT customer credit transfer and its ISO 20022 successor carry the same business event — a customer paying another customer across banks — in very different data structures.
| DIMENSION | MT103 | pacs.008 |
|---|---|---|
| Standard and syntax | Swift MT: a proprietary block-and-tag text format (blocks 1-5, fields like 20, 32A, 50a, 59a) maintained through Swift's annual standards releases. | ISO 20022: an open standard with an XML syntax generated from a formal data model; pacs.008 is the FI-to-FI customer credit transfer in the pacs family. |
| Party data | Ordering customer and beneficiary live in fields 50a and 59a as a handful of short text lines; structure depends on which option letter is used, and addresses are often free text. | Debtor, creditor, and their agents are dedicated structured elements with separate sub-elements for name, postal address parts, and identifiers — much easier for machines and screening engines to parse reliably. |
| Remittance informationHow much remittance data actually survives end to end depends on what each market infrastructure and usage guideline permits. | Field 70 offers a few lines of unstructured text — often too little for invoice-level detail, which then travels separately by email or portal. | Supports both unstructured and structured remittance elements with substantially more room, so invoice references can travel inside the payment. |
| Identifiers | Sender's reference in field 20, plus a unique end-to-end transaction reference (UETR) carried in the message header (block 3). | Multiple dedicated identifiers — instruction ID, end-to-end ID, transaction ID, and UETR — as named elements, so each party's reference survives the chain without overloading one field. |
| Charges representation | Field 71A carries the charge-bearer code (OUR, SHA, BEN); deducted charges appear in field 71F and related fields. | A ChargeBearer element carries the equivalent ISO codes (DEBT, SHAR, CRED, plus SLEV for scheme-governed charging), and charges information is carried in structured elements. |
| Where it is used today | Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions in November 2025, so MT103 is no longer the format for those flows on the Swift network; it survives in some domestic, legacy, and archive contexts. | The standard format for cross-border customer credit transfers on Swift under the CBPR+ usage guidelines, and for SEPA and most modernised market infrastructures (each with its own usage guideline). |
| Validation depth | Network validation checks field syntax and some cross-field rules, but much of the content is free text the network cannot police. | XML schema validation plus usage-guideline rules constrain structure and code values more tightly, catching more errors before they become repairs. |
| Translation and truncation riskThe academy's truncation-repair exception scenario walks through what operations teams do when translation loses data. | When an MT103 is translated into richer ISO structures, missing structure has to be inferred or left unstructured. | When a pacs.008 must be translated back to MT (or to a less permissive guideline), structured data may not fit the short MT fields and can be truncated — a known data-integrity and screening concern. |
Sources for this comparison4
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT103 message specification and coexistence timeline
Full field-level specifications live in the Swift Knowledge Centre User Handbook behind a swift.com login; content here relies on public summaries. Swift ended MT-to-ISO 20022 coexistence for in-scope cross-border payment instructions (for example MT103 and MT202) in November 2025; MT statement messages are being phased out on a separate timeline.
- Official requirement
ISO 20022 Catalogue of messages ↗ — ISO 20022 Registration Authority · pacs.008 message definition report
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Scheme-specific rule
Cross-Border Payments and Reporting Plus (CBPR+) usage guidelines ↗ — Swift (CBPR+ working group) · pacs.008 usage on the Swift network
Full guidelines require MyStandards access; content here relies on public summaries. MT-to-CBPR+ translation rules are published on Swift's translation portal.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Field-by-field equivalences are approximate: exact mappings depend on the message version, the applicable usage guideline, and published translation rules. Cells describe the general shape of each format, not a complete specification.
Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.