Fair Lending AI Compliance: Credit Model Bias Testing (July 2026)

Regulators reviewing fair lending AI compliance don't ask whether you have a monitoring dashboard. They ask for the timestamped records showing which thresholds fired, who received the alert, and what action followed. Most credit model governance programs generate observation; very few generate enforcement. The gap between those two things is where examination findings accumulate, and it's where this post starts.

TLDR:

• Fair lending AI compliance requires bias testing across three layers: pre-deployment statistical checks, behavioral stress testing, and post-deployment monitoring for distributional shift.
• The EEOC's four-fifths rule sets the enforcement floor: flag any protected group whose approval rate falls below 80% of the highest group's rate, with a 5 percentage point gap triggering review.
• Logging demographic parity gaps is observation; a deployment gate that blocks model promotion when a threshold is breached is enforcement. Examiners will ask which one you have.
• Lenders must document less discriminatory alternative searches before deployment; an absent LDA record functions as an admission when regulators or plaintiffs request it.
• Openlayer runs bias evaluations across ECOA and HMDA protected classes on every model version, writing pass/fail records, metric scores, and model version hashes to an audit trail examiners can inspect.

The regulatory framework governing AI credit models

Three overlapping regulatory frameworks govern how credit models get built, tested, and audited in 2026. Each one imposes specific obligations teams need to satisfy before deployment and maintain continuously afterward.

Equal Credit Opportunity Act and Fair Housing Act

The ECOA and FHA have governed lending discrimination for decades, but AI-driven underwriting has sharpened how regulators interpret their requirements. The CFPB and federal banking agencies expect lenders to produce adverse action notices that explain model decisions at the individual level, beyond simply citing a score. When a credit model uses hundreds of features, meeting that requirement demands explainability infrastructure built into the model pipeline, not added after the fact.

CFPB Model Risk Management Guidance

SR 11-7 and the CFPB's model risk guidance require banks to maintain independent model validation, document known limitations, and test for adverse impact across demographic groups. For AI credit models, regulators expect bias testing to be ongoing, not a one-time pre-launch exercise. Institutions without continuous monitoring records face examination findings that are difficult to contest without a complete audit trail.

EU AI Act: high-risk classification for credit scoring

Credit scoring systems fall under Annex III of the EU AI Act, classifying them as EU AI Act high-risk AI systems. The August 2026 compliance deadline means institutions operating in EU markets must have EU AI Act conformity assessment records in place under Article 43, data governance documentation satisfying Article 10, and ongoing logging sufficient to reconstruct model behavior under Article 12. Fines for high-risk system non-compliance reach €15 million or 3% of global annual turnover under Article 99(3). More serious violations, including prohibited practices, carry €35 million or 7% of global annual turnover under Article 99(6).

Three theories of fair lending liability for AI credit models

Federal fair lending law reaches AI credit models through three distinct legal theories, each with different evidentiary requirements and different implications for how teams should structure bias testing and audit documentation.

Disparate treatment

Disparate treatment occurs when a model treats applicants differently because of a protected characteristic. For AI systems, the risk surfaces in training data that encodes historical discrimination, proxy variables that track race or national origin, or feature engineering that effectively reintroduces protected class information through indirect inputs. Regulators look for intent evidence in model design decisions, beyond outcomes alone.

Disparate impact

Disparate impact liability attaches when a facially neutral policy produces measurably adverse outcomes for a protected class, regardless of intent. The EEOC's four-fifths rule sets the standard threshold: the selection rate for any protected group must be at least 80% of the rate for the highest-performing group. Configure an alert when any group's approval rate falls below 80% of the highest group's rate. A gap exceeding 5 percentage points triggers review regardless of whether discriminatory intent is present.

Lack of business justification

Even a model that produces disparate impact can survive regulatory scrutiny if the lender can show the practice is supported by business necessity and no less discriminatory alternative exists. This is where audit evidence becomes the deciding factor. Teams need documented records showing which features were reviewed, which alternatives were tested, and why the chosen approach produced the least disparate outcome achievable at acceptable predictive performance.

Each theory demands a different evidence artifact. Disparate treatment defense requires documentation of feature selection rationale. Disparate impact defense requires statistical testing results across demographic groups. Business justification defense requires comparative model evaluations showing alternatives were genuinely assessed.

Bias testing methodologies for AI credit models

