Model Risk Governance: A Practical Framework
Model risk governance turns scattered spreadsheets and black-box algorithms into a system someone is accountable for.
Blake Aber · Predicate Ventures · 2026
What model risk governance actually covers
Models drive lending decisions, capital calculations, fraud detection, and pricing. Each one carries the risk of being wrong—wrong by design, wrong in implementation, or wrong because it was applied to a situation it was never built for.
Model risk governance is the discipline that names an owner for that risk and defines how models get built, checked, and retired.
The reference point for most institutions is SR 11-7, the Guidance on Model Risk Management issued by the Federal Reserve jointly with the OCC. It describes an effective framework as covering three areas: model development, implementation, and use; effective validation; and sound governance, policies, and controls.
Those three areas are the outline for everything below.
The three components of a model
Before you can govern a model, you have to agree on what one is.
SR 11-7 defines a model as three parts: an information input component, a processing component, and a reporting component.
Inputs are the data and assumptions that feed the model. Processing is the method that turns inputs into estimates. Reporting is how the output reaches the people who act on it.
This definition matters commercially. It means governance applies to the assumptions and the presentation, not only the equation in the middle. A model can be mathematically sound and still fail because it was fed stale data or because its output was reported in a way that misled the people relying on it.
When firms scope their model inventory, this three-part definition decides what counts. Tools that only produce a number from a fixed formula may not qualify. Tools that estimate, forecast, or approximate almost always do.
Development, implementation, and use
The first area is the model's working life.
Development covers how the model is designed and tested. It includes the rationale for the method chosen, the quality of the data, and documentation good enough that someone other than the builder can understand it.
Implementation is the move from a developer's environment into production systems. This is where errors hide. A model that behaved correctly in testing can break when it is connected to live data feeds or coded into a different platform.
Use is the ongoing application of the model to real decisions. Governance here asks whether the model is still being applied to the conditions it was built for, and whether users understand its limits.
Each stage produces a record. The record is what a validator and an examiner will read.
Validation as an independent check
Validation is the second area, and it is the part most firms underbuild.
Effective validation is independent. The people checking a model should not be the people who built it, because builders are poorly positioned to see their own blind spots.
SR 11-7 recommends a periodic review of each model, at least annually and more often when circumstances warrant, to confirm it is working as intended.
Annual is a floor, not a target. A model tied to volatile markets or rapidly shifting customer behavior may need review every quarter. A stable model in a slow domain may justify the annual minimum. The framework asks the firm to decide the frequency and defend it.
Validation is not a one-time gate at launch. It is a repeated test that a model still fits the world it operates in. Markets move, portfolios change, and a model that was accurate two years ago may now be quietly biased.
What validation should confirm
A useful validation answers a few plain questions. Does the model do what its documentation claims? Are its inputs still appropriate? Do its outputs match reality when checked against outcomes? Are its known weaknesses being managed?
When the answer to any of these is no, the finding goes to the model owner with a timeline for resolution. Findings that sit unresolved are themselves a governance failure.
Governance, policies, and controls
The third area is the structure that holds the other two together.
Governance assigns roles. Someone owns each model. Someone validates it. Someone approves it for use and sets the policy for how often it is reviewed. The board and senior management are responsible for the framework as a whole.
Policies define the rules in writing—what qualifies as a model, how the inventory is maintained, what documentation is required, and how exceptions are handled. Controls are the mechanisms that enforce those rules, including access limits, change management, and monitoring of outputs.
Without this layer, development and validation become one-off efforts that decay. With it, they become a repeatable process an institution can staff, audit, and improve.
The regulatory baseline is settled and current
Model risk governance is not an aspiration a firm invents on its own. Regulators have set a shared standard.
The FDIC adopted the 2011 supervisory guidance as FIL-22-2017, extending the SR 11-7 approach across the institutions it supervises.
More recently, the OCC, Federal Reserve, and FDIC issued revised interagency model risk management guidance, rescinding prior issuances including OCC Bulletin 2011-12. The Federal Reserve published its version of the revised guidance as SR 26-2.
The practical takeaway is that the three-area framework—development and use, validation, and governance—remains the reference standard, now expressed through the current interagency guidance. Firms building or refreshing a program should map to the version in force for their regulator rather than the superseded letters.
Building a program that holds up
A credible model risk governance program is legible. An outsider should be able to open the inventory, pick a model, and trace its development record, its last validation, its owner, and its review schedule.
Start with the inventory. You cannot govern what you have not listed, and most firms discover they own more models than they thought once they apply the three-component definition.
Then set validation independence and cadence. Assign owners. Write the policy. Wire in the controls that catch a model drifting or a change slipping through untested.
The cost of this work is real. The cost of a mispriced portfolio, a failed capital calculation, or an examiner finding is larger, and harder to schedule. Governance is how a firm pays the smaller bill on purpose instead of the larger one by surprise.