Implementing a practical ORM system in the context of ERM in an era of financial & regulatory convergence via business

process governance

Guan Seng Khoo, PhD

Abstract

This article aims to address some of the issues and challenges faced by organizations and the respective project managers in implementing an Enterprise-wide Operational Risk Management (ORM) system. While non-technical, it focuses more on the generic and qualitative aspects of the implementation and how these can be understood. Every organization is different and has its own priorities with respect to the risks it faces and the impact they will have. However, the greatest challenge has always been the internal environment and the “silo” mindset of the organization, with different groups having their own agenda and priorities. The article proposes some strategies to help overcome the challenges posed by this type of organizational culture and how business process governance can be utilized in effective operational risk management, in conjunction with the organization’s own risk appetite and tolerance.

Sections

1. Introduction 2. ERM from a Risk-Return Perspective 3. ORM Implementation: Identifying the top risks of your organization 4. Developing an appropriate ORM framework and system 5. The Structure to Governing Risk 6. Business Process Governance & ORM 7. Operational KRIs in the ORM framework – Linkage to Risk Appetite 8. Concluding remarks

1. Introduction - Excerpts from the Wall Street Journal

Nearly six years ago, warning lights began flashing at Citigroup Inc.'s Japanese private bank. Koichiro Kitade, a marketing whiz who headed the office, was roping in hundreds of wealthy new clients. But he had a tin ear for regulation. In August 2001, Japan's Financial Services Agency flagged his group for infractions, including selling securities without prior authorization. Following a settlement, Citigroup dispatched Charles Whitehead, an American lawyer with Japanese experience, to serve as "country officer" in Japan. Regulators were told that Mr. Whitehead would share responsibility for compliance and control in all Citigroup's business units in Japan, from retail banking to corporate finance.

But Messrs. Whitehead and Kitade, who reported to different bosses in New York, clashed badly. And once again, the private bank spun out of control. By late 2003, Japanese regulators had found problems throughout the unit, and Citigroup's efforts to mollify them spiraled into disarray. Internal bickering about who should talk to regulators, and what they should say, reached top executives in Citigroup's Park Avenue headquarters. In September 2004, fed-up regulators yanked Citigroup's private-banking license altogether -- a stinging humiliation for Chief Executive Charles Prince, who flew to Tokyo and bowed low in apology.

"It was a train wreck in slow motion," said Mr. Prince. The scandal was a humbling lesson for the world's largest financial-services firm. Engineered through a series of massive deals by Wall Street titan Sanford Weill, Citigroup has achieved enormous profits through its size and global reach. But his successor, Mr. Prince, is discovering how hard it can be to control risk in an organization of more than 275,000 employees in 100 nations, where a small deal done badly can cause huge reputational damage.

A preliminary report on the Japan debacle, commissioned by Citigroup and prepared by former U.S. Comptroller of the Currency Eugene Ludwig, suggests the problem was systemic. "Quite simply, this is a situation characterized by a multitude of failure points within the organization," said the confidential report, portions of which The Wall Street Journal reviewed.

Citigroup's private bank debacle in Japan is only one of many that the business community has witnessed in recent years that have resulted in considerable financial loss, decreased shareholder value, damaged company reputations, and in many cases the destruction or discontinuity of the business, as in Citigroup Private-Bank’s case in Japan. Even today, the financial market is still plagued with uncertainties, threats, fraud and scandal cases which wreak havoc on the companies and markets concerned and the industry as a whole. These cases, particularly in the case of fraud, are considered to be just the tip of the iceberg as many smaller cases never reach the public domain for fear of the negative publicity. Other types of risks lie latent till they manifest as a result of poor management, poor corporate governance, poor planning, incompetence and a lack of anticipation. Risk though, is an integral part of any corporate business. While most companies do not seek to avoid risk, they do try to understand it properly, manage it effectively and evaluate it in the context of the reward that is being earned.

With the backdrop above in mind, this chapter aims to expose the reader to a new model in operational risk management, underpinned by a sound business process governance, that goes beyond mere “control” to contribute measurable business value in the context of an enterprise-wide risk management (ERM) framework. The emphasis is on producing high-quality earnings that are sustainable and will ultimately attract a premium rating for the companies and protect the interests of shareholders, depositors, employees and all other stakeholders. In addition, the model and framework have to be flexible enough to ensure that the organization remains relevant by being agile and adaptable in today’s dynamic and changing environment. In short, operational risk management (ORM) as an integral part of enterprise-wide risk management (ERM), creates a new culture of risk awareness under which the management of risks becomes an integrated and coordinated process across the entire organization. This chapter will explore the key roles and concepts in enterprise risk management, assess risks stemming from globalization, interdependence, technological and marketplace change, political and socio-economic uncertainty, natural or other disasters and examine new risk measurement and monitoring tools such as scenario analysis, gain/loss curves, key risk and control indicators (KRIs, KCIs) and value-at-risk (VAR) methodologies in operational risk management. This is achieved through innovation, excellent client service and a sound Enterprise-wide Risk Management (ERM) framework. The flow of the chapter is summarized as follows. The next section will set the tone in terms of the Basel Accord classification of loss event types and their relationship to the risk-return perspective from an enterprise viewpoint. Section 3 will examine how the top risks of the organization can be evaluated as part of the operational risk management (ORM) implementation, including how the risks can be prioritized and addressed. Section 4 will look at the challenges and how they can be overcome in order to implement an appropriate ORM system. These issues will include tackling the silo mindset prevalent in a lot of organizations and getting the buy-in from the board and colleagues from all levels of the organizational hierarchy during the implementation. Section 5 aims to provide the core fundamentals underpinning a sound risk management structure and will include a discussion on the pre-requisites for successful management, including issues related to human resource, technology, the corporate culture and the business processes involved. This will be followed by a more elaborate discussion on business process governance in the context of ORM in Section 6 and its relationship to the generation of KRIs and KCIs within the backdrop of the organization’s risk appetite and tolerance in Section 7, followed by some concluding remarks in Section 8.