Bias testing for AI credit models operates across three distinct methodological layers, and teams that conflate them tend to generate audit evidence that satisfies none of them completely. The layers are: pre-deployment statistical fairness testing, behavioral stress testing across demographic subgroups, and post-deployment monitoring for distributional shift.

Pre-deployment statistical fairness testing

Before a credit model goes live, the core fairness metrics to measure fall into two families: outcome-based metrics and error-rate metrics.

Outcome-based metrics measure whether the model's positive prediction rates differ across protected groups:

• Demographic parity measures the difference in approval rates across groups: P(Ŷ=1 | A=0) = P(Ŷ=1 | A=1). Flag for review when any group's approval rate falls below 80% of the highest group's rate, the threshold drawn directly from the EEOC's four-fifths rule. Configure an alert when the gap exceeds 5 percentage points (example threshold; calibrate to your institution's risk appetite and the applicable regulatory floor).
• Equal opportunity measures whether qualified applicants across groups receive approvals at equal rates: P(Ŷ=1 | Y=1, A=0) = P(Ŷ=1 | Y=1, A=1). A gap exceeding 3 percentage points above baseline should trigger a formal review before deployment proceeds.

Error-rate metrics measure whether the model's mistakes fall unevenly across groups:

• False negative rate disparity flags cases where creditworthy applicants in a protected group are denied at higher rates than creditworthy applicants outside it. A false negative rate more than 5 percentage points higher for any protected class is a red flag that warrants investigation before the model clears a deployment gate.
• False positive rate disparity flags the inverse: non-creditworthy applicants in one group being approved at higher rates. Both errors carry regulatory exposure under the Equal Credit Opportunity Act (ECOA) and the Fair Housing Act (FHA).

Behavioral stress testing

Statistical metrics on held-out test sets answer whether the model is fair on average. Stress testing answers whether it holds up at the edges. For credit models, that means constructing subgroup-specific test suites that probe:

• Near-threshold applicants in each protected class, where small score differences produce different outcomes and disparate impact is most likely to concentrate.
• Counterfactual pairs where protected attributes are varied while all creditworthiness signals are held constant. If changing an applicant's ZIP code, a known proxy for race, flips the decision, the model is encoding prohibited information through a facially neutral feature.
• Synthetic stress scenarios where income, employment history, and debt ratios are held at identical values across demographic groups to isolate model behavior from legitimate credit risk factors.

Counterfactual consistency checks are not optional for lenders subject to ECOA examination. The Consumer Financial Protection Bureau (CFPB) has explicitly named proxy variable use as an adverse action documentation concern for algorithmic credit models.

Post-deployment distributional monitoring

A model that passes pre-deployment bias testing can develop disparate impact over time as the applicant pool changes. Post-deployment monitoring requires:

• Tracking demographic parity gaps on live inference data at a cadence matched to application volume, at minimum monthly for high-volume lenders.
• Setting automated alerts when any group's approval rate falls more than 5 percentage points below the highest group's rate in the current monitoring window, with a named owner who receives the alert and a documented response window of no more than five business days before a formal investigation is initiated.
• Logging the feature distribution for each protected subgroup at inference time, beyond aggregate prediction rates alone, so that drift in input characteristics can be separated from drift in model behavior.

Logging inference-time distributions is observation. The enforcement step is the gate that blocks model promotion or triggers suspension when the demographic parity gap breaches the configured threshold. That blocking step is what separates enforcement from observation, and it is the artifact regulators will ask to see evidence of during a fair lending examination.

The less discriminatory alternative search requirement

Regulators and courts have made clear that a lender cannot simply defend a discriminatory outcome by pointing to a valid business justification. If a less discriminatory alternative (LDA) exists that serves the same business purpose with a smaller disparate impact, the lender is expected to adopt it. This obligation sits at the intersection of fair lending law and AI model governance, and it is one of the areas where compliance teams are least prepared.

The CFPB and DOJ have both signaled that LDA analysis is part of the disparate impact examination. For credit models, that means testing whether an alternative model specification, feature set, or decision threshold achieves comparable predictive performance while producing a smaller adverse impact ratio against protected classes.

What LDA testing requires in practice

There are three core questions an LDA analysis must answer for a credit model:

• Does an alternative model exist that performs comparably on the lender's stated business objective, measured by metrics like AUC, Gini coefficient, or default prediction accuracy within an acceptable tolerance range?
• Does that alternative produce a smaller disparate impact ratio against one or more protected classes, measured by comparing approval rates across groups against the four-fifths rule threshold?
• Was that alternative considered and documented before the current model was deployed, or at minimum before an adverse action decision was contested?

