AI Model Risk Management: The Banking Guide

AI Model Risk Management in Banking: SR 11-7, DORA, and the EU AI Act

AI model risk management used to mean one thing for a bank: satisfy SR 11-7, the Federal Reserve and OCC guidance that has governed model governance in US banking for over a decade. That is no longer the whole picture. A bank deploying AI for credit decisions, fraud detection, or customer risk scoring today is often answering to SR 11-7 style expectations, DORA's operational resilience and third-party risk requirements if it operates in the EU, and the EU AI Act's high-risk system obligations, all for the same underlying model. Treating those as three separate compliance projects triples the work for a problem that has one real overlapping core.

SR 11-7 vs. DORA vs. EU AI Act: A Side-by-Side Comparison

Each framework was written to solve a different problem, which is exactly why understanding the differences matters for AI model risk management planning.

What Each Framework Actually Wants From AI Model Risk Management

SR 11-7 was written in 2011 for statistical and quantitative models, but its core principles, independent validation, ongoing monitoring, clear documentation of assumptions and limitations, and effective challenge from people who did not build the model, translate directly to AI and machine learning systems. Regulators have been consistent that the guidance applies regardless of whether the model is a traditional regression or a large language model making a lending recommendation.

Why DORA Changes the AI Model Risk Management Conversation

DORA approaches the problem from a different angle entirely. Rather than asking whether a specific model is accurate, it asks whether the bank's operational systems, including AI vendors, cloud infrastructure, and any third party the AI model depends on, can withstand disruption. For a bank using a hosted AI provider or a multi-model platform, DORA is the framework that governs the vendor relationship itself: incident reporting, resilience testing, and concentration risk if too much of the AI stack depends on one provider.

The EU AI Act adds a third layer specific to the AI system's use case. Credit scoring, creditworthiness assessment, and several other banking AI applications fall squarely into the Act's high-risk category, which brings conformity assessment, technical documentation, and mandatory human oversight requirements that neither SR 11-7 nor DORA specify in the same form.

Where the Three Frameworks Overlap

Despite different origins, the three frameworks converge on a common set of practices that form the practical core of AI model risk management for banking.

1. Independent validation. SR 11-7 requires it explicitly, and the EU AI Act's conformity assessment for high-risk systems achieves a similar outcome.
2. Ongoing monitoring. All three frameworks expect a model's performance to be tracked after deployment, not just validated once before launch.
3. Documentation of limitations. SR 11-7 and the EU AI Act both require clear documentation of what a model does poorly, not just what it does well.
4. Third-party and vendor risk assessment. DORA makes this explicit; SR 11-7 and the AI Act both touch it through vendor governance expectations.
5. Human oversight for high-stakes decisions. Explicit in the EU AI Act, implied through effective challenge in SR 11-7.

Pros and Cons of a Unified Governance Process

• Pro: one documentation trail instead of three. Building governance around the overlapping core means one validation record can support multiple regulatory conversations.
• Pro: lower total compliance cost. Duplicated effort across separate SR 11-7, DORA, and AI Act tracks is expensive and easy to let drift out of sync.
• Pro: a clearer story for examiners and auditors. A single, well-documented process is easier to defend than three loosely connected ones.
• Con: the strictest requirement from each framework still has to be met. Unifying the process does not mean picking the lightest-touch option; it means building to the highest bar across all three.
• Con: jurisdiction still matters. A US-only bank does not need DORA or EU AI Act compliance, so the unified approach should be scoped to which frameworks actually apply.
• Con: requires genuine cross-functional coordination. Model risk, operational resilience, and legal or compliance teams often sit in different reporting lines, and a unified process needs someone with authority across all three.

“After testing multiple AI models on coding, research, and business prompts, combined outputs produced more reliable results than any single model.” Internal multi-model evaluation, Talkory research team.

Real Scenarios Worth Thinking Through

These scenarios are illustrative, showing how the three frameworks interact in practice rather than presented as verified case studies.

Consider a regional bank in the EU deploying an AI-assisted creditworthiness tool. SR 11-7 style principles govern the model's internal validation and monitoring, DORA governs the resilience and reporting expectations around the AI vendor providing the underlying infrastructure, and the EU AI Act's high-risk obligations require a documented conformity assessment and human oversight before the tool can be used in a live lending decision. Three frameworks, one governance file, if built correctly from the start.

Consider a US bank with no EU operations using AI for fraud detection. DORA and the EU AI Act do not directly apply, but SR 11-7 principles still govern the model's validation and ongoing monitoring, which means the bank still needs a rigorous governance process, just scoped to one framework instead of three.

Consider a bank that concentrated its entire AI stack with a single vendor to simplify procurement. DORA's third-party concentration risk expectations specifically flag this pattern, meaning the operational simplicity of a single vendor can create a documented resilience gap that a multi-vendor or multi-model approach would not.

A Practical Implementation Checklist

1. Map every AI system against all three frameworks, confirming which apply based on jurisdiction and use case.
2. Build one validation and documentation process designed to meet the strictest requirement from each applicable framework.
3. Assign clear ownership across model risk, operational resilience, and compliance, since no single team owns all three frameworks alone.
4. Include vendor and third-party risk assessment as a standing part of the process, not a one-time onboarding check.
5. Build human oversight checkpoints into any high-risk or high-stakes AI workflow, documented clearly enough to satisfy an examiner.
6. Review the classification and governance process at least annually, since all three frameworks continue to evolve.

Why Talkory Wins on Financial Services AI Governance

Talkory's core architecture, querying GPT, Claude, Gemini, Grok, Perplexity Sonar, and Kimi K3 in parallel and cross-verifying their answers, produces exactly the kind of documented, challengeable output that model risk frameworks like SR 11-7 expect: a confidence score, visible model agreement and disagreement, and a record of how a conclusion was reached rather than a single opaque answer.

Enterprise customers get custom data residency controls, dedicated infrastructure, and extended query history, directly relevant to DORA's third-party and operational resilience expectations for any financial institution building AI model risk management around a multi-model architecture.

Final Verdict: Build One Process, Not Three

AI model risk management in banking is no longer a single-framework problem. SR 11-7, DORA, and the EU AI Act each ask something genuinely different of an AI system, and a bank operating across US and EU markets is very likely answering to all three at once for the same models.

The direct recommendation: map which frameworks actually apply to your institution and jurisdiction, then build one governance process around the overlapping core, independent validation, ongoing monitoring, documented limitations, vendor risk assessment, and human oversight, rather than maintaining three separate compliance tracks that inevitably drift out of sync with each other.