The Architecture of Financial Risk Management Systems

Abstract

The architecture of systems dedicated to risk management is probably one of the more complex tasks to tackle in the world of finance. Financial risk has been at the center of attention since the explosive growth of financial markets and even more so after the 2008 financial crisis. At multiple levels, financial companies, financial regulatory bodies, governments and cross-national regulatory bodies, all have put the subject of financial risk in particular and the way it is calculated, managed, reported and monitored under intense scrutiny. As a result the technology underpinnings which support the implementation of financial risk systems has evolved considerably and has become one of the most complex areas involving systems and technology in the context of the financial industry. We present the main paradigms, requirements and design considerations when undertaking the implementation of risk system and give examples of user requirements, sample product coverage and performance parameters. [PUBLICATION ABSTRACT]

Headnote

The architecture of systems dedicated to risk management is probably one of the more complex tasks to tackle in the world of finance. Financial risk has been at the center of attention since the explosive growth of financial markets and even more so after the 2008 financial crisis. At multiple levels, financial companies, financial regulatory bodies, governments and cross-national regulatory bodies, all have put the subject of financial risk in particular and the way it is calculated, managed, reported and monitored under intense scrutiny. As a result the technology underpinnings which support the implementation of financial risk systems has evolved considerably and has become one of the most complex areas involving systems and technology in the context of the financial industry. We present the main paradigms, requirements and design considerations when undertaking the implementation of risk system and give examples of user requirements, sample product coverage and performance parameters.

Keywords: Financial Risk Systems, Cross Asset, Distributed Global Implementation

1 Introduction

The world of finance of today is an extremely complex habitat which has become increasingly difficult to estimate, manage and control. The complexity of the financial environment, interactions and specifically financial products has become such that the most sophisticated tools and systems are required to be able to estimate, quantify, monitor and ultimately control the complex parameters used in estimating the risk associated to the financial industry's activities. This is a subject that can be extremely daunting to approach in a limited space but a very high level overview is nonetheless possible. Over the past 30 years, the development and wide spread of derivatives has triggered the requirement for more and more complex ways of pricing, organizing and managing such products. Over the course of this time many different approaches have been pursued, some with more and others with less success. Often the challenge in this space is defining the type of risk measures that are to be considered as part of this effort. Since the '80s one key measure of risk has been VaR, or Value at Risk [5], which gave financial institutions a relatively both simple as well as complex way of estimating risk associated with financial instruments. While this measure is still wide-spread, its reliability and "clout" has been greatly damaged by events such as the failure of LTCM (Long Term Capital Management) in 1998 as well as other significant events. While there is a measure of agreement in terms of ways to estimate risk for some instruments, such as for ex. vanilla options [1] and by extension many other similar derived products, many other financial products widely traded in the markets, such as for ex. credit default swaps on mortgage securities, require such complex approaches and assumptions that make them outright difficult and even dangerous, one can say. To this extent, potent authors have come out to speak about the subject of risk and the way it is managed, or rather mismanaged [6] [10]. Some of these authors have predicted the events of 2008 and the reasons for the collapse of some financial institutions and the grand old establishment they had created, but maybe predicting is not necessarily the primary scope of this undertaking, rather just attempt to express how complex and difficult this subject is and to show that it is well deserved to consider that it is important to understand risk, even if ultimately risk is just that, risk, and may not be entirely possible to control, even if understood, as long as the decision is to take that risk.

In an effort to build such systems some pioneers have emerged in the industry. Most of these pioneers came out of institutions such as investment banks. A notable participant may be JPMorgan, which decided to spin out its risk platform and establish an independent company using to products developed within the company [8]. Of course that many other institutions have either developed their own internal solutions or have chosen to kick-start their effort by buying an off-the-shelf product which they then customized and adapted either themselves or with the aid of the respective system vendors (ex. of vendors Misys Sophis, Imagine, Sungard FrontArena). To give an estimate on the size of the effort involved, some of the institutions the author had access to estimate that the risk platforms implementations have taken more than one iteration to implement, in some cases three or four, and costs ranged from tens of millions USD into hundreds of millions, over the years. Considering the importance and sensitivity of the functions these systems are providing they can be highly sophisticated and tend to require a number of years of effort to have implemented. Not once, the difficulty, time and costs required may cause such implementation efforts to fail and lead many times to systems that are inconsistent, partially finished and which do not cover the entire area of the business on the relevant verticals and horizontals (meaning front to back and across business lines). As a result the task of managing the risk becomes exceedingly complex and many a times a balancing act between complexity, accuracy and feasibility versus usefulness.

