You don't have javascript enabled.

Six stages to a robust operational risk framework

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

  • Editorial Team
  • September 20, 2011
  • 7 minutes

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.