| 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 migration was needed, and how coexistence ended
What you will learn
Your objective. By the end of this lesson, you will be able to explain migration was needed. Migration from MT to ISO 20022 was needed because MT could no longer carry the rich, structured data that modern payments require, and because domestic schemes around the world were adopting ISO 20022 independently,.
Why it matters. For a business analyst, the end of coexistence changes the work.
Chapter objective: Learner plans an MT to MX migration, explains CBPR+ scope and timelines, and maps MT103, MT202, and MT202COV to pacs.008, pacs.009, and pacs.009 COV equivalents with data gaps noted. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Migration from MT to ISO 20022
- Core messages such as MT103 and MT202
- Translation risk
- MT knowledge
- Three forces drove
- Investigations still involve MT
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.
ISO 20022: An international standard for financial messaging that defines XML message formats for payments, securities and trade.
SWIFT MT message viewer showing Why migration was needed, and how coexistence ended.
Practise this lesson
Exercise
Read the ISO 20022 was 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
What is the core change under CBPR+ for cross-border payments?
Takeaway and next step
What to remember
For a business analyst, the end of coexistence changes the work.
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: processing pacs.008 at scale".
Transcript and full text
Show transcript
Migration from MT to ISO 20022 was needed because MT could no longer carry the rich, structured data that modern payments require, and because domestic schemes around the world were adopting ISO 20022 independently, which would have created fragmentation if cross-border payments had stayed on MT. The migration was therefore run as a community programme, CBPR Plus, with a coexistence period during which both MT and MX would be supported. Coexistence meant that a bank could send a payment as an MT103 or as a pacs.008, and the receiving bank had to be able to accept either format, process it, and, if needed, translate it to the other format for onward transmission. The coexistence period ended on 22 November 2025. From that date, MT messages are no longer accepted for cross-border payments on the SWIFT network. Core messages such as MT103 and MT202 cannot be sent for cross-border payment instructions. All cross-border payment instructions now use ISO 20022 messages, pacs.008 for customer credit transfers, pacs.009 for bank-to-bank transfers, pacs.002 for status reports, pacs.004 for returns, and camt.056 for cancellation requests. Banks that had not completed their migration by the deadline could no longer send cross-border payments on SWIFT until they did. During coexistence, a payment could start as an MX message, be translated to MT for a bank that had not yet migrated, and then be translated back to MX for the next bank that had migrated. Each translation was a point where data could be lost, truncated, or misinterpreted, and each translation added cost and operational risk. That translation risk is now gone for cross-border payments, because every bank in the chain uses the same format. The data that used to be truncated in translation now flows end to end in structured fields. For a business analyst, the end of coexistence changes the work. Your requirements no longer need to state which formats are supported for each flow, because there is only one format for cross-border payments. Your test plan no longer needs to cover MT to MT, MX to MX, MT to MX, and MX to MT flows. Instead, your work focuses on the richness of the ISO 20022 data, making sure structured addresses, remittance information, and party data are populated correctly, and making sure screening, reconciliation, and reporting systems use the new structured fields. MT knowledge is still valuable, because many payment investigations, historical records, and domestic systems still involve MT messages, and because understanding what MT could not carry explains why ISO 20022 was designed the way it was. The timeline ran over several years. SWIFT published the CBPR Plus usage guidelines and set out the migration plan, and ISO 20022 went live for cross border payments in March 2023. From that date, banks could send cross border payments as pacs.008 and pacs.009, and the coexistence period began. During coexistence, both MT and MX were accepted, and banks migrated at their own pace. The coexistence period ended on 22 November 2025. From that date, MT103 and MT202 are no longer accepted for cross border payment instructions on the SWIFT network, and any bank that had not migrated could no longer send cross border payments until it did. Three forces drove the change. The first was data. Compliance teams needed structured names and addresses to screen payments properly, and MT free text made screening slow and unreliable. The second was straight through processing. Richer structured data means fewer payments fall into repair queues, which means lower cost and faster delivery for customers. The third was consistency. Domestic schemes around the world were moving to ISO 20022 on their own timetables, and if cross border payments had stayed on MT, every payment that crossed from a domestic scheme to the cross border network would have needed translation. One shared standard removes that friction. MT did not disappear entirely. Statements still arrive as MT940 and MT950, trade finance still uses MT700 series messages, collections still use MT400 series messages, and some domestic flows still use MT. Investigations also still involve MT, because a payment from before the cutover, or a statement line from last year, will be in MT form. That is why this chapter still matters. A business analyst who can read an MT103 and a pacs.008, and who can explain what changed between them, is far more useful than one who only knows the new format.
Migration from MT to ISO 20022 was needed because MT could no longer carry the rich, structured data that modern payments require, and because domestic schemes around the world were adopting ISO 20022 independently, which would have created fragmentation if cross-border payments had stayed on MT. The migration was therefore run as a community programme, CBPR Plus, with a coexistence period during which both MT and MX would be supported. Coexistence meant that a bank could send a payment as an MT103 or as a pacs.008, and the receiving bank had to be able to accept either format, process it, and, if needed, translate it to the other format for onward transmission.
The coexistence period ended on 22 November 2025. From that date, MT messages are no longer accepted for cross-border payments on the SWIFT network. Core messages such as MT103 and MT202 cannot be sent for cross-border payment instructions. All cross-border payment instructions now use ISO 20022 messages, pacs.008 for customer credit transfers, pacs.009 for bank-to-bank transfers, pacs.002 for status reports, pacs.004 for returns, and camt.056 for cancellation requests. Banks that had not completed their migration by the deadline could no longer send cross-border payments on SWIFT until they did.
During coexistence, a payment could start as an MX message, be translated to MT for a bank that had not yet migrated, and then be translated back to MX for the next bank that had migrated. Each translation was a point where data could be lost, truncated, or misinterpreted, and each translation added cost and operational risk. That translation risk is now gone for cross-border payments, because every bank in the chain uses the same format. The data that used to be truncated in translation now flows end to end in structured fields.
For a business analyst, the end of coexistence changes the work. Your requirements no longer need to state which formats are supported for each flow, because there is only one format for cross-border payments. Your test plan no longer needs to cover MT to MT, MX to MX, MT to MX, and MX to MT flows. Instead, your work focuses on the richness of the ISO 20022 data, making sure structured addresses, remittance information, and party data are populated correctly, and making sure screening, reconciliation, and reporting systems use the new structured fields. MT knowledge is still valuable, because many payment investigations, historical records, and domestic systems still involve MT messages, and because understanding what MT could not carry explains why ISO 20022 was designed the way it was.
The timeline ran over several years. SWIFT published the CBPR Plus usage guidelines and set out the migration plan, and ISO 20022 went live for cross border payments in March 2023. From that date, banks could send cross border payments as pacs.008 and pacs.009, and the coexistence period began. During coexistence, both MT and MX were accepted, and banks migrated at their own pace. The coexistence period ended on 22 November 2025. From that date, MT103 and MT202 are no longer accepted for cross border payment instructions on the SWIFT network, and any bank that had not migrated could no longer send cross border payments until it did.
Three forces drove the change. The first was data. Compliance teams needed structured names and addresses to screen payments properly, and MT free text made screening slow and unreliable. The second was straight through processing. Richer structured data means fewer payments fall into repair queues, which means lower cost and faster delivery for customers. The third was consistency. Domestic schemes around the world were moving to ISO 20022 on their own timetables, and if cross border payments had stayed on MT, every payment that crossed from a domestic scheme to the cross border network would have needed translation. One shared standard removes that friction.
MT did not disappear entirely. Statements still arrive as MT940 and MT950, trade finance still uses MT700 series messages, collections still use MT400 series messages, and some domestic flows still use MT. Investigations also still involve MT, because a payment from before the cutover, or a statement line from last year, will be in MT form. That is why this chapter still matters. A business analyst who can read an MT103 and a pacs.008, and who can explain what changed between them, is far more useful than one who only knows the new format.
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.