| Field | Meaning | Required |
|---|---|---|
:20: | A unique reference assigned by the sending bank to identify this payment through its whole life. It must not repeat for the same sender within the same business | M |
:23B: | A four character code that tells the receiving bank how to handle the transfer. CRED means a normal credit transfer, SPAY means a SWIFT payment, SSTD means a st | M |
:32A: | The value date on which funds become available to the beneficiary, the three letter ISO currency code and the amount to be paid. For USD 25,000 on 5 November 20 | M |
:33B: | The currency and amount in which the ordering customer instructed the payment, when that differs from the settlement currency in field 32A. It preserves the ori | O |
:50a: | The customer who ordered the payment, identified by account number and name and address. Option K gives account, name and address in free text. Option F gives s | M |
:52a: | The financial institution that ordered the transfer when it is not the sender of the message. It is normally the bank holding the ordering customer account in a | O |
:53a: | The account held by the sender with the receiver, or the correspondent bank through which settlement will occur. It tells the receiving bank where to debit the | O |
:54a: | The account held by the receiver with another bank, used when the receiver does not hold the sender account directly. It identifies the next bank in the settlem | O |
:57a: | The bank where the beneficiary holds an account, when it is not the receiver of the MT103. It directs the receiving bank to forward the payment to the correct a | O |
:59a: | The final recipient of the funds, identified by account number and name and address. Option A gives the account and BIC, option F gives structured name and addr | M |
:70: | Free text information for the beneficiary explaining what the payment is for, such as an invoice number, contract reference or salary month. It is limited to fo | O |
:71A: | A three letter code stating who pays the transfer charges. OUR means the ordering customer pays all charges, BEN means the beneficiary pays all charges, and SHA | M |
Meridian Bank London sends an MT103, reference MER1035521, for USD 25,000 value 5 November 2024 to Harbour Bank Singapore to pay Bright Logistics for invoice INV-1187. This is a pre-migration example, from before coexistence ended on 22 November 2025. Field :71A: is SHA, the beneficiary account is given in :59a:, and the payment settles on the value date.
Valid example from the message catalogue. Scheme rules: MT103 is a SWIFT MT (FIN) message, not a base ISO 20022 message: there is no single global scheme rulebook, and each bank and market practice sets its own format limits and cut-off times on top of the
What SWIFT MT is, and why it lasted so long
What you will learn
Your objective. By the end of this lesson, you will be able to explain SWIFT MT is. SWIFT MT, where MT stands for Message Type, is the long established messaging standard used by banks around the world to exchange payment instructions and related information.
Why it matters. The fixed field structure also makes MT messages relatively easy to parse, to test, and to repair, which operations teams value.
Chapter objective: Learner reads and interprets SWIFT MT messages, including MT103, MT202, MT202COV, MT940, and MT950, and explains the purpose, key fields, and business use of each message type. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- SWIFT MT
- Format: compact
- Such as a full postal address
- Bank in London
- MT messages
- Fields: short
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
Repair: Manual correction of a payment that failed straight through processing because of missing or invalid data.
SWIFT MT message viewer showing What SWIFT MT is, and why it lasted so long.
Practise this lesson
Exercise
Read the MT103 for message described in this lesson and identify its key parts.
Use the message structure, fields and example in this lesson.
- What to do. List the main blocks of the message, name the field that carries the amount, and name the field that identifies the payment.
Correct result. The message is made of blocks, each carrying a part of the payment instruction. The amount field and the identification field are the two a receiving bank checks first, because without them it cannot process or reconcile the payment.
Why. A message is only useful if you can read it. The blocks tell the receiving bank what to do, and the amount and identification fields are what it checks first.
Check your understanding
Practice question
In an MT103, which field carries the value date, currency and amount of the payment?
Takeaway and next step
What to remember
MT is still used for statements, trade finance, collections, and domestic flows, so reading MT remains a working skill for any payments analyst.
Open the message type from this lesson and inspect its fields, then find the field that carries the amount.
Open the ISO 20022 Message Explorer →
Builds on "System design deep dive: how the lifecycle is built inside a bank".
Transcript and full text
Show transcript
SWIFT MT, where MT stands for Message Type, is the long established messaging standard used by banks around the world to exchange payment instructions and related information. SWIFT itself is a member owned cooperative that provides the secure network, the message standards, and the addressing system based on BICs that let banks identify each other. An MT message is a structured text message with a header, a text block containing tagged fields, and a trailer. Each message type has a number, such as MT103 for a customer payment, MT202 for a bank to bank payment, and MT940 for a statement, and each type has a defined set of fields with specific formats and rules. MT has lasted so long because it is reliable, standardised, and understood by every major bank. The format is compact, the validation is strict, and the network provides delivery confirmation and non repudiation. A bank that sends an MT103 knows that the receiving bank will interpret the fields in the same way, because the standard is enforced by SWIFT and by the user community. That reliability is why MT survived for decades as the standard for cross border payments, until the CBPR Plus migration ended MT for cross border payments on 22 November 2025. The fixed field structure also makes MT messages relatively easy to parse, to test, and to repair, which operations teams value. The limitation of MT is that it was designed in an era when messages had to be short and when character sets were limited. Fields are short, often limited to 35 characters per line, and remittance information is limited to 140 characters in an MT103. Structured data, such as a full postal address or a detailed invoice breakdown, is hard to carry in MT without truncation or workarounds. Those limitations are a major reason for the migration to ISO 20022, which uses XML and can carry far richer data. Understanding MT is still essential, however, because many banks processed MT messages during the coexistence period, and because many payment investigations still involve reading an MT message. SWIFT itself was founded in 1973, and the MT messages went live in 1977. Before that, banks sent payment instructions by telex, which was slow, unstructured, and easy to misread. MT gave every bank the same message formats, the same field definitions, and the same validation rules. A bank in London and a bank in Singapore could exchange an MT103 knowing both sides would read it the same way. That shared understanding is what made cross border payments reliable at scale, and it is why the standard survived for nearly fifty years. An MT message travels through the SWIFT network, which is known as FIN for these messages. The sending bank creates the message, the network checks the format, and the message is delivered to the receiving bank using its BIC. The network confirms delivery and keeps a record, so neither side can deny that the message was sent or received. If a message fails validation, the network sends back a negative acknowledgement and the message is not delivered. That strict checking is a big reason operations teams trusted MT, because a badly formed message was stopped before it could cause damage. MT messages are grouped into categories, and the category number is the first digit of the message type. Category 1 covers customer payments and cheques, including the MT103. Category 2 covers financial institution transfers, including the MT202. Category 3 covers treasury markets, category 4 covers collections, category 5 covers securities, category 7 covers documentary credits and guarantees, and category 9 covers cash management, including the MT900, MT910, MT940, and MT950. Knowing the category tells you at a glance what kind of business a message belongs to. MT lasted so long because of network effect. Every major bank was connected, every operations team knew the formats, and every system could parse them. But the limits eventually forced a change. Fields were short, data was unstructured, and compliance screening struggled with free text names and addresses. The CBPR Plus programme moved cross border payments to ISO 20022, and from 22 November 2025 MT103 and MT202 are no longer accepted for cross border payment instructions. MT is still used for statements, trade finance, collections, and domestic flows, so reading MT remains a working skill for any payments analyst.
SWIFT MT, where MT stands for Message Type, is the long established messaging standard used by banks around the world to exchange payment instructions and related information. SWIFT itself is a member owned cooperative that provides the secure network, the message standards, and the addressing system based on BICs that let banks identify each other. An MT message is a structured text message with a header, a text block containing tagged fields, and a trailer. Each message type has a number, such as MT103 for a customer payment, MT202 for a bank to bank payment, and MT940 for a statement, and each type has a defined set of fields with specific formats and rules.
MT has lasted so long because it is reliable, standardised, and understood by every major bank. The format is compact, the validation is strict, and the network provides delivery confirmation and non repudiation. A bank that sends an MT103 knows that the receiving bank will interpret the fields in the same way, because the standard is enforced by SWIFT and by the user community. That reliability is why MT survived for decades as the standard for cross border payments, until the CBPR Plus migration ended MT for cross border payments on 22 November 2025. The fixed field structure also makes MT messages relatively easy to parse, to test, and to repair, which operations teams value.
The limitation of MT is that it was designed in an era when messages had to be short and when character sets were limited. Fields are short, often limited to 35 characters per line, and remittance information is limited to 140 characters in an MT103. Structured data, such as a full postal address or a detailed invoice breakdown, is hard to carry in MT without truncation or workarounds. Those limitations are a major reason for the migration to ISO 20022, which uses XML and can carry far richer data. Understanding MT is still essential, however, because many banks processed MT messages during the coexistence period, and because many payment investigations still involve reading an MT message.
SWIFT itself was founded in 1973, and the MT messages went live in 1977. Before that, banks sent payment instructions by telex, which was slow, unstructured, and easy to misread. MT gave every bank the same message formats, the same field definitions, and the same validation rules. A bank in London and a bank in Singapore could exchange an MT103 knowing both sides would read it the same way. That shared understanding is what made cross border payments reliable at scale, and it is why the standard survived for nearly fifty years.
An MT message travels through the SWIFT network, which is known as FIN for these messages. The sending bank creates the message, the network checks the format, and the message is delivered to the receiving bank using its BIC. The network confirms delivery and keeps a record, so neither side can deny that the message was sent or received. If a message fails validation, the network sends back a negative acknowledgement and the message is not delivered. That strict checking is a big reason operations teams trusted MT, because a badly formed message was stopped before it could cause damage.
MT messages are grouped into categories, and the category number is the first digit of the message type. Category 1 covers customer payments and cheques, including the MT103. Category 2 covers financial institution transfers, including the MT202. Category 3 covers treasury markets, category 4 covers collections, category 5 covers securities, category 7 covers documentary credits and guarantees, and category 9 covers cash management, including the MT900, MT910, MT940, and MT950. Knowing the category tells you at a glance what kind of business a message belongs to.
MT lasted so long because of network effect. Every major bank was connected, every operations team knew the formats, and every system could parse them. But the limits eventually forced a change. Fields were short, data was unstructured, and compliance screening struggled with free text names and addresses. The CBPR Plus programme moved cross border payments to ISO 20022, and from 22 November 2025 MT103 and MT202 are no longer accepted for cross border payment instructions. MT is still used for statements, trade finance, collections, and domestic flows, so reading MT remains a working skill for any payments analyst.
Full lesson text (all scenes)
Completing a lesson updates your progress dashboard on the homepage.
Scene timestamps are estimated by allocating the narration text proportionally across the real audio length. The audio playback position is the source of truth: pause freezes the visual, seeking restores the correct scene, replay restarts the scene animation.