What disaster recovery planning gets wrong
Most banks have disaster recovery plans for their core banking systems. Many of those plans have not been tested in conditions that reflect a real failure. The gaps between the documented plan and the recoverable reality tend to be discovered at the worst possible moment.
DR planning for core banking is complex because the system does not operate in isolation. It has dependencies on network infrastructure, adjacent applications, data replication, and operational processes that must all be reflected in the plan. Where any of these are omitted or assumed, the plan fails in practice.
The RTO/RPO gap: what is specified vs what is achievable
Recovery Time Objective (RTO) and Recovery Point Objective (RPO) are the standard measures of DR capability. Banks specify them in contracts with vendors and infrastructure providers, and regulators ask for them during supervisory reviews. The problem is that the specified values are often aspirational rather than tested.
An RTO of four hours sounds specific. In practice, it means that the infrastructure can be restarted within four hours under optimal conditions. It does not mean that the bank can be fully operational — with staff available, processes running, and all channels active — within that window. The gap between infrastructure recovery and operational recovery is frequently underestimated.
Testing as a compliance exercise, not a real test
Many banks conduct annual DR tests that are designed to demonstrate compliance rather than to stress the plan. A planned failover on a Sunday morning, with all relevant staff pre-briefed and systems in a known state, is a useful exercise. It is not a substitute for a test that simulates an unplanned outage on a weekday morning at peak transaction volume.
The tests that reveal genuine gaps are the ones that are unpredictable in timing and scope. These are uncomfortable to run and require senior sponsorship. They are also the tests that give the bank confidence in its actual recovery capability.
Dependencies that are not in the DR plan
Core banking systems have documented dependencies — databases, application servers, network connections. They also have undocumented dependencies: manual processes that staff perform during end-of-day processing, Excel files that feed regulatory reports, telephone escalation chains that exist in individuals' heads rather than documented procedures.
When a recovery exercise proceeds according to the technical plan but the bank still cannot operate, the cause is typically one of these undocumented dependencies. Capturing them requires process mapping work that most DR projects do not budget for.
Human process failures under crisis conditions
Technical recovery is often the simpler part of a DR scenario. The harder part is coordinating people across teams, time zones, and organisations under pressure, with incomplete information and time constraints.
DR plans that specify technology recovery steps but do not address the human coordination process — who has authority to declare a disaster, who communicates with customers, who liaises with the regulator — create a gap that fills with improvisation during an actual event. Improvisation under pressure produces unpredictable results.
Building DR that actually works
Effective DR planning for core banking starts with an honest assessment of what recovery actually requires: not just which servers restart, but which processes must run, in which order, with which staff, before the bank can serve customers. This assessment typically reveals a longer list than the existing plan reflects.
It continues with a testing programme that gets progressively closer to real conditions — more realistic failure scenarios, less notice, and more honest measurement of actual recovery time. And it is maintained as a living programme, not a periodic project, because the system and its dependencies change continuously.