| 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
Adoption timeline and CBPR Plus
What you will learn
Your objective. By the end of this lesson, you will be able to explain adoption timeline and CBPR plus. ISO 20022 adoption followed a phased timeline, and the cross-border migration is now complete.
Why it matters. For a business analyst, the timeline matters because it explains the state of the systems you work on.
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
- ISO 20022 adoption followed a phased timeline
- SEPA: built
- Timeline matters because it
- Same payment sent on Monday
- Why the timeline
- One detail worth knowing
Key terms
Remittance information: Information that explains what a payment is for, such as invoice numbers, contract references or salary month.
Settlement: The final movement of funds between banks to discharge obligations created by cleared payments. Settlement is usually made in central bank money or through correspondent accounts.
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 Adoption timeline and CBPR Plus.
Practise this lesson
Exercise
Read the ISO 20022 adoption 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 adoption timeline and CBPR plus?
Takeaway and next step
What to remember
For a business analyst, the timeline matters because it explains the state of the systems you work on.
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 "The message catalogue, pacs, pain and camt".
Transcript and full text
Show transcript
ISO 20022 adoption followed a phased timeline, and the cross-border cutover for FI to FI payment instructions is complete, but migration work continues. The coexistence period for cross-border payments began in March 2023, when banks could send both MT and ISO 20022 messages. It ended on 22 November 2025. From that date, the in-scope FI to FI payment instructions (MT102, MT103, MT200, MT201, MT202, MT203) are no longer accepted for cross-border payments on the SWIFT network; they now use ISO 20022. MT messages still flow for other purposes: MT940, MT942 and MT950 reporting, the MT700 series for trade finance, MT19x and MT29x exceptions and investigations, and MT101 payment initiation. Source: SWIFT CBPR+ end of coexistence scope, 22 Nov 2025. Domestic systems followed their own timelines. CHIPS, the US private-sector system for large payments, moved to ISO 20022 in April 2024. Fedwire, the Federal Reserve real-time gross settlement system, moved to ISO 20022 in July 2025. SEPA had already been using ISO 20022 for years, since the SCT and SDD schemes were built on it. The Bank of England CHAPS system also moved to ISO 20022. The result is that most major payment systems in the world now use the same standard. The CBPR Plus programme defined the usage guidelines for the cross-border migration. It specified which ISO 20022 messages to use for which purpose, which fields are mandatory, and how to populate structured data. The programme continues to publish annual guideline releases. Migration work continues after November 2025 for the exceptions and investigations messages, for reporting, and for the interbank MT101 relay, so the current releases do not assume that all cross-border work is finished. For a business analyst, the timeline matters because it explains the state of the systems you work on. If you join a bank in 2026, you will still find live MT to MX migration work: the interbank MT101 relay migration, the exceptions and investigations migration (the deferred Standards Release 2026 package, 12 June 2027), and the reporting migration (MT to camt coexistence ending November 2028). Source: SWIFT Standards Release 2026 deferral announcement 27 Aug 2026, updated 21 Sep 2026. You will find ISO 20022 as the standard, and your work will be about using the rich data it carries, not about translating between formats. You will still need to understand MT, because historical records, investigations, and some domestic systems still use it, but the cross-border future is ISO 20022 only. Put the cutover date to work with a real case. A bank sends a cross border payment on Friday 21 November 2025 as an MT103, and it is accepted, because coexistence is still running. The same payment sent on Monday 24 November 2025 as an MT103 is rejected by the network, because coexistence ended on 22 November 2025 and cross border payment instructions must now travel as ISO 20022 messages. The payment has to be rebuilt as a pacs zero zero eight, with the same amount, value date, and remittance information, and sent again. The same logic applies on the domestic systems, each on its own date. A US dollar payment routed through CHIPS after April 2024 travels as a pacs zero zero eight, and a bank whose system still generates an MT103 for that corridor will see the payment rejected at the gateway. This is why the timeline is not history for its own sake. Every date in it is a day on which a working payment flow either kept working or stopped. For a business analyst, the migration dates shape three concrete pieces of work. First, a message inventory, every payment flow in the bank, the message it uses today, and the message it must use after each cutover date. Second, a field mapping document, for example MT103 field 32A to the pacs zero zero eight settlement amount and value date, so developers are never guessing. Third, a test calendar with dress rehearsals before each cutover and an exception queue for stragglers afterwards. One detail worth knowing. The November 2025 cutover covered cross border MT103 and MT202 payment instructions only. MT101 corporate to bank instructions were never part of the FIN deadline, and the interbank MT101 relay cutover set for 14 November 2026 was itself deferred by SWIFT on 27 August 2026, with no replacement date set and a new timeline promised by December 2026. A bank that still receives MT101 files from its corporate customers in 2026 is not behind schedule. Source: SWIFT deferral of SR2026 payments changes, 27 Aug 2026. An analyst who confuses the two will raise a false alarm and waste a project. Worked example with real numbers: a bank sends a EUR 100,000 payment from Paris to New York on 10 November 2025 as an MT103, and it is accepted, because coexistence is still running. The same payment sent on 24 November 2025 as an MT103 is rejected by the network, because coexistence ended on 22 November 2025 and the in-scope payment instructions must now travel as ISO 20022. The bank rebuilds the payment as a pacs.008 with the same amount, value date and remittance information, and it settles. In the same week, the bank receives an MT940 statement for the account, and that MT message is accepted, because reporting was not part of the November 2025 cutover. The two messages show the cutover scope: payment instructions migrated, reporting did not, and the analyst must know which is which. Failure and recovery: a bank that sends an MT103 after the cutover receives a network reject, and the recovery is to rebuild the payment as a pacs.008 and resend, not to retry the MT103, because the network will reject it again. A bank that sends a pacs.008 in the wrong version, for example pacs.008.001.02 when the usage guideline requires pacs.008.001.08, has the whole file rejected, and the recovery is to upgrade the version, which is a project change. A bank that assumes the migration is finished and stops its MT to MX mapping work will be caught out when the exceptions and investigations migration arrives, because the MT19x and MT29x messages it still uses will need ISO 20022 equivalents, and the mapping must be built before the cutover, not after it. Source: SWIFT CBPR+ end of coexistence scope, 22 Nov 2025; SWIFT Standards Release 2026 deferral announcement 27 Aug 2026. Last reviewed 7 November 2026.
ISO 20022 adoption followed a phased timeline, and the cross-border cutover for FI to FI payment instructions is complete, but migration work continues. The coexistence period for cross-border payments began in March 2023, when banks could send both MT and ISO 20022 messages. It ended on 22 November 2025. From that date, the in-scope FI to FI payment instructions (MT102, MT103, MT200, MT201, MT202, MT203) are no longer accepted for cross-border payments on the SWIFT network; they now use ISO 20022. MT messages still flow for other purposes: MT940, MT942 and MT950 reporting, the MT700 series for trade finance, MT19x and MT29x exceptions and investigations, and MT101 payment initiation. Source: SWIFT CBPR+ end of coexistence scope, 22 Nov 2025.
Domestic systems followed their own timelines. CHIPS, the US private-sector system for large payments, moved to ISO 20022 in April 2024. Fedwire, the Federal Reserve real-time gross settlement system, moved to ISO 20022 in July 2025. SEPA had already been using ISO 20022 for years, since the SCT and SDD schemes were built on it. The Bank of England CHAPS system also moved to ISO 20022. The result is that most major payment systems in the world now use the same standard.
The CBPR Plus programme defined the usage guidelines for the cross-border migration. It specified which ISO 20022 messages to use for which purpose, which fields are mandatory, and how to populate structured data. The programme continues to publish annual guideline releases. Migration work continues after November 2025 for the exceptions and investigations messages, for reporting, and for the interbank MT101 relay, so the current releases do not assume that all cross-border work is finished.
For a business analyst, the timeline matters because it explains the state of the systems you work on. If you join a bank in 2026, you will still find live MT to MX migration work: the interbank MT101 relay migration, the exceptions and investigations migration (the deferred Standards Release 2026 package, 12 June 2027), and the reporting migration (MT to camt coexistence ending November 2028). Source: SWIFT Standards Release 2026 deferral announcement 27 Aug 2026, updated 21 Sep 2026. You will find ISO 20022 as the standard, and your work will be about using the rich data it carries, not about translating between formats. You will still need to understand MT, because historical records, investigations, and some domestic systems still use it, but the cross-border future is ISO 20022 only.
Put the cutover date to work with a real case. A bank sends a cross border payment on Friday 21 November 2025 as an MT103, and it is accepted, because coexistence is still running. The same payment sent on Monday 24 November 2025 as an MT103 is rejected by the network, because coexistence ended on 22 November 2025 and cross border payment instructions must now travel as ISO 20022 messages. The payment has to be rebuilt as a pacs zero zero eight, with the same amount, value date, and remittance information, and sent again.
The same logic applies on the domestic systems, each on its own date. A US dollar payment routed through CHIPS after April 2024 travels as a pacs zero zero eight, and a bank whose system still generates an MT103 for that corridor will see the payment rejected at the gateway. This is why the timeline is not history for its own sake. Every date in it is a day on which a working payment flow either kept working or stopped.
For a business analyst, the migration dates shape three concrete pieces of work. First, a message inventory, every payment flow in the bank, the message it uses today, and the message it must use after each cutover date. Second, a field mapping document, for example MT103 field 32A to the pacs zero zero eight settlement amount and value date, so developers are never guessing. Third, a test calendar with dress rehearsals before each cutover and an exception queue for stragglers afterwards. One detail worth knowing.
The November 2025 cutover covered cross border MT103 and MT202 payment instructions only. MT101 corporate to bank instructions were never part of the FIN deadline, and the interbank MT101 relay cutover set for 14 November 2026 was itself deferred by SWIFT on 27 August 2026, with no replacement date set and a new timeline promised by December 2026. A bank that still receives MT101 files from its corporate customers in 2026 is not behind schedule. Source: SWIFT deferral of SR2026 payments changes, 27 Aug 2026. An analyst who confuses the two will raise a false alarm and waste a project.
Worked example with real numbers: a bank sends a EUR 100,000 payment from Paris to New York on 10 November 2025 as an MT103, and it is accepted, because coexistence is still running. The same payment sent on 24 November 2025 as an MT103 is rejected by the network, because coexistence ended on 22 November 2025 and the in-scope payment instructions must now travel as ISO 20022. The bank rebuilds the payment as a pacs.008 with the same amount, value date and remittance information, and it settles. In the same week, the bank receives an MT940 statement for the account, and that MT message is accepted, because reporting was not part of the November 2025 cutover. The two messages show the cutover scope: payment instructions migrated, reporting did not, and the analyst must know which is which.
Failure and recovery: a bank that sends an MT103 after the cutover receives a network reject, and the recovery is to rebuild the payment as a pacs.008 and resend, not to retry the MT103, because the network will reject it again. A bank that sends a pacs.008 in the wrong version, for example pacs.008.001.02 when the usage guideline requires pacs.008.001.08, has the whole file rejected, and the recovery is to upgrade the version, which is a project change.
A bank that assumes the migration is finished and stops its MT to MX mapping work will be caught out when the exceptions and investigations migration arrives, because the MT19x and MT29x messages it still uses will need ISO 20022 equivalents, and the mapping must be built before the cutover, not after it. Source: SWIFT CBPR+ end of coexistence scope, 22 Nov 2025; SWIFT Standards Release 2026 deferral announcement 27 Aug 2026. Last reviewed 7 November 2026.
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.