Over a typical month a lot of risk practitioners in my network pose various technical questions to me. Today is no different but this month we certainly have an interesting query that goes along the following lines:
"I am creating a data model for KRIs and Op Risk Loss Events and would be curious to know how the metadata model and tables could work, how can I simulate or model Key Risk Indicators?" | US Banker
A good question without any doubt and from what I observe in general risk management practice, Key Risk Indicators are rarely modeled in coherent manner. Let's address the database design first, then we can investigate various ways in which Key Risk Indicators can be modeled.
Key Risk Indicators are a popular element of an operational risk framework because they furnish risk managers with forward looking measures on threats. As an outcome of Basel II, a typical bank's risk department is often focused on capital numbers that are derived from recurring loss event data but this way of measuring risk is problematic when it is entirely backward looking.
Key Risk Indicators are an exciting proposition out of this trap because they attempt to be a proactive tool with which a risk manager can react to emerging causal factors before a risk event materializes.
As honourable as this forward looking KRI value proposition appears to be, KRI networks aren't without their problems. Firstly, KRI data has to be identified and captured across many different business functions in a company and that alone can be an arduous exercise. Secondly, this KRI data is just that, its data not information.
Translating raw KRI data into useful information is going to require the development of a sound database and modelling system. However, most of the leading risk management departments are doing little more than actively reporting their KRI results alongside their risk heatmaps.
Let's level these two hurdles starting with the metadata layer of the KRI system first.
Key Risk Indicators are an exciting proposition out of this trap because they attempt to be a proactive tool with which a risk manager can react to emerging causal factors before a risk event materializes.
Event Actualization | A Typically Sound Bank Risk Framework [ LINK ]
As honourable as this forward looking KRI value proposition appears to be, KRI networks aren't without their problems. Firstly, KRI data has to be identified and captured across many different business functions in a company and that alone can be an arduous exercise. Secondly, this KRI data is just that, its data not information.
Translating raw KRI data into useful information is going to require the development of a sound database and modelling system. However, most of the leading risk management departments are doing little more than actively reporting their KRI results alongside their risk heatmaps.
Let's level these two hurdles starting with the metadata layer of the KRI system first.
KRI Metadata
I personally define a successful Key Risk Indicator network as a comprehensive framework for identifying enterprise level threats and assessing appropriate factors that give signal or information around these specific risks. Such a facility is likely to generate voluminous amounts of KRI data that needs to be stored in a repository far greater than the capabilities found in a spreadsheet. With this in mind, we should create an access database for housing KRI data and a sample structure has been shown below.
To be totally real here, this database was built in Microsoft Access in about forty five minutes, it took nearly as long to turn the relationship schematic into an image and write it up in PowerPoint presentation!!! The point I am making here is that it is straightforward to enable the information technology aspects under risk management, risk teams don't have to go out and buy an expensive and often flawed risk management system from a vendor.
The database here comprises of four levels or working structures which I will briefly describe below:
KRI Database Design | Martin Davies
To be totally real here, this database was built in Microsoft Access in about forty five minutes, it took nearly as long to turn the relationship schematic into an image and write it up in PowerPoint presentation!!! The point I am making here is that it is straightforward to enable the information technology aspects under risk management, risk teams don't have to go out and buy an expensive and often flawed risk management system from a vendor.
The database here comprises of four levels or working structures which I will briefly describe below:
[Level-1] Risk and business definitions.
[Level-2] Connecting risks to business unit or facilities in the enterprise and identification of Key Risk Indicators.
[Level-3] Connecting or associating risks with specific Key Risk Indicators that have been identified.
[Level-4] The operable component of capturing KRI Data against KRI definitions.
The KRI Table | Martin Davies
There are many other pieces of information we may want to capture for a single KRI but this is the list of attributes that first came to mind.
If the database levels are anything to go by, one can see that they are likely to follow the PROCESS of risk management at a delivery level. That is, a risk manager will map business units at a top level, identify what risks threaten these business units and then register these risks before attempting to capture any KRI detailing on the risks specifically. I believe a good database or metadata model under a framework should support the operable levels of what it has been designed for.
Okay so there we have it in PART 1, the metadata layer under a KRI system and in PART 2 of this article we will look at what to do with the Key Risk Indicators that we capture.
Other articles in this series
This blog is just one chapter in a series of articles on 'What to do with KRIs?'. There will be four other chapters published on this KRI topic that deal with different aspects of Key Risk Indicators. These chapters have been listed below:
Part 1 - KRI Metadata Structure << This article
Part 2 - Eight KRI realms to transverse [LINK]
Part 3 - Front to back operation of the KRI system [Not published yet]
Part 4 - Modelling the KRI realms [Not published yet]We trust you will enjoy the ongoing dialogue and the practical examples that are going to follow.
No comments:
Post a Comment