2. ERM from a Risk-Return Perspective Fig. 1 below illustrates the general definitions of operational risk loss events by types and examples under the Basel Accord. As can be seen, the coverage is wide and the examples widespread enough to encompass practically any event that may affect the institution enterprise-wide.

Operational Risk Loss Events: Types, Examples

• Most banks have begun collecting operational risk loss data generally adaptable to Basel guidelines:

Discretionary losses

External fraud

Financing losses

Insurance claims

Internal fraud

Legal settlements

Policy violations

Processing losses

Trading losses

Unauthorized activities

Transaction and business

processes

Technology

Sales practices

Physical loss damage

Personnel/HR losses

Management processes

Natural Disasters

External effects

Potential Loss Events

Execution, Delivery and Process Management

Business Disruption and System Failures

Damage and Physical Assets

Clients, Products, and Business Services

Employment Practices and

Workplace Safety

External Fraud

Internal Fraud

Basel Level 1

Event Types

Fig. 1 Op Risk Loss Events Typically, the loss events might be internally or externally driven. Can you think of some loss events which are internally-derived? Now, compare them to some potential events which are a result of external events. As you can guess, the processes and information involved are far more complex and they require more insightful awareness and understanding of what operational risk management entails other than the quantification, what more in an era with numerous rules and regulations! One way to illustrate the complexity above is to consider the challenges faced by an organization, say a listed company running a budget airline. Fig. 2 below depicts some of the possible risk scenarios and inter-dependencies and how they are inter-linked in an enterprise-wide view. It is almost impossible to look at risk today with a silo-based mindset and hard to envision that something as far away as a rise in spot oil price on NYMEX, a commodity exchange, might potentially lead to a higher turnover in staff with

expertise in say, IAS/IFRS accounting standards or hedge effectiveness testing, as such expertise is a scarce resource and in demand globally.

Economic

Slowdown,Credit crunch

Credit risk

HedgingRegulatory/

Operational/Market risk

Staff turnoverHR operational

risk

Earnings volatilityReputation risk

HighOil PriceStrategicBusiness/

Market Risk

Fig. 2 Inter-dependencies of risk events on an enterprise-wide basis Such potential risk events, while posing threats and uncertainties, also present opportunities if they are anticipated and identified earlier and measures put in place to address them in case they manifest. Airlines which hedged their fuel costs a year ago did better than those which did not anticipate the oil price hike. Such actions enhance their reputation and brands, in turn increasing their businesses and revenue. Hence, the risk-reward considerations of operational risk management (ORM) and consequently, enterprise risk management (ERM) should be viewed in terms of three dimensions, namely, as threats, uncertainties and opportunities as shown in Fig. 3. Obviously from this perspective, a pro-active approach is required with the following considerations. That is, every risk event can potentially lead to an “upside” return, status quo or “downside” loss and hence, ERM isn’t just about negative risk containment or avoidance, but, also about strategizing to leverage on the risk awareness and activities to enhance returns, so as to ensure the corporation’s growth and business continuity and to outperform the average.

ERM from a RiskERM from a Risk--Return Return

Perspective: Perspective: ValueValue--forfor--MoneyMoney

• Risk-Return considerations: 3-D

Threat,

e.g., high oil prices, terrorism, etc.

Uncertainty,

e.g. impact of regulatory changes, fraudulent activity occurrence, etc.

Opportunity,

e.g., cut down on fraud, enhance reputation and market growth, etc.

⇒ Pro-active risk mgt

instead of being reactive

Fig. 3 ERM in a 3-Dimensional Perspective It is the maintenance of this fine balance between risk and returns by viewing them from these three perspectives that might potentially lead to business growth and sustainability in this era of dynamic and fast-changing business environment. 3. ORM Implementation

I. Identifying the top risks of your organization In order to identify and prioritize the top risks, we need to first assess, measure or quantify them. We could use an ERM matrix based on global best practices and accepted principles or look for guidance from experts (internal or external). On top of that, it would be appropriate to categorize all possible risks and stakeholders, and localize the risk concentrations and further analyze these risks based on the probability and impact at different levels and hierarchy of the organization. In summary, all these are tied to understanding your risk, your goals, and your priorities. In the context of ORM implementation, there are several critical issues that have to be considered. Firstly, you have to remember the KISS (Keep It Simple, Stupid) principle. Underlying this principle is to speak the same language about risk so that there is no ambiguity and miscommunication.

