Payments Training Hub
Worked example NOW Worked Field 70 Analyst can check Message validation Singapore bank Supplier cannot reconcile MESSAGE TRACE Worked This worked example is set before the CBPR+ migration, when an MT103 was still the message for a Step 1 of 6 Worked example 1 NOW Worked 2 Field 70 3 Analyst can check 4 Message validation 5 Singapore bank 6 Supplier cannot reconcile This worked example is set before the CBPR+ migration, when an MT103 was still the message for a cross-border customer payment. Step 1 of 6
Field 70 contains the remittance information Worked NOW Field 70 Analyst can check Message validation Singapore bank Supplier cannot reconcile MESSAGE TRACE Worked > Field 70 Field 70 contains the remittance information, for example slash INV slash 4567, which tells the supplier that Step 2 of 6 Field 70 contains the remittance information 1 Worked 2 NOW Field 70 3 Analyst can check 4 Message validation 5 Singapore bank 6 Supplier cannot reconcile Field 70 contains the remittance information, for example slash INV slash 4567, which tells the supplier that the payment is for invoice 4567. Step 2 of 6
Analyst can check the value date Worked Field 70 NOW Analyst can check Message validation Singapore bank Supplier cannot reconcile MESSAGE TRACE Worked > Field 70 > Analyst can check If the payment is delayed, the analyst can check the value date in field 32A and the sender and receiver BICs Step 3 of 6 Analyst can check the value date 1 Worked 2 Field 70 3 NOW Analyst can check 4 Message validation 5 Singapore bank 6 Supplier cannot reconcile If the payment is delayed, the analyst can check the value date in field 32A and the sender and receiver BICs in the header to see where the payment is in the chain. Step 3 of 6
Message validation checks Worked Field 70 Analyst can check NOW Message validation Singapore bank Supplier cannot reconcile MESSAGE TRACE Worked > Field 70 > Analyst can check > Message validation Now run the validation checks an analyst would run on this message. Step 4 of 6 Message validation checks 1 Worked 2 Field 70 3 Analyst can check 4 NOW Message validation 5 Singapore bank 6 Supplier cannot reconcile Now run the validation checks an analyst would run on this message. Step 4 of 6
Singapore bank validates Worked Field 70 Analyst can check Message validation NOW Singapore bank Supplier cannot reconcile MESSAGE TRACE Worked > Field 70 > Analyst can check > Message validation > Singapore bank The Singapore bank validates the message, screens the parties, and credits Meridian Supplies Pte Ltd. Step 5 of 6 Singapore bank validates 1 Worked 2 Field 70 3 Analyst can check 4 Message validation 5 NOW Singapore bank 6 Supplier cannot reconcile The Singapore bank validates the message, screens the parties, and credits Meridian Supplies Pte Ltd. Step 5 of 6
Supplier cannot reconcile Worked Field 70 Analyst can check Message validation Singapore bank NOW Supplier cannot reconcile MESSAGE TRACE Worked > Field 70 > Analyst can check > Message validation > Singapore bank > Supplier cannot reconcile If the supplier cannot reconcile the payment, check field 70 to see whether the invoice reference 4567 is Step 6 of 6 Supplier cannot reconcile 1 Worked 2 Field 70 3 Analyst can check 4 Message validation 5 Singapore bank 6 NOW Supplier cannot reconcile If the supplier cannot reconcile the payment, check field 70 to see whether the invoice reference 4567 is present. Step 6 of 6

Flow of the explanation in this lesson.

0:00 / 5:04 Step 1 of 6

How to read a real MT103, worked example

SWIFT MT Messages, Lesson 7 of 11, Narration 5:04, D04 Messaging and standards

Remittance informationReconciliationValue date

What you will learn

Your objective. By the end of this lesson, you will be able to explain to read a real MT103, worked example. This worked example is set before the CBPR+ migration, when an MT103 was still the message for a cross-border customer payment.