2 Elements Governing Risk Management and the Systems Supporting This Function

To analyze today's context in entirety we need to recognize that the financial industry of today operates in a complex environment with global markets. Institutions need to have the ability to manage risk across products, asset classes, geographies, customer segments and functional departments. Institutions that lack this ability can suffer extremely significant damage, in some instance terminal for the respective institutions. A research from the Tower group [11] argues that these new standards will mean that sizeable investments will be needed in systems able to deal with this complexity. This will be more so the case with large global institutions that have a stronger appetite for risk. According to the report, investment in technology development for risk management in the financial services industry outpaces other information technology spending as it was reported to have been estimated to above USD 21 billion in 2005. After the financial crisis of 2008 and the resulting increase in the level of oversight and risk management required these numbers have surely increased significantly but as of now conclusive numbers are yet to be found. As part of this development in enhancing the risk systems, financial institutions also need to invest in systems in a manner that allows improving business value and reducing capital requirements and lowers overall exposure.

In this context the high level drivers for such systems include access to real-time and accurate market information as well as a highly flexible framework allowing quick integration into the company's existing infrastructure.

There are many types of risk that need to be tackled as part of the risk management function and these include systematic risk (credit, operational, market, and interest rate risks) and unsystematic risk (business and financial risks). In this paper we will be dealing with systematic risks that can be measured using analytical or stochastic methods.

There are a variety of aspects that need to be taken into account when considering a suitable architecture for a cross platform risk platform. The aspects considered are all important, if in different degrees, and the ability to satisfy them of course also important in varying degrees. At a high level an important consideration needs to be given to the governance aspects of risk management, given that the governance model will ultimately determine the level of complexity, product coverage and cross usage by various departments (front office, operations, product control, market and credit risk, else). At a very high level it is important to establish a risk man agement philosophy. As part of this philosophy some of the main attributes may vary significantly depending on the risk appetite and culture of the company. For the purpose of our architectural considerations we will assume that the business has to maintain relatively tight risk metrics which largely need to be delivered in real time, or quasi real time, depending on the product set and markets covered. In no particular order, tight risk management means that there is a need to restrict the size of the individual manager (or group, smaller or larger) directional bias; it has to maintain well defined, monitored and acted upon drawdown limits; and that, as we mentioned, these measures need to be maintained in as much as possible on a real time basis. In terms of the senior managers responsibility, these may include allocation of capital to portfolio managers and strategies, depending on how these are defined in the institution; monitor and oversee various levels of portfolio managers; and monitor and approve trading limits; also potentially manage global even risk books to hedge significant events.

As part of the assessments required to establish the major areas important for the risk management in a financial institution, it is important for the system architects to involve the business community in the respective organization. The best way to do that is to have them provide feedback in the form of questionnaires or direct discussions. For the purposes of this study we used a questionnaire based approach implemented in one of the major multinational investment banks. The main governing considerations included in this process were: importance of an integrated workflow across execution and risk management systems; risk management functionality requirements in terms of priorities mainly involving risk diagnostic-predictive analysis- hedging and portfolio analysis; historical data and performance measurement requirements; cross products and cross regional requirements; overall existing risk management systems assessment. The major findings as part of the study distilled down to: confirming the requirement for an integrated platform for execution and risk management; confirming the requirement for a consolidated cross-products trading risk management platform; strong feedback specifically from some business functions around redundancy, limited functionality and unreliable state of current platforms; confirming the list of requirements (such as historical trends and charting, better risk sensitivities P&L explanatories, factorial P&L explanatories and stress, pre- and post- what-if analysis on strategies and portfolios, performance analysis, correlations between strategies and books, back-testing).

We present the number of execution systems used in the institution at the time (Fig. 1).

We also present the average number of risk systems used in the institution at the time (Fig. 2).

We further present the most frequently traded (in terms of number of users) products by region and asset class (Fig. 3).

Table 1 presents the result of the survey in terms of percentages of user's opinions.

