TL;DR
- SR 26-2 loosened process rules and kept one requirement: the Fed’s April 2026 replacement for SR 11-7 dropped the fixed annual validation cadence and enforceable status, and kept the rule to name an individual accountable for each model.
- Ownership means a named person: SR 26-2 asks institutions to delineate the individual responsible for a model throughout its life, a role most banks still assign to a committee.
- Approval has to happen twice, at launch and at every material change: a documented sign-off with an audit trail, triggered by the size of the change to the model.
- Retirement is its own governance event: a decommissioned model needs a stated reason, notice to the teams it affects, and a retained record. SR 26-2 sets no fixed timeline for any of it.
- iTuring’s Model Gov module ties ownership, approval, and retirement to one audit trail, so the records an examiner asks for live in one governed system.
- What SR 26-2 leaves undecided: it requires a named owner and leaves the approval and retirement workflow design to the bank. That gap is where most institutions are still behind.
Most banks think they have model governance once a model risk policy exists and a monitoring dashboard tracks drift. Neither answers the three questions an examiner asks: who owns this model, who approved it and every change made to it, and what happens when it comes out of production. A bank without documented answers to those three questions does not have model governance, no matter how detailed its monitoring is.
SR 26-2, the Federal Reserve’s April 2026 replacement for SR 11-7, changed how much the guidance prescribes. It removed the fixed annual validation requirement and the treatment of SR 11-7 as a de facto enforceable standard. What it kept, and sharpened, is the requirement to name an individual accountable for a model across its life. That single requirement is now the clearest structural rule left in US model risk guidance. Most banks still assign it to a committee.
Three things model governance covers beyond monitoring
Model governance is the set of named roles, approval records, and retirement rules that make a bank accountable for every model in production. Model monitoring, tracking a model’s drift and performance day to day, is one input into that system. A bank can monitor every model closely and still have no governance if no one owns the sign-off.
A monitoring dashboard answers one narrow question. Is this model still performing the way it did at launch? That question matters, and iTuring covers it in a separate piece on AI governance monitoring. It does not answer who is accountable when the model drifts, who signed off on the version currently in production, or what the bank does when the model eventually comes out of service.
Those three questions define governance. Model governance itself sits inside the broader discipline of building an AI governance platform a bank can defend in an exam. A named owner who answers for the model. A documented approval trail that shows who signed off on the model and every material change since. A retirement plan that exists before the model needs one.
This piece covers ownership, approval, and retirement across a bank’s full model portfolio. Readers evaluating collections models specifically can go deeper with iTuring’s model governance guide for AI collections. This one covers what SR 26-2 changed in April 2026 and what every model in production now needs, regardless of use case.
Model ownership: who is accountable for a model across its life
Model ownership is a named individual who answers for a model’s performance, its documentation, and its risk from the day it enters production until the day it’s retired. SR 26-2 requires institutions to delineate that individual by name. A committee, a team, or a job function does not meet that requirement on its own.
Most banks already have a model risk committee. Fewer have a named person who owns each individual model on that committee’s inventory. SR 26-2 draws that distinction directly. It asks institutions to delineate the individual responsible for a model throughout its lifecycle. That individual is a named person, separate from the committee that oversees the portfolio.
Ownership means three things in practice:
- A single named individual attached to each model in the inventory, recorded by name in the model’s own record.
- A documented handoff when a model moves between teams, so accountability has no gap between one owner leaving and the next one being assigned.
- Ownership that survives a reorganization. The record of who owns each model gets updated the same week a department changes, before the next exam finds the gap.
The bank that skips this step usually ends up with a specific bad artifact, a model inventory spreadsheet with an owner column that says “Risk Team” for forty rows. That column has to say a name.
Approval: what has to happen before a model or a change to one ships
Approval is a documented sign-off, with an audit trail, before a model enters production and again whenever a change is significant enough to shift its risk profile. The sign-off names who approved it, what evidence they reviewed, and when. A model that skips this step has no governance record, however well it performs.
Two approvals matter, and banks tend to build a process for only one of them.
Initial approval happens before a model goes into production. It should require the same things SR 26-2 asks for on an ongoing basis: a named reviewer, a documented risk tier, and evidence the model performs as intended for its stated use.
Re-approval happens when a change to a live model crosses a materiality threshold the bank sets in advance, retraining on a new data source, a shift in the target population, or a meaningful change to the model’s features. Most banks have a process for the first approval. Few have a working process for the second. That gap is where governance breaks down in practice.
A maker-checker structure, where the person who makes a change is never the person who approves it, closes that gap without adding a new committee. The approval record itself becomes the evidence an examiner asks for, naming who reviewed the change, what they reviewed, and when the model went live with it.
Retirement: what a model needs when it comes out of production
Retirement is the documented process for taking a model out of production. It needs three things: a stated reason, notice to every team the model’s output reaches, and a retained record of the model’s full history. SR 26-2 sets no fixed retention period. That decision belongs to the bank’s own recordkeeping policy.
A model rarely gets retired all at once. It gets replaced by a newer version, its use case gets discontinued, or its drift crosses a threshold the bank decided it would not tolerate. Whatever the reason, it has to be written down. “We stopped using it” is not a governance record.
A retirement record should include:
- The stated reason the model was taken out of production.
- The date it stopped generating decisions in production.
- Notice to every downstream team whose process depended on its output.
- A retained copy of the model’s full approval and change history, including versions before its final configuration.
The retained history matters more than the model itself once it’s retired. An examiner asking about a decision made two years ago needs the record of who approved the model and why, even though the model itself no longer runs.
What changed when SR 11-7 was rescinded, and what stayed the same
On April 17, 2026, the Federal Reserve, the OCC, and the FDIC jointly rescinded SR 11-7 and replaced it with SR 26-2 and OCC Bulletin 2026-13. The new guidance drops enforceable status and the fixed annual validation cadence, and is aimed most directly at banks over $30 billion in assets. It does not drop the requirement to name who owns each model.
Four things changed, confirmed directly from the Federal Reserve’s own release. The guidance now states plainly that it “does not set forth enforceable standards or prescriptive requirements,” a real shift from SR 11-7, which supervisors treated as a de facto standard for fifteen years. The fixed annual validation requirement is gone. Each bank now sets its own validation schedule based on its own risk profile. The guidance is described as most relevant to banks with more than $30 billion in total assets, a threshold SR 11-7 never had, though the agencies are explicit that smaller institutions with significant model risk exposure are not exempt. Generative and agentic AI models are named and excluded from scope entirely, called “novel and rapidly evolving,” with separate guidance expected later and no date given as of this writing.
One thing did not move. SR 26-2 still asks institutions to delineate the individual responsible for a model throughout its lifecycle. That line is short compared to the rest of the old guidance, and it’s now the clearest structural requirement left standing. Everything else is left to the institution to design: how approval is structured, how re-approval is triggered, how retirement is documented.
A handful of vendor pages that define model governance for a banking audience describe approval as a general step without naming what triggers a re-approval or what a retirement record needs to contain. That’s a reasonable place to start a comparison. In a live demo, ask a vendor to show the actual record their platform produces when a model change crosses a materiality threshold, and ask what happens to that model’s history once it’s decommissioned. Those two questions separate a governance platform from a monitoring tool wearing a governance label.
iTuring’s Model Gov module keeps ownership, approval, and retirement inside one governed workflow, with a single audit trail across all three. Every model in the inventory carries a named owner. Every approval, initial or triggered by a material change, runs through a maker-checker structure with an immutable audit trail. Every retirement preserves its full history when the model comes out of production. The same mechanism behind a 116% improvement in collections recovery for a leading NBFC in India runs this workflow. Its audit trail generates automatically as the platform executes a model, ready before an examiner asks for it.
Ownership, approval, and retirement are the three records SR 26-2 leaves to the bank to design. iTuring’s Model Gov module builds all three into one governed workflow, with a named owner on every model, a maker-checker approval trail for every launch and every material change, and a full history preserved through retirement. For a closer look at how this extends to the individual AI models running inside that portfolio, see AI model governance in financial services.
Book a 15-minute discovery call to see the audit trail an examiner would pull.
Sources
- SR 26-2, Board of Governors of the Federal Reserve System, 17 April 2026. https://www.federalreserve.gov/supervisionreg/srletters/SR2602.htm
- iTuring.ai case study, “Improve Collections and Optimize Efforts.” https://ituring.ai/case-study/improve-collections-and-optimize-efforts/