Interest Rate Risk

Liquidity Risk

Price Risk

Foreign Exchange Risk

Transaction Risk

Compliance Risk

Strategic Risk

Reputation Risk

Credit Risk

Market Risk

Liquidity Risk

Operational Risk

Legal Risk

Reputational Risk

Credit Risk

OCC Risk Categories Fed Risk Categories

Establishing ERM Risk Categories Defined by the Regulatory Establishing ERM Risk Categories Defined by the Regulatory

AgenciesAgencies

* Stick to prescribed regulatory definitions, removes ambiguity, don’t re-invent

* For BOD, senior management – ease of understanding & buy-in

Fig. 4 Speaking the Same Risk Language One approach is to stick to prescribed regulatory definitions as shown in Fig. 4 above. The categories above can be considered to encompass all the types of risks faced by an organization, and when presented to say, the upper management, senior executives or boards of directors, the buy-in process and ease of understanding are enhanced for better and effective ORM implementation.

II. Organization’s Risk Appetite & Tolerance Secondly, it is important to consider the organization’s risk appetite and tolerance. Based on the risk appetite and the adopted ERM matrix, e.g. the COSO-ERM Framework (see Fig. 5 below), we can concentrate on the core risks that the organization must either accept or prevent from occurring, must lessen in terms of their impact if they occur, or mitigate by transferring the risk away from the key tasks. In the COSO-ERM Framework, the same generic components of a risk framework – the internal environment, the objective setting, the event identification, the risk assessment, the risk response, the control activities, the ‘information & communication’ component and the risk monitoring process – are consistently applied across the whole organization, at different business units or departments or at different hierarchical levels of the organization, including subsidiaries. Four areas of activities are evaluated based on these same eight components, namely, strategic initiatives, operations, the reporting and compliance activities.

Under the risk response category, several options based on the organization’s risk appetite and tolerance can be considered. They are: • to accept the risk, i.e., do nothing as the organization is willing to take on

risk • to avoid the risk, i.e., the organization has a back-out strategy and

disengages from the process leading to risk • to share the risk, i.e., shift some of risk to external parties, e.g., by

outsourcing, syndication, or establishing joint venture • to mitigate or transfer the risk, i.e., design processes to reduce risk

exposures, say through insurance or implement risk transfer techniques, e.g., via insurance-linked securitization

The COSO-ERM Framework

Can view in context of 4 categories

Considers activities at all

levels of

enterprise

8 components to ERM

Fig. 5 The COSO-ERM Framework From the context of AMA modeling and quantification in the Basel Accord, the use of insurance as a risk mitigant is permitted. Unfortunately, the practices for incorporating insurance as a risk mitigant into its capital model are still evolving and few banks have incorporated the 20% insurance offset within its model.

III. Risk Prioritization – Likelihood and Impact In terms of prioritization, each risk is then analyzed by assigning it weighting factors such as those shown in the following matrix in Fig. 6. This matrix weighs the probability of a risky event: the risk that it will occur only once (Low, Medium, High) as well as the risk that it will occur multiple times (Low, Medium, High).

The matrix also weighs the impact, should the event occur: the impact on a single department or product (Noticeable, Moderate, High) as well as the impact on the entire company or division (Noticeable, Moderate, High). The total risk of an event is therefore a byproduct of the probability and impact. This step gives us an objective approach to prioritizing risk and as to how the risk can be managed.

Prioritizing in terms of e.g.:

- Exposure loss

- Cost of recovery

- Reputation

- etc.

Fig. 6 Risk Prioritization Several parameters can then be used as benchmarks for prioritization of risk exposures, namely, the exposure loss or indicator (or EL/EI), the cost of recovery (or conversely, LGE) and reputation risk, for example.

4. Developing an appropriate and practical ORM framework & system To develop an appropriate and practical ORM system, the internal environment of the organization needs to be considered carefully. It poses several challenges as you may need to get the buy-in from all levels of the organization’s hierarchy and adopt a mindset change management in the process. This is because to achieve reasonable success, the organization has to move from a silo-based to an enterprise-wide holistic view of operational risk management and at the same time, from a rules-based to a performance-based environment. Below, I outline some suggestions to overcome these challenges: SAP (Show A Preview), e.g., show a possible outcome, KISS (Keep It Simple, Stupid), e.g., speak the same, simple language, CLICK (Creative Leadership with Insight, Commitment & Know-how), i.e., provide creative leadership & strong guidance with conviction & know-how.

I. SAP

No matter how global or sophisticated your organization is, when you are embarking on an ORM implementation, engagement is the key to gaining the buy-in from all levels of the organizational hierarchy – easier said than done though! One approach is to illustrate to the key personnel at all levels a prototype model of what they are going to get and how they can benefit from it (the preview). The prototype can first be developed in-house by a project team that will eventually lead and drive the implementation program. Alternatively, it could be based on an existing solution or system being used by other organizations ahead of the implementation curve, which the project team has access to. This initial effort in prototyping an interim system or model that can be shown to senior management or directors in the form of an ORM cockpit or dashboard (ala movie poster) brings a lot of benefits to the subsequent deployment and implementation of the ORM system – see Fig. 7 below.

E xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ankE xam p le : A B C B ank

KRI/KRI/KCIsKCIs & & KPIsKPIs

RiskIndicators

Op Expense

NPL &

LLP

Assetturnover

PerformingIndicators

Debt to Asset

Rate of ROE

RAROC

Near Misses

- Lack of products

- Lack of expertise

- Slow response time

- No targeted market

- Lack of risk-

based pricing

Losses

- Internal Fraud- Market Share

- Share price of

parent

- etc.

RiskAssessment

- Focus on

business process

improvements

- Enhance internal

controls (checks & balances)

- etc.

Fig. 7 Op Risk Dashboard Firstly, much of the effort to produce the prototype will help the project team in establishing a foundation to support the creation of an ORM manual that will serve as the reference point for the establishment of management policies, procedures, and practices governing the initiation, definition, design, development, deployment, operation, maintenance, enhancement, and retirement of the ORM system.

Secondly, the preview of the ultimate ORM system provides visibility and transparency to the whole exercise, enhancing the confidence of the directors and senior management as it also provides an opportunity for them to have a first “taste” (encounter) of the final solution. More importantly, it also provides an avenue for them to be a critic, so that they can provide constructive feedback regarding the strengths and weaknesses of the interim system, which ultimately will be used by them – indirectly, they also become the stakeholders of the ORM implementation project based on their feedback and inputs. Thirdly, the preview allows for the identification and validation of an opportunity to improve business accomplishments of the organization or a deficiency related to the ORM project specification, identification of significant assumptions and constraints on solutions to that need, and recommendation for the exploration of alternative concepts and methods to satisfy the need.

II. KISS

Another key consideration is simplicity. The final ORM system should be easy to use and:

- emphasize user friendliness over ease of technical design and application software development

- stick to prescribed terminologies understood by all, e.g., establishing ORM Risk Categories that have already been defined by the Regulatory Agencies, in order to reduce ambiguity among the stakeholders and users of the ORM (see Fig. 4)

- ensure data sufficiency in terms of the meta-data requirements and infrastructure for optimal ORM

- provide easier, secure, reliable access to data based on an integration-centric approach

- tailor management information reports to customer needs

- provide automated tools to facilitate end user access to and use of data

- provide readily available help within the application software and provide for computer based training modules

- reduce the reliance on paper

- provide easier, secure access and management to electronic records

While the ORM system could be quite granular in terms of the depth of information to be retrieved and displayed, the project team should always bear in mind that at the senior management and directors’ level, the big picture is more critical. Hence, the ORM should allow for customization and access along the different levels of usage across the organizational hierarchy so that line managers, auditors and directors can access the same repository of information but view the information differently according to their needs and functional roles – i.e., different access rights can be put in place via digital rights management.

Operational Risk Loss Events: Types, Examples

• Degree of granularity of op risk loss measures will ascertain depth of ORM expertise & scope of data infrastructure readiness as well as op risk transfer

Discretionary losses

External fraud

Financing losses

Insurance claims

Internal fraud

Legal settlements

Policy violations

Processing losses

Trading losses

Unauthorized activities

Transaction and business processes

Technology

Sales practices

Physical loss damage

Personnel/HR losses

Management processes

Natural Disasters

External effects

Potential Loss Events

Example – AMA (IMA)

Approach: Generate estimates of op risk

capital based on measures of expected

op risk losses, i.e., the approach

assumes a fixed & stable relationship

between expected losses (mean of the

loss distribution) and unexpected losses

(tail of loss distribution)

Parameters:

EL = Expected Loss of Business line i

and event type j

EI = Exposure Indicator

PE = Probability of Event

LGE = Loss Given Event

CM = Capital Multiplier

Capitali,j = ELi,j X CMi,j = EI x PE x LGE x

CMi,j

Fig. 8 Basel 2 Op Risk Loss Event Types & Categories In an era of regulatory convergence, whether it is SOX, Basel II, International Accounting Standards (IAS), etc., integrating information in support of compliance and business growth is not a one-off proposition. Compliance requires ongoing and constant enforcement and it’s never a matter of simply checking a box and then moving to another project. Compliance-driven requirements are usually phased in, evolve constantly, and invariably become more complex and stringent over time. An integration-centric approach enhances the flexibility, and thus the value, of such an architecture because you can design the data integration capabilities necessary to meet whatever happens regulation-wise and business-wise. With this data integration-centric approach, you would have a supple, adaptable and (over time) familiar framework for integrating new data and types of data in new ways. In contrast, a non-integration-centric approach means having to recollect data for each new compliance and business mandate that comes along. Also, just like credit risk management with PD, LGD, etc., operational risk management requires judicious use of data to evaluate analogous key parameters like probability of event (PE), LGE and so on as shown in Fig. 8 above. Moreover, an integration-centric approach allows institutions to standardize their risk language in terms of the underlying Basel 2 risk-compliance

categories or items and the overlapping risk parameters in the context of associated regulations (SOX, IAS, etc.) – see Fig. 9 below. Such a flexible and “aggregatable” framework, coupled with the convergence in categorization, yields a lot of benefits and cost-effectiveness. Ultimately, the integration-centric model lends itself readily for future refinement and scalability in infrastructure needs and growth.

