.webp)
Listen To Our Podcast🎧
Introduction
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.
- What counts as a model under US supervisory guidance, and why vendor tools are included
- The 5 fields every inventory entry needs before an examiner will call it complete
- Why AI fraud detection and AML models are the most common inventory gaps
- How to record false positive rates so alert data doubles as validation evidence
- A 4-phase plan, starting now, to move from spreadsheet to governed inventory
Onboard Customers in Seconds
What Is a Model Inventory and Why Do Examiners Ask for It?
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.
What counts as a model in a bank?
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.
What do examiners do with the inventory?
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.
5 Fields Every Model Inventory Entry Needs
There is no single mandated template. In our experience, entries that satisfy examiners share the same five fields.
1. Named owner and developer
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.
2. Purpose and intended use
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.
3. Risk tier
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.
4. Validation status and findings
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.
5. Monitoring metrics and thresholds
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.
Why AI Fraud Detection and AML Models Expose Inventory Gaps
Fraud and AML systems change constantly, and they are often bought rather than built. That combination produces most of the gaps we see.
How does AI detect fraud, and why does that matter for inventory?
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.
Documenting machine learning fraud detection
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 and real-time scoring
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 vs Governed Inventory
| 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.
How Do You Track False Positives in Your Model Inventory?
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.
What is a normal false positive rate in fraud detection?
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.
How to reduce false positives in AML
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.
What is the false positive cost in fraud operations?
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.
4 Phases to Build a Model Inventory Examiners Trust
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.
1. Phase 1 (Now): Discover and list every model
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.
2. Phase 2: Tier and assign owners
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.
3. Phase 3: Link validation and monitoring
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.
4. Phase 4: Automate and retire
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 must list every model the bank relies on, including vendor tools, or examiners will count the gaps as findings.
- Five fields (owner, purpose, risk tier, validation status, monitoring) make an entry defensible.
- Fraud and AML models need version history because each retrain is a different model.
- Track the false positive rate as a monitored metric with a threshold and an owner.
- Build in four phases, starting with discovery now, and automate only after the data is clean.
Onboard Customers in Seconds
Conclusion
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.
Share this article