Does SR 11-7 Apply to Generative AI? Model Risk Management After SR 26-2

For fifteen years, a bank asked one document what a controlled model looks like. SR 11-7, the Federal Reserve and OCC guidance on model risk management issued in April 2011, gave the answer in a vocabulary every model risk officer now speaks natively: inventory, validation, effective challenge, ongoing monitoring, documentation. It was written for credit scorecards and pricing engines, and it aged remarkably well, because it codified something close to first principles.

On April 17, 2026, the agencies retired it. SR 26-2, issued jointly by the Federal Reserve, OCC, and FDIC, supersedes SR 11-7 and its BSA/AML companion, and it makes one scoping decision that matters more than everything else in the document combined. Footnote 3: "Generative AI and agentic AI models are novel and rapidly evolving. As such, they are not within the scope of this guidance."

So the systems drafting credit memos, summarizing suspicious activity, answering customer correspondence, and sitting inside half the vendor tools a bank licenses are now, formally, outside the model risk guidance. Not exempted from risk management: the same footnote says a bank's "risk management and governance practices should guide the determination of appropriate governance and controls" for whatever falls outside. Guided by principles, covered by nothing specific, and examined by supervisors who have promised a request for information rather than rules.

This piece is a working framework for that interim, written for the people who own the problem: what SR 11-7 actually required, why its successor let generative AI go, which disciplines transfer anyway, which assumptions break, and the record-keeping that lets a bank demonstrate control over a system it cannot inspect line by line.

1. What SR 11-7 actually required

Precision about the source text matters, because most of what circulates about SR 11-7 is summary of summary. The guidance defined 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," with three components: an information input component, a processing component, and a reporting component. The definition reached approaches "whose inputs are partially or wholly qualitative or based on expert judgment, provided that the output is quantitative in nature."

Model risk, in its telling, arises for two reasons: the model may have fundamental errors, or it "may be used incorrectly or inappropriately." Against both, the guidance built a scaffold whose load-bearing beam was effective challenge: "critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate changes," resting on a combination of "incentives, competence, and influence."

Validation had three core elements, quoted so often they became the field's liturgy: evaluation of conceptual soundness, including developmental evidence; ongoing monitoring, including process verification and benchmarking; and outcomes analysis, including back-testing. Material changes to models required revalidation before implementation. Banks were to maintain a firm-wide inventory of models in use, in development, or recently retired, with any variation warranting separate validation listed as a separate model. Vendors were expected to supply "developmental evidence explaining the product components, design, and intended use," disclose limitations, and support ongoing monitoring; banks were "expected to validate their own use of vendor products" and to hold contingency plans for the day a vendor model is no longer available. And documentation was to be "sufficiently detailed so that parties unfamiliar with a model can understand how the model operates, its limitations, and its key assumptions."

Read as a whole, the guidance assumed something it never needed to state: that the bank could, at least in principle, see everything. The code, the data, the assumptions, the change history. Every discipline in the document is a way of exercising that access.

2. Does SR 11-7 apply to generative AI? The answer changed in April 2026

Until this spring, the honest answer was: yes, in practice, uncomfortably. The 2011 definition was broad, supervisors applied it broadly, and nothing else existed. When the Federal Reserve, OCC, FDIC, NCUA, and CFPB issued their joint request for information on financial institutions' use of AI in March 2021, model risk guidance was the obvious frame of reference. The Financial Stability Oversight Council named AI a vulnerability in the financial system for the first time in its 2023 annual report. NIST published a generative AI profile of its AI Risk Management Framework in July 2024, cataloging risks with no analogue in a probability-of-default model, confabulation among them. Treasury ran its own request for information that summer and reported on the sector's AI use that December. Through all of it, examiners and model risk teams stretched SR 11-7 over systems it never anticipated, because it was the only fabric available.

The United Kingdom made the opposite choice explicit: the Prudential Regulation Authority's SS1/23, effective May 2024, wrote artificial intelligence and machine learning into the scope of its model risk principles directly.

The US agencies resolved the question the other way. SR 26-2 narrows the definition of a model to a "complex" quantitative method resting on "statistical, economic, or financial theories," excludes deterministic rule-based software, states that it does not set forth enforceable standards, notes it is expected to be most relevant to banking organizations with over $30 billion in total assets, and places generative and agentic AI outside its scope entirely. Vice Chair for Supervision Michelle Bowman was candid about the intent in a May 2026 speech: "Over time, supervisors expanded the scope of the previous guidance beyond its original purpose to apply it in unintended ways. ... The revised guidance now applies narrowly to traditional models and basic AI applications." In the same remarks: "Today, banks are relying on existing risk-management frameworks to guide their use of AI."

