| 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
MT message blocks 1 to 5: how to read a raw message
What you will learn
Your objective. By the end of this lesson, you will be able to explain MT message blocks 1 to 5: how to read a raw message. Every SWIFT MT message is built from up to five blocks, each wrapped in curly brackets and numbered 1 to 5.
Why it matters. That skill lets an analyst read any MT message without a tool.
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 message
- Block 2
- Example: {2:O1031734150713DEUTDEFFBXXX00739698421607131634N}
- Block 4
- Block 5
- Read it block by block
Key terms
Cover payment: A payment method where the customer instruction travels one route while the funds travel separately as a bank to bank cover message.
Value date: The date on which funds become available to the beneficiary and on which interest starts to accrue. It is the date used for settlement and for nostro posting.
SWIFT: The Society for Worldwide Interbank Financial Telecommunication, a member owned cooperative that provides secure messaging services for financial institutions.
SWIFT MT message viewer showing MT message blocks 1 to 5: how to read a raw message.
Practise this lesson
Exercise
Read the MT103 to 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
Which of the following best describes MT message blocks 1 to 5: how to read a raw message?
Takeaway and next step
What to remember
That skill lets an analyst read any MT message without a tool.
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 "Worked example: serial method, the same payment in three MT103s".
Transcript and full text
Show transcript
Every SWIFT MT message is built from up to five blocks, each wrapped in curly brackets and numbered 1 to 5. Block 1 is the basic header. It is the only mandatory block. It contains general information that identifies the message and some control information. It has five fields, all mandatory, the application identifier (F for FIN), the service identifier (01 for FIN), the logical terminal address of the sender (a 12 character BIC plus branch code), the four digit session number, and the six digit sequence number. A full example is {1:F01SOGEFRPPAXXX0070970817}, where SOGEFRPPAXXX is Societe Generale Paris, 0070 is the session number, and 970817 is the sequence number. Block 2 is the application header. It contains information specific to the application. It is required for messages that users or systems exchange. There are two variations. An input header starts with the letter I and describes a message a bank is sending into the network. It carries the message type, the receiver BIC, and the priority, for example {2:I103BSCHESMMXXXXN}, an outgoing MT103 to Santander at normal priority. An output header starts with the letter O and describes a message SWIFT has delivered. It is longer because it adds the history inside the network, message type, input time, input reference date, sender logical terminal, session and sequence numbers, output date, output time, and priority. An example is {2:O1031734150713DEUTDEFFBXXX00739698421607131634N}, an MT103 that arrived from Deutsche Bank. Block 3 is the user header. It is optional on most messages. It carries tagged items such as tag 103 for a FINCopy service, tag 108 for a message user reference of up to 16 characters, tag 111 for a service type identifier, tag 119 for the validation flag that marks an MT202 as a cover payment, and tag 121 for the Unique End-to-end Transaction Reference used in SWIFT gpi tracking. Block 3 becomes mandatory in one case. When a message goes through FINCopy, tag 103 must be present so SWIFT knows which copy service should receive the message. Block 4 is the text block. It holds the business data of the payment, organised as tagged fields. Each field starts with a colon, a two digit field number, an optional letter for the field option, and another colon, for example :20: for the transaction reference, :32A: for the value date and settled amount, and :59: for the beneficiary customer. Amounts use a comma as the decimal separator, so USD 367,574.90 is written as USD367574,90. Dates use the format YYMMDD, so 18 July 2024 is written as 180724. Multi line fields such as 50, 59, and 70 use line breaks, with each line limited to 35 characters. Block 5 is the trailers block. It indicates special circumstances related to message handling or contains security information. The checksum is the best known trailer. A complete raw message looks like this. {1:F01SOGEFRPPAXXX0070970817}{2:O1031734150713DEUTDEFFBXXX00739698421607131634N}{3:{103:TGT}{108:OPTUSERREF16CHAR}}{4: :20:UNIQUEREFOFTRX16, :23B:CRED, :32A:180724EUR735927,75, :33B:EUR735927,75, :50A:/DE37500700100950596700, DEUTDEFF, :59:/FR7630003034950005005419318, CHARLES DUPONT COMPANY RUE GENERAL DE GAULLE, 21 75013 PARIS :71A:SHA -}{5:{CHK:D628FE0165A7}}. Read it block by block, who sent it, what type it is, any user header data, the business fields, and the checksum. That skill lets an analyst read any MT message without a tool.
Every SWIFT MT message is built from up to five blocks, each wrapped in curly brackets and numbered 1 to 5. Block 1 is the basic header. It is the only mandatory block. It contains general information that identifies the message and some control information. It has five fields, all mandatory, the application identifier (F for FIN), the service identifier (01 for FIN), the logical terminal address of the sender (a 12 character BIC plus branch code), the four digit session number, and the six digit sequence number. A full example is {1:F01SOGEFRPPAXXX0070970817}, where SOGEFRPPAXXX is Societe Generale Paris, 0070 is the session number, and 970817 is the sequence number.
Block 2 is the application header. It contains information specific to the application. It is required for messages that users or systems exchange. There are two variations. An input header starts with the letter I and describes a message a bank is sending into the network. It carries the message type, the receiver BIC, and the priority, for example {2:I103BSCHESMMXXXXN}, an outgoing MT103 to Santander at normal priority. An output header starts with the letter O and describes a message SWIFT has delivered. It is longer because it adds the history inside the network, message type, input time, input reference date, sender logical terminal, session and sequence numbers, output date, output time, and priority. An example is {2:O1031734150713DEUTDEFFBXXX00739698421607131634N}, an MT103 that arrived from Deutsche Bank.
Block 3 is the user header. It is optional on most messages. It carries tagged items such as tag 103 for a FINCopy service, tag 108 for a message user reference of up to 16 characters, tag 111 for a service type identifier, tag 119 for the validation flag that marks an MT202 as a cover payment, and tag 121 for the Unique End-to-end Transaction Reference used in SWIFT gpi tracking. Block 3 becomes mandatory in one case. When a message goes through FINCopy, tag 103 must be present so SWIFT knows which copy service should receive the message.
Block 4 is the text block. It holds the business data of the payment, organised as tagged fields. Each field starts with a colon, a two digit field number, an optional letter for the field option, and another colon, for example :20: for the transaction reference, :32A: for the value date and settled amount, and :59: for the beneficiary customer. Amounts use a comma as the decimal separator, so USD 367,574.90 is written as USD367574,90. Dates use the format YYMMDD, so 18 July 2024 is written as 180724. Multi line fields such as 50, 59, and 70 use line breaks, with each line limited to 35 characters.
Block 5 is the trailers block. It indicates special circumstances related to message handling or contains security information. The checksum is the best known trailer. A complete raw message looks like this. {1:F01SOGEFRPPAXXX0070970817}{2:O1031734150713DEUTDEFFBXXX00739698421607131634N}{3:{103:TGT}{108:OPTUSERREF16CHAR}}{4: :20:UNIQUEREFOFTRX16, :23B:CRED, :32A:180724EUR735927,75, :33B:EUR735927,75, :50A:/DE37500700100950596700, DEUTDEFF, :59:/FR7630003034950005005419318, CHARLES DUPONT COMPANY RUE GENERAL DE GAULLE, 21 75013 PARIS :71A:SHA -}{5:{CHK:D628FE0165A7}}. Read it block by block, who sent it, what type it is, any user header data, the business fields, and the checksum. That skill lets an analyst read any MT message without a tool.
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.