| 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
Why ISO 20022 replaced MT
What you will learn
Your objective. By the end of this lesson, you will be able to explain ISO 20022 replaced MT. SWIFT MT served the industry well for decades, but it has limitations that became more pressing as payments became faster, more complex, and more regulated.
Why it matters. An analyst must be able to explain these benefits to stakeholders who see only the cost of migration, because the business case depends on those benefits being realised in operations, not just on the technical ability to send a new message format.
Chapter objective: Learner explains ISO 20022 structure, including business concepts, message definitions, XML syntax, and the roles of pacs, pain, camt, and admi messages, and navigates the message catalogue confidently. Learner practises this skill on realistic banking cases, explaining the reasoning clearly and using correct terminology throughout the work.
Key learning points
- SWIFT MT served the industry well
- Data: often truncated
- ISO 20022
- Migration: therefore just technical change
- Analyst must be able
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Sanctions screening: Checking payment parties, countries and references against sanctions lists published by governments and international bodies.
Reconciliation: The process of comparing records from two sources, such as a bank statement and an internal ledger, to confirm they agree.
SWIFT MT message viewer showing Why ISO 20022 replaced MT.
Practise this lesson
Exercise
Read the MT103 can 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
A developer is mapping a payment into ISO 20022 and asks which message carries the customer credit transfer itself. What should the BA answer?
Takeaway and next step
What to remember
An analyst must be able to explain these benefits to stakeholders who see only the cost of migration, because the business case depends on those benefits being realised in operations, not just on the technical ability to send a new message format.
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 "What ISO 20022 is".
Transcript and full text
Show transcript
SWIFT MT served the industry well for decades, but it has limitations that became more pressing as payments became faster, more complex, and more regulated. The first limitation is data richness. An MT103 can carry only 140 characters of remittance information, and addresses are limited to 35 characters per line. That is not enough for a corporate that needs to reconcile a payment against multiple invoices, or for a bank that needs a full structured address for sanctions screening. Data is often truncated, abbreviated, or placed in free text fields, which makes automation difficult and increases the risk of errors. The second limitation is structure. MT fields are flat and have limited nesting, so it is hard to represent complex relationships, such as a payment that involves an ultimate debtor who is different from the debtor, or a creditor who is different from the ultimate creditor. ISO 20022, by contrast, has a hierarchical XML structure that can represent those relationships clearly. The third limitation is interoperability. MT is primarily a SWIFT standard, while ISO 20022 is an open international standard that can be used by any scheme, any clearing system, and any bank, whether or not it uses SWIFT. That openness is why domestic schemes around the world are adopting ISO 20022 for their own real time and batch systems. The migration is therefore not just a technical change, it is a business change. Richer data means better reconciliation, better fraud detection, better sanctions screening, and better customer service. A supplier who receives a pacs zero zero eight with full invoice details can reconcile the payment automatically, without manual work. A compliance team that receives a structured address can screen more accurately, with fewer false positives. An analyst must be able to explain these benefits to stakeholders who see only the cost of migration, because the business case depends on those benefits being realised in operations, not just on the technical ability to send a new message format. Worked example with real numbers: a corporate sends 1,000 payments a month, each with five invoices, and in MT the remittance was truncated to 140 characters, so only three invoices per payment could be reconciled automatically, and the other two were reconciled manually at 15 minutes each, which is 500 hours a month. In ISO 20022 the pacs.008 carries structured remittance for all five invoices, so all 1,000 payments reconcile automatically, and the 500 hours are saved. The migration cost was EUR 200,000, so the payback was under six months, and the business case was written on reconciliation hours, not on message counts. A business analyst who cannot quantify the benefit in hours and errors will lose the business case to a stakeholder who sees only the cost. Failure and recovery: a migration that truncates data, because a long beneficiary name is cut from 35 characters to a structured address field that is shorter, will cause rejections or reconciliation failures, and the recovery is to change the mapping rule, to carry the full data in a structured field, or to agree with the beneficiary that the data will be sent separately. A migration that sends the wrong version, because the namespace was not updated, will cause the whole file to be rejected, and the recovery is to upgrade the version and resend. Each failure is a mapping failure, and it is found by testing the mapping with a real payment, field by field, before go live. For a business analyst, product owner or subject matter expert, the test is to explain why ISO 20022 replaced MT in business terms, not in technical terms: richer data means better reconciliation, better fraud detection, better sanctions screening and better customer service, and the analyst must give a worked example for each benefit, with numbers. The MT103 carried 140 characters of remittance and 35-character address lines, while the pacs.008. A requirement that says migrate to ISO 20022, without stating the benefit, the mapping and the test, is a technical task, not a business change, and it will be challenged at the first governance review.
SWIFT MT served the industry well for decades, but it has limitations that became more pressing as payments became faster, more complex, and more regulated. The first limitation is data richness. An MT103 can carry only 140 characters of remittance information, and addresses are limited to 35 characters per line. That is not enough for a corporate that needs to reconcile a payment against multiple invoices, or for a bank that needs a full structured address for sanctions screening. Data is often truncated, abbreviated, or placed in free text fields, which makes automation difficult and increases the risk of errors.
The second limitation is structure. MT fields are flat and have limited nesting, so it is hard to represent complex relationships, such as a payment that involves an ultimate debtor who is different from the debtor, or a creditor who is different from the ultimate creditor. ISO 20022, by contrast, has a hierarchical XML structure that can represent those relationships clearly. The third limitation is interoperability. MT is primarily a SWIFT standard, while ISO 20022 is an open international standard that can be used by any scheme, any clearing system, and any bank, whether or not it uses SWIFT. That openness is why domestic schemes around the world are adopting ISO 20022 for their own real time and batch systems.
The migration is therefore not just a technical change, it is a business change. Richer data means better reconciliation, better fraud detection, better sanctions screening, and better customer service. A supplier who receives a pacs zero zero eight with full invoice details can reconcile the payment automatically, without manual work. A compliance team that receives a structured address can screen more accurately, with fewer false positives. An analyst must be able to explain these benefits to stakeholders who see only the cost of migration, because the business case depends on those benefits being realised in operations, not just on the technical ability to send a new message format.
Worked example with real numbers: a corporate sends 1,000 payments a month, each with five invoices, and in MT the remittance was truncated to 140 characters, so only three invoices per payment could be reconciled automatically, and the other two were reconciled manually at 15 minutes each, which is 500 hours a month. In ISO 20022 the pacs.008 carries structured remittance for all five invoices, so all 1,000 payments reconcile automatically, and the 500 hours are saved. The migration cost was EUR 200,000, so the payback was under six months, and the business case was written on reconciliation hours, not on message counts. A business analyst who cannot quantify the benefit in hours and errors will lose the business case to a stakeholder who sees only the cost.
Failure and recovery: a migration that truncates data, because a long beneficiary name is cut from 35 characters to a structured address field that is shorter, will cause rejections or reconciliation failures, and the recovery is to change the mapping rule, to carry the full data in a structured field, or to agree with the beneficiary that the data will be sent separately. A migration that sends the wrong version, because the namespace was not updated, will cause the whole file to be rejected, and the recovery is to upgrade the version and resend. Each failure is a mapping failure, and it is found by testing the mapping with a real payment, field by field, before go live.
For a business analyst, product owner or subject matter expert, the test is to explain why ISO 20022 replaced MT in business terms, not in technical terms: richer data means better reconciliation, better fraud detection, better sanctions screening and better customer service, and the analyst must give a worked example for each benefit, with numbers. The MT103 carried 140 characters of remittance and 35-character address lines, while the pacs.008. A requirement that says migrate to ISO 20022, without stating the benefit, the mapping and the test, is a technical task, not a business change, and it will be challenged at the first governance review.
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.