Why it matters. If the beneficiary receives less than ten thousand dollars, the analyst can use the MT103 to explain why.

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

  • Worked example
  • Field 70 contains the remittance information
  • Analyst can check the value date
  • Message validation checks
  • Singapore bank validates
  • Supplier cannot reconcile

Key terms

Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.

Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.

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 MT message viewer showing How to read a real MT103, worked example.

Practise this lesson

Exercise

Read the MT103 was message described in this lesson and identify its key parts.

Use the message structure, fields and example in this lesson.

  1. 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 to read a real MT103, worked example?

Takeaway and next step

What to remember

Today the same payment travels as a pacs.008, which carries the same story in ISO 20022 form, with the same checks, the same charges logic, and the same exception paths.

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 "Field structure, how to read an MT message".

Transcript and full text

Show transcript

This worked example is set before the CBPR+ migration, when an MT103 was still the message for a cross-border customer payment. Consider a simple MT103 where a company in London, Acme Trading Ltd, pays a supplier in Singapore, Meridian Supplies Pte Ltd, ten thousand US dollars for invoice 4567. Field 20 contains the sender reference, for example ACME2024110501, which is the unique reference the sending bank uses to identify the payment. Field 32A contains 241105USD10000, which means the value date is 5 November 2024, the currency is US dollars, and the amount is ten thousand. The comma would be used if there were cents, for example 10000,00 for ten thousand dollars exactly. Field 50K contains the ordering customer, Acme Trading Ltd, with its address in London, and field 59 contains the beneficiary, Meridian Supplies Pte Ltd, with its address in Singapore and its account number. Field 70 contains the remittance information, for example slash INV slash 4567, which tells the supplier that the payment is for invoice 4567. Field 71A contains SHA, which means charges are shared, so the sending bank charges the sender and the receiving bank may charge the beneficiary. Field 52A identifies the ordering institution, the London bank, and field 57A identifies the account with institution, the Singapore bank where the supplier holds its account. If the beneficiary receives less than ten thousand dollars, the analyst can use the MT103 to explain why. The charges field shows that charges are shared, so a deduction by an intermediary or by the creditor agent is expected. The remittance information shows the invoice reference, so the supplier can reconcile the payment. If the payment is delayed, the analyst can check the value date in field 32A and the sender and receiver BICs in the header to see where the payment is in the chain. This worked example shows that an MT103 is not just a technical format, it is a business document that tells the story of a payment in a compact, standardised form. The same payment today travels as a pacs.008, which carries the same story in ISO 20022 form. Read the header first, because it frames everything else. Block 1 shows the sender BIC, which is the London bank, and block 2 shows the receiver BIC, which is the Singapore bank, with the message type 103 and a normal priority. Once you know the sender, the receiver, and the message type, you know this is a customer payment going from London to Singapore, and every field you read next fits into that story. Now run the validation checks an analyst would run on this message. Check that field 20 is unique and no longer than 16 characters. Check that field 32A has a value date that is a business day and an amount that matches the invoice of ten thousand US dollars. Check that field 50K names Acme Trading Ltd and that the name matches the customer record. Check that field 59 names Meridian Supplies Pte Ltd and that the account number belongs to that company. Check that field 71A says SHA, which matches the fee agreement between the banks. Any mismatch in those checks is a reason to hold the payment and ask a question before the money moves. Follow what happens after the MT103 is sent. The London bank debits Acme Trading Ltd and sends the MT103 to the Singapore bank. The Singapore bank validates the message, screens the parties, and credits Meridian Supplies Pte Ltd. The correspondent bank sends an MT900 to confirm the debit from the London bank nostro account and an MT910 to confirm the credit to the Singapore bank nostro account. The next day, the statement arrives as an MT940, and the reconciliation team matches the MT103, the MT900, the MT910, and the statement line to close the payment. If something goes wrong, the same message tells you where to look. If Meridian says the payment has not arrived, check the value date in field 32A and the sender and receiver BICs in the header to see where the payment is in the chain. If Meridian received less than ten thousand dollars, check field 71A and the charges fields to see what was deducted. If the supplier cannot reconcile the payment, check field 70 to see whether the invoice reference 4567 is present. If the payment was sent in error, the London bank can send an MT192 to ask for it back. Today the same payment travels as a pacs.008, which carries the same story in ISO 20022 form, with the same checks, the same charges logic, and the same exception paths.