What comes next is a question, literally. OCC Bulletin 2026-13, the bulletin that carries the revised guidance, says the agencies "plan to issue in the near future a request for information that addresses model risk management generally and considers, in particular, banks' use of AI, including generative AI and agentic AI and AI-based models." The Financial Stability Board's June 2026 consultation on sound practices for AI adoption points the same direction: internationally coordinated principles, not yet rules.

So the current state, stated plainly: the guidance that governed models for fifteen years is rescinded; its successor declines the systems at the frontier; the agencies have signaled interest and asked for patience. The model risk officer's mandate did not shrink with the scope. Boards, auditors, and examiners will still ask who governs the bank's generative systems, and the only available answer is the bank's own framework, built from the parts of the old discipline that still hold.

Which requires knowing which parts those are.

3. What breaks: four assumptions generative AI does not honor

SR 11-7's disciplines were built on assumptions so reliable in 2011 that the text never argues for them. Generative systems void each one.

A 2011 modelA generative system

• 01

  An artifact the bank holds“What is the model, and which version is live?”

  Code in a repository, coefficients in a table, a version number that changes when the bank changes it. The inventory lists it; the change log dates it.

  Vendor-hosted weights behind an API name that can front different behavior over a quarter, wrapped in prompts, corpora, and tools maintained by different hands. The version in force is a composite no one owns end to end.

  Holds
• 02

  Output a test can check“Same input, same output?”

  Yes: a quantitative estimate, reproducible on demand, scored against realized outcomes. Back-testing, benchmarking, and out-of-time testing all rest on this.

  No: decoding samples from a distribution, so a single run proves little in either direction. Evidence moves to populations (curated test sets, scored samples, worst-case rates) and never yields the older certainty.

  Holds
• 03

  Changes the bank schedules“When does revalidation trigger?”

  At the bank's own material changes: discrete, planned, rare, and validated before implementation, exactly as the guidance prescribed.

  Continuously and from every direction: prompt edits, corpus refreshes, new tools, silent vendor updates, forced deprecations. Each is arguably a model change; none waits for the bank's calendar.

  Holds
• 04

  Challenge with access“Can the challenger reach the thing challenged?”

  Yes: read the code, interrogate the assumptions, rebuild the estimation. Vendor gaps were patched with developmental evidence and disclosure.

  Weights, training data, and alignment internals are undisclosed, and no bank can compel more. Challenge survives only against the bank's own use of the system, never the system itself.

  Holds

SR 11-7 never argued for these assumptions because in 2011 they never failed. Switch the system and the same four questions get materially different answers: 4 of 4 hold under the current one. Every discipline in the old guidance was a way of exercising an access the second column no longer grants.

The model was an artifact the bank holds

A 2011 model was a thing: code in a repository, coefficients in a table, a version number that changes when the bank changes it. The inventory discipline assumes enumerable artifacts with stable identities. A frontier language model is a service: weights the bank will never hold, hosted by a vendor, revised on the vendor's schedule, deprecated on the vendor's notice. The same API name can front materially different behavior over a quarter. Meanwhile the thing the bank actually deploys is not the base model at all but a composite: model, system prompt, retrieval corpus, tool wiring, guardrail layer, each maintained by a different team or vendor. The inventory question "what model is this?" has no single answer, and the inventory question "what version was live in March?" may have none the bank can prove.

The output was a number a test could check

Validation's machinery (back-testing, benchmarking, out-of-time testing) presumes the model maps an input to a quantitative estimate that can be scored against a realized outcome. A generative system produces prose, and produces it non-deterministically: the same input can yield different output across runs by design, since decoding samples from a distribution. A single passed test is therefore weak evidence, and a single failed one is not localizable, since there is no coefficient to inspect. Evaluation has to move from the instance to the population: curated test sets, scored samples, distributions of error, worst-case rather than average. That is tractable, and a growing validation literature is building it, but it is a different epistemology than back-testing a PD model, and it never yields the older kind of certainty. Confabulation, a failure NIST's generative AI profile catalogs by name, has no seat in a 2011 error taxonomy: the system's most dangerous output is fluent, confident, and wrong.

A change was an event the bank scheduled

