The thesis: the AI rule has not arrived, but its shape already has.
On April 17, 2026 the Federal Reserve, the Office of the Comptroller of the Currency, and the FDIC issued SR 26-2, the first full rewrite of federal model risk management guidance since SR 11-7 in 2011. It replaces a prescriptive validation checklist with a materiality test built from two factors, a model’s purpose and its exposure, and lets institutions size their oversight to match.
One footnote in the guidance carries most of the story for finance teams outside banking. Generative and agentic AI models, the agencies wrote, are novel and rapidly evolving, and are not within the scope of this document. A separate request for information on AI use is still to come. Waiting for it costs a team its lead time. The materiality method SR 26-2 already spells out is the clearest public template available today for organizing an inventory of AI-driven finance tools before a formal rule arrives asking for one.
What actually changed, and what did not.
SR 11-7 set the model risk management baseline for fifteen years: a broad definition of “model,” an expectation of comprehensive validation, and roughly annual review cycles applied fairly uniformly across an institution’s model population. SR 26-2 keeps the core disciplines, development, validation, monitoring, and governance, but ties the intensity of each to a materiality score rather than a fixed schedule.
Materiality itself is defined precisely. Model purpose is a qualitative factor: models built to meet regulatory requirements or manage financial risk exposures rank higher. Model exposure is quantitative, generally sized by the portfolio or business impact a model touches. Together they set the tier, and the tier sets how much oversight a given model receives. A model of low materiality may need nothing more than identification and performance monitoring. A model of high materiality still gets the full weight of conceptual soundness review, testing, and effective challenge.
The guidance also narrows what counts as a model in the first place. The term now excludes simple arithmetic calculations, including spreadsheet formulas, and deterministic rule-based processes with no statistical, economic, or financial theory underneath them. That line matters for finance teams: a fixed approval-routing rule is not a model under this definition, but a forecasting tool, a scoring engine, or an anomaly detector built on statistical or AI methods is exactly the kind of thing the guidance is written for, even outside a bank’s own model population.
SR 11-7 versus SR 26-2.
| Dimension | Under SR 11-7 and SR 21-8 | Under SR 26-2, issued April 2026 |
|---|---|---|
| Who the guidance targets | Every banking organization, regardless of size, expected to run a full validation program | Most relevant to banking organizations with over $30 billion in total assets, tailored to risk profile |
| What counts as a model | Broad and largely undefined, leaving spreadsheets and rule-based tools in a gray zone | A complex quantitative method applying statistical, economic, or financial theory, explicitly excluding simple arithmetic and deterministic rule-based logic |
| How rigor is set | A single validation standard applied across the model population | Materiality, driven by model purpose and model exposure, sets the depth of governance a given model receives |
| Validation cadence | An expected annual review baseline | No fixed timing requirement; cadence follows the model's materiality and how it is used |
| Generative and agentic AI models | Not addressed; the concept did not exist in 2011 or 2021 | Explicitly out of scope for now, with a stated plan for a future request for information focused on AI |
Building the AI-ready model inventory.
A finance team does not need to wait for the agencies’ request for information to start this work, and waiting has a real cost: the moment formal AI guidance lands, an inventory built from scratch under deadline looks very different from one that already has owners, materiality scores, and validation evidence attached. Seven fields carry most of the value.
Model identity and purpose
A short name, the business function it serves, such as cash forecasting, invoice-matching anomaly detection, or credit scoring, and the statement of intended use it was built for.
Model type
Traditional statistical or quantitative, versus generative or agentic AI, tracked as a distinct field so the two populations can be reported separately once formal AI guidance arrives.
Materiality inputs
Model purpose, marked as regulatory or risk-facing where relevant, and model exposure, sized by the portfolio, transaction volume, or business decision it touches.
Owner and effective challenge reviewer
The business owner accountable for the model, and the independent reviewer with the standing to challenge its design and outputs.
Validation status and evidence
Whether conceptual soundness, testing, and ongoing monitoring have been completed, with the developmental evidence stored alongside the entry rather than referenced from memory.
Data lineage
Where the model's inputs originate, including which ERP, general ledger, or transaction system feeds it, so a downstream data change can be traced back to every model it touches.
Third-party and vendor flag
Whether the model is built in-house, embedded in a purchased platform, or delivered through an AI feature inside existing finance software.
The record one model needs.
The inventory does not require a dedicated model risk platform to start. A structured record like the one below, held wherever the finance team already tracks its systems and controls, keeps the materiality scoring and the model type explicit from the first entry, so a generative or agentic AI feature cannot slip through as an ordinary calculation.
Example model inventory record
{
"model_id": "ap-invoice-anomaly-detector",
"model_name": "AP invoice-matching anomaly detector",
"purpose": "Flags invoices with pricing or quantity mismatches against purchase orders before payment",
"model_type": "generative_ai",
"materiality": {
"purpose_qualitative": "risk_facing",
"exposure_quantitative": "invoice_volume_processed_monthly",
"tier": "elevated"
},
"owner": "AP operations lead",
"effective_challenge_reviewer": "internal audit, finance systems",
"validation": {
"conceptual_soundness_reviewed": true,
"last_monitoring_check": "2026-07-01",
"known_limitations_documented": true
},
"data_lineage": {
"source_systems": ["ERP purchase orders", "AP invoice queue"],
"downstream_use": "payment release hold"
},
"vendor_origin": {
"third_party": true,
"embedded_in_platform": true
}
}The same structure scales whether a finance function tracks five models or fifty, since each entry carries its own materiality tier, owner, and evidence rather than inheriting one blanket assumption for the whole population.
Implementation checklist.
Build one inventory that lists every quantitative model in use across finance and treasury operations, not only the models a prior audit already flagged.
Tag each entry by type: traditional statistical or quantitative, versus generative or agentic AI, using the guidance's own model definition as the dividing line.
Score materiality for every entry using purpose and exposure, the same two factors SR 26-2 uses, so lower-risk models get lighter oversight and higher-risk models get real scrutiny.
Assign an owner and an independent reviewer to each material model before the next close cycle, not after an examiner or auditor asks who is accountable.
Capture data lineage for every model, tracing its inputs back to the ERP or transaction system of record, so a source-data change surfaces every model it could affect.
Flag AI-driven features embedded in purchased finance software as their own inventory entries, even though today's SR 26-2 carve-out leaves them outside formal scope.
Store validation evidence, assumptions, and known limitations with each entry, rather than in a reviewer's inbox or a one-off slide deck.
Revisit the inventory when the agencies publish their request for information on AI, so the generative and agentic AI models already tagged can move into whatever framework follows.
Start with the models already touching cash, revenue recognition, or financial reporting estimates. Those carry the clearest materiality case under SR 26-2’s own purpose factor, and they are the entries an auditor is most likely to ask about first.
Constructive failure modes to design around.
Treating the generative and agentic AI carve-out as permission to skip inventory and ownership work until a formal rule arrives, instead of using the interim period to get ahead of it.
Applying one validation cadence to every model regardless of materiality, which SR 26-2 explicitly moves away from and which wastes review capacity on low-exposure tools.
Letting a purchased platform's embedded AI features go untracked because no one built them in-house, when the guidance's attention to third-party and vendor models applies just as much to a feature as to a standalone system.
Keeping model documentation in whoever built the model's personal files, so a validation review or an audit request turns into a search rather than a lookup.
Scoring materiality once at launch and never revisiting it, when a model's exposure can grow well past its original assessment as the business volume behind it grows.
Each of these is an inventory gap, not a compliance failure. SR 26-2 does not require any of this today. Building it now is a bet that the request for information, once it lands, will ask for exactly this kind of evidence.
What to ask ERP and AI tooling vendors now.
Can the platform maintain a model inventory that distinguishes traditional statistical models from generative or agentic AI features, rather than treating all automation as one category?
Does it capture and store a stated purpose and materiality assessment for each model or AI feature, with room to update that assessment as usage grows?
Can it record an accountable owner and an independent reviewer per model, and surface which models currently have neither?
Does it trace data lineage from each model back to the source ERP or ledger records feeding it, so a data change flags every downstream model?
Can it hold validation evidence, testing results, and known limitations as structured records attached to the model entry, not as separate unlinked documents?
If the model or AI feature is embedded rather than built by the finance team, does the platform disclose that origin clearly enough to complete a third-party oversight review?
A platform that answers all six with a live configuration screen has already built the inventory this guidance points toward, well ahead of any formal AI-specific rule.
Practical takeaway.
SR 26-2 does not regulate the forecasting model, the invoice-matching detector, or the AI copilot embedded in a finance team’s ERP. It regulates banks, and it explicitly excludes the newest AI models even there. What it hands every finance team, regardless of whether SR 26-2 applies to them directly, is a tested, public method for scoring which models matter most and how closely to watch them. A team that builds its inventory on that method now will meet the eventual AI-specific rule with an answer already on file, not a project that starts the day the request for information turns into a requirement.
Sources.
- Federal Reserve: SR 26-2, Supervisory Guidance on Model Risk Management
- Federal Reserve: SR 26-2 attachment, full guidance text
- OCC: Model Risk Management, Revised Guidance, Bulletin 2026-13
- OCC: news release on the revised model risk management guidance
- FDIC: Agencies Issue Revised Model Risk Guidance
- Sullivan & Cromwell: Federal Banking Agencies Issue Revised Guidance on Model Risk Management
- Baker Tilly: Updated Interagency Guidance on Model Risk Management (SR 26-2)
A targeted search for public X and Twitter commentary on SR 26-2 and its generative and agentic AI carve-out returned only professional-firm articles, vendor analysis, and regulator pages, short of the two to four high-signal posts this format calls for. Ordinary citations are used instead, and nothing is fabricated.