Payments modernisation programmes rarely start because an institution wakes up one morning wanting to modernise. They start because a regulator or a scheme has set a deadline, a messaging standard is being retired, or a settlement mechanism is changing underneath everyone at once. That external forcing function is useful for getting budget approved and stakeholders aligned, but it also shapes the programme in ways that are not always healthy.
The most common distortion is that the deadline becomes the primary design constraint, and resilience, testing depth and fallback planning become the things squeezed when the schedule tightens. This is precisely backwards for payments, where the cost of an outage or a data quality failure during migration is measured in real money moving incorrectly, not in a support ticket.
The deadline is real, the corner-cutting doesn't have to be
It is worth separating two things that get conflated under deadline pressure: the date by which the new capability must be live, and the amount of testing, dual running and rollback capability the programme is willing to fund. Institutions that protect the second even when the first is fixed tend to come through these migrations with far fewer incidents.
In practice this means resourcing resilience work as a first-class stream from day one, with its own budget line and its own milestones, rather than treating it as a activity that happens 'if there's time' once the functional build is done. Programmes that leave resilience to the end usually find there is never time.
The regulatory deadline sets when you must go live. It does not have to set how much resilience you are willing to fund to get there safely.
ISO 20022 and the migration trap
Message standard migrations such as ISO 20022 look, from a distance, like a data mapping exercise: translate fields from the old format to the new one and move on. In practice the richer data model exposes years of inconsistency in how fields were populated under the old standard, and that inconsistency has to be resolved, not just mapped, or it propagates into the new environment with a cleaner-looking wrapper around the same problem.
This is where programmes underestimate effort most consistently. Data quality remediation is unglamorous, hard to estimate precisely, and easy to defer, which makes it exactly the kind of work that gets cut when a deadline is fixed and something has to give.
- 路Treat data quality remediation as core migration scope with its own timeline, not a side task
- 路Run dual processing in parallel for long enough to catch discrepancies under real transaction volumes, not just test volumes
- 路Define rollback criteria and mechanisms before go-live, in writing, agreed by the people who would have to execute them
- 路Rehearse failure scenarios deliberately rather than assuming the plan will hold because it looks complete on paper
Dual running is a discipline, not a phase on a slide
Most payments migrations include a dual running period on the plan. Fewer treat it as seriously as it deserves in practice, because dual running is expensive, operationally demanding, and creates pressure to cut it short once the new system appears to be working. That appearance is exactly the risk: a system can look stable under partial load and reveal problems only once volume, concurrency or edge-case transaction types increase.
The institutions that get the most value from dual running are the ones that define, in advance, precise criteria for what 'working' means, including reconciliation accuracy, latency under peak load and the behaviour of exception handling, and hold themselves to those criteria even when commercial or regulatory pressure argues for cutting the period short.
Resilience as a design principle, not a contingency budget line
The strongest payments modernisation programmes we see treat resilience as something designed into the architecture from the outset: graceful degradation when a downstream dependency fails, clear ownership of incident response across the old and new environments during transition, and monitoring that is built for the migration period specifically rather than reused unchanged from steady-state operations.
This is a different posture from treating resilience as an insurance policy purchased at the end of the programme. It costs more upfront in planning discipline. It costs far less in the incident that does not happen during the highest-risk weeks of a migration, when both the old and new systems are live and every failure mode is doubled.
Regulatory deadlines are a legitimate and useful forcing function, but they are frequently allowed to make decisions that should be made on risk grounds instead. The question worth asking early in a payments modernisation programme is not only 'can we be ready by the date', but 'what is the minimum resilience posture we are prepared to accept during the migration weeks, regardless of the date'.
Programmes that answer that question honestly and protect the answer under schedule pressure tend to have quieter go-lives. That quietness is the actual return on the investment, even if it never appears as a line item anyone can point to afterwards.