SR 26-2 Explained: 2026 Model Risk Management Updates for AI

Your model inventory probably has gaps you haven't had to defend yet. SR 26-2 changes that. The 2026 update narrows the definition of what counts as a model, tightens the exclusion standard, and extends full validation obligations to third-party and AI-based systems that most teams have never formally reviewed. What follows is a breakdown of where the new guidance diverges from SR 11-7 and what your team needs to have in place before examiners ask.

TLDR:

• SR 26-2, issued April 17, 2026 by the Fed, OCC, and FDIC, extends SR 11-7 to cover AI/ML systems, LLMs, and agentic architectures.
• Vendor-sourced models now carry the same validation and monitoring obligations as internally built ones; attestations from vendors do not satisfy the requirement.
• Materiality-based tiering requires documented justification at every tier boundary, and monitoring dashboards alone no longer satisfy the governance standard.
• Agentic systems require governance controls at the action level, with audit trails granular enough to reconstruct every tool call and decision sequence.
• Openlayer maps pre-deployment evaluation results, drift thresholds, and deployment events to a structured audit trail examiners can inspect, with deployment gates that block promotion when criteria are not met.

What SR 26-2 is and why it was issued

SR 26-2 is the interagency model risk guidance issued jointly by the Federal Reserve, OCC, and FDIC on April 17, 2026. It replaces SR 11-7, which governed model risk management at U.S. banks since 2011. The OCC's accompanying bulletin describes the stated rationale: more than a decade of supervisory experience, accumulated industry feedback, and major advances in modeling practices across that period.

The guidance applies primarily to institutions with $30 billion or more in total assets, though smaller institutions carrying complex model portfolios will find it directly relevant.

SR 26-2 vs. SR 11-7: the core differences

SR 11-7, issued in 2011, set the original framework for model risk management at financial institutions. SR 26-2 does not replace it entirely. The two documents coexist, with SR 26-2 extending the prior guidance to cover AI-specific risks that SR 11-7 was never designed to handle.

Here is where the two diverge in ways that matter for implementation teams.

What SR 11-7 covers

SR 11-7 was built around traditional quantitative models: credit scoring, stress testing, pricing engines, and similar statistical tools with well-defined inputs, outputs, and validation protocols. Its core framework rests on three pillars: development and implementation, model validation, and governance and controls. That structure still applies under SR 26-2 for conventional models.

What SR 26-2 adds

SR 26-2 extends the framework across four areas SR 11-7 left largely unaddressed, each touching the core of what AI governance requires in modern institutions:

• Broader model definition: SR 26-2 captures AI systems that produce outputs through learned patterns instead of explicitly programmed logic. A model no longer needs a formulaic structure to fall under supervisory oversight. Generative systems, LLMs, and classification models trained on unstructured data all qualify.
• Explainability requirements: SR 11-7 assumed models could be interrogated through their mathematical structure. SR 26-2 requires institutions to document how AI outputs are explained to decision-makers and affected parties, even when the underlying mechanism resists direct interpretation.
• Data governance: SR 26-2 places substantially more weight on training data provenance, representativeness, and ongoing monitoring for data drift as a distinct risk category, not a subset of model development.
• Third-party and vendor model accountability: institutions cannot transfer risk to a vendor by sourcing an AI model instead of building one. SR 26-2 makes clear that oversight obligations follow the use case, not the origin of the model.

SR 11-7 remains the backbone of the framework. SR 26-2 adds the load-bearing elements that SR 11-7 cannot carry for AI systems operating at scale.

The narrowed definition of "model"

SR 26-2 draws a sharper boundary around what counts as a "model" than many teams expect. The original SR 11-7 guidance defined models broadly enough that firms developed inconsistent inventories, sometimes excluding tools that genuinely warranted oversight. The 2026 revision tightens that definition with two specific criteria: a model must use quantitative methods to produce outputs, and those outputs must be used to inform business decisions in a material way.

In practice, several categories of tools that previously sat in a gray zone now fall clearly inside the model risk perimeter:

