Wayne Scott, Regulatory Compliance Lead, NCC Group

Below is an insight into what can be expected from Wayne’s session at Vendor & Third Party Risk Europe 2023.

The views and opinions expressed in this article are those of the thought leader as an individual, and are not attributed to CeFPro or any particular organization.

Can you share some insight into the regulatory approach of operational resilience, and how this impacts supply chains?

Regulators receive a lot of criticism for any new regulation introduced, but the global shift in recognizing operational resilience from a regulatory perspective is long overdue. The Monetary Authority of Singapore (MAS) and the United Kingdom Prudential Regulation Authority (PRA) lead the way with their recent regulatory changes. Understandably, they firmly focus on Cyber Security throughout every set of new regulation, however, both MAS and the PRA were the first to name supplier failure, service deterioration and concentration risk as named risks.

These risks are non-cyber security related risks presented by the use of software and the cloud. One by one the other global financial services regulators have followed their lead; Canada, Hong Kong, and Switzerland have released revised regulations. The regulatory framework for DORA in the EU is expected very soon, with the US and Australia expected to announce their new regulations by Q3 2023 at the latest.

Although the regulatory style differs from country to country, some being more prescriptive than others, some choosing to announce accompanying legislative changes too, there’s a clear pattern emerging globally:

1. Naming of supplier failure, service deterioration and concentration risk
2. Assigning ownership of the newly named risks at the most senior level (in the UK that would be SMF24)
3. Mapping of the entire infrastructure, subsequent classification of material suppliers and material services to be submitted to the regulator.
4. Setting risk appetites and risk tolerances with a firm commitment to stay within both.
5. Requirement to build “stressed exit”, “contingency” or “separation” plans. To test those plans, for the plans to be demonstrably successful and to be submitted to the regulator.
6. Classification of critical third parties by the regulator with some regulators choosing to directly regulate those parties going forward.
7. Firm focus on proportionality, fourth parties, intragroup outsourcing and anything in the cloud is in scope.

These stressed exit plans must enable the regulated entity to pull the management of a failed service or supplier or pass the management of the service to another third party. Latter stages of a stressed exit plan are essentially the supplier identification and onboarding process already existing within the Financial Institution. Temporary stages, keeping the current service running, is where technology escrow fits in nicely.

Technology escrow is nothing new, NCC have been providing escrow solutions in some form since 1984 but with the introduction of cloud services in the last few years, technology escrow has evolved significantly. An escrow solution follows a three-step process:

1. Establishing a legal right to access business critical information not contained within software or cloud license agreements. Primarily this would be source code for on premise deployments, but for cloud services we would also look to take access credentials or a fresh instance of a multi tenanted service in a spun down dormant state.
2. Knowledge transfer of a gathering of information, an understanding of all the hardware and software involved in building of the service, along with a complete step by step build manual on how to rebuild the service.
3. Scenario testing on whether the regulated entity can repeat the build process, or, to see if a designated third party can replicate the build process.

The deliverables here are documentary proof that should supplier failure, service deterioration or concentration risk present an issue that the Financial Institution has the legal right to continue using the failed service, all the required information to maintain and access the service, and finally has the necessary skillset to manage the service going forward. This buys all the time needed to be able to source, test and implement a replacement service with any disruption being contained to a minimum.

How can we identify important businesses and systems within the supply chain? Can you share any examples of what these could be?

The classification of the criticality of a system should be heavily influenced by several things; the ramifications of its potential failure, the nature of the deployment, financial stability of the supplier, if the system is bespoke, the interchangeability of the system, the overall cost and time taken to complete the implementation, the frequency of upgrades and patches, the cost to replace the system and the total cost if the system becomes unavailable to the financial institution, their customers and the market.

We should never solely focus on the function of the system; function remains highly relevant but there’ll be a long list of non-critical systems that are nevertheless vitally important when all the factors are considered.

It is also worth keeping in mind that the importance of the supplier to the market itself is a determining factor, concentration risk is more and more frequently being named as a risk for consideration by regulators the world over. Once a risk is named by the regulator, mitigation strategies must be developed, tested, and often presented to the regulator for scrutiny.

Furthermore the “materiality” of a service will change over time, criticality isn’t a static definition, Afterall the standard business model for every fintech is to increase their product’s importance over the lifetime of the license agreement and to become “sticky”. In other words, your suppliers intend to become more important to you. Always assume they will, resilience is easier to embed than to retro fit.

Considering all these factors the point of procurement or the pre-outsourcing phase is the ideal place to identify important services and the risk mitigation strategy should start here too. Setting a resilience baseline is key for all suppliers, whether they are defined at the point of procurement as important or not. Assume supplier failure by default. Treat every service as critical from the outset. Ensure contractual provisions are made, should the importance of the supplier change, provisions that will ensure the service remains available even if the supplier ceases to exist.

The contractual provisions only need to be activated should the importance of the service change, but treating the supplier as important from the outset of the relationship will dictate the resilience of the service going forward. Insisting on the supplier’s ability to accommodate technology escrow as part of the pre-outsourcing phase not only meets global regulatory standards but also acts as a valuable preventative control.

The verification portion of a technology escrow solution, or the knowledge transfer process, frequently acts as a detective control. Escrow verification can rapidly identify an issue with IPR ownership, outdated hardware or software used in the build process, whether the necessary skillset to rebuild the service exists within the supplier, the time required to rebuild the service, or if the supplier even has access to the source code and frequently does so.

Verification is certainly a first step of understanding the potential duration of any software supplier failure and gathering enough information to understand if the regulated entity has the necessary skillset and infrastructure to pull the management of the service in house in the event of a supplier failure. All the information gathered in the verification process of an escrow agreement should be fed back into any calculations on a supplier or systems’ importance.

How can we use scenario testing to reflect emerging risks within supply chain resilience?

There’s an assumption that all risks presented by the technology supply chain are technological in nature, so in turn require a technological solution.

No firewall will prevent a software supplier from going into administration, no amount of ethical hacking will prevent a software service level from deteriorating to the extent it can no longer be maintained. No level of full spectrum attack will prevent a director from being embroiled in a “me too” scandal causing the share price to dip leaving them wide open to an aggressive takeover from competition that has a track record of asset stripping, layoffs and forced migrations to their platform of choice.

Additionally, it is increasingly difficult to monitor, report on and ultimately mitigate these scenarios. An escrow solution cannot affect the frequency of these operational resilience risks, but the potential outcome of each scenario remains the same: failure.

Ensure supplier failure, service deterioration and concentration risk are added to any existing scenario tests. Supplier failure increasingly is the outcome of a severe cyber security breach of the supply chain, service deterioration can be an indication of impending supplier failure, and both can add together and lead to takeover of the ownership of the supplier or to transfer of the ownership of the IPR to the service.

Scenario testing is a perfect mechanism for testing the risk the regulated entities’ own IT capabilities present to the FI in a stressed exit scenario. Does your infrastructure support the rebuild of the service? Do you have the necessary hardware or software? Will the 4^th parties involved in the build process sell you 1 license for their software? Will they even pick up the phone? Can your IT team rebuild and maintain the service should they be expected to do so? Will the supplier permit a scenario test?

All these questions, and many more, need to be asked and the answers feed back into the classification of whether a service is important.