SR 26-2 Vendor LLM Scoring Model Requirements: What Applies and What Banks Still Own

What changed with SR 26-2 and what it says about generative AI

The Federal Reserve published SR 26-2, Revised Guidance on Model Risk Management, on April 17, 2026. The OCC announced updated model risk management guidance the same day and stated that it rescinds its prior model risk management guidance and issuances. Teams that built vendor model programs around SR 11-7-era language should re-read the revised text rather than assume continuity.

Several features of SR 26-2 shape how a bank should treat a vendor LLM. The guidance is not enforceable and sets no prescriptive requirements, and it states that non-compliance will not result in supervisory criticism. The letter says it is expected to be most relevant to Federal Reserve-regulated banking organizations with over $30 billion in total assets, and it emphasizes a risk-based approach tailored to model risk profile, size and complexity.

The definition of a model is also narrower than many programs assume. A model is a complex quantitative method, system or approach that applies statistical, economic or financial theories to process input data into quantitative estimates. Simple arithmetic calculations and deterministic rule-based processes are excluded.

Most important here, footnote 3 states that generative AI and agentic AI models are novel and rapidly evolving, and that the principles apply to traditional statistical and quantitative models and non-generative, non-agentic AI models. A public commenter reads the footnote as placing generative and agentic models outside the guidance. A bank should therefore not describe SR 26-2 as the source of a requirement for an embedded LLM. It should document its own scoping position for each hybrid vendor model.

Where vendor responsibility actually comes from

The May 2024 interagency third-party risk management guidance is the firmer anchor. It states that engaging a third party does not diminish or remove a bank's responsibility to operate safely and soundly and to comply with applicable legal and regulatory requirements, including consumer protection laws, as if the bank performed the activity itself. It also says a bank cannot abrogate responsibility for effective risk management when it uses a third party to conduct third-party risk management for it.

SR 26-2 points the same way. It includes a section titled Vendor and Other Third-Party Products, and the OCC release says the guidance discusses considerations specific to those products, including their validation. Each banking organization remains ultimately responsible for adopting model risk management practices that are appropriate and effective for the risks it faces.

Two further points matter for governance. Internal audit would generally not duplicate model development or validation. Its role is to evaluate whether model risk management practices are rigorous and effective and implemented according to policy. Where external resources help manage model risk, sound practice is to keep proper oversight and integrate that work into the broader program.

Consumer protection duties also apply regardless of model risk guidance scope. Where a scoring output feeds a credit decision, commenters have pointed to Regulation B duties to state specific reasons and to retain evaluation records, and to the fact that these can continue after a vendor relationship ends. Compliance and model risk teams need a shared view of what the vendor component does.

Bank-retained obligations and vendor-supplied information

The split below is a working design for a bank's own policy, not a list taken from SR 26-2. The principle is that a vendor can supply information, but it cannot take over accountability for the bank's use of the model.

• Scoping position: Bank retains. Document which parts of a hybrid model are treated under SR 26-2 principles and which fall under third-party risk management and the bank's own AI practices.
• Disclosure of the LLM component: Vendor supplies, bank requests in writing: whether an LLM is embedded, what it does (feature extraction, text interpretation, explanation generation) and how updates are communicated.
• Validation evidence: Shared. The vendor provides documentation and validation summaries. The bank decides whether that is sufficient for its use and tests outcomes where it can.
• Change control: Bank retains the triggers and materiality thresholds. The vendor supplies change notices and version information.
• Production records: Bank retains. Policy decisions, human approvals and outcome records on interactions the bank controls belong in bank-controlled systems.
• Reasons given to applicants: Bank retains. Explanations generated by a vendor LLM remain the bank's responsibility under consumer protection law.

Change control when the vendor updates the model

A vendor can change an LLM component without the bank changing any input, prompt or decision process. One commenter cites research suggesting that provider-driven AI model updates can substantially alter financial risk assessments in this way, and notes that banks using the same upstream model version may share exposure to a common change. Treat these as commenter claims, but the design implication is sound: change control cannot depend on the bank's own release process alone.

A workable approach starts with contractual and operational triggers for vendor model or version changes. Where feasible, the bank compares the existing and replacement versions on identical inputs, applies institution-defined materiality thresholds, and escalates significant differences before deployment. Where the LLM generates explanations or reason statements for credit decisions, the bank should check applicant-facing statements against updated output. A statement that an applicant failed to achieve a qualifying score is cited by commenters as insufficient under Regulation B.

The NIST AI RMF Playbook adds a related point: organizations may adopt policies and procedures that include redundancies covering third-party functions, to mitigate third-party system failures.

Where runtime policy enforcement fits

Runtime enforcement addresses one narrow layer: the inputs, outputs and tool calls the bank can observe and control. On those interactions, a bank can enforce policy in the execution path, so that each interaction is allowed, redacted, blocked or escalated for human approval, and can keep a record of each decision. That is enforced at runtime, not reviewed after the fact, and it produces evidence the bank owns rather than evidence it must request.

Trussed provides this kind of enforcement in the execution path across models, agents, tools and MCP servers, scoped to individual interactions and tool calls, and generates audit-ready evidence from that enforcement. Its evidence is mapped to frameworks including NIST. It can be deployed self-managed in the customer cloud, with configurable retention and data residency, which bears on keeping records in bank-controlled systems. Trussed has run continuously in production in a regulated enterprise for more than 18 months, with insurance as its deepest regulated financial sector.

The limits are as important as the capability. Enforcement does not show how a vendor-internal component works, and where the vendor processes data inside its own environment the bank has no interaction-level visibility. Vendor documentation and contractual rights remain the main information source there. Enforcement does not replace independent validation or vendor due diligence. It supplies the production-behavior half of the picture, alongside them.