Fairness, explainability, and regulatory compliance

The CFPB has stated clearly that "black box" complexity is not an excuse. If you cannot explain a decision, you cannot legally use the model.

Step 1: Testing for disparate impact

You cannot test fairness without group data, but ECOA usually forbids collecting race on credit applications. The standard workaround is proxy estimation, most commonly BISG (Bayesian Improved Surname Geocoding), which estimates group probability from surname and location. It is imperfect, so treat results as estimates, not certainties.

Once you have estimated groups, run the classic disparate-impact screen.

Adverse Impact Ratio (AIR): Compare the approval rate of a protected group to the approval rate of the control group.

A widely cited rule of thumb from employment law, the four-fifths rule, flags an AIR below 0.80 for review. Here 0.77 is a red flag. Note: this is a diagnostic threshold, not a legal safe harbor. Courts and regulators weigh the full context.

Finding a disparity is the start, not the end. Two questions follow:

1. Is the disparity driven by a legitimate factor? Income and debt ratios can legally affect approval.

2. Is there a less discriminatory alternative (LDA)? This is the crucial modern standard. If you can find a model that is nearly as accurate but fairer, you are expected to use it.

Step 2: Searching for a less discriminatory alternative

Fair lending exams increasingly focus on LDA. The logic: if a fairer model exists at a small cost to performance, keeping the discriminatory one is hard to defend.

Practical techniques include:

• Dropping or capping proxy features that carry little predictive value but high disparate impact (for example, some behavioral variables).
• Adversarial debiasing: train the model so a second model cannot predict the protected class from its outputs.
• Reweighting or threshold adjustment across groups, used carefully to stay within legal limits.

The goal is a documented search. Examiners want to see that you looked for alternatives, measured the accuracy-versus-fairness tradeoff, and made a reasoned choice. A tiny drop in accuracy (say, moving AIR from 0.77 to 0.92 while losing a fraction of a point of predictive power) is usually a good trade.

Step 3: Explainability with SHAP

Now the adverse-action problem. You declined an applicant. Why?

SHAP (SHapley Additive exPlanations) is the industry-standard method. Borrowed from game theory, it fairly distributes a prediction across input features, showing how much each one pushed the decision up or down. Critically, it gives per-applicant explanations, exactly what adverse-action notices require.

For a declined applicant, SHAP might reveal the top negative drivers:

1. High credit utilization

2. Recent serious delinquency

3. Short credit history

4. Multiple recent inquiries

These mapmapUsing software to automate repetitive marketing tasks and campaigns, enabling personalisation at scale across channels like email, web, and social.Voir la définition complète → directly to adverse-action reason codes. This is where explainability and compliance meet: the same SHAP output that satisfies your data science validation also generates the legally required notice.

A caution regulators have raised: SHAP explains what the model did, not whether the decision was fair or the feature legitimate. A high-quality explanation of a biased decision is still a biased decision. Explainability supports compliance; it does not create it.

Step 4: Turning explanations into adverse-action notices

The translation layer matters. SHAP produces technical feature names. Applicants and examiners need plain language.

Build a mapping table:

| SHAP feature | Adverse-action reason |

|---|---|

| util_ratio_revolving | Amount owed on revolving accounts is too high |

| months_since_delinq | Serious delinquency on file |

| num_inquiries_6mo | Too many recent credit inquiries |

Then a rule selects the top drivers per applicant and prints the matching reasons. Validate that the mapping is faithful: the reason given must actually be a top driver of that specific decision, not a generic template.

Step 5: Documenting for model risk governance

Model risk governance is the internal control function that signs off before a model goes live. To pass review under SR 11-7 expectations, assemble a model documentation package that includes:

• Purpose and data: what the model predicts, what data trained it, known limitations.
• Fairness testing: AIR results by group, the LDA search, and the rationale for the chosen model.
• Explainability evidence: SHAP methodology, sample explanations, and the reason-code mapping.
• Ongoing monitoring plan: how you will re-test AIR and stability as the population drifts.

The last point is often missed. A model that was fair at launch can drift as applicant populations change. Regulators expect ongoing monitoring, not a one-time certificate.

Bringing it together: the examiner walkthrough

Picture the exam six months later, redone properly. The examiner asks why an applicant was declined. Now the team pulls the file:

• The adverse-action notice lists four plain-language reasons.
• Each reason traces to a SHAP driver for that exact applicant.
• The model's AIR sits at 0.92, above the four-fifths threshold, with documentation showing three alternatives were tested.
• The monitoring dashboard shows AIR checked quarterly.

That is a defensible model. Same accuracy goals as the black box, but now the institution can answer every question. The difference is not a fancier algorithm. It is disciplined process.

Where this is heading in 2026

Two shifts are worth watching. First, generative AI is entering credit workflows (drafting explanations, summarizing documents), which adds new explainability questions since large language models are harder to attribute than tree models. Second, regulators continue to sharpen expectations that "we used AI" is never a shield. The direction of travel is consistent: more transparency, not less.

Key Takeaways

• Complexity is not an excuse. Under ECOA and Reg B, every declined applicant is owed specific, accurate reasons. If your model cannot produce them, you cannot legally deploy it.
• Disparate impact is the main risk with ML credit models. Models learn proxies for protected traits even without seeing them. Run the Adverse Impact Ratio and treat sub-0.80 as a flag for review.
• Search for a less discriminatory alternative and document it. Examiners increasingly expect proof that you looked for a fairer model at acceptable cost.
• SHAP links validation and compliance. Per-applicant SHAP drivers, mapped to plain-language reason codes, satisfy both data science governance and adverse-action rules.
• Fairness is ongoing, not a one-time sign-off. Populations drift, so re-test AIR and stability on a schedule and keep the monitoring evidence.