• Vendor-supplied scoring engines where the underlying methodology is opaque, even if the firm did not build them internally
• Third-party AI tools integrated into credit, fraud, or underwriting workflows without formal validation
• LLM-based systems that produce recommendations, summaries, or classifications used by decision-makers downstream

The narrowed definition has a second consequence that teams often miss: exclusions are harder to defend. Teams reviewing their AI model governance frameworks will need to account for this shift explicitly. Under SR 26-2, claiming a tool is "not a model" requires documented evidence that its outputs do not materially influence decisions, and a bare assertion will not hold. That documentation burden now sits with the model owner, and examiners will ask for it.

Materiality-based tiering and risk-based validation

SR 26-2 reframes model risk validation around a concept that earlier guidance left underspecified: not all models carry equal risk, and validation effort should scale accordingly. The revised guidance formalizes this through materiality-based tiering, where institutions classify models by the potential impact of their failures before determining how rigorously to validate them.

The tiering logic has three practical implications worth spelling out.

• Models with high materiality ratings require full independent validation cycles, including conceptual soundness review, outcome analysis, and ongoing performance monitoring against defined thresholds. A credit scoring model used across millions of consumer decisions sits in this tier regardless of how well-understood the underlying methodology is.
• Models with lower materiality ratings may qualify for reduced validation scope, but the guidance is explicit that reduced scope requires documented justification tied to the risk assessment, and an informal judgment call by the model owner will not suffice.
• AI and LLM-based models frequently resist clean materiality classification because their outputs are probabilistic, their behavior changes with input distribution changes, and their failure modes are less predictable than those of traditional statistical models. SR 26-2 accounts for this by requiring institutions to treat model complexity as an input to the materiality determination itself.

The risk-based validation framework that follows from tiering, which parallels the NIST AI RMF approach to categorizing and treating model risk, is where many AI teams will feel the execution pressure most acutely. SR 26-2 calls for validation activities that match the model's risk profile at every stage of its lifecycle, from initial development through ongoing monitoring. For AI systems, that means pre-deployment evaluation results, drift monitoring records, and behavioral test logs all need to feed into a documented validation trail that auditors can inspect.

Teams that have treated monitoring dashboards as sufficient will find that SR 26-2 expects more: the distinction between observing model behavior and enforcing performance thresholds is now a governance requirement, not a design preference.

Effective challenge redefined

SR 26-2 revised guidance on model risk management redefines what counts as effective challenge in ways that catch most AI teams off guard. The original SR 11-7 framed effective challenge as an independent review function, typically a second line of defense team reviewing model assumptions and outputs. Under SR 26-2, that framing expands considerably.

Effective challenge now requires that reviewers can interrogate how a model produces outputs, and whether outputs fall within acceptable ranges is no longer enough on its own. For statistical models, this was manageable. For AI systems, particularly those built on complex architectures, the interrogation requirement creates a genuine technical burden.

There are three specific areas where SR 26-2 raises the bar:

• Explainability at the decision level: reviewers must be able to trace individual predictions or recommendations back to contributing inputs and model behavior, going beyond aggregate performance metrics across a validation dataset.
• Challenger model requirements: where feasible, institutions are expected to maintain or develop challenger models that test whether a simpler or alternative approach would produce materially different outcomes, placing the onus on model owners to document the basis for architectural complexity.
• Documentation of assumptions and limitations: effective challenge now requires that known failure modes, out-of-distribution behaviors, and edge case performance are explicitly documented, a core obligation of any responsible AI framework, and available to reviewers before deployment approval, not surfaced after the fact.

Vendor and third-party model governance

SR 26-2 extended model risk management obligations beyond internally developed models to cover any model used in decision-making, regardless of origin. That scope matters because most financial institutions today run on a mix of vendor-supplied models, third-party scored data, and purchased analytics packages alongside their own builds.

The 2026 update sharpens this. Institutions can no longer treat vendor attestations as a substitute for independent validation, a point reinforced across AI governance best practices for enterprise leaders. If a third-party credit scoring model informs lending decisions, the institution owns the validation responsibility, the monitoring obligation, and the documentation burden, even when the vendor's methodology is opaque or proprietary.

