Operational Risk Event Management: The Basel Taxonomy as Your Evidence Layer

Category: Enterprise Risk Author: Cody Swidler Tags: operational risk, loss events, Basel, event taxonomy, near-miss, loss data, KRIs

A wire went out to the wrong account. It got caught nine days later during a reconciliation, the counterparty returned most of it, and the desk absorbed the rest as a small write-off. Someone opened a ticket, someone closed the ticket, and the whole thing evaporated into an operations queue. Nobody logged it as an operational risk event. Nobody linked it to the payment-processing risk that was rated "unlikely" in the register. And so the single most honest piece of data the program produced that quarter — a real failure, with a real dollar amount, tied to a real broken control — was thrown away because there was nowhere to put it.

This is the quiet tragedy of most risk programs. They spend enormous energy scoring risks in workshops — arguing about whether a likelihood is a 3 or a 4 — while the events that would settle the argument are dissolving in ticketing systems, incident bridges, and inboxes. Your loss events are the only data in the entire program that isn't a guess. An event is not an estimate of what might happen. It is a record of what did. Capture it properly and it becomes the evidence layer everything else should be built on.

An Event Is What Actually Happened

I've written before about the connected GRC model — the idea that risks, controls, issues, and incidents are not four registers but four entities in one system. Events are the layer that makes the whole thing honest, because an event is the point where the abstraction touches the ground. A risk is a hypothesis about the future. A control is a bet that the hypothesis won't come true. An event is the moment the future arrives and tells you whether you were right.

Once you see events that way, three things follow automatically, and each one replaces a guess with a measurement. Frequency drives likelihood — a risk with eleven logged events this year is not "possible," it is occurring, and the count is your likelihood input whether the workshop likes it or not. Net loss sets the impact floor — if an event already cost the firm a quarter of a million dollars, the impact of the risk it came from is at least that, in currency, regardless of how optimistically anyone scored it. And the failed control is a free control test — an event is, definitionally, a case where the control that was supposed to hold did not. You paid for that test in real money. The least you can do is read the result, which is the whole argument behind a control that isn't tested being a hope.

That last point is the one programs miss most often. When a control fails in a test environment, everyone treats it as a finding. When the same control fails in production and causes a loss, everyone treats it as an incident to be closed. It is the same signal — the control does not work — but only one of the two ever makes it back to the risk rating. The event is the mechanism that carries the production failure home.

Why You Need a Taxonomy, Not a Freeform Log

The reason most event capture fails is not that firms don't record events — it's that they record them in whatever words the person on shift happened to use. One analyst writes "payment error," another writes "ops mistake," a third writes "fat finger." Six months later you cannot answer the only question that matters: are we losing money the same way repeatedly? A freeform log is a pile of anecdotes. A taxonomy turns it into data you can trend, compare, and defend.

The Basel Committee solved this problem years ago for the banking world, and its operational risk event-type taxonomy is the closest thing the discipline has to a common language. You do not need to be a bank to use it. The categories are generic enough to fit a fintech, a SaaS company, or a health system, and adopting a recognized standard means your data can be benchmarked against consortium loss databases instead of stranded in your own vocabulary. The taxonomy has two dimensions worth learning: what happened, and where it happened.

The Seven Level-1 Event Types

Basel sorts every operational loss into one of seven Level-1 categories based on the nature of the event. Internal Fraud covers losses from acts by insiders intended to defraud or circumvent the law — unauthorized trading that breaches limits, or an employee stealing assets. External Fraud is the same intent from a third party — theft, forgery, and check kiting on the low-tech end, account takeover and systems intrusion on the high-tech end. Employment Practices and Workplace Safety captures losses from acts inconsistent with employment law or agreements — discrimination claims, wrongful-termination settlements, and workplace-injury liability.

Clients, Products and Business Practices is the big, expensive one: losses from an unintentional or negligent failure to meet an obligation to clients, or from the nature of a product. Think mis-selling, disclosure failures, fiduciary breaches, market manipulation, antitrust, and product defects — the category that produces the nine-figure regulatory settlements. Damage to Physical Assets covers loss or damage from disasters and other events, natural or human-made. Business Disruption and System Failures captures the outages — hardware and software failures, telecommunications problems, utility disruptions. This is where most of a modern technology firm's operational losses actually land, which is why I keep pushing resilience teams to treat their incident record as feedstock for risk, not just an outage log.

The seventh, Execution, Delivery and Process Management, is the workhorse — losses from failed transaction processing or process management. Data-entry errors, missed deadlines, botched reconciliations, delivery failures, collateral mismanagement, disputes with vendors. It is rarely the most expensive category, but it is almost always the most frequent, and frequency is exactly the signal that should be feeding likelihood. Under each of these seven sit representative Level-2 subcategories — Internal Fraud splits into Unauthorized Activity and Theft and Fraud; Execution splits into Transaction Capture, Monitoring and Reporting, Customer Intake and Documentation, Vendors and Suppliers, and more. You do not have to adopt every Level-2 line on day one, but you should classify at Level 1 from the very first event, because that is the level at which patterns become visible.

