CC BY
100
Operational risk management: an overview
Yossi Raanan, Ron S. Kenett and Richard Pike 2.1 Introduction
Operational risk management is a somewhat new discipline. While financial risks were recognized long ago, they are in fact part of everyday life and not just a business issue; operational risks and their management have been misdiagnosed frequently as human error, machine malfunction, accidents and so on. Often these risks were treated as disconnected episodes of random events, and thus were not managed. With the advancement of computerized systems came the recognition that operational mishaps and accidents have an effect, sometimes a very considerable one, and that they must be brought under control. Today, operational risk management is gaining importance within businesses for a variety of reasons. One of them is the regulatory demand to do so in important sectors of the economy like banking (Basel II, 2006), insurance (Solvency II, 2009) and the pharmaceutical industry (ICH, 2006). Another is the recognition that since operations are something that the business can control completely or almost completely, it ought also to manage the risk associated with these operations so that the controls are more satisfactory for the various stakeholders in the business. This chapter provides an overview of operational risk management (OpR) and enterprise risk management (ERM) as background material for the following chapters of the book.
Operational Risk Management: A Practical Approach to Intelligent Data Analysis Edited by Ron S. Kenett and Yossi Raanan © 2011 John Wiley & Sons Ltd. ISBN: 978-0-470-74748-3
2.2 Definitions of operational risk management
Operational risk has a number of definitions which differ mainly in details and emphasis. Although the proper definition of operational risk has often been the subject of past heated debate (International Association of Financial Engineers, 2010), there is general agreement among risk professionals that the definition should, at a minimum, include breakdowns or failures relating to people, internal processes, technology or the consequences of external events. The Bank for International Settlements, the organization responsible for the Basel II Accord regulating risk management in financial institutions, defines operational risk as follows:
Operational risk is defined as the risk of loss resulting from inadequate or failed internal processes, people and systems or from external events. This definition includes legal risk, but excludes strategic and reputational risk. Legal risk includes, but is not limited to, exposure to fines, penalties, or punitive damages resulting from supervisory actions, as well as private settlements.
(Basel II, 2006)
It is this latter definition that will be used here. In layman's terms, operational risk covers unwanted results brought about by people not following standard operational procedures, by systems, including computer-based systems, or by external events.
In the Basel II definition, 'inadequate or failed internal processes' encompass not only processes that are not suitable for their purpose, but also processes that failed to provide the intended result. These, of course, are not the same. Processes may become unsuitable for their purpose due to external events, like a change in the business environment over which the business has no control. Such change might have been so recent that the business or organization did not have the time to adjust itself. Failed processes, on the other hand, mean that the organization has fallen short in their design, implementation or control. Once we include internal auditing as one of the important business processes, it is seen that internal fraud and embezzlements are part of the definition.
The 'people' part covers both the case of human error or misunderstanding and the case of intentional actions by people - whether with intent to cause harm, defraud or cheat, or just innocently cutting corners, avoiding bureaucratic red tape or deciding that they know a better way of executing a certain action. 'Systems' covers everything from a simple printer or fax machine to the largest, most complicated and complex computer system, spread over many rooms, connecting many users and many other stakeholders located in every corner of the globe. Last in this shortlist of categories of operational risk is 'external events'. This innocently looking phrase covers a lot of possible causes for undesired outcomes - from hackers trying to disrupt computer systems, through labour strikes, to terrorist attacks, fires or floods.
Operational risks abound in every sector of the economy and in every human endeavour. Operational risks are found in the health sector, in the transportation sector, in the energy industry, in banking, in education and, indeed, in all activities. Some sectors, because of enhanced sensitivity to risks or because of government regulations, have implemented advanced processes for identifying the risks particular to their activities. However, operational risks exist when any activity occurs, whether we manage them or not. This recognition is beginning to reach the awareness of many management teams in a wide variety of activities (Doebli et al, 2003).
An example where operational risks are recognized as a source for large potential losses can be found in the report by the Foreign Exchange Committee (2004) that encourages best practices for the mitigation of operational risks in foreign exchange services. A detailed discussion of risk management in this industry, including an application of Bayesian networks used later in this book, can be found in Adusei-Poku (2005).
On 14 March 2010, the Sunday Times published a summary of a 2200-page report investigating the crash of Lehman Brothers on Wall Street described in Chapter 1 (Sunday Times, 2010). The report stated that, on May 2008, a senior vice president of Lehman Brothers wrote a memo to senior management with several allegations, all of which proved right. He claimed that Lehman had 'tens of billion of dollars of unsubstantiated balances, which may or may not be 'bad' or non-performing assets or real liabilities', and he was worried that the bank had failed to value tens of billion of dollars of assets in a 'fully realistic or reasonable way' and did not have staff and systems in place to cope with its rapid growth.
Lehman's auditors, Ernst & Young, were worried but did not react effectively. Time was not on Ernst & Young or Lehman Brother's side. By September, the 158-year-old bank was bust, thousands of people had lost their jobs and the world's economy was pitched into a black hole. The court-appointed bankruptcy examiner found Lehman used accounting jiggery-pokery to inflate the value of toxic real-estate assets it held, and chose to 'disregard or overrule the firm's risk controls on a regular basis'. His most juicy finding was Repo 105, which the report alleges was used to manipulate the balance sheet to give the short-term appearance of reducing assets and risk. Not since Chewco and Raptor - Enron's 'off balance sheet vehicles' - has an accounting ruse been so costly.
These events are all examples of operational risks.
In summary, operational risks include most of what can cause an organization harm, that is foreseeable and, to a very large extent, avoidable - if not the events themselves, then at least their impact on the organization. It is quite plain that once we recognize the operational risks that face our enterprise, we can mitigate them. It is important to understand that a risk, once identified, is no longer a risk - it is a management issue. OpR is the collection of tools, procedures, assets and managerial approach that are all aimed together at one goal: to understand the operational risks facing the enterprise, to decide how to deal with them and to manage this process effectively and efficiently. It should be
noted that the idea of OpR is, in some sense, a circular problem. The processes and systems used for managing operational risks are all subject, themselves, to the same pitfalls that may cause systems and people to malfunction in other parts of the organization. It is hoped, however, that once OpR is adopted as a basic approach of management, the OpR system itself will be subjected to the same testing, screening and control that every other aspect of the operation is subjected to.
2.3 Operational risk management techniques
2.3.1 Risk identification
In order to manage and control risk effectively, management need a clear and detailed picture of the risk and control environment in which they operate. Without this knowledge, appropriate action cannot be taken to deal with rising problems. For this purpose, risks must be identified. This includes the sources, the events and the consequences of the risks. For this and other risk-related definitions, see also ISO 73 (2009).
Every organization has generic activities, processes and risks which apply to all business areas within the organization. Risk descriptions and definitions should be stored in one repository to allow organizations to manage and monitor them as efficiently as possible. This approach creates a consolidated, organization-wide view of risk, regardless of language, currency, aggregation hierarchy or local regulatory interpretations.
This consolidated view allows the organization to monitor risk at a business unit level. However, it is integral for each business unit to identify and monitor its local risks, as the risks may be unique to that business unit. In any case, a business unit is responsible for its results and thus must identify the risks it faces. In order to do this effectively, risks must be identified. Notwithstanding risks that are common knowledge, like fire, earthquakes and floods, they must also be included in the final list. All other risks, specific to the enterprise, must be identified by using a methodology designed to discover possible risks. This is a critical step, since management cannot be expected to control risks they are unaware of. There are a number of ways of identifying risks, including:
• Using event logs to sift the risks included in them.
• Culling expert opinions as to what may go wrong in the enterprise.
• Simulating business processes and creating a list of undesirable results.
• Systematically going through every business process used in the enterprise and finding out what may go wrong.
• Using databanks of risk events that materialized in similar businesses, in order to learn from their experience.
Some of these methods produce only a list of risks, while others may produce some ideas, more or less accurate, depending on the particular realization of the frequency of these risk events actually happening. This frequency is used to calculate the expected potential damage that may become associated with a particular event and, consequently, for setting the priorities of treating various contingencies.
Organizations ensure consistency in risk identification in two ways:
1. Risk identification is achieved via a centralized library of risks. This library covers generic risks that exist throughout the organization and associates the risks with the organization's business activities. When a business unit attempts to define its local risks and build its own risk list, it does so by considering a risk library. The library itself is typically created by using an industry list as an initial seed, and then augmented by collecting risk lists from every business unit, or it may be created by aggregating the risks identified by each business unit. In either case, this process must be repeated until it converges to a comprehensive list.
2. Identification consistency is further aided by employing a classification model covering both risks and controls. Using this model each risk in the library has an assigned risk classification that can be based on regulatory definitions, and each associated control also has a control classification. The key benefits of classification are that it allows organizations to identify common risks and control themes.
Once risks have been identified, control must be put in place to mitigate those risks. Controls can be defined as processes, equipment or other methods, including knowledge/skills and organization design, that have a specific purpose of mitigating risk. Controls should be identified and updated on a regular basis.
Controls should be:
• Directly related to a risk or a class of risks (not a sweeping statement of good practice).
• Tangible and normally capable of being evidenced.
• Precise and clear in terms of what specific action is required to implement the control.
The process of risk identification should be repeated at regular intervals. This is because risks change, the nature of the business evolves, the regulatory climate (sometimes defining which risks must be controlled) changes, the employees are rotated or replaced, new technologies appear and old technologies are retired. Thus, the risk landscape constantly evolves and, with it, the risks.
A control assurance process aims to provide assurance throughout the business that controls are being operated. It is generally implemented in highly 'control focused' areas of the business where management and compliance require affirmation that controls are being effectively operated.
Control assurance reporting is defined as the reporting of the actual status of a control's performance. This is fundamentally different from the risk and control assessment process discussed in Section 2.3.4, which is concerned with assessing and validating the risk and control environment. Control assurance is a core component of the risk management framework and is used to:
• Establish basic transparency and reporting obligations.
• Establish where 'control issues' occur and ensure that the relevant management actions are taken.
• Highlight insufficiently controlled areas.
• Highlight areas of 'control underperformance'.
• Provide detailed control reporting to various levels of management.
Control assurance is not necessarily undertaken by every area in the business; it is more noticeably present in the areas of the business that require assurance that controls are being effectively operated.
Control assurance is generally performed on a periodic basis, typically monthly or quarterly. Each business unit typically nominates someone to ensure that control assurance reporting is carried out. This does not mean that this is the only person who has controls to operate; rather this person ensures that all controls have been operated by the relevant person in the area for which he/she is responsible.
Business units, in conjunction with appropriate risk management personnel, should define all of the controls within their responsibility. From this, the shortlist of controls to be included in the control assurance process is developed. This shortlist should consider:
• The impact and likelihood of the risk mitigated by the control.
• The effectiveness and importance of the control.
• The frequency of the control operation.
• The regulatory relevance of the control.
• The cost/performance ratio of developing and implementing the control.
The OpR function monitors the control shortlists in conjunction with business units to ensure their appropriateness and adequacy.
Risk event capture is the process of collecting and analysing risk event data.
An operational risk event, as previously defined, can result in:
• An actual financial loss of a defined amount being incurred - a loss.
• An actual financial profit of a defined amount being incurred - a profit.
• A situation where no money was actually lost but could have been were it not for the operation of a control - a near miss.
• A situation where damage is caused to equipment and to people. When analysing risk events, it should be possible to identify:
• The controls which failed or the absence of controls that allowed the event to occur.
• The consequence of the event in terms of actual financial loss or profit.
• The correlations between risks - as a financial loss is often the result of more than one risk co-occurring.
Although collecting risk event data is in many cases an external regulatory requirement, it is also beneficial to an organization in that it:
• Provides an understanding of all risk events occurring across the organization.
• Provides quantifiable historical data which the organization can use as input into modelling tools.
• Promotes transparent and effective management of risk events and minimizes negative effects.
• Promotes root cause analysis which can be used to drive improvement actions.
• Reinforces accountability for managing risk within the business.
• Provides an independent source of information which can be used to challenge risk and control assessment data.
The degree of cooperation of front-line workers with the reporting requirements varies and is not uniform - not across industries and not even across a particular organization. As Adler-Milstein et al. (2009) show, workers are more likely to report operational failures that carry financial or legal risks.
2.3.4 Risk and control assessments
The management of risks and their associated controls is fundamental to successful risk management. Any risk and control assessment (RCA) process should be
structured and consistent to allow for the qualitative assessment of the validity of key business risks and their controls. This is fundamentally different from control assurance which is concerned with providing assurance that controls are being effectively operated.
RCA is a core component of the risk management framework and is used to:
• Identify the key risks to the business.
• Assess the risks in terms of their overall significance for the business based on the judgement of business management.
• Establish areas where control coverage is inadequate.
• Drive improvement actions for those risks which are assessed as outside agreed threshold limits for risk.
• Provide consistent information on the risk and control environment which can be aggregated and reported to senior management to better help in making more informed decisions.
RCA is performed in different areas of the organization, referred to as assessment points. These are identified by the relevant business unit owners. RCA is generally performed on a periodic basis, typically monthly or quarterly. The duration of each assessment is variable and will depend on the number of risks and controls to be assessed. Both business unit owners and members of the risk management team will be involved in each RCA.
RCA is normally a three-step process which allows the business to identify, assess and manage risk:
1. The identification step (which takes place outside of any system) results in a list of the key risks to be included in the assessment.
2. The assessment step allows the business to rank the risks identified in terms of significance to the business and assess the validity of their scoring. This step will include an approval of the assessment.
3. The management step is primarily involved with ensuring improvement actions raised as a result of risks being outside agreed limits are followed up and compiling reporting information.
One of the goals of this activity is to be able to predict the risks facing the organization, so that the priorities for handling them can be properly decided. That is, the goal is to be able to manage the operational risk and bring its size to that level which the organization can tolerate. It is not just about bookkeeping and clerical record keeping, done in order to demonstrate diligence. As Neil et al. (2005) note, 'Risk prediction is inextricably entwined with good management practice and [that] measurement of risk can meaningfully be done only if the effectiveness of risk and controls processes is regularly assessed.'
Key risk indicators, or KRIs, are metrics taken from the operations of a business unit, which are monitored closely in order to enable an immediate response by the risk managers to evolving risks. This concept of 'Key X indicators' is not new, nor is it particular to risk management. Its more familiar form is KPI, where P stands for Performance. The basic idea behind these two acronyms is quite similar. Indicators - for risk or for performance - may be quite numerous within a given enterprise. For an industrial firm risk indicators may include:
• Number of defective items produced - in each production line.
• Percentage of defective items produced - in each production line.
• Change - daily, weekly, monthly, etc. - in the number of defective items produced in each production line.
• Number of items returned as defective for each product (again, this may be expressed in numbers, percentages or monetary value).
• Number of maintenance calls for each production line - absolute or per unit of time.
• Number of accidents on the production lines.
• Number of unplanned stoppages of each production line.
For achieving comprehensive OpR in an enterprise, we add to the KPIs listed above operational risk indicators associated with other divisions of the enterprise - finance, marketing, human resources and computer operations. So, it is evident that the number of risk indicators in a given enterprise may be very large, thus making it very difficult to track, monitor and control. Therefore, a select few risk indicators are chosen to serve as a warning mechanism for the enterprise. These may be simple risk indicators like 'number of computer crashes in a week', or 'number of communication breakdowns in a day', or 'costs of unscheduled repairs incurred in the computer centre during a prescribed period of time'. Alternatively, they may be compound indicators, artificial in a sense, made up of direct risk indicators for a given area of activity to create a representative indicator for that activity in such a way that changes in this compound indicator will warn the risk management officer of approaching difficulties.
The KRIs are lagging or leading indicators of the risks facing the enterprise. The way to create them changes from one organization to another, and their construction expresses such attributes as the level of importance that the organization attaches to each of its activities, the regulatory climate under which the organization operates and the organization's appetite for risk. Consequently, two similar organizations serving the same markets may have quite different KRIs. The list of possible KRIs is so long - when compiled from all possible sources - that libraries of KRIs have been set up and some can only be accessed under a subscription agreement - see, for example, KRIL (2010). The actual
definition of a particular organization's KRIs requires usually a project targeted at this goal that is usually undertaken as part of an overall OpR approach. For more on KPIs and KRIs see Ograjensek and Kenett (2008) and Kenett and Baker (2010). A study by Gartner positioning OpR software products is available in McKibben and Furlonger (2008).
2.3.6 Issues and action management
The management of issues and their associated actions is fundamental to successful OpR. The issues and actions management process should provide a standardized mechanism for identifying, prioritizing, classifying, escalating and reporting issues throughout the company.
The collection of issues and actions information allows the business to adopt a proactive approach to OpR and allows for swift reactions to changes in the business environment.
Issues and actions management is a core component of the risk management framework and is used to:
• Support the evaluation of risk likelihood and control effectiveness during the RCA process.
• Highlight control failures or uncontrolled risks during the control assurance process.
• Highlight events resulting in significant financial loss. Guiding principles state that issues should generally originate from:
• Control improvements.
• Control weaknesses.
• Compliance gaps/concerns.
• Audit recommendations - both financial audit and risk audit.
• Risk event reports.
• Quality defects.
The issue management process should:
• Capture issues related to the RCA and control assurance processes, risk events, internal audits and compliance audits.
• Support the creation of issues on an ad hoc basis.
• Allow for the creation of actions and assign responsibilities and target completion dates for the same.
• Monitor the satisfactory completion of issues and actions.
• Provide reports to support the issue management and action planning process.
2.3.7 Risk mitigation
Risk mitigation is an action, consciously taken by management, to counteract, in advance, the effects on the business of risk events materializing. The risk mitigation strategies for operational risks fall into the same four general categories of risk mitigation used for managing risks of all types. These are:
• Avoid the risk.
• Accept the risk.
• Transfer the risk.
• Reduce the risk.
Avoiding the risk means not taking the action that may generate it. With operational risk, that means not performing the operation. Accepting the risk means that the organization, while well aware of the risk, decides to go ahead and perform the operation that may end in the risk event occurring, and to suffer the consequences of that occurrence. Transferring the risk may be accomplished by a number of methods. The most familiar one is to insure the business against the occurrence of that risk event. This way, the risk is transferred to the insurance company and a probabilistic loss event (the risk actually occurring and causing damage) is substituted by a deterministic, known loss - the insurance premium. Another way of transferring the risk is to subcontract the work that entails the risk, thereby causing some other business to assume the risk. Finally, reducing the risk means taking steps to lower either the probability of the risk event happening or the amount of damage that will be caused if it does occur. It is possible to act on these two distributions simultaneously, thereby achieving a lower overall risk.
Risk mitigation is an important part of risk management in general and operational risk is no exception. In some sense, the area of OpR that is restricted to the management of information and communications technology (ICT) operations has been concerned for quite some time with disaster recovery planning (DRP), which is a detailed plan for continued ICT operations in case a disastrous event happens. However, DRP deals with major disruptions of ICT operations in the enterprise, while risk management deals with all types of risks, large and small. Recently, this area of risk mitigation has been extended to the whole business and the area of business continuity management deals with the ways and means to keep a business going even after a major catastrophe strikes.
2.4 Operational risk statistical models
Operational risks are characterized by two statistical measures related to risk events: their severity and their frequency (Cruz, 2002). A common approach to model the frequency and the severity is to apply parametric probability distribution functions. For severity, the normal and lognormal distributions are often applied. Other distributions used to model the severity are: inverse normal, exponential, Weibull, gamma and beta. For details on these distributions see Kenett and Zacks (1998).
On the other hand, in order to model the frequency of specific operational risk events, two main classes are used: ordinary (Poisson, geometric, binomial) and zero-truncated distributions.
The most common goodness-of-fit test for determining if a certain distribution is appropriate for modelling the frequency of events in a specific data set is the chi-square test. The formal test for testing the choice made for a severity distribution is instead the Kolmogorov -Smirnov test and related measures of interest (see Kenett and Zacks, 1998).
Having estimated, separately, both the severity and the frequency distributions, in operational risk measurement we need to combine them into one aggregated loss distribution that allows us to predict operational losses with an appropriate degree of confidence. It is usually assumed that the random variables that describe severity and frequency are stochastically independent. Formally, the explicit formula of the distribution function of the aggregated losses, in most cases, is often not analytically explicit. One popular practical solution is to apply a Monte Carlo simulation (see Figure 2.1).
On the basis of the convolution obtained following a Monte Carlo simulation, operational risk measurement can be obtained as a summary measures, such as the 99.9th percentile of the annual loss distribution, also called value at risk (VaR). In operational risk the distribution of a financial loss is obtained by multiplying the frequency distribution by the severity distribution. These considerations motivate the use of the geometric mean of risk measures, when aggregating risks over different units. The use of the geometric mean is a necessary condition for preserving stochastic dominance when aggregating distribution functions.
Cause and effect models have also been used extensively in operational risk modelling. Specifically Bayesian methods, including Bayesian networks, have been proposed for modelling the linkage between events and their probabilities. For more on these methods see Alexander (2000, 2003), Giudici and Billota (2004), Cornalba and Giudici (2004), Bonafede and Giudici (2007), Fenton and Neil (2007), Ben Gal (2007), Dalla Valle et al. (2008), Figini et al. (2010), Kenett (2007) and Chapters 7 and 8 in this book. These and the next chapters include examples from the MUSING project (MUSING, 2006). The next section presents a short overview of classical operational risk measurement techniques.
Frequency Distribution
No. of Loss Events Per Year
Figure 2.1
Annual Loss Distribution
Expected!
99.9th Percentile
Annual Loss
Monte Carlo convolution of frequency and severity.
O TJ
re
H
I —
S
zn
£ g
Z
H £
O <
re §
re
2.5 Operational risk measurement techniques
In order to be able to assess and manage risk, it must be measured. It is impossible to manage anything that is not measured, risk being a prime example of this approach. In this section we introduce three operational risk measurement techniques: the loss distribution approach, scenario analysis and balanced scorecards.
2.5.1 The loss distribution approach
The loss distribution approach (LDA) is a measurement technique that is particularly suitable for banks and other financial institutions. It aims at calculating the VaR, which is a monetary value that these institutions need in order to assign adequate capital, as far as their regulators are concerned, against operational risk (see Figure 2.1). This expected value may be of lesser interest for businesses that have a different approach to risk, for example if they view small losses, bounded above by a periodically changeable limit, as either negligible or part of the cost of doing business. On the other hand, these businesses insure themselves against losses that surpass another dynamically changed amount and consequently implement mitigation strategies to handle only losses that fall between these two bounds. This optional mitigation strategy is not available to banks and many other financial institutions for they function, in effect, as their own insurers and therefore must have a more precise knowledge of the risks, not just some bounds and frequencies. As an example of this type of risk management behaviour one may look at supermarkets and large food sellers in general that have become accustomed, albeit unwillingly, to losses stemming from employee theft - a definite operational risk. Many consider this theft-produced loss a part of doing business as long as it does not rise above a certain level, determined individually by each chain or food store, and take out a specific policy with an insurance company against larger thefts.
The LDA, which is used extensively in calculating the capital requirements a financial institution has to meet to cover credit risks, is a statistically based method that estimates two functions involved with risk - the occurrence frequency and the loss amount frequency. From these two distributions, the distribution of the VaR may be computed. For financial institutions, the VaR has to be calculated for each business line (Basel II, 2006), and then a total VaR is calculated by summing the individual business line VaRs multiplied by their weight in the bank's outstanding credits. While this measuring method is complex to implement and requires extensive databases, some of them external to the bank, and is computationally intensive, there are a number of approaches for financial institutions to calculate it (see e.g. Frachot et al., 2001; Tapiero, 2004; Shevchenko, 2009). The effort and investments involved may be worthwhile only for large banks, since it can lead to a significantly smaller capital allocation for operational risk, thus freeing a highly valuable resource for the bank.
For operational risk in other types of business, such a very fine breakdown of events and their consequences may not be required, for a number of reasons.
First, the operational risk is seldom, if ever, related to a business line. Second, operational risk events are frequently the result of more than one causing factor in the wrong range and thus attributing the risk to one of them or distributing it among them will be highly imprecise, to say the least. Third, the costs of implementing such a measurement system may prove prohibitive for a business that is capable of getting insurance against these losses for a small fraction of that cost. A method similar to the LDA is demonstrated for a process that is part of OpR in banks in Chapter 10 describing the near miss/opportunity loss in banks.
2.5.2 Scenarios
Scenarios are used in many areas where the prospects of having accurate predictions are slim or where there are no analytical tools available to produce such predictions at all. They are frequently used for strategic planning in order to discover, as realistically as feasible, what would be a suitable reaction by the business to a wide range of possible developments of many variables that affect the business, in various combinations. Scenarios range from an extension of current reality into the foreseeable future to extreme changes in the business's environment, status, capabilities and associations. Scenarios are used in operational risk measurement in a number of cases. The first case involves an organization that wishes to engage in OpR, but lacks the requisite risk event repository from which to calculate - or even simply summarize - the results of the various risks. That is the most usual case, and it is frequently used because it takes a long time from the initiation of a risk management activity to the time when the organization has a workable repository with enough risk events that materialized. Thus, organizations use the scenario technique in order to shorten the time to the implementation of a risk management approach with the proper mitigation strategies. The second case involves a significant change in the environment that the business operates in. Usually it is a change in the external environment: new regulatory demands, radically changed economic environment, new technologies being brought rapidly to bear on the economic segment the business operates in, and so on. Occasionally, it may be a drastic reorganization of the business, such as a merger of different units into a single one, or a merger with another business or an acquisition of a business and the attempt to assimilate it successfully into the business.
The scenarios technique involves a team, familiar with the business processes being studied, devising possible business scenarios - and trying to see what the reaction of the business might be, and what might go wrong. Doing this systematically, step by step, and covering all possible areas (technology, people, processes, etc.) that might be affected by the scenario, results in a list of potential risk events that are latent within the business process under study. This method is then applied to every business process used in the business until a complete list of latent risk events is compiled. This list is then analysed, categorized and stored as a virtual risk event repository. Then, a measure may be computed for
variables that are of interest, including the VaR involved with each risk event. If some data is available that describes the frequency of executing a particular business process, estimates of expected losses can be computed. Mitigation strategies are then devised for each risk event, and the implementation of OpR continues from this point onward.
The benefits of this technique are:
1. It is not dependent on an existing repository of risk events.
2. Even if a risk event repository exists in the business, this technique may prepare the business for risk events that have not yet been registered in the repository - for the simple reason that they had not occurred or that they had occurred prior to the repository being established - but these risks are nevertheless worth considering and preparing mitigation strategies for them.
3. It may be done in a relatively short period of time, eliminating the need for waiting for a significant accumulation of risk events in the risk repository.
4. It may be used in addition to using the risk repository. The drawbacks of this technique are:
1. It is based on a complete mapping of all business processes in the business. Leaving out a few business processes may make the whole effort not useful since significant portions of the business activity may be left uncovered.
2. It usually requires a large team. The team usually includes people from the risk management office, from the industrial engineering unit and from the operation of the business itself. The core people, like the risk managers and the industrial engineers, may form the central, fixed part of the team, but the people familiar with the various business processes will have to change with each area of activity covered.
3. Lacking any significant history of risk events, it requires a very determined management to undertake such an extensive and expensive activity.
All things considered, it is a good technique, though usually the lack of complete mapping of all business processes prevents it from being very effective. On the other hand, this mapping - a requisite for this technique - may be a very substantial side benefit of this operation and, indeed, it may be a sufficient benefit in and of itself so as to justify the whole process.
2.5.3 Balanced scorecards
Scorecards were made famous in the business world by Norton and Kaplan in the early 1990s (Kaplan and Norton, 1992, 1993, 1996; see also Organjensek and Kenett, 2008). Since that time, the notion has caught on and today the balanced scorecard (BSC) is widely used in businesses in all disciplines. For an application
to organizations developing systems and software see Kenett and Baker (2010). In short, the basic concept of the scorecards is, as the name implies, to compute a score for the measured phenomena and to act upon its changing values. The concept of an operational risk scorecard is the same as that of the general scorecard, except that in this case it is much more specialized and concerns only operational risks in the business. Whereas in the classic BSC the scores represent the performance in the financial, customer, internal processes and learning and growth facets of the business (although many variations exist), in the operational risk scorecard the measured aspects may be technology, human factors and external factors affecting the business operations. This division is by no means unique, and many other divisions may be used. For example, a bank trying to comply fully with the Basel II recommendations may concentrate more heavily on the ICT part of the operations when handling operational risk, and subdivide this score into finer categories - hardware, software, communications, security and interface. Similar subdivisions may be tried out in other areas representing operational risk.
When the complete classification and categorization of all operational risks are completed, weights are assigned to the elements within each category and then a risk score may be computed for each category by providing the values of the individual risks of the elements. The resulting score must be updated frequently to be of value to the organization.
As a final note, it is worthwhile to consider a combined risk indicator, composed of the individual risk categories managed by the organization, which is added to its overall scorecard, thus providing management not only with performance indicators in the classic BSC, but also with an indication of the risk level at which the organization is operating while achieving the business-related indicators.
2.6 Summary
This chapter introduces the basic building blocks of operational risk management, starting from the basic definition of operational risk, through the steps of identifying, classifying, controlling and managing risks. The following chapters, organized in three parts, provide an in-depth analysis of the various ways and means by which operational risk are handled. We briefly describe these three parts.
Part II: Data for Operational Risk Management and its Handling
Operational risk management relies on diverse data sources, and the handling and management of this data requires novel approaches, methods and implementations. This part is devoted to these concepts and their practical applications. The applications are based on case studies that provide practical, real examples
for the practitioners of operational risk management. The chapters included in Part II are:
Chapter 3 Chapter 4 Chapter 5 Chapter 6
Ontology-based modelling and reasoning in operational risks Semantic analysis of textual input A case study of ETL for operational risks Risk-based testing of web services
Part III: Operational Risks Analytics
The data described in Part II requires specialized analytics in order to become information and in order for that information to be turned, in a subsequent phase of its analysis, into knowledge. These analytical methods are described in the following chapters:
Chapter 7: Scoring models for operational risks
Chapter 8: Bayesian merging and calibration for operational risks
Chapter 9: Measures of association applied to operational risks
Part IV: Operational Risk Management Applications and Integration with other Disciplines
Operational risk management is not a stand-alone management discipline. This part of the book demonstrates how operational risk management relates to other management issues and intelligent regulatory compliance. The chapters in this part consist of:
Chapter 10:
Chapter 11 Chapter 12 Chapter 13 Chapter 14
Operational risk management beyond AMA: new ways to
quantify non-recorded losses Combining operational risks in financial risk assessment scores Intelligent regulatory compliance Democratization of enterprise risk management Operational risks, quality, accidents and incidents
The book presents state-of-the-art methods and technology and concrete implementation examples. Our main objective is to push forward the operational risk management envelope in order to improve the handling and prevention of risks. We hope that this work will contribute, in some way, to organizations which are motivated to improve their operational risk management practices and methods with modern technology. The potential benefits of such improvements are immense.
References
Adler-Milstein, J., Singer, S.J. and Toffel, M.W. (2009) Operational Failures and Problem Solving: An Empirical Study of Incident Reporting, Harvard Business School Technology and Operations Management Unit, Working Paper No. 10-017. http://ssrn.com/abstract=1462730 (accessed 21 May 2010).
Adusei-Poku, K. (2005) Operational Risk Management - Implementing a Bayesian Network for Foreign Exchange and Money Market Settlement, PhD dissertation, Faculty of Economics and Business Administration of the University of Gottingen.
Alexander, C. (2000) Bayesian Methods for Measuring Operational Risk, http://ssrn.com /abstract=248148 (accessed 21 May 2010).
Alexander, C. (2003) Operational Risk: Regulation, Analysis and Management , Financial Times/Prentice Hall, London.
Basel Committee on Banking Supervision (2006) Basel II: International Convergence of Capital Measurement and Capital Standards: A Revised Framework - Comprehensive Version. http://www.bis.org/publ/bcbs128.htm (accessed 21 May 2010).
Ben Gal, I. (2007) Bayesian Networks, in Encyclopaedia of Statistics in Quality and Reliability, ed. F. Ruggeri, R.S. Kenett and F. Faltin, John Wiley & Sons, Ltd, Chichester.
Bonafede, E.C. and Giudici, P. (2007) Bayesian Networks for Enterprise Risk Assessment, Physica A, 382, 1, pp. 22-28.
Cornalba, C. and Giudici, P. (2004) Statistical Models for Operational Risk Management, Physica A, 338, pp. 166-172.
Cruz, M. (2002) Modeling, Measuring and Hedging Operational Risk, John Wiley & Sons, Ltd, Chichester.
Dalla Valle, L., Fantazzini, D. and Giudici, P. (2008) Copulae and Operational Risk, International Journal of Risk Assessment and Management , 9, 3, pp. 238-257.
Doebli, B., Leippold, M. and Vanini, P. (2003) From Operational Risk to Operational Excellence, http://ssrn.com/abstract=413720 (accessed 11 January 2010).
Fenton, N. and Neil, M. (2007) Managing Risk in the Modern World: Applications of Bayesian Networks , London Mathematical Society, London.
Figini, S., Kenett, R.S. and Salini, S. (2010) Integrating Operational and Financial Risk Assessments, Quality and Reliability Engineering International , http://services.bepress.com/unimi/statistics/art48 (accessed 6 March 2010).
Frachot, A., Georges, P. and Roncalli, T. (2001) Loss Distribution Approach for Operational Risk and Unexpected Operational Losses, http://ssrn.com/abstract=1032523 (accessed 21 May 2010).
Giudici, P. and Bilotta, A. (2004) Modelling Operational Losses: a Bayesian Approach, Quality and Reliability Engineering International , 20, pp. 407-417.
ICH (2006) The International Conference on Harmonization of Technical Requirements for Registration of Pharmaceuticals for Human Use, Guidance for Industry: Q9 Quality Risk Management , http://www.fda.gov/RegulatoryInformation /Guidances/ucm128050.htm (accessed 6 March 2009).
International Association of Financial Engineers (2010) http://www.iafe.org/html/cms_ orc.php (accessed 8 March 2010).
ISO GUIDE 73 (2009) Risk management - Vocabulary.
Kaplan, R.S. and Norton, D.P. (1992) The Balanced Scorecard - Measures that Drive Performance, Harvard Business Review , 70, 1, pp. 71-79.
Kaplan, R.S. and Norton, D.P. (1993) Putting the Balanced Scorecard to Work, Harvard Business Review , 71, 5, pp. 134-142.
Kaplan, R.S. and Norton, D.P. (1996) The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, Boston, MA.
Kenett, R.S. (2007) Cause and Effect Diagrams, in Encyclopaedia of Statistics in Quality and Reliability , ed. F. Ruggeri, R.S. Kenett and F. Faltin, John Wiley & Sons, Ltd, 2007.
Kenett, R.S. and Baker, E. (2010) Process Improvement and CMMI for Systems and Soft- ware: Planning, Implementation, and Management , Taylor & Francis Group, Auerbach Publications, Boca Raton, FL.
Kenett, R.S. and Zacks, S. (1998) Modern Industrial Statistics: Design and Control of Quality and Reliability , Duxbury Press, San Francisco.
KRIL (2010) The KRI Library, http://www.kriex.org/ (accessed 7 February 2010). McKibben, D.
and Furlonger, D. (2008) Magic Quadrant for Operational Risk Management Software for Financial Services, Gartner Industry, Research Note G00157289.
MUSING (2006) IST- FP6 27097, http://www.musing.eu (accessed 21 May 2010).
Neil, M., Fenton, N. and Tailor, M. (2005) Using Bayesian Networks to Model Expected and Unexpected Operational Losses, Risk Analysis Journal , 25, pp. 963 -972.
Ograjensek, I. and Kenett, R.S. (2008) Management Statistics, in Statistical Practice in
Business and Industry , ed. S. Coleman et al., John Wiley & Sons, Ltd, Chichester. Shevchenko, P.V. (2009) Implementing Loss Distribution Approach for Operational Risk, Applied Stochastic Models in Business and Industry , DOI: 10.1002/asmb.811.
Solvency II (2009) http://www.solvency-2.com/ (accessed 21 May 2010).
Sunday Times (2010) Lehman's $50 Billion Conjuring Trick: A report into the Ameri- can bank's collapse reveals financial chicanery and negligent management, March 14. Quoted from http://www.blacklistednews.com/news-7798-0-24-24-.html (accessed 21 May 2010).
Tapiero, C. (2004) Risk and Financial Management: Mathematical and Computational Methods , John Wiley & Sons, Inc., Hoboken, NJ.
The Foreign Exchange Committee (2004) Management of Risk Operational in For- eign Exchange, Risk Analysis , 25, 4, http://www.ny.frb.org/fxc/2004/fxc041105b.pdf (accessed 7 March 2010).