"Material changes to models should also be subject to validation." In 2011 that sentence had an obvious operational meaning, because changes were discrete, bank-initiated, and rare. In a generative deployment, behavior-altering change arrives continuously and from every direction: a revised system prompt, an edited template, a refreshed retrieval index, a new tool granted to an agent, a vendor's silent model update, a deprecation that forces migration. Each is arguably a model change under the old test, since each can move outputs materially. No bank can run full revalidation for each, and the vendor-initiated ones the bank may not even observe. Change control, the cleanest discipline in the old guidance, is the one that breaks outright.

Challenge presumed access

Effective challenge assumed the challenger could reach the thing challenged: read the code, interrogate the assumptions, rebuild the estimation. SR 11-7's vendor section anticipated proprietary components, but its remedy was disclosure: developmental evidence, testing results, known limitations, delivered by a cooperative vendor to a paying bank. A frontier lab's model card is not that. Training data, alignment procedures, and evaluation internals are undisclosed at a level the 2011 authors did not imagine, and no bank has the standing to compel more. SR 26-2 quietly concedes the point for the models it does cover, noting banks "may not receive from the vendor the underlying code, data, or methodology," while insisting the principles still apply. For generative systems the concession is near-total: challenge survives, but only against the bank's own use of the system, never the system itself.

4. What transfers: the disciplines that still work for LLMs

The wrong reading of section 3 is that model risk management has nothing to offer. Most of the old structure transfers; it just attaches to different objects.

Inventory transfers, with the boundary redrawn. The unit is no longer the model but the use: this task, on this model and endpoint, with this prompt and template revision, over this retrieval corpus, under these limits. SR 11-7 already held the key rule: any variation that warrants separate validation is a separate inventory entry. A generative AI model inventory built on use-tuples can be complete in a way a list of vendor names never will be, and it is the precondition for everything else, including answering the RFI when it lands.

Use limits and materiality tiering transfer intact. SR 26-2's frame of materiality as exposure plus purpose applies to a generative use case without modification, and it is the honest basis for proportionality: a drafting assistant whose output a banker rewrites is not a credit adjudicator, and should not be governed like one. The discipline is stating the limit in writing (what the use is approved for, what it is barred from, what happens at the boundary) and treating an out-of-limit use the way the old regime treated an unvalidated model.

Monitoring and outcomes analysis transfer, reshaped. Ongoing monitoring was always the discipline that assumed least about the model's interior, which is why it survives best. Population-level scoring against curated golden sets, sampled human review with recorded verdicts, drift alarms on input and output distributions, and complaint and override tracking are all recognizable descendants of the 2011 text. Even parallel outcomes analysis has a direct descendant: when a vendor forces a model migration, running old and new against the same test population before cutover is precisely the discipline SR 11-7 prescribed for model adjustments.

Vendor management transfers with more weight on it. The old expectations (developmental evidence, disclosed limitations, change notification, contingency plans) become contract requirements rather than assumptions. The contingency-plan expectation reads as prophecy: model deprecation is not a tail risk in this market, it is a published schedule.

Documentation transfers as the load-bearing wall. "Parties unfamiliar with a model" is simply a description of every future examiner of a generative system, including the bank's own staff two years out. Which is where the framework has to go next, because documentation of a system that changes weekly and answers differently twice cannot mean a validation report. It has to mean a record of use.

5. Demonstrating control you cannot exercise line by line

Here is the uncomfortable arithmetic the interim leaves. A bank cannot validate a frontier model's interior: no access. It cannot freeze the system: the vendor ships. It cannot test its way to per-output certainty: the output space is language. Line-by-line control, the kind SR 11-7's authors could assume, is not available at any price a bank can pay.

What remains available is control over use, and evidence of it. Not "we validated the model" but: this output, on this date, came from this endpoint at this template revision, over this corpus snapshot, inside this approved use and its written limits, was reviewed by this person holding this authority, and the record of all of it was sealed when the decision issued and has provably not changed since. Every clause is something the bank actually controls, which is what makes the claim honest, and the set of clauses is exactly the anatomy an examiner reconstructs after the fact. We have written about why operational logs cannot carry this burden and about what a decision record must contain to survive audit; the argument lands harder here, because for generative systems the record is not one control among many. It is the control. A bank that cannot inspect the model and cannot enumerate its states has exactly one demonstrable object per decision: the sealed record of what it did.

Model inventoryTransfersUse limits & materialityTransfersOngoing monitoringTransfersOutcomes analysisTransfersConceptual soundness reviewStrainsEffective challengeStrainsChange controlBreaksDocumentation & recordsTransfers

Model inventoryTransfersSurvives with the boundary redrawn.

