Operational risk loss data collection that starts from the ledger: agents find every loss event and argue its Basel type, and your analysts decide
Every loss in the ledger captured, and the loss database tied to the GL each month.
See one case, screen by screen ↓Operational risk loss data collection is how a bank captures every operational loss event, groups its costs and recoveries, classifies it by Basel event type and business line, and keeps the loss history its risk management relies on. Operational Risk Loss Data Collection starts from the general ledger instead of forms: agents sieve the week's entries, group and classify the loss events with cited reasoning, and an analyst approves each one, checked by the second line.
AI use cases in banking: a buyer's guide to agentic AI for bank and credit union operations →
Updated
Operational risk loss data collection at most banks starts from a form. A business line risk coordinator records a loss event in the GRC system when someone remembers, with the amount from their own records. Finance books the reimbursements, legal fees, suspense write-offs, refunds and later recoveries to the general ledger on its own schedule, and the operational risk analyst is not told.
So losses nobody submits sit in legal expense or suspense until a quarter-end spreadsheet finds them, if it does. One loss is entered as three events, or with its recovery netted into the gross loss. Business lines tag the event type they recognize: a wire sent on a spoofed email becomes a processing error because a callback was skipped, when the Basel definitions call it External Fraud. And the loss database is tied to the ledger a quarter late, after the people who knew the answer have moved on.
Estimated split for one loss found in the ledger rather than reported on a form: about 45 days when it surfaces at the quarter-end tie-out, against the 5-day target the working solution is designed to. Our arithmetic, kept modest.
Seven agents sieve the ledger, group and classify each loss with cited reasoning, and tie the database to the GL; the analyst decides and the second line checks.
Corvane National Bank, a $92 billion regional bank, Thursday, September 3, 2026. A business email compromise on a commercial client's wire has left three entries in three accounts over a month, and the business line has tagged it a process error. Here is what happens next, screen by screen, in the working solution.
Elena opens This week's ledger. The Finder agent has read 4,812 entries in the 38 accounts where operational losses land, plus 214 incident tickets. Layer by layer it set aside 1,906 reversals and reclasses, 1,388 accruals and provisions, 1,071 normal charges and 66 credit-boundary charges, leaving 381 entries in 68 candidate events: 29 at or above $10,000, 39 below and 6 near misses.
17 of the 29 losses at or above $10,000 were never submitted on a form.
Elena opens the first layer: 1,906 reversals and reclasses under rule S-1. Each example shows its ledger entries, such as JE 26-0901-0441, a $12,300 reclass reversed by JE 26-0901-0442. A "This is a loss" button sends any entry back to the Grouper agent, logged with her name.
Rule S-1: “An entry and its reversal or reclass within 30 days net to zero and are not a loss.”
A $182,400 reimbursement to commercial client Halvorsen Marine Supply on August 4, a $36,000 legal fee on August 20 and a $41,500 recovery on September 2 posted to three different accounts. The Grouper joined them by the wire reference FW-0803-55120, incident ticket INC-26-11873 and legal matter 26-118, each step cited, with occurrence August 3 and discovery August 4 on the timeline.
Gross loss $218,400 · recovery $41,500 recorded separately, never netted · net loss $176,900
Rafael Quintero's line tagged the loss Execution, Delivery and Process Management on August 5: “We skipped the callback.” The Classifier proposes External Fraud › Theft and Fraud, Basel business line Payment and Settlement, at 0.93 confidence. It cites the look-alike email domain in the ticket, the Basel definition and Corvane's rule B-3, and keeps the skipped callback on the record as the cause of the control failure, linked to control WIR-CB-02.
Rule B-3: “When a third party's deception causes the loss, External Fraud prevails; the failed control is the cause.”
Elena asks why the skipped callback is not the event type. The answer cites rule B-3 and the Basel definition, and explains that the callback failure stays linked to control WIR-CB-02, so Treasury Management's RCSA still sees it. Two more questions are offered: why the legal fees belong to the event, and whether the recovery should reduce the gross loss.
“Because the loss was triggered by a third party's deception, not by a processing mistake on its own.”
Approving LE-26-0847 changes the business line's tag, so it is a reclassification. Elena picks reason code R2 Boundary rule (fraud versus process) and writes a note for the validator. The event goes to Jonah Whitcombe for a second-line check, and a notice to the business line is drafted.
Her note: “Look-alike domain in INC-26-11873; rule B-3. Callback failure kept as the cause (WIR-CB-02).”
Jonah's queue holds every reclassification, every split and every event of $100,000 or more, one by one, and routine batches checked by a 1-in-5 sample. He sees the move from Execution, Delivery and Process Management to External Fraud, Elena's reason and note, and the same cited reasoning she saw, and confirms. Elena could not have checked it herself.
Shown to the maker: “You made this decision. A different person must check it: separation of duties.”
Rafael's Commercial Banking queue shows the notice for LE-26-0847: the new event type, rule B-3, and that the skipped callback stays linked to WIR-CB-02 in his RCSA. He can accept it, or dispute it with a reason by Tuesday, September 8. Below it, LE-26-0868, LE-26-0882 and LE-26-0879 wait for him to confirm ownership within three business days.
Below the $10,000 threshold, the Grouper found 31 recurring events in four groups: debit card fraud write-offs, ATM and teller cash differences, deposited check fraud and goodwill fee refunds, $38,945 in all. Each stays its own event. Elena approves them in one action and the validator checks 7 at random. Six near misses are kept with no loss, such as a wire to a look-alike payee stopped by a callback with $412,000 not sent.
The Reconciliation agent ties August across 38 accounts: general ledger $4,322,915, loss database $4,192,340, difference $130,575. Every dollar is explained: $61,200 of credit-boundary charges and an $18,400 timing event excluded by rule, the $36,000 legal fee now in LE-26-0847, and $14,975 of fee refunds now LE-26-0882. With nothing unexplained, Celeste signs the August reconciliation, due Friday, September 11.
Unexplained: $0. Signing is blocked while any difference is open.
The same week's ledger, seen by four of the people who carry it, from the first line to the Head of Operational Risk: what their month looked like, and what it looks like now.
Seven agents sieve the ledger, group and classify each loss with cited reasoning, and tie the database to the GL; the analyst decides and the second line checks.
Reads every entry in the 38 accounts scanned and the incident tickets each week, and sets aside reversals, accruals, normal charges and credit-boundary charges, each with the rule that set it aside.
Joins entries into one event by wire reference, ticket, legal matter, customer and dates, adds recoveries and related costs, re-opens an event when a related entry posts, and proposes splits.
Proposes the Basel Level 1 and 2 event type, the Basel and internal business line and the causal factor in one plain sentence, citing the ticket, the Basel definitions and the bank's boundary rules.
Drafts the event description, required at $100,000 and above, and the reclassification notice to the business line.
Checks each event against restricted links from case management, applies the “Restricted · BSA team” flag and masks account numbers.
Ties the loss database to the general ledger each month, account by account, and explains every difference with the entry or rule behind it.
Builds the risk committee summary, the trends and the quarterly loss history file in the FR Y-14Q Schedule E layout, and runs its field checks.
Checks every reclassification and split. The agents propose; a named person decides.
Ask why an event has its type, which entries are in it, or what is still unexplained. Every answer points to the ledger entry, ticket or rule behind it.
Why isn't the skipped callback the event type?
Because the loss was triggered by a third party's deception, not by a processing mistake on its own. Rule B-3 classifies such losses as External Fraud even when a control failed, which matches the Basel definition. The skipped callback stays on the event as the cause of the control failure and is linked to control WIR-CB-02, so Treasury Management's RCSA still sees it.
Should the $41,500 recovery reduce the gross loss?
No. A recovery is recorded separately with the same reference number and never netted into the gross loss. The event keeps gross $218,400 and a recovery of $41,500; the net $176,900 is for management reporting. The funds came from the receiving bank, not an insurer, and the loss is below the crime policy's $250,000 deductible, so there is no claim.
Which August differences are still unexplained?
Before this week, two: the $36,000 legal fee for matter 26-118 and $14,975 of fee refunds. The legal fee is now part of LE-26-0847, and the refunds are proposed as LE-26-0882. When both are approved, nothing is unexplained and Celeste Odum can sign.
Show this week's small recurring losses I can approve together
31 events in four groups, $38,945 in all: debit card fraud (14), cash differences (9), deposited check fraud (5) and goodwill fee refunds (3). Each stays its own event, never bundled; approving them together sends a batch to the validator, who checks 7 at random.
13 screens from the working solution, on its sample data. Pick one to see it large.
Thresholds, clocks, accounts and boundary rules are settings. Every change is a new version, approved by the Head of Operational Risk and on the audit trail.
| Setting | Default | Choose from |
|---|---|---|
| Collection threshold | $10,000 gross | Events at or above it are decided one by one; smaller events are kept and may be approved together, never bundled into one event |
| Description required | $100,000 and above | Drafted by the Narrative agent; the analyst owns the text |
| Second-line checks | Reclassifications, splits and events of $100,000 or more, one by one | Routine batches checked by a random 1-in-5 sample |
| Clocks | Decide a candidate event within 5 business days | Confirm ownership within 3, second-line check within 5, reconciliation signed by business day 8; anything overdue goes to the Head of Operational Risk, events of $1,000,000 or more the same day |
| Accounts scanned | 38 accounts in 8 groups | Operational losses, fraud losses, legal expense, suspense write-offs, customer remediation and refunds, settlements, loan servicing charges for the credit-boundary check, and recoveries |
| Event types and boundary rules | Basel Level 1 and 2, the bank's Level 3, rules B-1 to B-9 (v4.2) | Credit boundary, timing events, fraud versus process, internal involvement, outage versus processing, legal costs, one event across lines, small recurring losses, near misses and gains |
| Confidence to propose | 0.80 | Below it the Classifier asks instead of proposing, and the Grouper asks before joining entries |
| Data and privacy | GLBA need-to-know | Account numbers masked to the last four, customer names replaced on exports, supporting records kept at least five years, event data never used to train models |
Every figure is labelled: a target the solution is built to, an estimate, a typical published result, or a proven one.
“demo” = seen in the working solution, on its sample data · “target” = the design goal, measured in the live solution · “estimated” = our estimate. Regulations are named as context only: the Federal Reserve's FR Y-14Q Schedule E instructions, 31 CFR 1020.320(e) (SAR confidentiality) and 31 CFR 1010.430 (five-year retention of BSA records). Corvane National Bank, Halvorsen Marine Supply and the people, events and records named on this page are fictional: characters and sample data in the working solution.
Operational risk loss data collection is how a bank captures every operational loss event, groups its costs and recoveries, classifies it by Basel event type and business line, and keeps the loss history its risk management relies on. Operational Risk Loss Data Collection starts from the general ledger instead of forms: agents sieve the week's entries, group and classify the loss events with cited reasoning, and an analyst approves each one, checked by the second line.
Each week the Finder agent reads every entry in the accounts where losses land, such as operational losses, fraud losses, legal expense, suspense write-offs and customer remediation, and the incident tickets. Whatever it sets aside carries a rule, and a person can send it back. In the sample week, 17 of the 29 losses at or above $10,000 had never been submitted on a form.
The Classifier agent proposes the Basel Level 1 and 2 event type, the business line and the cause in one plain sentence, citing the ticket, the Basel definitions and your boundary rules, beside the business line's own tag. Below 0.80 confidence it asks instead of proposing. Changing a business line's tag needs a reason code and a second-line check.
No. A recovery is recorded separately under the same reference number, and the gross loss stays before recoveries. The net loss is shown for management reporting. In the sample case, a $41,500 recovery stays beside a $218,400 gross loss, for a net loss of $176,900.
Each month the Reconciliation agent ties the loss database to the general ledger account by account and explains every difference with an entry or a rule: credit-boundary charges, timing events, costs grouped into an event, or losses still waiting for approval. The Head of Operational Risk can sign only when nothing is unexplained.
The Reporting agent builds a quarterly loss history file in the FR Y-14Q Schedule E layout and checks its fields: the dates, recoveries in their own column and one reference number per event. Restricted links are never in the file. It goes to the Head of Operational Risk for approval; the agent never files anything.
Yes. The agents find, group, classify and draft; the analyst approves, reclassifies or splits, the second-line validator checks, and the Head of Operational Risk signs the reconciliation and approves every settings change. Nobody checks their own decision, every override has a reason code, and everything is on the audit trail.
The Agentic Solution Engine builds and deploys it from your requirements and documents, such as your loss accounts, event type and boundary rules, thresholds and last quarter's loss events, and it goes live once every quality gate has passed. We will walk you through it on a month of your own ledger first.
Closures asked for only when the proof is there, and MRA dates kept on the record.
1-min demoOperational Resilience ManagementEvery recovery time proven by test evidence, every breach fixed with an owner and a date.
1-min demoALCO ReportingAn approved ALCO pack in 3 days, with every change explained and cited.
1-min demoWe'll run Operational Risk Loss Data Collection on a month of your loss accounts and last quarter's loss events.