Key Takeaways

Chapter 12: Operational Risk and Technology Risk Management

Core Concept

Operational risk — loss from failed processes, people, systems, or external events — encompasses technology risk, model risk, third-party risk, and cyber risk. As financial institutions have become technology companies, operational risk has moved from a residual category to a central regulatory and management concern.

Essential Points

1. The Basel Definition and Capital Framework - Operational risk = loss from inadequate/failed internal processes, people, systems, OR external events - Excludes strategic risk and reputational risk (though these often result from operational events) - Basel IV / SMA: Business Indicator × loss multipliers derived from historical loss data - Replaces AMA (Advanced Measurement Approaches) which produced inconsistent, model-dependent results

2. Seven Basel Risk Categories 1. Internal fraud 2. External fraud 3. Employment practices and workplace safety 4. Clients, products, and business practices 5. Damage to physical assets 6. Business disruption and system failures 7. Execution, delivery, and process management

3. DORA: The EU Technology Risk Standard - Five pillars: ICT risk management, ICT incident reporting, resilience testing, third-party risk, information sharing - Effective January 17, 2025 — the most comprehensive regulatory technology risk framework to date - Applies to financial institutions AND critical ICT third-party providers - Material ICT incidents: 4-hour initial notification, 72-hour intermediate, 30-day final

4. The ORM Framework Components - RCSA: Business units identify and assess risks in their processes; inherent vs. residual risk; control documentation - Loss data collection: Internal events database + ORX external data for low-frequency, high-severity risks - Scenario analysis: For tail risks not in historical data — expert elicitation of plausible severe scenarios - KRI monitoring: Leading indicators that signal increasing risk before events occur

5. Third-Party Risk Is Now a Primary Risk Category - US: 2023 Interagency Guidance covers the full third-party relationship lifecycle - DORA: Register of all ICT arrangements; contractual requirements; exit strategies - UK: Cloud concentration risk is a specific regulatory concern - Due diligence: financial health, SOC 2, business continuity, sub-contractor chain, concentration risk

6. Model Risk Management (SR 11-7) - All models require: model inventory entry, conceptual soundness assessment, independent validation, ongoing monitoring - SR 11-7 scope now effectively extends to ML-based compliance systems (transaction monitoring, fraud, KYC) - Model governance: a Model Risk Committee or equivalent with appropriate seniority - Validation must be independent of development — a direct governance requirement

7. Cybersecurity Risk Has Its Own Reporting Regime - US SEC: Material cyber incidents disclosed within 4 business days of materiality determination - DORA: 4-hour initial notification for major incidents - UK: FCA notification "as soon as reasonably practicable" - NIST CSF 2.0 (2024): Identify, Protect, Detect, Respond, Recover, Govern — the US reference framework

Key Distinctions

Connections to Other Chapters

• Chapter 4 (Technology Foundations): ML models in compliance (Chapter 4) are subject to SR 11-7 model risk management (Chapter 12)
• Chapter 5 (Data Architecture): Data quality failures are a primary source of execution and process management operational risk
• Chapter 26 (Explainable AI): XAI techniques (Chapter 26) support model validation and documentation requirements under SR 11-7
• Chapter 27 (Cloud Compliance): Cloud adoption creates third-party and concentration risk covered by DORA and the 2023 Interagency Guidance
• Chapter 33 (Cybersecurity/DORA): DORA's full scope — including specific cybersecurity requirements — is covered in depth in Chapter 33

Next: Chapter 13 — Regulatory Reporting: From XBRL to API-Based Reporting →