The delivery challenge
The migration covered both payment initiation and bank reporting. The technical target included ISO 20022 payment and cash-management messages, but each bank followed its own readiness path, test process, activation sequence and implementation detail.
If each bank had been managed independently, the programme would have had no reliable way to compare risk, prioritise effort or understand what proportion of business activity was genuinely protected by the migration plan. The challenge was therefore to create portfolio-level control without losing the bank-specific detail required for execution.
What had to change
The key change was to stop measuring progress only by how many banks were "in progress". A smaller number of high-impact banks could matter more than several low-volume completions. Readiness needed to reflect business criticality, migration timing, dependency risk and the availability of a realistic fallback.
The approach
1. Build one bank readiness matrix
Every bank moved through a common set of control points: specification confirmed, connectivity understood, test path available, sample exchange complete, defects owned, business validation complete, production approval received and cutover scheduled.
2. Separate message readiness from bank readiness
A valid pain.001 or camt message did not automatically mean the bank was ready for production. The programme treated schema validation, bank acceptance, business processing and operational cutover as separate stages.
3. Use pilots to prove the operating model
Representative migrations were used to prove more than file acceptance. The pilot needed to validate generation or ingestion, transport, bank processing, TMS/ERP behaviour, reconciliation, defect handling and production support.
4. Prioritise the landscape by impact
The bank plan was viewed through both readiness and business importance. This helped focus attention on migrations where a delay could create disproportionate operational exposure.
5. Create fallback before the deadline
For banks where readiness was uncertain, contingency was treated as a formal workstream rather than a late escalation. Alternative routes, temporary continuation options or replacement paths were assessed early enough to be actionable.
6. Move to delivery-window reporting
Senior reporting shifted toward practical delivery windows: already live, next-wave go-live, later-wave go-live and unresolved. This made the portfolio easier to understand than broad status labels that did not show when a migration would actually land.
What the delivery model achieved
Comparable bank readiness
A common control model made it easier to distinguish genuine readiness from activity.
Risk weighted by business impact
Attention could be directed to the migrations that mattered most operationally.
Contingency became deliberate
Fallback options were considered before they became emergency decisions.
Phased delivery became clearer
Leadership could see which migrations were live, imminent, later or unresolved.
What was learned
ISO 20022 programmes can appear technical because the visible artefacts are XML messages, schemas and bank specifications. In practice, the most difficult part is often coordination: different banks, different timelines, system dependencies, business validation and the need to protect payment continuity while the migration is still moving.
What we would carry into a similar engagement
- Track every bank against the same readiness gates.
- Measure business coverage, not only bank count.
- Prove end-to-end processing in the pilot, not just message validity.
- Establish fallback early for uncertain or critical banks.
- Report by delivery window so leadership can see the real migration path.