Blog

Financial-services AI compliance after SR 26-2: a practitioner's governance playbook

· RAIS Team

SR 26-2 has been in force since 17 April 2026. It modernised bank model risk management (MRM) for the first time since 2011 — and placed generative and agentic AI outside the formal MRM scope. The model-risk function inherited a cleaner toolkit. AI governance inherited a question. This piece is for the FinServ practitioners who need to close the gap before their next exam, with tools that amplify your in-house expertise.

What SR 26-2 actually did

Supervisory Letter SR 26-2 — Revised Guidance on Model Risk Management was issued on 17 April 2026 by the Board of Governors of the Federal Reserve System, the Office of the Comptroller of the Currency, and the Federal Deposit Insurance Corporation — the three agencies together. The letter supersedes both SR 11-7 — Guidance on Model Risk Management (April 2011) and SR 21-8 (the April 2021 Interagency Statement on MRM for BSA/AML). Both supersessions are listed on the face of the SR 26-2 letter.

The applicability framing matters. SR 26-2 is expected to be most relevant to banking organisations with over $30 billion in total assets regulated by the Federal Reserve. Smaller institutions are not the primary audience, and the letter does not treat them as such. The action urgency comes from the letter already being in force, not from a deadline still to arrive.

Three substantive shifts sit at the centre of the revised guidance, set out in the attached revised guidance text:

  • Materiality-based posture. Governance effort is calibrated to actual risk. Previously-equal models now sort by materiality — and not every model needs the heaviest validation cadence.
  • Narrower model definition. Simple arithmetic calculations such as those inside spreadsheets, and deterministic rule-based processes and software, sit outside the new definition. Many practitioners still use model colloquially for any deterministic calculation; the new boundary matters when scoping the validation universe.
  • GenAI and agentic AI carved out of formal MRM scope. Not prohibited — non-covered. The agencies framed the carve-out as a function of how rapidly these technologies are evolving, and explicitly assigned responsibility to other risk areas within the organisation.

The third shift is the one most law-firm summaries treat as a footnote. It is the wedge for everything that follows.

What SR 26-2 did not do — the GenAI gap

SR 26-2 did not ban generative or agentic AI from US banks. It did not bring them under a single new federal AI mandate. It did not silence the question. It placed them outside the formal MRM scope and signalled that their governance should sit with other risk areas — without prescribing which ones.

That non-coverage is the gap. The model risk function — historically the home for any statistical, financial, or economic model — no longer owns generative AI under the new guidance. Tech and Cyber Risk, Third-Party Risk, and the emerging AI Governance function are the natural inheritors. Whether one of them owns it, or a combined steering committee does, is now an internal organisational design question rather than a regulatory one.

Three traps sit close to this framing and need calling out plainly:

  • "SR 26-2 banned GenAI from MRM" misrepresents the carve-out. It is non-coverage, not prohibition.
  • "SR 26-2 doesn't apply to AI" is too broad. AI and machine-learning systems that fit the new statistical, financial, or economic model definition remain in scope under MRM. The exclusion is specific to generative and agentic AI.
  • "GenAI is unregulated in US banks" is wildly wrong. GenAI sits outside MRM, but Tech and Cyber Risk, Third-Party Risk, and AI Governance still cover it under existing instruments — and external instruments such as the EU AI Act apply extraterritorially when EU customers are in scope.

Hold this distinction: out of MRM scope, not out of every governance function.

Three governance functions that just inherited GenAI

Each of these functions already has a charter and a vocabulary. Inheriting GenAI rarely means standing up a new programme from scratch — it usually means extending the existing one with AI-specific controls.

AI Governance — the obvious owner

Many banks created an AI Governance function in 2024–2025, typically reporting to Risk or directly to the Chief Risk Officer. The function sits one level removed from model risk, with a mandate that already spans data governance, model lifecycle, and ethical use. Generative AI lands here naturally: AI usage policy, AI risk register, employee guidelines for staff AI use, and AI vendor due diligence are all extensions of work that may already exist in draft. The AI Policy Generator, AI Risk Register, and Employee AI Guidelines map directly to the artefacts this function will be asked to produce. The maturity gap to watch is between banks that stood up the function as a steering committee with no permanent owner versus those that hired a dedicated AI Governance Lead — the latter absorb the SR 26-2 carve-out without an internal reorganisation, while the former usually need a short charter refresh before they can take the work formally.

Technology and Cyber Risk — the NYDFS angle

AI-enhanced cyberattacks, deepfakes used against multi-factor authentication, and AI-enabled social engineering all sit inside Tech and Cyber Risk's existing remit. The NYDFS Industry Letter on cybersecurity risks arising from AI of 16 October 2024 is interpretive guidance under 23 NYCRR Part 500 — it does not create new obligations but clarifies how existing ones apply. The specific operational read most teams miss: NYDFS Covered Entities are explicitly told to avoid SMS, voice, and video factors as the sole second factor for high-risk transactions, because each of those channels is now demonstrably defeatable by widely available deepfake tooling. For EU-supervised entities, Regulation (EU) 2022/2554 (DORA) covers the ICT and third-party arrangements that AI vendors fall into. For Canadian federally regulated financial institutions, the cyber piece sits in OSFI B-13 — distinct from OSFI E-23, which covers model risk.

