What FCA/PRA Operational Resilience Rules Mean for Your Application Performance Testing Strategy

• The FCA and PRA’s operational resilience rules (PS21/3 and SS1/21) required in-scope firms to be able to operate their important business services within impact tolerances by 31 March 2025, and that obligation is now ongoing, not a one-time deadline.
• Firms must test against “severe but plausible” disruption scenarios, which in practice means performance, load, failover, and third-party dependency testing, not just functional testing.
• The FCA’s own one-year-on review found that firms are still inconsistent at identifying important business services and that remediation plans need to be better funded, governed, and continuously tested.
• TSB’s £48.65 million fine and the Treasury Committee’s finding of over 803 hours of banking IT downtime in two years both show what happens when performance testing doesn’t map cleanly to regulatory expectations.
• A performance testing strategy built around impact tolerances, mapped dependencies, and independently evidenced scenario testing is now a compliance requirement as much as an engineering good practice.

Introduction

For years, application performance testing in UK financial services sat mostly in the engineering column: a pre-release checkbox to confirm a system could handle expected load. The FCA and PRA’s operational resilience regime changed that. Since the transition period ended on 31 March 2025, in-scope firms are expected to demonstrate, with evidence, that they can keep their important business services running within defined impact tolerances even under severe but plausible disruption. That is no longer a purely technical statement. It is a regulatory one, and it has direct, specific implications for how a firm scopes, schedules, and evidences its performance testing programme.

This matters because the cost of getting it wrong is well documented in the UK market. TSB’s 2018 migration failure resulted in a combined £48.65 million fine from the FCA and PRA, on top of £330 million in wider costs, after regulators found that “critical testing plans and principles had to be deviated from” under schedule pressure. More recently, Treasury Committee data showed nine of the UK’s largest banks and building societies logged at least 158 IT failure incidents and over 803 hours of downtime between January 2023 and February 2025, with Barclays alone expecting to pay up to £12.5 million in customer compensation. Operational resilience rules exist precisely to reduce the frequency and severity of incidents like these, and performance testing sits at the centre of whether a firm can actually meet them.

A Quick Recap of the FCA/PRA Operational Resilience Framework

The rules are set out primarily in the FCA’s Policy Statement PS21/3, “Building operational resilience,” alongside the PRA’s Supervisory Statement SS1/21 for PRA-authorised firms such as banks, building societies, and insurers. The rules came into force on 31 March 2022, with a three-year transition period ending 31 March 2025.

By 31 March 2025, in-scope firms were expected to have completed mapping and testing so they could remain within impact tolerance for every important business service, and to have made the investments needed to sustain that. The obligation did not end there. The FCA’s own guidance describes operational resilience as a “dynamic activity” after that date, meaning testing, remediation, and evidence gathering are expected to continue on an ongoing basis, not as a single project that concludes.

Why This Is a Performance Testing Problem, Not Just a Compliance Problem

It’s tempting to treat operational resilience as a governance and documentation exercise led by risk and compliance teams. In practice, the rules translate directly into engineering requirements that only a performance testing programme can satisfy.

• Impact tolerances are quantitative. A tolerance defined as, for example, a maximum of two hours of disruption to a payments service cannot be validated through a design review. It has to be tested under conditions that approximate real severe disruption, which means load testing, failover testing, and chaos-style fault injection against realistic transaction volumes.
• Mapping requires knowing your actual dependency graph. In a microservices architecture, an important business service is rarely delivered by one system. It runs across APIs, message queues, third-party integrations, and shared infrastructure. Performance testing is one of the few disciplines that actually exercises that full chain under load rather than assuming it holds.
• Third-party testing needs scrutiny, not just trust. The FCA has been explicit that firms remain responsible for the resilience of outsourced and third-party components, even when the third party performs its own testing. That means a firm’s performance testing strategy needs to either test third-party dependencies directly or critically assess the third party’s own test methodology and evidence.
• Severe but plausible is a testing standard, not a compliance phrase. It implies scenarios beyond typical peak load: simultaneous failure of a primary data centre and a key third-party API, a cyber incident combined with a traffic surge, or a botched deployment during a high-volume period, closely mirroring what actually happened during TSB’s 2018 migration and several of the incidents catalogued by the Treasury Committee in 2023 to 2025.

Where UK Firms Are Still Falling Short

The FCA’s own observations, published as firms approached and then passed the 31 March 2025 deadline, are a useful diagnostic for any firm reviewing its own programme. Two findings stand out for performance testing specifically.

First, firms remain inconsistent at identifying important business services in the first place, with some relying on a single criterion rather than considering the full range of factors the rules require. If an IBS is scoped too narrowly, the systems and APIs that support it never make it into the performance testing plan at all, which means a firm can pass every test it runs and still be exposed.

Second, the FCA found that remediation plans for vulnerabilities identified during testing needed to be better funded, more clearly governed, and subject to ongoing scenario testing to verify they actually worked, rather than treated as complete once documented. A performance test that surfaces a bottleneck is only useful if the fix is retested under the same severe but plausible conditions that found it in the first place.

Both findings point to the same underlying issue: testing that happens once, against too narrow a scope, does not meet what the regulators are actually looking for.

A Practical Performance Testing Checklist Mapped to FCA/PRA Expectations

The Role of Independent Testing in Providing Auditable Evidence

