Risk: getting started in operational risk; approaches and their drawbacks

RMA Journal, The, May, 2003 by Peter Nakada, Andrew Hickman

A seven-part series explores risk management at regional banks to help senior managers make better decisions about methodologies and processes.

As regional banks begin setting up enterprise risk management programs, they are devoting substantial time and effort to understanding and analyzing operational risk. Why?

* It gives chief risk officers something to do. Chief credit officers and A/LM specialists have other major banking risks covered, so newly appointed CROs find themselves most occupied with the "other" risk--operational risk.

* Incoming regulation requires it. The new Basel Capital Accord will, for the first time, explicitly require banks to hold capital against operational risk. Regulators have said the average capital burden won't change, but that may not be true for individual firms.

* Operational risk looks easy. Compared with, say, the sophisticated models required to assess credit risk, the frameworks needed to address operational risk seem downright simple.

Even if we believe these are good reasons, they're nor sufficient reasons. Op risk needs attention, but it should not be make-work for a CRO. The Basel Accord covers only one, small piece of the op risk puzzle--dramatic events that require reserve capital. And op risk is by no means as easy as is often claimed.

That said, there are other, stronger reasons to address operational risk. To see what these might be, let's first review how banks are typically dealing with operational risk today.

Common Approaches

A new CRO's first instinct is, understandably, to gather data. This typically involves developing an operational risk taxonomy and then determining which operational risks each business faces. This can be done qualitatively, by interviewing business managers and asking them about their historical operational losses. This approach results in a "traffic light" report with operational risk categories on one axis, business lines on the other axis, and a green-yellowred light in each box showing the level of operational risk. This type of report is good for raising awareness of operational risk and developing management controls. But it does not help to quantify, or capitalize, operational risk.

Many firms have opted to address the capital question by adopting another approach: building an event loss database. This involves recording operational losses and categorizing them by type. Like the traffic-light approach, this is useful for raising awareness of key operational risks, and it's the one that flows most naturally from the Basel Accord. However, the claims of database proponents notwithstanding, it's unlikely to yield much more insight into operational risk, for reasons given in the sidebar, "Key Problems with Event Loss Databases."

A better alternative. Large, rare risks are the only type that require capitalization. Any firm exposed to large, common risks is going to be out of business before it has much time to worry about op risk. Small, rare losses are immaterial. That leaves small, common operational losses, for which the key issue is not earnings volatility or risk capital, but rather management of the average level of losses. This involves identifying control points in the bank's operations and linking them to losses.

The best approach for large, rare risks is to measure the frequencies and seventies of loss events in terms of observable and identifiable parameters. For example, employee misbehavior risks might be represented by the rate of incidents per employee. To the extent that useful parameters can be identified, they can then be applied to underlying drivers that vary from bank to bank--in this case, the number of relevant employees. Historical data is important, but only for establishing parameters to the risk model.

For small, common losses, banks would do better to develop metrics that are indirectly related to operational losses--cancelled trades, employee turnover rates, or audit and trade exceptions, for example--so long as this indicator is intuitively related to the frequency of the underlying loss event. Turning these indicators into useful management tools is a straightforward process:

* Establish a baseline from past performance.

* Set goals for future performance.

* Set a threshold for unacceptable performance that will trigger management action. This approach is related to statistical process control or Six Sigma programs that have been used in manufacturing for years and are being adopted by forward-thinking banks.

We can see how this twofold approach makes the case for handling operational risk much more robust.

* The CRO contributes to business performance. The capital requirement for a business line becomes much more clearly defined. This allows business lines to be capitalized appropriately and their risk-adjusted returns on capital to be more easily compared.

* Real risks are addressed. Rather than knee-jerk compliance with a partial regulatory standard, businesses can spend on controls that will genuinely (and efficiently) mitigate operational risk. For example, this approach allows proper cost/benefit analysis of the billions of dollars of insurance that banks buy every year.