How to develop a robust risk management framework

This article updates Six stages to a robust operational risk framework, written by Richard Pike in September 2011. It explains how a financial services company can create and implement a stable and manageable framework for risk management.

1. Risk identification

In this section in the previous article I talked about the process of defining and listing the risks associated with different types of operational risk. The end point was a risk library for the firm along with the related items (policies, regulations, controls, tests, etc.).

The practice of risk teams providing lists of risks to management for their review has some major faults and over the past number of years these have been exasperated. Issues with risk registers include:

COMPLEXITY: modern business is complex and interconnected; the higher up the organisation the more interconnected things become, with risks often being combined and having multiple different outcomes. For example, the risk associated with internal fraud can be categorised as a compliance risk and also as an operational risk.

COMMUNICATION: particularly evident in non-financial risks are the hierarchy and aggregation effect that a simple list does not communicate. For example, the risk of a bank branch flooding in a storm is really only of relevance to a branch manager and their regional manager. The CEO of a bank will find its inclusion in a risk register annoying and irrelevant unless 25% of the retail branches and the head office are all at risk of flooding in a storm.

CONTEXT: Why is a particular risk important to my business? So what? These are regular questions that result from a senior executive reviewing a risk register. While one solution is to add context – setting out how a risk might arise and how it might impact the business – this can result in information overload.

OWNERSHIP: Within a standard risk register it is often difficult to assign ownership and responsibility. This results in either no ownership being attributed or defaulting to a second line resource, which is incorrect.

In order for a firm to manage operational risk into the future it needs to transition from a risk register to a network. This allows for interconnectedness, levels and the need for context associated with risks to be recorded and communicated as a network.

The benefit of a network is that it can handle multiple connections between items. At the same time they can be easily separated (into different levels or categories) while retaining their connectivity. Other object types can also be added to the network to incorporate context where necessary (eg policies, regulations).

In addition, when risk teams communicate risks within a network environment it stimulates conversations and challenges people to explore the linkages and interdependencies.

As useful as a network of risks is, it is still not directly related to the business. In order to make risk discussions more relevant it is important to anchor the risk network to key dimensions within the business. There are a number of dimensions that a firm could choose:

•           Organisation units

•           Processes

•           Legal entities

•           Policies

•           Objective

While each has its merits, it is becoming increasingly clear that linking to objectives is the most beneficial to a financial institution. One of the key reasons for this is that modern businesses are increasingly organising themselves using objectives.

Given this drive to manage by objectives it can be argued that risk managers should endeavour to anchor their risks to objectives if they want to make them more relevant to senior managers and their teams.

Allied to this, in the financial industry, it is also evident that regulatory expectations are that risk appetite and strategy definition are very closely coupled. This is forcing boards and senior managers at firms to have clear strategy and risk appetite development processes, which are integrated. It also means that best practice is to understand the effects on risk appetite of a strategic change and vice versa.

2. Core risk management process

The second stage in the framework development is to put in place the core risk management processes, they include:

• Risk & Control Self-Assessment (RCSA)
• Key risk indicators (KRIs)
• Loss events
• Issue management

These processes haven’t changed much over time. Companies have generally gotten better at managing them and found efficiencies where necessary.

The main changes are in the importance and oversight of each process. In many organisations now the RCSA process has become much more important. Often firms take a failing in any of the other processes a reason to review the relevant RCSA. They will also make the reporting of that review a formal oversight process. So for example, if you have a large loss or a failed test that will trigger a formal review of the relevant RCSA to check whether the risk is present and if so, if the correct assessments have been made given this new information.

The role of KRIs has also been elevated. With the increased importance of risk appetite statements, many operational risk KRIs are being used to estimate appetite in a particular aspect of risk. The governance of these indicators has also moved on to a state where there are very well defined escalation and review processes that make up an important part of an operational risk framework. 

3. Standard reporting

The third phase of the framework is that of developing and delivering reports to management related to the status of the above mentioned risk management processes.

The changes in phase one have resulted in reporting that is much more focused on the effect of operational risk on business objectives. The best firms have ceased to report on silos of risk data (losses, test results, etc)  and now present reports by business objectives or at least process. So for example; a list of the major objectives and for each the list of items (losses, tests, issues, KRIs, RCSAs) that have broken tolerances. This results in operational risk reports that are much more relevant for business managers.

4. Key risks, scenarios and capital calculation

This stage of the framework has also progressed as a result of the increased focus on linking risk to business objectives.

If you have completed that stage well, you automatically have the ability to generate a list of the key risk to the firm as they will be the risk associated with the key objectives. This will also make the process of developing relevant scenarios more straightforward. It is in the area of operational risk scenarios that most work has been done recently.  There are now well-designed processes for developing and running scenarios and they are well embedded in many firms’ operational risk frameworks.

 As a result of more formal scenario assessment processes, it is now the norm to see capital calculation methodologies based upon scenarios or a mixture of loss events and scenarios. While the regulatory guidance for operational risk capital is somewhat unsure at the moment firms that utilise well-formed scenario analysis in their internal calculations are the most common.

5. Risk appetite

In the original article I mentioned that the linking of the risk library to the strategy comes into focus in the risk appetite. I stated that ‘If you can supply the Board with the key risks to their business and their strategy it is easier for them to annunciate a risk appetite’. This still holds and the linking of risks to business objectives will help achieve this aim. A well-defined risk appetite and the associated oversight and escalation procedures have now become staples of good risk management.

In a recent discussion paper on operational resilience, the Bank of England , PRA and FCA have suggested that firms go further and define core business services (Building the UK financial sector’s operational resilience). The idea is that firms will define their own impact tolerances for important business services.  If this idea takes hold then we can presume that operational risks will need to also be reported in line with the core business services an their impact tolerances.

6. Business & audit involvement and review

The final stage of the risk framework development is the involvement of the sister functions like the business and the audit teams. There have been two main changes in this area.

Regarding the business: increasingly the business is developing their own internal risk and control review capability (often call the 1.5 line of defence). They are doing this in order to assure themselves that risk is being managed but also to protect the front line teams from constant bombardment from the second and third lines.

The linkage to audit teams has matured in that often now boards have asked 2nd and 3rd lines to provide them with a joined up assurance map. The aim of this map is to show exactly how the board are getting assurance and where that assurance is lacking.  This process helps to identify areas where assurance is lacking or also where there are overlaps.

• Read more under:
• InsurTech