AI Governance for Credit Decisions: What ECOA, CFPB, and SR 11-7 Require

The Compliance Landscape Has Shifted Permanently

When lenders first deployed statistical scorecards in the 1980s, regulators could inspect the model. A scorecard had weights, cutoffs, and reason codes that mapped cleanly to adverse action notices. An examiner could trace any denied application to a specific decision path.

Gradient-boosted trees, neural networks, and large language models broke that traceability. A model with 500 features and non-linear interactions cannot produce a human-readable reason code from first principles — it must be engineered to do so after the fact. That engineering gap is exactly where ECOA, the CFPB, and SR 11-7 apply pressure.

The good news: the compliance requirements are well-defined. The bad news: most "AI governance" tooling addresses monitoring and alerting, not enforcement. When an AI model violates a policy, a monitoring dashboard tells you about it hours later. A governance enforcement layer prevents the violation before the output leaves the model.

ECOA and Regulation B: Adverse Action Requirements for AI

The Equal Credit Opportunity Act and its implementing regulation, Regulation B, require creditors to provide specific reasons for adverse action — denial, counteroffer, or withdrawal — within 30 days of a credit application. The CFPB's 2022 circular on adverse action explicitly confirmed that AI models are not exempt: a creditor cannot cite "complex AI methodology" as a reason for adverse action. Specific, accurate, and meaningful reasons are required regardless of model complexity.

What "Specific and Accurate" Means for AI Models

Regulation B requires that adverse action notices identify the principal reasons for the action. For traditional scorecards, reason codes were embedded in the scoring model. For AI models, lenders have adopted two primary approaches:

• Post-hoc explanation methods (SHAP, LIME) — generate feature importance values after inference and map the top contributors to reason codes
• Surrogate model explanation — train an interpretable model to approximate the AI model's decisions, then use the surrogate's reason codes

Neither approach satisfies the requirement by itself. The CFPB's 2023 guidance made clear that explanation outputs must be validated — meaning the reason codes must actually reflect the model's decision, not just a post-hoc approximation. An enforcement layer is required to verify that the explanation method is working before an adverse action notice is issued.

CFPB Guidance on AI Credit Scoring: The 2024–2026 Enforcement Pattern

The CFPB has issued three significant items of guidance bearing on AI credit models since 2022: the adverse action circular, the examination procedures update for algorithmic credit scoring, and the 2025 supervisory highlights that identified AI explainability failures at multiple institutions. The pattern is consistent: examiners are looking for evidence that lenders can produce specific, auditable reason codes for any adverse decision and that fair lending testing has been applied to the AI model's outputs.

Disparate Impact Testing is Not Optional

AI credit models that use proxy variables or correlates of protected classes can produce disparate impact even when those variables are not explicitly prohibited. The CFPB expects lenders to conduct regular disparate impact testing — comparing approval rates, pricing, and terms across protected classes — and to maintain documentation demonstrating that disproportionate outcomes have been tested and justified under a business necessity standard.

An enforcement layer that can apply disparate impact checks at inference time — flagging decisions that would produce statistically anomalous outcomes for protected classes — is architecturally superior to batch testing that happens days or weeks after decisions are made. Pre-execution enforcement makes the decision auditable before it is issued; post-hoc testing discovers problems after applicants have been harmed.

SR 11-7: Model Risk Management for Credit AI

The Federal Reserve's SR 11-7 guidance on model risk management predates modern AI by more than a decade, but it applies fully to machine learning credit models. SR 11-7 establishes three pillars for model governance: model development and implementation, model validation, and governance, policies, and controls.

What SR 11-7 Requires That Most AI Systems Don't Have

SR 11-7 requires that model risk controls be proportional to model materiality. For a model that makes credit decisions affecting consumer access to credit, the materiality is high and the controls must be correspondingly robust. Specifically, SR 11-7 expects:

• Ongoing monitoring — not just at deployment, but continuous performance tracking against outcomes
• Outcome analysis — comparing model predictions to actual defaults and repayment behavior
• Model inventory — a complete, current record of all models in production with their validation status
• Override controls — documented procedures for when and how model outputs can be overridden by human judgment, with audit trails
• Limits and restrictions — defined acceptable-use boundaries for each model, enforced at runtime

The "limits and restrictions" requirement is the one that most AI deployments handle worst. A policy document that says "this model should not approve loans above $250,000 without human review" is not an SR 11-7 control. The control is the enforcement mechanism that makes it impossible to issue a decision above that threshold without a documented human review step. That is what a governance enforcement layer provides.

The Validation Independence Requirement

SR 11-7 requires that model validation be conducted by staff independent from the model development team. For AI models, this creates a practical challenge: the validation team needs enough access to the model's decision logic to verify that governance controls are working. An enforcement layer with a documented policy specification — expressed as machine-readable rules — gives validators exactly what they need: a formal definition of the model's intended behavior that can be tested independently of the inference code.

