SWIFT / Learning brief
SWIFT MTs – Key Details
Your notes
In simple terms / 01
What this means in plain language
Explains the MT naming convention, message categories, three-digit identifiers, and other structural details used across SWIFT FIN messages.
SWIFT MT names follow a structured convention. The three digits identify a category, a group, and a specific message function, while variants or usage rules can add more context. Broad categories help users recognize whether a message concerns areas such as customer payments, financial-institution transfers, securities, trade, or cash management. The number is only a starting point: accurate interpretation also depends on direction, sender and receiver roles, field options, network rules, and the business process. A familiar code should never replace reading the actual message.
Complete lesson / 02
Understand the full idea, step by step
A knitting pattern reads k2, p2, *k1, yo* to end. Meaningless until someone shows you that k is knit, p is purl, *...* repeats, and a number is a count. A SWIFT field specification is exactly this kind of shorthand: a few letters and symbols that say precisely what may go in a field. Once you can read the shorthand, you can read any field in any MT message you have never seen before.
The three digits already tell you a lot
Before the fields, read the message number. An MT type is three digits, and each digit means something: the first is the category (its business area), the second is a group within that area, and the third names the specific message. So an MT103 is category 1 (customer payments), and an MT202 is category 2 (financial-institution transfers). The number is a first hint, not the whole story — direction, sender and receiver roles, and the actual fields still decide what a message truly means.
Field format specification
Every field in an MT message has a defined format: a compact string of length-and-character codes stating what content is allowed. Read left to right, each piece is a count, a character type, and sometimes a marker for whether the length is fixed or a maximum. Learn a handful of symbols and the whole catalogue of specifications opens up, because they all use the same alphabet.
The symbols in a format string
- n
- digits, 0-9
- a
- uppercase letters, A-Z
- c
- uppercase letters and digits
- x
- any character in the permitted SWIFT set
- d
- an amount, using a decimal comma
- ! (as in 6!n)
- fixed length — exactly that many characters
- no ! (as in 15d)
- maximum length — up to that many characters
- [ ] (as in [3!c])
- the enclosed part is optional
Reading :32A: and a BIC
Now 6!n3!a15d reads cleanly: 6!n is exactly six digits (a value date as YYMMDD), 3!a is exactly three letters (a currency code such as EUR), and 15d is an amount of up to fifteen characters with a decimal comma. One more you will meet everywhere is 4!a2!a2!c[3!c] — a bank identifier code (BIC): four letters for the bank, two for the country, two characters for the location, and an optional three-character branch. Same alphabet, different field.
SWIFT MT — ILLUSTRATIVE, NON-PRODUCTION
Look at the tags. :30: is a six-digit date (6!n), :32B: a currency-and-amount, and :21: a reference. Notice :50H: names the ordering customer — the H is the option letter. Fictional corporate request for transfer.
You may be wondering: why is the field written `:50a:` in the standard but `:50H:` in a real message?
The lowercase letter in a specification like :50a: is a placeholder meaning "one of several format options exists here, and the sender picks the one that fits". Each option is a real letter: :50A: identifies the ordering customer by an account and a BIC, :50K: by an account and a name-and-address, :50F: by a structured party format. The sample above chose :50H:. So :50a: is the menu; the capital letter in an actual message is the dish that was ordered.
COMMON CONFUSION
“The lowercase letter in :50a: is a typo or an anonymised field.”
It is deliberate. Lowercase signals a choice of format options; the sender replaces it with the specific option letter used. Reading :50a: as if it were a fixed field is how people miss that two messages both "have field 50" while carrying party data in completely different shapes.
STRICTLY SPEAKING
Strictly speaking, the full specification for a field also states whether it is mandatory or optional, any code words it may contain, and cross-field rules that constrain it — detail this lesson sets aside to keep the notation clear. The authoritative format and option list for every field lives in SWIFT's own message standards, which is what a bank validates against.
FOR NOW, REMEMBER
- An MT number is three digits: category, group, specific message — a first hint at meaning, not the whole answer.
- A field format string is read left to right: a count, a character type (n, a, c, x, d), and markers for fixed length (!) or optional parts ([ ]).
- So
6!n3!a15dis date, currency, amount;4!a2!a2!c[3!c]is a BIC. - A lowercase option letter like
:50a:means several format options exist; the message shows the real one, such as:50K:.
TRY IT YOURSELF
A field's specification is `35x`. Which message content fits it?
You can read a field's shape now. Next: which fields must appear at all — mandatory, optional, and conditional — and how the network itself checks a message before anyone is paid.
KEEP GOINGKey takeaways / 03
Three things to remember
- 01
The three-digit MT identifier signals category and function.
- 02
Field options refine how a message carries information.
- 03
Context is required to interpret an MT correctly.
Practical use cases / 04
Where you would use this
A new analyst groups messages by business area during system discovery.
A developer selects parsing and validation rules from the exact MT type.
An investigator checks sender, receiver, direction, and fields before classifying a case.
Worked example / 05
Put the idea into a real situation
Illustrative example: an analyst sees an MT103 and recognizes it as a customer payment message, while an MT202 relates to financial-institution transfer activity. That first classification narrows the likely workflow, but it does not complete the analysis. The analyst still checks the institutions, references, field options, related messages, and account route to understand whether the message is a customer instruction, funding leg, return, or investigation context.
Evidence & review / 07
Evidence & review
SWIFT FIN MT format notation and field option letters.
What this brief simplifies: Introduces the format alphabet and option letters but sets aside mandatory/optional/conditional status and code-word rules, covered in the next lesson.
Sources for this brief2
- Official requirement
Swift Standards MT (annual standards releases) ↗ — Swift · MT naming and field format notation
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.