Etc.External

Fraud

External

Events

Hacking,

Phishing

Etc.

Business

Disruptions &

system Failures

Systems

Disclosure,

Fiduciary,

Improper

Business

Practices

Etc.

Client,

Products &

Business

Practices

Transaction

Capture,

Execution,

Monitoring & Reporting

Etc.

Execution,

Delivery &

Process Mgt

Process

Etc.Employment Practices &

Workplace

Safety

Unauthorized

Activity,

Theft & Fraud

Etc.

Internal ActsPeople

Risk

Event level 2Event Type

Level 1

Risk

Category

SOX Risk

Misstatement

of Client Fees

Common Risk

Basel II – Clients,

Products & Business

Practices

Internal Audit Risk

Firm enters into a

business relationship

with inappropriate parties

or does not accurately profile the client

Compliance Risk

Firm opens accts with

persons intending to

launder money and does

not detect, report or record

suspicious activities by its

customers

Operational Risk

Failure to follow firm’s

policies & procedures

Illustration: Implementing a Common Risk Illustration: Implementing a Common Risk

Language that is Flexible & Language that is Flexible & ““AggregatableAggregatable””

IAS Risk

Overstatement

of Hedge

Effectiveness,

Fair Value Measurement

Fig. 9 Model & Data Integration-Centric Approach III. CLICK

No matter how good the planning, budgeting and resource provisioning are, if the ORM implementation is performed by the “blind leading the blind”, e.g., buying off-the-shelf system and models, and with a lack of conviction and commitment, the final outcome would still yield a white elephant. Risk management must be applied to all phases throughout the life cycle of the implementation. Risk, as used in project management, is associated with a lack of resources, information, and/or control. It is important to distinguish risk management from "problem management" in that risk management is concerned with situations that may or may not occur, whereas problem management is concerned with known difficulties that are a result of a risk having occurred. An analysis of risk and any strategy adopted to control risk should at least consider the effect of one or more of three factors: lack of resources (such as personnel or funding); lack of information (for example, completeness and confidence); or lack of control over the decision-making process (such as external project decisions affecting the project plans and assumptions).

Applying risk management to the ORM production or infrastructure system stage includes considering backup and recovery in service level agreements and plans. Management responsibility for a risk must be assigned to individuals and units that can affect the risk's root causes. The Project Manager shall be responsible for managing project risks over which the Project Manager can exert direct control. Risks that affect the project, but are not under project control, shall be explicitly assigned to either the Program Sponsor or the CRO, as appropriate. Situations external to the project that could be sources of risk to the project shall be coordinated through the Project Manager. Risk shall be a consideration in a Review Board and management decisions. Project risk situations, plans, and progress against risks must be considered at all project reviews. Strong guidance must come from the Program Sponsor, Project Manager and Team so that the ORM implementation is carried out with a clear view of the objective and an insightful understanding of what it hopes to achieve. Coupled with the commitment of the team and management with the backing of the whole enterprise, and the strong political will of the stewards and stakeholders of the ORM project, the likelihood of a successful implementation will be enhanced.

5. The Structure to Governing Risk: ORM Fundamentals In incorporating a structure to govern risk, there are four critical elements to consider, namely, the people, the process, the technology and last but not least, the corporate culture. We will not discuss the corporate culture in this chapter, but will focus on the process aspect. One challenge is not having the human resource expertise in terms of depth and breadth. Hence, advisory services and training should be part and parcel of good ORM project management governance. Second, managing the expectations of the staff, senior management and directors as to the success of the implementation is also complex and time-consuming. This is where a HR responsibility governance framework comes into the picture – see Fig. 10 below. As can be seen, the involvement of the board is critical especially for alignment and oversight accountability. Without the board’s support, the ultimate success of the ORM implementation may be affected.

HR/People Responsibility HR/People Responsibility

Governance Framework in ORMGovernance Framework in ORM• Board responsibilities

– Strategic oversight; alignment

• CEO responsibilities

– Assign resp./accountability/ authority; oversee compliance

• Executives responsibilities

– Project implementation commensurate with risk; integrate with operations

• Senior Managers responsibilities

– Risk assessment, implement policies, oversee implementation operations

• All employees responsibilities

– Awareness; compliance; reporting

• HR Implementation Program

– Providing support for networks, systems (ref. ISO17799)

– Periodic assessment of risk

– Policies/procedures to address security risks and implementation obstacles; full lifecycle

– Operational awareness training

– Periodic testing; remedial action processes

– Incident response procedures

– Business continuity plans

• Reporting

– Adequacy, effectiveness, acceptable residual risk reported to executives

– Independent evaluation reported to the board

Fig. 10 HR Governance Framework for ORM Implementation With regards to technology, the emphasis here seeks to leverage the ability of technology to provide discipline and consistency to help the ORM personnel and staff to optimize the business processes via the appropriate enabling tools and systems. Here, the ORM team also performs stress tests to ensure ORM implementation adequacy in times of shocks or unforeseen obstacles. This will serve to enhance the transparency and reputation of the project management delivery.

