Fair lending, explainability, and adverse action

Define fairness in the product context

Fair lending analysis begins with the applicable law, product, decision, and population. Technical fairness metrics can help identify disparities, but no single metric proves legal compliance. Approval, pricing, limits, servicing, and collections can each affect customers.

Map the full decision chain, including marketing, application completion, model scores, rules, and overrides. A model evaluated only on completed applications may miss barriers earlier in the journey. Use approved methods and appropriate access controls for sensitive analysis. The objective is to understand and address unjustified differences with evidence, not to select a metric that makes the dashboard look balanced.

Fairness analysis starts with the decision and the population affected. Approval, pricing, credit limits, servicing, collections, and exception handling can each produce different outcomes. A model-level metric does not cover the entire customer journey. Define the comparison, the relevant data, and the limits on collection and use of sensitive information with the appropriate legal and governance owners.

A measured difference calls for investigation of causes and context; it is not self-explanatory. Product eligibility, data coverage, missingness, model behavior, and human overrides can all contribute. Conversely, an attractive aggregate metric can hide a problem within a smaller segment. Review both the overall process and meaningful subpopulations, with attention to sample size and uncertainty.

Inside the mechanism. Fairness analysis starts with the lending decision, relevant population, applicable law, and possible harm. Approval, pricing, limits, servicing, and collection can create different outcomes. A single statistical parity metric does not answer every legal or product question. Define the comparison, data limits, and decision process being evaluated, then combine quantitative evidence with an assessment of the actual policy and customer experience.

A concrete example. Approval, pricing, limits, servicing, and exceptions can each produce different customer outcomes. A single aggregate metric cannot describe the entire credit journey. The comparison arm has 840/7000 adverse outcomes (12.00%) and the treatment arm has 773/7000 (11.04%). The absolute difference is -0.96 percentage points, with an illustrative large-sample 95% interval from -2.01 to 0.10. Interpretation depends on assignment integrity, outcome maturity, independence, and the actual decision being evaluated.

When the assumption fails. A model-level result is treated as sufficient evidence about every downstream action. Define the population, decision, comparison, uncertainty, and relevant governance review. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Approval, pricing, limits, servicing, and exceptions can each produce different customer outcomes. A single aggregate metric cannot describe the entire credit journey.

Outcome comparisons in context: reference condition figure preview

01Reference conditionOutcome comparisons in context

Outcome comparisons in context: failure and stress figure preview

02Failure and stressOutcome comparisons in context

Outcome comparisons in context: controlled response figure preview

03Controlled responseOutcome comparisons in context

Define fairness in the product context Define fairness in the product context — the flow Follow the sequence. Investigate causes and alternatives. Scope Identify the decision and applicable duties Measure Examine relevant outcomes and populations Review Investigate causes and alternatives — Follow the sequence. Investigate causes and alternatives. Chapter sources · Open image

Define fairness in the product context Define fairness in the product context — the distinction These concepts answer different questions. Read each definition in the context of the section. Technical parity Equality under a chosen metric Legal assessment Contextual analysis under the applicable law — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Define fairness in the product context Decision-chain review Fictional teaching record. Accuracy alone is insufficient. Decision-chain review Illustrative data; not a real customer record or a prescribed policy. Application completion unequal rates Possible upstream barrier Model accuracy similar One technical measure Conclusion further review needed Accuracy alone is insufficient Fairness can be affected before model scoring — Fictional teaching record. Accuracy alone is insufficient. Chapter sources · Open image

Define fairness in the product context Define fairness in the product context — control and failure modes Fairness can be affected before model scoring. The branches show why alternative designs fail. Control design Assess the whole customer decision chain. Fairness can be affected before model scoring. Failure mode 1 Declare compliance from one parity metric. The legal question is broader. avoid Failure mode 2 Ignore incomplete applications. Access barriers may be missed. avoid Failure mode 3 Select only favorable metrics. That hides rather than resolves differences. avoid — Fairness can be affected before model scoring. The branches show why alternative designs fail. Chapter sources · Open image

Examine proxies and data provenance

A feature can correlate with a protected characteristic without naming it. Removing explicit sensitive fields does not remove every proxy or historical bias. Evaluate why each feature is relevant, how it was collected, and what errors it carries.

Distinguish data used for permitted compliance analysis from data allowed in an operational decision. Apply separation and access controls where needed. Review alternative features and policies that achieve the legitimate objective with less adverse impact where the applicable framework calls for that analysis. Document the tradeoffs and evidence rather than assuming predictive power settles every question.

Inside the mechanism. A feature can carry information about a protected characteristic even when that characteristic is not directly used. Examine provenance, purpose, relationships, and the mechanisms through which the feature affects treatment. Removing a field does not automatically remove its proxies. Evaluation also depends on data access and lawful use. Preserve the reason a feature is included and the evidence supporting its relevance to the decision.