Why Deterministic Enforcement Is Required — Not Probabilistic Guardrails

There is a fundamental architectural distinction between two categories of AI governance tooling:

• Probabilistic guardrails — use a secondary AI model or statistical classifier to evaluate whether the primary model's output complies with policy. Because the guardrail itself is probabilistic, it will occasionally approve non-compliant outputs and occasionally block compliant ones. The false-negative rate is not zero.
• Deterministic enforcement — express policy as formal rules (explicit conditions, thresholds, required fields) and evaluate those rules against the model's input and output deterministically. The enforcement engine does not have a false-negative rate for the policies it covers; the policy either fires or it does not.

For regulated credit decisions, deterministic enforcement is the only architecture that satisfies ECOA, the CFPB, and SR 11-7. Here is why: regulators do not accept "our guardrail is 99.7% accurate" as a compliance defense. They require controls that produce auditable, explainable, reproducible outcomes. A policy rule that says "if loan_amount > 250000 AND human_review = false THEN BLOCK" is auditable. A neural guardrail with a 0.3% false-negative rate is not.

How CoreGuard's lending_v1 Policy Pack Addresses Each Requirement

CoreGuard's lending_v1 policy pack is a pre-built policy specification designed for consumer lending compliance. It evaluates proposed credit decisions against a set of deterministic rules derived from ECOA, Regulation B, FCRA Section 615, and SR 11-7 model risk requirements. The policy pack ships with the following capabilities:

Adverse Action Reason Code Validation

Before a credit decision is issued, lending_v1 verifies that the explanation pipeline has produced at minimum the required number of specific reason codes (configurable, default: 4), that each reason code maps to a known valid code from the CFPB's standardized list, and that the explanation confidence score meets the institution's validated threshold. If any check fails, the decision is BLOCKED and the failure reason is recorded in a signed audit certificate.

# CoreGuard lending_v1 adverse action validation (simplified)
{
  "policy_set": "lending_v1",
  "action": {
    "type": "credit_denial",
    "reason_codes": ["payment_history", "credit_utilization"],
    "explanation_confidence": 0.91,
    "loan_amount": 48000,
    "applicant_id": "APP-20260505-0042"
  },
  "context": {
    "model_id": "credit_model_v3.2",
    "human_review": false
  }
}

# Response
{
  "decision": "ALLOWED",
  "risk_level": "LOW",
  "violations": [],
  "audit_certificate": "eyJhbGci...",
  "reason_codes_validated": true,
  "explanation_confidence_met": true
}

Fair Lending Disparity Gate

The policy pack includes a runtime disparity gate that checks the current batch approval rate for each protected class segment against a configurable disparity threshold (default: 80% rule, i.e., adverse action rate for any protected class must not exceed 1.25x the rate for the most favored class). When the disparity gate triggers, decisions for the affected class are escalated to human review rather than auto-decided.

SR 11-7 Override Controls

Any credit decision that falls outside the model's validated operating range — defined in the policy pack as input feature distributions observed during validation — is automatically flagged for human review and logged with a model_boundary_exceeded policy violation. This implements the SR 11-7 requirement for controls at the boundary of the model's validated use envelope.

Signed Audit Certificates

Every decision evaluated by CoreGuard produces an HMAC-SHA256 signed audit certificate containing the full policy evaluation record: which rules fired, which passed, which were skipped, the disposition, and the timestamp. These certificates are verifiable by examiners independently of CoreGuard infrastructure — a critical property for SR 11-7 audit independence. The certificate format is designed to be submitted directly in regulatory examinations without additional processing.

Implementation: Integrating CoreGuard into an Existing Credit Pipeline

CoreGuard's lending_v1 pack integrates into existing credit decisioning pipelines without requiring changes to the underlying model. The evaluation endpoint accepts the proposed credit decision in a structured format and returns a disposition — ALLOWED, BLOCKED, or MODIFIED — before the decision is committed to the loan origination system.

import requests

def enforce_credit_decision(decision_payload: dict) -> dict:
    """
    Submit a proposed credit decision to CoreGuard for policy evaluation.
    Returns the enforcement disposition and signed audit certificate.
    """
    response = requests.post(
        "https://your-coreguard-instance/v1/decisions/evaluate",
        json={
            "policy_set": "lending_v1",
            "user": {
                "id": decision_payload["officer_id"],
                "role": "loan_officer"
            },
            "action": {
                "type": decision_payload["decision_type"],
                "loan_amount": decision_payload["amount"],
                "reason_codes": decision_payload["explanation"]["codes"],
                "explanation_confidence": decision_payload["explanation"]["confidence"],
                "applicant_id": decision_payload["application_id"]
            },
            "context": {
                "model_id": decision_payload["model_version"],
                "human_review": decision_payload.get("human_reviewed", False),
                "channel": decision_payload["origination_channel"]
            }
        },
        headers={"Authorization": f"Bearer {COREGUARD_API_KEY}"},
        timeout=0.5  # Sub-millisecond enforcement target
    )
    return response.json()