The third question is where most lenders' audit trails fail. A model that was never tested against alternatives has no documented evidence that the chosen specification was the least discriminatory path available. When a regulator or plaintiff requests that documentation, its absence functions as an admission.

Building the evidentiary record

LDA testing generates evidence only if the testing process itself is logged. Each candidate model assessed during the search needs a record that captures the feature set used, the fairness metrics produced across demographic groups, the performance metrics against the business objective, and the reason the candidate was accepted or rejected. Teams building this evidentiary structure should also review the EU AI Act risk management system requirements that govern how high-risk systems document ongoing controls. That record becomes the artifact regulators review when assessing whether the deployed model was the result of a genuine LDA search or a post-hoc rationalization.

Openlayer's bias testing infrastructure supports this by running fairness evaluations across candidate model versions in parallel, writing pass/fail results and metric scores to an immutable audit trail, and flagging configurations where a candidate achieves comparable AUC but a narrower demographic parity gap. That comparison record, stored against the model version hash and the evaluation timestamp, is the documentation a compliance team can produce when the LDA question is raised in an examination.

Explainability and adverse action notice compliance

The CFPB has stated directly that a model too opaque to identify specific reasons for its decisions cannot be used for adverse credit decisions under ECOA. Complexity is not a defense. CFPB Circular 2022-03 makes this explicit: creditors using AI or complex algorithms must still provide accurate, specific reasons for adverse action, and that legal requirement holds regardless of the technology used.

That position forces a distinction regulators and courts take seriously. There are two explanation types that matter here, and conflating them creates audit exposure.

Post-hoc rationalization applies SHAP values to a black box after the decision executes, generating reason codes that may or may not reflect actual feature weighting at inference time. Model-native explanations surface directly from the decision process itself and remain auditable against the inference record. Post-hoc attribution can be reconstructed to fit the preferred narrative after the fact; model-native attribution cannot.

Regulation B (12 CFR 1002.9) requires adverse action notices within 30 days of a complete application, with specific principal reasons stated. A compliant reason-code dictionary maps each code to the model feature it represents, the direction of its effect, and the threshold that triggered the denial. That dictionary must be version-controlled against the deployed model artifact, not assembled from documentation written separately and stored elsewhere.

Proxy variables and alternative data assessment

Proxy variables are indirect features that track protected characteristics without naming them directly. A model might never see race or national origin as an input, yet still produce racially disparate outcomes because it trained on ZIP code, surname frequency scores, or years at current residence. Regulators and examiners treat this as disparate impact regardless of intent, and fair lending AI compliance obligations apply in full.

There are several proxy types that appear consistently across credit model audits.

• Geographic proxies: ZIP code, census tract, and neighborhood-level features often encode race and ethnicity at high fidelity in segregated housing markets. A model weighting these features heavily can replicate redlining patterns structurally even when the feature label contains no demographic information.
• Name-based proxies: surname and first name frequency distributions map to national origin and ethnicity. Models trained on application data that includes applicant name fields, or that ingest name-extracted features from third-party enrichment, can absorb this signal.
• Behavioral proxies: shopping category patterns, merchant type history, and app usage data from alternative data providers can encode race, religion, or familial status at rates that produce measurable adverse impact across protected groups.
• Temporal proxies: employment gap length and credit history age track gender due to caregiving patterns and with age directly. Neither feature names a protected class, yet both can drive disparate outcomes under ECOA.

Identifying these requires more than correlation analysis on protected attributes. The test is whether removing or replacing the feature changes the approval rate gap across demographic groups by a meaningful margin. A feature that survives that substitution test with no rate change is contributing little protective information; one that collapses the gap when removed is functioning as a proxy regardless of its label.

Alternative data sources introduce a separate layer of assessment, one item on any EU AI Act compliance checklist for credit scoring deployments. Cash flow data, rental payment history, and utility records can genuinely expand credit access for thin-file applicants, and the CFPB has signaled that these sources can reduce disparate impact when reviewed properly. But the obligation to test remains: alternative data that produces a disparate impact exceeding the four-fifths threshold requires a business necessity justification documented in the model file before deployment.

What examiners request as audit evidence

When a fair lending examiner arrives, whether from the CFPB, OCC, FDIC, or a state banking regulator, the documentation request is not abstract. Examiners ask for specific artifacts, and institutions that cannot produce them face findings that go beyond the model itself.

Here is what examination requests typically cover:

