MT message structure
How an MT message is put together: five blocks, numbered field tags, and the references that let banks track one payment across many systems.
L0 Explain simply
An everyday analogy: an MT message is a letter written on a strict pre-printed form. The envelope says who sent it, who must receive it, and how urgent it is — that is the job of the headers. Inside, the form has numbered boxes, and every box has one fixed meaning: box 20 is always your reference, box 32A is always the date, currency, and amount. Stapled to the back is a slip the postal system uses for its own checks — the trailers. Because everyone fills in the same boxes the same way, a bank on one side of the world can read a form filled in on the other side without ever phoning to ask what a field means. That rigid sameness is the whole point of a message standard.
L1 Core concepts
An MT (message type) is identified by three digits — MT103, MT202, MT940 — where the first digit is the category: 1 for customer payments, 2 for financial institution transfers, 9 for cash management. Every MT message is built from up to five blocks. Block 1, the basic header, identifies the sender and the session. Block 2, the application header, carries the message type, the receiver, and the priority. Block 3, the optional user header, carries service data — most importantly field 121, the UETR, a unique end-to-end transaction reference that lets one payment be tracked across every bank it touches. Block 4 is the text: the business content, arranged as numbered fields. Block 5 holds trailers used for control and authentication.
L2 Practitioner view
Practitioners rarely read whole messages; they read the fields that matter for the problem in front of them. Block 2 answers "what is this and which direction did it travel" — an input message is one your institution sent, an output message is one it received. Field 20 in block 4 is the sender's reference, the key that queries, investigations, and returns are built around; banks downstream quote it in their own related-reference fields, chaining the journey together. The UETR does the same job network-wide and is what tracking tools query. When a message violates format rules, the network refuses it and the sender sees a negative acknowledgement — so a surprising share of exception work happens before a counterparty ever sees the payment. Screening and repair systems are, underneath, parsers of these same blocks and tags.
L3 Technical details
Block 1 (basic header) holds the service identifier, the sender's logical terminal address built on its BIC, and session and sequence numbers. Block 2 (application header) starts with I or O for input or output, then the three-digit message type, the counterparty address, and priority. Block 3 (user header) is a set of tagged sub-fields in braces; field 121 carries the UETR, formatted as a UUID. Block 4 (text) holds fields written as :tag:value — :20: sender's reference, :32A: value date as YYMMDD then currency then amount — with option letters changing a field's format: :50K: is the ordering customer as name and address lines, :50A: the account-plus-BIC form. Block 5 (trailers) carries control trailers such as checksums and possible-duplicate flags. Complete field specifications live in the SWIFT Standards MT documentation, which requires a swift.com account.
Sources & standards1
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Standards MT message format specifications
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.
L4 Standards & sources
The governing source is the SWIFT Standards MT documentation, published as part of the User Handbook on swift.com. It formally defines what this topic summarises: the block structure of every FIN message, a field dictionary per message type — each field's format, option letters, and presence rules — and the network-validated rules, each with its own error code, that the network enforces by rejecting a non-compliant message before delivery. The standard is versioned: changes flow through the annual Standards Release cycle, in which SWIFT publishes a Standards Release Guide describing the coming changes and every connected institution must adapt by the same activation date. In practice: check which Standards Release a specification belongs to, and remember the authoritative documents sit behind a swift.com account — public summaries, this one included, are not substitutes.
Sources & standards1
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Standards MT User Handbook; Standards Release Guide
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.
THE MESSAGE, BLOCK BY BLOCK
Block 1Basic headerSame on every message
Identifies the sender and the session — every FIN message starts here.
Mandatory
- Application ID
- Application ID. F — this is a FIN (financial application) message.
- Service ID
- Service ID. Identifies the SWIFT service carrying the message — ordinary FIN traffic vs. a system message.
- LT Address
- Logical Terminal Address. The sender's address, built on its BIC — which institution and which terminal sent this.
- Session Number
- Session Number. Identifies the logon session the message was sent in.
- Sequence Number
- Sequence Number. The message's position within that session — the network's own ordering check.
Block 2Application headerSame on every message
Says what this message is, which direction it travelled, and how urgent it is.
Mandatory
- I / O
- Input/Output Indicator. I — this institution sent it. O — this institution received it.
- Message Type
- Message Type. The three digits that name the message, e.g. 103, 202, 940.
- Address
- Destination / Origin Address. The counterparty's logical terminal address — who it went to (input) or came from (output).
- Priority
- Message Priority. S (System), N (Normal), or U (Urgent) — how the network should queue it.
Block 3User headerSame on every message
Optional service data — most importantly, the reference that tracks one payment across every bank it touches.
Optional
- 121
- UETR. The unique end-to-end transaction reference, formatted as a UUID — the same value a gpi Tracker queries across the whole payment chain.
- Other sub-fields
- Other service data. Additional tagged sub-fields the sending institution's service may require, such as a unique message reference.
Block 4TextChanges by message type
The business content, as numbered :tag: fields. The only block whose shape changes by message type — which tags appear is specific to the message. These are the ones you meet most; each message's own reference has the full, exact set.
Mandatory
- :20:
- Sender's Reference. The sender's own reference for the message — the key queries, returns, and reconciliation quote.
- :21:
- Related Reference. The reference of a related message this one answers or continues (e.g. the transaction being covered).
- :23B:
- Bank Operation Code. What kind of transfer this is; CRED marks an ordinary credit transfer.
- :32A:
- Value Date / Currency / Amount. When the money moves between the banks, in which currency, and how much settles.
- :33B:
- Currency / Instructed Amount. The originally instructed currency and amount, when different from what settles (with :36: the exchange rate).
- :50a:
- Ordering Customer. The party who orders and funds the payment (the debtor). The option letter — K, F, A — sets the format.
- :52a:
- Ordering Institution. The ordering customer's bank, when different from the sender.
- :56a:
- Intermediary Institution. A bank between the sender and the account-with institution in the chain.
- :57a:
- Account With Institution. The bank that holds the beneficiary's account.
- :59a:
- Beneficiary Customer. The party being paid (the creditor); account on the first line.
- :70:
- Remittance Information. Details passed to the beneficiary so they can reconcile the payment.
- :71A:
- Details of Charges. Who bears the charges: OUR, SHA, or BEN.
- :72:
- Sender to Receiver Information. Structured bank-to-bank instructions and codes.
Block 5TrailersSame on every message
Control data appended for integrity and duplicate detection — not part of the business content.
Optional
- CHK
- Checksum. Lets the receiver detect whether the message was corrupted in transit.
- PDE
- Possible Duplicate Emission. Flagged when a message is re-sent and might arrive twice, so the receiver can check before acting on it again.
- Other trailers
- Other control trailers. Additional trailers the network or a specific service may add.
| SWIFT MT | ISO 20022 MX | What lines up |
|---|---|---|
| Block 1 — Basic header | AppHdr (head.001) — Fr / To | Both identify sender and receiver, but MX's header is itself a registered ISO 20022 message that can wrap any payload, not a fixed transport preamble. |
| Block 2 — Application header | AppHdr (head.001) — MsgDefIdr | MT names the message by a 3-digit type in the header; MX names it by MsgDefIdr, the full message-definition identifier, e.g. pacs.008.001.08. |
| Block 3 field 121 — UETR | Document — transaction identification (e.g. UETR) | The same UETR value travels on both sides of a mixed MT/MX chain, but on the MX side it sits in the payload's transaction data, not in a separate header block. |
| Block 4 — Text | Document — the message body | Both carry the actual business content, but MT uses numbered :tag: fields; MX uses named, nested XML elements defined by the message's own schema. |
| Block 5 — Trailers | No equivalent block | MX has no in-message trailer. Integrity and duplicate detection are handled at the transport and business-application level instead of inside the message. |
Sources for the block anatomy3
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Standards MT message format specifications
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 · Business Application Header (head.001) message definition
Each message set is described by a Message Definition Report; earlier versions remain available in the ISO 20022 messages archive.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Field lists are the commonly-cited structural fields, not the full Standards MT field dictionary or ISO 20022 catalogue. The full specifications require a swift.com account (MT) or the iso20022.org e-repository (MX).
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.
Sources for this topic2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · Standards MT message format specifications
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.
- Simplified educational illustration
Payments Signal editorial teaching models — Payments Signal
What this simplifies: Block examples are abbreviated and several header sub-fields and trailer types are omitted for readability. The full Standards MT documentation, including every network-validated rule, requires swift.com access; this topic is a summary of its structure, not a substitute for it.
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.
Deepest material on this page: L4 — Standards & sources. Where a topic stops short of implementation depth, that is a deliberate coverage decision, not an oversight — see coverage.