Book 3. Operational Risk

FRM Part 2

OR 3. Risk Identification

Presented by: Sudhanshu

Module 1. Identifying Operational Risks

Module 2. Operational Risk Taxonomies

Module 1. Identifying Operational Risks

Topic 1. Scope of Risk Identification

Topic 2. Top-Down Risk Identification Tools

Topic 3. Bottom-Up Risk Identification Tools

Topic 4. Scenario Analysis Best Practices

Topic 1. Scope of Risk Identification

• Definition: Risk identification involves recognizing potential risks that could affect a financial institution’s operations. It is the first phase in the operational risk management framework.
• Two Main Approaches:

  • Top-Down: Initiated by senior management and cascaded to business units and processes.

  • Bottom-Up: Business units assess their own risks locally.

• Combined Approach: Utilizing both methods provides a comprehensive view of operational risk.
• Details:

  • Top-down: Begins at board level → business units → business processes.

  • Bottom-up: Focuses on risks specific to each unit or function.

  • Effective risk identification supports profitability and loss prevention.

Topic 2. Top-Down Risk Identification Tools

• The collection of risks identified forms part of the bank’s overall risk inventory—or alternatively, its risk register or risk universe.

• Key tools include exposures and vulnerabilities, risk wheel and emerging risks
• Exposures and Vulnerabilities
  • ​Exposures
    • Key Areas: Consideration given to major clients, revenue sources, distribution channels, suppliers, key personnel, and service providers (IT, transaction processing)
    • Third-Party Dependencies: Reliance on outsourcing and third parties creates operational risk exposures based on potential significant failures from these relationships
  • Vulnerabilities
    • Internal Weaknesses: Include obsolete processes, control weaknesses, overdue maintenance/testing/updates, and neglected oversight of peripheral business units
    • Critical Risk Point: Greatest risk occurs when vulnerabilities link to significant exposures (e.g., unmonitored rogue trader) with potential for large losses or bankruptcy
    • Targeted Resolution: Identifying exposures and vulnerabilities together enables isolation of problems to specific business lines for focused resolution efforts

Topic 2. Top-Down Risk Identification Tools

• Risk Wheel
  • Visual Integration: Risk wheel displays selected/common risks in circular format to illustrate how different risk types interconnect and integrate
  • Banking Components: Typical bank risk wheel includes cogs for business objectives, labor market, reputation, technology, regulation, economy, natural events, data/information, and business continuity
  • Causal Chain Example: Weather disaster (natural events) → multi-day service outage (business continuity) → potential reputational harm demonstrates interconnected risk effects
  • Root Cause Focus: Causal analysis enables proactive risk prioritization and mitigation by addressing root problems rather than reactive symptom management
  • Strategic Application: Deeper understanding of causes and effects supports more effective risk management decision-making and resource allocation

Topic 2. Top-Down Risk Identification Tools

• Emerging Risks
  • Increased Importance: Market volatility, new technologies, online banking presence, and cybersecurity issues have significantly elevated emerging risk identification priority
  • Risk Categories: Emerging risks divided into predictable (well-known: cyber, regulatory, climate change; less-known: identified through horizon scanning) and unpredictable (global pandemic: requiring overall preparedness and resiliency)
  • PESTLE Framework: Horizon scanning considers political, economic, social, technological, legal, and environmental factors, focusing only on changes negatively affecting bank mission and strategy
  • Strategic Focus: Analysis should concentrate on specific threats relevant to scenario analysis and contingency planning rather than unwieldy comprehensive environmental changes
  • Advanced Approaches: Large banks analyze business-related research/trends and competing technology; machine learning and big data show significant potential for operational risk identification through quarterly emerging risk committees

Practice Questions: Q1

Q1. In the context of risk identification, which of the following items is most likely to be considered a vulnerability?
A. Principal regulator.
B. Critical third parties.
C. Stand-alone IT systems.
D. Main drivers of revenue.

Practice Questions: Q1 Answer

Explanation: C is correct.

• Vulnerabilities are the weakest links in business activities. Therefore, a standalone IT system is an example of a vulnerability in that it may lack updating or monitoring that could result in an external cyberattack.
• The other three items are exposures. For example, failure of critical third parties (e.g., service providers) to perform specifiic tasks for the bank may result in large losses for the bank. Or, noncompliance with one or more regulations could result in signifiicant fines and penalties assessed by the principal regulator

Topic 3. Bottom-Up Risk Identification Tools

