LLM Model Risk Documentation for Banks: A Working Guide

On April 17, 2026, US banking regulators replaced SR 11-7, the fifteen-year-old model risk framework, with SR 26-2 — and explicitly removed generative AI from its scope. That does not mean your LLM systems are ungoverned. It means there is no prescriptive US standard telling you what to write down, so the documentation you produce is your entire defense when an examiner, auditor, or board member asks why the model can be trusted. This guide is the documentation pack we recommend every bank and insurer maintain for each LLM system: five documents, the fields that go in them, and the events that force a rewrite.

What SR 26-2 actually changed

The Federal Reserve, OCC, and FDIC issued SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. Three changes matter for anyone running LLMs.

First, it supersedes SR 11-7 (2011) and SR 21-8 (2021) entirely. The OCC's Bulletin 2026-13 also rescinds OCC 2011-12, the old credit-scoring bulletin 1997-24, and the MRM booklet of the Comptroller's Handbook. If your policies cite SR 11-7 as the governing standard, those citations now point at a withdrawn document.

Second, scope. SR 26-2 is expected to be most relevant to banking organizations with over $30 billion in assets, and it states plainly that generative AI and agentic AI models are "novel and rapidly evolving" and therefore not within its scope. The same footnote adds that a banking organization's own risk management and governance practices should guide how it controls anything the document does not cover. Read that twice: the agencies declined to write the GenAI rulebook and handed the pen to you.

Third, tone. The guidance is explicitly not a set of enforceable standards; non-compliance with the guidance alone will not draw supervisory criticism. But the same paragraph notes that supervisory action can follow from unsafe or unsound practices stemming from insufficient management of model risk. Principles-based does not mean optional.

The agencies also signaled what comes next: a Request for Information on model risk management that specifically covers banks' use of generative and agentic AI. The carve-out is a pause, not an exemption. We covered the strategic picture in SR 26-2 and GenAI Model Risk: What Banks Must Build Now; this post is the paperwork.

Who still needs this documentation

Three groups, for three different reasons.

US banks of any size. SR 26-2 says it may still be relevant to institutions at or below $30 billion in assets where model use is complex. More importantly, the OCC's Fall 2025 Semiannual Risk Perspective had already flagged AI as an emerging risk requiring management commensurate with its materiality, and a May 2025 GAO report on AI oversight in financial services found examiners were applying the old guidance to AI tools inconsistently. When the standard is unsettled, the institution with clear, reasoned documentation of its own framework is in a far better exam position than the one waiting for Washington.

UK-regulated firms. The PRA's SS1/23, Model Risk Management Principles for Banks, takes the opposite approach on scope: its five principles apply to all models used to inform business decisions, whether developed in-house or externally, regardless of technology, explicitly including AI and machine learning techniques. It also requires responsibility for the MRM framework to sit with a named Senior Management Function holder. If you are UK-regulated, your LLMs are in scope today, no carve-out.

Any bank or insurer touching the EU. The EU AI Act's Article 11 requires technical documentation for high-risk AI systems to be drawn up before the system is put into service and kept up to date. Credit scoring and life-insurance pricing are high-risk uses. Annex IV lists the minimum contents, starting with a general description, intended purpose, context and conditions of use, provider, and version. If you build one documentation pack to the standard below, you can map it onto Annex IV with modest effort rather than starting over.

Insurers should note that while US insurance regulation runs through state regulators and the NAIC rather than the Fed, the same examiner logic applies: inventory, validation evidence, monitoring, and a named owner.

The documentation pack: five documents per LLM system

The old SR 11-7 text, now marked as superseded on the Federal Reserve's site, set a documentation bar that still reads well: sufficiently detailed that parties unfamiliar with the model can understand how it operates, its limitations, and its key assumptions. Organize that into five documents.

1. The model inventory record

One record per LLM system, in the same inventory as your traditional models. The fields that differ from a credit scorecard:

• System name and a named individual owner. A person, not a team.
• Model type and provenance. Foundation model API, fine-tuned open-weight model, RAG pipeline, or prompt-engineered wrapper, plus provider and exact model version.
• Use-case boundary. The exact tasks the system is authorized to perform, and the decisions its output may feed.
• Risk tier and rationale. What the output influences: customer communications, credit memos, claims decisions, regulatory reports.
• Deployment environment. Vendor API, your VPC, or on-premise, and where prompts and outputs are stored.
• Prompt and configuration versions. Prompts are model parameters in everything but name; version them in the inventory.
• Human oversight controls. Whether review is mandatory, sampled, or absent, and who performs it.
• Validation status, last review date, and revalidation triggers. Covered below.

