An MT message consists of up to five blocks, identified by numbers and enclosed in curly braces {}.
{1: Basic Header Block}
{2: Application Header Block}
{3: User Header Block}
{4: Text Block}
{5: Trailer Block}
Each block:
- has a fixed role,
- follows specific structural rules,
- and is processed by different layers of the messaging stack.
Block 1 – Basic Header Block
Network Identity and Session Control
Block 1 identifies the sending institution and the SWIFT session used to transmit the message.
Purpose
- Identifies the sender’s logical terminal
- Establishes session and sequence context
- Enables network-level tracking and uniqueness
Characteristics
- Mandatory
- Fixed structure
- Generated by the sending system
- No business data
Contains (High-Level)
- Application identifier
- Service identifier
- Sender logical terminal
- Session number
- Sequence number
Field Structure
| Position | Tag/Field | Mandatory/Optional | Description | Data Type/Format | Example |
| a | Block Identifier | Mandatory | Fixed value indicating the Basic Header Block. | 1x (numeric) | 1 |
| b | Application Identifier | Mandatory | Identifies the application (e.g., FIN for user-to-user messages). | 1a (char) | F |
| c | Service Identifier | Mandatory | Specifies the service type (e.g., 01 for FIN user-to-user). | 2n (numeric) | 01 |
| d | LT Identifier (Logical Terminal Address) | Mandatory | Sender’s LT for input messages or receiver’s for output; 12-character BIC + LT code (8+1+3 format). | 12x (alphanumeric) | CITIFRPPAXXX |
| e | Session Number | Mandatory | Identifies the current FIN session (4 digits). | 4n (numeric) | 0070 |
| f | Sequence Number (ISN/OSN) | Mandatory | Unique 6-digit sequence for input (ISN) or output (OSN) session. | 6n (numeric) | 970817 |
Full example: {1:F01CITIFRPPAXXX0070970817}
Block 2 – Application Header Block
Message Direction, Type, and Routing
Block 2 defines how the message flows through SWIFT.
It exists in two variants:
- Input (I) – when a message is sent to SWIFT
- Output (O) – when a message is delivered by SWIFT
Purpose
- Defines message direction
- Identifies message type (MT103, MT202, etc.)
- Specifies sender/receiver context
- Controls message priority
Characteristics
- Mandatory
- Direction-dependent structure
- Partially generated by SWIFT (Output)
- Used heavily in investigations and tracing
Contains (High-Level)
- Direction indicator (I / O)
- Message type
- Logical terminal (receiver or sender reference)
- Priority
- Delivery timestamps (Output only)
- Message Input Reference (Output only)
Input Format Fields (to SWIFT)
| Field | Tag/Name | Mandatory/Optional | Description | Data Type/Format | Example |
| 1 | Input/Output ID | Mandatory | Identifies direction to SWIFT (‘I’ for input). | 1a | I |
| 2 | Message Type | Mandatory | 3-digit SWIFT MT identifier (e.g., 101 for MT101). | 3n | 103 |
| 3 | Destination Address | Mandatory | Receiver’s 12-char LT address (BIC + LT code). | 12x | NDEANOKKBXXX |
| 4 | Priority | Optional | Delivery priority: S (system), N (normal), U (urgent). | 1a | U |
| 5 | Delivery Monitoring | Optional | Monitoring: 1 (warning), 2 (notification), 3 (both). | 1n | 3 |
| 6 | Obsolescence Period | Optional | Delay time in 5-min units before DLM/warning (003=15min U, 020=100min N). | 3n | 003 |
Full input example: {2:I103NDEANOKKBXXXU3003}
Output Format Fields (from SWIFT)
| Field | Tag/Name | Mandatory/Optional | Description | Data Type/Format | Example |
| 1 | Input/Output ID | Mandatory | Identifies direction from SWIFT (‘O’ for output). | 1a | O |
| 2 | Message Type | Mandatory | 3-digit SWIFT MT identifier. | 3n | 103 |
| 3 | Input Time | Mandatory | Sender’s local input time (HHMM). | 4n | 1734 |
| 4 | Message Input Reference (MIR) | Mandatory | 28-char ref: date (6n) + sender LT (12x) + session (4n) + seq (6n). | 28x | 150713NDEANOKKBXXX0073969842 |
| 5 | Output Date | Mandatory | Receiver’s local output date (YYMMDD). | 6n | 160713 |
| 6 | Output Time | Mandatory | Receiver’s local output time (HHMM). | 4n | 1634 |
| 7 | Priority | Optional | Delivery priority: N (normal), U (urgent). | 1a | N |
Full output example: {2:O1031734150713NDEANOKKBXXX00739698421607131634N}
Block 3 – User Header Block
Application-Level Metadata and References
Block 3 carries user-defined and SWIFT-defined metadata that supplements the business message.
Purpose
- Carry tracking identifiers
- Support end-to-end reference correlation
- Provide processing instructions or flags
Characteristics
- Optional
- Message-type independent
- Does not contain business payment data
- Elements are called User Header Elements, not fields
Common Elements (Examples)
- Message User Reference (MUR)
- Unique End-to-End Transaction Reference (UETR)
- Processing indicators
Common Fields
| Tag | Mandatory/Optional | Description | Data Type/Format | Example |
| 103 | Optional | Service Identifier for FIN-copy service (e.g., PM processing); absent means direct delivery. Used in MT103,202,204. | {103:3!a} | {103:AB1} |
| 108 | Optional | Message User Reference (MUR): sender’s free-format reference up to 16 chars. | {108:16x} | {108:ABC123} |
| 113 | Optional | Banking Priority: 4-char code agreed between users (sender-set, receiver may ignore). | {113:4!x} | {113:URGT} |
| 119 | Optional | Validation Flag: requests STP (103+ rules) or COV (MT202 COV); absent defaults to core rules. Mandatory for MT202 COV. | {119:STP} {119:COV} Options: STP, COV, etc. | {119:STP} |
| 121 | Optional (mandatory for MT103/202/205 payment variants) | Unique End-to-End Transaction Reference: UUID-like for payment chaining. | {121:36!x} | {121:3fad5ba3-748b-44ba-80a4-ee32507b8e35} |
| 111 | Optional | Service Type Identifier: global payment service code (e.g., 001). | {111:3!n} | {111:001} |
Full Example: {3:{108:0000000000000zza}{111:001}{121:4936052d-7584-436f-aa55-a47914c1cc4c}}
Note: Other fields like below appear contextually.
- {106:MIR} (Message Input Ref),
- {115:} (Addressee Info for Y-copy),
- {423:} (Balance Checkpoint),
- {424:} (Related Ref),
- {165:} (Server Info), and
- {433:/AOK/} (Sanctions Screening)
Block 4 – Text Block
Business Content of the Message
Block 4 is the core of the MT message.
This is where the actual payment or financial instruction lives.
Purpose
- Carry business data
- Define who pays whom, how much, when, and how
- Represent the semantic meaning of the message
Characteristics
- Mandatory
- Message-type specific
- Contains MT fields
- Governed by MT Field Format language
Contains
- MT fields identified by tags (e.g., :20:, :32A:, :50K:)
- Field formats using symbols like n, a, c, x, d
- Length rules, optionality, repetitions, and letter options
Structure
The fields depend on each message type and not generalized across Block 4. They will be covered separately under each message type.
Block 5 – Trailer Block
Security, Integrity, and Network Controls
Block 5 contains trailer information added by SWIFT to ensure message integrity and security.
Purpose
- Verify message authenticity
- Detect tampering or corruption
- Support network-level validation
Characteristics
- Optional
- Generated and interpreted by SWIFT infrastructure
- Not part of business processing
- Elements are called Trailer Elements, not fields
Common Elements (Examples)
- Message Authentication Code (MAC)
- Checksum (CHK)
- Test and Training indicators
Structure:
| Tag | Mandatory / Optional | Description | Data Type / Format | Example |
| MAC | Optional (Mandatory for authenticated messages) | Message Authentication Code. Ensures message authenticity and integrity between SWIFT participants. | Fixed-length alphanumeric (SWIFT-generated) | {MAC:ABCDEF12} |
| CHK | Optional | Checksum. Used to verify message completeness and detect transmission errors. | Fixed-length alphanumeric | {CHK:123456789ABC} |
| TNG | Optional | Test and Training Indicator. Marks the message as test or training traffic. | Fixed literal (no value) | {TNG:} |
| PDE | Optional | Possible Duplicate Emission indicator. Flags a message that may be a duplicate. | Fixed literal | {PDE:} |
| DLM | Optional | Delayed Message Indicator. Indicates delayed delivery of the message. | Fixed literal | {DLM:} |
Full Example: {5:{CHK:123456789ABC}{MAC:ABCDEF12}}
How MT Blocks Work Together (Architectural View)
| Layer | MT Block | Role |
| Network Layer | Block 1 | Sender identity and session |
| Routing Layer | Block 2 | Direction, message type, priority |
| Application Metadata | Block 3 | References and tracking |
| Business Layer | Block 4 | Payment data |
| Security Layer | Block 5 | Integrity and authentication |
This layered design is deliberate and directly influenced the architecture of modern messaging standards.
Relationship to ISO 20022
ISO 20022 formalizes the same separation:
High Level Comparison
| MT Concept | ISO 20022 Equivalent |
| Blocks 1 & 2 | Application Header (AppHdr) |
| Block 3 | Application / Business references |
| Block 4 | Business Message (pacs, pain, camt) |
| Block 5 | Network / envelope controls |
Understanding MT blocks makes ISO 20022:
- easier to learn,
- easier to map,
- and easier to troubleshoot.
Key Takeaways
- MT messages are block-structured by design
- Each block has a clear, non-overlapping role
- Only Block 4 contains business fields
- Blocks 1, 2, 3, and 5 support network, routing, and control
- This separation is the foundation for modern payment messaging.