# In your loan origination flow:
enforcement = enforce_credit_decision(proposed_decision)

if enforcement["decision"] == "BLOCKED":
    # Route to human review with audit certificate attached
    queue_for_human_review(
        application_id=proposed_decision["application_id"],
        block_reason=enforcement["violations"],
        certificate=enforcement["audit_certificate"]
    )
elif enforcement["decision"] == "ALLOWED":
    # Commit to LOS with certificate stored for SR 11-7 audit trail
    commit_decision(
        application_id=proposed_decision["application_id"],
        certificate=enforcement["audit_certificate"]
    )

Common Compliance Gaps That CoreGuard Closes

Based on examination findings and supervisory highlights published by the CFPB and Federal Reserve, the following compliance gaps appear most frequently in AI credit model deployments:

• Explanation confidence not validated at runtime — SHAP values are computed but not checked against a minimum confidence threshold before the reason codes are used in an adverse action notice
• No runtime disparity monitoring — disparate impact testing is done quarterly in batch, not at the time of each decision
• Override controls are procedural, not technical — policy says human review is required above a threshold, but there is no technical gate preventing the LOS from issuing a decision without it
• Audit trail is incomplete — logs record that a decision was made but not which policies were evaluated and why
• Model boundary is undefined — there is no formal specification of the model's validated operating range and no mechanism to flag out-of-range decisions

Each of these gaps is addressed by the lending_v1 policy pack as a deterministic rule evaluated at inference time. The result is an enforcement layer that makes it structurally impossible to issue a non-compliant credit decision — not one that detects non-compliant decisions after they have already harmed applicants.

What Examiners Will Ask — and What You Need to Show Them

CFPB and Federal Reserve examiners examining AI credit models will typically request: the model inventory entry for each model in production, the model validation report for each model, evidence that adverse action reason codes are accurate and specific, disparate impact testing results for the most recent 12 months, and documentation of all model overrides with their disposition.

With CoreGuard's lending_v1 pack deployed, you can produce a signed audit certificate for every credit decision in the examination period, demonstrating that policy checks ran and passed (or that non-compliant decisions were blocked) for 100% of decisions. That is a materially stronger examination posture than log files that record what happened but not whether policy was enforced.

Frequently Asked Questions

Does ECOA require specific reason codes even when an AI model is used?

Yes. The CFPB's 2022 adverse action circular confirmed that AI and machine learning models are not exempt from Regulation B's (12 CFR § 1002.9) specific-reason-code requirement. A creditor cannot cite "complex AI methodology" as a reason for adverse action. Specific, accurate, and meaningful reasons derived from the model's actual decision factors are required regardless of model complexity.

What is the 80% rule and how does it apply to AI credit models?

The 4/5ths (80%) adverse impact rule holds that if the adverse action rate for a protected class exceeds 1.25x the rate for the most favored class, a prima facie case of disparate impact is established under the Fair Housing Act and ECOA. For AI credit models, this means approval rate disparities across race, sex, national origin, and other protected classes must be tracked and tested. A governance enforcement layer can apply this check at inference time — flagging decisions that would breach the threshold before they are issued, rather than discovering the disparity in quarterly batch testing.

What does SR 11-7 require for AI credit models specifically?

SR 11-7 requires model risk controls proportional to model materiality. For credit AI, this means: ongoing performance monitoring, outcome analysis comparing predictions to actual repayment behavior, a current model inventory, documented override controls with audit trails, and defined limits and restrictions on model use enforced at runtime. The "limits and restrictions" requirement is the most frequently unaddressed — a policy document specifying review requirements is not an SR 11-7 control. A technical enforcement gate that makes it structurally impossible to bypass review is.

Why is deterministic enforcement required rather than probabilistic guardrails?

Regulators require controls that produce auditable, explainable, and reproducible outcomes. A probabilistic guardrail — one that uses a secondary AI model to evaluate compliance — has a non-zero false-negative rate. "Our guardrail is 99.7% accurate" is not a defensible compliance posture under ECOA, FCRA, or SR 11-7. A deterministic rule that evaluates explicit conditions (loan amount thresholds, reason code requirements, disparity gates) either fires or it does not — there is no ambiguity, and the result is fully auditable.

How do CoreGuard audit certificates satisfy SR 11-7 audit independence requirements?

CoreGuard's HMAC-SHA256 signed audit certificates are verifiable independently of CoreGuard infrastructure using the certificate's public signing key. Each certificate contains the full policy evaluation record: which rules fired, which passed, and why — along with the timestamp and disposition. SR 11-7 requires that model validation be conducted by staff independent from development. A signed audit certificate verifiable by the validation team without access to inference code satisfies this by providing a tamper-evident record of every policy enforcement event.