A concrete example. A feature can carry information about a prohibited basis or reflect unequal data coverage even when its label looks neutral. The source and use both matter. The rule flags 2,032 of 27,500 evaluated applications. Of those flags, 1,650 meet the synthetic target, giving 81.2% precision. It misses 412 target events. Under the stated cost assumptions, residual loss and operating friction total $742,950. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. A missing-history pattern is treated as low quality without examining who lacks the data. Review provenance, missingness, predictive purpose, and appropriate outcome comparisons. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A feature can carry information about a prohibited basis or reflect unequal data coverage even when its label looks neutral. The source and use both matter.

Proxy and data provenance review: reference condition figure preview

01Reference conditionProxy and data provenance review

Proxy and data provenance review: failure and stress figure preview

02Failure and stressProxy and data provenance review

Proxy and data provenance review: controlled response figure preview

03Controlled responseProxy and data provenance review

Examine proxies and data provenance Examine proxies and data provenance — the flow Follow the sequence. Evaluate errors proxies and alternatives. Provenance Identify source and collection process Relevance Explain the feature’s decision purpose Impact Evaluate errors proxies and alternatives — Follow the sequence. Evaluate errors proxies and alternatives. Chapter sources · Open image

Examine proxies and data provenance Examine proxies and data provenance — the distinction These concepts answer different questions. Read each definition in the context of the section. Predictive association Feature helps estimate an outcome Permissible use Feature is suitable under the legal and policy context — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Examine proxies and data provenance Feature review Fictional teaching record. Candidate for evaluation. Feature review Illustrative data; not a real customer record or a prescribed policy. Feature geographic aggregate Potential proxy concern Purpose capacity estimate Claim to test Alternative verified cash evidence Candidate for evaluation Prediction alone does not justify every use — Fictional teaching record. Candidate for evaluation. Chapter sources · Open image

Examine proxies and data provenance Examine proxies and data provenance — control and failure modes Prediction alone does not justify every use. The branches show why alternative designs fail. Control design Review relevance provenance and impact. Prediction alone does not justify every use. Failure mode 1 Assume no sensitive column means no bias. Proxies and process effects can remain. avoid Failure mode 2 Reuse audit-only data in production automatically. Permitted uses can differ. avoid Failure mode 3 Ignore data errors by group. Unequal error can affect decisions. avoid — Prediction alone does not justify every use. The branches show why alternative designs fail. Chapter sources · Open image

Generate accurate adverse-action reasons

Regulation B includes requirements for notices of adverse action and specific reasons under its scope. The applicable timing, content, and treatment depend on the transaction and applicant. A generic statement that an internal score was too low is not a substitute for the required specific basis.

Design the reason system with the decision system. Record the actual factors, policy version, and approved mapping to understandable language. Test cases where rules override a model and where several factors contribute. The explanation should describe the decision that occurred, not a different model’s convenient approximation.

An adverse-action explanation must reflect the actual reasons for the action under the applicable requirements. If a policy limit caused a decline, a model explanation about unrelated features does not repair the mismatch. Retain the decision path: relevant inputs, model result, policy rules, overrides, and the final reasons used. Customer-facing wording should accurately express those reasons at the appropriate level of detail. A system that cannot reconstruct the path creates a problem for review as well as for communication.

Inside the mechanism. Adverse-action reasons must reflect the actual decision within the applicable notification requirements. Store the factors and rule path used at decision time rather than generating plausible reasons from a later model. A generic internal code may need a clear customer-facing explanation. Complex models do not remove the need for accurate reasons. Test the mapping from decision evidence to notice content and retain the resulting notice record.

A concrete example. A notice must reflect the actual reasons for the action under the applicable requirements. A plausible explanation for another component is not the decision path. The case identifies 3,060 eligible records from a source population of 4,250. The required workflow completes for 2,968, but 45 completed records miss the illustrative internal target. Another 92 remain incomplete. Communication evidence covers 2,938 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. A model explanation is sent even though a policy override caused the final result. Trace inputs, rules, model results, overrides, and accurate customer-facing reasons. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A notice must reflect the actual reasons for the action under the applicable requirements. A plausible explanation for another component is not the decision path.

Actual adverse-action reasons: reference condition figure preview

01Reference conditionActual adverse-action reasons

Actual adverse-action reasons: failure and stress figure preview

02Failure and stressActual adverse-action reasons

Actual adverse-action reasons: controlled response figure preview

03Controlled responseActual adverse-action reasons

Generate accurate adverse-action reasons Generate accurate adverse-action reasons — the flow Follow the sequence. Compare notice reasons with the decision. Capture Record actual decision factors Map Use approved specific reason language Verify Compare notice reasons with the decision — Follow the sequence. Compare notice reasons with the decision. Chapter sources · Open image

Generate accurate adverse-action reasons Generate accurate adverse-action reasons — the distinction These concepts answer different questions. Read each definition in the context of the section. Generic score statement Does not identify the actual specific basis Specific reason Explains the relevant factor under the approved process — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Generate accurate adverse-action reasons Reason mapping Fictional teaching record. Traceable translation. Reason mapping Illustrative data; not a real customer record or a prescribed policy. Actual factor insufficient verified income Decision evidence Mapped reason approved specific wording Customer explanation Version reason-map-6 Traceable translation Notices must not invent a substitute rationale — Fictional teaching record. Traceable translation. Chapter sources · Open image

