When the Federal Reserve, OCC, and FDIC issued SR 26-2 on 17 April 2026, they modernised bank model risk management and explicitly carved generative and agentic AI out of formal MRM scope. The model-risk function inherited a cleaner toolkit; AI governance inherited a question. This piece is the operational playbook for the parallel track — tools that amplify your in-house expertise to stand up alongside MRM, not in place of it.
Why "parallel" — what SR 26-2 changed and what it left
SR 26-2's GenAI carve-out is not a void. The agencies framed the carve-out as a function of how rapidly these technologies are evolving and signalled that governance responsibility sits with other risk areas. That is a non-coverage assignment, not a prohibition — and not a single-owner instruction.
A parallel track is the realistic answer. AI governance, technology and cyber risk, third-party risk, and the model-risk function each hold a piece of the new estate. Hold this distinction: out of MRM scope, not out of every governance function. A parallel governance track preserves SR 26-2's calibrated MRM construct for statistical, financial, and economic models and stands up the AI-specific controls catalogue for everything else — without leaving a gap a supervisor can find.
Four building blocks of an AI governance track
The track is four artefacts. Each maps to a regulator expectation and extends something most banks already maintain in draft. Responsible AI Studio (RAIS) builds the toolkit each block draws from.
Policy — what an AI usage policy must cover when GenAI is in scope but out of MRM
An AI usage policy converts the SR 26-2 carve-out into a programme. Without one, a supervisor reads the GenAI exclusion as a hole in the controls catalogue. With one, it reads as a deliberate functional reassignment with cited authorities. The policy needs eight things at minimum — scope, acceptable use, data handling, vendor controls, training requirements, monitoring, incident response, and governance review — with each clause traceable to the regulation it answers to. The AI Policy Generator drafts the document with citations to SR 26-2, the EU AI Act, the NIST AI Risk Management Framework (NIST AI RMF), and ISO/IEC 42001 appropriate to your jurisdictions.
Risk register — sector-specific GenAI risks on a 5×5 matrix
The GenAI risk register is where the carved-out portfolio gets quantified and treated. The risks that recur across FinServ deployments are knowable and tight in number — hallucination in customer-facing chat, prompt-injection against agentic workflows, model drift when a foundation-model vendor swaps a base model, single-provider dependency, training-data poisoning, and copyright exposure on output. Each gets an inherent score on a 5×5 likelihood × impact matrix, three documented mitigations, a residual score after those mitigations, and a NIST AI RMF function mapping. The AI Risk Register pre-populates 12 to 18 sector-specific risks and ships in both .docx and .xlsx so the model-risk team and the AI governance lead can share one source of truth.
Vendor assessment — AI-specific due diligence aligned to ISO 42001 or NIST AI RMF
Most generative AI in a FinServ production environment is procured rather than built — which puts the AI vendor squarely inside Third-Party Risk's remit. The standard ICT vendor questionnaire does not cover training-data provenance, inference-data handling, prompt-input retention, model-versioning notice, or sub-processor flow-down. For EU-supervised entities, Regulation (EU) 2022/2554 (DORA) Article 28 is the third-party arrangements anchor AI vendors fall into. The AI Vendor Assessment carries the AI-specific clauses by default and aligns to ISO 42001 or NIST AI RMF per the framework the vendor's controls catalogue references.
Incident response — P1–P4 severity, multi-regulator notification matrix
A generic cyber-incident runbook does not cover AI-specific severity triggers. Hallucination causing customer harm, prompt-injection that exfiltrates training data, and agentic-AI action outside policy each need their own classification entry. The notification matrix absorbs EU AI Act Article 73 serious-incident reporting, NYDFS 72-hour notification analogues under 23 NYCRR Part 500, and the operational-incident reporting US banks already maintain. The AI Incident Response Playbook is the spine; the regulator-specific timelines slot in.
How this track avoids duplicating SR 26-2 work
The fear with a parallel track is double-work — two registers, two policies, two incident runbooks. The avoidance pattern is structural: one AI inventory, two governance lenses applied to it. Models that fit the new SR 26-2 statistical, financial, or economic model definition route to MRM; generative and agentic AI route to the AI governance track; deterministic spreadsheet calculations route nowhere because they are out of the model definition altogether. Shared owners cover the overlap — the model-risk lead and the AI governance lead sit on the same steering committee, and the third-party risk team handles vendor due diligence for both. One inventory, two tracks, no duplicated artefacts.
Where to read the source material
- SR 26-2 — Revised Guidance on Model Risk Management (17 April 2026)
- NYDFS Industry Letter on cybersecurity risks arising from AI (16 October 2024) — interpretive guidance under 23 NYCRR Part 500.
- Regulation (EU) 2022/2554 (DORA)
- Regulation (EU) 2024/1689 — Artificial Intelligence Act
Generate your AI policy → /tools/policy-generator/for/financial-services
Qualified review still required. Outputs are AI-generated starting-point documents — not a substitute for qualified legal or compliance advice.