- Every AI or ML model your organization uses for a material business decision falls under SR 11-7. That includes credit scoring, fraud detection, AML screening, risk models, and pricing algorithms. The framework predates modern AI, but regulators have explicitly confirmed it applies. A model that is not in your inventory has not been validated, classified, or monitored — which is itself an examination finding.
- SR 11-7 requires independent validation — meaning parties not involved in model development must validate its conceptual soundness, data quality, and performance. For AI models, this is where most banks have gaps. Only 44% of banks properly validate their AI tools. Validation must happen before deployment and repeat annually or after any material change.
- The three-lines-of-defense structure for model governance is not just an organizational preference — it is what examiners look for. First line owns and uses the model. Second line validates and challenges it. Third line audits the program. If the same team builds, validates, and monitors a model, that is an SR 11-7 finding regardless of the model’s performance.
- Model documentation must survive an examiner review on short notice. That means: conceptual soundness justification, training data description with known limitations, validation results including back-testing, and an ongoing monitoring plan. For AI models, add: demographic subgroup performance results, proxy variable analysis for any model used in credit or risk decisions, and adverse action notice mapping for credit models.
- Vendor-supplied AI models — credit bureau scores, fraud platforms, AML tools — require the same SR 11-7 governance as internally developed models. Institutions must conduct or obtain validation evidence, maintain documentation, and monitor performance. “The vendor handles governance” is not an acceptable answer in an examination.
SR 11-7 was issued in April 2011 by the Federal Reserve and the Office of the Comptroller of the Currency. At the time, the concern was quantitative models for credit risk, market risk, and regulatory capital — the kind of models that contributed to the 2008 financial crisis. The guidance has not been materially updated since then.
It does not need to be. The framework it established — model inventory, risk tiering, independent validation, ongoing monitoring, and documentation — applies to every AI and machine learning model a financial institution uses for material decisions. Regulators have confirmed this explicitly. The OCC’s Comptroller’s Handbook on Model Risk Management states directly that AI tools fall within the MRM framework. The average bank now uses 175 models, large banks use 300 or more, and AI adoption is accelerating. Only 44% of banks properly validate their AI tools. The framework exists. The compliance gap is in applying it.
The Model Definition
SR 11-7 defines a model as “a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.” This is broad enough to cover machine learning classifiers, neural networks, gradient boosting models, scoring algorithms, and most AI systems used in financial services. If it takes data in and produces a number or a decision that influences a business outcome, it is almost certainly a model under SR 11-7.
What SR 11-7 Actually Requires
The Model Inventory
Every model must be catalogued in a model inventory. For AI, the inventory challenge is discovery: AI functionality is increasingly embedded in vendor platforms and third-party data feeds in ways that are not always visible as discrete models. A complete model inventory entry should include: model name and unique identifier; business function and intended use; risk tier; development origin (internal or vendor); owner and users; validation status and date; monitoring status; known limitations. For AI models: document whether the model is used in credit decisions, adverse action determinations, or AML/KYC screening.
Risk Tiering
| Tier | Criteria | Required Governance |
|---|---|---|
| High | Used for credit underwriting, pricing, regulatory capital, or fraud decisions with direct customer impact; high complexity; broad institutional use | Full validation: conceptual soundness, data quality, performance testing, back-testing, sensitivity analysis, demographic bias testing. Annual re-validation. Continuous monitoring. MRM committee review before deployment. |
| Medium | Customer-facing AI, AML/KYC screening, internal risk analytics; moderate complexity or scope | Validation with focused scope. Periodic monitoring with defined review schedule. Documentation current. |
| Low | Back-office automation, internal productivity tools, low-impact analytics | Inventory entry, basic documentation, periodic review. |
Independent Validation
Validation must be conducted by parties independent of model development. For AI models, validation has specific technical dimensions:
- Conceptual soundness: Is the modeling approach appropriate for the problem? Are the underlying assumptions justified? Does the model architecture make sense for the data and objective?
- Data quality: Is the training data representative of the population the model will be applied to? Are there known data quality issues, temporal gaps, or demographic coverage limitations?
- Performance testing: How well does the model perform on held-out data? Precision, recall, AUC for classification; RMSE, R-squared, back-testing for regression.
- Sensitivity analysis: How does the model respond to changes in inputs? Are there inputs with outsized influence? Could adversarial inputs produce unexpected outputs?
- Demographic subgroup analysis: For any model used in credit or risk decisions: does performance differ significantly across demographic groups? This is simultaneously an SR 11-7 requirement and a fair lending obligation under ECOA.
Ongoing Monitoring
- Performance tracking: Compare model outputs to actual outcomes on a defined schedule. For credit models: compare predicted default rates to actual. For fraud models: track true and false positive rates.
- Model drift detection: Identify when the statistical distribution of inputs or outputs has shifted from the training baseline.
- Population stability analysis: Track whether the characteristics of the model’s input population have shifted materially from the development sample.
- Alert and exception reporting: Define performance thresholds that trigger escalation.
Documentation Requirements
| Document | Content |
|---|---|
| Model development documentation | Problem statement, data sources and preparation, model architecture selection and justification, training process, known limitations, intended use boundaries. |
| Validation report | Methodology used, data quality findings, performance results on held-out test data, demographic subgroup analysis, sensitivity analysis, identified limitations, validation conclusion. |
| Risk tier justification | Basis for the risk tier assignment, materiality assessment, complexity rating, breadth of use, potential impact analysis. |
| Monitoring plan | Metrics to be tracked, frequency of review, performance thresholds, escalation triggers, re-validation criteria. |
| Change log | Record of all material changes to the model, including vendor-initiated updates, with dates and validation status. |
| Adverse action notice mapping (credit models) | For each denial or adverse action: specific model outputs and how they map to compliant adverse action notice language under ECOA/Regulation B. |
The Three Lines of Defense
| Line | Role in AI Model Governance | What Examiners Look For |
|---|---|---|
| First Line: Business / Model Owners | Owns the model, defines intended use, manages day-to-day performance monitoring, documents overrides and exceptions. | Model inventory entries maintained; performance alerts acted on; model used within documented intended use boundaries; override decisions documented with rationale. |
| Second Line: Model Risk Management / Compliance | Conducts or oversees independent validation; challenges conceptual soundness; maintains the MRM policy; reviews and approves new models before deployment. | Validation reports completed before deployment; validation team independent of development; MRM policy current and covers AI; high-tier models reviewed by MRM committee. |
| Third Line: Internal Audit | Audits the MRM program; confirms the first two lines are functioning; tests whether documentation matches practice. | Audit findings addressed; MRM program scope covers AI and vendor models; governance processes actually followed, not just documented. |
The most common SR 11-7 finding for AI is a breakdown in independence. The team that builds the model also validates it. Independent does not mean physically separate — it means the validator has no stake in the model’s approval, no reporting relationship to the model owner, and the organizational standing to push back.
Vendor Model Governance
A significant proportion of financial services AI is acquired, not built. SR 11-7 is explicit: vendor-supplied models require the same MRM rigor as internally developed ones. Three specific PM challenges:
- Validation evidence: Many vendors will not share detailed model documentation for proprietary reasons. This does not excuse the institution from its validation obligation. Where full documentation is unavailable, document what was obtained, what was not, and the basis for the reliance decision. Contractual audit rights should be negotiated before execution.
- Performance in your environment: A vendor’s validation was conducted on their data, in their environment. Your obligation is to validate performance in your lending environment, on your applicant pool, with your data. Vendor validation is not institutional validation.
- Change management: Vendor models are updated without always triggering the institution’s change management process. Contracts must require advance notification of material model changes, and those changes must re-enter the institution’s validation workflow.
Building SR 11-7 Compliance Into Your Project
| Phase | Key Actions |
|---|---|
| Project Initiation | Determine whether the system meets the SR 11-7 model definition. Assign a risk tier and document the basis. Identify the validation team and confirm independence. Scope documentation deliverables as project workstreams with owners and timelines. |
| During Development | Maintain a development log capturing design decisions, data source choices, feature selection rationale, and known limitations. For credit AI: begin adverse action notice mapping during model development. For models trained on historical data: conduct proxy variable analysis during feature selection. |
| Before Deployment | Obtain completed validation report from the independent validation team. Confirm adverse action notice mapping is complete for any credit model. Confirm monitoring is operational before go-live. |
| Post-Deployment | Conduct the first formal monitoring review at 90 days. Run annual re-validation using current production data. Update the model inventory within 30 days of any material change. Keep documentation current. |
Right-Sizing for Your Situation
For PMs new to model risk management. Covers SR 11-7 model definition and scope, building a model inventory from scratch, minimum viable validation for lower-tier AI models, and documentation templates for examiner readiness.
For PMs building repeatable MRM processes. Comprehensive risk tiering methodology for AI, independent validation program design, three-lines-of-defense implementation for AI governance, vendor model governance framework, and monitoring program design.
For PMs in mature financial institutions. Integrating AI into enterprise MRM programs, managing model inventory at scale, MRM committee governance for high-tier AI, examination preparation, and GenAI governance within the MRM framework.
Framework References
Federal Reserve / OCC SR 11-7: Supervisory Guidance on Model Risk Management (April 2011, FDIC FIL-22-2017) — Three-part framework: model development and use, model validation, and governance. Applies to all AI and ML models used for material decisions. The foundational document for this article.
OCC Comptroller’s Handbook: Model Risk Management (August 2021) — Explicitly confirms AI tools fall within the MRM framework. Provides examiner guidance on what sound MRM looks like in practice, including for machine learning models.
OCC/FRB/FDIC Third-Party Risk Management Guidance (2023) — Planning, due diligence, contracting, and ongoing monitoring expectations for vendor AI models. Reinforces that third-party models require SR 11-7-equivalent governance.
NIST AI RMF 1.0 — MEASURE 2.5 (performance thresholds), MEASURE 2.11 (bias and proxy variable analysis), MANAGE 4.1 (continuous monitoring). Maps the technical testing obligations to SR 11-7 validation and monitoring requirements.
CFPB Circular 2022-3 and Circular 2023-3 — ECOA adverse action notice obligations that interact with SR 11-7 validation requirements for credit models. Validation of a credit AI model is incomplete without adverse action notice mapping.
This article is part of AIPMO’s Financial Services series. See also: AI Governance in Financial Services | Fair Lending and Credit AI | Adverse Action Notices and Explainability