One theme runs through both the rules themselves and the FCA’s observations since the 2025 deadline: evidence quality matters as much as engineering effort. A firm that has done extensive internal performance testing but cannot produce clear, auditable evidence mapped to its impact tolerances is in a weaker position, both operationally and in a regulatory review, than one with a more modest but well-documented, independently validated programme.

This is where an independent performance engineering partner adds distinct value beyond an internal team’s own testing. Avekshaa Technologies works with UK banks, insurers, and payment providers to build performance testing programmes specifically structured around impact tolerance validation and severe but plausible scenario testing, using the P-A-S-S framework (Performance, Availability, Scalability, Security) to correlate load testing results with real application performance monitoring and observability data, so a test result maps directly to root cause and to the specific important business service it affects.

Relevant delivery experience for regulated UK environments includes:

• A 500% scalability increase validated for payment gateway APIs under five times normal transaction volume, directly relevant to impact tolerance testing for payment-related important business services
• Support for 108 million daily transactions on a telecom provider’s API infrastructure with zero downtime, demonstrating sustained testing under real severe load rather than a single point-in-time exercise
• A same-day migration covering 461 bank branches and 851 ATMs with no service disruption, the kind of coordinated, mapped, dependency-aware execution that severe but plausible scenario testing is meant to validate
• Independent testing evidence structured around compliance frameworks relevant to UK financial services, including PCI-DSS and ISO 27001:2022, through Avekshaa’s Independent Testing and Quality Assurance practice

Firms working through operational resilience obligations can also draw on Avekshaa’s Site Reliability Engineering and Cloud Engineering practices to validate auto-scaling and failover behaviour alongside API-level performance results, and on dedicated Digital Quality Assurance for Banks and Insurance Companies offerings built around exactly this kind of regulatory context, delivered through a dedicated UK operation.

Conclusion

Operational resilience rules turned application performance testing from an engineering best practice into a documented regulatory expectation. Firms now need to prove, with evidence tied to specific impact tolerances, that their important business services hold up under severe but plausible disruption, not just assert that they probably would. The FCA’s own findings since the 2025 deadline show that many firms are still refining how they scope important business services and verify remediation, which means performance testing strategy and operational resilience compliance are converging faster than many test plans have caught up with.

If your firm is reviewing how its performance testing programme maps to impact tolerances and severe but plausible scenario requirements, it’s worth validating the current approach against independent, auditable evidence rather than internal sign-off alone. Book a meeting with Avekshaa’s performance engineering team to discuss your specific important business services and testing scope.

FAQs: FCA/PRA Operational Resilience and Performance Testing

1. Do the FCA and PRA operational resilience rules apply to all financial services firms? The rules apply to firms in scope of PS21/3 and SS1/21, which includes banks, building societies, insurers, and other firms subject to enhanced Senior Managers and Certification Regime requirements, as well as entities authorised under the Payment Services Regulations 2017 and Electronic Money Regulations 2011. Firms outside this scope are not formally required to comply, but the FCA has noted that the underlying good practice is relevant more broadly.
2. What is the deadline for operational resilience compliance? The transition period ended on 31 March 2025. By that date, in-scope firms needed to have completed mapping and testing so they could remain within impact tolerance for every important business service. The obligation continues after that date as an ongoing activity, not a completed project.
3. What does “severe but plausible” actually mean in a testing context? It means scenarios more extreme than typical peak load, but still realistic given the firm’s actual risk profile: simultaneous failure of a primary system and a key third party, a cyber incident combined with a traffic surge, or a deployment failure during a high-volume period. It requires combining load testing, failover testing, and dependency-failure simulation rather than testing each in isolation.
4. Can functional testing satisfy operational resilience testing requirements? No. Functional testing confirms a system behaves correctly under normal conditions. Operational resilience testing requires demonstrating that important business services remain within defined impact tolerances under severe disruption, which is fundamentally a performance, load, and failover testing exercise, not a functional one.
5. Are firms still required to test after the 31 March 2025 deadline has passed? Yes. The FCA describes operational resilience as a dynamic, ongoing activity after the transition period. Firms are expected to keep important business services and their mapping under regular review, continue scenario testing, and maintain properly funded and governed remediation plans.
6. How does third-party outsourcing affect performance testing obligations? Firms remain responsible for the operational resilience of their important business services even when parts are delivered by third parties. If a third party performs its own testing, the firm still needs to be satisfied that the methodology and scenarios tested are appropriate and sufficient for its own requirements, which in practice often means requesting evidence or commissioning independent validation.
7. What evidence do regulators expect to see from a firm’s performance testing programme? Evidence should map clearly to each important business service and its specific impact tolerance, cover severe but plausible scenarios rather than only steady-state load, and demonstrate that identified vulnerabilities were remediated and then retested. Independently produced or independently reviewed evidence generally carries more weight in a regulatory review than internal self-assessment alone.
8. What’s a realistic first step for a firm that suspects its performance testing doesn’t fully map to its impact tolerances? Start with the mapping exercise itself: confirm every important business service has a complete, current map of the systems, APIs, and third parties that deliver it, then check whether existing performance test scenarios actually exercise that full chain under the specific duration and volume thresholds defined in the impact tolerance. Gaps found at that stage are usually the same gaps a regulator would find.