SR 11-7 and OCC Bulletin 2011-12 are the same document: the Supervisory Guidance on Model Risk Management issued by the Federal Reserve and the OCC on April 4, 2011. It defined a model as a quantitative method that processes input data into quantitative estimates, defined model risk as the potential for adverse consequences from incorrect or misused model outputs, and built model risk management on three elements: robust development, implementation and use; independent validation made of conceptual-soundness review, ongoing monitoring and outcomes analysis; and governance through board oversight, policies, a firm-wide model inventory and internal audit, all under the principle of effective challenge. Its technology-neutral definition is why banks applied it to machine-learning credit, fraud and AML models. It was superseded on April 17, 2026 by SR 26-2 / OCC Bulletin 2026-13 / FDIC FIL-15-2026, which keep the same architecture for machine-learning models but place generative and agentic AI outside their scope.
TRACKED DOCUMENTS: SR 11-7 · OCC Bulletin 2011-12 · SR 26-2
Issued
April 4, 2011, by the Federal Reserve (SR 11-7) and the OCC (Bulletin 2011-12); FDIC adopted it in June 2017 (FIL-22-2017)
Form
21-page supervisory guidance in seven sections; not a regulation
Status
Superseded April 17, 2026 by SR 26-2 / OCC 2026-13 / FDIC FIL-15-2026
Structure
Three elements: development and use (§IV), validation (§V), governance (§VI)
AI today
ML models stay in scope of the 2026 guidance; generative and agentic AI are outside it
What are SR 11-7 and OCC 2011-12, and are they still in effect?
SR 11-7 and OCC Bulletin 2011-12 are two transmittals of one document: the Supervisory Guidance on Model Risk Management that the Board of Governors of the Federal Reserve System and the Office of the Comptroller of the Currency issued jointly on April 4, 2011. The Fed sent it to its examiners and supervised institutions as Supervisory and Regulation Letter 11-7; the OCC published it for national banks and federal savings associations as Bulletin 2011-12, “Sound Practices for Model Risk Management”. The FDIC adopted the same text in June 2017 as FIL-22-2017. For fifteen years it was the rulebook for how US banks built, validated and governed quantitative models, and because its definition of a model was technology-neutral it was also the framework banks applied to machine-learning credit, fraud and anti-money-laundering models.
It is no longer in effect. On April 17, 2026 the Federal Reserve, OCC and FDIC replaced it with revised interagency guidance, issued as SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026. The replacement keeps the three-part architecture and the vocabulary (conceptual soundness, outcomes analysis, effective challenge, model inventory), narrows what counts as a model, ties the intensity of validation to materiality, says it is most relevant to banks above $30 billion in assets, and states that generative AI and agentic AI models are outside its scope. This guide explains the 2011 text because its concepts are the concepts of the 2026 text and of most model-risk frameworks worldwide; where the two differ, it says so. For the status, PDF links and change log see our SR 11-7 and OCC Bulletin 2011-12 document pages; for a cell-by-cell comparison with the replacement see SR 11-7 vs SR 26-2; for the wider US, UK and euro-area picture see the model risk management hub.
How does SR 11-7 define a model, model risk and its two sources?
Everything in the guidance follows from four definitions in Section III. They are quoted here because the exact words decided, for fifteen years, whether a spreadsheet, a scorecard or a neural network had to be inventoried and validated.
| Term | SR 11-7 text (Section III) | What it meant in practice | In SR 26-2 (2026) |
|---|---|---|---|
| Model | “A quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates.” A model has three components: an information input component, a processing component and a reporting component. The definition “also covers quantitative approaches whose inputs are partially or wholly qualitative or based on expert judgment, provided that the output is quantitative in nature.” | Anything that turns data into a number used for a decision: credit scorecards, capital and stress-testing models, valuation and pricing models, AML transaction-monitoring and customer-risk-rating systems, and, by the same words, machine-learning classifiers and regressors. Qualitative inputs did not take a tool out of scope. | Narrowed to a “complex” quantitative method; simple arithmetic and deterministic rule-based processes are excluded; generative and agentic AI are out of scope. |
| Model risk | “The potential for adverse consequences from decisions based on incorrect or misused model outputs and reports.” It “can lead to financial loss, poor business and strategic decision making, or damage to a bank's reputation.” | A risk category of its own, to be managed like credit or market risk, with the bank expected to identify its sources and magnitude and then manage it. | Same definition; materiality now explicitly scales the response. |
| Source 1: fundamental errors | “The model may have fundamental errors and may produce inaccurate outputs when viewed against the design objective and intended business uses.” Errors “can occur at any point from design through implementation”: theory, sample design, numerical routines, inputs and estimation, coding. | The error is in the model. Caught by conceptual-soundness review, developmental evidence, testing and process verification. | Retained. |
| Source 2: incorrect or inappropriate use | The model “may be used incorrectly or inappropriately”: applied outside the environment for which it was designed, or to products and markets it was not built for, without understanding its limitations and assumptions. | The error is in the use. Caught by documented restrictions on use, ongoing monitoring and governance of model changes. | Retained. |
| Effective challenge | The “guiding principle”: “critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes”, depending on “a combination of incentives, competence, and influence”. | The test of whether validation is real: separated from development, technically competent, and able to force a change. | Retained as the central principle. |
What are the three pillars of model risk management?
The guidance never uses the word pillar. Section III says: “Model risk management begins with robust model development, implementation, and use. Another essential element is a sound model validation process. A third element is governance.” Each element gets its own section (IV, V and VI). Practitioners draw the three as a lifecycle, which is how the diagram below presents them: development feeds validation with developmental evidence, validation feeds development with findings and compensating controls, effective challenge is the principle running between them, and governance is the ring around both. The guidance is explicit that the ring is not optional: “Even if model development, implementation, use, and validation are satisfactory, a weak governance function will reduce the effectiveness of overall model risk management.”
| Pillar | SR 11-7 section | What it requires | Who owns it |
|---|---|---|---|
| 1. Development, implementation and use | Section IV | A clear statement of purpose; sound design, theory and logic; data and methodology suited to the purpose; testing before use; documentation detailed enough for an independent party to understand the model; controls over implementation; use that respects the model's limitations. | Model owners and developers in the first line |
| 2. Validation | Section V | Independent, effective challenge across three core elements: evaluation of conceptual soundness, ongoing monitoring (including process verification and benchmarking) and outcomes analysis (including back-testing); validation of vendor and third-party models; findings tracked to closure. | An independent validation function, usually in the second line, with staff who have the skills and authority to challenge |
| 3. Governance, policies and controls | Section VI | Board and senior-management oversight; written policies and procedures; defined roles and responsibilities; a firm-wide model inventory; documentation standards; internal audit's assessment of the whole framework. | Board, senior management, the model risk function and internal audit |
Pillar 1 · Model development, implementation and use (Section IV)
Development starts with “a clear statement of purpose” so the model is built for the use it will actually have. The design, theory and logic must be documented and supported by published research and sound industry practice. The guidance demands “a rigorous assessment of data quality and relevance”, with documentation of where the data came from and what was done to it, which is the hook on which examiners hang every question about AI training data (see our BCBS 239 guide for the data side). Testing before use must demonstrate accuracy, robustness and stability, including the model's behaviour outside the range of its development sample; sensitivity analysis and stress testing are named. Implementation means the model is correctly coded and integrated; use means it is applied within its stated limitations and that business users understand them. Materiality scales all of this: a bank whose models are “less pervasive” may run a less complex programme, but where model failure “would have a particularly harmful impact on a bank's financial condition” the framework “should be more extensive and rigorous”.
Pillar 2 · Model validation (Section V)
Validation is “the set of processes and activities intended to verify that models are performing as expected, in line with their design objectives and business uses”. It must cover all three components of a model, input, processing and reporting, and “applies equally to models developed in-house and to those purchased from or developed by vendors or consultants”. It requires independence: “validation should be done by people who are not responsible for development or use and do not have a stake in whether a model is determined to be valid”. Every model gets a periodic review “at least annually but more frequently if warranted”, and material changes trigger validation. The three core elements of validation are set out in the table in the next section.
Pillar 3 · Governance, policies and controls (Section VI)
The board and senior management are responsible for the framework; policies, reviewed annually, define what a model is, the standards for development, validation and documentation, and the requirements for vendor models; roles are assigned so that owners, developers, validators and internal audit are distinct; internal audit assesses the overall effectiveness of the framework; and the bank keeps a firm-wide model inventory. Section VI also covers external resources (consultants and vendors used in validation) and documentation.
What are the three core elements of model validation?
Section V says “an effective validation framework should include three core elements”. They should not be confused with the three pillars: all three sit inside pillar 2. The table gives the 2011 text, the evidence a validator produces for each, and how the element changes when the model is machine learning.
| Element | SR 11-7 text (Section V) | Evidence in a validation | For machine-learning models |
|---|---|---|---|
| 1. Evaluation of conceptual soundness, including developmental evidence | “Assessing the quality of the model design and construction”: review of documentation and empirical evidence supporting the methods used and variables selected; judgment in design must be “well informed, carefully considered, and consistent with published research and with sound industry practice”; sensitivity analysis to check the model is not unstable; developmental evidence reviewed before use and whenever there is a material change. | A written opinion on theory and method, the variable-selection rationale, data quality and relevance, limitations and assumptions, and sensitivity results, each tied to documentation the validator could reproduce. | Feature engineering and hyper-parameter choices replace variable selection; explainability tools stand in for a closed-form theory; the training-data cut, its lineage and its representativeness are the developmental evidence that matters most. |
| 2. Ongoing monitoring, including process verification and benchmarking | “Confirms that the model is appropriately implemented and is being used and is performing as intended”, and tests whether changes in products, exposures, activities, clients or markets mean the model no longer fits. Process verification checks that inputs, code and reports are correct; benchmarking is “the comparison of a given model's inputs and outputs to estimates from alternative internal or external data or models”. | Monitoring metrics with thresholds, an override and exception log, benchmark results, a change log, and evidence that the model is used only inside its documented restrictions. | Input-drift and population-stability monitoring, retraining triggers and challenger models; vendor-hosted models need the vendor to supply the performance information the bank cannot compute itself. |
| 3. Outcomes analysis, including back-testing | “A comparison of model outputs to corresponding actual outcomes”, assessing accuracy of estimates or forecasts or rank-ordering ability, with expected ranges set in advance. Back-testing compares actual outcomes with forecasts “during a sample time period not used in model development” at a frequency matching the forecast horizon. Poor performance must lead to action. | Back-test results against stated tolerances, rank-ordering statistics, calibration results, and a record of the remediation that followed any breach. | Hold-out and out-of-time testing, performance by segment (which is where fairness findings surface), and, for models whose outcomes are slow to arrive, proxy outcomes with a documented rationale. |
What do a model inventory and a validation report contain?
Two documents carry most of the examiner's attention, and the 2011 text describes both. The inventory must cover models “implemented for use, under development for implementation, or recently retired”, with “a specific party” charged with maintaining a firm-wide version so the bank can evaluate “its model risk in the aggregate”; any variation that warrants a separate validation is a separate entry. Validation reports “should articulate model aspects that were reviewed, highlighting potential deficiencies over a range of financial and economic conditions, and determining whether adjustments or other compensating controls are warranted”, with “clear executive summaries”.
| Artefact | Contents named in SR 11-7 | What AI adds |
|---|---|---|
| Model inventory (Section VI) | Purpose and products the model is designed for; actual or expected usage and any restrictions on use; type and source of inputs and underlying components (including other models); outputs and their intended use; dates of validation activities and findings; the model's owner, developer, validator and user; status of issues and their resolution. Covers in-use, in-development and recently retired models. | The training-data snapshot and its lineage; the vendor or foundation model it depends on; a tier or materiality rating driving validation depth; whether the model is deterministic, non-generative ML or generative/agentic (the last two are outside SR 26-2 and need a separate governance home). |
| Validation report (Section V) | Executive summary with a statement of model purpose and an accessible synopsis of the model and the validation results; the aspects reviewed; major limitations and key assumptions; potential deficiencies across a range of conditions; whether adjustments or compensating controls are warranted; findings with severity and remediation; the validator's independence and competence. | Explainability and feature-importance results; segment-level outcomes and fairness tests; data-drift and retraining policy; third-party evidence obtained from the vendor; a statement of what could not be validated and the compensating control for it. |
| Policies and procedures (Section VI) | What qualifies as a model; standards for development, implementation, use, validation and documentation; validation requirements for vendor and third-party products; roles and responsibilities; annual review of the policy itself. | An explicit line between model risk policy and AI governance policy, so that generative and agentic tools are governed somewhere once the 2026 guidance leaves them out. |
How did SR 11-7 treat vendor and third-party models?
The guidance refused to let outsourcing dilute validation. It expects the bank to obtain developmental evidence from the vendor (“the design, development, and validation of the vendor product”), to validate its own use of the product with its own data, to obtain ongoing performance information, and “to have as much knowledge in-house as possible, in case the vendor or the bank terminates the contract for any reason, or if the vendor is no longer in business”. It adds: “Banks should have contingency plans for instances when the vendor model is no longer available or cannot be supported by the vendor.” Those sentences are the ancestor of today's exit-plan expectations for AI vendors in SR 23-4 / OCC 2023-17, and of Article 28(8) of the EU's DORA (see our DORA guide). SR 26-2 keeps a stand-alone section on vendor and other third-party products and ties it to the 2023 third-party guidance.
How does model risk guidance apply to machine-learning models and LLMs?
The 2011 text never mentions artificial intelligence, machine learning or neural networks. It did not need to: a supervised-learning model that “applies statistical ... techniques ... to process input data into quantitative estimates” is a model under Section III, and banks and examiners treated it as one. The 2021 interagency statement on model risk management for BSA/AML systems (SR 21-8 / OCC 2021-19) confirmed that the principles applied flexibly to machine-learning transaction monitoring, and the agencies' March 2021 request for information on AI pointed to SR 11-7 as a framework that already applied. What the 2011 text could not anticipate was a model whose output is text rather than a number, whose behaviour changes with a prompt, and whose weights the bank does not own.
The 2026 revision answers that gap by drawing a line rather than extending the framework. SR 26-2 keeps traditional and non-generative machine-learning models inside the guidance, with validation and monitoring scaled to materiality, and states that generative AI and agentic AI models “are novel and rapidly evolving” and “are not within the scope of this guidance”, directing banks to apply broader risk-management and governance practices to them. Fed Vice Chair for Supervision Michelle Bowman described the change on April 27, 2026 as clarifying that the guidance “does not” reach generative AI, in remarks we track as Bowman: AI in the Financial System, and the agencies said a request for information on AI and model risk would follow. The OCC's Spring 2026 Semiannual Risk Perspective (May 7, 2026) reports banks taking a “measured approach” to generative and agentic AI, limited to specific cases with guardrails and a human in the loop. Six months earlier, in October 2025, OCC Bulletin 2025-26 had told community banks that the 2011 guidance had been read too prescriptively, for instance as requiring a full validation of every model every year.
| System | Under SR 11-7 / OCC 2011-12 (to Apr 17, 2026) | Under SR 26-2 / OCC 2026-13 (from Apr 17, 2026) | Elsewhere |
|---|---|---|---|
| Scorecards, regression, stress and capital models | In scope. | In scope if “complex”; simple arithmetic and deterministic rules drop out of the inventory. | PRA SS1/23 covers all models used to inform decisions, with tiering. |
| Non-generative ML (credit, fraud, AML, pricing) | In scope by the technology-neutral definition; applied in practice. | In scope; intensity of validation set by materiality. | ECB internal-models guide (July 2025) requires ML capital models to be explainable and their complexity justified; EU AI Act Annex III for credit scoring of natural persons from Dec 2, 2027. |
| Generative AI (LLM assistants, document summarisation, code) | Not addressed; banks improvised under the model definition or treated it as a tool. | Expressly out of scope; governed through enterprise, third-party and data-governance practices pending the promised RFI. | PRA's November 2025 AI/ML roundtable applies SS1/23 to AI; DORA governs the vendor and ICT side in the EU. |
| Agentic AI (tool-using agents acting on systems) | Not addressed. | Expressly out of scope, same as generative AI. | Our agentic banking section tracks the emerging expectations. |
| Vendor and foundation models | In scope; developmental evidence, own-use validation, contingency plan. | Stand-alone vendor section tied to SR 23-4 third-party guidance. | DORA Articles 28–30 in the EU; PRA SS2/21 outsourcing in the UK. |
The practical consequence is a two-track programme. Machine-learning models keep the full SR 11-7 treatment, now under SR 26-2: inventory, conceptual-soundness review of features and training data, monitoring for drift, outcomes analysis by segment, and effective challenge from an independent validator. Generative and agentic systems need a governance home that is not the model policy, because the guidance now declines to be one; until the agencies' request for information turns into guidance, the questions examiners ask about them come from third-party risk, data governance, information security and consumer-protection law, and the discipline most banks borrow is the NIST AI Risk Management Framework (our NIST AI RMF guide).
What should a bank do with SR 11-7 now?
- Re-point policies that cite SR 11-7 or OCC 2011-12 to SR 26-2, OCC Bulletin 2026-13 or FDIC FIL-15-2026. The 2011 text is history, archived in the OCC's rescinded-bulletins collection; historic validation reports written against it remain valid records.
- Re-screen the inventory against the narrower 2026 definition. Deterministic rules and simple arithmetic can leave the model inventory; document the reasoning for each removal, because the ECB and PRA definitions are wider.
- Keep the three validation elements distinct in every report: a finding on conceptual soundness is not cured by good back-testing, and the structure survived the revision unchanged.
- Treat training data as developmental evidence: lineage, representativeness and the date of the cut go into the conceptual-soundness section, which is where SR 26-2 keeps the data-quality expectation.
- Give generative and agentic AI an explicit governance owner outside the model policy, with inventory, use restrictions, vendor terms and exit plans, so that the question “who governs this?” has an answer when the examiner asks it.
- Scale by materiality on purpose: SR 26-2 is written for banks above $30 billion in assets, and OCC Bulletin 2025-26 told community banks that annual full validation of every model was never required.
- If the bank operates in the UK or the euro area, map the SR 26-2 programme onto PRA SS1/23 (five principles, model tiering, all models that inform decisions) and the ECB internal-models guide; our PRA SS1/23 vs SR 26-2 comparison lists the differences cell by cell.
Is SR 11-7 the same as OCC Bulletin 2011-12?
Yes. The Federal Reserve and the OCC issued one document, the Supervisory Guidance on Model Risk Management, on April 4, 2011. The Fed transmitted it as SR Letter 11-7 and the OCC as Bulletin 2011-12; the FDIC adopted the same text in June 2017 as FIL-22-2017. All three were replaced on April 17, 2026.
Is SR 11-7 still in effect in 2026?
No. SR 11-7, OCC Bulletin 2011-12 and FDIC FIL-22-2017 were superseded on April 17, 2026 by revised interagency guidance issued as SR 26-2, OCC Bulletin 2026-13 and FDIC FIL-15-2026. The replacement keeps the three elements and the vocabulary but narrows the definition of a model, scales validation to materiality and excludes generative and agentic AI.
What are the three pillars of SR 11-7?
Robust model development, implementation and use (Section IV); a sound model validation process (Section V); and governance, policies and controls (Section VI). The guidance calls them elements rather than pillars, and effective challenge is the principle that runs through all three.
What are the three core elements of model validation in SR 11-7?
Evaluation of conceptual soundness, including developmental evidence; ongoing monitoring, including process verification and benchmarking; and outcomes analysis, including back-testing. They sit inside the validation pillar and are distinct from the three pillars themselves.
How does SR 11-7 define 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, including approaches whose inputs are partly or wholly qualitative provided the output is quantitative. SR 26-2 narrows this to complex methods and excludes simple arithmetic and deterministic rules.
Does SR 11-7 apply to machine learning and large language models?
Machine-learning models with quantitative outputs met the 2011 definition and were validated under it; they remain in scope of SR 26-2. Large language models and agentic AI were never addressed by the 2011 text, and SR 26-2 states that generative and agentic AI models are not within its scope, leaving them to broader risk-management and governance practices pending an interagency request for information.
Did SR 11-7 require every model to be validated every year?
It required a periodic review of each model at least annually to decide whether the model works as intended and whether existing validation is sufficient; that review could simply affirm earlier work. OCC Bulletin 2025-26 (October 2025) told community banks the guidance had been read too prescriptively, and SR 26-2 ties validation intensity to materiality.
What must a model inventory contain under SR 11-7?
A firm-wide record of models in use, under development and recently retired, maintained by a designated party, describing each model's purpose and products, actual or expected usage and restrictions, the type and source of inputs and underlying components, outputs and their use, validation dates and findings, owners, developers, validators and users, and the status of open issues.
- Supervisory Guidance on Model Risk Management (SR 11-7 attachment) — Board of Governors of the Federal Reserve System and OCC, Apr 4, 2011 (federalreserve.gov) · our page on SR 11-7
- OCC Bulletin 2011-12: Sound Practices for Model Risk Management (rescinded archive) — Office of the Comptroller of the Currency, Apr 4, 2011 (occ.gov) · our page on OCC Bulletin 2011-12
- SR 26-2: Revised Guidance on Model Risk Management — Federal Reserve Board, Apr 17, 2026 (federalreserve.gov) · our page on SR 26-2
- OCC Bulletin 2026-13: Model Risk Management: Revised Guidance — Office of the Comptroller of the Currency, Apr 17, 2026 (occ.gov) · our page on OCC Bulletin 2026-13
- FDIC FIL-15-2026: Agencies Revise the Interagency Model Risk Management Guidance — Federal Deposit Insurance Corporation, Apr 17, 2026 (fdic.gov) · our page on FDIC FIL-15-2026
- Interagency Statement on Model Risk Management for Bank Systems Supporting BSA/AML Compliance (SR 21-8) — Federal Reserve, OCC, FDIC, NCUA, FinCEN, Apr 9, 2021 (federalreserve.gov) · our page on 2021 BSA/AML Model Risk Statement
- SR 23-4: Interagency Guidance on Third-Party Relationships: Risk Management — Federal Reserve Board, Jun 7, 2023 (federalreserve.gov) · our page on SR 23-4
- Artificial Intelligence in the Financial System (Vice Chair for Supervision Michelle W. Bowman) — Federal Reserve Board, May 1, 2026 (federalreserve.gov) · our page on Bowman: AI in the Financial System (May 2026)
- Semiannual Risk Perspective, Spring 2026 — Office of the Comptroller of the Currency, May 7, 2026 (occ.treas.gov) · our page on OCC Semiannual Risk Perspective, Spring 2026
- SS1/23: Model risk management principles for banks — Prudential Regulation Authority, May 17, 2023 (bankofengland.co.uk) · our page on PRA SS1/23
- PRA model risk management roundtable on AI and machine learning (slides) — Prudential Regulation Authority, Nov 24, 2025 (bankofengland.co.uk) · our page on PRA AI/ML model-risk roundtable (Nov 2025)
When this rule moves, the next morning's brief says so
when one of these regulators moves, the next morning's brief says so · six sourced stories · 7 am ET · free
plus every tracker, bank and agent page update, the morning after · leave any morning