The Crux of Banks Regarding Operational Risk Management

The Setup Nobody Questions

Banks operate under a layered regulatory architecture. At the top, risk management standards like ISO 31000 and COSO ERM define how organizations should manage risk — through identification, analysis, evaluation, and treatment. In the middle, Basel III/IV prescribes how much capital banks must hold against operational risk. And at the operational level, banks build risk registers — the living documents that are supposed to translate strategic risk governance into daily decision-making.

The structural problem is this: Basel's OPE25 Table 2 — the "Detailed loss event type classification" — was designed for capital adequacy calculation. It classifies financial losses by category so regulators can verify that banks hold enough capital. It was never designed to be a threat taxonomy, a risk identification tool, or the backbone of a risk register.

And yet, that is precisely how most banks use it.

Walk into any major bank's operational risk function and ask to see the risk register. Chances are the top-level categories map directly to Basel's seven event types: Internal Fraud, External Fraud, Employment Practices, Clients/Products/Business Practices, Damage to Physical Assets, Business Disruption and System Failures, Execution/Delivery/Process Management. The risk register is Basel Table 2 with likelihood and impact scores bolted on.

This creates a structural contradiction: ISO 31000 and COSO ERM demand that organizations identify causes of risk. Basel OPE25 provides categories defined by consequences. The risk register is supposed to bridge the two, but it inherits Basel's consequence-oriented structure and therefore cannot fulfill the cause-identification mandate of the risk standards it claims to implement.

This article dissects that contradiction using a cause-oriented analytical lens: the Top Level Cyber Threat Clusters (TLCTC) framework's Bow-Tie model, which enforces a strict separation between causes, events, and consequences. What emerges is not a minor classification quibble — it is a fundamental structural failure that renders most banks' operational risk registers incapable of supporting the risk-based decision-making they were built to enable.

What Basel Table 2 Actually Classifies

Basel OPE25 Table 2 provides seven Level 1 "event-type categories." The word "event" suggests these are discrete occurrences. They are not. Let's test each one against a simple diagnostic: where does this category sit in a Bow-Tie risk model?

A Bow-Tie separates risk into five elements: Threats (causes on the left), Preventive Controls (barriers on the left), a Central Event (the pivot), Mitigating Controls (barriers on the right), and Consequences (effects on the right). If a taxonomy is semantically clean, each category should occupy one position.

Internal Fraud — "Losses due to acts of a type intended to defraud..." This describes actor motivation ("intended to defraud"), actor position ("at least one internal party"), and outcome ("losses"). It spans the entire Bow-Tie from cause through consequence. It is not an event — it is an event chain compressed into a label.

External Fraud — Same structure, different actor position. The phrase "Hacking damage / Theft of information (with monetary loss)" in the Level 3 examples compresses: attack mechanism → system compromise → data exfiltration → financial impact — at minimum four distinct Bow-Tie nodes — into a single classification.

Business Disruption and System Failures — "Losses arising from disruption of business or system failures." "Disruption" is a consequence. "System failures" can be either a cause (hardware failure) or an event (system outage). The Level 3 examples ("Hardware / Software / Telecommunications / Utility outage/disruptions") conflate adversarial attacks (e.g., DDoS) with non-adversarial failures (e.g., power outage) in a single category.

Damage to Physical Assets — "Losses arising from loss or damage to physical assets." This is explicitly and entirely an outcome. The cause could be natural disaster, arson, vandalism, or a cyberattack with physical consequences. Basel doesn't distinguish because the category is defined by what was damaged, not by what caused the damage.

The remaining three categories (Employment Practices, Clients/Products/Business Practices, Execution/Delivery/Process Management) follow the same pattern: they are defined by the domain in which consequences manifest, not by the mechanism that produced them.

Result: Not a single Basel Level 1 category occupies the cause side alone. Most sit on the consequence side or straddle cause and consequence. This is not a semantic technicality — it is a structural defect that cascades through every downstream use of these categories.

Event Chains Masquerading as Single Events

The deeper problem is that several Basel categories don't describe atomic events at all. They describe causal chains — sequences where one thing leads to another — collapsed into a single label.

Consider what happens when a bank suffers a ransomware incident. The actual causal chain, decomposed properly, looks like this:

Cause:     Phishing email → Malware execution → Credential theft → Privilege abuse → File encryption
           ↓
[SRE]:     System Compromise — Loss of Control over file servers
           ↓
[DRE]:     Loss of Accessibility — Business data encrypted
           ↓
[BRE₁]:    Business disruption — Revenue loss during downtime
[BRE₂]:    Ransom payment demand
[BRE₃]:    Regulatory notification obligation
[BRE₄]:    Recovery and rebuild costs
[BRE₅]:    Reputational damage — Customer attrition

Where [SRE] is the System Risk Event (the central Bow-Tie event — loss of control), [DRE] is the Data Risk Event (the technical consequence — what happened to data), and [BRE] are the Business Risk Events (the organizational consequences — what it costs).

In a Basel-based risk register, this single attack path fragments across multiple categories:

• "External Fraud — Systems Security" (because "hacking" was involved)
• "Business Disruption and System Failures" (because systems went down)
• "Damage to Physical Assets" (if servers required replacement)
• "Clients, Products & Business Practices" (if client data obligations were breached)

The bank now has four risk register entries for one attack path, each with its own risk owner, its own control set, and its own capital allocation. The preventive controls are identical for all four — they all require email filtering, application whitelisting, multi-factor authentication, and least-privilege enforcement. But because the register fragments by consequence domain rather than by cause, four different teams may independently implement overlapping controls while missing the actual gap.

Conversely, genuinely different attack paths with different control requirements get merged because they produce losses in the same Basel category. A SQL injection exploiting a code flaw in the bank's web application and a social engineering attack on the helpdesk both end up classified as "External Fraud — Systems Security." The first requires secure coding practices, web application firewalls, and input validation. The second requires identity verification procedures and security awareness training. Zero overlap in preventive controls. Basel treats them as the same risk.

What ISO 31000 and COSO ERM Actually Require

ISO 31000 defines risk as the "effect of uncertainty on objectives" and mandates identification of "sources of risk, events, their causes and their potential consequences." COSO ERM similarly requires organizations to "identify events" and "assess risks" by considering "likelihood and impact."

Both frameworks explicitly call for cause identification. ISO 31000 lists "causes" as a mandatory element of risk identification. COSO's event identification component expects organizations to understand what drives risk events, not merely what they are called.

But here is the critical gap: neither standard imposes a structural constraint on what counts as a valid cause identification. They mandate the process (identify → analyze → evaluate → treat) and define the vocabulary ("risk," "event," "consequence"), but they provide no taxonomy — no closed set of cause-side categories that would force the analyst to be specific about mechanisms.

This means the following risk register entry is fully ISO 31000 compliant:

Risk: Data breach
Source: External threat actors
Consequence: Financial loss, regulatory penalties
Likelihood: Medium
Impact: High

Every required field is populated. The process was followed. And yet this entry contains zero actionable information. "Data breach" is a consequence (a Data Risk Event — Loss of Confidentiality). "External threat actors" is an actor classification, not a causal mechanism. There is no generic vulnerability named, no attack mechanism identified, and therefore no way to determine which preventive controls would reduce the likelihood.

ISO 31000 accepts this entry because it tells you that you must identify risks, not how you must decompose them. It provides verbs but no nouns.

The Structural Contradiction

Now we can see the contradiction clearly:

1. ISO 31000 / COSO ERM mandate cause identification but provide no taxonomy of causes
2. Basel OPE25 Table 2 provides a taxonomy, but it classifies by consequences, not causes
3. Banks fill the gap by using Basel's consequence taxonomy as if it were a cause taxonomy
4. The result: risk registers that satisfy the formal requirements of ISO 31000 (causes are "identified") while structurally violating its intent (the "causes" are actually consequence labels)

This contradiction produces six cascading organizational failures:

1. Risk Entries Are Not Falsifiable

Under a consequence-based taxonomy, a risk identification workshop can produce "risk of ransomware" and nobody can prove this is wrong — it is a valid natural language description of something bad that might happen. But "ransomware" is an outcome label. It names neither the generic vulnerability that would be exploited nor the mechanism that would deliver the payload. Ten different attack paths can lead to ransomware. Each requires different preventive controls. The risk entry is unfalsifiable because it makes no testable claim about causation.

A risk entry becomes falsifiable only when it names the causal mechanism: "Risk of credential theft through phishing, leading to lateral movement and ransomware deployment." Now each node can be challenged: Do we have email-facing users? Are credentials phishable (no MFA)? Can the attacker move laterally (flat network)? Can executables run on file servers (no application whitelisting)? Each question points to a specific, testable control.

2. The [SRE] → [DRE] → [BRE] Chain Gets Flattened

The three-stage consequence chain — System Risk Event → Data Risk Event → Business Risk Event — represents three distinct detection and intervention windows:

• [SRE] window: The SOC can detect and contain compromise before data is affected (hours to days)
• [DRE] window: DLP and integrity monitoring can limit scope before business impact materializes (days to weeks)
• [BRE] window: Response and recovery planning can reduce business consequences (weeks to months)

When Basel collapses the entire chain into a single category label, organizations lose the concept that intervention points exist between system compromise and business impact. Modern adversaries routinely maintain persistence for weeks between [SRE] (initial compromise) and [DRE] (data exfiltration). That detection window is precisely where threat hunting, behavioral analytics, and network segmentation provide value. But if the risk register doesn't separate these stages, the organization cannot justify investment in detective controls that operate in that window — because the window doesn't exist in its risk model.

3. Controls Get Mapped to Consequences Instead of Causes

When risks are defined by their Basel outcome category, the natural response is to map controls to that category. "External Fraud — Systems Security" gets assigned controls like "firewall, IDS, anti-fraud monitoring." But whether these controls are relevant depends entirely on which generic vulnerability would be exploited — and that information is absent.

