Operational Risk Categorisation (IOR)

Operational Risk Categorisation Operational Risk Sound Practice Guidance

An IRM Group Company

Foreword The Institute of Operational Risk (IOR) was created in January 2004 and became part of the Institute of Risk Management in 2019. The IOR’s mission is to promote the development of operational risk as a profession and to develop and disseminate sound practice for the management of operational risk.

The need for effective operational risk management is more acute than ever. Events such as the global financial crisis or the COVID-19 pandemic highlight the far-reaching impacts of operational risk and the consequences of management failure. In the light of these and numerous other events organisations have to ensure that their policies, procedures, and processes for the management of operational risk meet the needs of their stakeholders.

This guidance is designed to complement existing standards and codes for risk management (e.g. ISO31000). The aim is to provide guidance that is both focused on the management of operational risk and practical in its application. In so doing, this is a guide for operational risk management professionals, to help them improve the practice of operational risk in organisations.

Readers looking for a general understanding of the fundamentals of operational risk management should start with the IOR’s Certificate in Operational Risk.

Not all the guidance in this document will be relevant for every organisation or sector. However, it has been written with the widest possible range of organisations and sectors in mind. Readers should decide for themselves what is relevant for their current situation. What matters is gradual, but continuous improvement.

The Institute of Operational Risk Sound Practice Guidance Although there is no one-size-fits-all approach to the management of operational risk, organisations must benchmark and improve their practice regularly. This is one of a series of papers, which provides practical guidance on a range of important topics that span the discipline of operational risk management. The objectives of these papers are to: • Explain how to design and implement a ‘sound’ (robust and effective) operational risk management framework • Demonstrate the value of operational risk management • Reflect the experiences of risk professionals, including the challenges involved in developing operational risk management frameworks.

2

Contents 1. Introduction

4

2.The rationale for operational risk categorisation

5

3.Key Principles for Categorising Operational Risks

6

3.1 Risk categorisations should be based on established external frameworks

6

3.2 Risk categorisations should be customised

6

3.3 Consultation is essential

6

3.4 Periodic review

6

4. Designing an Operational Categorisation Framework

8

4.1.The Basis of Categorisation: Cause, Event or Effect?

8

4.2 Minimising Gaps and Overlaps

9

4.3 Granularity

9

4.4 Other Design Considerations

10

5. Implementation

11

5.1 Roles and responsibilities

11

5.2 Ensuring consistent use

11

5.3 Reporting

12

5.4 Addressing boundary events

12

6. Conclusion

14

Appendix A: Example Operational Risk Categorisations

15

3

Section 1 - Introduction Organisations are exposed to a range of risk types. Operational risks are one of these risk types.

Table 1 summarises some of the common risk types to which organisations are exposed.

Risk Type Credit Liquidity Market Operational Reputation Strategic

Description The risk that a counterparty may default of their obligations (a given financial claim is not paid in full) or have their credit rating downgraded.

The risk that an organisation is unable to meet its financial liabilities as they fall due.

The risks that arise due to fluctuations in the value of, or income from, the assets of an organisation.

The risk of loss resulting from inadequate or failed internal processes, people, and systems or from external events.

Threats to the public perception of an organisation and goodwill exhibited by its stakeholders.

Risks that are created or affected by the chosen strategy of an organisation.

Table 1: Common Risk Types

Whilst the focus of this paper is the categorisation of operational risks, they exist within a wider organizational context. Specifically, there will be times when exposures and events over-lap these risk types or where an event in one type of risk causes risks in another. For example, the emergence of an operational risk could precipitate a strategic risk and the combination could in turn lead to a reputational impact. In view of this, any categorisation of operational risks must not seek to segregate or isolate exposures and should be conducted within a holistic framework for categorising all of the risks to which an organisation is exposed (for example, an enterprise risk management framework).

4

