SWIFT MT Messages: A Field-by-Field Primer

For decades, cross-border and correspondent-banking payments spoke a single language: SWIFT MT. Even as the industry migrates to ISO 20022, MT messages remain everywhere in older systems, archives and reconciliations, so being able to read one is a core payments skill. This primer walks through the structure and the fields that matter most.

The block structure

Every SWIFT MT message is built from numbered blocks, wrapped in curly braces:

• Block 1 (Basic Header): application and sender identification.
• Block 2 (Application Header): message type and receiver (or sender, for outgoing).
• Block 3 (User Header): optional references, such as a unique end-to-end reference.
• Block 4 (Text Block): the actual message content, where the numbered fields live. This is what people usually mean when they read an MT message.
• Block 5 (Trailer): authentication and control information.

Message types: MT103 and MT202

The MT catalogue is organised by category. Category 1 covers customer payments and category 2 covers financial-institution transfers. Two dominate:

• MT103: a single customer credit transfer, the workhorse for paying an end customer or supplier across borders.
• MT202: a general financial-institution transfer, used to move funds between banks, including the MT202 COV variant that accompanies an MT103 through a chain of correspondent banks.

Reading the fields in Block 4

Fields are identified by a tag such as :20: and often a letter option such as :32A: that specifies the exact format. The essentials in an MT103 include:

• :20: Sender's Reference, the unique transaction reference assigned by the sender.
• :23B: Bank Operation Code, indicating the type of transfer (for example a normal credit transfer).
• :32A: Value Date, Currency and Amount, packed together as a date (YYMMDD), a three-letter currency code, and the amount. This is the single most important field: when, in what currency, and how much.
• :50a: Ordering Customer, the payer. The letter option (for example 50K or 50F) controls whether an account and structured details are provided.
• :52a: Ordering Institution, the payer's bank if different from the sender.
• :57a: Account With Institution, the beneficiary's bank.
• :59a: Beneficiary Customer, the party being paid.
• :70: Remittance Information, free text explaining the payment (invoice numbers and the like).
• :71A: Details of Charges, indicating who pays fees: OUR (sender pays all), SHA (shared), or BEN (beneficiary pays).

If you learn only three fields, learn :20: (the reference), :32A: (date, currency and amount) and :71A: (who bears the charges). They anchor almost every investigation.

The charges question and gpi

The :71A: charge code drives real money. Under OUR, the sender covers all fees so the beneficiary receives the full amount; under SHA, each side pays its own bank; under BEN, fees are deducted along the way and the beneficiary gets less than the face amount. Because deducted correspondent fees historically made cross-border payments opaque, SWIFT introduced gpi (global payments innovation), which adds a unique end-to-end reference (the UETR) so a payment can be tracked across the correspondent chain and fees made visible.

Why the structure feels cramped

MT was designed in an era of expensive bandwidth, so fields are short and meaning is often overloaded into free text and codewords. That compactness is exactly why the industry is moving to ISO 20022, whose structured fields eliminate the ambiguity that MT tolerates. Still, translation between MT and the ISO 20022 pacs messages is a fact of life during coexistence, and understanding the MT side is essential to doing that translation without losing data.

Categories and confirmations

The MT catalogue extends well beyond payments. Category 5 covers securities, category 7 covers documentary credits and guarantees (trade finance), and category 9 covers cash management and status messages such as the MT900 and MT910 debit and credit confirmations and the MT940 and MT950 statement messages that report account activity. Anyone reconciling correspondent accounts will meet the MT940 statement constantly. The first digit tells you the business area, the second and third narrow it to the specific message, so learning the categories lets you orient quickly even in an unfamiliar message type.

Validation and straight-through processing

MT messages are validated against network rules: mandatory fields must be present, codewords must come from allowed lists, and field formats are strictly checked, which is why a malformed :32A: or an invalid currency code is rejected by the network before it ever reaches the receiver. Well-formed messages that pass validation and contain complete beneficiary data can be processed automatically end to end, whereas messages with ambiguous free-text fields drop out for manual repair. That contrast, clean structured data flowing straight through versus free text causing exceptions, is precisely the argument driving the migration to ISO 20022.

Key takeaways

• MT messages are built from Blocks 1 to 5; Block 4 holds the numbered fields you read.
• MT103 is a customer credit transfer; MT202 (and MT202 COV) moves funds between financial institutions.
• Key fields include :20: (reference), :32A: (value date, currency, amount), :50a: (payer), :59a: (beneficiary) and :71A: (charges).
• The :71A: charge code (OUR, SHA, BEN) determines who bears fees and how much the beneficiary receives.
• SWIFT gpi added end-to-end tracking (the UETR); ISO 20022 pacs messages are the structured successors to MT.