A model inventory is the first document a bank examiner asks for, and it is the one many banks cannot produce cleanly. When the list lives across three spreadsheets and an engineer's memory, every follow-up question takes days to answer.
This post covers what examiners expect to see in a model inventory, which fields matter, and where fraud and AML models tend to slip through. It also lays out a four-phase plan you can start this quarter.
The guidance is written for compliance officers, CISOs, and the operations and data teams who own the models.
A model inventory is a complete, current list of every model a bank uses, with the owner, purpose, risk tier, validation status, and known limitations of each. Examiners use it as the map for their review: they pick models from it and ask to see the evidence behind each one.
The expectation comes from supervisory guidance on model risk management. The Federal Reserve's SR 11-7 and the OCC's companion Bulletin 2011-12 both call for a comprehensive set of model information, and both have applied since 2011.
A model is any quantitative method that turns input data into estimates or scores used for decisions. Credit scorecards, capital models, and pricing tools qualify. So do fraud scores, sanctions fuzzy-matching, and customer risk ratings.
The common mistake is treating vendor tools as out of scope. If your bank relies on the output, the model belongs in the inventory, even when you cannot see the code.
They sample from it. An examiner picks a few models, then requests development documentation, validation reports, and monitoring results for each. A model missing from the inventory is a finding on its own, before anyone reads a validation report.
An incomplete model inventory is a finding by itself. Examiners cannot test what they cannot see, so a missing model raises questions about every other control.
There is no single mandated template. In our experience, entries that satisfy examiners share the same five fields.
Every model needs one accountable business owner and one named developer or vendor contact. "Fraud team" is not an owner. A person is, and the record should change when that person moves roles.
State what decision the model supports and where it is not meant to be used. Model drift often begins when a score built for card fraud is quietly reused for another product.
Tier by materiality and complexity, and write down the rationale. The tier sets how often validation happens, so an examiner will test whether your tiers make sense.
Record the last validation date, who did it, and any open issues with due dates. Independent validation is the point here, so the validator should not be the developer.
List the metrics you track, the thresholds that trigger review, and where results are stored. This field is what separates a real inventory from a static list.
Fraud and AML systems change constantly, and they are often bought rather than built. That combination produces most of the gaps we see.
The short answer to "how does AI detect fraud" is that a model learns patterns from labeled transactions and scores new activity by how far it departs from normal behavior. Because that learning changes with retraining, each version is a different model in practice. Your inventory needs a version history, not just a name. If you want the basics, our guide on artificial intelligence fraud detection versus traditional methods covers the mechanics behind ai fraud detection explained for risk officers.
Machine learning fraud detection needs three items beyond a standard entry: training data sources, feature lists, and a retraining schedule. Without them, a validator cannot judge whether the model still fits the population it scores.
Examiners also ask about explainability. If an analyst cannot say why a transaction was scored high, the model is hard to defend.
AI fraud detection in banking often runs inline at payment time. Real time fraud detection banks depend on scores returned in milliseconds, so the inventory should record latency limits and the fallback rule set that applies when the model is unavailable. That fallback is a control, and it needs an owner too.
When selecting fraud detection software, the inventory question to ask the vendor is simple: can you supply development documentation, validation support, and change notices? Tools such as fraud detection software should be judged partly on how well they feed your governance process. The same test applies to AI fraud detection software from any vendor.
| Spreadsheet inventory | Governed inventory | |
|---|---|---|
| Completeness | Depends on who remembers to update it | Feeds from deployment and procurement records |
| Version history | Overwritten cells | Every retrain logged as a new version |
| Validation tracking | Manual reminders | Due dates and status tied to risk tier |
| Vendor models | Often missing | Required field with documentation links |
| Audit trail | None | Who changed what, and when |
Every retrain creates a new model version. If your inventory records one entry per model name, you cannot show an examiner which version made a given decision.
Track them as a monitoring metric with a threshold, an owner, and a review date. That turns alert data you already have into validation evidence.
There is no universal benchmark, so avoid quoting one. The false positive rate fraud detection teams should watch is your own: the share of alerts closed as not suspicious, measured per model version and per segment. Set a baseline, then set a threshold that triggers review when the rate moves.
The question of how to reduce false positives in AML usually starts with tuning thresholds, cleaning input data, and adding behavioral features. Any change to those is a model change, and it should pass through the same approval as a new model. Our post on rule-based systems vs AI for false positives compares the options, and it is a practical starting point for how to reduce false positives in AML programs.
To reduce false positives in transaction monitoring without creating a blind spot, test changes on historical alerts first. Keep the results with the validation file.
False positive cost fraud teams carry is mostly analyst time, plus customer friction when good payments are declined. A simple estimate is alerts per month times minutes per review times loaded hourly cost. Ten thousand alerts at 15 minutes each is 2,500 analyst hours, before any customer impact.
The human side is fraud alert fatigue. When most alerts are noise, reviewers slow down and real cases get closed too fast. Recording the metric in your inventory gives leadership a reason to fund tuning. For an example of what tuning can achieve, see how agentic AI fraud agents cut false positives.
Transaction monitoring software deserves the same scrutiny as any other model. Treat false positives in fraud detection as a standing metric, not a one-off tuning project.
Most banks cannot build a perfect inventory in one pass, and trying to is a common reason projects stall. A phased plan gets defensible coverage sooner. The NIST AI Risk Management Framework is a useful reference for the governance practices behind it.
Start with a sweep of procurement records, deployment lists, and team interviews. Capture name, owner, purpose, and vendor. In our client engagements, a first pass at a mid-sized bank typically takes 4 to 8 weeks, and it usually finds models nobody had listed.
Apply a risk tiering scheme and name an accountable owner for each model. Write the rationale for each tier in a single sentence. High-tier models, which usually include fraud, AML, and credit, get attention first.
Attach the last validation report to each entry and define monitoring metrics, including false positive rates for detection models. Set due dates from the tier. This is where the inventory stops being a list and becomes a control.
Connect the inventory to deployment pipelines so new versions register automatically, and add a retirement step so decommissioned models leave the active list with a record. Automation also helps with regulatory reporting, as covered in our guide to DORA compliance automation for digital banks.
There is a tradeoff. Automation costs engineering time, and it only pays off once Phases 1 to 3 give it clean data to work with.
A model inventory that lives in scattered spreadsheets fails the moment an examiner samples from it. The fix is not a bigger spreadsheet, and a first discovery pass takes roughly 4 to 8 weeks in our experience.
Three things close the gap: a named owner and risk tier on every entry, a version history for models that retrain, and monitored metrics such as false positive rates that double as validation evidence. Together they answer the follow-up questions before they are asked.
The realistic path is phased. Finish discovery in Phase 1, then tier and assign owners, and only then automate. Banks that follow this order tend to reach a defensible inventory without stalling on tooling.
Start this week by listing every fraud and AML model in production, then assign one owner to each.
A model inventory is a complete, current list of every model a bank uses, with its owner, purpose, risk tier, validation status, and monitoring metrics. Examiners use it to select models for review, so it must include vendor and AI fraud detection tools as well as internally built models.
They expect full coverage of models in use, a named owner and developer, the intended use, a risk tier with rationale, the last validation date and open findings, and the monitoring metrics with thresholds. Version history for models that retrain, such as machine learning fraud detection, is also expected.
Yes. If the bank relies on the output for decisions, the tool is a model regardless of who built it. Record the vendor contact, the documentation you can obtain, and how you validate or test the tool, including its false positive rate.
Update it whenever a model is added, changed, retrained, or retired, and review the full list at least annually. Real time fraud detection models that retrain frequently should register each new version automatically.
The inventory stores the false positive rate as a monitored metric with a threshold and an owner. When the rate drifts, the owner reviews thresholds and data inputs, and any tuning goes through change approval. That discipline is how to reduce false positives in AML monitoring without creating blind spots.
Start with Phase 1: sweep procurement records and deployment lists, and interview teams to list every model with an owner and purpose. Prioritize fraud, AML, and credit models, then move to tiering in Phase 2.