Section 2 - The rationale for operational risk categorisation Operational risk exposures arise from the day-to-day operations of organisations. These operations span many activities and processes and require people, systems, and equipment to perform them in an efficient and low-cost manner. Give the breadth of organisational activities and the diverse processes, people, systems, and equipment required to fulfil them, the potential range of operational risk exposures and events are numerous. For example, they range from IT security breaches, employment disputes, fraud and customer complaints to fires, floods and other so-called ‘acts of god’.

Given the wide scope of operational risk exposures and events, categorisation can help to organise the identification, assessment, monitoring and control of specific types of exposure, as well as the types of loss that may occur. Different categories of risk may require specific risk assessment techniques and control approaches. Equally, some may be insurable (liability claims and property damage), others not (regulatory fines). The specific benefits are as follows: • Identification: an operational risk categorisation provides a ‘menu’ of potential risks, which can be used as a prompt in determining those that are relevant to an organisation or its specific departments and functions. This should help prevent risks from being overlooked • Measurement: the use of consistent terms and descriptions facilitates comparisons between operational risks and supports data aggregation (especially were risks are sub-categorised, see below) • Monitoring and reporting: a common frame of reference enables more meaningful analysis and oversight of the outputs generated by an operational risk management framework. For example, management should be better able to prioritise resources to the most significant operational risks, compare risk exposures in different departments and functions and set more granular targets, limits, and thresholds • Control: given the scope of operational risk, different categories may require very different control responses. Hence by categorising these risks customised control strategies may be developed Finally categorising operational risks demarcates them from other types of risk (Market, Credit, etc.). Where an organisation has multiple risks and other related control functions this helps to minimise the potential for gaps and overlaps, though rarely will they be eliminated, especially overlaps. Boundary issues between operational risk categories and other risk types do occur and are discussed below.

5

Section 3 - Key Principles for Categorising Operational Risks It is important to minimise the potential for gaps and overlaps in any operational risk categorisation. Avoiding gaps is especially important, since this may result in important exposures being ignored.

Section 3.1 - Risk categorisations should be based on established external frameworks Various organisations provide example risk categorisations. The most common for operational risk is provided by the Basel Committee on Banking Regulation. Though this focuses on financial institutions it represents a good starting point for any operational risk categorisation. This external framework is outlined in Appendix A, along with one other, the UK Treasury’s ‘Orange Book’.

Section 3.2 - Risk categorisations should be customised Though an established external framework provides a useful starting point for any categorisation, organisations may need to adapt them to suit the nature, scale, and complexity of their operations. Where organisations do deviate from an external framework it is recommended that a mapping exercise is completed to ensure that all relevant categories are included. It may also be that an organisation is required to use an external framework (e.g. the Basel framework) for regulatory reporting. Here no category must be missed out.

Section 3.3 - Consultation is essential The directors, managers and employees of an organisation must all be comfortable with any categorisation. Specifically, they must be able to understand the terms and descriptions that are used, and the categorisation must be usable and support the work that they do.

It is recommended that an initial, draft, categorisation is developed by the (operational) risk function, using one of the established external frameworks as a foundation. Comments should then be invited from all those that will be involved in the use of the categorisation (e.g. risk owners, a governing body, internal audit, compliance, etc.) to ensure that they understand the terms and descriptions used. They could also be invited to suggest omitted categories, that may be relevant for the organisation, but which are not captured by an external framework. However, where this is done, care should be taken to check whether any additional categories are simply a rewording of an existing category, as well as whether they can be mapped back to one of the categories within the external framework used as a basis for the categorisation.

Section 3.4. Periodic review An organisation’s operations and its associated operational risk exposures will change regularly.

It may also be that through the use of categorisation gaps and overlaps are identified that were not considered at the initial design stage. Equally new types of risk may emerge, as was the case with cyber risk. Hence, to ensure that any categorisation framework remains valid periodic review is necessary. Usually, this should be completed on an annual basis.

Care should be taken when changing a pre-existing categorisation. Changes to categorisation may make it harder to track trends or interfere with historical data aggregation. When any change is made to a pre-existing category this should be mapped back to the previous categorisation to allow data to be carried forward into subsequent risk assessments, for example. This is especially important where statistical tools and models are used to support risk assessment.