• Adverse impact ratios by protected class for each decision point the model touches, calculated using the four-fifths rule: any group whose selection rate falls below 80% of the highest-performing group's rate triggers a documented review. Examiners want the raw numbers, not a summary conclusion.
• Intersectional disparity analysis across combinations of protected characteristics, moving beyond single-axis comparisons. A model that passes gender and race checks individually can still produce compounding disparities at the intersection.
• Proxy variable testing records showing which features were screened for correlation with protected class membership, which passed, which were removed, and who approved each decision. Examiners treat an undocumented proxy review as a missing control.
• Model version history linking each evaluation run to the exact artifact deployed in production, including the model version hash, training data snapshot, and the approval event authorizing deployment.
• Ongoing monitoring logs showing that demographic parity gaps were tracked post-deployment, the threshold that triggered review (commonly a gap exceeding 5 percentage points), and whether any threshold breach generated a documented response.
• Challenge and override records when human reviewers overrode model outputs, because examiners check whether override rates themselves differ by protected class.

The evidentiary standard is traceability. An examiner who cannot follow a continuous chain from model training through deployment through post-deployment monitoring to any specific decision will treat the gap as an uncontrolled risk, regardless of how the model actually performed.

Continuous monitoring and post-deployment obligations

Approval closes the pre-deployment chapter. Once a credit model goes live, fair lending AI compliance moves from documentation to detection, and the obligations running in parallel are specific enough to warrant their own dedicated layer.

What regulators expect after deployment

Post-deployment monitoring under fair lending frameworks is not a general directive to "keep an eye on things." The CFPB's supervisory guidance and OCC model risk management expectations (SR 11-7) both specify categories of ongoing surveillance that institutions must maintain as audit evidence.

Here is what that looks like in practice:

• Adverse impact ratios by protected class, recalculated on a rolling basis, with a documented threshold that triggers escalation. The EEOC's four-fifths rule sets the enforcement floor: configure an alert when any group's selection rate falls below 80% of the highest group's rate. A gap exceeding 5 percentage points triggers review.
• Feature drift indices comparing live input distributions against the training distribution baseline, logged at inference time so that any shift in applicant population composition is detectable before it corrupts outcomes.
• Outcome disparity trends segmented by race, national origin, sex, and age, tracked over time instead of as point-in-time snapshots, so that gradual drift accumulating across quarters does not escape notice between audit cycles.
• Decision override logs capturing every instance where a human reviewer reversed or modified a model-driven credit decision, with the reason code preserved as a structured field, not free text.

The difference between logging and enforcement

Logging these metrics is observation. Blocking or escalating based on them is enforcement. That distinction is what separates a monitoring program that satisfies examiners from one that produces records but permits harm to continue.

An adverse impact alert that fires a notification but leaves the model running is observation. A deployment gate configured to suspend automated decisioning when the demographic parity gap exceeds 5 percentage points is enforcement. The gate does more than record the anomaly; it stops the inference path until a named owner clears the flag. That blocking step is what separates enforcement from observation, and examiners reviewing a fair lending program will ask which one the institution actually has in place.

Connecting monitoring output to the audit trail

Post-deployment monitoring records do not stand alone. The EU AI Act post-market monitoring requirements under Article 12 require high-risk systems to log sufficient information to reconstruct system behavior after deployment. Under ECOA and the FFIEC examination framework, monitoring output becomes the evidence base for responding to regulatory inquiries and for proving that the institution identified and acted on disparity signals before harm compounded.

The artifact that moves from monitoring to audit trail is specific: a timestamped record of each metric calculation, the threshold it was compared against, whether it triggered an alert, who received the alert, and what action was taken. A monitoring dashboard that displays current metrics without writing those records to an auditable log does not satisfy examination requirements, even if the metrics themselves are correct. Examiners do not review dashboards; they review records.

When incident flags require escalation

Not every threshold breach is the same severity, and the escalation protocol has to reflect that. Here is the three-tier structure that maps to fair lending incident response:

• Critical: suspend the model immediately and notify the Model Owner, Governance Lead, and legal counsel within one hour if the system has produced loan denials at a statistically measurable adverse rate against a protected class, or if a drift event has corrupted inputs in a way that cannot be bounded. EU AI Act serious incident reporting under Articles 61 and 72 requires notification within 15 days of a serious incident; internal escalation must precede that clock, not follow it.
• High: keep the system running under enhanced monitoring, tighten alert thresholds, and deliver a root-cause summary within 24 hours if adverse impact ratios have breached the 5 percentage point trigger but the disparity pattern does not yet confirm systemic harm. Assign a named investigator at alert time, not after the 24-hour window closes.
• Low: log and assign within five business days if isolated anomalies appear in a single decisioning segment with no corroborating pattern across other segments. Re-classify upward if investigation reveals the anomaly is not isolated.