A practical field guide for LLM inventories appears in RiskTemplates' write-up on applying model risk guidance to LLMs, which also makes the point that shadow AI — LLM use never registered in the inventory — is the most common gap examiners find.

2. The use-case and conceptual soundness document

SR 11-7's "conceptual soundness" section asked why the model's design fits its purpose. For an LLM you cannot defend the architecture's internals, so defend the boundary instead:

• Why an LLM is appropriate for this task at all, and what alternatives were considered, including not automating.
• What the system may never do: the prohibited outputs and out-of-scope inputs.
• Known failure modes: hallucination, prompt sensitivity, training-data cutoff, behavior on adversarial input.
• Data flows: what goes into prompts, whether personal data is redacted first, where outputs land.
• For RAG systems: the source corpus, update cadence, and how retrieval failures surface to the user.

3. The validation report

Validation still rests on the three pillars the old guidance named — conceptual soundness, ongoing monitoring, and outcomes analysis — but outcomes analysis for an LLM is an evaluation suite, not a back-test. Before deployment, and after every revalidation trigger, document:

• The gold-standard test set: size, source, who labeled it, and how disagreements were resolved.
• Task metrics with numeric pass thresholds: extraction accuracy, hallucinated-fact rate, refusal behavior on out-of-scope inputs.
• Adversarial and red-team results. Our guide to red-teaming an LLM before deployment covers the test design.
• Prompt sensitivity: output variance across rephrasings of the same request.
• Human oversight effectiveness: the measured catch rate of your review process, not just its existence.
• Limitations and conditions of approval, signed by someone independent of the team that built the system.

If you do not have an evaluation suite yet, that is the prerequisite, and we have a separate guide to building an LLM evaluation suite for a bank or insurer. The NIST AI Risk Management Framework and its July 2024 Generative AI Profile (NIST-AI-600-1) are useful voluntary scaffolding for the risk categories your validation should cover.

4. The monitoring plan

Define, before go-live: which metrics are tracked in production, at what frequency, what thresholds trigger investigation, and who gets paged. Minimum set for a customer-adjacent system: accuracy on a rolling sampled audit, hallucination flags per thousand outputs, out-of-scope attempt rate, latency and cost per transaction, and the human review overturn rate. The overturn rate is the early-warning metric most teams miss; when reviewers start correcting the model more often, something drifted.

5. The vendor file

For API models and vendor-built systems, you cannot validate the internals, so validate around them. SR 26-2 keeps the old expectation that vendor products are fully subject to model risk management: understand the vendor model's design, development data, and performance as far as possible, and run your own ongoing outcomes analysis. The file should hold the vendor's model card and safety evaluations, your own use-case validation, and the contract. On the contract, the clauses that matter are advance notification of model version and training-data changes, incident notification, data handling terms for your prompts and outputs, audit or assessment rights, and exit provisions. Our AI vendor due diligence guide goes clause by clause.

A worked example: a claims summarization LLM

Make this concrete. A mid-size insurer deploys a fine-tuned open-weight model in its own VPC to summarize incoming claims packets for adjusters. The numbers below are illustrative, not benchmarks.

• Inventory record. Owner: Head of Claims Operations. Type: fine-tuned open-weight model plus retrieval over the policy document store. Risk tier: high, because summaries feed reserve-setting notes. Oversight: mandatory adjuster review before any summary enters the claim file.
• Validation. Gold set: 600 historical claims packets sampled across four product lines, summarized by senior adjusters, with disagreements adjudicated by a second reader. Thresholds: extracted-field accuracy (dates, amounts, policy numbers) at 97% or better; hallucinated-fact rate below 1% of summaries; zero leakage of medical details into fields visible to unauthorized roles. Prompt sensitivity tested across 25 rephrasings. Result: passes at 98.1% field accuracy, 0.7% hallucination rate, approved with the condition that medical-access controls are re-tested after any model update.
• Monitoring. Weekly: 50-summary sampled audit by QA. Monthly: hallucination flags per 1,000 summaries and adjuster overturn rate, with a 3% overturn threshold triggering review. Quarterly: risk summary to the model risk committee.
• Revalidation triggers. Base model upgrade, retrieval corpus restructuring, overturn rate above threshold for two consecutive months, or expansion to a fifth product line.