Generate accurate adverse-action reasons Generate accurate adverse-action reasons — control and failure modes Notices must not invent a substitute rationale. The branches show why alternative designs fail. Control design Produce reasons from the actual decision path. Notices must not invent a substitute rationale. Failure mode 1 Use a generic risk score sentence for all cases. It can omit the required specific basis. avoid Failure mode 2 Explain only the model when a rule overrode it. The rule may have driven the action. avoid Failure mode 3 Write reasons after losing the evidence. Accuracy becomes difficult to establish. avoid — Notices must not invent a substitute rationale. The branches show why alternative designs fail. Chapter sources · Open image

Use explanation tools within their limits

Feature attribution describes how a model output relates to inputs under a method’s assumptions. It does not automatically establish causation, legal sufficiency, or the actual policy reason. Correlated features can share or shift attributed importance.

Validate explanation stability and fidelity for the specific use. Test nearby inputs, correlated features, and cases with policy overrides. Human reviewers need enough context to challenge an explanation that sounds plausible but does not match the record. Keep technical analysis separate from approved customer-facing statements while maintaining a trace between them.

Inside the mechanism. An explanation method describes a model under its assumptions; it does not automatically establish causation, legal compliance, or the true reason for a policy override. Correlated features can make attributions unstable. Compare explanation output with the actual decision path and known limitations. If an external constraint determined the action, a score explanation alone can misdescribe why the customer received that outcome.

A concrete example. A model explanation describes behavior under a particular method and reference. It does not itself establish causation, fairness, or that the final action used the model. The case identifies 2,448 eligible records from a source population of 2,950. The required workflow completes for 2,375, but 36 completed records miss the illustrative internal target. Another 73 remain incomplete. Communication evidence covers 2,351 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. An attractive feature-importance chart substitutes for validation of the notice reasons. Test the explanation against the actual action logic and disclose the method’s limits. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A model explanation describes behavior under a particular method and reference. It does not itself establish causation, fairness, or that the final action used the model.

Limits of explanation tools: reference condition figure preview

01Reference conditionLimits of explanation tools

Limits of explanation tools: failure and stress figure preview

02Failure and stressLimits of explanation tools

Limits of explanation tools: controlled response figure preview

03Controlled responseLimits of explanation tools

Use explanation tools within their limits Use explanation tools within their limits — the flow Follow the sequence. Use the approved decision-reason process. Explain Compute attribution under stated assumptions Validate Test fidelity and stability Translate Use the approved decision-reason process — Follow the sequence. Use the approved decision-reason process. Chapter sources · Open image

Use explanation tools within their limits Use explanation tools within their limits — the distinction These concepts answer different questions. Read each definition in the context of the section. Attribution Model contribution under a method Causation Effect of changing a factor in the real world — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Use explanation tools within their limits Explanation review Fictional teaching record. Not attribution alone. Explanation review Illustrative data; not a real customer record or a prescribed policy. Top feature correlated balance signal Model attribution Policy override missing required evidence Actual rule action Notice basis reviewed decision path Not attribution alone Attribution is one technical artifact — Fictional teaching record. Not attribution alone. Chapter sources · Open image

Use explanation tools within their limits Use explanation tools within their limits — control and failure modes Attribution is one technical artifact. The branches show why alternative designs fail. Control design Validate explanations against the full decision. Attribution is one technical artifact. Failure mode 1 Call attribution causal proof. The method does not establish that by itself. avoid Failure mode 2 Ignore correlated inputs. Importance can shift between them. avoid Failure mode 3 Send raw feature codes to customers. The explanation must be understandable and appropriate. avoid — Attribution is one technical artifact. The branches show why alternative designs fail. Chapter sources · Open image

Monitor overrides and outcomes

Human overrides can correct model errors or introduce inconsistent treatment. Record who changed the decision, the permitted reason, evidence, and outcome. Review patterns by team and relevant population using approved analysis.

Compare both approval and denial overrides. A policy that allows commercial staff to bypass controls for favored customers needs explicit authority and oversight. Monitor after deployment because data and behavior change. A fair-lending review at model launch does not establish that future operation remains acceptable under changed conditions.

Inside the mechanism. Overrides can introduce inconsistent treatment even when the base model is stable. Record initiator, authority, reason, evidence, original recommendation, and final action. Analyze outcomes across relevant populations and decision types with appropriate maturity and uncertainty. A low override count does not prove consistency if undocumented manual paths exist. Include exception channels and downstream servicing decisions in the operating view.

A concrete example. Human review can correct a model error or introduce a new inconsistency. The final customer outcome includes both automated and manual actions. The comparison arm has 405/4500 adverse outcomes (9.00%) and the treatment arm has 373/4500 (8.29%). The absolute difference is -0.71 percentage points, with an illustrative large-sample 95% interval from -1.87 to 0.45. Interpretation depends on assignment integrity, outcome maturity, independence, and the actual decision being evaluated.

When the assumption fails. Only the automated recommendation is evaluated while overrides are omitted. Retain override reasons and compare final outcomes with an analysis that respects selection and uncertainty. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

Human review can correct a model error or introduce a new inconsistency. The final customer outcome includes both automated and manual actions.