Scope - What This Guide Covers
This guide explores the debate over SR 11-7's future and its implications for your model risk management framework. Whether you're defending your governance structure to executives or redesigning validation workflows for AI models, you'll find practical guidance on positioning your program amid regulatory uncertainty.
We cover:
- The core arguments driving the BPI's call for SR 11-7's removal
- Why bank model risk chiefs oppose that position
- How to build a framework that works regardless of SR 11-7's fate
- Specific implementation choices that satisfy both innovation and control objectives
This isn't about predicting regulatory outcomes. It's about making your framework resilient to them.
Key Concepts and Definitions
SR 11-7: Federal Reserve and OCC supervisory guidance issued in 2011, establishing expectations for model risk management, including model development, implementation, and use; validation; and governance. It defines a model as "a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates."
Model Risk: The potential for adverse consequences from decisions based on incorrect or misused model outputs. SR 11-7 identifies two primary sources: a model may have fundamental errors and produce inaccurate outputs when viewed against its design objective, or it may be used incorrectly or inappropriately.
Three Lines of Defense: SR 11-7's governance structure separating model development and use (first line), independent validation (second line), and internal audit (third line). This separation creates the tension at the heart of the current debate.
Effective Challenge: The independent review and critical analysis that SR 11-7 requires from validation teams. The term appears 15 times in the guidance and represents its philosophical core.
Requirements Breakdown
What SR 11-7 Actually Requires
The guidance establishes three core pillars:
Model Development and Implementation (First Line)
- Documented development process with clear objectives
- Testing of model components and overall performance
- Outcomes analysis comparing model outputs to actual results
- Documentation sufficient for effective challenge
Independent Model Validation (Second Line)
- Evaluation of conceptual soundness
- Ongoing monitoring of model performance
- Outcomes analysis
- Validation conducted by qualified staff not responsible for development or use
Model Risk Management and Governance (Board and Senior Management)
- Board-approved policies defining acceptable model risk
- Inventory of models with risk tiering
- Regular reporting to board and senior management
- Clear accountability and ownership
The BPI Position: Why Remove SR 11-7?
The Bank Policy Institute argues for SR 11-7's removal, focusing on whether prescriptive 2011-era guidance constrains banks' ability to adapt frameworks to modern AI systems. Their argument typically follows these lines:
- Principles-based supervision would allow more flexibility than detailed requirements
- Banks have mature model risk programs that would persist without the guidance
- Innovation in AI and machine learning requires adaptive governance, not fixed processes
The Practitioner Position: Why Keep SR 11-7
Bank model risk chiefs oppose removal. Their concerns reflect operational reality:
- SR 11-7 provides the institutional authority validation teams need to push back on business pressure
- Without explicit supervisory expectations, resourcing for independent validation becomes vulnerable
- The guidance creates consistent expectations across institutions, preventing a race to the bottom
- Removing SR 11-7 doesn't eliminate model risk; it just eliminates the framework for managing it
Implementation Guidance
Building a Framework That Survives Either Outcome
Your framework needs to work whether SR 11-7 stays, goes, or evolves. Here's how:
Anchor to Risk, Not Compliance
Don't build your model risk program around SR 11-7 citations. Build it around actual model failure modes, then map it to SR 11-7. If the guidance disappears, your program still addresses real risks.
Consider a credit underwriting model. Your validation protocol should test for:
- Discriminatory outcomes (fair lending risk)
- Performance degradation in economic stress (credit risk)
- Data quality issues affecting predictions (operational risk)
These risks exist independent of supervisory guidance.
Preserve Independence Structurally
The three lines of defense aren't just an SR 11-7 requirement. They're how you prevent groupthink. If your validation team reports to the business line using the models, you don't have effective challenge regardless of what the guidance says.
Structure matters more than policy. A validation team that's independent on paper but gets defunded when they delay a model launch isn't actually independent.
Document With Purpose
SR 11-7's documentation requirements feel burdensome until you need to defend a model decision two years later. Your documentation should answer:
- Why did we choose this approach over alternatives?
- What assumptions did we test, and what did we accept on faith?
- What would make us reconsider this model's fitness for use?
If SR 11-7 goes away, you still need these answers.
Adapting the Framework for AI Models
SR 11-7's 2011 vintage shows most clearly in AI model validation. The guidance assumes you can fully inspect model logic. Many AI systems don't work that way.
For Foundation Model Integrations
You can't validate a foundation model's training the way SR 11-7 envisions validating a logistic regression. But you can validate:
- Prompt engineering and retrieval-augmented generation design
- Output filtering and guardrails
- Performance on your specific use cases
- Monitoring for drift in production
This isn't a workaround. It's applying SR 11-7's principles (effective challenge, ongoing monitoring, outcomes analysis) to a different model architecture.
SR 11-7 makes you responsible for vendor models. With AI, you're often buying access to a model, not the model itself. Your validation focuses on:
- Vendor due diligence (do they have validation processes?)
- Use case appropriateness (is this model fit for your purpose?)
- Performance monitoring (does it work in your environment?)
- Fallback procedures (what happens when the API fails?)
Common Pitfalls
Pitfall 1: Treating SR 11-7 as a Checklist
SR 11-7 doesn't give you a validation checklist. It gives you principles. If you're checking boxes without asking "does this model work correctly?", you're missing the point.
Pitfall 2: Assuming Removal Means Deregulation
If SR 11-7 goes away, you still have safety and soundness expectations. You still have fair lending laws. You still have operational risk requirements. The specific guidance might disappear; the underlying regulatory obligations won't.
Pitfall 3: Waiting for Clarity
You can't pause model validation while regulators debate SR 11-7's future. Build your program to be defensible under multiple scenarios. If you can articulate why your approach manages model risk effectively, the specific regulatory citation matters less.
Pitfall 4: Ignoring the Resource Signal
The practitioner opposition to removing SR 11-7 often comes down to resources. Without explicit supervisory expectations, validation budgets get cut. If you're a model risk chief, the BPI-practitioner split should tell you: don't assume your executive team will fund robust validation just because it's the right thing to do.
Quick Reference Table
| Element | SR 11-7 Requirement | Risk-Based Alternative | AI Model Adaptation |
|---|---|---|---|
| Validation Independence | Second line of defense, not involved in development | Separate reporting line, distinct accountability | Same; applies to prompt engineering and integration validation |
| Conceptual Soundness | Evaluation of theory and logic | Design review, assumption testing | Architecture review, capability assessment for use case |
| Ongoing Monitoring | Regular performance tracking | Automated dashboards, threshold alerts | Output quality metrics, adversarial simulation, drift detection |
| Outcomes Analysis | Compare predictions to actuals | Backtesting, performance attribution | A/B testing, human review sampling, error analysis |
| Documentation | Sufficient for effective challenge | Decision rationale, assumption log, validation evidence | Prompt design, guardrail logic, performance test results, limitations |
| Board Reporting | Risk profile, validation findings | Materiality-based reporting | Include AI-specific risks: hallucination, bias, adversarial vulnerability |
| Model Inventory | Complete inventory with risk tiering | Asset register with business criticality | Include foundation model integrations, API dependencies |
The debate over SR 11-7's future isn't really about the guidance. It's about whether institutions will maintain rigorous model risk management without explicit supervisory expectations forcing the issue. Your job is to build a framework that doesn't depend on that question being answered your way.
