Compliance/SR 11-7

SR 11-7 Model Risk Management for AI Agents

Banks and federally regulated financial institutions should engage Model Risk Management when an AI agent produces or materially influences regulated decisions. SR 11-7 and OCC 2011-12 set the standard: development discipline, independent validation, ongoing monitoring, and effective challenge. Each pillar needs evidence the validators can sample.

Last updated: May 20, 2026

What is SR 11-7?

Federal Reserve SR Letter 11-7, jointly issued with OCC Bulletin 2011-12 on April 4, 2011, established Supervisory Guidance on Model Risk Management for federally regulated banks and bank holding companies. The FDIC adopted similar guidance in 2017 (FIL-22-2017). The framework defines a model as a quantitative method that processes input data into quantitative estimates, and requires three pillars: development and use, validation, and governance. The 2021 interagency RFI on AI risk management did not replace SR 11-7, but it kept AI and machine-learning systems inside the supervisory risk conversation.

Why it applies to AI agents

SR 11-7 was written for credit risk models, market risk models, and operational models. AI agents may be a model or a model-adjacent control problem with extra surface area: they consume data, use an LLM, and take action. Each step is a separate risk vector. The three pillars matter on the governed tool path, where errors can translate directly into financial, legal, or operational harm.

MRM teams at banks already maintain model inventories, validation cadences, and effective challenge procedures. Adding AI agent systems to that framework requires evidence the team can sample: what does the agent do, who approved it, how often does it fail, what changed last month. Runtime authorization is where the answer to each of those questions becomes documented fact rather than a self-report.

Control mapping: SR 11-7 pillars to Veto features

The table maps the three SR 11-7 pillars and their concrete sub-areas to runtime authorization features that produce sampling-ready evidence.

AreaRequirementVeto feature
DevelopmentDocumented purpose, design, theory, assumptions, limitationsPolicy YAML with comments describing agent scope, intent, and limitations
DevelopmentTesting prior to deployment with appropriate rigorPolicy tests with offline cases; validation gates can assert expected outcomes
ImplementationControls around deployment, change management, and operational useEnvironment-scoped policies (dev, staging, and prod); CODEOWNERS-required reviews
UseAppropriate use with awareness of limitationsPer-tool allowed-argument constraints; out-of-scope queries denied at runtime
ValidationConceptual soundness: review of theory, design, data, assumptionsPolicy diffs in version control reviewable by independent validators
ValidationOngoing monitoring: performance compared to expectations over timeWorkspace with decision outcome trend lines; alert thresholds on policy violation rates
ValidationOutcomes analysis: actual vs. expected resultsReviewer rejection rates and reason taxonomy exported for outcomes analysis
ValidationIndependence of validation function from developmentApproval workflow assigns independent reviewers; reviewer ID logged per decision
GovernanceModel inventory: complete, accurate, currentPolicy file directory acts as machine-readable agent inventory; policy checks can flag drift
GovernanceRoles and responsibilities for model owners, users, validatorsCODEOWNERS on policy files; per-org reviewer assignments in approval workflows
GovernanceEffective challenge with authority and competenceReviewer can deny any agent action with documented justification; decision record preserves the challenge
GovernanceInternal audit review of model risk management frameworkExportable evidence packages: policy history, decision records, approval records, incident timeline

Evidence Veto provides

Model Risk Management functions speak in terms of validation reports, ongoing monitoring reports, and the annual model risk assessment. Veto outputs feed each of those reports.

Model inventory

Policy YAML files are the agent inventory: each agent has a documented scope, allowed tools, and intended workflow. Reviewable in policy review workflows.

Ongoing monitoring

Monthly decision record exports with decision outcome rates, approval latency, policy violation counts, and reviewer rejection trends feed into MRM ongoing monitoring reports.

Effective challenge records

Reviewer denials, comments, and structured rejection reasons demonstrate effective challenge in operation. Each preserved with reviewer ID and timestamp.

Change records

Git history of policy changes documents model adjustments. Each can be tied to a reviewer-approved pull request with validation evidence where configured.

Implementation timeline

April 4, 2011Federal Reserve SR 11-7 and OCC Bulletin 2011-12 jointly issued
June 7, 2017FDIC FIL-22-2017 adopts similar model risk management guidance
March 31, 2021Interagency Request for Information on AI and ML risk management issued by Fed, OCC, FDIC, CFPB, NCUA
2022-2026MRM functions adapt frameworks to LLM-based and AI agent systems; validation methodology evolves
OngoingAnnual model risk assessment and periodic validation cadence by risk tier

Enforcement is through bank supervision. Weak model-risk controls can lead to supervisory findings, remediation programs, and constraints on model or agent use until issues are resolved.

Frequently asked questions

Are AI agents considered models under SR 11-7?
Often, when they produce or materially influence quantitative decisions. SR 11-7 (Federal Reserve SR Letter 11-7, jointly issued with OCC Bulletin 2011-12 on April 4, 2011) 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. AI agents outside that exact definition can still be model-adjacent systems that need a rigorous control process. The 2021 interagency RFI kept AI and ML inside the model-risk conversation, but scope still depends on use case and output.
What are the three pillars of SR 11-7?
SR 11-7 organizes model risk management around three pillars. First, robust model development, implementation, and use, with documented purpose, theory, design choices, and limitations. Second, sound model validation, including conceptual soundness review, ongoing monitoring, and outcomes analysis, conducted by parties independent of model development. Third, governance, policies, and controls, including roles, oversight, model inventory, internal audit, and effective challenge.
What is effective challenge and how does it apply to AI agents?
Effective challenge is a critical analysis of model assumptions, methodology, and outcomes performed by parties independent of the model owner with the incentive, authority, and competence to identify weaknesses. For AI agents, effective challenge means independent review of the agent's allowed actions, the prompts and tools it uses, and the operational decisions it produces. Approval workflows where a human reviewer can deny an agent action are the runtime expression of effective challenge.
Which Veto outputs feed a model risk management framework?
Veto provides three categories of MRM evidence: model inventory artifacts (policy YAML lists agents, scope, and approved tools), ongoing monitoring artifacts (decision records with decision outcome rates, latency, policy violations), and governance artifacts (policy versioning, reviewer approvals, incident records). Model validation teams use these as input to validation reports and the annual model risk assessment.

Related evidence resources

SOX

Section 302/404 ICFR for financial AI agents

NIST AI RMF

GOVERN, MAP, MEASURE, MANAGE aligned with SR 11-7

Financial Agents

Banking and FI agent patterns with MRM integration

MRM does not approve self-reports. Give validators sampling-ready evidence.

Sign upRead docsBook a call