Third-Party Risk — the procurement angle

Most generative AI in production at a bank is procured, not built. That puts the AI vendor squarely inside Third-Party Risk's remit — and the controls catalogue that already governs ICT third parties needs AI-specific extensions. Training-data provenance, inference-data handling, prompt-input retention, model versioning notice, and sub-processor flow-down each need a clause that did not exist in a 2022 ICT vendor template. The recurring failure mode here is contractual: a vendor MSA signed in 2023 typically gives the bank no right to receive notice when the underlying foundation model is swapped, retrained, or fine-tuned in ways that could change risk material to a regulated use case. Closing that gap is a paper exercise, but it is rarely already done. The AI Vendor Assessment and DPA Generator carry those clauses by default.

Five moves to make this quarter

Five moves cover most FinServ AI governance backlogs while the SR 26-2 transition is still fresh. None of these requires a new platform purchase — each one extends an artefact most banks already maintain in some form, which is the point. The aim is to land a defensible position before the next supervisory exam, not to stand up a new governance estate.

Inventory your AI use cases against the SR 26-2 boundary

Walk every AI use case in the organisation through three buckets. What fits the new statistical, financial, or economic model definition and stays inside MRM? What is generative or agentic and moves out of MRM scope? What was always a deterministic spreadsheet calculation and is now explicitly out of the model definition altogether? Each bucket gets an owner. The inventory is the input for every subsequent decision — re-baselining the validation universe, re-scoping the GenAI risk register, and re-mapping vendor contracts. A common worked example: a credit-decisioning model trained on tabular borrower data stays inside MRM; the GenAI loan-officer assistant that drafts adverse-action letters does not. The model risk team has clarity on one side of that line; AI governance owns the other.

Close the AI governance gap with a policy your auditor recognises

An AI usage policy that cites SR 26-2, the EU AI Act, ISO/IEC 42001, and the NIST AI Risk Management Framework appropriate to your jurisdictions is the artefact that converts a gap into a programme. Without one, the SR 26-2 carve-out reads to a supervisor as a hole in the controls catalogue rather than a deliberate functional reassignment. With one, it reads as evidence the bank has thought through where the GenAI portfolio lives and which control framework it answers to. Generate your AI policy → /tools/policy-generator/for/financial-services is the cheapest path to a draft your model risk function, AI governance lead, and legal counsel can mark up together.

Refresh your model risk register against the new materiality criteria

SR 26-2's risk-based posture means models that previously sat at equal validation cadence now sort by materiality. The register needs to reflect that. Two practical implications: validation effort can be reduced on lower-materiality models without changing the substantive MRM principles, and previously-equal documentation expectations now tier. The AI Risk Register pre-populates 12 to 18 sector-specific risks on a 5×5 likelihood × impact matrix with documented residual risk after mitigations, and aligns each risk to the NIST AI Risk Management Framework function it sits under. The .docx and .xlsx outputs land together so the model risk team and the AI governance lead can share one source of truth.

Update vendor DPAs for AI-specific terms

The DORA-Article-28-style ICT third-party arrangements that EU-supervised entities maintain need AI-specific clauses — training-data provenance, inference-data handling, prompt-input retention, and model versioning notice. The same applies to US bank vendor contracts under existing third-party risk frameworks, where the agencies' historical guidance on vendor-management already touches AI-adjacent ground but rarely names the specific terms. A typical example: a foundation-model vendor swapping a base model from one release to the next without contractual notice can change behaviour material to a regulated use case overnight, and the bank's controls catalogue will not register the change unless the contract requires notification. The DPA Generator and AI Vendor Assessment ship with the AI-specific clauses already drafted.

Build an AI-aware incident response plan

A single playbook needs to absorb EU AI Act Article 73 serious-incident reporting for high-risk systems, NYDFS 72-hour notification analogues under 23 NYCRR Part 500, and the OCC operational-incident reporting expectations a US bank already maintains. The trap most banks fall into is keeping a generic cyber-incident runbook and assuming it covers AI events — it usually does not, because the AI-specific severity triggers (hallucination causing customer harm, prompt-injection that exfiltrates training data, and agentic-AI action outside policy) need their own classification table and their own notification matrix. The AI Incident Response Playbook is the spine; the regulator-specific timelines slot in.

How Responsible AI Studio (RAIS) tools fit in for FinServ

Compliance work starts with structured documents. Responsible AI Studio (RAIS) builds the toolkit that turns the regulatory inputs your FinServ governance team already understands into draft-ready artefacts in minutes — tools that amplify your in-house expertise rather than replace the qualified review your programme still needs.

The FinServ industry cell sits inside the broader 126-cell SEO matrix that pairs 9 tools across 14 industries — and FinServ is the industry with the deepest jurisdictional coverage in the toolkit.

Where to read the source material

Build your FinServ AI risk register → /tools/ai-risk-register/for/financial-services

Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.