In terms of high level results of the survey the main pressure points for the institution can be categorized as: consistency and standards (pricing, market data, product definition, hierarchies); reliability (global real-time complete positions and risk); flexibility (multi- asset and cross-regional; desk-top integration, drill-downs, slicing the hierarchies & product definitions, Histories); scale and capacity (volume insensitive platform); sophistication (360 degrees of risk coverage; integrated with trader workflow); operational safety (single trade entry, trade life-cycle workflow).

We present a summary of the target trading risk architecture as emerging from the survey in Table 2.

An important consideration when implementing a cross-platform risk management system is the product coverage required for each of the strategies/business lines. As such we include in the "must-have" considerations for these systems a sample list of products to be covered. This is of course not exhaustive but it should give a good idea of what is required for a decent coverage across a number of major strategies (see Table 3).

In terms of performance requirements that the system needs to satisfy, they can of course vary widely, but for a reasonable set of parameters we can make a certain number of assumptions in order to satisfy the needs of a medium to large size business based in multiple locations across the globe (see Table 4).

3 Risk Management System Design

A risk system engine is a system with a number of core components that collaborate and react to external events and perform required actions. Some of the core functions of the system include the ability to keep track of all the activities executed as part of the trading operation, the ability to track the most current risk profile as well as the "as-of-date" status at some point in the past (in case an analysis needs to be performed, which is invariably the case), support for a superset of all the products traded in the relevant target business aria (which can become very challenging for a truly cross-asset system) and the capability to continuously evolve in line with market evolutions and indeed the ability to support continuous change (in case a new product requires to be traded on very short notice, as again is indeed the case on a fairly constant basis). In order to support such functions the system requires a complex infrastructure, made even more complicated by the requirements of the Sarbanes-Oxley acts which enforce complete auditing. In day-today operations a risk system allows continuous updates to its position status (both from manual as well as automated sources), updates the pricing data from the markets, uses relevant pricing and risk models and outputs the required updates in prices and positions. Simultaneously the system needs to be responsive enough so as to allow for ad-hoc user commands. By implementing these functions the risk system executes the actions needed such as estimating risk explanatory parameters for PnL, recalculating affected positions and keeping in line with the changing underlying prices and associated markets. The types of actions and events that a risk system supports and provides include: support for both simple (one-offparameters changes, such as spot level for ex. to allow a what-if scenario simulation) as well as complex user operations (such as executing scenario ad-hoc simulations during market hours), support for continuous system status changes resulting from market price updates, trade events (both manual and automates fills), user driven events (changing the parameters such as credit spreads, volatility, interest rate, dividends), as well as general system events (market status, system health states, network links). A central component of the risk system is the pricing library which needs to cover all product types [2] [3] [4].

While the spectrum of possible actions for a risk system tends to be quite exhaustive, a summary of the possible actions taken as a result of reacting to these events include: evaluation of fair values (either marked-tomarket or marked-to-fair), calculation of various parameters relevant for each instrument type, generally calculating individual product based and overall exposures as well as updating the latest status to the user and present information required for hedging [9].

To support this complexity the designers of risk systems need to contend with an escalating set of requirements that need to be satisfied. In the first place, in order for such a system to have any chance of success, it needs to consider the disparate and sometimes conflicting lists of requirements that the various business functions will need from the system across front office, middle office (operations), risk functions (market and credit risk), reporting and compliance functions. In a truly global system such as the ones used by multinational investment institutions a risk system may have thousands of users that it needs to support across a variety of business areas. To support such functions the system needs to be able to clearly and accurately reflect product specifications in such a way that once implemented it requires only minor changes to add a new product type. A global system needs to be able to support potentially millions of computations, which are due to changes in parameters (volatility, interest rates, dividends, and correlations) or events such as transactions. In order to support this, the system requires a distributed architecture that consists of networked workstations or servers on a large scale (1000's of CPU's). Of course that such a system needs to be able to deal with and support multiple currencies and users located in different locations. For a brief description a risk management software packages include the following components: credit risk measures, models, and exposure simulation; market risk measures, models, and exposure simulation; fraud risk measures, models, and exposure simulation; Value-at-Risk, historic simulation, and Monte Carlo simulation; "Greek" risk calculators (beta, delta, gamma, vega, theta, rho); instrument coverage (such as fixed income, equities, commodities, derivatives); modeling & scenario generation; stress testing and time simulations; APIs and toolkits for interfaces to other systems; spreadsheet add-ins [7].

4 Risk System Architecture

