SR 26-2 and AI-Generated Code: What Banks Must Decide for Themselves

What SR 26-2 says, and what changed

SR 26-2, titled Revised Guidance on Model Risk Management, was issued on April 17, 2026. The OCC issued updated guidance the same day and stated that it rescinds prior model risk management guidance and other issuances. The guidance says practices should vary with a bank's risk profile and model usage, and be tailored and commensurate with size, complexity and the extent of model use. The SR letter states it is expected to be most relevant to banking organizations with over $30 billion in total assets regulated by the Federal Reserve.

On May 1, 2026, Governor Bowman said the Fed, together with the OCC and FDIC, recently amended the guidance to clarify that it does not apply to generative or agentic AI. She said supervisors had expanded the scope of the previous guidance beyond its original purpose, and that the agencies expect other risk-management and governance practices to support adoption of these technologies.

The practical consequence is that a brief built on the idea that SR 26-2 prescribes controls for AI-written code starts from the wrong premise. The guidance does not specify coding-assistant controls. It does say that a bank's own risk management and governance practices should guide the controls for tools, processes or systems it does not cover. Policy ownership, risk tiering and evidence standards for AI coding assistants sit with the institution.

What still applies to the models being built

The exclusion concerns generative and agentic AI. It does not remove the models your developers and quants are building. Feature engineering, estimation logic and validation scripts feed models that remain within the development, documentation and validation expectations of SR 26-2, whoever or whatever typed the code.

Several provisions bear directly on that work. An effective development process generally begins with a clear statement of purpose, so development stays aligned with intended use. All parts of the model lifecycle benefit from governance supported by clear policies and effective controls. Effective challenge, meaning critical analysis by objective experts who evaluate model risk and drive appropriate changes, runs from development through ongoing monitoring. The guidance also ties validation quality to the rigor and effectiveness of the review rather than to organizational structure.

A workable position, and it is a reading rather than guidance text, is to keep the model in scope of SR 26-2, treat the coding assistant as a tool governed by the bank's own practices, and record separately which code was AI-assisted. That record gives validators and reviewers something concrete to challenge, and it avoids asking the model risk program to certify controls it did not design.

Code provenance for documentation and validation

Code provenance, for this purpose, means three things recorded about a piece of code: its origin (human-authored, or AI-generated or modified, and by which assistant), its licence context, and its security context. SR 26-2 does not define these fields, so the institution decides what to capture and how it appears in model documentation.

The value is in independent validation. A validator reviewing estimation logic can see which parts were AI-assisted and apply proportionate scrutiny, and a change-control record can show who approved an AI-proposed change. Without that attribution, a bank can say little to an examiner beyond a general statement that developers use assistants.

Keep this separate from model lineage and dataset provenance. Code provenance says nothing about training data or how a model was derived, and it should not be described as if it did. It answers one narrower question: where did this code come from, and under what conditions was it accepted.

What runtime enforcement closes and what stays with the program

Runtime enforcement produces evidence about assistant actions. It does not classify models, reach validation conclusions or accept risk. Trussed enforces policy in the execution path of coding assistants, with allow, redact, block, rate limit and escalate-for-human-approval decisions on individual interactions and tool calls. It ships code provenance covering origin, licence and security context, and generates audit-ready evidence from enforcement. It can be deployed self-managed in the customer cloud, with configurable retention and data residency. Trussed does not provide model provenance, model lineage or dataset provenance. Its production track record is in regulated enterprises, with insurance the regulated financial sector where it is deepest.

The split below is a way to assign ownership.

• What the assistant can read or send: Runtime enforcement: redact or block context at the point of use. Program: define what counts as sensitive and approve the policy.
• Which code is AI-generated: Runtime enforcement: attach origin, licence and security context as code is produced. Program: decide how attribution appears in model documentation.
• Approval of consequential changes: Runtime enforcement: hold the action and capture the approver. Program: define which changes are consequential and who may approve.
• Validation conclusions: Runtime enforcement: supply evidence to validators. Program: perform effective challenge and own the conclusions.
• Assistant classification and risk acceptance: Runtime enforcement: none. Program: decide how the assistant is classified, tiered and approved, and communicate with examiners.