This worked example is set before the CBPR+ migration, when an MT103 was still the message for a cross-border customer payment. Consider a simple MT103 where a company in London, Acme Trading Ltd, pays a supplier in Singapore, Meridian Supplies Pte Ltd, ten thousand US dollars for invoice 4567. Field 20 contains the sender reference, for example ACME2024110501, which is the unique reference the sending bank uses to identify the payment. Field 32A contains 241105USD10000, which means the value date is 5 November 2024, the currency is US dollars, and the amount is ten thousand. The comma would be used if there were cents, for example 10000,00 for ten thousand dollars exactly.

Field 50K contains the ordering customer, Acme Trading Ltd, with its address in London, and field 59 contains the beneficiary, Meridian Supplies Pte Ltd, with its address in Singapore and its account number. Field 70 contains the remittance information, for example slash INV slash 4567, which tells the supplier that the payment is for invoice 4567. Field 71A contains SHA, which means charges are shared, so the sending bank charges the sender and the receiving bank may charge the beneficiary. Field 52A identifies the ordering institution, the London bank, and field 57A identifies the account with institution, the Singapore bank where the supplier holds its account.

If the beneficiary receives less than ten thousand dollars, the analyst can use the MT103 to explain why. The charges field shows that charges are shared, so a deduction by an intermediary or by the creditor agent is expected. The remittance information shows the invoice reference, so the supplier can reconcile the payment. If the payment is delayed, the analyst can check the value date in field 32A and the sender and receiver BICs in the header to see where the payment is in the chain. This worked example shows that an MT103 is not just a technical format, it is a business document that tells the story of a payment in a compact, standardised form. The same payment today travels as a pacs.008, which carries the same story in ISO 20022 form.

Read the header first, because it frames everything else. Block 1 shows the sender BIC, which is the London bank, and block 2 shows the receiver BIC, which is the Singapore bank, with the message type 103 and a normal priority. Once you know the sender, the receiver, and the message type, you know this is a customer payment going from London to Singapore, and every field you read next fits into that story.

Now run the validation checks an analyst would run on this message. Check that field 20 is unique and no longer than 16 characters. Check that field 32A has a value date that is a business day and an amount that matches the invoice of ten thousand US dollars. Check that field 50K names Acme Trading Ltd and that the name matches the customer record. Check that field 59 names Meridian Supplies Pte Ltd and that the account number belongs to that company. Check that field 71A says SHA, which matches the fee agreement between the banks. Any mismatch in those checks is a reason to hold the payment and ask a question before the money moves.

Follow what happens after the MT103 is sent. The London bank debits Acme Trading Ltd and sends the MT103 to the Singapore bank. The Singapore bank validates the message, screens the parties, and credits Meridian Supplies Pte Ltd. The correspondent bank sends an MT900 to confirm the debit from the London bank nostro account and an MT910 to confirm the credit to the Singapore bank nostro account. The next day, the statement arrives as an MT940, and the reconciliation team matches the MT103, the MT900, the MT910, and the statement line to close the payment.

If something goes wrong, the same message tells you where to look. If Meridian says the payment has not arrived, check the value date in field 32A and the sender and receiver BICs in the header to see where the payment is in the chain. If Meridian received less than ten thousand dollars, check field 71A and the charges fields to see what was deducted. If the supplier cannot reconcile the payment, check field 70 to see whether the invoice reference 4567 is present. If the payment was sent in error, the London bank can send an MT192 to ask for it back. Today the same payment travels as a pacs.008, which carries the same story in ISO 20022 form, with the same checks, the same charges logic, and the same exception paths.

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.