A bias audit workflow for lending models

A bias audit for a lending model is a pipeline you rerun on a schedule, in four stages. Measure outcome disparities across protected classes with a defensible proxy. Explain what drives them at the feature level. Search for a less discriminatory alternative that holds its predictive power. Monitor the live model so the numbers you signed off on stay true as the population moves.

Everything else is documentation wrapped around those four stages. Build it as a pipeline because fairness drifts for the same reasons accuracy drifts. Your applicant mix changes at quarter-end, a data vendor reweights a feature, a bureau field starts arriving null more often, and the disparity you cleared in March is back in July. A one-off test signed by model risk tells you little about the model you are running today. So the audit has to be code that reruns, with an audit trail behind it.

Get the protected-class labels right first

You cannot measure disparate impact without knowing who is in each group, and Regulation B under ECOA generally bars you from collecting race, ethnicity, or sex on non-mortgage consumer credit. That leaves you inferring it, and the inference method is itself part of what an examiner reviews.

• For mortgages, HMDA already carries applicant race, ethnicity, and sex. Use it directly and reconcile the file against your loan origination system so you are testing the same applications you decisioned.
• For everything else, the CFPB-standard method is Bayesian Improved Surname Geocoding (BISG), which combines surname and census-tract demographics into a probability that an applicant belongs to each group. It is a proxy with real error, and it under- and over-counts in known ways.
• Whatever the source, resolve identity carefully. Deduplicate applicants, handle joint applications explicitly, and make sure a single person appearing across products does not pick up two conflicting proxy labels. Entity resolution errors here quietly bias the whole audit.

Write down the proxy’s construction, its version, and its measured error against any ground truth you do have. When a disparity number is challenged, the first question is always whether the labels hold up, and you want that answered in advance.

Measure disparity, then explain it

The headline metric is adverse impact ratio: for a protected group, the rate at which applicants are approved (or priced favorably) divided by the same rate for the reference group. The four-fifths rule flags a ratio under 0.80. Compute it on point-in-time data, using the scores and cutoffs that were actually live. A re-scored backtest leaks information the model never had at decision time, and that leakage flatters the numbers.

The ratio alone will not survive scrutiny, because BISG labels are probabilistic. Run the standard significance and threshold tests on the weighted counts, report confidence intervals, and be explicit that a 0.79 with a wide interval is a different finding than a 0.79 that is tight. Segment the analysis. A model can clear the aggregate and fail badly inside a thin-file or low-income slice, and that slice is where regulators look.

Then explain the gap. A disparity number with no attribution gives you nothing to fix, and under adverse-action rules it falls short of what you have to disclose. Use feature-attribution methods on the decisioning population to see which inputs push the protected group toward denial. You are hunting for features that carry demographic signal without a clean underwriting rationale: a geography-derived variable, a device or channel field, a debt ratio computed in a way that penalizes irregular income. Rank features by their contribution to the disparity, not by global importance, because those are different lists.

Search for a less discriminatory alternative

Finding a disparity is where the obligation starts. Fair-lending doctrine expects a lender to look for an alternative model that achieves substantially the same business objective with a smaller disparate impact, and to document the search. This is the part most teams skip and the part examiners increasingly ask to see.

Concretely, that means running a constrained search over model variants:

• Drop or transform the features your attribution step flagged, and measure both the change in the impact ratio and the loss in AUC or approval-rate-at-fixed-loss. You are trading along a frontier and you need to show the frontier.
• Retrain with fairness constraints or adversarial debiasing where the drop-a-feature approach costs too much predictive power, and record why the constrained model was or was not adopted.
• Keep the rejected alternatives. A model that reduced disparity but was not shipped is exactly what you have to be able to explain, with the business reason for the decision written at the time rather than reconstructed later.

The output of this stage is a documented decision: either you adopted a less discriminatory alternative, or you have a specific, evidenced reason none existed at acceptable cost. Either one holds up in an exam. What fails is an unexplained gap with no record that you looked.

Wire monitoring into the scoring path

The audit you passed at validation decays. Bake the same tests into production so they run on every scored batch instead of once a year.

• Compute the adverse impact ratio and per-group approval and pricing rates on each batch, using the proxy labels attached at scoring time, and alert when any group crosses a warning band before it hits the 0.80 line.
• Track the adverse-action reason codes by group. If the top denial reasons diverge sharply across protected classes, that is an early signal something in the feature pipeline shifted, and it also feeds directly into whether your ECOA notices are still accurate.
• Watch input drift on the features that carry the most demographic signal, since those are where a vendor change or a null-rate spike will move fairness first.
• Set a false-positive budget for the alerts. A monitor that pages on every quarter-end mix shift gets muted, and a muted monitor is worse than none.

Keep the whole thing under lineage: which model version, which proxy version, which cutoffs, which batch. When an examiner or an internal reviewer asks whether the model treated a group fairly last March, the answer should be a query against stored results, reproducible to the row, rather than a project you rerun from memory.