6. Business Process Governance & Op Risk Management (ORM) The other critical component in a risk management framework pertains to the business process management. Business process management refers to the assessment of process workflows, mapping and scenario analysis complemented by documentation and policy manuals, which can be harnessed to enhance operational risk management. Underlying a sound ORM and the basis for streamlining risk management initiatives is the access to accurate and timely information. Key to this notion is the measurement and generation of Key Risk (KRI) and Control Indicators (KCIs) based on several parameters, namely, time, cost, quality and risk. Here is where business process governance plays a critical role. From an operational risk point of view, we can use fraudulent activities as potential loss events to illustrate the role of business process governance.

Fig. 11(a) illustrates an overview of the internal and external environment of an organizational hierarchy in order to demonstrate the different process drivers of possible scenarios of fraudulent activities at different levels of the hierarchy. To elucidate further the importance of the role of business process in the operational risk exposure space, let’s briefly compare the loss events at Barings and Enron. In the case of Barings, it was about the lack of oversight and awareness by the senior management and board of directors (in London) about Leeson’s activities in Singapore, while in Enron’s case, the senior management was directly involved in the fraudulent activities. The fraudulent activities in both cases were due to and involved different processes. Hence, it is important to establish a “process datamart” to archive these various operational loss incidences according to various types of origin or process type. Such a process-centric data segmentation model will help provide clarity in terms of the Basel 2 level 1 and 2 categories of loss events and further aid the development and adoption of a more sophisticated approach for ORM, namely, the internal (IMA) and advanced measurement approaches (AMA).

PeopleProcess

Disclosure

People

Process Systems

Technology

ModelGeography

PeopleProcess

CustomerSystems & Tech

Systems

Technology

People

Customer

Interactivity

Level

Middle-level

Management

Senior-level

Management

Board level:

Directors &

CEO/CFO

Process

Reporting

e.g. Fraud Incidence at any Layer of Organizational Hierarchy

ENVIRONMENT (INTERNAL & EXTERNAL)ENVIRONMENT (INTERNAL & EXTERNAL)

Diffe

ren

t Bu

sin

ess P

rocesses

CORPORATE CULTURECORPORATE CULTURE

Dif

fere

nt

Typ

es o

f P

ote

nti

al

Fra

ud

ule

nt

Dif

fere

nt

Typ

es o

f P

ote

nti

al

Fra

ud

ule

nt

Acti

vit

y

Ac

tivit

y

Fig. 11(a) Fraud & Business Process in the Organization Essentially, in the context of optimal operational risk management, it is highly appropriate to perform a risk mapping between the potential loss events and business process first – see Fig. 11(b) below.

Different Types of FraudDifferent Types of FraudFraud type 1

Fraud type 2

Fraud type 3

Fraud type n

Biz Process type 1

Biz Process type 2

Biz process type 3

Biz Process type n

Types of Fraud Loss Events

Data-warehouse

(Basel 2 OpRisk Mgt)

Business Processes

Data-warehouseMapping

Fig. 11(b) Op Risk Mapping The risk-based mapping process will enhance the clarity and future audit of the operations in addition to unearthing more latent information about the organization itself. This way, a more comprehensive and enterprise-view of the potential operational risk exposures hopefully can be unearthed first. Of course, not all scenarios can be accounted for but the task involved will elevate the organization to a higher level of awareness and appreciation of all its business processes and correspondingly, operational risk management. As a result of the exercise, if future loss incidences occur, the risk response from the mapping process may potentially help prevent the escalation of these losses or to mitigate them appropriately. What is often not mentioned from these process-centric risk mapping exercises is the transparency that they yield as part of the outcomes. When performed across the whole organization, the clarity achieved in terms of highlighting each business unit or line, together with the core processes and task-holders (contact persons) involved can never be under-estimated as accountability and “auditability” are also taken into consideration – ATA (Accountability, Transparency and Auditability) – see Fig. 12 below.

DetailedDetailed processprocess –– LoanLoan AnalysisAnalysis

• Op Risk Analysis based on major functions e.g.

– Document completeness

– Scoring

– References

– Collaterals

– ...

• Used IT application

• Responsibilities

• Used documents

• ...

Check, ifcollateralevaluationrequired

Verify

scoring

Checkcompletenessof documents

- if incomplete:Credit Advisor has toprovide missing documents

Checkreferences

Loan documentsavailable toloan admin.

Risk Analyst

Risk Analyst

Risk AnalystLoan

System

Prepareloan file

LoanAdministrator

Loan Memorandum(incl. supporting docs)

LoanAdministrator

Loan File

Loan Memorandum(incl. supporting docs)

LoanSystem

CreditAdvisor

Loan Memorandum(incl. supporting docs)

Loan

System

Fraudulentactivity

Risk information will be

linked to the specific

functions, which also

allows for identifying

potentials for improvement

