Machine-learning automation, made trustworthy by design

Context

Banks check themselves constantly. Operational risk teams run thousands of recurring control tests — each one a written procedure that a risk officer follows to confirm a process is working as it should. Most of that work was manual: pull a sample, check the records by hand, log the result in a spreadsheet.

A data science organization had begun automating some of those tests with rules and models. Leadership asked for a well-designed experience for the newly automated ones. I argued for something bigger: one workflow for every test, automated or not, so officers never worked across two systems and automation never became its own silo.

I owned that platform end to end — the workflow for running tests, the screens where officers made decisions, the procedure search, and the dashboard leadership used to monitor the program. Data science built the rules and models; my job was to make their output something officers would act on and auditors would accept. Along the way I grew the product team behind it from zero to twenty.

Problem

Automation couldn’t scale one test at a time, because every test had its own bespoke procedure. Officers had no single view of what had run, what had failed, and what needed a person. Procedures lived in scattered documents, and officers often worked from outdated versions. And when model output did reach an officer, it arrived as a bare score with no reason attached — so they redid the work rather than trust it.

The bank wanted daily confidence that risk was under control. The answer arrived monthly.

Approach

Deciding what to automate first

With thousands of tests and a finite team, prioritization was the real product decision. Every test was scored on four factors — manual effort, frequency, severity of the underlying risk, and feasibility of automating it — and the scores, not the loudest stakeholder, set the roadmap. Rule-based, high-effort tests went first. Judgment-heavy tests got machine-learning triage with an officer making the final call. Low-effort tests waited or stayed manual.

Four principles

These governed every screen, and they shaped how the data science team delivered their work:

1. Every flag comes with a reason. A score without an explanation gets re-reviewed, which erases the time saved.
2. Officers keep the decision. Automation clears the routine and prioritizes the rest; people decide the exceptions.
3. Every override is captured, with a reason. That record trains the models and gives audit a defensible trail.
4. The current procedure is one search away. No one should wonder whether they’re following the right version.

What we designed

Not all of this had launched by the time I left, and the examples and figures throughout are altered to protect proprietary detail.

One definition for every test. Population, rule logic, sampling method, owner, frequency. Once tests were described the same way, the automation team could onboard them in batches instead of building each from scratch.

Procedure search on a governed taxonomy. Every procedure was classified by line of business, risk type, process area, test type, and control reference — a taxonomy I defined with risk subject-matter experts. The hard part was that teams named the same control differently: “client onboarding review,” “CIP verification,” and “new account due diligence” were one procedure. We mapped each to a canonical term and kept the synonyms, so a search in any team’s language returned the same governed procedure.

A sample of the taxonomy

Facet values are drawn from public risk frameworks; no internal procedures or controls are shown.

A procedure, tagged across five facets

Wire transfer callback verification

Version 4 · Owner: Payments Risk · Reviewed quarterly

Line of business

Global Markets

Risk type

External fraud

Process area

Payments & transfers

Test type

Operating effectiveness test

Control reference

BSA/AML · Control 4.2.7

Three team names, one governed procedure

• Consumer onboarding calls itClient onboarding review
• Compliance calls itCIP verification
• Branch operations calls itNew account due diligence

Canonical termCustomer identification reviewAll three names are kept as synonyms, so a search in any team's language returns this one approved procedure.

Routing by risk, not by age. Rule-based tests ran fully automated. ML-scored tests sent only exceptions to officers, into queues ordered by risk tier, so the most consequential cases were worked first.

Reasons in, reasons out. Every flagged case showed why it was flagged, next to the evidence. Officers recorded a structured override reason in a few clicks — principles 1 and 3, built into the same screen.

Quality review inside the record. QA sampled completed work weighted by risk score, in the same case record, replacing a parallel spreadsheet process.

A daily answer for leadership. The dashboard showed tests run, pass and fail rates, auto-cleared versus human-routed volume, override rates, capacity forecasts, and backlog age. It became the screen operational risk leaders opened each morning.

risk-review-platform / today

Outcome

Figures are withheld; directionally:

• Most recurring tests moved from manual execution to automated or exception-only review
• Officers’ time shifted from screening to judgment on the genuinely ambiguous cases
• Time to onboard a new test dropped sharply
• Leadership had a same-day view of the program instead of a monthly one

What I’d do differently

Build the procedure search and taxonomy before the automation, not alongside it. The taxonomy turned out to be the foundation everything else depended on, and settling it earlier would have saved rework in how tests were defined. I’d also invest sooner in taxonomy governance: who owns a term, how synonyms get added, how a retired control is handled.

What I carry forward

Automation adoption is an interface problem as much as a modeling problem. The models were only as valuable as the trust, prioritization, and feedback loops designed around them — and that shapes how I approach AI-assisted design tooling today. The question is never only whether the model is good, but whether the people relying on it can see why it said what it said and correct it when it’s wrong.