The general architecture of a risk system may be designed in a modular way and can be configured to support a dedicated set of instruments, functions and user groups (dedicated business targeting, or cross-asset implementation) on one side as well as being deployed to support a local business or indeed a truly global implementation for multinational institutions [12].

There are several layers of components to be taken into consideration, as well as the way they interact and exchange information. One of the core considerations for the architecture is the workflow that each product needs to go through, as in such a system there are several roles involved (front office (trading, sales, structuring), operations, product control, risk, compliance, treasury, margining, collateral management, reporting, etc.) and in quite a large number of the deals involved multiple parties need to be involved to ensure a given deal is processed correctly.

The core components include the position engine, the calculation engine and pricing models which are responsible for calculating the fair values for all the products. Specifically the calculation engine needs to aggregate all the data required (instrument static & dynamic data) in order to provide it to the pricing models in a load-balanced way. For Monte-Carlo valuation models the calculation engine also performs the functionality required to support distributed Monte-Carlo models. The position engine maintains an accurate account of all the positions during the entire life of a position, including postexpiration, such that the data can be retrieved even at a later time when the position is not actively traded anymore. In order to support this all positions and marks are maintained, each trade is accounted for at all times, and records are maintained in a currently active database and then migrated to an archive when they are not active anymore. The instrument static data service stores and manages a full description of all the data that represent the contractual details for the products that the system risk manages. The dynamic data services stores and manages the respective data for each of the underlying instruments for the products supported by the system. The data may be maintained manually or using automated feeds from external providers. The dynamic data required includes volatility surfaces, dividends (cash and/or yields), yield curves (for each relevant currency), repo curves and correlation sets.

Multi-site implementation: In the case of large financial institutions which require spreading of risk across regions as well as aggregation of risk centrally the architecture of the risk systems needs to support such deployments. The technology approach may include either message, database or other type of replication in terms of data distributions as well as rules based workflows for maintaining the relevant static and dynamic data (instruments, volatilities, dividends, correlations, else, in the primary locations for the respective products).

5 Conclusions

This paper presents a brief description of the modern landscape involving risk management, explains how risk systems are implemented and what the main requirements for such systems are, presents the impact that the financial markets upheavals have had over this area of technology and how it has created an increased need for even more sophisticated risk systems in the financial industry.

The use of financial risk systems is a growing area. The need for increasingly sophisticated risk systems has been growing globally and has become of paramount importance especially after the 2008 financial crisis. The practice is for many large financial institutions to implement their own proprietary systems. As the requirements for new risk measures and monitoring increasing we can expect that this trend will continue. Vendors however also have their very important role to assist mid and small sized institutions with providing a robust risk management platform while the providers can help in a significant way by collating the requirements and offering advantages of scale.

One extremely important aspect in the establishing of the risk management architecture is to consult the target business community or the "target audience" for the risk management systems being developed or enhanced and making sure that the main requirements and considerations are taken into account well in advance of establishing the system's main architectural framework. This is important in the case of any system but it is even more so in the case of systems like a risk management system whose development cycles and shelf life may be more than 10 years, and in some case much more into 15- 20 years.

References

References

[1] F. Black, M. Scholes, The Pricing of Options and Corporate Liabilities, Journal of Political Economy, 1973.

[2] S. Das, Swap & Derivative Financing: The Global Reference to Products, Pricing, Applications and Markets, 1994.

[3] F.J. Fabozzi, Fixed Income Mathematics: Analytical & Statistical Techniques, 1996

[4] J.C. Hull, Options, Futures, and Other Derivatives, Wiley, 1997.

[5] P. Jorion, Value at Risk: The New Benchmark for Managing Financial Risk, McGraw-Hill, 1996.

[6] B. Mandelbrot, The Misbehavior of Markets: A Fractal View of Financial Turbulence, 2006.

[7] M. Penubothu, Contributions to the study and modeling of knowledge development systems, PhD thesis, Saurashtra University, 2008.

[8] RiskMetrics, Risk Management: A Practical Guide, 1999, http://www.riskmetrics.com

[9] N. Taleb, Dynamic hedging , 1996.

[10] N. Taleb, The Black Swan: The Impact of the Highly Improbable, 2010.

[11] Tower Group, Information Risk Management in Financial Services, whitepaper, 2007.

[12] I. Ziman et al. Structured Risk System Implementation, Internal Documentation, 2005.