What banks must do, readiness and testing

Banks that migrate to ISO 20022 must undertake a programme of work that covers technology, operations, compliance, and customer readiness. On the technology side, payment engines must be upgraded to parse and generate XML, to validate against the CBPR Plus usage guideline, and to handle both MT and MX during coexistence. Screening systems must be upgraded to screen structured data, reconciliation systems must be upgraded to match on new references, and reporting systems must be upgraded to produce camt statements. Each of those upgrades requires design, build, and testing, and the testing must cover not just the happy path, but also translation, truncation, and error handling. On the operations side, staff must be trained to read pacs messages, to understand the new error codes, and to handle exceptions in the new format. Repair queues will look different, investigations will require new skills, and customer queries will change, because customers will ask about new fields and new references. On the compliance side, sanctions screening, anti money laundering, and fraud rules must be updated for the new data model, and the bank must be able to demonstrate to regulators that its controls work in both formats. On the customer side, corporates must be told what data they need to provide, what will change in their files, and what the timeline is for their own migration. Readiness is therefore not a single milestone, but a programme with multiple workstreams and multiple dependencies. An analyst working on a migration programme must be able to track readiness across technology, operations, compliance, and customers, and must be able to identify the critical path. A bank that is technically ready but has not trained its operations team is not ready. A bank that has trained its team but has not updated its screening is not ready. Your readiness checklist should cover each workstream, with clear criteria for what ready means, and with a plan for what happens if a workstream is not ready on the cutover date. Take a simple example. A bank plans to migrate 200 payment flows to ISO 20022. Its readiness checklist shows the payment engine is ready, but the operations team has not yet been trained on the new error codes, and the screening system still screens free text names instead of structured party data. The programme is not ready, even though the technology is, because the first pacs zero zero eight that fails validation will sit in a repair queue that nobody knows how to clear, and the first sanctions alert on a structured address will be worked by hand. The checklist must therefore show every workstream as ready before the cutover date is confirmed. Testing a migration is a programme in itself, and it runs in phases. Unit tests check each mapping rule on its own. System integration tests check the full flow, from customer instruction to status report, through the payment engine, the screening system, and the reconciliation system. Industry testing with SWIFT checks that the bank can exchange messages with counterparties. Dress rehearsals run the cutover itself, with real volumes and real timings, so the team knows what will happen on the day. Each phase needs test data that reflects real life, including long fields, special characters, and the edge cases that break mapping rules. The programme timeline has clear milestones. Gap analysis shows what is missing. Build delivers the new message handling. Internal testing proves the build works. Counterparty testing proves the bank can exchange messages with the banks it actually pays. Readiness declaration states that technology, operations, compliance, and customers are all ready. Cutover moves live traffic to the new format. The coexistence period was used to test with live traffic in both formats, which gave banks real evidence before the end of coexistence on 22 November 2025. At each gate, the business analyst verifies specific evidence. The mapping document is signed off by operations and compliance. Test evidence exists for every flow, including the flows that should fail validation. The operations team has been trained on the new error codes and can work a repair queue in the new format. The screening system has been updated for structured data. Customer communications have been sent, telling corporates what data to provide and what will change. And there is a rollback plan, stating what happens if the cutover fails and how quickly traffic can move back.