6

Adding new categories is easier, but it is important to double check whether a ‘new’ category is not simply a re-imagining of a pre-existing one. Adding multiple new categories may also make the categorisation unnecessarily complex, especially if they increase the potential for overlaps and mis-classifications.

Table 2: Levels of granularity for operational risk categorisation The Basel operational loss event classification provided in Appendix A illustrates the first three levels of table 2.

Not all organisations may elect to have levels 2 or 3 in table 1. But most will have level 4. This is to allow specific departments, functions, etc. to customise the categorisation to meet their specific needs while ensuring that all risks can be mapped back to a level 1 category.

7

Section 4 - Designing an Operational Categorisation Framework As explained above designing an operational risk categorisation framework requires great care.

Errors at the design stage may make the framework inefficient and time-consuming to use. Worse it may result in important operational risks from being overlooked.

Section 4.1 - The Basis of Categorisation: Cause, Event or Effect?

Like any type of risk, operational risks are multi-faceted. Meaning that they are a combination of causes, events, and effects. Figure 1 illustrates the relationship between them.

Figure 1: Cause, event, and effect The common definition of operational risk provided in table 1 demarcates operational risk based on its causes: people, processes and systems and external events. These causes may result in a wide range of operational risk events (fires, floods, theft, errors, and omissions, etc.). In turn, these events have multiple effects (financial loss, physical injuries, etc.). A categorisation may be based on any one of these three facets of operational risk.

Categorisations based on operational risk events are most common. The Basel categorisation in Appendix A is event-based, so financial institutions are often required to report their operational losses using this categorisation and therefore decide to use it elsewhere to ensure consistency.

Also, loss data is collected on a per-event basis. Loss events being the most visible manifestation of the presence of operational risk in an organisation.One of the advantages of an event-based approach is that it does not preclude the further sub-division of events into their constituent causes and effects. This allows an organisation to better picture the relationships between causes, events, and effects, highlighting potential correlations or concentrations of risk.

However, the downside of an event-based approach is that the associated categorisation framework can become very detailed, in an attempt to reflect the totality of events that may occur.

This requires careful consideration of the issue of granularity (see section 4.3, below).

Causal based categorisations have an intuitive appeal because they represent the starting point for operational risk exposures and so may help make operational risk management more leading and proactive. However effective classifications are hard to achieve in practice. Though the broad categories of causes are small, specific causes are numerous, often more numerous that potential events.

8

The absence of established external frameworks for categorising operational risks according to their causes also makes them more challenging. The same arguments apply to effectbased categorisations (numerous sub-effects, especially non-financial effects, and no external framework).

The IOR’s view is that operational risks are best categorised on an event basis. However, where possible high-level sub-categorisations for their causes and effects should be used to complement an event-based categorisation. This will allow an organisation to better link causes, events, and effects and to identify and mitigate potentially dangerous patterns in these causes and effects.

Section 4.2. - Minimising Gaps and Overlaps No operational risk categorisation is perfect. Compromise is always required. A very detailed categorisation may eliminate most gaps but result in frequent overlaps and classification problems. Misclassification is just as serious an issue as potential gaps or overlaps. In contrast, a less detailed classification should make it easier to categorise risks but could result in important risks being missed.

The best approach is to develop levels of classification. The initial level of classification is kept relatively broad, with additional layers added to provide further detail (see 4.3 below). The advantages of such an approach are that all operational risk events should be classifiable, while the layers of detail help users to apportion events, thus preventing overlaps and gaps. For more on addressing boundary issues see section 5.3.

Section 4.3. - Granularity Determining the level of detail in any operational risk categorisation is an essential decision. Less granularity will make the categorisation easier to manage and aggregate data for assessment and reporting purposes, but more detail will assist the focus of management and support mitigation. Some organisations adopt a compromise solution, which involves adding more granularity for critical categories but accepting less detail for categories of lower significance (in terms of volume and/or value). This avoids the trap of too few risks spread across too many categories, resulting in an inability to aggregate.

