SWIFT MT messages are often described as “legacy”, yet they continue to power a large part of the global payments ecosystem. At the core of every MT message lies a strict field format language that governs how data must be represented, parsed, validated, and interpreted.
Understanding MT field formats is not about memorising syntax. It is about understanding:
- how payment data was historically constrained,
- why ISO 20022 looks the way it does today,
- and how real-world payment systems still behave in 2026.
This article provides a complete, structured explanation of MT field formats, covering:
- message and block structure,
- tags and delimiters,
- format notation,
- length rules,
- optionality,
- separators,
- character sets,
- letter options,
- validation philosophy,
- and why MT knowledge remains crucial even after ISO 20022 migration.
What Is an MT Message?
An MT (Message Type) message is a structured, text-based financial message defined by SWIFT. Each MT message:
- serves a specific business purpose (e.g. customer credit transfer, interbank transfer),
- follows a predefined structure,
- and must comply with strict formatting rules.
Unlike XML-based standards, MT messages rely on positional parsing and character-level validation.
High-Level Structure of an MT Message
An MT message is divided into logical blocks, each enclosed in curly braces {}.
{1: Basic Header Block}
{2: Application Header Block}
{3: User Header Block}
{4: Text Block}
{5: Trailer Block}
Key Points
- Curly braces {} are block delimiters
- Blocks are identified by block numbers
- Field formats apply primarily to Block 4 (Text Block)
The end of Block 4 is explicitly marked by: “-}”
A missing or misplaced block delimiter invalidates the entire message.
Note: Please refer to the Overview of MT Blocks article for more information.
Link: https://paymenttalks.com/overview-of-mt-message-blocks/
Tags and Their Delimiters
What Is a Tag?
MT messages are not self-describing like XML.
There are no element names or schemas at runtime.
Tags solve this by:
- Identifying business meaning
- Enforcing field format rules
- Allowing deterministic parsing
- Enabling message-type-specific validation
Without tags, MT messages would be ambiguous free text.
Tag Structure
Format: “ :Tag: ”
- 2 or 3 digits, sometimes
- followed by a letter option
Examples:
:20:
:32A:
:50K:
:59F:
Numeric Part Identifies the business field (Same number = same business role)
Letter Option tells different data representation and different format rules
Tag Delimiter Rules
| Element | Purpose |
| : (colon) | Marks start and end of the tag |
| Line break | Marks end of field content of Tag information |
| -} | Marks end of Block 4 |
Rules:
- Tags always start on a new line
- Only one tag per line start
- Tags are case-sensitive and uppercase
- Fields must appear in the prescribed sequence
How SWIFT Describes MT Field Formats
SWIFT defines field formats using symbolic notation, not examples. This notation precisely defines:
- allowed character types,
- length constraints,
- repetition rules.
Core Format Symbols
| Symbol | Meaning |
| n | numeric digits (0 to 9) only |
| a | alphabetic letters (A through Z), upper case only |
| c | alphabetic letters (upper case) and digits only |
| h | hexadecimal letters A through F (upper case) and digits only |
| x | any character of the X permitted set, upper and lower case allowed |
| y | any character of the EDIFACT level A character set as defined in ISO 9735 upper case only |
| z | any character as defined by the Information Service |
| e | blank space |
| d | Decimal number (comma as decimal separator) |
Character Sets and Case Sensitivity
a, c, h
- Uppercase only
- Lowercase not allowed
Used for:
- Currency codes
- Qualifiers
- Identifiers
x — SWIFT Character Set
✔ Includes lowercase letters
✔ Includes uppercase letters, digits, and allowed punctuation
Most Name and Address fields use x, for example:
4*35x
Therefore:
- John Doe → valid
- JOHN DOE → valid
- John doe, Riyadh → valid
Uppercase-only behaviour often seen in practice is an implementation choice, not a SWIFT rule.
Decimal and Numeric Rules
Length Indicators and the Exclamation Mark !
Repeating Lines (* Notation)
Composite Field Formats
Optional Data and Square Brackets [ ]
Separators Inside Fields
Letter Options in MT Fields
Mandatory, Optional, and Repeating Fields
- Some fields are mandatory
- Some optional
- Some repeatable
A field may be perfectly formatted and still invalid if:
- It appears when not allowed
- It appears too many times
- It appears out of sequence
Validation Philosophy of MT Formats
MT field formats are designed for:
- Deterministic parsing
- Minimal ambiguity
- High resilience in legacy systems
Even a single character violation can:
- Break parsing
- Cause rejection
- Lead to downstream misinterpretation
Why MT Field Format Knowledge Still Matters in 2026
ISO 20022 is now the strategic standard endorsed by SWIFT — but operational reality is hybrid.
MT Still Matters Because:
- MT messages still flow across many corridors
- Translators map MT ↔ ISO daily
- Investigations and repairs still reference MT fields
- Legacy systems still store MT-shaped data
You cannot:
- design correct mappings,
- validate translation logic,
- understand truncation,
- or debug production issues
without understanding MT field formats.
How MT Knowledge Helps Learn ISO 20022
MT formats explain:
- why ISO is structured,
- why party roles are explicit,
- why truncation rules exist,
- why enrichment is required.
Think of it this way:
- MT defines the problem
- ISO 20022 defines the solution
Understanding MT makes ISO 20022 intuitive rather than overwhelming.
Final Takeaway
MT field formats are not obsolete trivia.
They are the foundation on which modern payment messaging evolved.
Understanding them gives you:
- deeper system insight,
- stronger debugging skills,
- better ISO 20022 comprehension,
- and real-world payments credibility.
MT may no longer be the future —
but it is still the grammar of today’s payment reality.