Fig. 12 Operational Risk Management via ATA When coupled with issues related to the quality, time and cost, such a risk-oriented ATA model will provide a better analysis of the processes and the potential operational risk exposures. Also, with the current global emphasis on corporate governance and transparency, the ATA approach fits this “ethics” mindset smoothly and provides the benchmark for best practices in ORM implementation, especially those pertaining to Pillar 2 of the Basel Accord. To expedite the mapping, we can make use of reference models for the definition of high-level processes, with the risks assigned on a process level, instead of a business line, thus yielding more clarity and concrete information. The processes themselves can also be the basis for the op risk self assessment (RSA), ensuring a complete picture for every process. In a nutshell, the correlation between ORM and business process governance can be depicted in Fig. 13(a) and 13(b).

Enterprise PerformanceEnterprise Performance

““WHATWHAT““ResultsResults

““HOWHOW““HistoryHistory

““WHYWHY““CausesCauses

Business PerformanceBusiness Performance

Bu

sin

ess

In

tellig

en

ce

Bu

sin

ess I

nte

llig

en

ce

Finance & balance +Finance & balance +

static indicatorsstatic indicators

Liquidity / Cashflow

Return on Investment

RAROC

ROA

Process Performance = Indicators + Processes

Time

Cost

Quality

Risk

Enterorder

can be doneautomatically

Orderentered

Matchorder

Data transferedto OMAR

SETS

SETS

Checkorder

completely filled

Orderchecked

OMAR

CustomerTrading

CustomerTrading

Order isfor SETS

Large Capsselected MidCaps

Completeorder

Price

Ordercompleted

OMARCustomerTrading

Business Process

Performance Indicators + Process Chain

Bu

sin

ess

Pro

ces

s In

tellig

en

ce

Fig. 13(a) Elements of Process Performance

Sound Business Process Governance (Loss Estimation)

Business Process Governance

Potentially

Reduced UL

Enhanced Operational Efficiency

Risk-based Returns

Clearer Tracking & Auditability of Process

Checks & Controls

Reduced OpRisk EL

Credit OpRisk EL

Credit Risk EL

Risk Capital Calculation &

Allocation

Inputs into Risk-based

Pricing

Fig. 13(b) Linkage between Process Governance & ORM

As depicted in Fig. 13(a), process performance is examined from the perspectives of four parameters, namely, time, cost, quality and risk, with the help of benchmarks and risk indicators like KRIs and KCIs so that the “What, How and Why” of any operational loss incidence can be evaluated. Fig. 13(b), meantime, illustrates how loss estimation of operational loss incidences can be derived from a business process governance approach through the clarity in the tracking and audit of the process checks and controls during the risk mapping process. An optimal process governance may potentially enhance operational efficiency, thus reducing expected losses while the more rigorous auditability and controls may pre-empt or contain potential unexpected loss incidences, enhancing risk and capital management.

7. Operational KRIs in the ORM framework – Linkage to Risk Appetite

The design and implementation of operational KRIs and KCIs (Key Risk and Control Indicators) have to be viewed from a holistic perspective. We may have to ask the appropriate questions like:

• “Are we taking the right amount of risk?”

• “Are we getting a return that is consistent with our overall level of risk?”

• “Does our organizational culture promote or discourage the right level of risk taking activities?”

• “Do we have a well-defined organizational risk appetite?”

• “Has our risk appetite been quantified in aggregate and per occurrence?”

• “Is our actual risk level consistent with our risk appetite?” Ultimately, the determination and evaluation of KRIs and KCIs are inherently linked to the organization’s risk appetite and tolerance. In my opinion, due to the lack of understanding of what operational risk management entails, a lot of Asian financial institutions surprisingly display a high risk tolerance although they have a low risk appetite. They seem to tolerate a lot of capital “leakages” due to complacency or they take for granted operational loss incidences, especially those of a high-frequency nature, like business interruptions due to power failures, pollution or flooding, as they are part and parcel of the social environment where they operate. This misperception often impacts on their design and use of KRIs and KCIs, leading to inefficient use of early warning signals and information and resulting in further capital “leakages”, especially involving incidences characterized by losses of small magnitude but high frequency. However, there is no guarantee that such high-frequency operational loss events may not suffer from an unexpected loss of high-magnitude. Recent natural calamities in SE Asia, like flooding, have increasingly led to huge blowouts in terms of financial losses, although they tend to be smaller in the past. Unlike credit risk, it is not so easy to compartmentalize operational loss incidences into two distinct categories – small impact, high-frequency and large impact, low-frequency. Today, these events have loss impacts that

stretch across a continuum, rather than localize at either end of the spectrum, e.g. losses due to fraudulent activities and flooding can span from small amounts of a few thousand dollars (say from credit card theft or a branch closure lasting a few hours due to flooding) to those that can bring down the whole organization – think Nick Leeson and Barings!

Process-Driven Op Risk Mapping

Building blocks (major examples)

Internal & external

audit ratings

Early warning

systems

Develop guidelines

for each BU

Calculate limits

Internal & external

qualitative data

Analyze current

compliance P&P

Biz Process structure &

value chain assessment

Key risk indicators &

exposures ID

BU risk analysis &

metrics definition

Calibration with loss

event & qualitative data

Predictive

modeling

Risk indexing &

aggregation

Economic capital &

value based management

Risk metrics, mapping &

performance dashboard

Quantitative analysis &

risk scoring

Business Process

Governance & Performance

Capital Management &

