The rules behind AI model validation, in plain language

When a large language model enters a regulated financial workflow, four sets of rules begin to apply. We wrote this page for the people who have to live with those rules, not for lawyers. Each section explains what the rule says, who it covers, and what evidence satisfies it.

Last reviewed: July 2026 · Educational content, not legal advice

1. SR 11-7 and OCC 2011-12: the independent validation requirement

Federal Reserve SR Letter 11-7 · OCC Bulletin 2011-12 · "Supervisory Guidance on Model Risk Management" · in force since 2011

SR 11-7 is the Federal Reserve's guidance on how banks should manage the risk that their models are wrong. It was issued in 2011 alongside a parallel bulletin from the OCC, and the FDIC adopted similar guidance in 2017. Strictly speaking it is guidance rather than law; however, bank examiners apply it during examinations, and for a supervised institution that distinction rarely matters in practice. Recent supervisory communications extend similar expectations to broker-dealers and investment advisers that use AI in regulated work.

What counts as a "model"

The guidance defines a model as a quantitative method that turns input data into estimates a business relies on. The definition was written with credit and valuation models in mind; however, it comfortably covers an LLM once its outputs feed a regulated decision or process, e.g., classifying risk disclosures, screening filings, or extracting terms from documents. Therefore, what your team calls the tool does not matter. What the tool does determines its status.

What the guidance requires

• Validation before reliance, and again after material change. A new model version, a new prompt strategy, or a quiet vendor upgrade each restart the clock.
• Effective challenge. Validation must come from people with the independence, skill, and standing to genuinely question the model. Independence means separation from the people who built it and from the people who chose to buy it.
• Three pillars. Conceptual soundness (is this approach defensible for the task), ongoing monitoring (does it keep working), and outcomes analysis (do the outputs match reality, which requires a trusted answer key).
• Documentation a reviewer can follow. Methods, data, thresholds, results, and fixes, recorded so that an independent reader could retrace the conclusion.

Where LLMs strain the framework

SR 11-7 assumes a model that behaves the same way every time: same input, same output. LLMs break that assumption, because identical inputs can return different answers on different runs. Thus a validation that ignores repeated-run stability has tested the model's mood rather than its behavior. LLMs also arrive without an answer key for your task, perform unevenly across categories of input, and change underneath you when the vendor updates. Therefore, a defensible LLM validation adds stability testing, human-labeled ground truth, category-level analysis, and a rule for when vendor updates trigger revalidation. This is the methodology gap our published benchmark research was built to address.

2. The EU AI Act: Article 15 and the technical file

Regulation (EU) 2024/1689 · high-risk obligations apply from August 2, 2026 · penalties up to €15M or 3% of global turnover for most violations

The EU AI Act is a statute, not guidance, and it reaches American companies. If your AI system is placed on the EU market, or if its outputs are used in the EU, the Act applies regardless of where you are headquartered.

The risk-tier logic

The Act sorts AI systems into tiers: prohibited, high-risk, limited-risk, and minimal-risk. The high-risk list in Annex III includes systems that evaluate the creditworthiness of individual people or set their credit scores, which is core territory for lending fintechs. Other financial document AI may sit outside the high-risk tier. However, buyers and partners increasingly ask for AI Act-style documentation regardless, because the Act's technical file has become the de facto evidence standard.

What high-risk status requires

• Article 15. The system must achieve appropriate levels of accuracy, robustness, and cybersecurity, perform consistently, and state its accuracy metrics in the instructions for use. "Appropriate" is not something a vendor can self-declare; it implies measurement against a defensible benchmark.
• Annex IV technical documentation. A standing file that describes the system, its data, its validation and testing procedures, and the results, including the metrics used and what they showed. This file is what a market-surveillance authority asks to see.
• Supporting obligations. Risk management, logging, human oversight, and post-market monitoring round out the duties for providers; deployers carry lighter but real duties of their own.

3. Third-party risk guidance: why your bank partner keeps asking

Interagency Guidance on Third-Party Relationships: Risk Management · Fed, OCC, FDIC · June 2023

Banks do not escape model risk by buying instead of building. The 2023 interagency guidance requires banks to perform due diligence and ongoing monitoring on their vendors, in proportion to the risk each vendor carries, and a vendor's AI system used in a critical activity sits near the top of that list. In practice, the bank discharges this duty by demanding evidence from the vendor: documentation, testing results, and independent validation.

This is the rule that makes validation commercially urgent for fintechs even when no regulator has ever contacted them. The stalled bank partnership, the procurement review that will not close, and the diligence questionnaire asking whether the model has been independently validated are all this guidance operating downstream. Therefore, for a fintech, an independent validation report functions less like a compliance cost and more like a sales asset; it answers the question that is holding up the deal.

4. ECOA and Regulation B: adverse action and the black-box problem

Equal Credit Opportunity Act · Regulation B · CFPB Circulars 2022-03 and 2023-03

When a lender denies credit or takes another adverse action, the law requires specific and accurate reasons for the decision. The CFPB has stated plainly that using a complex or opaque model is not an excuse. In other words, if the lender cannot explain which factors drove the model's decision, the lender is out of compliance, not the model.

For AI-assisted lending this creates an obligation that sits next to validation. The reasons a model gives for its decisions must themselves be tested, because a stated reason that does not track the model's actual behavior is an inaccurate reason. Thus an explainability audit, which checks whether stated reasons match measured behavior, is a distinct exercise from an accuracy validation, and lenders increasingly need both.

5. A note on state AI laws

State legislation is where AI rules move fastest and hold still least. Colorado's 2024 AI Act was the first comprehensive state framework, and it required impact assessments for high-risk systems including those used in financial services. In May 2026 the governor signed a replacement bill that repealed those requirements before they ever took effect; the new framework drops the impact assessments and the mandated risk programs in favor of disclosure duties that begin January 1, 2027. Texas, California, and other states have their own frameworks in motion.

The practical lesson is straightforward. Anyone who built a compliance program on Colorado's impact assessments last year is now rebuilding it. Therefore, we suggest building AI governance on the durable requirements, i.e., supervisory model-risk expectations and the EU AI Act, and treating state laws as items to monitor rather than foundations to build on. A validation file assembled to SR 11-7 and Annex IV standards will likely satisfy or exceed whatever the surviving state frameworks ask for.