This series of blog posts discusses the importance of the risk intelligence concept, as raised by Chartis Research surveys (read the full Chartis Research white paper). In this post, we explain the concept of risk intelligence, and some of the challenges in implementing a risk management system in general.
Risk intelligence refers to the ability to make informed decisions about risks based on historical, current and future views of a business. It involves identification, extraction and analysis of internal and external data such as counterparty credit risk management data, operational risk data, liquidity numbers, and risk-based performance metric data.
Traditionally, financial institutions (FIs) approached the need for risk information like any other business information need by adopting business intelligence (BI) tools developed internally or purchased from generic BI vendors such as Business Objects and Cognos. Most of these solutions are based on technology architectures now over a decade old. Then the challenge for system architects was to spare expensive memory and accommodate slow computer processing. Since then, there have been technological improvements including faster processors, cheaper memory and zero-footprint web deployment allowing technology vendors to improve their BI solutions and report on anything from market data to counterparty credit risk management data with more ease.
Implementation has been a serious problem with traditional BI technologies being used for risk management purposes. Implementation projects can take months, sometimes years to complete and often morph into multimillion dollar systems integration initiatives that do not necessarily provide FIs with more successful risk management solutions (such as counterparty credit risk management or operational information). Ongoing frustrations with data quality as well as the process of accommodating business users’ and regulators’ requests for new reports, add to the IT resources needed to maintain systems. These issues push up the overall cost of ownership. Managing growing costs is also an obstacle to a successful system that provides accurate, easy-to-access counterparty credit risk management data, liquidity numbers, etc.
The implementation problem was compounded further, because many first- and second-generation risk application providers based their reporting and BI layers on the same traditional architectures. They also embedded third-party BI tools into their applications via original equipment manufacturer (OEM) agreements. For example, a bank might have its own standard BI tool for generic business intelligence/analytics and reporting (e.g. Business Objects). Its counterparty credit risk management system would have a different BI tool (e.g. SAS) embedded in it and its operational risk system, would have still another BI tool embedded in it (e.g. Cognos). The operational risk function would likely have some inhouse-developed tools as well as a number of Excel- or MS Access-based tools – resulting in multiple, and sometimes conflicting, BI practices.
In the next post, we will discuss some interesting findings regarding the implementation of risk management systems, as concluded by Chartis Research surveys run between 2006 and 2009.