Unit 06 · Chapter 3 · 10 min read

Fair lending, explainability, and adverse action

Evaluate decision quality and communicate the actual reasons.

A model has no field named race. That does not establish that its decisions are fair or lawful. Data, proxies, selection, policy, and human overrides can all affect who receives credit and on what terms.

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.

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.

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.

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.

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.

Monitor overrides and outcomes Monitor overrides and outcomes — the flow Follow the sequence. Address unjustified inconsistency. Override Capture authority and evidence Analyze Compare patterns and outcomes Correct Address unjustified inconsistency — Follow the sequence. Address unjustified inconsistency. Chapter sources · Open image

Monitor overrides and outcomes Monitor overrides and outcomes — the distinction These concepts answer different questions. Read each definition in the context of the section. Documented exception Approved departure with a supported reason Uncontrolled discretion Different treatment without an adequate basis — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Monitor overrides and outcomes Override record Fictional teaching record. Evidence-backed reason. Override record Illustrative data; not a real customer record or a prescribed policy. Original decline Initial decision Override approve Changed action Basis verified corrected income Evidence-backed reason Human changes can alter both risk and fairness — Fictional teaching record. Evidence-backed reason. Chapter sources · Open image

Monitor overrides and outcomes Monitor overrides and outcomes — control and failure modes Human changes can alter both risk and fairness. The branches show why alternative designs fail. Control design Audit overrides as part of the decision system. Human changes can alter both risk and fairness. Failure mode 1 Ignore manual decisions in model review. They affect customer outcomes. avoid Failure mode 2 Allow unrecorded commercial bypasses. Treatment becomes hard to justify. avoid Failure mode 3 Treat launch review as permanent assurance. Operation and populations change. avoid — Human changes can alter both risk and fairness. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

This chapter builds on Consumer protection, errors, and complaints. Continue with Privacy, payment data, and secure evidence to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.

Sources

Reviewed 2026-09-17