There are a few places where this creates real friction for AI teams:

• Vendor black-box constraints often prevent full access to training data, feature engineering logic, or model internals. SR 26-2 does not waive the validation requirement because access is restricted; it requires institutions to document the limitation, assess its implications for model risk, and compensate with alternative validation approaches such as outcome analysis, benchmarking, or challenger models.
• Third-party LLM API integrations connected by product teams without formal risk review now fall squarely within scope. A generative model producing customer-facing summaries or credit explanations is a model for SR 26-2 purposes, whether it was built in-house or called from an external API.
• Off-the-shelf tools processing regulated data without documented validation status represent an inventory gap that examiners will look for. If the institution cannot produce a validation record, the model is treated as unvalidated, not as outside scope.

The practical implication: every model in production, regardless of source, needs a registry entry with ownership assigned, validation status recorded, and ongoing monitoring in place.

The GenAI and agentic AI carveout

SR 26-2 extends its scope beyond traditional statistical models to cover generative AI and agentic systems, though the guidance treats these as a distinct risk category, not a direct extension of the legacy model risk framework.

For generative AI, the revised guidance calls out several properties that sit outside what SR 11-7 was designed to handle: outputs that are probabilistic and open-ended instead of bounded, training data that may be proprietary or opaque, and emergent behaviors that are difficult to anticipate through conventional pre-deployment testing. LLMs used for customer-facing applications, internal knowledge retrieval, or decision support all fall within scope when they materially influence business outcomes or consequential decisions.

Agentic systems introduce a further layer of complexity. Where a single model produces an output a human reviews, an agent executes sequences of actions, calls external tools, writes to systems of record, and may spawn sub-agents, often without a human checkpoint between steps. SR 26-2 signals that these architectures require governance controls at the action level, extending well past the output level. That means logging tool calls, maintaining decision chain records, and building review gates into the execution path itself.

There are two practical consequences for AI teams working in this space:

• Evaluation must cover behavior across multi-step sequences, going beyond single-turn outputs. A model that performs well in isolation may behave unpredictably when embedded in an agentic pipeline where earlier tool calls alter the context it receives.
• Audit trails must be granular enough to reconstruct what the agent did, in what order, and on what inputs, the standard covered in depth in an AI model audit context. A log that captures only final outputs does not satisfy the record-keeping intent of the guidance.

The carveout does not exempt these systems from model risk management; it acknowledges that the methods required to manage them differ from those applied to regression models and scoring engines, and signals that examiners will be looking for evidence that institutions have adapted their frameworks accordingly.

What the carveout means for AI teams in practice

The carveout in SR 26-2 removes the blanket exemption that many AI teams had quietly relied on. Under the prior guidance, vendor-supplied models often passed through with minimal internal scrutiny if they were widely used or commercially available. The revised framework closes that gap: if a model informs a material business decision, the institution owns the validation obligation regardless of where the model originated.

For AI teams, this plays out across three areas:

• Vendor model inventories need to be audited against the materiality threshold. A credit scoring model licensed from a third-party vendor and used to approve or deny applications falls inside SR 26-2's scope. The fact that the vendor built and trained it does not transfer the validation burden.
• Documentation requirements now extend to models that were never formally registered as "models" internally. LLM-based summarization tools feeding underwriting workflows, for example, qualify if their outputs shape a consequential decision.
• Ongoing model monitoring obligations apply at the same standard as internally developed models. Periodic performance review, drift detection, and threshold-based alerting are not optional for vendor models that cross the materiality line.

The practical implication is that AI teams can no longer treat the vendor relationship as a compliance proxy. Contractual representations from a model vendor do not satisfy an institution's internal validation requirements under SR 26-2. The audit trail, the performance benchmarks, and the monitoring records all need to exist inside the institution's own governance infrastructure.

What did not change under SR 26-2

SR 26-2 is a calibration, not a reset. The three validation pillars that SR 11-7 put in place remain intact and still carry the same weight with examiners.

