SR 11-7 is the Federal Reserve's guidance on model risk management, issued jointly with the OCC in 2011. It runs to twenty-six pages. It was written for statistical models: the kind a bank's credit team uses to score a loan, the kind a treasury team uses to price a derivative, the kind an ALM team uses to project net interest income. Deterministic inputs, deterministic outputs, a defined model owner, a defined validation cycle.
The Fed has never officially rewritten SR 11-7 for large language models. What it has done, in a series of interpretive letters through 2025 and 2026 and a working proposal circulated to the seven largest US bank holding companies, is state which parts of the 2011 guidance apply unchanged to LLMs, which parts need reinterpretation, and which parts need new controls the 2011 guidance never contemplated.
The letters have not been widely published. The proposal is not yet a rule. But it is being reviewed by the model risk committees of every US bank we have talked to, and it is shaping what an MRM sign-off on an LLM-assisted workflow actually looks like now.
Here is what has changed, what an MRM committee is being asked to defend, and where the platform layer under the LLM has to provide new evidence the 2011 guidance did not require.
The four things SR 11-7 asks for
The original guidance asks for four things. All four survive in the LLM context. All four need a new interpretation.
Sound model development. The 2011 assumption is that a model is developed by a team the bank employs, on data the bank controls, with methodology the bank can inspect. An LLM breaks all three assumptions. The bank did not develop the model. The training data is proprietary to the provider. The methodology is a set of published papers and a lot of undisclosed engineering. The interpretive question is: what is the "sound development" evidence for a model the bank did not develop?
Ongoing monitoring. The 2011 pattern is that a model is validated at deployment, then monitored quarterly against a defined set of performance benchmarks, and revalidated on a schedule. An LLM's behaviour changes with the prompt, the retrieval context, the temperature setting, the provider's own silent updates. What is "quarterly monitoring" of an artefact whose behaviour changes on the vendor's release schedule?
Outcomes analysis. The 2011 pattern is that model predictions can be compared against realised outcomes on a defined cohort. LLM outputs are often free-form text: a coverage analysis for a claim, a first draft of a compliance narrative, a categorisation of a customer complaint. The realised outcome is subjective. What is "outcomes analysis" for a first-draft coverage analysis reviewed by a human adjuster?
Model inventory and tiering. The 2011 pattern is that every model in production is registered in an MRM register with a tier that determines its validation cadence. When an LLM is called from a business application, the "model" for MRM purposes is not just the LLM. It is the specific combination of prompt, retrieval, validation logic, and output filtering that produced the specific decision. What counts as an inventoried artefact?
The proposal's answer to all four is the same in shape. The evidence has to be structural. It cannot depend on the bank being able to inspect the model. It has to depend on the bank being able to inspect the specific execution that produced the decision.
Where the platform layer has to help
The 2011 controls were mostly organisational. Model owner, validation team, register maintainer. The proposal's implied controls are mostly technical, and they sit at the platform layer, not in the model.
Every LLM endpoint is an inventoried artefact. The register does not track "GPT-5" or "Claude Opus" as models. It tracks specific endpoint configurations: banking-claims-triage.v3.4 running against anthropic.claude-opus-5.20260601 with a specific prompt template, a specific retrieval scope, and a specific output validator. Each endpoint has its own tier, its own validation package, its own inventory identifier, its own owner. When the prompt template changes, that is a new endpoint version and the register knows.
Every model call is logged with the full context that produced it. Not just the prompt and the response. The specific documents retrieved, the specific policy checks that passed, the specific version of the endpoint configuration, the user who invoked it, and the workflow record it was called on behalf of. This is the "seven-step trace" pattern applied to LLM calls. It is what makes the outcomes analysis question tractable. When an examiner asks "how did the coverage analysis produced by the LLM for claim 2026-CL-0042184 compare to the analysis produced by human adjusters on the reference cohort", the query runs against the trace store and the reference cohort store.
Every provider update is a version event. When Anthropic ships an update to claude-opus-5, the endpoints that route through it are automatically flagged for revalidation. The MRM register knows the version each endpoint is running against. When a version change happens, the register schedules the revalidation task and blocks new deployments of endpoints that have not cleared the check.
Every downstream deployment inherits the tier of its highest-tier component. A workflow that uses a tier-1 endpoint is a tier-1 workflow, even if the workflow itself is simple. The tier is the upper bound of the risk of any component in the chain. This forces the register to be honest about system-level risk rather than component-level risk.
What an MRM sign-off actually looks like now
At every US bank we work with, the MRM sign-off on an LLM-assisted workflow now contains four artefacts. Three of these are new; one of them is a reinterpretation of an old one.
The endpoint validation package. A structured document that describes the specific endpoint configuration, its intended use, the population it is validated for, the performance benchmarks it has met, the residual risks the validation identified, and the compensating controls the workflow applies. This is a rewrite of the old "model development documentation", scoped to an endpoint configuration rather than a model.
The trace evidence bundle. A sample of the seven-step traces the endpoint produced during validation, showing the specific retrievals, tool calls, policy validations, and human decisions that flowed through the endpoint on the validation cohort. The MRM committee reviews the traces to confirm the workflow does what the validation says it does.
The version-change register. A commitment from the endpoint owner to notify the MRM committee within a specific window (usually five business days) of any change to the endpoint configuration or the underlying provider version, with the trigger that would cause the endpoint to require revalidation. The register is queried at every quarterly cycle.
The compensating controls narrative. A description of the human-in-the-loop gates, the output validation, the appeal path for customers, and the escalation path for adjusters who disagree with the model. This is the load-bearing artefact. The MRM committee's judgment about the risk of an LLM-assisted workflow is mostly a judgment about the strength of the compensating controls, because the model itself cannot be validated the way a statistical model can.
What AI Guardrails ships against this
AI Guardrails is the runtime trust layer that sits between the LLM and the outside world. Its job is to produce the four artefacts above as a first-class output of the workflow, not as a documentation exercise the ops team fills in later.
Structured policy artefacts, versioned and diffable, so the compensating controls narrative can be written directly from the policy source rather than reconstructed.
Prompt inspection, retrieval sanitisation, and RBAC-gated tool calls, all logged at the trace level, so the seven-step trace store is populated by construction.
Per-endpoint version tracking, so the version-change register is a query against the platform rather than an email chain.
Compliance-exportable audit trail, so the MRM committee's evidence bundle is a query against the compliance store rather than a data-science project.
AI Gateway underneath handles the endpoint inventory, the tiered routing, and the finance-grade cost attribution the model risk committee's chief of staff also asks about at every quarterly meeting.
What this changes for the bank
The MRM committee's meeting used to be about approving models. It is now about approving endpoint configurations and the compensating controls around them. The unit of governance has changed. The endpoint is not the model. The endpoint is the specific configuration that produced the specific decision, and the register has to track it that way.
The banks that treat this as a documentation exercise (a Word template the LLM team fills in and the MRM committee signs) will not survive the first supervisory examination that asks for the trace evidence. The banks that treat it as an architecture problem (the platform under the LLM produces the trace as a by-product of the execution) will pass the examination with a query.
If your bank is in the middle of that transition, tell us the specific workflow the MRM committee is asking about next. We will run an architecture review on what the endpoint validation package would look like for that workflow, in an actual document your model risk officer and your head of AI can read together.