# Fairness, explainability, and regulatory compliance
A lender rolls out a new machine learning credit model. It boosts approvals and cuts defaults. Six months later, an examiner asks a simple question: "Why was this applicant declined?" The data science team points to a gradient-boosted model with 400 features. Nobody in the room can answer. That silence is a compliance failure, and it can freeze a product launch or trigger an enforcement action.
This lesson shows how to stress-test a credit model so that silence never happens.
Two US legal frameworks shape every credit decision, and they apply whether a human or a model makes the call.
ECOA (Equal Credit Opportunity Act): Prohibits discrimination in lending based on protected characteristics: race, color, religion, national origin, sex, marital status, age, and receipt of public assistance. It is implemented through Regulation B.
Adverse action notice: Under Reg B, when you decline, reduce, or worsen credit terms, you must tell the applicant the specific principal reasons. "Your score was too low" is not enough. You need concrete drivers like "serious delinquency on file" or "too many recent inquiries."
Disparate impact: A policy that looks neutral but produces worse outcomes for a protected group can still be illegal, even without intent to discriminate. This is the trap that catches complex models. The model never sees race, yet it can learn proxies (zip code, shopping patterns) that correlate with it.
Regulators also expect strong model risk management (MRM)
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.
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.
# Approval rates by estimated group (illustrative numbers)
approval_control = 0.62 # e.g., control group
approval_protected = 0.48 # e.g., protected group
air = approval_protected / approval_control
print(round(air, 2)) # 0.77A 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.
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:
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.
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.
import shap
explainer = shap.TreeExplainer(credit_model)
shap_values = explainer(applicant_features)
# Rank the features that pushed toward decline
top_reasons = shap_values.values[0].argsort()[:4]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.View full definition → 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.
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.
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:
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.
Knowledge check
1. An adverse action notice under Regulation B states only: 'Your credit score was too low.' Why is this insufficient?
2. A credit model never receives race as an input, yet approves protected-group applicants at a substantially lower rate because it heavily weights zip code and shopping patterns. Which concept does this illustrate?
3. When examiners ask 'Why was this applicant declined?' and the team cannot answer because of a 400-feature gradient-boosted model, what is the core compliance problem?
4. Select ALL correct answers. Which characteristics are protected under ECOA?
Select all the correct answers.
5. Select ALL correct answers. What does strong model risk management (per SR 11-7 guidance) expect of a credit model?
Select all the correct answers.
Picture the exam six months later, redone properly. The examiner asks why an applicant was declined. Now the team pulls the file:
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.
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.