Blog article
See all stories »

Don’t Risk It: Demand More from your Risk Technology


Six key tenants for risk technology platforms, to ensure they can handle risk calculations, aggregation and reporting requirements in ever more complex and fragmented market structures.

Given events in the financial sector in the past decade, it’s safe to say all eyes are on risk. In the context of lessons learned from the financial crisis, the Basel Committee on Banking Supervision in its BCBS 239: Principles for Effective Risk Data Aggregation and Risk Reporting has deemed legacy bank IT and data architectures "inadequate to support the broad management of financial risks," forcing global banks to invest in more sophisticated risk technology.

With regulatory deadlines looming in January 2016 for large organisations, and eventually smaller financial institutions over time, it is fair to say that for most banks, compliance is not just a box-ticking exercise, sufficient to get through the stress-testing requirements. With the business case for ‘fit for purpose’ risk technology in place there is an appreciation of the business insights and competitive advantages – not to mention better use of risk capital - that smart risk technology offers. As recent events have shown, risk stress testing capabilities play a substantial role in banks’ capital distribution plans, and continue to be under regulatory scrutiny.

Increasingly firms are recognising the opportunity to build on existing or adopt new risk management systems that will enable sustainable growth. 89% of respondents to an EY survey this year view BCBS 239 as an 'enabler' for their enterprise-wide risk data management capability - a chance for a risk-tech health-check and overhaul, to shape their IT strategy and develop their IT infrastructure, rather than simply as a regulation to comply with.


Six key questions for the CRO and Risk CTO

The key issue now is how best to ensure your business gets what it needs from its risk technology. Implementation of a sustainable and integrated risk management system is no easy task and risk managers must ask themselves the right questions before they make decisions on what system is right for them and why. It is crucial to view risk technology as more than just data management and aggregation. It starts with collecting and managing internal and external inputs, testing assumptions across the entire business, holistically if you will, to calculate statistical answers, producing even more data, and then getting those answers to the right people at the right time.

It is vital risk managers demand the best from their risk platforms and not simply make do with cumbersome legacy systems, or in fact expensive vendor products, that may not be fit to deal with incoming regulatory requirements or market structures.

The following six questions should help discern if existing risk technology will stand the test of time (and regulation), where it needs upgrading and where the gaps are:

  1. Are existing risk management systems EMPOWERING or restricting managers when performing in depth analysis of firm-wide risk exposures? Do they have instant access to the vast array of underlying data and tools to carry out risk aggregation, stress testing, capital calculations or regulatory reporting?
  2. Is the current system affording enough TRANSPARENCY, allowing Risk Managers to analyse risk exposures and distribute internal reports swiftly to the right recipients?  Data governance and architecture as well as IT infrastructures are key tenants of BCBS 239, designed to improve transparency across risk calculation and aggregation processes. While progress reports for the implementation of these principles see banks falling short, the time is now to get risk calculation capabilities right and improve transparency, both for internal but also external audits and regulatory reporting.
  3. Is the system ACCURATE and CONSISTENT, facilitating comprehensive, complete risk analysis? ‘Garbage-in-garbage-out’ can only be avoided if there is a clear, centralised canonical store of reference data and market data, consistently maintained for accuracy. To achieve this you need dedicated ownership to maintain the data, and sophisticated technology to do it automatically with demonstrable reconciliation processes.
  4. Is your risk technology RELIABLE in terms of handling the daily variability of data and timely delivery to the necessary teams and individuals in an organisation? This is where Risk Managers need to be particularly demanding of their technology. In every organisation there will be multiple upstream and downstream systems, with multiple moving parts, and inevitably there will be failures that will cause reports to fail or be delayed. A truly reliable platform is not just about each component of risk technology being resistant to failure, but the platform as a whole needs to be built with elasticity in its interaction between components and external systems. Furthermore, Business Continuity and Disaster Recovery handling should be built in, not an afterthought.
  5. Is your risk platform ADAPTABLE? Can it flex to fit the ever-changing landscape of financial markets as well as regulatory pressures? Risk and IT systems need to continuously adapt to the environment around them rather than play catch-up; interfacing with existing systems, plugging into new ones, gathering data on ever changing market conditions and risk appetites. Being ready for new business and regulations should all be part and parcel of any well-designed risk platform.
  6. Finally, given regulatory pressures on financial institutions, can your existing system SCALE your risk computations in line with requirements, if asked to do so tomorrow?  Regulators, investors and executive management are demanding more frequent and timely reporting. The granularity of this analysis is only increasing. What was required on a quarterly basis is becoming monthly; end-of-month reports are becoming weekly if not daily; real-time risk is no longer just a nice to have. With the impending requirements of the Fundamental Review of the Trading Book (FRTB), moving to much more granular expected-shortfall calculations will severely test the scalability of your risk technology.

Any CRO who can answer ‘yes’ to all of these questions, is in good stead to thrive in today’s risk environment and comply with many of the requirements set out in BCBS 239 around risk data aggregation capabilities and risk reporting practices, as well overarching data & IT governance.  If not, these six tenants provide an effective starting point to identify where the gaps are and whether to build on existing capabilities or build a whole new system.

At the same time, avoiding common pitfalls when choosing a risk platform is just as crucial. What any CRO will be looking to minimise is COMPLEXITY, COST and MANUAL LABOUR. With each manual process, for example, comes increased operational risk. As much as possible, the platform should minimise the need for manual intervention. Moreover, automating the mundane, focuses users on the more important analysis of results. Delivering all this, with constraints on cost will be no mean feat, but certainly achievable.


Don’t just make do: demand more from your risk platform

With the WHAT, WHY and WHEN clearly behind us, the focus is on HOW?

The question now is: HOW will the CROs and their technology teams ensure the risk platforms are fit for purpose, deliver on multiple fronts and are in line with regulatory requirements and market expectations?

The answer is: by making sure the right tool kit is in place. Don’t just make do with inherited or legacy technology. Demand more from your risk platform.  After all, there are more than careers and reputations at stake; the stability of the business, financial markets and health of the global economy depends on risk, and the capability to manage it.



Basel Committee on Banking Supervision: Progress in adopting the principles for effective risk data aggregation and risk reporting; January 2015

EY BCBS 239 risk data aggregation and reporting February 2015,$FILE/EY-bcbs-239-risk-data-aggregation-reporting.pdf




Comments: (0)