• Definition: Bottom-up tools are used by business units and front-line employees to identify specific operational risks.
• Key tools include event and loss data analysis, risk and control self-assessment (RCSA) and Process Mapping
• Event and Loss Data Analysis
  • Internal, competitor, and industry loss data most reliable for forecasting future losses during stable market conditions
  • Internal Loss Patterns: Losses typically concentrated in back offices (financial markets, then retail, then IT) with risk levels dependent on transaction volume and size
  • External Learning: ORX consortium and other bank incidents help identify internal risks; banks should assess if similar incidents could occur and adjust risk management accordingly
  • Near Miss Value: Events with loss potential but no actual impact provide inexpensive learning experiences and highlight control weaknesses requiring attention
  • Incident Documentation: Maintaining logs of prior incidents (with or without losses) supports risk committee meetings and reveals evolving risk profiles for management practice improvements

Topic 3. Bottom-Up Risk Identification Tools

• Risk and Control Self-Assessment (RCSA)
  • ​Comprehensive Scope: RCSA involves entire bank, business units, or departments in self-evaluating key operational risks, controls, and control effectiveness to determine residual risk
  • Second Line Function: Typically performed by second line of defense assessing first line risks, often facilitated through questionnaires for data gathering
  • Strategic Participant Selection: Most valuable insights come from longest-tenured staff (historical perspective/rationale) and newly hired staff (fresh perspective from different work environments)
  • Annual Frequency: Usually conducted yearly or after major risk profile changes (competitor cyber events, regulatory penalties) or environmental shifts (global pandemic)
  • Balanced Approach: Must avoid excessive frequency (becomes checklist task) and excessive detail (yields minor, mundane risks with limited financial impact)
  • Value-Added Focus: Should remain insightful exercise rather than routine compliance activity to maintain effectiveness for risk identification and assessment

Topic 3. Bottom-Up Risk Identification Tools

• Process Mapping
  • Core Function: Process mapping clearly outlines individual steps and identifies potential problems, focusing on control-risk alignment to assess under/overcontrolled areas
  • Detail Balance: Must avoid excessive detail (time-consuming, less important focus) and insufficient detail (inadequate insight) for optimal usefulness
  • Key Action Integration: Optimal balance achieved when each step connects to key actions with corresponding controls for meaningful analysis
  • Risk-Control Linkage: Controls mapped to specific risks being mitigated with consideration of potential problems at each process step

Topic 3. Bottom-Up Risk Identification Tools

Practice Questions: Q2

Q2. The chief risk officer (CRO) at a local bank is more in favor of an assessment of operational risk at a more local and detailed level. Which of the following risk identification tools is the CRO least likely

to recommend?

A. Risk wheel.

B. Process mapping.

C. Analysis of near misses.

D. Risk and control self-assessment.

Practice Questions: Q2 Answer

Explanation: A is correct.

• Assessing risk at a more local and detailed level is characteristic of a bottom-up approach to risk identifiication. In that regard, process mapping, analysis of near misses, and risk and control self-assessments are key tools used in the bottom-up approach.
• A risk wheel is a top-down risk identification tool that uses brainstorming to generate ideas during a risk identifiication workshop. Therefore, it is least likely to be recommended by the CRO in this case.​ 

Topic 4. Scenario Analysis Best Practices

• Definition: Scenario analysis identifies low-probability, high-severity events to test the bank's resilience.

• Examples include natural disasters, global pandemics, major cyberattacks, and major business disruptions.

• Regulatory Guidance

  • BCBS Framework: Scenario analysis focuses on low-probability, high-severity events that could cause severe operational losses, with resilience scenarios used for business continuity planning
  • Future-Oriented Planning: Best practice BCPs should include scenario analyses considering damaging event impacts, recovery methods, and classification of key business operations with third-party dependencies
  • Business Impact Testing: All scenarios tested using business impact analysis (BIA) examining both quantitative impacts (financial) and qualitative impacts (legal, reputation)
  • Recovery Objectives: Service resumption focus requires recovery time objectives (RTOs) and recovery point objectives (RPOs) to determine acceptable data loss and downtime limits, plus provisions for unforeseen major disruptions

Topic 4. Scenario Analysis Best Practices

