SR 26-2 and Machine Learning in CECL Allowance Models

What SR 26-2 establishes, and what it leaves to judgment

The Federal Reserve issued SR 26-2 on April 17, 2026, as a supervisory letter on revised guidance for model risk management. As of November 2026, the letter states that it is expected to be most relevant to banking organizations with over $30 billion in total assets regulated by the Federal Reserve. Institutions outside that group should decide and document how they treat the guidance.

The letter says the revised guidance highlights sound principles for effective model risk management while recognizing that practices appropriately vary among banking organizations based on their specific risk profiles and model usage. For risk leaders, this matters more than any single control. There is no prescribed checklist for an ML-based CECL model. Scope, depth of validation and evidence expectations are risk-based judgments that the institution must make and be able to defend in its own terms.

That proportionality applies to machine learning in the allowance process. A gradient-boosted loss model that drives reserve estimates warrants a different level of scrutiny than a tool that summarizes portfolio commentary. Both may touch CECL workflows, so the first governance decision is which components are models, which are supporting tools, and who owns each classification.

Where the obligation sits across the lifecycle

The table separates lifecycle areas that rely on pre-deployment work and documentation from the interaction-level evidence that runtime enforcement can add. It reflects general model risk practice and should be mapped by the institution to the full text of SR 26-2 and its own policies.

• Model definition and inventory: Institution-owned. Decide which ML components are in scope and record them. Runtime enforcement has no role in this decision.
• Development and documentation: Institution-owned. Design choices, data use rationale and limitations are documented by the model owner. Runtime records do not substitute.
• Validation and challenger analysis: Independent validation, outcomes analysis and explainability work happen before and around deployment. Runtime enforcement does not perform or replace them.
• Ongoing monitoring and drift: Owned by model owners and risk functions through performance review. Interaction records can show how often inputs or outputs were redacted or blocked, which is operational context, not drift analysis.
• Change control and use restrictions: Approval and release processes belong to the institution. Runtime policy can enforce a restriction, for example which tools a model may call, and record each decision.
• Third-party and pre-trained components: Due diligence and validation stay with the institution. Continuous monitoring of components in deployment can be supported by interaction-level enforcement and records.

What machine learning changes about the evidence problem

Interpretability, drift and third-party components are the three pressure points when ML enters a CECL allowance model. Each is primarily a validation and monitoring problem. Interpretability is addressed through model design and post-hoc explanation methods, validated before use. Drift is addressed through monitoring of inputs and outcomes against defined thresholds. Third-party or pre-trained components need risk tracking and clear criteria for when they exceed tolerance and should be retired.

NIST's AI RMF material frames this usefully, though it is not supervisory text. It separates testing, evaluation, verification and validation across a model, its subcomponents, deployment and operation. It also pairs explainable models and post-hoc explanations with audit logs. Treat the two as complementary: explanations show why a model behaved as it did, and interaction records show what it was permitted to do in operation.

The gap that appears with AI-enabled CECL workflows is at the point of execution. When a model, an agent or an assistant reads allowance inputs, produces outputs or calls a tool, validation documents describe intended behavior. They do not show what happened on a particular interaction. That is the narrow gap runtime evidence addresses.

What runtime policy enforcement can and cannot support

Trussed enforces policy in the execution path across models, agents, tools and MCP servers. For each individual interaction or tool call, it can allow, redact, block, rate limit or escalate for human approval, and enforcement at runtime produces audit-ready evidence of the decision. For a CECL workflow, a reviewer can see, for example, that a tool call touching a restricted data field was blocked, or that an output was redacted before it reached a downstream user.

That supports specific expectations: use restrictions can be enforced rather than only written down, and records of enforcement can sit alongside change control and monitoring files. Trussed can be self-managed in the customer's cloud, with configurable retention and data residency, so retention can follow the institution's own policy.

The boundaries need to be stated plainly. Trussed does not validate models, produce development documentation or maintain the model inventory. It does not provide model lineage, dataset provenance or end-to-end tracing of agentic workflows. Its evidence covers individual interactions and tool calls, and it does not satisfy SR 26-2 on its own. Validation, ownership and inventory remain with the institution.

Practical next steps and tradeoffs

Start with the full text of SR 26-2 and map each lifecycle area to an owner and an evidence type, as in the table above. Record the rationale for control scope, given the guidance's emphasis on risk profile and model usage. Confirm whether the institution falls within the guidance's stated asset focus, or how it otherwise applies it.

Then identify where AI systems actually touch CECL processes: data retrieval, scoring calls, narrative drafting, reviewer tooling. For each, decide which interactions need enforcement, which outcomes will be recorded and how long records are kept. Tighter enforcement reduces permitted behavior and may add review work through human approval steps. Broader permissions reduce friction but leave more to after-the-fact explanation. That tradeoff is a proportionality decision for the institution, and it should be documented.

Runtime evidence is useful only as one layer. It strengthens the interaction-level portion of an examiner file and leaves validation, documentation and inventory to the processes built for them.