How SR 11-7 Applies to AI Credit Models: Building a Compliant Model Risk Management Program

Model risk management for AI credit models in US banking runs on SR 11-7 and OCC Bulletin 2011-12, the 2011 interagency supervisory guidance that requires every model to sit in an inventory, pass independent validation, and face "effective challenge" — with no exemption for machine learning. Examiners apply the letter to a gradient-boosted scorecard exactly as they would to a vintage regression, and the guidance's own definition of a model sweeps the new tools in by construction.

3G Times publishes information, not legal advice, and SR 11-7 is supervisory guidance rather than a statute; institutions should map its expectations to their own regulatory profile with counsel and their regulators.

What counts as a model under SR 11-7?

The guidance defines a model as a quantitative application of statistical, economic, financial, or mathematical theory that processes inputs into estimates used in decisioning. Three features do the work: a technique, inputs, and an output that influences a business decision. A credit-scorecard that turns bureau attributes and cash-flow features into a default probability is a model under any reading. So are the pieces around it — a fraud classifier in the origination funnel, a limit-setting engine, a pricing optimizer — and so are vendor models running as a service. The unit of analysis is the estimate, not the algorithm.

Machine learning does not move that boundary; it raises the stakes inside it. SR 11-7 was written when explainability was a property of linear coefficients, but its requirements — conceptual soundness, outcomes analysis, ongoing monitoring — were deliberately technology-agnostic. A lender that documents its neural underwriter as "proprietary AI" has documented nothing the guidance recognizes.

How should development documentation change for machine learning?

The development standard is unchanged in kind: the developer must record theory, assumptions, data, and limitations. In practice, machine learning shifts where the evidence lives. Data lineage becomes the load-bearing document — source systems, transformation code, training-window boundaries, and the treatment of rejected applicants, since a model trained only on funded loans inherits the rejection bias of its predecessor. Feature documentation must flag attributes that act as proxies for protected classes: zip codes, device fingerprints, shopping-cart composition, and bank-transaction merchants have all drawn fair-lending scrutiny because they correlate with protected attributes even when membership is never an input.

Documentation should also state the model's intended use and prohibitions — which products, populations, and decision points the model was built for — because misuse is half of model risk as the guidance defines it. A repayment-risk score repurposed for marketing segmentation is a misuse event even when the arithmetic is impeccable.

What does independent validation actually require?

SR 11-7 structures validation around three activities, and all three apply to AI credit models.

• Conceptual soundness. Review the theory, key assumptions, and data quality; for machine learning, add a review of the learning objective itself — what the loss function optimizes versus what the business intends to measure — and of class-imbalance handling where defaults are rare events.
• Ongoing monitoring. Track performance, stability, and usage after deployment: population-stability drift on inputs, accuracy decay on outcomes, override rates by channel, and segmentation by geography and protected class where law permits monitoring.
• Outcomes analysis. Back-testing against realized defaults, benchmarking against an interpretable challenger — often a scorecard or logistic regression retained precisely for this purpose — and sensitivity analysis to input perturbation.

Independence is the second half of the requirement. Validation must report outside the development line, with competence, authority, and incentives to challenge; the guidance calls this combination "effective challenge" and treats its absence as a governance failure distinct from any model's arithmetic. For a small fintech, one qualified validator outside the data-science team with escalation rights to the board's risk committee is a defensible minimum posture; for a bank, the bar scales with portfolio concentration in the model.

How does governance hold the program together?

Governance is where examiners start, because it is what they can see first. The required artifacts are a board-approved model risk policy, a complete model inventory with tiering by materiality and risk, defined roles across three functional lines, and documented validation findings with tracking to closure. Tiering drives cadence: a first-degree model deciding credit approvals deserves full validation at development, annual reassessment, and event-driven review after data or code changes, while a lower-tier model may cycle longer. The inventory must include vendor and embedded models — "the platform computed it" is not an inventory entry, and the 2011 guidance already reached third-party models through the using institution.

Change management is the governance theme examiners press hardest in machine-learning programs, because retraining is routine rather than exceptional. A scheduled retrain that shifts a score cutoff by a few points is still a model change: it belongs in the change log, it triggers the tier-appropriate review, and its downstream effect on approval rates by segment belongs in the next monitoring package. Programs that retrain silently accumulate exactly the drift the guidance wrote ongoing monitoring to catch.

What does this mean in practice?

• Inventory the invisible. Fraud engines, pricing optimizers, and vendor scorecards embedded in origination platforms are models; the most common exam finding is the one that was never listed.
• Keep a dumb challenger. An interpretable benchmark model retained in parallel gives validators a reference point and gives adverse-action processes a stable basis for reasons codes.
• Wire monitoring to downstream duties. Drift findings should feed fair-lending monitoring and adverse-action reason generation, because a degrading feature can silently change which reasons surface on denials.
• Contract for evidence. Vendor agreements should guarantee access to documentation sufficient for the using institution's own validation — SR 11-7 does not travel with the vendor; it stays with the decision-maker.

The durable read of SR 11-7 for AI underwriting is that novelty changes none of the questions, only the effort each answer takes. Institutions that can show an inventory, independent challenge, and monitoring wired to consumer-facing duties are doing what the 2011 drafters asked, whatever mathematics sits in the middle.

Frequently asked questions

Does SR 11-7 apply to non-bank fintechs?

Not directly — it binds Federal Reserve-supervised institutions and, in parallel form, national banks through OCC Bulletin 2011-12. It reaches fintechs through partnership diligence: bank sponsors impose SR 11-7-grade model documentation on their service providers as a condition of the program.

How often must an AI credit model be revalidated?

The guidance sets no fixed clock and instead ties reassessment to materiality and change. A common tiered implementation validates Tier 1 models annually or upon material data, code, or population change, with lighter reviews for lower tiers.

Can a vendor's validation report substitute for the bank's own?

Partially. A vendor report is evidence an institution may rely on, but the using institution owns the model risk, must review the vendor's work critically, and performs its own outcomes analysis on its own portfolio, which the vendor cannot see.

Are explainability tools required by SR 11-7?

The guidance requires that assumptions and limitations be communicated to decision-makers, not any specific technique. Post-hoc explanation tools satisfy that duty only when validated themselves — an unexamined explanation layer is a second model, and is treated as one.