Various layers of granularity are possible. Table 2 summarises the most common.

Level 1

2

3 4

Explanation A small number of high-level labels reflecting, for example, common categories of events, the generic systems and processes of an organisation, areas of regulatory concern or the organisation’s objectives. For example: Acts of God (fires, etc.), Business Continuity, IT Systems, Legal and Regulatory, Financial Crime, etc The level 1 categories split into their logical component parts, depending on the specific manifestations of these events. For example, acts of god might be spit into fires, floods, windstorms, etc. Financial crime into internal and external fraud or IT systems into hacking attacks and equipment failures Level 2 categories further sub-divided to reflect the operational activities that may occur within an organisation’s divisions, departments, or functions A detailed description of the level 2 or 3 (where present) operational risk events that may occur within a specific context (e.g. payroll, manufacturing, sales, etc)

The advantage of levels 2 and 3 is that they add extra detail. This detail can help users to ensure that risks are categorised consistently. Also, it can reduce the potential for risks being overlooked, because users have not considered a specific aspect of a risk event (e.g. internal as well as external hacking attacks).

9

Section 4.4. - Other Design Considerations In the course of designing operational risk categorisations practitioners have discovered a number of other factors to consider. These are summarised below.

• The design of the categorisation must be appropriate and proportionate. A more granular/ detailed approach is not necessarily better and can lead to confusion, increasing the time and resources required to manage operational risks. For many organisations this means that level 1 granularity should be sufficient, at most level 2 • Consistency of use is key – this means ensuring clear and unambiguous explanations for each category of risk. Non-technical language (so-called plain English) is recommended, as this will reduce the potential for any misunderstanding • Ensure relevance to all parts of the organisation. The framework must make sense to the user population and be structured in a manner that is consistent with their activities and objectives • It is advisable to avoid including an “other” category. Such categories can become overloaded with risks that could be categorised elsewhere. Where a discrete new category of risk genuinely emerges, it should be added to the framework

10

Section 5 - Implementation This section outlines the factors that should be considered when implementing an operational risk categorisation, along with some common challenges and how these challenges may be overcome.

Section 5.1. - Roles and responsibilities An operational risk classification will influence many operational risk management activities across all of the departments and functions that make up an organisation. Table 3 outlines the primary users of the classification and their responsibilities.

Role Governing body and senior managers

Responsibilities The governing body supported by senior management have responsibility for ensuring that a sound system of operational risk management is in place.

This includes ensuring that an appropriate risk categorisation framework is in place and that the framework is working as intended.

Risk owners and Risk owners are business managers which responsibility for the management other staff with of some or all operational risks in their area. Risk owners should ensure that operational risk they and their staff understand the operational risk categorisation framework management and that it is used correctly to support risk identification, reporting, etc. responsibilities All other staff with operational risk management responsibilities must also ensure that they understand the categorisation framework and use it correctly.

Risk function The risk function, or operational risk function, where present, is responsible for the design of the operational risk management categorisation framework and for ensuring that it is used consistently across the organisation.

Internal audit

To support the implementation of the framework the (operational) risk function should ensure that it is documented and that a clear description of each category is provided. Mechanisms for dealing with any boundary issues (see below) should also be explained. This documentation could be supported by training and awareness activities, to help ensure that all relevant staff understand the framework and can use it effectively.

Internal audit is responsible for providing assurance to the governing body and supporting senior management that the operational risk categorisation framework is fit for purpose and working as intended.

Internal audit may also choose to use the operational risk classification to support audit planning and to structure management actions in audit reports. Linking each action to one or more category of operational risk.

Where possible this approach is recommended, as it can help to embed the categorisation approach and ensure a consistent approach to operational risk.

Section 5.2. - Ensuring consistent use Consistency of use is key. If different managers or parts of the organisation classify similar risks differently then it will be impossible to achieve an accurate organisation-wide view of its operational risks.

