Compliance & Risk 10 min read Updated August 2026

Finance AI Model Validation — SR 11-7, SR 26-2 & EU AI Act

A practical framework for validating AI tools in financial institutions — deterministic testing methodology, model documentation requirements under SR 11-7 and SR 26-2, and how to make AI tool deployment defensible under FINRA and EU AI Act review.

Educational content, not professional advice — AI output and figures here can be wrong. Verify before you rely on it. Full disclaimer →

The Model Validation Problem for AI in Finance

SR 11-7 — the Federal Reserve's guidance on model risk management — was written for statistical models: regression equations, credit scorecards, pricing algorithms. When financial institutions began deploying large language models and AI-assisted calculation tools, a question with real regulatory teeth emerged: do LLMs constitute "models" under SR 11-7, and if so, what does validation look like?

SR 26-2 (April 2026) addressed this directly by carving out generative AI from formal SR 11-7 model validation — but the carve-out does not mean no governance. It means the governance framework needs to be adapted. The specific requirements under SR 26-2 are: (1) AI tool inventory and risk classification, (2) accuracy and reliability testing before deployment, (3) ongoing performance monitoring, and (4) documented human oversight for consequential decisions. What the regulation does not prescribe is the specific test methodology — that's where this framework comes in.

What "Validation" Means for an AI Finance Tool

For a traditional statistical model, validation means backtesting against held-out data, comparing outputs to observed outcomes, and stress-testing assumptions. For an AI finance tool — a Claude-powered DCF calculator, an MCP server that prices options, an AI that extracts financial data from filings — validation means something more direct: does the tool produce the correct numerical answer?

The critical insight is that most finance calculations have analytically computable ground truth. Black-Scholes is a closed-form formula. The MACRS depreciation schedule is published in IRS Rev. Proc. 87-57. ASC 842 lease liability is a present value calculation with a defined discount rate. WACC is a weighted average of two analytically defined costs. For these domains, validation is not probabilistic — it's deterministic. Either the tool returns 22.38% for a specific WACC problem or it doesn't. Pass/fail is objective.

This is the basis of ClaudeFinanceLab's financial accuracy eval framework: every tool is tested against analytically computed ground truth, not against LLM-generated reference answers. The test results are public, reproducible, and re-run on every deployment.

The Four-Part Validation Framework

Part 1: Tool Inventory and Risk Classification

Before any testing, map every AI tool in use to a risk tier. The SR 26-2 guidance recommends three tiers:

  • "Map all AI tools currently in use in our finance function. For each tool, answer: (1) What decision or output does it produce? (2) Is that output used directly or reviewed by a human before action? (3) What is the financial materiality of an error in this output — what is the worst-case dollar impact? (4) Is this output subject to external reporting (financial statements, regulatory filings)? From these four questions, assign a risk tier: Tier 1 (high materiality, external reporting, minimal human review) — requires full documentation; Tier 2 (material, human reviewed) — documentation with annual testing; Tier 3 (advisory only, human always decides) — light touch, periodic review."

Part 2: Pre-Deployment Accuracy Testing

For Tier 1 and Tier 2 tools, accuracy testing before deployment is non-negotiable. The testing methodology must be documented — regulators will ask what you tested, what the pass criterion was, and what the result was. Vague answers ("we tested it and it looked right") are the model risk examiner's least favorite response.

  • "Design a pre-deployment accuracy test suite for our AI WACC calculation tool. The tool takes: company name or ticker, capital structure (debt, equity, preferred), cost of debt (YTM or credit spread + risk-free), tax rate, and beta source (raw or unlevered from comps). For a test suite: (1) Define 5 test cases with known inputs and analytically computed WACC outputs (use CAPM for cost of equity: risk-free + beta × equity risk premium; use pre-tax cost of debt × (1-t) for after-tax cost of debt). (2) Define the pass criterion: output within 0.01 percentage points of the analytically computed answer. (3) Define the Hamada relevering test: given an unlevered beta of 0.85, D/E of 1.2, and tax rate of 25%, what is the levered beta? Computed answer: 0.85 × (1 + (1-0.25) × 1.2) = 1.616. (4) Produce the test report format: test ID, inputs, expected output, actual output, pass/fail, timestamp."
  • "Build a Black-Scholes accuracy test suite for our options pricing tool. Test cases: (1) European call: S=100, K=105, T=0.5, r=0.05, σ=0.20 → expected C=$5.57. (2) European put using put-call parity: same inputs → expected P=$8.04. (3) Deep-in-the-money call: S=120, K=100, T=1, r=0.05, σ=0.25 → expected C=$27.03. (4) At-the-money call at expiry: S=100, K=100, T→0 → expected C≈max(0, S-K)=$0. (5) Delta test: for case (1), expected Δ=N(d₁) where d₁=(ln(100/105)+(0.05+0.04/2)×0.5)/(0.20×√0.5). Compute d₁, expected delta, and verify the tool's output. Define pass criterion: within 0.001 of closed-form value. Produce the test documentation."

