The Equal Credit Opportunity Act and its implementing regulation, Regulation B, require creditors to notify applicants of adverse action taken on credit applications and, upon request or automatically under certain circumstances, provide the specific reasons for the adverse decision. The Consumer Financial Protection Bureau has issued guidance making clear that this obligation applies to decisions made by machine learning models, and that the reasons provided must be the principal reasons that actually influenced the decision — not a generic list of factors the model theoretically considers. For most ML credit models deployed today, the technical infrastructure to satisfy this requirement does not exist, and building it is not a trivial exercise.
What the CFPB Actually Requires
Regulation B allows the adverse action notice to state up to four principal reasons for the decision, selecting from a list of approved reason codes. The regulatory intent is that these reasons should reflect the actual basis for the decision in a way that is meaningful to the applicant and actionable — the applicant should be able to understand what they could do to improve their creditworthiness. For a logistic regression scorecard, mapping from model coefficients to reason codes is well understood: the model's features are ranked by their contribution to the decision, and the top reasons correspond to the features with the largest negative contribution.
For a gradient boosting model or neural network, this mapping does not exist by default. The CFPB's 2022 guidance explicitly rejected the argument that model complexity excuses the obligation to provide specific, accurate reasons. Creditors using complex models must implement explainability mechanisms that produce reason codes reflecting the model's actual decision basis. The guidance does not prescribe a specific explainability method, but the reason codes produced must be the principal reasons for the specific decision on the specific application — not general factors or population-level feature importances.
The CFPB has examined lenders specifically on their adverse action notice practices for ML models and has issued supervisory findings where the reasons provided did not reflect how the model actually made the decision. The finding is treated as a Regulation B violation, not a technical deficiency. Corrective action requires rebuilding the explainability infrastructure, not simply updating the notice language.
SHAP-Based Reason Code Generation
SHapley Additive exPlanations (SHAP) is the most widely used method for generating individual-level model explanations that are consistent with the regulatory requirement for specific, accurate reasons. SHAP assigns each feature a contribution value for each individual prediction, representing the marginal contribution of that feature to the prediction relative to the average. Ranking features by their absolute SHAP value for a specific application and mapping the top negative contributors to reason codes produces adverse action reasons that reflect how the model actually decided on that specific application.
The implementation requires that SHAP values be computed for every application at decision time — or stored alongside the decision for subsequent use in adverse action notices and regulatory examination. For models with high feature counts and high transaction volumes, this creates a computational cost that must be planned for. Pre-computing SHAP baseline values for the model and applying the SHAP TreeExplainer for tree-based models, or KernelExplainer for non-tree models, at decision time is the standard approach, with the explanation output stored in the audit log alongside the decision.
Disparate Impact Testing Architecture
ECOA and the Fair Housing Act prohibit lending discrimination on protected class bases, including facially neutral policies that have a disparate impact on protected groups and cannot be justified by business necessity. For ML models, disparate impact testing requires comparing approval rates, pricing, and other credit outcomes across protected class groups — which requires demographic data that the model is typically not permitted to use as an input. Fair lending testing programmes obtain demographic data from HMDA filings, BISG proxy methodology, or geocoded census data, link it to the model's output for the test population, and run statistical tests to identify significant disparities.
The engineering requirement is a testing pipeline that can run disparate impact analysis on the full origination population at regular intervals — at minimum quarterly, and before any model change is deployed. The pipeline must be instrumented to detect demographic proxies in the model's features — variables that are not explicitly demographic but are highly correlated with protected class membership, such as certain postal codes or names — and flag them for review. Regulators expect lenders to have identified and assessed any proxy variables in their models as part of the fair lending compliance programme.
Counterfactual Explanations and the Actionability Requirement
Beyond adverse action reasons, the regulatory expectation is that the reasons provided should be actionable — the applicant should be able to understand what they can do to obtain credit in the future. Counterfactual explanations — what changes to the application would have resulted in an approval — are a complementary explainability technique that supports this requirement. Counterfactual generation identifies the minimum change to application features that would have moved the model from decline to approve, subject to feasibility constraints (the counterfactual must suggest changes the applicant can plausibly make). Presenting actionable guidance alongside the adverse action reasons, while not strictly required by Regulation B, reduces the risk of complaints and demonstrates a good-faith compliance posture.
The engineering behind this article is available as a service.
We have done this work — not advised on it, not reviewed documentation about it. If the problem in this article is your problem, the first call is with a senior engineer who has solved it.