What changes · The unit of inventory shifts from the model artifact to the use: task, model and endpoint, prompt and template revision, retrieval corpus, written limits. SR 11-7's own rule ports directly: any variation warranting separate validation is a separate entry.

What compensates · An inventory of use-tuples, including AI embedded in vendor software. It is the precondition for every other discipline, and for answering the agencies' promised request for information.

The reading that matters is the last row. Documentation not only transfers, it is the compensating control for the rows that strain and break: a bank that cannot inspect the model and cannot enumerate its states has exactly one demonstrable object per decision, the sealed record of what it did.

This also fits the supervisory temperament on display. The agencies withdrew prescription and promised questions. When the questions arrive, whether in the promised RFI, an exam, or a discovery request, they will be retrospective: show us what ran, under what limits, reviewed by whom. A framework built on decision-level records answers retrospective questions as queries. A framework built on policy documents answers them as reconstruction projects, and reconstruction, as the model risk field has known since 2011, is where control goes to be asserted rather than demonstrated.

For completeness: this is the problem the Sigilith Platform is built for, checking each consequential AI output against the policy in force and sealing the record at issue, with evidence packs exportable for exactly these reviews. The framework above stands on its own regardless of tooling.

6. Before the RFI lands

Five moves, in dependency order, each defensible to a board today:

1. Build the generative use inventory now, including AI embedded in vendor software. The revised guidance no longer compels it; the coming RFI, the FSB's consultation, and the first exam question all assume it. An inventory of use-tuples, not product names.
2. Tier by materiality and write the use limits. Exposure plus purpose, per use, with the barred uses stated as plainly as the approved ones.
3. Stand up population-level monitoring for the material tier: golden sets, sampled human review, drift and override tracking, and parallel runs at every forced migration.
4. Contract for the old vendor expectations: developmental evidence, change and deprecation notice, disclosed limitations, and a contingency path off the model.
5. Write decision-level records, binding model and template revision, corpus state, policy in force, reviewer, and output, sealed at issue and retained on the exposure horizon.

Then run the diagnostic this series keeps returning to, aimed at the new target: pick one generative output your institution issued last quarter and try to produce, today, the record in move five. Time the attempt. However long it takes is a precise measure of the distance between the control your framework asserts and the control it can demonstrate, and it is the same measurement an examiner will eventually take.

Sources

The guidance, before and after

• Federal Reserve, SR 11-7: Guidance on Model Risk Management, 4 April 2011, and the attached guidance (superseded 2026)
• Federal Reserve, SR 26-2: Revised Guidance on Model Risk Management, 17 April 2026, and the attached interagency guidance
• OCC, Bulletin 2026-13: Model Risk Management: Revised Guidance, 17 April 2026 (rescinding OCC Bulletin 2011-12 and the Model Risk Management booklet of the Comptroller's Handbook)
• Bank of England PRA, SS1/23: Model risk management principles for banks, May 2023, effective 17 May 2024

Agency statements and inquiries on AI in banking

• Federal Reserve, OCC, FDIC, NCUA, CFPB, Request for Information and Comment on Financial Institutions' Use of Artificial Intelligence, Including Machine Learning, 86 FR 16837, 31 March 2021
• Michelle W. Bowman, Artificial Intelligence in the Financial System, remarks at the FSOC AI Series Roundtable, 1 May 2026
• Michelle W. Bowman, Opening remarks on sound practices for artificial intelligence, FSB virtual outreach event, 7 July 2026
• Financial Stability Oversight Council, 2023 Annual Report, December 2023 (first identification of AI as a financial-system vulnerability)
• U.S. Department of the Treasury, Request for Information on Uses, Opportunities, and Risks of Artificial Intelligence in the Financial Services Sector, 12 June 2024, and Artificial Intelligence in Financial Services, December 2024
• Financial Stability Board, Sound Practices for Responsible Adoption of Artificial Intelligence (AI): Consultation report, 10 June 2026

Standards and technical literature

• NIST, AI 600-1: Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile, July 2024
• A. Bhattacharyya, Y. Yu, H. Yang, R. Singh, T. Joshi, J. Chen, K. Yalavarthy, "Model Risk Management for Generative AI In Financial Institutions", arXiv preprint, March 2025

Related Sigilith analysis

• The AI Audit Gap: Why "Logs" Aren't Evidence
• What an AI Decision Record Must Contain to Survive Audit
• 1.1 Billion Decisions, No Record: What Mobley v. Workday Reveals About AI Evidence