Throughout time, multiple Payment processing windows have been closed, with vital consequences, we can all remember an outage either at the groceries, on our digital bank etc.
This is the operating environment banks now design for. Not theoretical worst-cases, but the realistic, cascading, disruptions that regulators are increasingly asking institutions to prove they can absorb.
What is system resilience during outages?
System resilience during outages is a bank's demonstrated ability to continue delivering critical business services , payments, lending, account access , within pre-defined tolerance thresholds when one or more underlying technology systems fail. It combines architectural redundancy, tested recovery procedures, and continuous monitoring to ensure that outages cause acceptable, bounded impact rather than service collapse.
Why the stakes are higher than they used to be
Two regulatory shifts changed the conversation permanently.
In the UK, the FCA and PRA published PS21/3 in March 2021, requiring firms to identify their important business services, set impact tolerances expressed in time and customer harm, and prove through testing that they can remain within those tolerances during severe but plausible disruptions. The compliance deadline passed in March 2022, and supervisory scrutiny has intensified since.
In the EU, the Digital Operational Resilience Act (DORA) applied from January 2025. DORA Article 11 requires financial entities to implement business continuity policies and test them through scenario-based exercises that include ICT disruption scenarios. Article 12 mandates backup policies, restoration procedures, and , critically , documented recovery time objectives for critical functions.
That regulatory context matters when reading what follows. Banks aren't just doing this because it's good practice. They're doing it because supervisors can now demand evidence.
Impact tolerances: The number that drives everything
A common mistake practitioners make is treating recovery time objectives as aspirational targets rather than binding constraints. Under the FCA PS21/3 framework, an impact tolerance is the maximum level of disruption a firm is willing to accept before customer harm or systemic risk becomes unacceptable. It's a ceiling, not a goal.
For a retail bank, the important business services might include:
- Current account payments (consumer and business)
- Mortgage origination and drawdown
- Online and mobile banking access
- Card transaction processing
Each service gets its own tolerance. A bank might set a four-hour tolerance for mobile banking access but a 30-minute tolerance for real-time payment processing. The tolerance reflects actual customer and market impact, not what the IT team thinks they can achieve.
Once set, every architectural decision flows from that threshold. If payments must recover within 30 minutes, the bank needs a recovery architecture that can actually hit that window , tested, not assumed. For more on setting these thresholds, the RTO vs RPO explainer covers the technical mechanics in detail.
The architecture banks cctually use
Resilient banking infrastructure typically combines several overlapping mechanisms.
Geographic redundancy. Core banking systems run across multiple data centres in different physical locations. Active-active configurations allow both sites to process transactions simultaneously; active-passive configurations keep a warm standby ready to take over. Active-active costs more but cuts failover time from minutes to seconds.
Application-level failover. Payment gateways, API layers, and authentication services sit behind load balancers that redistribute traffic automatically when a node fails. Well-designed systems make this invisible to the customer.
Data replication and recovery points. Banks define recovery point objectives (RPOs) , the maximum data loss they can accept , and configure replication frequencies accordingly. For payments, RPOs are often measured in seconds. Overnight batch systems might tolerate a few hours.
Vendor and supply chain redundancy. The Change Healthcare ransomware attack in February 2024 crippled healthcare payments processing across the US because thousands of providers had a single-vendor dependency. Banks learned , or re-learned , that critical functions need more than one supply chain path. This is why dependency mapping, which surfaces single points of failure before they surface in an incident, has become a Board-level conversation.
| Recovery Architecture Model | Failover Time | Cost Relative to Single-Site | Best Suited For |
|---|---|---|---|
| Active-Active (multi-site) | Seconds | High | Payment processing, real-time settlement |
| Active-Passive (warm standby) | 5–30 minutes | Medium | Core banking, CRM, risk systems |
| Cold standby | Hours | Low | Non-time-critical batch, archival systems |
| Cloud burst / hybrid DR | Minutes (variable) | Variable | Peak-load resilience, secondary channels |
Identifying what actually needs to be resilient
Not every system in a bank's estate deserves the same investment in resilience. In most organisations we've seen, there's a meaningful gap between the systems IT teams think are critical and the services the business actually depends on in a crisis.
A formal business impact analysis closes that gap. The BIA identifies which business processes are genuinely time-sensitive, what technology, people, and third parties they depend on, and what harm materialises at different durations of disruption. Without that foundation, resilience investments get misallocated , money goes to redundant infrastructure for systems that can wait 48 hours, while the payment gateway that processes £2 billion a day runs on a single vendor connection.
Mapping dependencies also exposes the cascading failure risk. The DP World Australia port cyberattack in November 2023 disrupted container operations for four days not because DP World's core systems failed, but because interdependencies between their operational technology and IT networks created a situation where recovery of one system required taking down another. Banks face structurally similar risks in their payment, fraud, and authentication layers.
How banks test outage resilience
Documented plans don't prove resilience. Testing does.
Regulatory expectations have moved well past annual tabletop exercises. Under DORA Article 25, financial entities must conduct threat-led penetration testing (TLPT) at least every three years for significant systems. The FCA expects firms to test their ability to remain within impact tolerances, not just their ability to recover eventually.
In practice, effective bank resilience testing includes:
Scenario-based exercises. Rather than generic IT failover drills, banks now run exercises built around realistic threat scenarios , a cloud provider outage affecting a specific service, a ransomware event that encrypts backup repositories, a third-party payment processor going offline. The scenario forces teams to work through actual decision chains, not theoretical ones.
Live failover testing. The only way to know that active-passive failover works in 15 minutes is to actually fail it over. Banks that only test in non-production environments discover gaps when it matters.
Crisis management integration. Technology recovery and crisis communication don't always connect. A bank might restore its payment system within tolerance but fail to notify customers, regulators, or the media appropriately. IT crisis management frameworks bring these threads together.
A recurring finding from post-incident reviews: teams that exercised regularly , including exercises that deliberately injected ambiguity and incomplete information , recovered faster and made fewer compounding errors. The BCI Good Practice Guidelines have tracked this correlation across sectors for years. Organisations that treat BCM exercises as a measure of activity rather than readiness consistently underperform in real events.
The regulatory compliance layer
For practitioners working in scoped financial institutions, the compliance requirements are specific enough to drive programme design.
Under DORA, Article 11.1 requires that business continuity policies address scenarios including severe business disruptions to ICT systems. Article 12 requires documented and tested backup and restoration procedures with defined RTOs. The EBA's regulatory technical standards (published December 2023) set minimum expectations for what those plans must contain.
Under ISO 22301:2019, Clause 8.4 covers business continuity planning and requires that recovery procedures be documented with assigned ownership and tested at planned intervals. Many banks use ISO 22301 as their baseline programme framework and layer DORA and FCA-specific requirements on top.
The FCA and PRA's supervisory statements (SS1/21 and SS2/21) are the most explicit of any major jurisdiction about what evidence they expect , firms should be able to show not just that they have a plan, but that the plan works within the defined tolerance.
From documentation to operational reality
The gap between having plans and having resilience is where most programmes struggle. Plans go stale. Dependencies change when vendors are switched, applications are migrated to cloud, or teams reorganise. A plan written 18 months ago against a different infrastructure map is effectively a liability.
Always-on resilience , continuous monitoring, automated plan currency checks, real-time dependency tracking , is how forward-thinking banks close that gap. The shift from periodic BCM to always-on resilience reflects this operational reality.
For institutions evaluating tooling to support this, the BCM software guide for financial services covers what capabilities actually matter in a regulated banking context.
Sources
- FCA/PRA PS21/3, *Building Operational Resilience*, March 2021
- FCA/PRA SS1/21 and SS2/21, *Operational Resilience Supervisory Statements*, March 2021
- EU Regulation 2022/2554 (DORA), Articles 11, 12, 25, January 2025
- EBA Regulatory Technical Standards under DORA, December 2023
- ISO 22301:2019, *Business Continuity Management Systems*, Clause 8.4
- BCI Good Practice Guidelines 2023 Edition
- CrowdStrike Falcon Channel File 291 incident, July 2024
- Change Healthcare ransomware event, February 2024
- DP World Australia cyberattack, November 2023
Discover how Fortiv's operational resilience solutions help financial services teams prove tolerance compliance and recover faster from outages →
