Out-Law Analysis 3 min. read

How tech providers can support financial services firms on operational resilience

Financial services providers are taking take steps to ensure that their client-facing services are operationally resilient in response to recent regulatory developments. The aim is to prepare thoroughly for disruption and prevent, as far as possible, any customer from experiencing an “intolerable” level of financial, reputational or other form of harm.

Dependency on third parties has been identified as an important focus area for establishing and maintaining high levels of operational resilience. Third party providers therefore should be aware of what may be asked of them to effectively support the operational resilience of their financial services sector customers.


In the UK, both the Prudential Regulation Authority (PRA) and the Financial Conduct Authority (FCA) require regulated businesses to identify all of their important business services and map “the people, processes, technology, facilities and information necessary” to deliver those services. The regulators expect third party arrangements to be considered as part of this mapping.

While the first round of mapping has largely been completed, the regulators expect the level of detail to become more sophisticated over time. Mappings undertaken will need to be reviewed at least annually and following material changes to the business or the market.

More sophisticated mappings may lead to closer scrutiny of the people, processes and technology that underpin third party service arrangements. This may in turn result in more detailed requests for information as part of due diligence, governance, audit or through more general contractual commitments to share information.

In principle, technology providers will be effective in supporting their customers’ operational resilience mapping objectives if the level of detail they provide about their services meets the following criteria – it should:

  • be sufficient to identify the people, technology, processes and other resources that would be critical to the continued delivery of the customer’s client-facing service in the event of severe disruption;
  • provide sufficient insight into potential vulnerabilities to that service which may arise in the event of severe disruption.

Technology providers will need to assess how to meet these disclosure expectations without compromising commercial sensitivities or data and systems security. As the regulators have largely left it to the regulated entities to determine the level of granularity required for the mapping of each service, the approach one customer may take to meeting its mapping requirements may differ from that of another. Technology providers will also be mindful of protecting the confidentiality of other customers’ information, particularly in the context of shared service environments.

There is an opportunity for technology providers to get ahead of the curve and propose levels of disclosure that appropriately meet the regulatory resilience objectives.  

Impact tolerances

At the centre of the UK’s operational resilience framework is the requirement for regulated entities to, by March 2025, ensure that their important business services stay within defined impact tolerances. Maximum tolerable levels of disruption (MLTDs) are to be set for each important business service. These may take into account recovery time objectives, recovery point objectives, work recovery times and other key metrics that measure the ability of the service to remain fully available.

Increasingly, regulated entities are assessing service level commitments, other performance indicators and associated reporting and corrective action commitments from an operational resilience perspective to meet these regulatory expectations. Gaining an understanding of common approaches taken in setting MLTDs will help technology suppliers design and implement services that support customers in evidencing that their third party dependencies do not compromise their operational resilience.

Scenario testing

Regulators expect regulated entities to involve their third party suppliers in operational resilience testing activities. These tests focus on “severe but plausible disruption” and may require a level of participation that is different from other security or business continuity testing scenarios that some technology suppliers may be more accustomed to.

A core purpose of the tests will be to validate or invalidate the MLTD set by the customer. If a test demonstrates that a MLTD is not valid, this could have a knock-on effect on agreed service levels or other contractual arrangements, as the customer may look to amend the contract to bring the service within a revised MTLD.

Technology suppliers that have considered the potential consequences of a scenario test invalidating a service’s MLTD will be better placed to propose appropriate contractual terms which govern their participation in tests and the actions required to address the outcome of the tests. To date, the focus of many suppliers in this area has been around the effort and cost involved in participating in testing. While this is a valid concern to address, it is also important for suppliers to understand the broader regulatory challenge around responding to test outcomes. Doing so may improve the opportunity for both parties to plan at the pre-contractual stage for the operational, cost and other implications that changes to MLTDs may require.

Consequences of getting it right or wrong

Suppliers that engage with the operational reliance requirements of their customers will be better placed to provide effective services to regulated financial services providers in future. Those that do not risk losing market share.

Rewiring financial services
Digital transformation is accelerating in the financial services sector, particularly in the wake of the global pandemic. We investigate the legal and regulatory landscape in financial services technology and highlight the opportunities for change.
Rewiring financial services
We are processing your request. \n Thank you for your patience. An error occurred. This could be due to inactivity on the page - please try again.