11

A key challenge to consistency is that categories are rarely mutually exclusive. This means that the users of any operational risk categorisation framework will sometimes find that risk could potentially be placed into two or more categories. For example, a fraud committed by a former employee might be classified as either an internal or external fraud.

A related challenge is that risk events can be related, with the occurrence of one event causing another to occur. For example, an external hacking attack might, in turn, result in a systems failure as well as data theft. How then should such an event be categorised? As an external fraud or cyber attack (the underlying cause) or as a systems failure or data theft event?

There are no single right solutions to these challenges. But it is essential to agree on a consistent approach for them across an organisation. As a general rule the IOR would recommend the following: • Operational risk events should be categorised according to the underlying or original event. In the case of the above hacking attack example, this means classifying the event as an external hacking (cyber) attack, rather than a systems failure or data theft event. However, the potential for such an event to impact systems continuity and security should be noted and addressed in any management response.

• Procedures should be documented on how to resolve any classification difficulties. As a general rule if managers are in any doubt about how an operational risk should be classified they should refer the matter to the (operational) risk function for a decision.

• These procedures should be supported by training on how to categorise operational risks consistently. Ideally, this training should include local examples of risks and explain how they should be categorised.

• Where an IT system is used to support operational risk management, the risk categorisation framework should be embedded within this system and include guidance on how to classify risks appropriately (e.g. drop-down descriptions of each risk category).

• As part of the periodic review process of the operational risk categorisation attention should be paid to problem categories, where management finds it most difficult to allocate risks consistently. Where possible these categories should be amended, in consultation with management, to correct any issues.

Section 5.3. - Reporting The structure of operational risk reports should reflect, where possible, the agreed operational risk categorisation. This should ensure the accurate aggregation of operational risk data and help to further embed the categorisation across the organisation.

An operational risk categorisation should also be used to adjust the level of detail provided in reports. As a general rule, the governing body will require reports that summarise any significant exposures or loss events with an organisation’s level 1 (see table 2) operational risk categories.

Senior management significant exposures/loss events with the level 2 categories and for departmental/functional managers exposure to their local level 2 or 3, if used, risks.

Section 5.4. - Addressing boundary events A boundary event can be defined as one which becomes apparent in one risk type but has its causes in a different risk type e.g. an insurance risk or credit risk loss that has arisen as a result of an underlying operational risk event (e.g. a processor control failure). For example, a creditor default is an example of credit risk, but the underlying cause may have been errors in the due diligence process, which meant that credit was provided to a counterparty with a poor credit rating.

12

Boundary events are inevitable for most organisations. They can be particularly problematic in organisations that have discrete risk functions (e.g. a credit risk management function and an operational risk management function). This is because arguments may occur over which function ‘owns’ the risk. It may also lead to a waste of management resources because it is double managed. Even worse risks may be overlooked, with each function assuming that it is the other’s responsibility.

Boundary events are less problematic in organisations that have mechanisms for coordinating the management of different risk types, such as an Enterprise Risk Management Framework or a holistic risk function lead by a Chief Risk Officer. Cross-discipline training can also help, where specialist risk functions learn about the work of their peers (e.g. operational risk training for the credit risk function and vice-versa). As can the establishment of a cross-disciplinary risk committee that discusses potential boundary events and apportions responsibility for their management to the relevant risk function.

13

Section 6 - Conclusion Given the wide variety of operational risks, they must be organised consistently. The categorisation is an important part of this objective, helping to allocate limited management resources efficiency and preventing risks from being overlooked.

In a sense, a sound operational risk categorisation is the skeleton that supports the entire operational risk management framework. A weak approach to categorisation will mean a weak framework. However effective the other elements are believed to be.

Appendix A: Example Operational Risk Categorisations L Below two external categorisations that include a significant number of operational risk events are provided. It is recommended that one of these (the one believed to be most suited to the nature, scale and complexity of the organisation) is used as the starting point for the organisation’s customised operational risk classification.

