SWIFT / Learning brief
SWIFT MTs – Blocks 1 Through 5
Your notes
In simple terms / 01
What this means in plain language
Breaks a SWIFT MT message into its five blocks and explains the identifying, application, content, trailer, and user information they carry.
A SWIFT FIN MT message is organized into five logical blocks. The basic header identifies the sending interface and message context. The application header describes routing and message information. The user header can carry additional processing data. The text block contains the business fields for the specific MT type. The trailer holds security, validation, or system-related information when applicable. Reading the blocks separately helps technical and operations teams distinguish network envelope data from the actual payment instruction and troubleshoot a message without treating every element as customer content.
Complete lesson / 02
Understand the full idea, step by step
Post a parcel abroad and it travels wrapped in layers: an outer address label the courier reads, a customs slip, and inside, the letter meant only for the person who opens it. A SWIFT payment message is built the same way — layers, each read by a different reader. Learn the layers once and every MT message you ever open stops looking like a wall of colons and codes.
SWIFT FIN MT message — Message Type, carried on SWIFT's store-and-forward FIN service
SWIFT — the Society for Worldwide Interbank Financial Telecommunication — runs a secure network banks use to exchange structured messages. Its long-standing message format is called MT, for Message Type. Every FIN MT message is assembled from five numbered blocks. The first blocks are the envelope the network needs to move and identify the message; the later blocks carry the business content and its controls. Remember the guardrail from the start of the course: this message carries an instruction, not the money itself.
The five blocks at a glance
- Block 1 — Basic Header
- Who sent it and on which service — the sender's address and application details the network needs.
- Block 2 — Application Header
- What it is and where it goes — the message type (e.g. 103), the receiver, direction, and priority.
- Block 3 — User Header
- Optional extra handling data — references the banks add, including the end-to-end tracking reference (UETR).
- Block 4 — Text
- The payment itself — the tagged business fields: references, parties, amount, charges, routing.
- Block 5 — Trailer
- Controls — checksum and flags the network uses to confirm the message is complete and not a duplicate.
Envelope, letter, seal
Think of blocks 1 and 2 as the envelope: the address, the stamp, the routing the postal system reads to deliver it. Block 3 is a sticky note the banks add for their own handling. Block 4 is the letter — the actual message the receiving bank acts on. Block 5 is the seal that proves nothing was tampered with or lost. Separating them this way means network data and business data never blur into one undifferentiated string, and each part can be checked by the reader who owns it.
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
This is the whole message. The {1:...} and {2:...} at the top are blocks 1 and 2 — the envelope. {3:...} is the user header. Everything between {4: and the closing -} is block 4, the text: :20: is the sender's reference, :32A: packs value date, currency and amount together, :50K: is the ordering customer and :59: the beneficiary. Fictional parties and accounts throughout.
Reading one message, block by block
- MESSAGE
Block 1 (Basic Header): confirm who sent it. Bank Alfa's address and the FIN application identify the origin before anything business-related is read.
- MESSAGE
Block 2 (Application Header): read the message type and receiver. "103" says single customer credit transfer; the receiver address says Nordbank; direction says this is an input message Bank Alfa is sending.
- MESSAGE
Block 3 (User Header): pick up the tracking reference and any handling instructions the banks attached — present on modern payments, absent on some older messages.
- MESSAGE
Block 4 (Text): work the payment. Reference in :20:, amount in :32A:, ordering customer in :50K:, beneficiary in :59:, charges in :71A:. This is where Maya spends her time.
- MESSAGE
Block 5 (Trailer): let the controls confirm the message arrived whole and is not a duplicate before acting on it.
COMMON CONFUSION
“The five blocks are five separate messages stitched together.”
They are five parts of one message. A single MT103 opens with block 1 and ends with block 5's trailer; the blocks are layers of one document, not a bundle. Read out of order they still describe one instruction — but reading them in order tells you first how to route it, then what it says.
STRICTLY SPEAKING
Strictly speaking, block 3 is optional on the older MT formats, which is why some legacy messages have only four visible blocks — though on today's payment messages block 3 is required, because it carries the UETR, and block 5's trailer is added by the network rather than typed by a person. And this five-block shape belongs to SWIFT's FIN MT format specifically — the newer ISO 20022 MX messages you will meet later are XML with no block numbers at all. The blocks are how you read an MT, not how you read every payment message.
FOR NOW, REMEMBER
- A FIN MT message has five blocks: basic header, application header, user header, text, and trailer.
- Blocks 1 and 2 are the envelope the network routes on; block 4 is the payment content; blocks 3 and 5 are handling and controls.
- Block 4 holds the tagged business fields — references, parties, amount, charges — and is where operations reads the actual instruction.
- The blocks are five layers of one message, and this shape is specific to MT, not to ISO 20022 MX.
TRY IT YOURSELF
An MT103 Bank Alfa sent has been returned with a complaint that it reached the wrong institution. Maya wants to find the cause quickly. Which block should she read first?
You can now name the five blocks. Next, zoom into block 4 and learn to read a single field's specification — the :32A: and 4!a2!a2!c shorthand that tells you exactly what may go inside.
Key takeaways / 03
Three things to remember
- 01
The five blocks separate envelope, routing, business, and control data.
- 02
Block four normally contains the message-type business fields.
- 03
Not every block element is customer payment information.
Practical use cases / 04
Where you would use this
A developer parses an MT message into header, content, and trailer structures.
An operations analyst locates a business field without confusing it with routing data.
A support engineer diagnoses whether rejection relates to syntax, routing, or content.
Worked example / 05
Put the idea into a real situation
Illustrative example: an inbound MT103 fails validation. The support engineer first confirms the sender and application details in the early blocks, then checks the payment fields in block four and any control information in block five. A malformed beneficiary field points to business content, while a routing mismatch points elsewhere. Separating the layers lets the team assign the defect quickly and retain the original message for audit.
Evidence & review / 07
Evidence & review
SWIFT FIN MT messages (legacy MT format); not ISO 20022 MX.
What this brief simplifies: Treats the five blocks as fixed layers and uses a single fictional MT103; real FIN adds session/sequence controls, service messages, and network-added trailers not shown.
Sources for this brief2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · FIN message block structure
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
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.