• Brainstorming Methods
  • Methodological Challenges: Scenario analysis faces pitfalls including inconsistent methodology and behavioral biases, requiring neutrality through empirical evidence and detailed documentation
  • Documentation Requirements: Regulators mandate consistent results across iterations, supported by explanations for scenario development and detailed assumption write-ups
  • Preparation Materials: Documents provided to participants include external/internal loss data, major incidents, RCSA feedback, KRI scores, and vulnerability assessments
  • Participant Composition: Upper management from various business units typically participate; external risk specialists ideal but infrequent, helping avoid myopia and internal loss bias
  • Generation Phase: Workshop facilitators (ORM specialists) create abundant scenarios through leading questions, elaborate and refine them, then classify by risk type or impact
  • Silent Voting Technique: Participants document concerns privately to avoid biases from strong personalities or dominant participants steering discussions
  • Scenario Selection: Final scenarios chosen by combining similar ones, dropping immaterial impacts, and retaining those with larger financial impact relevant to bank operations
  • External Validation: Banks cross-check scenarios with ORIC or ORX databases after internal generation process to identify omissions without introducing biases

Practice Questions: Q3

Q3. Which of the following statements regarding scenario analysis workshops and brainstorming sessions at a large bank is most accurate?

A. The assumptions used in scenario analysis can only be based on real-life data.

B. The facilitators of the workshops and sessions should be taken from the board of directors and senior management.

C. The participants in the workshops and sessions should be taken from a full range of seniority levels within the dierent business units.

D. The most common procedure is to withhold a “preparation pack” of documents from participants and distribute them after the generation phase to minimize any bias introduced to the sessions.

Practice Questions: Q3 Answer

Explanation: A is correct.

• To meet regulators’ requirements to reduce subjectivity and biases, assumptions used in scenario analysis must be based on empirical (real-life) data and evidence.
• The facilitators are usually ORM professionals and far less likely to be internal to the bank. The participants should be senior managers within the different business units. It is more common to distribute such preparation documents before the initial meetings, although less frequently, such documents will be withheld and distributed later to minimize any bias.

Module 2. Operational Risk Taxonomies

Topic 1. Operational Risk Taxonomies

Topic 2. Custom Taxonomies

Topic 3. Operational Riskdata eXchange (ORX) Taxonomy

Topic 4. ORX Taxonomy: Level 1 and Level 2 Risks

Topic 5. Taxonomies for Causes, Impacts, and Controls

Topic 6. Taxonomies for Causes

Topic 7. Taxonomies for Impacts

Topic 8. Taxonomies for Controls

Topic 1. Operational Risk Taxonomies

• Basel Definition: Operational risk defined as the risk of loss resulting from inadequate or failed internal processes, people and systems, or from external events.”
• Critical to distinguish between causes (root factors), events (what happens), and impacts (consequences) when describing risks
• Banks should organize risks using four elements - cause, risk/event, impact, and control - supported by taxonomies
• Integration Process: Separate listings of causes, impacts, and controls are integrated with risks during the risk assessment phase, with taxonomies enabling increasingly detailed descriptions
• Basel Taxonomy: A structured hierarchy of operational risks mandated by the Basel Committee on Banking Supervision (BCBS).
  • Levels
    • Level 1: 7 broad descriptions of events/risks
    • Level 2: 20 categories of risk
    • Level 3: Specific examples
  • ​BCBS only considers Levels 1 and 2 as regulatory categories

Topic 1. Basel Taxonomy

Topic 1. Basel Taxonomy

Practice Questions: Q1

Q1. Regarding the Basel taxonomy of operational risks for banks and the Level 1 category of internal fraud, which of the following items would most appropriately be included at Level 3?

A. Insider trading.

B. Theft and fraud.

C. Unauthorized activity.

D. Losses due to acts of a type intended to defraud.

Practice Questions: Q1 Answer

Explanation: A is correct.

• The Level 1 category is internal fraud, and it is defined as “losses due to acts of a type intended to defraud …” Furthermore, Level 2 subdivides internal fraud into two further categories: unauthorized activity and theft and fraud.
• Level 3 provides specifiic examples of risk and, in that regard, insider trading is a specifiic example of internal fraud.

Topic 2. Custom Taxonomies

• Definition: Banks may create custom taxonomies to reflect their unique risk profiles beyond Basel standards.
• Drivers for Customization
  • Cybersecurity risks
  • Risks associated with outsourcing, project management and supply chain maangement
  • AML compliance

Topic 3. Operational Riskdata eXchange (ORX) Taxonomy

