Why Is Our Bank's AI Model Failing Model Risk Management Review?

Model risk management starts with a complete inventory, and it is the single most common place banks fail. Business units stand up machine learning tools for underwriting, fraud scoring, collections triage, or AML alert prioritization without routing them through the formal model governance process, creating what examiners call shadow AI. If a reviewer finds an AI tool in production that was never logged, scoped, or risk-rated, the finding cascades into every other part of the review because nothing downstream, validation, monitoring, documentation, was ever performed.

SR 26-2, the interagency guidance the Federal Reserve, OCC, and FDIC jointly issued on April 17, 2026 to replace SR 11-7 and SR 21-8, actually narrows the formal definition of a model to exclude simple arithmetic and deterministic rule-based tools. That sounds like relief, but in practice it shifts the burden onto the bank to prove a given AI tool is simple enough to fall outside scope. Banks that assumed a scoring tool was too small to register are now being asked to justify that judgment call in writing. Our overview of SR 11-7 and AI model risk management consulting and the dedicated page on model risk management under SR 26-2 both walk through how the inventory and materiality rules changed.

OCC Bulletin 2011-12 and SR 11-7 built model validation around three pillars: conceptual soundness, ongoing monitoring, and outcomes analysis. Conceptual soundness requires the bank to understand the theory and mathematics underlying the model, meaning a reviewer can ask why the model produced a specific output for a specific customer and expect a reproducible answer. Gradient-boosted trees, neural networks, and many vendor-supplied ML models cannot answer that question without a dedicated explainability layer built on top of them.

This gap shows up hardest in adverse action and fair lending contexts, where banks are still running adverse action processes designed for older scorecard models on top of ML systems that have replaced them. A model that hits strong accuracy metrics in testing can still fail review outright if the bank cannot trace a denied application back to the specific factors that drove the decision.

AI introduces risks that traditional model governance was not built to catch: model drift, bias accumulation over time, and outputs that stay confident even as they become less accurate. Deloitte's analysis of AI in banking risk management notes that banks generally have strong legacy model governance capabilities, but those frameworks were designed for models that are far easier to monitor than continuously retrained AI systems.

SR 11-7 and now SR 26-2 both require ongoing performance monitoring and outcomes analysis as a standing validation pillar, not a one-time exercise at model launch. Without automated drift detection, defined thresholds for triggering re-validation, and a documented cadence for outcomes testing, a reviewer has no way to confirm the model still behaves the way it did when it was first approved, and that alone is enough to fail the review.

Most banks do not build their own credit, fraud, or underwriting models from scratch, they license them from vendors and adapt them internally. A 2025 AI Benchmarking Survey from ACA Group and the National Society of Compliance Professionals found that only 24% of financial services firms have policies governing third-party AI use, only 43% perform enhanced due diligence on AI vendors, and only 28% of firms test or validate AI outputs at all.

Deloitte puts the accountability problem plainly: most banks rely on third-party AI and adapt it to their environments, but even when the technology comes from a vendor, accountability does not transfer with it. Reviewers do not accept a vendor's own performance claims as a substitute for independent validation. Our pages on AI model risk vendor due diligence and the AI vendor evaluation checklist cover the specific documentation banks need from vendors before a model goes into production.

SR 11-7 requires that model validation be performed by parties independent of model development, with genuine authority to challenge the model rather than rubber-stamp it. A recurring examination finding is that validation documentation cannot show the model was tested on a representative sample of the bank's actual population, that there is a defined mechanism for human override when model confidence falls below a set threshold, or that open validation findings were closed within a reasonable timeframe rather than sitting unresolved for years.

None of these gaps require exotic technology to fix. They require a validation function with real independence, a documentation standard that anticipates being read by someone trying to find holes in it, and a governance committee that tracks remediation to closure instead of to a status update.