The Eight Business Lines — Where It Happened

The second dimension is location. Basel defines eight standardized business lines — Corporate Finance, Trading and Sales, Retail Banking, Commercial Banking, Payment and Settlement, Agency Services, Asset Management, and Retail Brokerage. The banking labels won't map cleanly onto a non-bank, and that's fine — the point is not the specific names but the discipline of tagging every event to a consistent organizational unit so you can answer "which part of the business is bleeding?" A software company might swap in product lines or platform teams. What matters is that the dimension exists and is applied uniformly, because a loss profile that tells you Execution failures are concentrated in one settlement function is a profile you can act on. A loss profile that only tells you the firm had losses is not.

The Three Dates and the Anatomy of a Loss

Here is where amateur event logs fall apart and disciplined ones pull ahead: a single operational loss has not one date but three, and conflating them corrupts every trend you'll ever draw. The date of occurrence is when the event actually happened — when the wire went out wrong. The date of discovery is when you found out — the reconciliation nine days later. The date of accounting is when the loss hit the general ledger, which can be months later still, after the recovery attempt fails and finance recognizes the write-off. Capture all three. The gap between occurrence and discovery is itself a control metric — a long gap means your detective controls are slow, and that's a finding hiding inside your loss data.

The money has structure too. Gross loss is the full financial impact before anything comes back. Recoveries are the amounts you claw back independently of the event itself — insurance payouts, counterparty returns, restitution. Net loss is gross minus recoveries, and it is the number that matters for risk, because it is what the firm actually absorbed. A gross loss of five million with a four-and-a-half-million insurance recovery is a very different risk story than a five-million net loss, and a register that only records one figure tells the wrong one. Net loss is what sets the impact floor. It is also, incidentally, exactly the number regulators and consortium databases want, so recording it cleanly costs you nothing extra and buys you comparability.

Boundary Events and the Losses You'll Miss

Two categories of event routinely escape operational risk capture because they get filed under a different risk type first. Basel calls these boundary events. A credit-related operational risk event is an operational failure that ends up as a credit loss — a loan booked with fraudulent documentation, or collateral that was mismanaged and couldn't be seized. For regulatory capital these are treated as credit risk, so the credit team owns the loss and the operational risk team never hears about it — even though the root cause was a broken process, and the process is what you can actually fix. A market-related operational risk event is the mirror image: an operational error that surfaces as a trading loss, like a mispriced position from a bad data feed, which Basel does treat as operational risk. The rule I use is simple — flag boundary events in the operational risk system for management purposes even when they're accounted for elsewhere for capital. You lose visibility into your own control failures the moment you let the accounting treatment decide what you're allowed to learn from.

The Near-Miss Is Your Only Leading Indicator

Everything above is about losses — events that cost money. But the most valuable event in the book is often the one that cost nothing. A near-miss is an event that occurred but produced no net loss, either through luck or through a control that caught it just in time. The wrong wire that got recalled before it settled. The unauthorized trade that happened to move in your favor. Firms ignore these because there's no dollar amount to book, which is exactly backwards. A loss is a lagging indicator — it tells you about a control that already failed. A near-miss is a leading indicator — it tells you about a control that is failing and hasn't cost you yet. Capturing near-misses is how you get ahead of the loss instead of forever cleaning up after it, and it turns your event log from an obituary into an early-warning system.

From Events to Appetite

Once events are captured against a consistent taxonomy with clean net-loss figures, they stop being a filing exercise and start driving the program. The most direct connection is to appetite. A rolling twelve-month net operational loss is one of the cleanest key risk indicators you can run — it aggregates every event into a single trendable number you can hold against a board-approved threshold, which is precisely the mechanism I laid out in turning a risk appetite statement into thresholds and KRIs. When the rolling total crosses the amber line, that's not a debate — it's your own realized losses telling you the environment has shifted. You can slice the same data by event type to see which of the seven categories is driving the breach, and by business line to see where, and now the escalation conversation is about evidence instead of anxiety.

This is the whole point of treating events as the evidence layer. The workshop-scored register asks people to imagine the future and grade it. The event log records the present and counts it. When the two disagree — when a risk rated "unlikely" has a dozen events behind it — the events win, because they happened. Build the discipline to capture every event against the Basel taxonomy, record its three dates and its net loss, flag the boundary cases, and welcome the near-misses, and you'll have something most programs never achieve: a risk picture that answers to the facts.

Cody Swidler is the founder of PivotRisk and Head of Platform Resiliency at Apex Fintech Solutions. He has built and scaled GRC, resilience, and risk programs across Microsoft, Twilio, Box, Zayo, and Miro.