| 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
Post-migration checklist for a BA: what to verify now that MT103 and MT202 are gone for cross-border payments
What you will learn
Your objective. By the end of this lesson, you will be able to explain post-migration checklist for a BA: what to verify now that MT103 and MT202 are gone for cross-border payments. Now that coexistence has ended on 22 November 2025 and MT103 and MT202 are gone for cross-border payments, the BA checklist has changed.
Why it matters. Confirm that the operations team can read an ISO 20022 message and investigate a payment without needing to translate it to MT.
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
- Now that coexistence has ended
- Check that remittance information
- Document the lessons learned
- No MT103 or MT202 still sent
- Exception flows
- Track validation rejections and look for patterns
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 Post-migration checklist for a BA: what to verify now that MT103 and MT202 are gone for cross-border payments.
Practise this lesson
Exercise
Read the MT103 and 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 post-migration checklist for a BA: what to verify now that MT103 and MT202 are gone for cross-border payments?
Takeaway and next step
What to remember
The migration is done, but the discipline that made it work should stay.
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 "CBPR Plus usage guidelines and scheme rules".
Transcript and full text
Show transcript
Now that coexistence has ended on 22 November 2025 and MT103 and MT202 are gone for cross-border payments, the BA checklist has changed. Instead of planning a migration, you verify that the migration actually worked. Start by confirming that all cross-border payment flows use ISO 20022 messages, pacs.008 for customer transfers, pacs.009 for bank-to-bank transfers, pacs.002 for status, pacs.004 for returns, and camt.056 for cancellations. Check that no MT103 or MT202 messages are still being sent for cross-border payments, and that any MT traffic that remains is for statements, collections, trade finance, domestic flows or historical records only. Next, verify the data quality. Check that structured addresses are populated in the new structured fields, not in free text. Check that remittance information is complete and not truncated. Check that the UETR is present and carried forward on every message. Check that charges are reported in the structured charges elements. Pull a sample of live payments and trace each one end to end, from the customer instruction to the final status report, and confirm that the data survives the full journey without loss. Then verify the downstream systems. Confirm that sanctions screening uses the structured party data, not just the free-text name. Confirm that reconciliation matches on the new references, including the UETR and the end-to-end identification. Confirm that reporting systems produce camt.052, camt.053, and camt.054 statements correctly. Confirm that the operations team can read an ISO 20022 message and investigate a payment without needing to translate it to MT. Finally, document the lessons learned from the migration. Record which mappings were hardest, which counterparties were slowest to migrate, and which validation errors were most common. That record becomes the playbook for the next migration, whether it is a domestic scheme moving to ISO 20022, a new instant payment system, or a new regulatory requirement. The migration is done, but the discipline of documenting what worked and what did not is what makes the next project faster. Start the checklist with a message inventory. List every cross border payment flow the bank runs, and confirm each one uses the right ISO 20022 message. Customer transfers use pacs.008, bank to bank transfers use pacs.009, status reporting uses pacs.002, returns use pacs.004, and cancellations use camt.056. Then check that no MT103 or MT202 is still being sent for cross border payments. Any MT traffic that remains should be for statements, collections, trade finance, domestic flows, or historical records only. Next, verify data quality with a sample of live payments. Pull a set of pacs.008 messages and check that structured addresses are populated in the structured fields, not in free text. Check that remittance information is complete and has not been truncated. Check that the UETR is present and is carried forward on every message in the chain. Check that charges are reported in the structured charges elements. Then trace one payment end to end, from the customer instruction in pain.001 through the pacs.008 to the final pacs.002 status report, and confirm that the data survives the full journey without loss. Then verify the exception flows, because those are the flows that break first. Send a test payment that should be rejected, and confirm a pacs.002 arrives with the right reason code. Send a payment that cannot be applied, and confirm a pacs.004 return arrives. Send a camt.056 cancellation request, and confirm a camt.029 resolution arrives. Confirm that the operations team can read each of those messages, work the exception, and answer a customer query without translating anything back to MT. If the team still reaches for an MT translation to understand a payment, the training is not finished. Finally, set up ongoing governance. Monitor new CBPR Plus releases and assess each one for impact on the implementation. Keep the mapping documents current, because they explain why historical payments look the way they do. Track validation rejections and look for patterns, such as one counterparty repeatedly sending unstructured addresses. Review truncation logs, even though truncation should now be rare for cross border payments. And keep MT knowledge alive in the team, because statements, trade finance, and historical investigations still need it. The migration is done, but the discipline that made it work should stay.
Now that coexistence has ended on 22 November 2025 and MT103 and MT202 are gone for cross-border payments, the BA checklist has changed. Instead of planning a migration, you verify that the migration actually worked. Start by confirming that all cross-border payment flows use ISO 20022 messages, pacs.008 for customer transfers, pacs.009 for bank-to-bank transfers, pacs.002 for status, pacs.004 for returns, and camt.056 for cancellations. Check that no MT103 or MT202 messages are still being sent for cross-border payments, and that any MT traffic that remains is for statements, collections, trade finance, domestic flows or historical records only.
Next, verify the data quality. Check that structured addresses are populated in the new structured fields, not in free text. Check that remittance information is complete and not truncated. Check that the UETR is present and carried forward on every message. Check that charges are reported in the structured charges elements. Pull a sample of live payments and trace each one end to end, from the customer instruction to the final status report, and confirm that the data survives the full journey without loss.
Then verify the downstream systems. Confirm that sanctions screening uses the structured party data, not just the free-text name. Confirm that reconciliation matches on the new references, including the UETR and the end-to-end identification. Confirm that reporting systems produce camt.052, camt.053, and camt.054 statements correctly. Confirm that the operations team can read an ISO 20022 message and investigate a payment without needing to translate it to MT.
Finally, document the lessons learned from the migration. Record which mappings were hardest, which counterparties were slowest to migrate, and which validation errors were most common. That record becomes the playbook for the next migration, whether it is a domestic scheme moving to ISO 20022, a new instant payment system, or a new regulatory requirement. The migration is done, but the discipline of documenting what worked and what did not is what makes the next project faster.
Start the checklist with a message inventory. List every cross border payment flow the bank runs, and confirm each one uses the right ISO 20022 message. Customer transfers use pacs.008, bank to bank transfers use pacs.009, status reporting uses pacs.002, returns use pacs.004, and cancellations use camt.056. Then check that no MT103 or MT202 is still being sent for cross border payments. Any MT traffic that remains should be for statements, collections, trade finance, domestic flows, or historical records only.
Next, verify data quality with a sample of live payments. Pull a set of pacs.008 messages and check that structured addresses are populated in the structured fields, not in free text. Check that remittance information is complete and has not been truncated. Check that the UETR is present and is carried forward on every message in the chain. Check that charges are reported in the structured charges elements. Then trace one payment end to end, from the customer instruction in pain.001 through the pacs.008 to the final pacs.002 status report, and confirm that the data survives the full journey without loss.
Then verify the exception flows, because those are the flows that break first. Send a test payment that should be rejected, and confirm a pacs.002 arrives with the right reason code. Send a payment that cannot be applied, and confirm a pacs.004 return arrives. Send a camt.056 cancellation request, and confirm a camt.029 resolution arrives. Confirm that the operations team can read each of those messages, work the exception, and answer a customer query without translating anything back to MT. If the team still reaches for an MT translation to understand a payment, the training is not finished.
Finally, set up ongoing governance. Monitor new CBPR Plus releases and assess each one for impact on the implementation. Keep the mapping documents current, because they explain why historical payments look the way they do. Track validation rejections and look for patterns, such as one counterparty repeatedly sending unstructured addresses. Review truncation logs, even though truncation should now be rare for cross border payments. And keep MT knowledge alive in the team, because statements, trade finance, and historical investigations still need it. The migration is done, but the discipline that made it work should stay.
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.