If the attack vector is a server-side code flaw, the preventive controls are secure coding, patching, web application firewalls, and code review. If the vector is credential theft, the controls are multi-factor authentication, credential rotation, and identity governance. If the vector is social engineering, the controls are security awareness training and verification procedures. These control sets are almost entirely non-overlapping, yet Basel lumps all three under a single risk category.

The organization reports "we have 15 controls for External Fraud" without knowing whether any of them address the specific generic vulnerability that would enable the next incident. They are counting controls, not assessing coverage.

4. Phantom Risks and Hidden Risks

The consequence-based register simultaneously overcounts (the same attack path appears as multiple "risks" in different Basel categories) and undercounts (genuinely different attack paths with different control needs are merged in the same category). Risk-based prioritization — the core purpose of the risk register — becomes unreliable because the unit of analysis (the "risk") doesn't correspond to the unit of action (the preventive control set).

5. Risk Appetite Becomes Unverifiable

A typical risk appetite statement reads: "The bank accepts a maximum annual loss of €5M from External Fraud events." This is unverifiable against controls because it doesn't specify which attack paths are within appetite. It can only be monitored retrospectively against loss history. By the time you know you've exceeded appetite, the losses have already occurred.

A cause-based appetite statement would read: "Residual risk from credential theft is managed to a maximum of [X] incidents per year, controlled by MFA enforcement achieving >99% coverage." This can be monitored in real-time through control performance metrics.

6. Incident Learning Becomes Circular

When incidents are classified post-hoc into Basel categories, the "root cause analysis" often produces findings like: "Root cause: External Fraud — Systems Security. Remediation: Enhance systems security controls." The category name is the finding, and the finding is the category name. No new causal knowledge was generated. The organization has not learned which specific generic vulnerability was exploited, which means it cannot determine which specific control would prevent recurrence.

Ten years of Basel-compliant loss data tells the bank how much was lost in each category. It tells the bank nothing about which generic vulnerabilities were repeatedly exploited and therefore nothing about which controls would deliver the highest marginal return on investment.

What's Missing: A Mandatory Causal Commitment

The root cause of all six failures is the same: there is no structural requirement to name the cause before classifying the risk.

ISO 31000 provides the process grammar (identify → analyze → evaluate → treat). NIST CSF provides the control verbs (Identify → Protect → Detect → Respond → Recover). But neither provides the threat nouns — a closed, cause-side vocabulary that forces the risk identification process to produce specific, testable, falsifiable claims about which mechanism could produce which consequence.

What's needed is a mandatory decomposition rule: before a risk entry can be considered "identified," the analyst must name the generic vulnerability that would be exploited. Not the outcome. Not the actor. Not the business domain. The mechanism.

This is what a cause-oriented framework forces: every risk entry must commit to a causal claim. "External Fraud — Systems Security" is not a valid risk identification because it names no mechanism. "Server-side code flaw in the customer-facing web application, leading to unauthorized database access" is a valid identification because it names the generic vulnerability (code flaw), the system context (web application), the attack vector (exploitation), and the resulting system risk event (database compromise). From that identification, the control mapping follows directly and deterministically.

The Fix: Layering Cause on Top of Consequence

The solution is not to abandon Basel's categories. They serve their capital calculation purpose. The fix is to layer a cause-side taxonomy underneath the existing loss classification, so that every loss event is tagged with both its Basel category (for capital adequacy) and its causal mechanism (for risk reduction):

Basel Layer:   "External Fraud — Systems Security"     →  €1.2M loss
Cause Layer:   Phishing → Credential Theft → Function Abuse  
               → [SRE: Account Compromise]  
               → [DRE: Confidentiality — Wire transfer data exposed]  
               → [BRE: €1.2M fraudulent transfer]

Both layers serve their purpose. Neither replaces the other. But only the cause layer enables the bank to answer the question that actually matters for risk reduction: "What should we fix so this doesn't happen again?"

The cause layer also enables something that no amount of Basel-compliant loss data can provide: cross-organizational comparability. When two banks classify the same incident using cause-side categories anchored to generic vulnerabilities, they can compare not just how much they lost but why they lost it — and therefore which controls are structurally effective against which mechanisms.

That is the difference between operational risk management as a documentation exercise and operational risk management as an engineering discipline. The documentation exercise satisfies the regulator. The engineering discipline protects the bank.

Conclusion

Banks have built their operational risk registers on a foundation designed for accounting, not analysis. Basel OPE25 Table 2 classifies financial losses by consequence domain. ISO 31000 and COSO ERM require cause identification. The risk register is caught between two masters, and it resolves the tension by pretending that consequence labels are causes.

The result: risk registers that cannot support targeted control mapping, cannot distinguish between different attack paths, cannot separate system events from data events from business events, and cannot generate causal knowledge from incident data. They satisfy audit requirements and generate impressive-looking heat maps. They do not reduce risk.

The structural fix is conceptually simple: require every risk entry to name the generic vulnerability. Force the causal commitment before permitting the consequence classification. This single rule — which no existing risk standard mandates but every risk standard's logic demands — would transform operational risk registers from backward-looking loss catalogs into forward-looking threat models.

Banks know how much they lost. They need to know why they lost it. The answer is not in Basel's event categories. It is in the causes those categories were never designed to capture.