• Expanded Framework: ORX taxonomy increased from Basel's 7 to 14 Level 1 risk types for more comprehensive coverage
• Elevated Classifications: Several Basel Level 2 risks promoted to ORX Level 1, including third-party failure risk, statutory reporting and tax risk, business continuity risk, data management risk, information security risk (including cyber risk), and model risk
• Classification Inconsistency: Banks showed great diversity in defining risks - same item could be classified as "control failure" by one bank, "cause" by another
• Emerging Risk Focus: Key modern risks (cyber, conduct, third-party) often classified inconsistently across institutions due to subjective judgment
• Business-Specific Approaches: Large multinational banks focused on internal control failures while payment processors emphasized information security/technology risks
• Standardization Need: Diversity and inconsistency in bank taxonomies created demand for international standard through ORX framework

Topic 4. ORX Taxonomy: Level 1 and Level 2 Risks

• The Level 1 Risks and corresponding level 2 risks are given below
• 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 organization, Internal fraud committed against customers/clients, or third/fourth parties
• Physical Security and Safety: Damage to organization'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 fulfill duties to customers, Client account mismanagement, Improper distribution/marketing, Improper product/service design
  Whistleblowing, Breach of code of conduct and employee misbehavior

Topic 4. ORX Taxonomy: Level 1 and Level 2 Risks

• 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, Know your customer (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/extraterritorial regulations, Prudential risk
• Third Party: Third party management control failure, Third party criminality/non-compliance with rules and regulations, Inadequate intra-group agreements/service level agreements (SLAs)
• Information security (including Cybersecurity): 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/filling 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

Topic 5. Taxonomies for Causes, Impacts, and Controls

• Definition: Breaking risks into cause, event, impact, and control helps clarify and mitigate operational risks.

• Figure 44.6 illustrates the overall relationship, with the encircled portion representing the actions steps to be taken based on the causes of the risks and controls that are available.

• Basic operational risk taxonomy includes four root causes: employees, process failure, external factors, and systems
• ORX taxonomy expands Basel's Level 1 categories into more specific Level 2 subcauses for detailed incident analysis
• Level 2 provides specific examples of failure causes underneath each of the four main Level 1 categories
• Detailed taxonomy enables precise identification and categorization of operational risk incident root causes

• Causes (ORX Level 1 Examples)

  • Employees: Human error, incompetence and/or poor training, poor communication, intentional harm
  • Process Failure: Failures in system design, process design, or governance
  • External:
    • Political, regulatory, economic, and physical aspects of the business environment
    •  Intentional harm
  • Systems:
    • Malfunctions; lack of capacity
    • Insufficient maintenance and/or testing
    • Service disruption
    • Insufficient data storage; data loss

Topic 6. Taxonomies for Causes

• Impacts are classified at Level 1 as direct financial (losses or remediation), indirect financial, and non-financial

• Impacts (ORX Level 1 Examples)

  • Direct Financial Impact:
    • Lost or damaged assets​
    • Legal costs; fines/penalties
    • Regulatory fines/penalties
    • Provisions
    • Compensation to customers and third parties
    • Gains and recoveries
    • Revenue reductions
  • Indirect financial impact: Regulatory compliance, Reputational harm, Customer detriment
  • Non-financial impact: Customers, employees, third parties (e.g., suppliers, service providers), shareholders, competitors

Topic 7. Taxonomies for Impacts

• Controls (ORX Level 1 Examples)

  • Preventive: Preventive controls are proactive in nature and used to minimize the chance of risks occurring by directly addressing the likely causes.

    • Example: An edit check (e.g.,must be five digits in length) to reduce data entry errors.

  • Detective: Detective controls come into play during or after the event in hopes of minimizing any negative impacts.

    • Example: A periodic reconciliation of transactions for accuracy (e.g., two independent amounts should “balance”).

  • Corrective: Corrective controls try to minimize or fix errors going forward so that they are not repeated in the future.

    • Example: Training sessions and sharing of “best practices.”

  • Directive: Directive controls consist of guidance, processes, and training that are provided while performing duties to minimize the risk of error.

    • Example: Detailed and step-by-step instructions on how to perform a specific process.

Topic 8. Taxonomies for Controls

Practice Questions: Q2

Q2. An investor records its investments on its internal systems and reconciles them with the investment listing on the brokerage statement each month. This reconciliation is best described as a:

A. corrective control.

B. detective control.

C. directive control.

D. preventative control.

Practice Questions: Q2 Answer

Explanation: B is correct.

A reconciliation is meant to detect an error as soon as possible so that it can be subsequently corrected, if needed. In that regard, the reconciliation is best described as a detective control. The reconciliation is not a corrective control as the reconciliation itself does not correct the error.