Each incident record must carry the severity tier, the system status decision, the notification action taken, and the root cause classification, structured as a discrete artifact, not a narrative summary. An investigation record missing any of those four elements is an open audit gap.

Governance tooling for fair lending AI compliance

Three categories of tooling typically appear in fair lending AI compliance stacks, and understanding where each stops is as important as knowing what each covers.

Governance documentation tools

Credo AI and IBM watsonx.governance sit at the governance documentation layer. Organizations developing a responsible AI framework will find these tools useful for mapping model attributes to regulatory frameworks and generating policy attestation records; IBM watsonx.governance tracks model metadata, lineage, and factsheet outputs across the watsonx ecosystem. Both produce the documentation artifacts regulators ask to see. Neither monitors live inference outputs, enforces demographic parity thresholds at runtime, or blocks a model from generating adverse action decisions when a fairness gap exceeds its approved limit. That distinction matters: a factsheet showing a model passed pre-deployment bias testing is observation after the fact, not a gate that prevented a discriminatory decision from reaching an applicant.

Production monitoring and runtime enforcement

Arize AI covers production monitoring for model drift and performance degradation. It surfaces when feature distributions shift or prediction patterns change, and it does so with genuine depth at the observability layer. But drift detection is observation. Flagging that a demographic parity gap has widened since last week does not block the next loan denial from going out. Enforcement requires a gate that stops inference when a threshold is breached, not an alert that notifies after the fact.

Openlayer spans both layers. Pre-deployment, it runs over 175 pre-built tests across bias metrics, data quality, and behavioral consistency, writing pass/fail records, metric scores, and flagged failure modes directly into an audit trail auditors can inspect. At runtime, it enforces demographic parity thresholds and adverse impact ratios as blocking gates: configure an alert when any group's selection rate falls below 80% of the highest group's rate, and the system stops inference instead of logging the anomaly for later review. That blocking step is what separates enforcement from observation. Post-deployment, Openlayer captures the input feature values, preprocessing steps, output scores, and model version hashes needed to reconstruct any decision in a post-incident investigation, satisfying the record-keeping structure Article 12 of the EU AI Act requires and that ECOA adverse action documentation demands.

How Openlayer supports fair lending bias testing and audit evidence

Openlayer is a unified evaluation, observability, and governance platform, making it a practical fit for fair lending AI compliance workflows where bias testing alone is not sufficient. Teams need repeatable test execution, documented results, and audit trails that survive regulatory examination. Here is how that works in practice.

Bias testing across protected classes

Openlayer runs disaggregated performance testing across all ECOA and HMDA protected classes automatically. For a credit scoring model, that means computing approval rate disparities, false positive rates, and false negative rates broken out by race, national origin, sex, age, and familial status within the same evaluation pipeline.

The demographic parity check flags when any group's approval rate falls below 80% of the highest-performing group's rate, the four-fifths threshold the EEOC's adverse impact doctrine requires. Equal opportunity checks confirm that qualified applicants across groups receive approval at statistically equivalent rates: P(Ŷ=1 | Y=1, A=0) = P(Ŷ=1 | Y=1, A=1). When a gap exceeds 5 percentage points, the test fails automatically and blocks promotion (example thresholds; calibrate to your institution's risk appetite and the applicable regulatory floor).

These are not one-time evaluations. Openlayer runs the same test suite on every model version, so when a retrain moves demographic parity in either direction, the delta is recorded against the previous version with a timestamp and a named approver.

Audit evidence that holds up

The output of each evaluation run is not a dashboard screenshot. It is a structured record containing:

• The exact model version hash and dataset snapshot used in the test
• Metric scores by protected class with the threshold that triggered pass or fail
• The timestamp, the evaluator configuration, and the name of the approver who cleared or flagged the result
• A complete input/output log sufficient to reconstruct any individual inference in the batch

That record maps directly to what CFPB examiners and DOJ investigators request during a fair lending examination: evidence that the institution tested for disparate impact, documented the results, and acted on findings before deployment. The audit trail is the artifact, not a byproduct.

Continuous monitoring after deployment

