ORX Reference Taxonomy For Operational And Non-financial Risk Guidance .
ORX Reference Taxonomy for operational and non-financial risk – guidance document 31 OCTOBER 2019 www.orx.org Commercial in Confidence
Contents 1. Introduction . 3 1.1. 1.2. 1.3. Approach . 3 Scope and limitations . 4 How to use this document . 5 2. The ORX Reference Taxonomy . 6 3. Guidance . 9 3.1. 3.2. 3.3. 3.4. 3.5. 3.6. 3.7. 3.8. 3.9. 3.10. 3.11. 3.12. 3.13. 3.14. 3.15. 3.16. People . 9 External Fraud . 10 Internal Fraud . 11 Physical Security & Safety . 12 Business Continuity . 13 Transaction Processing and Execution . 14 Technology . 15 Conduct . 16 Legal . 20 Financial Crime . 21 Regulatory Compliance . 22 Third Party . 22 Information Security (including cyber) . 25 Statutory Reporting and Tax . 26 Data Management . 27 Model . 29 Appendix A. . Methodology . 30 Appendix B. . Overview of dataset . 32 B.1. Mapping between the new reference taxonomy and Basel . 33 Oliver Wyman Page 2 of 41 Commercial in Confidence www.orx.org
1. Introduction In recent years, operational risk has become an increasingly important component of the risk profile of financial organisations. Meanwhile, the broad landscape of operational risks has seen rapid evolution, with relatively recent additions to the risk vocabulary, e.g. cyber and conduct, rising to the top of organisations’ risk agendas. Given that the Basel operational risk taxonomy (the “Basel taxonomy”) was developed almost 20 years ago, some of these recently emerging themes are not explicitly captured or addressed in it. In response, a majority of ORX members have either chosen to adapt the Basel event types, or developed their own taxonomies, leading to some divergence in operational risk taxonomies between organisations. Against this backdrop, ORX has set out to develop a new reference operational and nonfinancial risk taxonomy (‘the ORX Reference Taxonomy’) to act as a common, practical reference for categorising operational risks. Based on, and informed by, the current practices of ORX members (using their taxonomy data), this reference taxonomy aims to provide a common language for sharing risk information and enabling meaningful dialogue between financial organisations. It is important to note that member data has been used to drive the development of this reference taxonomy, ensuring where possible that it is based on the common denominator. However, practice is divergent, particularly for certain risk types. Many taxonomies have idiosyncratic features driven by factors such as regulatory environment, business lines and/or organisational features. This reference taxonomy reflects practice, but for certain risks, analysis has identified that there is more than one way to represent them in the taxonomy. ORX intends to regularly review this reference taxonomy to ensure it evolves in line with industry practice and the risk environment, and to monitor industry practice (including whether ORX observes convergence). 1.1. Approach The development of the ORX Reference Taxonomy was informed by four principle inputs: A. The set of level 1 risks identified as part of ORX’s 2018 report “Development in Risk Taxonomies” The results from this previous work were published in July 2018 in the paper titled “Development in risk taxonomies”. The paper highlighted the need in the industry for improved risk taxonomies, whilst recognising the challenges in designing and integrating a new taxonomy. The paper outlined the emerging ORX Reference Taxonomy (in the form of level 1 risk events). This previous analysis formed the basis of the work described in this document. Oliver Wyman Page 3 of 41 Commercial in Confidence www.orx.org
B. A set of principles to guide the design The ORX Reference Taxonomy was designed to follow five principles: 1. Include two taxonomy levels 2. Be intuitive and easy to understand 3. Cover the scope of the current Basel taxonomy 4. Allow for mapping back to the Basel taxonomy 5. To the extent possible, be mutually exclusive and collectively exhaustive C. A thorough review and analysis of taxonomies submitted by 58 ORX members, further confirmed with taxonomies submitted by 2 ORX members Member data has been central to the development of this reference taxonomy, ensuring that, wherever possible, it represents common practice among institutions. As noted above, member taxonomies have idiosyncratic features. These are driven by factors such as regulatory environment, business profile and/or organisational structure. Where our analysis identified more than one way to approach a risk theme within the risk taxonomy, we have clearly called this out below, while striving to represent the majority view in the taxonomy. D. Input from the taxonomy advisory group A taxonomy advisory group, consisting of 8 financial institutions (with representation from both the banking and insurance industry) from various geographies and jurisdictions, gathered twice during the exercise to confirm the direction of travel, to provide feedback on the design of the taxonomy and to offer perspectives as the end-users of the taxonomy. They were also consulted extensively on the draft versions of this document to ensure the final taxonomy was fit-for-purpose and intuitive to use. See Appendix A and Appendix B for further details of the methodology, and an overview of the ORX member dataset, respectively. A mapping between the ORX Reference Taxonomy and the Basel event types is provided in B.1. 1.2. Scope and limitations The ORX Reference Taxonomy is a risk event taxonomy, based on the ‘bow tie’ method (see Appendix A), which distinguishes causes, events, and impacts: Cause: Underlying environment that allows risk events to develop; multiple causes can be mapped to one risk event Event: Discrete, specific occurrence, one degree removed from the impact Impact: Direct and/or indirect consequence of a risk event for an organisation; multiple impacts can be assigned to one risk event Oliver Wyman Page 4 of 41 Commercial in Confidence www.orx.org
Figure 1. Bow Tie Method (see appendix A for further detail) The scope of work did not include separate categorisations of causes or impacts. Institutions commonly capture causes and impacts and in addition may find it useful to employ “flags” to identify additional attributes of risk events, e.g. for reporting and analysis purposes. Specific guidance on the use of flags is provided in section 3. The aim of the exercise is to look at the most common peer practices and to arrive at a taxonomy that is internally consistent. Given the divergent approaches to define a risk taxonomy, it was sometimes necessary to apply a practical lens in order to select an approach that could be applied across business models, institution types and jurisdictions. As the industry continues to evolve and mature, the ORX Reference Taxonomy will evolve in tandem. The intention is for the reference taxonomy to be updated and refreshed with industry taxonomies on regular basis to reflect the latest developments. 1.3. How to use this document The purpose of the ORX Reference Taxonomy is to provide a consistent language for the industry to refer to when speaking about operational risks. It proposes one way to categorise operational risks, based on the current trends observed in the members’ taxonomies. It is not intended to be integrated directly into the organisation’s risk management tools and processes (e.g. risk identification) without further considerations for the organisation’s specific risk profile. This document is intended as user guidance for interpreting and applying the ORX Reference Taxonomy: Section 2 provides an overview of the taxonomy Section 3 provides detailed guidance for each level 1 risk, i.e. – Definitions of level 2 risks, including specific examples of risk events; where there are areas of potential overlap between event types, these overlaps have been identified, and clear boundaries have been drawn between the event (explaining the logic applied when developing the reference taxonomy). – For areas commonly debated in the industry, select deep dive exhibits provide detailed guidance on boundaries between risk categories; these include the level 1 risks of Conduct, Third Party, Information Security, and Model Oliver Wyman Page 5 of 41 Commercial in Confidence www.orx.org
2. ORX Reference Taxonomy Table 1. New ORX Reference Taxonomy for operational and non-financial risk Level 1 Risks Level 2 Risks People Breach of employment legislation or regulatory requirements Ineffective employment relations Inadequate workplace safety External Fraud Third party/vendor fraud Agent/broker/intermediary fraud First party fraud Internal Fraud Internal fraud committed against the organisation Internal fraud committed against customers/clients, or third/fourth parties Physical Security & Safety Damage to organisation’s physical asset Injury to employee or affiliates outside the workplace Damage or injury to public asset Business Continuity Inadequate business continuity planning/event management Transaction Processing and Execution Processing/execution failure relating to clients and products Processing/execution failure relating to securities and collateral Processing/execution failure relating to third party Processing/execution failure relating to internal operations Change execution failure Technology Hardware failure Software failure Network failure Conduct Insider trading Anti-trust/anti-competition Improper market practices Pre-sales service failure Post-sales service failure Client mistreatment/failure to fulfil duties to customers Client account mismanagement Improper distribution/marketing Improper product/service design Whistleblowing Breach of code of conduct and employee misbehaviour Legal Mishandling of legal processes Contractual rights/obligation failures Non-contractual rights/obligation failures Financial Crime Money laundering and terrorism financing Sanctions violation Bribery and corruption Oliver Wyman Page 6 of 41 Commercial in Confidence www.orx.org
Level 1 Risks Level 2 Risks KYC and transaction monitoring control failure Regulatory Compliance Ineffective relationship with regulators Inadequate response to regulatory change Improper licensing/certification/registration Breach of cross-border activities/extra-territorial regulations Prudential risk Third party Third party management control failure Third party criminality/non-compliance with rules and regulations Inadequate intra-group agreements/SLAs Information Security (including cyber) Data theft / malicious manipulation of data Data loss Cyber risk events Data privacy breach / confidentiality mismanagement Improper access to data Statutory Reporting and Tax External financial and regulatory reporting failure Tax payment/filing failure Trade/transaction reporting failure Data Management Unavailability of data Poor data quality Inadequate data architecture/IT infrastructure Inadequate data storage/retention and destruction management Model Model/methodology design error Model implementation error Model application error Figure 2 shows an illustration to help guide the reader in identifying the applicable level 1 risk when categorising a risk event. Oliver Wyman Page 7 of 41 Commercial in Confidence www.orx.org
Figure 2. Decision tree for categorising risk events Operational risk event Is the event inconsistent with employment practices/obligations, incl. workplace safety, or does it affect employee relations? Information Security Does it involve data security? Is it a data asset? Does it affect hardware, software or networks? Is an asset/assets 1, or the general public negatively impacted? Is it a financial asset? Is there intent to defraud? Does it involve cyber attacks? Technology Data M anagement Are people involved? Are they physically affected? Is it a financial crime 2? Financial Crime Does it involve an internal party? External Fraud Does it compromise market integrity? Internal Fraud Conduct Physical Security and Safety Yes No Level 1 Does it breach a code of conduct? Transaction Processing & Execution People Is it a third party management failure3? Third Party Is it a business continuity management failure? Business Continuity Does it affect external/regulatory reporting or tax payments 4? Statutory Reporting and Tax Is it a legal execution error? Legal Is it a model failure? M odel Does it violate rules regarding improper licensing, cross-border activities or prudential risk, or involve mismanaged regulatory obligations? Regulatory Compliance 1. Includes employees; 2. Money laundering, sanctions violations, bribery and corruption, or KYC failures; 3. Includes intra-group agreements; 4. Tax payments include risk of errors, omissions or delays in preparing, producing, or filing tax forms for the organisation’s own taxes Oliver Wyman Page 8 of 41 Commercial in Confidence www.orx.org
3. Guidance 3.1. People Definition: The risk of breaching employment legislation, mismanaging employee relations, and failing to ensure a safe work environment. L2 risk categories Table 2. Definition of level 2 risks Level 2 risk Definition Example risk event Breach of employment legislation or regulatory requirements Actual or perceived mistreatment of employees, which can be traced to a regulatory breach (e.g. unfair dismissal, harassment) An employee is harassed or discriminated against at work Ineffective employment relations Includes industrial action (e.g. strikes, tribunals), and ineffective union/employee group relations management An employee strike results in operational losses Inadequate workplace safety Unsafe work environment affecting employees’ physical and mental health An employee slips due to a spillage in the office cafeteria Additional guidance To avoid overlap with other level 1 risks, the following guidance is recommended: All risks related to workplace security, and health and safety, including breach of public safety regulations, should be mapped to People rather than Physical Security and Safety Risks relating to employee data, e.g. the failure to comply with laws/regulations concerning employee data privacy, are mapped to Information Security Risks relating to workforce misconduct, e.g. inappropriate employee behaviour breaching the organisation’s code of conduct, are mapped to Conduct As described in section1.2, the ORX Reference Taxonomy is an event-based taxonomy based on the ‘bow tie’ method. Therefore, the taxonomy does not include the underlying causes of risk events which many organisations instead capture via separate causal taxonomies. The following examples include items which are typically associated with the causes of risk events mapped to People: Unavailability of necessary capabilities and skills to meet business and customer needs Mismanagement of existing resources Failure to retain talent, leading to a diminished workforce Concentration of unique or irreplaceable skills and/or knowledge within a person or role (“key person risk”) Compensation schemes failing to incentivise optimal employee behaviour, without breaching a compensation regulation Oliver Wyman Page 9 of 41 Commercial in Confidence www.orx.org
3.2. External Fraud Definition: Fraud attempted or perpetrated against the organisation by an external party (i.e. a party without a direct relationship to the financial institution) without the involvement of an employee or affiliate of the organisation. L2 risk categories Table 3. Definition of level 2 risks Level 2 risk Definition Example risk event Third party/ vendor fraud Fraud committed by a third party/vendor A vendor submits a fraudulent invoice Agent/broker/ intermediary fraud Fraud committed by an agent, broker or intermediary A broker intentionally charges a higher fee to the organisation First party fraud Fraud committed by a first party Note: this includes insurance claims fraud and underwriting fraud. An individual submits a fraudulent loan application using a falsified credit history Additional guidance The level 2 risks listed above are categorised using the dimension of “actor”, i.e. the party committing the fraud against the organisation. Alternative dimensions include “channel”, “item”, “product” and “type”. The “actor” dimension was selected for the following reasons: The level 2 risks associated with the dimension of “actor” are not dependent on the organisation’s business model or business line, unlike, for example, the dimension of “product” The dimension of “actor” is not subject to evolution over time, in contrast to, for example, the dimension of “channel” The dimension of “actor” allows for a classification that is both mutually exclusive and comprehensively exhaustive However, organisations may not always be able to determine the actor responsible for the External Fraud risk event. In this case, the recommendation is to map the event to First party fraud. In addition, the following items are excluded from External Fraud: Events relating to data theft (mapped to Information Security) Items relating to fraud governance, as these refer to a control failure, rather than a risk event, and are therefore excluded from the reference taxonomy Oliver Wyman Page 10 of 41 Commercial in Confidence www.orx.org
3.3. Internal Fraud Definition: Fraud attempted or perpetrated by an internal party (or parties) against the organisation, i.e. an employee or affiliate of the organisation, including instances where an employee is acting in collusion without external parties L2 risk categories Table 4. Definition of level 2 risks Level 2 risk Definition Example risk event Internal fraud committed against the organisation Fraud committed by an internal party against the organisation Employee misuses organisation’s assets to embezzle employer’s funds Internal fraud committed against customers/clients, or third/fourth parties Fraud committed by an internal party against the organisation’s customer/clients, or third/fourth parties Employee takes control of customer account to steal customer funds Additional guidance The level 2 risks listed above are categorised using the dimension of “target”, i.e. the party against which the fraud is committed. Alternative dimensions include “channel”, “item”, “type”, and “device”. The ‘target’ dimension was selected for the following reasons: The dimension of “target” is not subject to evolution over time, in contrast to, for example, the dimension of “channel” The dimension of “target” allows for a classification that is both mutually exclusive and comprehensively exhaustive To avoid overlap with other level 1 risks, the following guidance is recommended: Theft or malicious damage of physical assets is mapped to Physical Safety and Security Events relating to data theft are mapped to Information Security While tax evasion pertaining to the organisation’s own taxes is mapped to Internal Fraud, the risk of organisations’ complicity in aiding their clients’ or customers’ tax evasion is classified under Conduct Oliver Wyman Page 11 of 41 Commercial in Confidence www.orx.org
3.4. Physical Security & Safety Definition: The risk of damage to the organisation’s physical assets, client assets, or public assets for which the organisation is liable, and (criminal) injury to the organisation’s employees or affiliates. L2 risk categories Table 5. Definition of level 2 risks Level 2 risk Definition Example risk event Damage to organisation’s physical asset Damage to specific assets owned or maintained by the organisation, including buildings, equipment and data centres (not including human assets) A building of the organisation is damaged in a fire Injury to employee or affiliates outside the workplace Injury to the physical and/or mental health of the organisation’s employees or affiliates; note that this excludes risk events within the remit of workplace health and safety Employees are kidnapped during a business trip Damage or injury to public asset Damage to public assets, and non-affiliated people for which the organisation is liable A window dislodges from the organisation’s building and falls onto a passer-by Additional guidance Risk events mapped to Physical Security and Safety are classified according to the type of asset affected, rather than the cause of the security or safety incident, for example, negligence, accidents, natural disasters, and intentional acts. This is in line with the definition of the ORX Reference Taxonomy as an event-based taxonomy, as described in section 1.2. Also note that, unlike Internal Fraud and External Fraud, there is no distinction between the type of perpetrator (i.e. internal vs. external). Note that risks relating to failures of workplace security and health & safety are recommended to be mapped to People (see section 3.1). Oliver Wyman Page 12 of 41 Commercial in Confidence www.orx.org
3.5. Business Continuity Definition: Failure of the business continuity management framework. L2 risk categories Table 6. Definition of level 2 risks Level 2 risk Definition Example risk event Inadequate business continuity planning/event management Failure to provide and maintain appropriate business continuity management (BCM), and event management framework including inadequate business continuity plans After a system outage disrupts online banking services, the required back-up system is not deployed Breakdown of management notification and escalation process whereby designated crisis management team members were not engaged to respond to the event Lack of notification of any incidents or other event that may cause a business disruption or where the service provider has implemented their business continuity plan Additional guidance To avoid overlap with other level 1 risks and draw a clear distinction between risk events and causes, Business Continuity is defined to include only risk events that are related to the failure of business continuity management. It is therefore recommended that the following risks are excluded from Business Continuity and mapped to an alternative level 1 risk: Unavailability of physical assets is mapped to Physical Security and Safety Unavailability of systems, including telecommunications and utilities, is mapped to Technology Unavailability of data is mapped to Data Management Unavailability of people/human resources is excluded from the ORX Reference Taxonomy, given that this refers to a cause, as outlined in section 3.1 Oliver Wyman Page 13 of 41 Commercial in Confidence www.orx.org
3.6. Transaction Processing and Execution Definition: Failure to process, manage and execute transactions and/or other processes (such as change programme) correctly and/or appropriately. L2 risk categories Table 7. Definition of level 2 risks Level 2 risk Definition Example risk event Processing/execution failure relating to clients and products Failure to correctly execute transactions related to clients and products1 For insurer, this includes processing errors in claims handling and payments, processing errors in reinsurance, processing errors relating to underwriting Interest owed to a customer from a savings product is not calculated and paid out correctly Processing/execution failure relating to securities and collateral Failure to correctly execute transactions related to trade and collateral2 Securities pledged for the repayment of loans are mis-managed Processing/execution failure relating to third party Failure to correctly execute transactions towards third parties Payments to third parties are delayed Processing/execution failure relating to internal operations Failure to correctly execute internal processes3 Payment of the organisation’s payroll is delayed Change execution failure Failure to successfully deliver change (as individual programmes and/or a portfolio of programmes)4 Failure in the change process that causes non-delivery of the change programme. Additional guidance Risks related to the execution of transactions are generally part of broader business processes, and therefore closely linked to other risk events. To avoid overlap with other level 1 risks, the following guidelines are recommended: Execution errors, e.g. the failure to accurately record business transactions in the general ledger, are mapped to Transaction Processing and Execution, rather than Statutory Reporting and Tax, since the incorrect reporting is an impact of the execution error 1 This includes onboarding/account opening, offboarding/account closing, payment, settlement, fees, account/product management, transactions, Shariah-compliant transactions, client interaction, client reporting, cash, and valuation. 2 This includes trade accounting, trade capture/execution, collateral, and trade counterparty. 3 This includes mistakes in employee payrolls, front office and back office failures, data capture failures, and project/change risk. 4 Most of the level 2 and level 3 risks in the members data are not precise in defining the exact nature of the failure of change programmes/projects. Oliver Wyman Page 14 of 41 Commercial in Confidence www.orx.org
Risk events relating to data capture are mapped to Transaction Processing and Execution, unless directly tied to data mismanagement, in which case these are mapped to Data Management Risk events relating to the mis-execution of processes that can be classified under Conduct (i.e. pertains to client, products/services, markets and business practices) should be classified under Conduct; mis-execution of all other processes are classified under Transaction Processing and Execution 3.7. Technology Definition: The risk associated with the failure or outage of systems, including hardware, software and networks. L2 risk categories Table 8. Definition of level 2 risks Level 2 risk Definition Example risk event Hardware failure Risk of hardware, including utilities, not performing correctly or adequately ATM machine breaks down Software5 failure Risk of software not performing correctly or adequately Payment software fails to process customer card transactions. Network failure Risk of networks not performing correctly or adequately The network connecting point-ofsales devices fails, preventing customers from making payments Additional guidance Technology risk events are categorised according to the part of the system affected, i.e. hardware, software, or network failures, rather than the type of failure or outage. The approach is used to ensure a clear separation between risk events and causes. The examples below illustrate the recommended mapping of risk events along boundaries between Technology and other level 1 risks: Risk events related to system failures of third parties are mapped to Technology Misuse of technology to facilitate internal fraud is mapped to Internal Fraud 5 Software would include applications, middleware and operating systems; utilities would be a subset of applications Oliver Wyman Page 15 of 41 Commercial in Confidence www.orx.org
In addition, risk events pertaining to Technology may be directly connected to other risk events. In these cases, such risk events can be recorded separately (and linked) or flags could be used if appropriate (see section 3.13), for example: Cyber-attacks with systems compromise are considered two separate risk events that are mapped to Information Security and Technology, respectively Likewise, systems f
A mapping between the ORX Reference Taxonomy and the Basel event types is provided in B.1. 1.2. Scope and limitations The ORX Reference Taxonomy is a risk event taxonomy, based on the 'bow tie' method (see Appendix A), which distinguishes causes, events, and impacts:
Bruksanvisning för bilstereo . Bruksanvisning for bilstereo . Instrukcja obsługi samochodowego odtwarzacza stereo . Operating Instructions for Car Stereo . 610-104 . SV . Bruksanvisning i original
10 tips och tricks för att lyckas med ert sap-projekt 20 SAPSANYTT 2/2015 De flesta projektledare känner säkert till Cobb’s paradox. Martin Cobb verkade som CIO för sekretariatet för Treasury Board of Canada 1995 då han ställde frågan
service i Norge och Finland drivs inom ramen för ett enskilt företag (NRK. 1 och Yleisradio), fin ns det i Sverige tre: Ett för tv (Sveriges Television , SVT ), ett för radio (Sveriges Radio , SR ) och ett för utbildnings program (Sveriges Utbildningsradio, UR, vilket till följd av sin begränsade storlek inte återfinns bland de 25 största
Hotell För hotell anges de tre klasserna A/B, C och D. Det betyder att den "normala" standarden C är acceptabel men att motiven för en högre standard är starka. Ljudklass C motsvarar de tidigare normkraven för hotell, ljudklass A/B motsvarar kraven för moderna hotell med hög standard och ljudklass D kan användas vid
LÄS NOGGRANT FÖLJANDE VILLKOR FÖR APPLE DEVELOPER PROGRAM LICENCE . Apple Developer Program License Agreement Syfte Du vill använda Apple-mjukvara (enligt definitionen nedan) för att utveckla en eller flera Applikationer (enligt definitionen nedan) för Apple-märkta produkter. . Applikationer som utvecklas för iOS-produkter, Apple .
och krav. Maskinerna skriver ut upp till fyra tum breda etiketter med direkt termoteknik och termotransferteknik och är lämpliga för en lång rad användningsområden på vertikala marknader. TD-seriens professionella etikettskrivare för . skrivbordet. Brothers nya avancerade 4-tums etikettskrivare för skrivbordet är effektiva och enkla att
Den kanadensiska språkvetaren Jim Cummins har visat i sin forskning från år 1979 att det kan ta 1 till 3 år för att lära sig ett vardagsspråk och mellan 5 till 7 år för att behärska ett akademiskt språk.4 Han införde två begrepp för att beskriva elevernas språkliga kompetens: BI
The colonial response to these acts is really the start of the American Revolution. First Massachusetts passed a set of resolutions calling for colonists to: one, disobey the Intolerable Acts, two, stop paying taxes, and three, prepare for war. And in September 1774, a group of delegates from twelve of the thirteen colonies - Georgia! - met in Philadelphia to coordinate the resistance of the .
