Resilient Stress Testing Platforms: Top 4 Considerations

“Bank of England May Toughen Stress Tests as Economy Rallies,” claimed the Bloomberg Business headline on 28 July. Deputy Governor Jon Cunliffe explained in a speech that the Bank of England’s approach would be to use stress testing more countercyclically: “Rather than testing every year against a scenario of constant severity, the severity of the test, and the resilience banks need to pass it, would be greater in boom times when credit and risk is building up in the financial system…”.

This is just one example of why the long-established approach to stress testing using primarily Value at Risk (VaR) methodology is quickly drawing to a close. Not only will more complex methodologies be required to answer regulatory reporting requirements, these processes can also help businesses obtain a better handle on risk management by ascertaining any number of systemic shocks, such as commodities turbulence or currency rate declines. Banks now recognise that spreadsheets alone cannot help manage either regulatory requirements or shareholder scrutiny, so new systems must be implemented. This article reviews the considerations that banks should keep in mind when upgrading to resilient stress testing technology covering: silo issues, reconciliation of parallel risk management infrastructure, ability to handle future stress tests, and related computational power.

VaR-iety required

What is clear is that VaR, the commonly used stress test pre-2008, did little to prevent the financial crisis from happening. Over the past 5-6 years the regulators, including the Basel committees, the Fed, the PRA and EBA, have focused on the ability to measure and analyse extreme events, otherwise known as ‘tail risks’. Specifically, regulations are moving away from VaR towards Conditional VaR (CVaR) or Expected Shortfall (ES) which try to incorporate more of the tail risk rather than just one particular scenario.

Whilst VaR forms the cornerstone of internal models used by banks to measure capital requirements for market risk, one of its shortcomings is the typical inaccuracy when dealing with illiquid securities. It is also worth noting that due to technical shortcomings of most implementations, VaR reports tend to be static and difficult to aggregate and analyse. It takes online analytical capabilities to be able to analyse VaR dynamically and be truly useful to the end user. With the granularity and transparency required by regulators and investors, simply reporting a high-level number no longer cuts it.

What we see going forward is that VaR will end up being just one of the many tools needed for risk management. While its use for regulatory capital may decline in favour of ES calculations as part of the Fundamental Review of the Trading Book (FRTB), it is seeing new interest in margin calculations where measurement has been less stressful. The ability to perform better extreme case analysis also allows firms to better understand these events and hence prepare for related eventualities. More importantly, they make sure they operate within the stated risk appetite of a firm.

Risk management teams need the capacity to incrementally add to their arsenal of risk calculations; the ability to adapt to new requirements, market conditions and regulatory pressure is key.

Considerations for implementation of a capable stress testing system

When updating risk management systems, firms should consider the following:

1. Handling siloed environments and their differing capabilities: Most firms are finding themselves confronted with the problem of diverse siloed environments. These silos tend to have completely different technology stacks, posing a logistical challenge because of the difficulty in implementing the risk requirements in each of these disparate systems.One approach would be to migrate the varying silos, and their related technologies, into one overall system that can handle everything – the “one size fits all” approach. These monolithic systems can, however, be quite costly and time-consuming to implement. There is also the worry that they may not work as well as expected upon completion or the end result might not be adaptable to future requirements.Another approach is to integrate, rather than migrate, these existing silos and have them communicate efficiently with each other via a decoupled, yet centralised, environment. By providing the ability for the systems to talk to each other, firms can make the most of their existing expertise and implement risk management requirements alongside the existing front office systems.
2. Reconciliation of parallel risk infrastructure: Another result of legacy silo stacks is the development over time of a parallel risk pricing infrastructure. Because front-office portfolio systems were not generally designed to answer risk questions, a separate set of evaluation environments were then built for risk management purposes. Problems were created, however, when trying to reconcile these multiple environments due to differing underlying assumptions (for example, the reaction of interest rates to a certain scenario), or the fact that the systems were potentially managed by different teams with different underlying data. Because of these inevitable variations between portfolio and risk management systems, regulators and auditors alike are keen to see firms adopt technologies that can efficiently address these discrepancies.
3. Implementation timescales: We do not expect the eagerness of regulators introducing new, complex stress tests to abate anytime soon, meaning the timescales for each new requirement that is added to a firm’s workload will only get longer and longer. One prevalent mistake we have observed is that firms tend to solve one stress test at a time, with little to no re-use of work done for other stress testing. The end result being that their siloed technology stacks and siloed risk management teams have a logistical nightmare when trying to conduct firmwide tests.Whilst it is an option to simply answer new questions on an individual basis, implementation of new stress tests can be achieved much faster when systems are consolidated, with the ability to use shared reference data and communicate with each other. A federated computation environment helps achieve this. A scalable stress testing environment, both in terms of performance as well as reusability, is what firms should be striving to implement.
4. Scalability: It is estimated that with the passing from VaR to Stress Expected Shortfall under the FRTB, approximately 50-100 times more calculation power will be needed – a significant growth in a firm’s computational environment. The issue of scale becomes an important consideration, especially as with each and every regulation there is an expected increase in the level of granularity and amount of data that needs to be analysed and reported. With that comes the related increase in computation and architectural capability.

Integration vs. Migration

Strengthening risk management practices across the industry has been declared a key objective of the Bank of England’s stress-testing framework. For firms to respond to the level of detail required by regulation, as well as the expected frequency of reporting, an upgrade of technology is inevitably required. Yet regulatory compliance is just one of the reasons. We see firms striving for the ability to stress test individual portfolios, business lines or holistically across the board, because investors and shareholders are also demanding that same level of detailed understanding. After all, an enterprise-wide view of risk exposure is key for any future risk decision or overall business decision.

When considering the upgrade of a risk management system, one option could be a complete overhaul towards a monolithic system, whilst another far less costly option is to implement an integrated platform. Having a centralised and integrated risk management environment should not require upheaval of existing front office systems. By using an integration platform that allows existing silos of technology to not only communicate with each other, but also enable use of a consistent set of data when dealing with numerous differing stress tests, the output can then be handled in an incremental fashion. An approach based on integration and centralisation, rather than monolithic migration, can give your firm the best of both worlds – and answers the call of regulators, auditors, investors and shareholders alike.