Demographic parity does not stay fixed after a model ships. Feature distribution shift, population mix changes, or upstream data pipeline changes can widen disparate impact gaps without any change to the model weights. Openlayer monitors approval rate ratios by protected class in production on a configurable cadence. When the gap between any protected group and the highest-performing group exceeds the configured threshold, an alert fires to the named model owner and governance lead.

That alerting is observation. The enforcement layer sits at the deployment gate: if a scheduled re-evaluation fails the four-fifths check, promotion to production is blocked until a named reviewer clears the finding and documents the resolution. That blocking step is what separates enforcement from observation, and it is what regulators look for when they ask whether the institution had controls in place, beyond policies alone.

Connecting test results to regulatory obligations

Credo AI and IBM watsonx.governance both produce governance documentation, policy frameworks, and risk registers. What they do not do is execute bias tests at inference time, generate the structured metric records those policy documents reference, or block deployment when a fairness threshold is breached. The documentation those tools produce points to evidence that has to exist somewhere else. Openlayer is where that evidence is created, versioned, and exported in audit-ready form.

For institutions subject to the EU AI Act's Article 10 data governance and Article 15 accuracy and robustness requirements, Openlayer's unified evaluation, observability, and governance platform supplies the evaluation records the technical documentation Annex IV requires. For ECOA and Regulation B compliance, the same records satisfy the adverse impact analysis documentation that a CFPB examination will request. The evaluation runs once; the record satisfies multiple regulatory frameworks simultaneously.

Final thoughts on fair lending AI compliance

Fair lending AI compliance comes down to one question examiners will ask: can you show a continuous, traceable record from model training through every live decision? Logging metrics is observation. Blocking deployment when a demographic parity gap exceeds your configured threshold is enforcement. Getting that distinction right, and documented, is what separates institutions that pass examinations from those that contest findings without the evidence to back them up. If you want to see how your current bias testing and monitoring setup maps to what examiners actually request, contact the Openlayer team.

FAQ

What's the difference between Credo AI and Openlayer for fair lending AI compliance documentation?

Credo AI produces policy attestation records and maps model attributes to regulatory frameworks, but it does not execute bias tests, generate structured metric records, or block deployment when a fairness threshold is breached. Openlayer generates the underlying evidence those policy documents reference: pass/fail records by protected class, model version hashes, dataset snapshots, and timestamped audit trails that CFPB examiners and DOJ investigators request directly.

How do I build an audit trail that satisfies both EU AI Act Article 12 and ECOA adverse impact documentation requirements?

Each evaluation run in Openlayer writes a structured record containing the exact model version hash, the dataset snapshot used, metric scores by protected class against the configured threshold, the evaluator configuration, and a named approver. That single record satisfies Article 12's requirement to log sufficient information to reconstruct system behavior after deployment and the ECOA adverse impact analysis documentation a fair lending examination will request, the evaluation runs once and the record maps to both frameworks simultaneously.

How should I structure less discriminatory alternative testing so the search is defensible under CFPB scrutiny?

Run candidate model versions in parallel and log a record for each that captures the feature set, fairness metrics across demographic groups, performance metrics against your business objective, and the reason the candidate was accepted or rejected before deployment. The absence of that record is what makes a model selection indefensible, regulators treat an undocumented LDA search as evidence no genuine search occurred, so the evidentiary artifact is the record of the process, not the outcome alone.

What's the fastest way to set up demographic parity monitoring that blocks inference instead of just alerting on it?

Configure a deployment gate that suspends automated decisioning when any protected group's approval rate falls below 80% of the highest-performing group's rate, the threshold the EEOC's four-fifths rule sets, instead of routing a notification to a reviewer while the model keeps running. The distinction matters during examination: an alert that fires without halting inference is observation; a gate that stops the inference path until a named owner clears the flag is enforcement, and examiners reviewing a fair lending program will ask which one is actually in place.

What does a post-deployment fair lending incident record need to contain to close the audit gap?

Each incident record must carry four elements as discrete structured fields: the severity tier with explicit system status decision (suspend, enhanced monitoring, or continue), the notification action taken with named recipients and timestamps, the root cause classification assigned to exactly one category (data drift, labeling error, or deployment configuration issue), and the remediation steps with a named owner and resolution deadline. If an incident spans multiple categories, assign the primary driver; document secondary causes in the narrative field. A record missing any of these elements is an open audit gap, examiners reviewing incident response will treat an incomplete record the same way they treat a missing control.