• Conceptual soundness: model design, underlying assumptions, and data selection must still be defensible on their own terms, independent of whether outputs look reasonable in backtesting.
• Outcomes analysis: back-testing and prediction-versus-actual comparisons are still required wherever historical data allows. SR 26-2 does not relax this because AI models are harder to interrogate.
• Ongoing monitoring: continuous performance assessment as conditions change was a SR 11-7 requirement and stays one. The monitoring cadence expectations for traditional models have not softened.

Effective challenge as the governing principle of the MRM framework also carries forward unchanged. The expectation that independent reviewers can genuinely interrogate model assumptions, not simply sign off on outputs, was always the standard.

"The Board expects a financial institution's board of directors and senior management to build a culture that promotes sound model risk management practices and effective challenge of models."

Internal audit's role is similarly preserved: auditors assess whether the MRM program itself is rigorous, not whether individual model validations were correct. That boundary between audit oversight and model validation work remains where it has always been.

For the largest banks with mature MRM programs, most of the examination experience will feel familiar. The discipline expected under SR 11-7 is still expected. What SR 26-2 adds sits on top of that foundation, not in place of it.

Building an SR 26-2 ready MRM program

Four moves translate SR 26-2 from principle to examination readiness:

• Re-baseline the model inventory against the narrowed definition. Remove simple arithmetic tools, reclassify borderline systems, and document the exclusion rationale for anything left out. Examiners will ask why a tool was excluded, and the list of included tools tells only half the story.
• Build a materiality tiering matrix that maps inherent risk, exposure, and intended use to governance intensity. The matrix needs written justification at each tier boundary; internal consensus alone will not hold up under examination.
• Stand up a parallel governance track for GenAI and agentic systems, sized to your institution's risk profile. Waiting for more prescriptive guidance is not a defensible posture when those systems are already in production.
• Package examiner-ready evidence: validation outcomes bound to deployed model versions, monitoring cadence records, and a documented proportionality rationale for every tier assignment.

Institutions with mature MRM programs face recalibration more than reinvention. The inventory exists, validation workflows are in place, and the conceptual soundness expectation is familiar. The work is extending those controls to systems SR 11-7 never reached. Institutions with ad hoc workflows face something structurally harder: the inventory has to exist before tiering applies, and tiering has to exist before proportionality can be argued to an examiner. Selecting the right AI governance tools is a prerequisite for building that infrastructure.

How Openlayer supports SR 26-2 and AI governance obligations

SR 26-2 reframes model risk management around documentation, monitoring, and governance controls that most AI teams have not yet built into their workflows. Governance-layer platforms such as Credo AI and IBM watsonx.governance handle the policy documentation and risk taxonomy side of that obligation: defining risk tiers, capturing attestations, and maintaining model inventories. Where they stop is at runtime: neither platform monitors live model outputs, enforces behavioral thresholds, or blocks a model from deploying when validation criteria are not met. Openlayer covers each of those obligations directly, connecting evaluation results and runtime monitoring data to the evidence trail examiners expect to see, and enforcing deployment gates when criteria are not satisfied.

There are four areas where Openlayer's capabilities map to SR 26-2 requirements.

• Continuous monitoring and drift detection: SR 26-2 requires ongoing performance tracking after deployment. Openlayer monitors production model behavior in real time, tracking output quality, input distribution changes, and performance degradation against thresholds you set. When drift crosses a defined limit, alerts fire before the model has been operating outside its validated range for an extended period.
• Automated evaluation against pre-deployment criteria: The guidance expects models to pass documented validation standards before going live. Openlayer runs over 175 pre-built tests covering accuracy, fairness, and behavioral consistency, and writes pass/fail records, metric scores, and flagged failure modes directly to an audit trail that examiners can inspect.
• Governance documentation and audit-ready evidence: SR 26-2 expects banks to maintain records that reconstruct model behavior after the fact. Openlayer captures model version hashes, evaluation results, monitoring thresholds, and deployment events in a structured record linked to each production system, not scattered across team wikis and spreadsheets.
• Fairness and bias testing for high-risk models: Credit, underwriting, and collections models face the sharpest scrutiny under SR 26-2 and concurrent fair lending obligations. Openlayer runs AI fairness metrics checks including demographic parity and adverse impact analysis as part of the validation pipeline, producing the documented fairness evidence a compliance review requires.

