The Federal Reserve's SR 11-7 guidance has been the backbone of bank model risk management for over a decade. It was built around a specific mental model: a quantitative analyst builds a logistic regression or a credit scoring model, a separate validation team stress-tests it, and the model inventory captures its inputs, assumptions and limitations. That framework works reasonably well for traditional statistical models. It is straining under the weight of foundation model deployments inside regulated financial institutions.
Banks are now deploying large language models for customer service, document summarization, credit memo generation, BSA/AML narrative drafting and internal code review. Each of those use cases touches either a consumer-facing product or a regulatory workflow. That means SR 11-7 model risk management obligations attach, and the guidance has not been rewritten to say how. This article walks through what the gaps look like in practice, what OCC and FDIC examiners are actually asking in supervisory examinations, and what a defensible validation posture looks like in 2026.
SR 11-7 Was Not Written for This
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. That definition is broad enough to capture LLMs on its face. The Federal Reserve and OCC have both confirmed that foundation models deployed for material business decisions fall inside the model inventory requirement.
The problem is not definition coverage. The problem is that validation methodology assumed something the guidance authors had no reason to anticipate: that the model developer would not be the bank, the training data would not be auditable, the weights would not be inspectable, and the behavior of the model would shift with prompt phrasing in ways that do not map to traditional sensitivity analysis.
SR 11-7 instructs validators to evaluate conceptual soundness, ongoing monitoring and outcomes analysis. All three of those pillars require access to information that a bank using a third-party foundation model via API simply does not have. You cannot audit GPT-4's training corpus. You cannot inspect its weight distribution. You cannot run a traditional back-test on a model whose output is a paragraph of text rather than a probability score.
That is the core of the problem in 2026. The regulatory obligation is real. The methodology to satisfy it does not exist yet in any standardized form.
What SR 11-7 Actually Requires
Before examining the gaps, it is useful to be precise about what the guidance actually mandates so that compliance officers and model validation teams are solving the right problem.
SR 11-7 establishes three core requirements. First, model development and implementation must follow sound practices that include clear documentation of purpose, design assumptions, data inputs and known limitations. Second, model validation must be performed by parties independent of model development and must cover conceptual soundness, data quality and ongoing performance monitoring. Third, governance and controls must ensure that model use is consistent with documented purpose and that material model risk is escalated to senior management and the board.
The guidance also explicitly requires that banks manage vendor and third-party models with the same rigor as internally developed models. This last point is what makes foundation model governance so operationally difficult. The guidance assumes that a vendor model, like an internally built one, can be examined, tested and documented. That assumption does not hold for closed-weight frontier models delivered via API.
The Foundation Model Validation Gap
The validation gaps that emerge when SR 11-7 meets a foundation model deployment cluster around four specific failure modes.
Conceptual Soundness Cannot Be Verified
For a credit risk model, conceptual soundness means the validator can examine whether the theoretical relationship between predictor variables and the outcome is grounded in economic logic and supported by literature. For an LLM summarizing loan documents, what does conceptual soundness mean? The model was not designed for that task. It was pre-trained on a general corpus and fine-tuned or prompted for domain application. There is no theory section in the model card that a validator can evaluate against established finance literature.
The practical workaround banks are using is behavioral evaluation: red-teaming, adversarial prompting, hallucination rate measurement and structured scoring rubrics. That is better than nothing. It is not the same as conceptual soundness review and examiners are starting to notice the difference.
Sensitivity Analysis Does Not Transfer
SR 11-7 expects validators to test how model outputs change with changes in inputs and assumptions. For a logistic regression, that is straightforward. For an LLM, prompt sensitivity is enormous and non-linear. Changing one word in a system prompt can shift output tone, accuracy and compliance posture in ways that are not predictable from first principles. Banks that are running serious LLM validation programs are now documenting prompt versioning alongside model versioning and treating a prompt change as a model change requiring validation review. Most are not doing this yet.
Outcome Metrics Are Undefined for Generative Outputs
Traditional model monitoring uses error rates, Gini coefficients, Kolmogorov-Smirnov statistics and population stability indices. None of those apply cleanly to a model that produces text. There is active research on automated evaluation metrics including RAGAS for retrieval-augmented generation systems and G-Eval frameworks for LLM output quality. These are not yet standardized and examiners are not expecting them to be. What examiners are expecting is that banks have defined what good output looks like and are measuring against that definition consistently.
Model Drift Is Not Weight Drift
SR 11-7's ongoing monitoring requirement was designed for statistical model drift: the relationship between predictors and outcomes degrades over time as the data generating process changes. For a hosted foundation model, the bank may not know when the underlying model is updated. OpenAI, Anthropic and Google all issue model version updates that can change behavior materially. A bank using a pinned model version has partial protection. A bank using a floating endpoint has essentially no control over model stability and is running an SR 11-7 monitoring program against a target that moves without notice.
What OCC and FDIC Examiners Are Asking in 2026
Based on supervisory communications and publicly available OCC examination guidance, examiners are focusing on several consistent questions when they encounter foundation model deployments during horizontal reviews.
The first line of questioning concerns inventory completeness. Is the foundation model in the model inventory? What tier of materiality has been assigned? Many banks are inventorying LLMs but assigning them low materiality ratings to reduce validation burden. Examiners are challenging that classification directly, particularly for models touching customer communication, credit decisioning support or regulatory reporting workflows.
The second area is validation independence. SR 11-7 requires that validators be independent of model developers. For a foundation model, the bank did not develop the model, which creates an interpretive question about who satisfies the independence requirement. Some banks are treating the vendor relationship management team as the relevant party. Examiners are not finding that satisfying.
The third area is use case scope creep. Banks often deploy an LLM for a narrow documented purpose and then expand use informally. A model validated for internal document summarization gets used for drafting customer dispute responses. Examiners are asking whether model governance controls prevent or detect scope expansion and whether expanded use triggers re-validation.
The fourth area is vendor due diligence documentation. Under SR 11-7's third-party model provisions, banks must obtain sufficient information from vendors to perform meaningful validation. Examiners are asking specifically what the bank has obtained: model cards, system cards, evaluation benchmarks, red team reports. For closed-weight commercial models, those documents may not exist or may be heavily redacted. That is a finding that banks need to document and escalate rather than ignore.
A Workable MRM Framework for LLMs
Several leading institutions are converging on a layered framework that maps SR 11-7 requirements to LLM-specific validation controls. It is not a perfect analogy but it is defensible.
The first layer is use case classification. Not every LLM deployment is a material model under SR 11-7. Banks are developing classification rubrics based on decision materiality, consumer impact and regulatory workflow involvement. An internal coding assistant is different from a credit memo generator. The classification decision must be documented and defensible.
The second layer is prompt governance. Since prompt design functions as a specification layer for LLM behavior, leading programs are treating prompts as model artifacts subject to version control, change management and validation review. Prompt changes above a defined threshold of complexity require the same approval workflow as model parameter changes.
The third layer is behavioral testing batteries. These replace traditional statistical validation with structured evaluation suites covering accuracy on domain-specific test cases, hallucination rate on factual claims, adversarial robustness, demographic fairness and regulatory compliance of outputs. The test cases must be representative of production inputs, updated regularly and scored against documented acceptance thresholds.
The fourth layer is human-in-the-loop controls. For high-materiality use cases, the model output must be reviewed by a qualified human before it drives a decision or leaves the institution. This does not eliminate model risk but it does create an auditable control that examiners can verify.
The fifth layer is vendor contractual controls. Banks are negotiating for model version pinning, advance notification of model updates, access to evaluation reports and the right to audit model behavior. For frontier model providers, some of these terms are not available. That unavailability must be documented as residual risk and escalated appropriately.
Third-Party Model Risk and Vendor Opacity
SR 11-7 states explicitly that a bank's use of vendor models does not diminish the bank's responsibility to manage model risk. The Federal Reserve and OCC have reiterated this position in the context of AI and machine learning in multiple supervisory letters and speeches since the guidance was first issued.
The operational problem is that the major foundation model providers are not structured as bank technology vendors. They do not have banking examination experience and their standard API terms of service were not written with SR 11-7 compliance in mind. Banks that want to deploy OpenAI, Anthropic, Google or Mistral models in material workflows need to treat the contractual negotiation as a compliance exercise, not a procurement exercise.
The minimum documentation a bank should obtain before deploying a third-party foundation model in a material use case includes: a model card describing training data categories, evaluation benchmarks and known limitations. A current system card for any instruct-tuned or RLHF-trained variant. Third-party red team or safety evaluation reports. A data processing agreement that addresses whether bank inputs are used for training. And a commitment to advance notification of model version changes. Where any of these are unavailable, the gap must be disclosed in the validation report as unresolved residual risk. Examiners are looking for honest risk acknowledgment more than they are looking for perfect coverage.
Documentation and Ongoing Monitoring Requirements
SR 11-7's documentation requirements are often where LLM programs fail their first examination. The guidance requires that models be documented sufficiently for a knowledgeable third party to understand the model's purpose, design, data inputs, assumptions, limitations and validation results. That is a high bar for a system where the core model was built by a third party and the bank's contribution is a system prompt and a retrieval pipeline.
The emerging standard for LLM model documentation in regulated financial institutions covers the following elements. Purpose and scope: what decisions or outputs does the model produce and what business process does it support. Architecture description: what foundation model is used, what version, what fine-tuning or retrieval augmentation has been applied, and what prompt design governs behavior. Data provenance: what retrieval sources, knowledge bases or context documents are injected at inference time. Validation results: what test suite was run, what acceptance thresholds were set and what the results were. Ongoing monitoring plan: how often is the behavioral test battery re-run, who reviews results and what triggers re-validation. Known limitations and residual risks: what the model cannot do reliably and what human controls compensate.
Ongoing monitoring for LLMs should include at minimum: quarterly re-runs of the behavioral evaluation suite, automated logging and sampling of production inputs and outputs, regular human review of sampled outputs by domain experts and immediate re-validation triggered by any upstream model version change. For retrieval-augmented generation systems, monitoring must also cover the retrieval layer: index staleness, retrieval relevance scores and citation accuracy.
The institutions that are doing this well are treating LLM governance as a continuous process rather than a point-in-time validation event. That shift in posture is both what SR 11-7 actually requires and what the technology demands. Foundation models are not static artifacts. A compliance program built around static validation will fail on both regulatory and technical grounds.
For institutions building out these programs, the data governance infrastructure that supports model monitoring is closely connected to broader data rights and ownership frameworks. Resources at ownmydata.ai address the consent and provenance infrastructure that underpins compliant data pipelines. Implementation patterns for data access controls in regulated environments are documented at mydatakey.org. The Federal Reserve's original SR 11-7 guidance remains the authoritative source for model risk management obligations and is available directly through the Federal Reserve supervision and regulation release library.