SR 11-7's Effective Challenge Requirement, Applied to AI Models

SR 11-7 is fifteen years old, predates every model anyone now worries about, and remains the document a bank examiner will reach for when asked how an AI model is governed. Most of it transfers cleanly. One concept does not, and it is the one the whole framework rests on.

What the guidance actually says

The Supervisory Guidance on Model Risk Management was issued jointly on 4 April 2011 by the Board of Governors of the Federal Reserve System as SR 11-7 and by the Office of the Comptroller of the Currency as Bulletin 2011-12. The Federal Reserve publishes SR 11-7; the OCC publishes Bulletin 2011-12. The Federal Deposit Insurance Corporation adopted it for its supervised institutions in 2017.

The guidance 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, and identifies three components: an information input component, a processing component, and a reporting component. It defines model risk as the potential for adverse consequences from decisions based on incorrect or misused model outputs, arising from fundamental errors and from incorrect or inappropriate use. And it builds the response on three elements: robust model development, implementation and use; sound model validation; and governance, policies and controls.

Effective challenge is the connective tissue. The guidance describes it as critical analysis by objective, informed parties who can identify model limitations and assumptions and produce appropriate change, and then says that the effectiveness of the challenge depends on the incentives, the competence and the influence of those parties. That three-part formulation is the whole of the concept and it is worth quoting the three words exactly, because each one fails differently for an AI model.

The three conditions

Incentives

The challenger must want to find problems. In a conventional model risk function this is handled structurally: validation reports to a different executive than model development, and its performance is not measured by how many models it approves. AI deployments break this quietly, because they are frequently run out of a product or innovation function with a delivery commitment, and the person best equipped to challenge the model is on the team shipping it. If the only people who understand the system are the people building it, the incentive condition has failed no matter what the organisation chart says.

Competence

The challenger must be able to do the analysis. For a logistic regression this means statistics. For a system built on a hosted language model it means understanding prompt sensitivity, evaluation design, the difference between a benchmark score and performance on your own distribution, and the failure modes that do not appear in aggregate metrics. A validation function staffed entirely by quantitative analysts from a credit-risk background will produce a thorough report about the wrong things.

Influence

This is the one the guidance is most explicit about and the one most often missing in practice. Effective challenge means the challenger can produce appropriate change — not raise an issue, not log a finding that is accepted with a remediation date two years out, but require the change. The test is whether a validation function has ever stopped a deployment. If the answer is no, and the institution has deployed anything non-trivial, that is the finding.

Conceptual soundness without internals

SR 11-7 expects validation to cover evaluation of conceptual soundness, ongoing monitoring including process verification and benchmarking, and outcomes analysis including back-testing. Conceptual soundness means reviewing the design and construction of the model, the quality and appropriateness of the theory and logic, and the developmental evidence.

Applied to a third-party foundation model this is where the framework strains hardest, and it is worth being honest that it strains rather than pretending a documentation package resolves it. You cannot review the design of a model whose weights, training data and architecture you have not seen. What a validator can actually do is a narrower and still useful set of things:

• Validate the system, not the model. The regulated artefact is the end-to-end process: retrieval, prompt construction, the model call, post-processing, thresholds, and the human decision step. Most of that is yours and is fully reviewable, and most of the failure modes live there rather than in the weights.
• Substitute empirical evidence for theoretical review.Where conceptual soundness cannot be assessed directly, the guidance already contemplates compensating emphasis on outcomes analysis and benchmarking. Held-out evaluation on your own data, stratified by the segments you care about, is the substitute.
• Test the assumptions you can state. Sensitivity to prompt wording, to input ordering, to sampling parameters, to document length. These are testable properties of your deployment even when the model is opaque.
• Establish limits of use. SR 11-7 treats incorrect or inappropriate use as a source of model risk equal to fundamental error. Documenting what the system must not be used for, and controlling that, is squarely within the framework.

What no amount of process fixes is version instability. A model that is silently updated by its provider is a model whose developmental evidence expires without notice, and continuous monitoring is not an optional enhancement in that setting — it is the only thing standing between the institution and a validated model that no longer exists.

Vendor and third-party models

SR 11-7 has a section on models from vendors and other third parties, and its position is unambiguous: the institution remains responsible for the appropriate use of the model, must validate it in the same way as an internally developed model to the extent possible, must obtain developmental evidence, must perform ongoing monitoring and outcomes analysis on its own data, and must have contingency plans for when the model or the vendor becomes unavailable.

That last requirement has become sharply practical. A contingency plan for a vendor scoring model was historically a document. For a system dependent on a hosted model API it is a question with a technical answer — whether a second provider can serve the same workload, whether prompts and evaluations transfer, and how long the switch takes. See the separate third-party risk guidance, which is a different document and does additional work.

Is an LLM even a model under SR 11-7?

This question is asked in good faith and the answer is genuinely unsettled at the edges. The 2011 definition speaks of quantitative estimates. A model producing a probability of default clearly qualifies. A model summarising a document into free text does not obviously produce a quantitative estimate at all.

Two readings are current. The narrow one takes the definition literally: a text summariser is a tool, governed under general operational risk and third-party frameworks rather than under model risk. The broad one observes that the guidance also covers approaches that process input data into estimates used in decision-making, and that examiners have shown little appetite for a distinction that would put a system influencing credit or suitability decisions outside model governance because its output happens to be prose.

Nothing has authoritatively resolved it. What would resolve it is amended or supplemental interagency guidance, which has been discussed publicly but not, at the time of writing, issued. The defensible position in the meantime is to inventory these systems, classify them by the consequence of the decision they influence rather than by the data type of their output, and apply proportionate validation — which is what a bank would end up doing under either reading. See AI model governance in finance.