Part 3: Model Governance Documentation

SR 11-7 (and by extension SR 26-2) requires written documentation that can survive a model risk examination. For an AI tool, the minimum documentation set is: (1) a model card describing what the tool does and what it doesn't do; (2) the validation methodology and test results; (3) the monitoring plan; and (4) a record of who approved deployment and on what basis.

  • "Draft a model card for our AI-powered leveraged finance credit analysis tool. The tool: (1) ingests credit agreements (PDF/text), (2) extracts covenant definitions and calculations, (3) tests covenant compliance against actual financial data, (4) outputs a compliance certificate with calculation workings. Draft the model card to include: (a) Model description and intended use cases; (b) Limitations and out-of-scope applications — what this tool cannot reliably do; (c) Accuracy validation summary — tests performed, pass rate, ground truth methodology; (d) Known failure modes — e.g., non-standard covenant definitions, handwritten addenda, ambiguous credit agreement language; (e) Human oversight requirements — what a credit analyst must review before the output is relied upon; (f) Monitoring plan — what metrics are tracked post-deployment and at what frequency; (g) Approval record — who reviewed the tool and when. Use SR 11-7 model risk management language where appropriate."
  • "Write the ongoing monitoring plan section of our AI model governance document for a Claude-powered financial statement analysis tool. The tool summarizes 10-K and 10-Q filings, extracts key financial metrics, and flags anomalies. Monitoring plan should cover: (1) Performance metrics to track monthly — accuracy rate on extracted numerical values (compare AI extraction to human spot-check on random sample of 5 filings/month), rate of missed anomalies (anomalies flagged manually that the tool missed), false positive rate; (2) Threshold for escalation — what metric deterioration triggers a formal re-validation review; (3) Quarterly human review — senior analyst review of 10 tool outputs per quarter to assess ongoing accuracy; (4) Trigger events — regulatory changes, model version updates, new data sources — that require immediate re-testing; (5) Annual re-validation — full re-run of the pre-deployment test suite annually."

Part 4: EU AI Act Compliance for High-Risk Finance AI

The EU AI Act classifies AI systems used in financial services as high-risk if they are used for creditworthiness assessment, credit scoring, or decisions affecting access to financial products. High-risk AI requires: conformity assessment, registration in the EU database, human oversight measures, and accuracy/robustness testing. For non-EU firms with EU clients, the Act applies to the AI system's output, not just where the system is operated.

  • "Assess whether our AI credit underwriting tool falls under EU AI Act high-risk classification. The tool: (1) analyzes borrower financial statements, (2) generates a credit recommendation (approve/decline/conditions), (3) a human credit officer reviews and makes the final decision, but in 80% of cases follows the AI recommendation. Analysis requested: (a) Does this fall under Annex III point 5(b) — AI used for creditworthiness assessment? (b) Does the 80% follow-rate constitute meaningful human oversight or is it rubber-stamping? (c) If classified as high-risk, what are the specific obligations: conformity assessment, technical documentation, accuracy testing, bias monitoring? (d) What changes to the workflow would reduce regulatory risk while maintaining the efficiency gain from AI assistance?"

How ClaudeFinanceLab's Eval Framework Satisfies Documentation Requirements

The ClaudeFinanceLab financial accuracy eval framework was designed from the start to satisfy the documentation requirements of SR 11-7, SR 26-2, FINRA AI guidance, and the EU AI Act. Specifically:

  • Published methodology — the test methodology (direct Python import, analytically computed ground truth, deterministic pass/fail at 0.01% tolerance) is publicly documented on the evals page and available on request
  • Reproducible results — every test has a test ID, inputs, expected output, actual output, and pass/fail. Anyone can reproduce the results; they are not based on LLM judgment
  • Re-run on every deployment — results are current as of the timestamp shown, not historical; any tool that fails a test does not deploy
  • Domain-specific ground truth — test cases are grounded in authoritative sources: IRS MACRS tables, Black-Scholes closed-form formula, FASB ASC 842 guidance

Financial institutions using ClaudeFinanceLab tools can reference our public eval results and methodology in their model governance documentation. For a written evaluation report specifically formatted for SR 11-7, SR 26-2, or EU AI Act model governance files, contact evals@claudefinancelab.com.

Related Reading

Using Claude at your firm?

Connect Claude to live financial data via MCP — EDGAR, FDIC, BIS, CME and 18 more.

New guides & tools — free

Get notified when we add new MCP servers, finance AI guides, and eval results.

Try These Skills

Browse all Compliance & Risk tools →
FEEDBACK