Download as docx, pdf, or txt
Download as docx, pdf, or txt
You are on page 1of 5

Six stages to a robust operational risk framework

20 September 2011

Prior to the financial crisis, very few institutions were able to look at their overall risk profile
holistically and truly understand the impact strategic decisions would have on the overall
organisation. In most cases, these decisions were made based on single lines of business, operating
entities, products, geographies or risk factors. Ultimately they helped contribute to poor choices and
sometimes the downfall of organisations.

It is imperative in a post-crisis world to have a robust operational risk management (ORM)


framework in place to ensure that there is a strong link between the strategic goals of the firm and the
operational activities and decisions made within the management team.

Richard Pike, risk principle, Wolters Kluwer Financial Services, explores how an organisation can
create and implement a stable and manageable framework for operational risk management in order
to comply with the multitude of regulatory requirements they are faced with.

1. Risk identification

The first stage in the framework definition process is to understand the scope of the risks that the
entire organisation and its strategy are exposed to. The operational risk manager should review
current business and the strategy for future business against the list of possible risks. The list of
possible risks will be itself defined by the scope of the ORM framework.

Risk types that might be included in the ORM framework are: IT risk, vendor risk, compliance risk,
process risk, and financial reporting risk (eg Sarbanes-Oxley). Once the risks to the organisation and
strategy are defined they may be allocated to individual functions if the operational risk teams are
split into sub units.

Regardless of the structure, the final output of this process is to create a library of risks and related
items. These related items include: policies and procedures, regulations, controls, tests and indicators.
It is vital that these libraries be created so that the links between items are understood and double
counting is minimised.

2. Core risk management process

The second stage in the framework development is to put in place the core ORM processes, which
will include risk & control self-assessment (RCSA), key risk indicators (KRIs), loss events, and issue
management.

Risk & Control Self-Assessment (RCSA)

The RCSA process should identify the key operational risks to the business, and assess those risks in
terms of their overall significance for the business based on the judgment of business management.
It also needs to drive improvement actions for those risks, which are assessed as outside agreed
threshold limits for operational risk. They provide consistent information on operational risk, which
can be aggregated and reported to senior management to better inform decision making.

Key Risk Indicators (KRIs)

KRIs are a core component of the ORM framework and will be used to establish basic transparency
and reporting obligations, measure and monitor operational risk across the company in a consistent
format, and provide an ‘early warning indicator’ of potential process failures and/or control
issues.

KRIs should also highlight areas of high risk in order to more effectively allocate resources, perform
sensitivity analysis and/or stress testing on exception rates, provide high level operational risk and
process/control reporting to line management company risk committee and estimate cost (loss level)
due to operational risk.

Loss Events
The objective of the loss event collection process is to provide a consistent and structured approach
to identify, capture, analyse and report on operational losses. The loss event collection process will
promote transparent and effective management of loss events and minimise negative effects.

It will also promote root cause analysis which can be used to drive improvement actions, emphasise
emerging trends and identify control gaps, highlighting correlations between risks and controls.

Loss event collection can also help provide objective data which can be used to quantify operational
risk for risk based capital calculation, on collection of sufficient data and reinforce accountability for
managing operational risk within the business. Additionally, it can be used to provide an independent
source of information which can challenge ORA and KI data and demonstrate compliance with
international and local regulations.

Issue Management

The issue management process should record issues related to risk assessment, KIs, loss recording,
positive assurance, internal audits, compliance audit and also support ad-hoc issues.

It should enable an issue target to be identified which can be amended as more detail about the issue
is obtained, assign a responsibility, priority and target completion date for the issue. It should also be
used to create action plans and assign responsibilities and target completion dates for actions.

Solid issues management practices should monitor that to see if actions are completed in a
satisfactory manner, provide security for sensitive issues eg fraud cases, and automatically notify and
track issues. Finally, it should provide reports to support the issue management and action planning
process and provide query capabilities.

3. Standard Reporting

The third phase of the framework is related to developing and delivering reports to management
related to the status of the above mentioned operational risk management processes, which is an on-
going process.

A key deliverable of this phase should be the capability to show the linkage across the main ORM
processes through the risk libraries. For example, organisations should be able to compare, for any
one library risk (eg AML fraud) the amount of losses to the latest assessment. This will show up
areas where either the assessments are out of line, or the losses were unexpected.

4. Key risks, scenarios and capital calculation

This vital stage of the framework is to focus on the key risks to the organisation and ensure that they
are well understood by management and stress tests are completed around these risks. The process
involves key risk definition, scenario development and capital calculation:

Key risk definition

Review of the outputs of the ORM processes and decide upon the key risks to the business and its
strategy. Those risks should expose the company to outright failure or major failure to achieve
strategic objectives.

Scenario development

Review of the factors that might cause the risk to transpire, development of scenarios in which those
factors are stressed and review of the organisation under those stress scenarios.

Capital calculation

In institutions where operational risk capital is required to be calculated, this process will develop
those models using data from all of the ORM processes and the scenario process.

5. Risk appetite
One of the most important parts of the ORM framework is the stage at which you present the reports,
key risks and scenarios (including capital calculation if required) to senior management and compare
them to the risk appetite statement defined by the board of directors. This may be an iterative
process, in that the senior management needs to understand how the key risks will be reported in
order to define their appetite. This is where the original linking of the risk library to the strategy
comes into focus. 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.

The second part of the process is to take decisions around those risks that are outside the risk
appetite. Either you can decide to change the strategy or to make tactical changes within the business
to mitigate the risk. In the second case it is easier to communicate the reason for business changes if
there is an explicit link to strategy.

6. Business & audit involvement and review

The final stage of the ORM framework development is the involvement of the “sister―
functions like the business and the audit teams. This is a vital stage and should actually be operating
alongside the other stages rather than at the end. The two main aims of the stage are; firstly, to get a
review from those functions as to the veracity of the ORM framework as it applies to them and
secondly, to get buy in ensuring that the various touch points between ORM and the sister functions
will be operated correctly.

With the application of this six stage process, risk managers can help ensure the creation and
enforcement of a solid risk management framework. Such a framework not only allows the
organisation to manage risk more effectively, but also to better exploit the dynamic tension between
risk and opportunity. This turns managing risk from something the organisation has to do into
something it needs to do in order to grow and thrive in today’s new economic marketplace.

You might also like