Does Performance Testing Keeps You Within FCA/PRA Impact Tolerances?

Quick Summary :

• 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 was fined £48.65 million after regulators found that the primary causes were issues related to IT configuration, capacity, and coding. Additionally, there were shortcomings in testing and risk management prior to the system going live. This incident serves as an early warning of the consequences of weak operational discipline.
• A performance testing strategy built around impact tolerances, mapped dependencies, and independently evidenced scenario testing is a key input to meeting these rules, not just an engineering good practice.

What UK Bank IT Failures Cost

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. 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 an estimated £330 million in wider costs disclosed by the bank in the aftermath (LBC). Regulators found that the direct causes of the technical problems were issues with IT configuration, capacity, and coding, compounded by failings in planning, testing, risk management, and outsourcing in the run-up to go-live (PRA final notice). 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 is a key part 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.

What’s changing next: the PRA’s PS7/26 and the FCA’s PS26/2 add a new layer on top of this framework, a unified operational incident reporting regime, together with rules on material third-party reporting, taking effect on 18 March 2027. From that date, firms will need to notify regulators of serious operational incidents through a single reporting channel and maintain an annual register of material third-party arrangements, on top of the mapping, testing, and impact tolerance obligations already in force.

Where Performance Testing Fits

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, and performance testing is what proves the technology side of that case, even though people, process, and communications are part of the wider resilience picture too.

• 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, the FCA’s insights and observations note that firms remain inconsistent at identifying important business services in the first place, with some relying on a single criterion, such as excluding a service because a competitor could substitute for it, 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, on the same page, the FCA states that it expects remediation plans for vulnerabilities identified during testing to be approved, fully funded, and appropriately governed to ensure delivery, with evidence at closure through repeated scenario tests to verify the vulnerability has actually been resolved, 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. In our view, 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 value beyond an internal team’s own testing. Avekshaa Technologies builds performance testing programmes structured around impact tolerance validation and severe but plausible scenario testing, correlating load testing results with application performance monitoring and observability data so a test result maps directly to root cause and to the specific important business service it affects, drawing on its Independent Testing and Quality Assurance, Site Reliability Engineering, and Cloud Engineering practices, with evidence structured around frameworks relevant to UK financial services such as PCI-DSS and ISO 27001:2022.

Conclusion

Operational resilience rules have 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 many firms are still refining how they scope important business services and verify remediation, so testing strategy and operational resilience compliance are still catching up to each other. If your firm is reviewing how its testing programme maps to impact tolerances and severe but plausible scenarios, book a meeting with Avekshaa’s performance engineering team to talk through your specific important business services and testing scope.

FAQs

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. Can functional testing satisfy operational resilience testing requirements?
   Not on its own. Functional testing confirms a system behaves correctly under normal conditions, not how it holds up under severe disruption. Demonstrating that an important business service stays within impact tolerance under severe but plausible conditions needs performance, load, and failover testing as a key input, alongside testing of people, process, and third-party response. Functional testing doesn’t cover any of that.
3. 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.
4. 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.