◆ Quick answer
An operational loss event log should include event ID, date occurred and date discovered, business line, Basel event category, loss typology, description, root cause, gross loss, recoveries, insurance recovery, net loss, a near-miss flag with potential loss, customers affected, regulatory impact, data breach, outage hours, owner, status and remediation due date, plus a quick three-field root cause (what happened, why, fix). Log every financial loss at or above a set threshold (the Loss Monitoring kit uses $1,000 gross), every near miss regardless of size, and every event with regulatory or customer impact even at $0.
Guide vs. template
This guide explains what belongs in the template. The paid template gives you the editable working files so you're not rebuilding from a blank page.
Paid template includes
- ◆ Loss event log for losses and near misses across the 7 Basel event types, with typologies (account takeover, APP scams, check fraud, synthetic identity and more)
- ◆ Automatic net loss, escalation tier, internal timeline and bank-partner notice flag on every event
- ◆ Dashboard by category, business line, tier and quarter, with top 10 losses, largest near misses and charts
- ◆ Escalation Alerts: open Tier 3–4 events and outstanding bank notices, with who to escalate to
What is this template for?
An operational loss event tracking template is the log risk teams use to record every operational failure — fraud losses, system outages, processing errors, refunds and fines — with its Basel event category, gross loss, recoveries, insurance, net loss, root cause, owner and remediation status. The useful version captures near misses too: a card-testing attack your fraud rules blocked is a $0 entry that proves a control worked, and an insider-access event with no financial loss can still carry regulatory impact and a bank-partner notice. Loss data is the raw material for the rest of your operational risk program — it tests your risk and control self-assessment (RCSA) ratings, calibrates your key risk indicator (KRI) thresholds, and gives your bank partner evidence that your program reflects what actually happens.
◆ Audience
Who needs this.
- ◆ Your bank partner or examiner asked whether you track operational losses and near-misses, and you don't have a structured log.
- ◆ You're building an operational risk program and need the Basel-aligned loss data foundation that RCSA and KRI monitoring sit on top of.
- ◆ Losses are scattered across incident tickets, finance write-offs, and email threads with no single view of net loss by category.
- ◆ Your risk committee wants loss trends by business line and severity, and assembling that view takes you a week each quarter.
- ◆ You've had near-misses that never got documented — which means the control lessons evaporated with them.
◆ Required fields
What every row needs.
The fields that make this template defensible to an auditor, bank partner, or examiner — and what goes in each.
| Field | Why it matters | Example |
|---|---|---|
| Event ID, date occurred, and date discovered | The gap between occurrence and discovery is itself a finding — a long gap says something about your detection controls. | LE-2026-007: occurred 2026-04-02, discovered 2026-05-20 — 48 days to discover unauthorized account viewing |
| Business line | Loss trends by business line show where operational risk concentrates and who owns remediation. | Payments; Lending / Credit; Customer Operations; Technology / Engineering; Compliance; Finance |
| Basel event category and loss typology | The seven Basel operational loss event types are the taxonomy bank partners use; a typology field (account takeover, synthetic identity, reconciliation break) makes patterns visible inside each category. | External Fraud / Account takeover; Execution, Delivery & Process Management / Payment error; Business Disruption & System Failures / System outage |
| Gross loss, recoveries, insurance recovery, and net loss | A $12,500 misrouted payout that was fully recovered is a very different event from an unrecovered outage — the log needs all four numbers to show it. | Payout misroute: $12,500 gross − $12,500 recovered = $0 net; office water damage: $22,000 gross − $18,000 insurance = $4,000 net |
| Near-miss flag and potential loss | Near misses are leading indicators — they show where controls almost failed before the loss shows up in the numbers. | Card-testing attack blocked: near miss = Y, gross $0, potential loss $60,000 |
| Customers affected, regulatory impact, data breach, and outage hours | These fields drive escalation independent of dollar amount — a $0 event with regulatory impact outranks a $20,000 event with none, and a near miss that involves a data breach still escalates. | Insider account viewing: $0, regulatory impact = Y, data breach = Y → Tier 3; fee disclosure error: 2,900 customers → Tier 4 |
| Root cause and quick root cause analysis | Losses without causes get re-suffered. Three short fields — what happened, why, fix — keep root cause analysis proportionate for smaller events; Tier 3 and 4 events get a full deep dive. | What happened: pipe burst damaged office flooring. Why: line not inspected; sensor offline. Fix: add lines to inspection; sensors on separate power |
| Owner, status, and remediation due date | The log should show that each loss changed something — a control, a process, an architecture decision — with a named owner driving it to done. | Region outage: active-active deployment and quarterly failover test — owner Dev Patel, status In Progress, due 2026-12-31 |
| Escalation tier, internal timeline, and bank-partner notice | Calculating these from the thresholds removes judgment calls about who hears what and when, and flags the bank notices that are still outstanding. | Tier 3: chief risk officer (CRO) and CEO plus compliance and legal, same business day; bank-partner notice Required, bank notified = Y |
◆ Worked example
Example loss event log entries
| External fraud event | LE-2026-001 — Credential-stuffing attack drained 47 wallets through peer-to-peer transfers before step-up authentication triggered. Root cause: no multi-factor authentication (MFA) on a legacy account type. Gross loss $47,350, recoveries $3,100, net $44,250 — Tier 2 (gross of $10,000 or more). Fix: MFA for all accounts and velocity rules on new devices. |
|---|---|
| Disclosure error with regulatory impact (Clients, Products & Business Practices) | LE-2026-003 — An instant-transfer fee was shown only after the confirmation screen in one app version; fees refunded to 2,900 customers. Gross loss $86,400, no recoveries. Regulatory impact = Y, and 1,000+ customers affected makes it Tier 4. Root cause: UI change released without compliance review. |
| System outage with bank-partner notice | LE-2026-011 — Cloud region outage took the app and API down for 4.5 hours; $118,000 of service-level agreement credits paid to partners. Tier 4 (120,000 customers affected), and the 4+ hour outage flags bank-partner notice. Forgone transactions are not counted — only out-of-pocket costs. |
| Near miss at $0 | LE-2026-006 — Card-testing attack: 2,847 test authorizations blocked before any loss. Logged as a near miss with $0 loss and $60,000 potential loss. Lesson: detection worked because rules were tuned the week before — document the pattern and keep the rule. |
| Zero-dollar event with regulatory impact | LE-2026-007 — A support agent viewed 38 customer accounts with no ticket over seven weeks; no funds moved. Net loss $0, but regulatory impact and data breach = Y make it Tier 3 with bank-partner notice required. It occurred April 2 and was discovered May 20 — a 48-day detection gap. |
◆ Implementation roadmap
How to roll this out.
Set capture thresholds before logging anything
Owner · Operational risk lead with chief financial officer (CFO) input
Output · Documented standards: financial losses at or above a set threshold ($1,000 gross in the kit) get a log entry; near misses and regulatory or customer-impact events are logged at any amount
Seed the log with your first batch of historical events
Owner · Operational risk lead with finance, fraud and engineering
Output · About 10 events from the last 12 months — largest fraud loss, misrouted payments, longest outage, refunds, vendor failures, fines, misconduct, scam reimbursements, a near miss and a reconciliation break — so the dashboard is never blank
Classify each event using the Basel categories and a decision guide
Owner · Event owner with risk review
Output · Consistent classification — employee acting on purpose means Internal Fraud; system failure means Business Disruption, a person's processing error means Execution; multi-category events classified by primary cause
Wire dollar and non-dollar escalation tiers
Owner · Operational risk lead + CRO
Output · Tiers by gross loss (before uncertain recoveries): under $10,000 to the team manager within 5 business days; $10,000+ to the risk manager and CFO within 2 business days; $100,000+ to the CRO and CEO the same business day; $1,000,000+ to the board immediately — plus non-dollar triggers: 100+ or 1,000+ customers, regulatory impact, data breach, and outages of 2+ hours
Run root cause analysis proportionate to severity
Owner · Event owner with second-line challenge
Output · Quick three-field root cause on every event; a full deep dive with timeline, five whys, corrective actions and lessons learned for every Tier 3 and 4 event
Report trends and feed the rest of the risk program
Owner · Operational risk lead
Output · Monthly dashboard by category, business line, tier and quarter for the risk committee — with each loss triggering a review of the related RCSA control, a check on KRI thresholds, and an issue for each corrective action
◆ Ready to use it?
Download the Loss Monitoring & Event Tracking Kit.
Use the guide to understand the structure, or buy the editable template to move faster.
◆ FAQ
Frequently asked questions.
What counts as a loss event versus a near miss? ⌄
A loss event is an operational failure that produced an actual out-of-pocket loss or impact. A near miss is an event that could have caused a loss but didn't, because a control caught it or luck intervened. Both belong in the log: a card-testing attack your fraud rules blocked is a $0 near miss that validates the control. A near miss that also involves a data breach, regulatory impact or many customers still escalates on those triggers.
What are the 7 Basel operational loss event categories? ⌄
Internal Fraud; External Fraud; Employment Practices & Workplace Safety; Clients, Products & Business Practices; Damage to Physical Assets; Business Disruption & System Failures; and Execution, Delivery & Process Management. The 2026 US capital proposal uses the same seven event types. When events span categories, classify by primary cause and note the secondary effect in the description.
What is the minimum loss amount worth logging? ⌄
Pick a threshold and write it down — the Loss Monitoring kit uses $1,000 gross, with smaller losses tallied monthly. Three things get logged regardless of amount: near misses, any event with regulatory impact, and any event with customer impact. Also check your bank partner agreement, which may set its own reporting minimums and notification timelines.
What is the difference between gross loss and net loss? ⌄
Gross loss is the full out-of-pocket cost before anything comes back. Net loss subtracts recoveries (reversed payments, returned funds, amounts recovered from a vendor or fraudster) and insurance recoveries. A misrouted $12,500 payout that was fully recovered nets to $0 but still gets logged: the process failure happened. Escalation tiers key off gross loss, because recoveries are uncertain when an event is first reported.
When should a loss event be escalated to executives or the board? ⌄
Set tiers by gross loss — for example: under $10,000 to the team manager within 5 business days; $10,000 or more to the risk manager and CFO within 2 business days; $100,000 or more to the CRO and CEO the same business day; $1,000,000 or more to the board or audit committee immediately, with a full report and remediation plan within 48 hours. Then layer non-dollar triggers on top: 100+ customers affected, regulatory impact, a data breach or an outage of 2+ hours forces Tier 3, and 1,000+ customers forces Tier 4.
Do fintechs need Basel-aligned loss tracking if they are not banks? ⌄
No US rule sets a loss-data standard for non-banks, and fintechs don't hold operational risk capital. But sponsor banks oversee the risks of their fintech partners, their examiners look at that oversight, and many program agreements require loss and incident reporting. A consistent log using the same seven event types your bank partner uses answers those questions — and connects your losses to your RCSA, KRIs and issues instead of living in a silo.