ML credit models must provide specific adverse action reasons. No black box defense. Mapped to SWT3 witness procedures.
Audience: Fintech compliance officers, credit risk teams using ML underwriting models, fair lending officers, bank examiners, model risk management teams (SR 11-7), and legal counsel advising on ECOA/Regulation B compliance.
Status: Binding interpretive guidance published May 5, 2026. Effective immediately. Lenders using ML underwriting models remain fully responsible under the Equal Credit Opportunity Act (ECOA) and Regulation B for providing specific, accurate adverse action reasons. "Black box" or proprietary models do not excuse compliance. CFPB is actively monitoring for bias in AI lending.
CFPB Circular 2026-03 reinforces existing obligations under the Equal Credit Opportunity Act (ECOA) and Regulation B as they apply to AI and ML-driven credit underwriting. The core requirements:
Each CFPB requirement maps to one or more SWT3 witness procedures. The table below shows what each procedure witnesses and what evidence it produces for examiners.
| CFPB Requirement | SWT3 Procedure | What It Witnesses | Evidence Produced |
|---|---|---|---|
| Specific adverse action reasons | AI-EXPL.1 |
Explanation method, feature count, top features | Per-decision explainability anchor with factor attribution |
| Bias monitoring | AI-FAIR.1 |
Bias disparity ratio, protected group count, max disparity | Periodic fairness assessment anchors with quantified disparities |
| Model understanding | AI-MDL.1 |
Model hash, version, architecture type | Model identity anchor linking decisions to validated model version |
| Inference provenance | AI-INF.1 |
Model hash, prompt/input hash, response/output hash | Per-inference provenance anchor with cryptographic input-output binding |
| Audit trail integrity | AI-AUDIT.1 |
Entry count, tamper detection result | Tamper-evident audit chain with integrity verification |
| Transparency disclosure | AI-TRANS.1 |
Disclosure type, recipient type, timestamp | Disclosure event anchor proving applicant was informed |
| Drift monitoring | AI-DRIFT.1 |
Metrics evaluated, drift count, drift type | Statistical drift detection anchor with threshold status |
| Incident reporting | AI-INCIDENT.1 |
Severity, notification status, incident type | Incident lifecycle anchor with notification chain |
This is the Circular's core requirement. Every credit denial using an ML model must cite specific factors that drove the adverse decision. AI-EXPL.1 witnesses the explanation method used (SHAP, LIME, feature importance, counterfactual, etc.), how many features were evaluated, and which features drove the decision.
The anchor captures explanation_method, feature_count, and top_features as structured factors, creating a cryptographic record that the lender produced a specific, method-backed explanation for each adverse action.
Filter the witness ledger by AI-EXPL.1 for the underwriting model. Each denial should have a corresponding anchor with feature_count > 0 and explanation_method documented. Missing anchors for denial events indicate a gap in adverse action documentation.
CFPB is actively monitoring for discriminatory patterns in AI-driven lending. AI-FAIR.1 measures bias disparity ratios across protected groups (race, gender, age, marital status, national origin, and other classes protected under ECOA). The procedure captures the number of protected groups evaluated, the maximum observed disparity, and the assessment methodology.
Regular bias assessments create an evidence chain demonstrating ongoing fair lending compliance -- not just a point-in-time validation.
Look for regular AI-FAIR.1 anchors with at least monthly cadence for production lending models. max_disparity values exceeding 0.80 (the four-fifths rule threshold) should trigger corresponding remediation evidence. Gaps in cadence suggest the lender is not continuously monitoring for disparate impact.
The Circular requires lenders to understand how their models work. AI-MDL.1 proves which model version produced a given decision by anchoring the model hash, version identifier, and architecture type. AI-INF.1 provides per-inference provenance, cryptographically linking each input to its output through the identified model.
Together, these procedures create an unbroken chain: validated model (AI-MDL.1) received this input and produced this output (AI-INF.1), which was then explained to the applicant (AI-EXPL.1).
Cross-reference AI-MDL.1 model hashes with the institution's validated model registry. AI-INF.1 anchors should cover 100% of credit decisions -- not just denials. A model hash mismatch between AI-MDL.1 and AI-INF.1 indicates an unvalidated model was used in production.
Credit models degrade over time as economic conditions, applicant demographics, and market behavior shift. AI-DRIFT.1 detects statistical drift in model behavior by evaluating key performance metrics against established baselines, capturing the number of metrics evaluated, the count of metrics exhibiting drift, and the drift type (data drift, concept drift, or performance drift).
Continuous drift monitoring demonstrates that the lender is actively managing model risk -- not deploying a model and forgetting it.
Verify drift monitoring cadence -- daily or weekly for production lending models. When drift_count > 0, there should be correlating model revalidation evidence (new AI-MDL.1 anchors or documented remediation). Extended drift without revalidation is a finding.
CFPB Circular 2026-03 does not operate in isolation. For federally supervised institutions, it sits alongside SR 11-7 (Federal Reserve Supervisory Letter on Model Risk Management). The two frameworks are complementary:
SWT3 evidence satisfies both simultaneously. AI-EXPL.1 anchors prove adverse action specificity for CFPB. AI-MDL.1 and AI-DRIFT.1 anchors prove model validation and monitoring for SR 11-7. The same witness ledger serves both examiner populations without duplication.
For comprehensive SR 11-7 procedure mappings, see the SR 11-7 Model Risk Overlay Guide.
Six questions a bank examiner will ask during a fair lending examination involving AI/ML underwriting models, and where the evidence lives.
| Examiner Question | Evidence Source |
|---|---|
| How does the model explain individual denials? | AI-EXPL.1 anchors -- filter by model ID and adverse action events. Each anchor records the explanation method and specific features cited. |
| Has the model been tested for disparate impact? | AI-FAIR.1 anchors -- monthly cadence, protected group coverage, and max disparity values. Values above 0.80 should have remediation records. |
| Which model version produced this decision? | AI-MDL.1 anchor for the model, cross-referenced with AI-INF.1 anchors for the specific inference. Model hash links to validated version. |
| Is the institution monitoring for model drift? | AI-DRIFT.1 anchors -- verify cadence (daily/weekly) and check that detected drift triggered revalidation (subsequent AI-MDL.1 anchors). |
| Has the audit trail been tampered with? | AI-AUDIT.1 anchors -- tamper detection result confirms integrity of the evidence chain. Merkle rollups provide daily aggregate proofs. |
| Were applicants told AI was used in the decision? | AI-TRANS.1 anchors -- disclosure event records with recipient type and timestamp. Each anchor proves the disclosure occurred before or at the time of adverse action. |
pip install swt3-aifrom swt3_ai import SWT3Witnesswitness = SWT3Witness(api_key="your-key", tenant="your-tenant")# Witness a credit decision explanationwitness.witness("AI-EXPL.1", factor_a="shap", factor_b="12", factor_c="debt_to_income|payment_history|credit_utilization")
npm install @tenova/swt3-aiimport { SWT3Witness } from "@tenova/swt3-ai";const witness = new SWT3Witness({ apiKey: "your-key", tenant: "your-tenant" });// Witness a credit decision explanationwitness.witness("AI-EXPL.1", { factorA: "shap", factorB: "12", factorC: "debt_to_income|payment_history|credit_utilization"});