Though the Basel loss event types were designed for financial institutions and specifically banks, it remains a useful reference source for non-financial organisations, especially those in the private sector. The Treasury’s ‘Orange Book’ classification (updated in 2020) is primarily designed for public sector organisations, but is relevant for private sector also, especially smaller, less complex ones.

The Basel classification is dedicated to operational risk events. In contrast the Orange Book classification includes other types of risk. Nevertheless a significant number of the Orange Book risk types fall within the scope of operational risk.

14

Event Type Definition Category (Level 1)

Categories (Level 2)

Activity Examples (Level 3)

Internal Fraud

Losses due to acts of a type intended to defraud, misappropriate property or circumvent regulations, the law or company policy, excluding diversity/ discrimination events, which involves at least one internal party

• Unauthorised Activity • Theft and Fraud

• Transactions not reported (intentional) • Transaction type unauthorised (with monetary loss) • Mismarking of position (intentional) • Mismarking of position (intentional) • Fraud / credit fraud / worthless deposits • Theft / extortion / embezzlement / robbery • Misappropriation of assets • Malicious destruction of assets • Forgery • Check kiting • Smuggling Account takeover / impersonation etc • Tax non-compliance / evasion (wilful) • Bribes / kickbacks • Insider trading (not on firm’s account)

External Fraud

Losses due to acts of a type intended to defraud, misappropriate property or circumvent the law, by a third party

• Theft and Fraud • Systems Security

• • • • •

Employment practices and workplace safety

Losses arising from acts inconsistent with employment, health or safety laws or agreements, from payment of personal injury claims, or from diversity / discrimination events

• Employee Relations • Safe Environment • Diversity and Discrimination

• Compensation, benefit, termination issues • Organised labour activity • General liability (slip and fall etc) • Employee health and safety rules events • Workers compensation • All discrimination types

15

Theft / robbery Forgery Check kiting Hacking damage Theft of information (with monetary loss)

Clients, products and business practices

Losses arising from an unintentional or negligent failure to meet a professional obligation to specific clients

• Suitability, disclosure and fiduciary • Improper business or market practices • Product flaws • Selection, sponsorship and exposure • Advisory activities

• Fiduciary breaches / guideline violations • Suitability / disclosure issues (knowyour-customer etc) • Retail customer disclosure violations • Breach of privacy • Aggressive sales • Account churning • Misuse of confidential information • Lender liability • Antitrust Improper trade / market practices • Market manipulation • Insider trading (on firm’s account) • Unlicensed activity • Money laundering • Product defects (unauthorised etc) • Model error • Failure to investigate client per guidelines • Exceeding client exposure limits • Disputes over performance of advisory activities • Natural disaster losses • Human losses from external sources (terrorism, vandalism)

Damage to physical assets

Losses arising from loss or damage to physical assets from natural disaster or other events

Disasters and other events

Business disruption and system failures

Losses arising from disruption of business or system failures

Systems

Execution, delivery and process management

Losses from failed transaction processing or process management, from relations with trade counterparties and vendors

Transaction • Miscommunication capture, execution • Data entry, maintenance or loading and maintenance error • Missed deadline or responsibility • Model / system mis-operation • Accounting error / entity attribution error • Other task mis-performance • Delivery failure • Collateral management failure • Reference data maintenance

• • • •

16

Hardware Software Telecommunications Utility outage / disruptions

Monitoring and reporting

• Failed mandatory reporting obligation • Inaccurate external report (loss incurred)

Customer intake and documentation

• Client permissions / disclaimers missing • Legal documents missing / incomplete

Customer / client account management

• Unapproved access given to accounts • Incorrect client records (loss incurred) • Negligent loss or damage of client assets

Trade counterparties

• Non-client counterparty misperformance • Miscellaneous nonclient counterparty disputes

Vendors and suppliers

• Outsourcing • Vendor disputes

17

www.theirm.org

Developing risk professionals