Key points of this lesson, in order.
Capstone Brief: BA on a SWIFT MT to ISO 20022 Migration
What you will learn
Your objective. By the end of this lesson, you will be able to explain capstone brief: BA on a SWIFT MT to ISO 20022 migration. You are the business analyst assigned to a migration project at a mid-sized bank in Mumbai that sends around 12,000 outward cross-border payments a day, and your job is to move those payments from SWIFT MT format to ISO.
Why it matters. You are the business analyst assigned to a migration project at a mid-sized bank in Mumbai that sends around 12,000 outward cross-border payments a day, and your job is to move those payments from SWIFT MT format to ISO 20022.
Chapter objective: Learner completes a capstone project that designs an end-to-end payment solution for a stated business problem, integrating messages, rails, controls, and operations into one coherent proposal. Learner demonstrates this skill using realistic banking examples, explaining each step clearly and using correct terminology throughout.
Key learning points
- Business analyst assigned to migration
- Project scope covers outward customer payments
- Stakeholders span whole bank
- Timeline runs nine months
- Deliverables: artefacts this capstone teaches
- Risks are real, plan for them
Key terms
Correspondent banking: A service where one bank holds accounts for another bank so the second bank can make payments in currencies or countries where it has no branch.
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.
Clearing and settlement timeline showing Capstone Brief: BA on a SWIFT MT to ISO 20022 Migration.
Practise this lesson
Exercise
Scenario: you are a payments BA writing a test strategy for a new ISO 20022 migration. The bank is migrating its cross-border payments from MT to MX (CBPR+). The migration covers MT103 to pacs.008, MT202 to pacs.009, and MT950 to camt.053. Write a test strategy that covers functional testing, negative testing, migration testing, and production support. For each test area, list the test scenarios, the expected results, and the acceptance criteria.
The migration: MT103 (customer credit transfer) becomes pacs.008. MT202 (financial institution transfer) becomes pacs.009. MT950 (statement message) becomes camt.053. The bank processes 10,000 cross-border payments per day. The migration must not disrupt live payments. The test environment has a test SWIFT connection and a test ISO 20022 interface. The go-live date is 22 November 2025. The test strategy must cover: message validation, field mapping, status reporting, exception handling, reconciliation, and rollback.
- What to do. Write the test strategy with four sections: functional testing, negative testing, migration testing, and production support. For each section, list at least five test scenarios with the input, the expected result, and the acceptance criterion. Then state the entry and exit criteria for each test phase.
Correct result. Functional testing: test 1, send a valid pacs.008 for a USD 10,000 payment and verify it is accepted with status ACCP and the beneficiary is credited; acceptance criterion is that the pacs.008 is accepted and the pacs.002 returns ACCP. Test 2, send a pacs.008 with a valid IBAN and verify the beneficiary account is credited in full; acceptance criterion is that the credited amount matches the instructed amount. Test 3, send a pacs.009 for a bank-to-bank transfer and verify it settles; acceptance criterion is that the pacs.009 is accepted and the settlement account is debited. Test 4, receive a camt.053 statement and verify it reconciles to the internal ledger; acceptance criterion is that all entries match. Test 5, send a pacs.008 with a charge bearer OUR and verify the beneficiary receives the full amount; acceptance criterion is that no charges are deducted. Negative testing: test 1, send a pacs.008 with an invalid IBAN and verify it is rejected with reason code AC01; acceptance criterion is that the rejection is returned with the correct code. Test 2, send a pacs.008 with a negative amount and verify it is rejected; acceptance criterion is that the rejection is returned. Test 3, send a pacs.008 with a missing mandatory field and verify it is rejected; acceptance criterion is that the schema validation fails. Test 4, send a duplicate pacs.008 with the same UETR and verify it is detected as a duplicate; acceptance criterion is that the duplicate is rejected with reason code AM05. Test 5, send a pacs.008 with an amount over the limit and verify it is rejected or held; acceptance criterion is that the limit is enforced. Migration testing: test 1, send an MT103 and verify it is converted to a pacs.008 with all fields mapped correctly; acceptance criterion is that the pacs.008 matches the MT103 field by field. Test 2, send an MT202 and verify it is converted to a pacs.009; acceptance criterion is that the pacs.009 matches the MT202. Test 3, receive an MT950 and verify it is converted to a camt.053; acceptance criterion is that the camt.053 matches the MT950. Test 4, run a parallel test with live MT traffic and verify the MX output matches; acceptance criterion is that the MX output is identical to the expected output. Test 5, test the rollback: revert to MT and verify payments continue; acceptance criterion is that the rollback completes within one hour and no payments are lost. Production support: monitor the pacs.002 status codes, the rejection rate, and the reconciliation breaks for the first week; acceptance criterion is that the rejection rate is below 0.1 percent and all breaks are resolved within one business day. Entry criteria: test environment is ready, test data is prepared, and the test cases are approved. Exit criteria: all functional and negative tests pass, migration tests pass, and the rollback test passes. Worked reasoning: a test strategy covers functional (does it work), negative (does it fail correctly), migration (does the conversion work), and production support (can we operate it). Each test needs an input, an expected result, and an acceptance criterion, so the test is objective.
Why. Hint 1: a test strategy has four parts: functional, negative, migration and production support; do not write only functional tests. Hint 2: every test needs an input, an expected result and an acceptance criterion. Hint 3: negative testing is as important as functional testing, because it proves the system fails safely. The worked explanation shows the test strategy discipline: cover what should happen, what should not happen, how the migration works, and how the system will be operated after go-live.
Check your understanding
Practice question
In a capstone project to design a cross-border payment flow, what is the most important deliverable?
Takeaway and next step
What to remember
Your job as BA is to surface these risks early, document them, and drive the decisions that resolve them.
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 →
The capstone. It sits at the end of the Professional pathway, after ch28, ch35, ch37 and ch45. Complete those chapters first.
Transcript and full text
Show transcript
You are the business analyst assigned to a migration project at a mid-sized bank in Mumbai that sends around 12,000 outward cross-border payments a day, and your job is to move those payments from SWIFT MT format to ISO 20022. The bank's payment hub still produces MT103 messages for customer payments, MT202 messages for bank-to-bank transfers, and MT940 messages for account statements, and MT103 and MT202 must be replaced by their ISO 20022 equivalents before the 22 November 2025 deadline that ended coexistence for cross-border FI to FI payment instructions; MT940 reporting migrates on a separate timeline, with MT to camt coexistence ending November 2028. Source: SWIFT CBPR+ end of coexistence 22 Nov 2025; SWIFT reporting migration to Nov 2028. The migration is not optional, and the bank cannot send payments after the deadline if it has not migrated. The project scope covers outward customer payments first, because they carry the highest volume and the highest regulatory risk. In scope are the conversion of MT103 to pacs.008, the mapping of all fields including the party identification fields, the validation rules for the new format, the exception handling for messages that fail conversion, and the reconciliation reporting that proves every payment was converted correctly. Out of scope for this phase are inward payments, which will migrate in a later release, and the MT940 statement migration, which is handled by a separate team. Your stakeholders span the whole bank. The project sponsor is the head of transaction banking, who owns the budget and the deadline. The payment operations team of 25 staff will use the new process daily and must be trained. The compliance team must confirm that the new messages carry all the data required for sanctions screening and regulatory reporting. The IT team of eight developers and four testers will build and test the conversion engine. The correspondent banking team manages the nostro agents who receive the new messages, and the SWIFT operations team manages the connectivity to the SWIFT network. The timeline runs for nine months, from March to November 2025, so the bank is ready before the 22 November 2025 deadline. March and April are for analysis and mapping, May and June for build, July and August for testing, September for user acceptance testing, October for dress rehearsals and training, and November for go-live. There are two hard milestones. The mapping document must be signed off by the end of April, and user acceptance testing must be complete by the end of September. Missing the April milestone pushes the build, and missing September leaves no time for rehearsal before the deadline. Your deliverables are the artefacts this capstone will teach you to produce. You will write the Business Requirements Document, the field-by-field mapping document, the user stories with acceptance criteria, the test cases for user acceptance testing, the training material for the operations team, and the go-live checklist. Each deliverable has a reviewer and a sign-off date, and each one builds on the previous one, so a mistake in the mapping document flows into the user stories, the tests and the training. Getting the mapping right is the single most important thing you will do. The risks are real and you must plan for them. The biggest risk is that a field in the MT103 has no direct equivalent in pacs.008, which means the team must agree a translation rule or accept data loss, and either choice needs compliance approval. Another risk is that a nostro agent bank is not ready to receive pacs.008, which would force the bank to keep sending MT103 to that corridor. A third risk is volume. The conversion engine must handle the morning peak of 3,000 payments an hour without slowing down. Your job as BA is to surface these risks early, document them, and drive the decisions that resolve them. Take one payment through the migration to make it concrete. A corporate customer sends an MT103 for USD 25,000 to a supplier in Singapore, with field 50K for the ordering customer, field 59 for the beneficiary, field 70 for remittance information, and field 71A for the charges. In pacs.008, the same payment has a group header, a payment information block, and a credit transfer transaction block, with the debtor, the creditor, the instructed amount, and the remittance information as structured fields. The mapping document must show each MT103 field, its pacs.008 equivalent, and the rule for fields that have no direct equivalent, such as field 72, which becomes structured remittance information or is dropped with approval. That mapping is the single most important deliverable in the project. The nostro readiness risk is the one that catches migrations by surprise. Suppose the bank is ready to send pacs.008 on 1 November 2025, but its nostro agent in Japan is not ready to receive it until January 2026. The bank must either keep sending MT103 to that corridor, which is not possible after the cutover for in scope messages, or route the payment through a different correspondent that is ready, which changes the charges and the value date. The BA must therefore track the readiness of every nostro agent, corridor by corridor, and must define the fallback for each corridor that is not ready. A migration that is ready internally but not ready with its counterparties is not ready at all. The capstone teaches the BA's core skill: turning a regulatory deadline into a project that can actually be delivered. The BA must write the business requirements document, the field by field mapping, user stories with acceptance criteria, test cases for user acceptance testing, training material, and the go-live checklist, and each one must be consistent with the others. The BA must also manage the stakeholders: the sponsor who owns the budget, operations who will use the new process, compliance who must approve the mapping, IT who will build it, and the correspondent banks who must receive it. The capstone is a rehearsal for the real work, and the standard is the same: a mapping that is wrong will break payments, and a migration that misses its deadline will stop them.
You are the business analyst assigned to a migration project at a mid-sized bank in Mumbai that sends around 12,000 outward cross-border payments a day, and your job is to move those payments from SWIFT MT format to ISO 20022. The bank's payment hub still produces MT103 messages for customer payments, MT202 messages for bank-to-bank transfers, and MT940 messages for account statements, and MT103 and MT202 must be replaced by their ISO 20022 equivalents before the 22 November 2025 deadline that ended coexistence for cross-border FI to FI payment instructions; MT940 reporting migrates on a separate timeline, with MT to camt coexistence ending November 2028. Source: SWIFT CBPR+ end of coexistence 22 Nov 2025; SWIFT reporting migration to Nov 2028. The migration is not optional, and the bank cannot send payments after the deadline if it has not migrated.
The project scope covers outward customer payments first, because they carry the highest volume and the highest regulatory risk. In scope are the conversion of MT103 to pacs.008, the mapping of all fields including the party identification fields, the validation rules for the new format, the exception handling for messages that fail conversion, and the reconciliation reporting that proves every payment was converted correctly. Out of scope for this phase are inward payments, which will migrate in a later release, and the MT940 statement migration, which is handled by a separate team.
Your stakeholders span the whole bank. The project sponsor is the head of transaction banking, who owns the budget and the deadline. The payment operations team of 25 staff will use the new process daily and must be trained. The compliance team must confirm that the new messages carry all the data required for sanctions screening and regulatory reporting. The IT team of eight developers and four testers will build and test the conversion engine. The correspondent banking team manages the nostro agents who receive the new messages, and the SWIFT operations team manages the connectivity to the SWIFT network.
The timeline runs for nine months, from March to November 2025, so the bank is ready before the 22 November 2025 deadline. March and April are for analysis and mapping, May and June for build, July and August for testing, September for user acceptance testing, October for dress rehearsals and training, and November for go-live. There are two hard milestones. The mapping document must be signed off by the end of April, and user acceptance testing must be complete by the end of September. Missing the April milestone pushes the build, and missing September leaves no time for rehearsal before the deadline.
Your deliverables are the artefacts this capstone will teach you to produce. You will write the Business Requirements Document, the field-by-field mapping document, the user stories with acceptance criteria, the test cases for user acceptance testing, the training material for the operations team, and the go-live checklist. Each deliverable has a reviewer and a sign-off date, and each one builds on the previous one, so a mistake in the mapping document flows into the user stories, the tests and the training. Getting the mapping right is the single most important thing you will do.
The risks are real and you must plan for them. The biggest risk is that a field in the MT103 has no direct equivalent in pacs.008, which means the team must agree a translation rule or accept data loss, and either choice needs compliance approval. Another risk is that a nostro agent bank is not ready to receive pacs.008, which would force the bank to keep sending MT103 to that corridor. A third risk is volume. The conversion engine must handle the morning peak of 3,000 payments an hour without slowing down. Your job as BA is to surface these risks early, document them, and drive the decisions that resolve them.
Take one payment through the migration to make it concrete. A corporate customer sends an MT103 for USD 25,000 to a supplier in Singapore, with field 50K for the ordering customer, field 59 for the beneficiary, field 70 for remittance information, and field 71A for the charges. In pacs.008, the same payment has a group header, a payment information block, and a credit transfer transaction block, with the debtor, the creditor, the instructed amount, and the remittance information as structured fields. The mapping document must show each MT103 field, its pacs.008 equivalent, and the rule for fields that have no direct equivalent, such as field 72, which becomes structured remittance information or is dropped with approval. That mapping is the single most important deliverable in the project.
The nostro readiness risk is the one that catches migrations by surprise. Suppose the bank is ready to send pacs.008 on 1 November 2025, but its nostro agent in Japan is not ready to receive it until January 2026. The bank must either keep sending MT103 to that corridor, which is not possible after the cutover for in scope messages, or route the payment through a different correspondent that is ready, which changes the charges and the value date. The BA must therefore track the readiness of every nostro agent, corridor by corridor, and must define the fallback for each corridor that is not ready. A migration that is ready internally but not ready with its counterparties is not ready at all.
The capstone teaches the BA's core skill: turning a regulatory deadline into a project that can actually be delivered. The BA must write the business requirements document, the field by field mapping, user stories with acceptance criteria, test cases for user acceptance testing, training material, and the go-live checklist, and each one must be consistent with the others. The BA must also manage the stakeholders: the sponsor who owns the budget, operations who will use the new process, compliance who must approve the mapping, IT who will build it, and the correspondent banks who must receive it. The capstone is a rehearsal for the real work, and the standard is the same: a mapping that is wrong will break payments, and a migration that misses its deadline will stop them.
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.