The distinction worth holding onto: logging and alerting are observation. Openlayer's deployment gates block promotion when evaluation criteria are not met, which is enforcement. That blocking step is what separates a governance control from a governance record, and it sits at the core of Openlayer's unified evaluation, observability, and governance platform.

Final thoughts on SR 26-2 revised guidance and what it means for AI teams

SR 26-2 does not ask you to start over. It asks you to extend what you already built into territory SR 11-7 never reached: vendor models, LLM-based workflows, and agentic systems that have been running in production without the governance controls now expected. The inventory, the tiering matrix, and the documented audit trail are not optional additions; they are what examiners will ask for first.

Connect with us to see how Openlayer maps directly to those SR 26-2 documentation and monitoring obligations.

FAQ

What does SR 26-2 revised guidance on model risk management require that SR 11-7 did not?

SR 26-2 extends SR 11-7's three-pillar framework (conceptual soundness, outcomes analysis, and ongoing monitoring) to cover AI-specific obligations SR 11-7 was never built to handle. The four additions are explicit explainability requirements for AI outputs, lifecycle-wide data governance beyond the development phase only, full validation accountability for vendor and third-party models, and continuous monitoring with defined thresholds for generative and agentic systems. SR 11-7 remains the backbone; SR 26-2 adds the load-bearing elements SR 11-7 cannot carry for AI at scale.

What counts as a "model" under SR 26-2, and how do I know if a tool my team uses qualifies?

A tool qualifies as a model under SR 26-2 if it uses quantitative methods to produce outputs that materially influence business decisions, and the burden of proving exclusion sits with the model owner, not the examiner. In practice, this pulls in vendor-supplied scoring engines with opaque methodologies, third-party LLM APIs connected by product teams without formal risk review, and LLM-based summarization or classification tools feeding underwriting or credit workflows. If you cannot produce documented evidence that a tool's outputs do not materially influence decisions, examiners will treat it as in-scope.

How should I handle SR 26-2 model risk obligations for vendor-supplied AI models where the methodology is opaque or proprietary?

Vendor black-box constraints do not waive the validation requirement. SR 26-2 requires institutions to document the access limitation, assess its implications for model risk, and compensate with alternative validation approaches such as outcome analysis, benchmarking, or challenger models. Contractual representations from the vendor do not satisfy the institution's internal validation obligations; the audit trail, performance benchmarks, and monitoring records must exist inside the institution's own governance infrastructure. Every vendor model crossing the materiality threshold needs a registry entry with named ownership, recorded validation status, and ongoing monitoring in place.

Can I use Openlayer to generate the audit-ready evidence SR 26-2 examiners will ask for?

Yes. Openlayer writes pass/fail records, metric scores, flagged failure modes, model version hashes, monitoring thresholds, and deployment events to a structured audit trail linked to each production system, produced as a byproduct of normal evaluation and monitoring workflows, not assembled after the fact. For credit, underwriting, and collections models facing fair lending scrutiny alongside SR 26-2, Openlayer runs demographic parity checks and adverse impact analysis as part of the validation pipeline, generating the documented fairness evidence a compliance review requires. One distinction worth holding: logging and alerting are observation; Openlayer's deployment gates block promotion when evaluation criteria are not met, which is enforcement, and that blocking step is what separates a governance control from a governance record.

What governance controls does SR 26-2 expect for agentic AI systems, and how do those differ from traditional model validation?

SR 26-2 signals that agentic systems require governance at the action level, beyond the output level, because agents execute sequences of tool calls, write to systems of record, and may spawn sub-agents without a human checkpoint between steps. Traditional model validation assesses a bounded output a human reviews; agentic validation must cover behavior across multi-step sequences, maintain audit trails granular enough to reconstruct what the agent did and in what order, and build review gates into the execution path itself. A log capturing only final outputs does not satisfy the record-keeping intent of the guidance; the audit trail must link each tool invocation to the agent ID, the inputs received, and the authorization state at the moment of action.