Model risk management for AI and ML: SR 11-7, SS1/23, and OSFI E-23

If you run credit, fraud, pricing, or capital models at a regulated firm, you already know model risk management. The question that keeps coming up now is narrower: do those same rules apply to the machine learning and large language models your teams are shipping? For banks and insurers supervised in the US, UK, or Canada, the answer is yes, and the obligation is already live.

This post is for risk, compliance, and model validation leaders who need to know how the three main model risk regimes treat AI and ML, what each one expects, and how to run one program that satisfies all three instead of three separate ones.

Your AI models are already in scope

None of the major model risk frameworks single out AI. They do not have to. Each defines a model broadly enough to cover any quantitative method that turns input data into an estimate, and that definition predates the current wave of machine learning by design.

The US Federal Reserve and OCC guidance, SR 11-7, defines a model as a quantitative method that applies statistical, economic, financial, or mathematical theories to process input data into quantitative estimates. A gradient-boosted credit scorecard fits that definition as cleanly as a logistic regression. So does a neural network, and so does an LLM used to draft or triage a lending decision.

The practical effect: if a model influences a regulated decision, it belongs in your model inventory and under your validation program, whether it was built in 2015 or last quarter, and whether it is a simple regression or a foundation model you license from a vendor.

The three regimes at a glance

Three supervisory regimes cover most of the English-speaking regulated market. They share a common backbone but differ in scope and timing.

A few things worth knowing. SR 11-7 was the foundational reference for over a decade; on April 17, 2026 the US agencies issued revised interagency guidance (SR 26-2 / OCC Bulletin 2026-13) that supersedes it while keeping the same core validation principles. A program built to SR 11-7 maps directly onto the successor. SS1/23 has been in force since 17 May 2024 and applies to PRA-regulated firms with internal model approval (IRB, IMA, or IMM), which in practice means the larger banks. OSFI's updated E-23 takes effect on 1 May 2027 and, unlike the older deposit-taking version, reaches insurers and other federally regulated financial institutions.

What all three ask for

Read the three side by side and the same model risk management operating model appears in each. The vocabulary differs, but the expectations line up.

A current model inventory. Every model in use gets cataloged with its owner, purpose, inputs, methodology, and known limitations. A spreadsheet that goes stale between reviews does not meet the bar; the inventory has to reflect what is running now.

Risk-based tiering. Not every model deserves the same scrutiny. Each regime expects you to rate models by materiality and impact, then scale validation depth and oversight to match. SS1/23 makes this Principle 1; SR 11-7 frames it as proportionality; E-23 calls it risk rating.

Independent validation. A function separate from the model's developers reviews it before first use and on an ongoing basis, with the standing to challenge it. SR 11-7 calls this effective challenge and expects three components: conceptual soundness, ongoing monitoring, and outcomes analysis.

Ongoing monitoring. Validation is not a one-time gate. Performance is tracked over time so that drift and decay surface and trigger action rather than sitting unnoticed until the next annual review.

Governance and documentation. Board and senior-management oversight, written policy, clear roles across owners, validators, and internal audit, and documentation detailed enough that a knowledgeable third party, including an examiner, could follow it.

What AI and ML change

The frameworks apply cleanly to AI, but AI raises the stakes on three of their requirements.

Conceptual soundness gets harder to evidence. A black-box model resists the kind of assumption-by-assumption review that a regression invites. Explainability, feature governance, and documented testing move from good practice to the core of a defensible validation.

Monitoring has more to catch. Machine learning models drift as the world moves away from their training data, and they can develop fairness or performance problems that were not visible at deployment. Outcomes analysis has to run continuously, not annually.

Effective challenge needs new fluency. A validator who can interrogate a scorecard may not be equipped to challenge an ensemble or an LLM. And vendor models raise a specific trap: licensing a foundation model does not transfer the obligation. The institution still has to validate, document, and control it.

One operating model that satisfies all three

Because the three regimes ask for the same things, you do not need three programs. You need one lifecycle that runs from inventory to attestation, applied consistently and evidenced in a way you can show any of the three supervisors.

That lifecycle has six moving parts:

• Inventory: a single catalog of every model, kept current.
• Tiering: rate each model by materiality so validation effort stays proportionate.
• Independent validation: structured reports with evidence and findings, produced separately from the model's developers.
• Ongoing monitoring: metric thresholds so drift and decay raise an alert instead of waiting for the next review.
• Revalidation triggers: breach, material change, or a tiering increase reopens validation, rather than relying on memory.
• Attestation: a per-tier roll-up of tiering, validation coverage, monitoring status, and open findings into a status you can put in front of leadership or an examiner.

VerifyWise runs this as one audit-logged workflow, which is where most of the practical difficulty in these programs sits. The rules are not the hard part. Keeping the inventory current, proving validation was independent, catching drift before an examiner does, and reconstructing the trail on demand are the hard parts, and they are what a spreadsheet-and-documents setup tends to miss.

Enforcement: supervisory expectations, not fines

One point that is easy to get wrong. None of these three regimes is a statute with its own schedule of fines. They are supervisory expectations, and enforcement runs through examination.

In the US, weaknesses surface as Matters Requiring Attention or, in the Federal Reserve's more urgent tier, Matters Requiring Immediate Attention, both non-public, both requiring written remediation with deadlines. Unremediated or severe findings can feed lower supervisory ratings and, in serious safety-and-soundness cases, formal action under the agencies' separate legal authority. SS1/23 and E-23 work the same way: supervisors assess your program and expect you to close gaps.

The practical consequence is that these findings hinge on whether you can evidence a working program. An audit-logged, always-current model risk record is the difference between a clean exam and a remediation plan.

Where to start with model risk management

If you are early, the highest-impact first move is an honest inventory. Most firms underestimate how many models they run once AI and ML systems, vendor tools, and end-user spreadsheets are counted. From there, tier by materiality so you know where to spend validation effort, then stand up monitoring on the models that matter most.

For the regime-specific detail, our solution pages break down each one: SR 11-7 for the US, SS1/23 for the UK, and OSFI E-23 for Canada. If you want to see the inventory-to-attestation workflow in practice, book a demo.