Model Risk Management: Selling AI to Banks Under SR 11-7
Banks govern AI as model risk under SR 11-7. If you sell to them, your governance must survive validation. Here is what model risk management demands of vendors.
Banks do not evaluate your AI as software. They evaluate it as a model, under a discipline called model risk management, and in the United States the governing guidance is SR 11-7. That framing changes everything about the sale. A bank's model risk team assumes any model can be wrong, and their entire job is to bound how wrong and how bad. If you sell into financial services and cannot survive model validation, you do not close, no matter how good your demo looked. This is the strictest governance bar in enterprise AI, and clearing it is a moat almost no competitor bothers to build.
What is model risk management and why does it matter?
Model risk management is the practice of identifying, measuring, and controlling the risk that a model produces wrong outputs or is used incorrectly. SR 11-7, the regulatory guidance most banks follow, rests on three pillars: robust model development, independent validation, and ongoing governance. A vendor selling an AI model into a bank becomes part of that framework whether they planned for it or not.
The core assumption is the one vendors resist. The bank does not ask you to prove your model is right. They assume it can be wrong and ask you to prove you understand how, how often, and with what consequences. A vendor who shows up claiming high accuracy and nothing else fails immediately, because they have answered a question the framework does not ask. The framework asks about limitations, not just performance. This is why claims discipline is not optional here: an overstated claim is not a marketing sin, it is a validation failure.
What does independent model validation demand?
Validation is the pillar that catches unprepared vendors. An independent team, separate from whoever built the model, tests whether it does what it claims and where it breaks. To survive it, you need to bring the evidence they will otherwise demand and wait for.
- Documented limitations. Where does the model perform poorly, on what inputs, and how did you measure it. A vendor who claims no limitations is a vendor who has not looked.
- A real eval set. Not a cherry-picked demo. The test data and methodology behind every performance claim. Validators want to reproduce your numbers, so publishing honest benchmarks is the baseline.
- Version control. Which model version is in production, what changed between versions, and how a change is reviewed. Floating on the latest model fails validation outright, which is why you pin the model version in production.
- Monitoring for drift. Evidence that you detect when the model's behavior shifts in production, not just at launch. Ongoing monitoring is a pillar, not an afterthought.
Why ongoing governance is where vendors slip
Development and validation are point-in-time. The third pillar is continuous, and it is where vendors who cleared the initial review still lose the account. A bank expects the model to be governed over its whole life: monitored, revalidated when it changes, and controlled by documented policy. If your model silently updates because you float on a provider's latest version, you have broken the governance the bank built their approval on. Every material change reopens the validation question, so telling customers before you change the model is a contractual reality in this market, not a courtesy.
The other continuous requirement is traceability. When something goes wrong, the bank must reconstruct what the model did and why, which means you need data lineage on every output and the ability to explain a single decision months later. A model risk team that cannot audit your decisions cannot approve your model, full stop.
The bar is the business case
Model risk management is the most expensive governance to satisfy in enterprise AI. That expense is the point. Most AI vendors cannot survive independent validation, so the banks that need AI have a thin field of qualified suppliers. Build the documentation, the eval discipline, the version control, and the ongoing monitoring, and you are competing in a market where the governance bar has already eliminated most of your competition and where switching costs are brutal once you are in.
I build governance to this standard because the hardest markets are the most defensible ones. My venture Girard AI treats model versioning, drift monitoring, and decision traceability as core infrastructure rather than compliance overhead, which is what lets it stand up to validation-grade scrutiny. The general principle across everything I run is simple and I have argued it before: capability is a commodity, governance is the moat. Nowhere is that truer than in a bank's model risk review.