That pack — inventory entry, boundary document, validation report, monitoring plan — is roughly 25 pages. It answers the examiner's first ten questions before they are asked.

Revalidation triggers: events, not anniversaries

The old MRM world ran on annual validation cycles. LLMs change faster than that: providers push model updates, prompts get edited, input distributions shift. The OCC had already conceded the point for community banks in Bulletin 2025-26, noting that MRM guidance does not, and should not be interpreted to, require annual validation. Define event-triggered revalidation in the inventory record instead:

• A provider or base-model version change.
• A material prompt, retrieval, or guardrail change.
• Measured degradation past a documented threshold.
• Deployment to a new use case outside the validated boundary.
• A regulatory or policy change affecting the task.

Calendar reviews still have a place as a backstop, but the events above are what actually catch LLM failures. Keep a vendor change log: date, version change, and what revalidation you ran. When a provider silently updates a model, that log is the difference between a controlled event and an exam finding.

Common mistakes

• Citing SR 11-7 as your governing standard. It was superseded in April 2026. Update policy references to SR 26-2 and document how your GenAI framework extends it.
• Treating the GenAI carve-out as a free pass. The carve-out is jurisdictional, not permissive; examiners will test governance at the boundary where traditional ML meets LLM pipelines, especially in transaction monitoring and compliance.
• Documentation theater. A 90-page policy that never names an owner, a threshold, or a trigger fails the "parties unfamiliar with the model" test worse than a short pack with real numbers.
• Validating once at go-live. Without event-triggered revalidation, a vendor model update invalidates your approval without anyone noticing.
• Leaving RAG out of scope. The model is unchanged but the system is not; retrieval corpus changes alter outputs as surely as retraining.
• No measured human oversight. "A human reviews outputs" without a measured catch rate is an assertion, not a control.

When the full framework is the wrong choice

SR 26-2 is explicit that practices should be proportionate to risk, and PRA SS1/23 builds in proportionality too. An internal LLM that drafts meeting notes or summarizes public research, with no path to customer or financial decisions, does not need a validation report with numeric thresholds. It still needs an inventory record and an owner, because shadow AI is how low-risk tools quietly become high-risk ones. The mistake is not under-documenting a low-risk tool; it is never having classified it. Write the inventory record, tier it low, and move on.

Frequently asked questions

Does SR 11-7 still apply to LLMs? No. SR 26-2 superseded SR 11-7 on April 17, 2026, and generative and agentic AI are explicitly outside SR 26-2's scope. In practice, examiners, the PRA, and the EU AI Act all push banks toward the same disciplines SR 11-7 named, so its vocabulary remains the right scaffolding even though the letter is withdrawn.

Is an LLM a model under the new guidance? Generative AI is carved out of SR 26-2's definition, which targets quantitative methods producing quantitative estimates. Non-generative machine learning, such as a fraud classifier, remains in scope. The prudent reading, and the one the OCC's risk publications support, is that risk management should be commensurate with the risk regardless of the label.

How often must an LLM be revalidated? There is no fixed cycle. OCC Bulletin 2025-26 confirmed even community banks are not required to validate annually. Define event triggers instead: model version changes, material prompt or retrieval changes, measured degradation, and new use cases, with a periodic review as backstop.

What can I document about a vendor API model I cannot inspect? Document around it: the vendor's model card and disclosures, your own use-case validation on your data, output monitoring, human review effectiveness, and contractual rights to change notification and incident reporting. SR 26-2 keeps vendor products fully subject to model risk management expectations.

Does the EU AI Act apply to a bank's LLM systems? For high-risk uses such as creditworthiness assessment and life-insurance pricing, yes. Article 11 requires technical documentation before the system is put into service, kept up to date, containing at least the Annex IV elements. A well-built model risk pack maps onto Annex IV with limited extra work.

Who should own LLM model risk documentation? A named individual owner per system in the inventory, independent validation by staff who did not build the system, internal audit reviewing whether the framework itself works, and in the UK an accountable Senior Management Function holder under SS1/23.

Where to go from here

If your inventory has LLM-shaped gaps, start with the inventory records this week; everything else hangs off them. AI Agents Plus implements enterprise AI for banks and insurers, including private model deployment, evaluation suites, and the governance documentation described in this guide; our enterprise AI practice covers the full engagement, and our Claude for financial services work applies the same discipline to funds and advisors. If you want a second pair of eyes on an existing pack, talk to an engineer.