Risk Quantification

Risk-based Outputs

& Thresholds

Fig. 14 Op Risk Mapping & KRIs To understand better the linkage between the risk appetite, KRI and ORM (Operational Risk Management), we can view the relationship in terms of the building blocks involved in business process governance, capital management and the risk-based outputs or reporting structures as shown in Fig. 14. The indicators, such as the KRIs and KCIs, represent reporting parameters for performance benchmarking and early warning signal generation, serving as part and parcel of an optimal risk monitoring system or framework. Here, the risk appetite and tolerance of the organization are embedded into the risk management framework via these KRIs and KCIs. The levels of the KRI (or KCI) thresholds or tolerance are an indication and quantification of the organization’s risk appetite. To achieve the threshold setting in the design of the KRI, what is necessary is the initial collation and aggregation of the required data based on an appropriate meta-data model. For instance, if we wish to evaluate whether the balance sheet of an organization is stressed, certain factors or parameters need to be defined first and action taken to collect the necessary information to help set the threshold levels either for performance evaluation or as early warning signals – see Fig. 15.

Low

Stress

High

Stress

Negative

2 1 or less

60% or more30%

10%

1% or less5%

5% or less

80% or more60%

20% or more10%

110% or less135%

20% or less40%

Liquidity

– Current ratio

Solvency

– Debt to Asset ratio

Profitability

– Net Operating Income

Repayment Capacity

- Debt coverage ratio

Efficiency

- Operating expense ratio

- Interest expense ratio

- Asset turnover ratio

- Rate of return on equity

- Rate of return on assets

Balance Sheet Stress Test

Related KRIs

from Financial

Analysis

Example

Fig. 15 KRI Generation from Balance Sheet In Fig. 15 above, the two levels of threshold for the debt to asset ratio representing the solvency of the firm, i.e., 30% and 60%,are a function of the organization’s own risk appetite based on the past empirical data of the firm. Different organizations may set these thresholds at different levels, unique to their own performance data in the past, as well as their risk appetite. Similarly, for the rest of the other parameters, these threshold levels between a low stress state and a high stress situation, function as KRIs for the firm to respond to based on its individual risk tolerance and appetite. These individual parameters may also yield an aggregate or global KRI measure or model, say by taking a weighted measure of the individual factors or levels. The potential risk responses as a result of acting on these KRIs (or KCIs) will be dependent on several of these options:

a) accept the risk, i.e., do nothing, indicating that the firm is willing to take on the risk,

b) avoid the risk, by adopting a back-out strategy or disengaging from the process leading to the risk,

c) share the risk, i.e., shift some of the risk to external parties, e.g., through outsourcing, syndication or forming joint ventures, and,

d) mitigating the risk via insurance or designing processes to reduce the risk exposures

The outcomes or actions of all these options may result in enhanced rewards or reduced losses or the status quo, but more importantly, a risk-based performance approach has been utilized to benchmark the performance based on the firm’s own risk appetite.

Synergy Between Process Governance & Data Management Framework

Business

Process Governance

Data Management Framework

Data Management

Framework

Critical Basis of Operational Risk

Management

Yields Organizational & Process

Efficiency Measures (6 Sigma)

Clarity of Relationship between

People, Functional Roles,

Responsibilities, Reporting & Systems

Transparency of Core Processes:

Audit Trail of Internal “Check &

Balance” Controls

Process Datamart

Raw Materials for Meta Data Definition

for OpRisk Capital calculation

Yields Reduction of Expected Loss (EL)

Potential

Risk-based Documentation of Policies &

Procedures

Derived Threshold Levels (KRIs, KCIs,

KPIs, KTIs) from Process & Risk

Mapping

Info Datamart

Connectivity with “EAI Middleware”

Fig. 16 Synergy between Process and Data Governance Ultimately, for the KRIs (or KCIs) to be fully operational and useful in an ORM framework, there must be synergy between all the critical components of the firm’s infrastructure, both hard and soft. The information architecture and management have to communicate and be fully integrated with the process management as depicted in Fig. 16. If this symbiotic relationship is attained, then the whole process of operational risk management will become clearer and more manageable.

8. Concluding Remarks While the final outcome is a working ORM system, ORM by itself is always a work in progress. In a dynamic and changing business environment, ORM (and ERM) should be viewed as an evolutionary development and provide for an incremental delivery of products, services and tools that can help an organization manage its risks going forward. It has to take into account the demands and needs of diverse regulatory drivers like Basel 2, IAS and SOX and yet, be able to aggregate and present the risk-based information in a uniform and simple language, understood by all and to be acted upon for the benefit of the organization.

References

1. http://www.bis.org 2. http://www.japantoday.com/jp/news/312436 3. http://www.rmi.gsu.edu/rmi/faculty/klein/RMI_3500/Readings/Other/Citi

group_Japan.htmhttp://www.rmi.gsu.edu/rmi/faculty/klein/RMI_3500/Readings/Other/Citigroup_Japan.htm

4. http://www.federalreserve.gov 5. http://www.occ.treas.gov 6. http://www.prmia.org 7. http://www.garp.com 8. http://www.iasb.org/Home.htm 9. http://www.coso.org