Credit Decisioning AI Audit: What US Examiners Expect

A credit decisioning AI audit tests whether a lender can show, with records rather than assertions, that an automated or AI-assisted credit model is sound, fair, explainable and overseen by people who can challenge it. In the United States there is no single audit standard. The expectation is assembled from fair-lending law (ECOA and Regulation B), the Fair Credit Reporting Act (FCRA), and supervisory model-risk guidance, applied in proportion to the model's risk. This guide sets out what the audit covers, how to test it, and which evidence to keep.

TL;DR

• An audit of AI credit decisioning examines the full model lifecycle: materiality, data, explainability, performance, human oversight, cyber and ICT risk, and third-party dependencies.
• ECOA and Regulation B apply regardless of model complexity. Adverse-action reasons must be specific and accurate, and a complex model is no excuse for vague ones.
• Validation must independently challenge assumptions, inputs and outcomes, and monitoring needs documented metrics, thresholds and alerts.
• Fair-lending testing should cover disparate treatment, disparate impact and a documented search for less discriminatory alternatives.
• Evidence matters as much as controls: documentation must be detailed enough for a qualified third party to operate and maintain the model.

Table of Contents

• What an AI credit decisioning audit covers
• The US legal and supervisory baseline
• Validating the model, its data and its performance
• Testing for discrimination and fair-lending risk
• Explaining denials and other adverse actions
• Human oversight, change control and vendor models
• Records that prove oversight
• Our perspective
• Preparing evidence before the examiner asks
• FAQ
• Sources

What an AI credit decisioning audit covers

The audit starts with a question of scope: which models influence a credit decision, and how heavily? That includes scorecards, machine-learning underwriting models, limit-setting and pricing models, fraud screens that can decline an applicant, and increasingly AI agents that assemble or summarize an application file before a human or a rules engine decides.

The Financial Stability Board's sound practices, finalized on October 15, 2026, give a useful lifecycle structure. They recommend materiality assessment, data governance, explainability or compensating controls, performance evaluation, human oversight, cyber and ICT risk management, and management of third-party dependencies. Those seven areas make a workable audit program for a credit model.

Proportionality sets the depth

There is no universal checklist. The OCC's revised model risk guidance, issued April 17, 2026, says audit and oversight depth should track the institution's risk profile and the significance and complexity of the model. The OCC also states the guidance is not enforceable or prescriptive and that generative and agentic AI fall outside its current scope, although it may still be relevant to smaller banks with significant model-risk exposure.

That last point matters to anyone deploying agents in credit operations. Agentic systems sit outside the OCC's current scope, but ECOA, Regulation B and FCRA apply to the decision regardless of the technology that produced it. An audit should therefore treat agents as in scope under the law even where supervisory model guidance is silent.

When an audit is needed

Trigger an audit, or an out-of-cycle review, in these situations:

1. A new model or agent enters the credit workflow, or an existing one is retrained or given new data sources.
2. Monitoring shows drift, a threshold breach or an unexplained shift in approval rates for a group.
3. A vendor changes a model that you rely on but did not build.
4. A regulator, bank partner or internal audit function asks for evidence of oversight.
5. Complaint patterns suggest adverse-action notices do not match what the model actually used.

The US legal and supervisory baseline

Three layers apply, and the audit should map each control to one of them.

Fair lending: ECOA and Regulation B. The CFPB's April 17, 2024 circular, published in the Federal Register, restates that ECOA and Regulation B prohibit discrimination in credit transactions on listed bases, including race, color, religion, national origin, sex (including sexual orientation and gender identity), marital status, age (subject to capacity to contract), receipt of public-assistance income, and good-faith exercise of Consumer Credit Protection Act rights. The CFPB said in an August 2024 AI comment that ECOA applies regardless of technology or model complexity, and that it will review fair-lending testing of complex models.

Adverse action: ECOA and FCRA. Creditors must give specific reasons for a denial. FCRA adds separate disclosures when adverse action rests on a consumer report and a credit score was used. Both are covered in detail below.

Model risk guidance. The OCC's 2026 guidance, and the FHFA's advisory bulletins for entities it supervises, set expectations for development, validation, monitoring, governance and vendor models. They are the best available benchmark for how an examiner will judge your controls, even where your institution is not directly bound by a given bulletin.

Validating the model, its data and its performance

Validation is the core technical workstream. The OCC's bulletin says validation should address conceptual soundness and outcomes analysis, while monitoring and governance should define policies, roles and responsibilities. The FHFA's supplemental guidance in AB 2022-03 is more granular about method: auditors should independently challenge assumptions, mathematical formulas and inputs, document reviews and outcomes in a validation report, monitor performance against documented metrics, thresholds and alerts, and track remediation of findings.

A practical validation test plan

Drift deserves its own test. A model that was sound at approval can degrade as applicant mix changes, so the audit should confirm that drift metrics exist, that thresholds were set before the fact, and that breaches produced documented decisions. Our note on audit packs for model drift risk covers how to produce that evidence on demand.

Sampling decisions

Beyond model-level testing, auditors usually sample individual decisions to check that the system behaved as documented: that the right inputs were used, that the right reason codes were generated and that any human override was recorded. A defensible approach to audit sampling for AI decisions should define the population, the sampling method and the stratification before the sample is drawn, so the result stands up to challenge.

Testing for discrimination and fair-lending risk

Accuracy is not a fair-lending defense. The FHFA warns that AI and machine-learning underwriting can create consumer-protection and fair-lending risk through inadequate explainability, output interpretability and decision controls.

The CFPB's position in its AI comment is that firms should regularly test models for disparate treatment and disparate impact, and should search for and implement less discriminatory alternatives, using manual or automated techniques. An audit should therefore check four things:

1. Disparate treatment testing. Are prohibited bases, or close proxies, excluded from inputs, and is that verified rather than assumed?
2. Disparate impact testing. Are approval rates, pricing and terms compared across protected groups, and are the results documented with the method used?
3. Less discriminatory alternative search. When a disparity is found, is there a record that alternative model specifications were evaluated, and why the chosen one was kept or replaced?
4. Frequency. Is testing repeated after retraining, not run once at launch?

What a credible test looks like

The CFPB's 2019 update on its first no-action letter is still an instructive template. It described comparing a machine-learning underwriting model with a traditional model, independently validating the traditional model for fair lending, and evaluating credit access, pricing and disparities by race, ethnicity, sex and age.

A September 10, 2026 peer-reviewed study in Emerald proposes combining predictive-performance metrics with disparate-impact and demographic-parity measures and interpretability analysis. In its dataset experiment, the model showed dependence on age and property-ownership features. The lesson for practitioners is that performance, fairness and explainability should be assessed together; a single accuracy figure cannot carry the audit.

Explaining denials and other adverse actions

Explainability is where AI credit models most often meet the law. The rules are plain, even if the models are not.

• Reasons must be specific and accurate. The CFPB's circular states that reasons must identify the principal factors actually considered or scored. Overly broad or vague explanations are noncompliant, and an inaccurate checklist substitute does not cure that.
• Complexity is not a defense. For complex models, the creditor must still disclose the actual reasons, even when their relationship to creditworthiness is not obvious.
• FCRA is a separate layer. If adverse action is based in whole or in part on a consumer report and a credit score was used, the creditor must disclose the score and the key factors that adversely affected it. The CFPB's innovation spotlight explains that these disclosures include the consumer reporting agency's contact information.
• Supervisors are watching. The CFPB's Winter 2025 supervisory highlights on advanced technologies stress that creditors must accurately identify specific reasons and cannot justify noncompliance by citing the technology used.

Audit procedure for adverse-action notices

Pull a sample of denials and trace each one backwards: the notice, the reason codes, the model's actual feature contributions, and the input data. The test is whether the reasons given match what drove the score for that applicant. If reason codes come from a static mapping that was never reconciled to the model's behavior, expect a finding. Where an applicant's file was summarized by an AI agent, confirm the summary's contribution is itself traceable.

Human oversight, change control and vendor models

Controls fail at the boundaries: between development and validation, between the lender and its vendor, and between the model and the person who can override it.

Effective challenge

The FHFA defines effective challenge in AB 2022-03 as critical analysis by independent, informed personnel who can identify limitations, evaluate assumptions and recommend changes. It calls for separation from development and for documentation of the challenge process, the resulting changes and the rationale. An auditor should ask three questions. Are the challengers qualified? Are they organizationally separate from model builders? Does senior management support and act on their findings?

Vendor and third-party models

Buying a model does not transfer accountability. Under the same bulletin, the institution's validation group remains accountable for the quality, recommendations and opinions of any vendor validation. The OCC's April 2026 announcement describes the revised guidance as risk-based and tailored to size, complexity and model use, and notes that it covers vendor and other third-party products. In practice, audit whether you hold enough vendor documentation to validate the model, whether change notifications are contractually required, and whether you can detect a silent model update. Our 30/90/180-day plan for third-party AI sets out how to stage that work.

Lifecycle accountability

The FSB's emphasis is that governance continues from use-case approval through deployment, monitoring, human oversight and third-party dependency management. For the auditor, that means checking that approvals, overrides and retirements are logged, and that a named owner exists for each model in production. A structured AI governance framework with evidence by design helps assign those owners and functions.

Records that prove oversight

An audit that cannot be evidenced did not happen. The FHFA's guidance in AB 2022-03 is the clearest list of what to retain:

1. Model documentation detailed enough for a qualified third party to operate and maintain each model use.
2. Significant limitations, their root causes and mitigation strategies, communicated to model users. Limitations may arise from assumptions, uncertainties and restrictions on appropriate use.
3. Validation reviews and outcomes, documented in a validation report.
4. Performance-tracking metrics and thresholds, with the alerts that fired.
5. Findings and remediation, tracked to closure.
6. The effective-challenge record: the process, the changes it produced and the rationale.

Two design principles make this evidence more defensible. First, it should be produced from system metadata rather than copied from customer files, which keeps privacy exposure low; see how to prove data minimization without raw data. Second, logs should be structured, time-stamped and complete enough to reconstruct a decision, as described in our guide to AI logging without customer data. Where reporting is automated, confirm what evidence regulators accept before relying on it.

Our perspective

Most credit AI audits we see described fail at the same point: the controls exist, but the proof is reconstructed after the examiner asks. We build around the opposite assumption. Governance evidence should be a by-product of how the system is observed, not a project assembled in the weeks before a review.

For firms deploying AI agents near credit decisions, that starts with knowing which agents exist. An inventory and identity graph, built from OAuth metadata alone, shows which agents hold which grants, and where risk concentrates, including financial blast-radius exposure. It touches no customer data and requires no software inside production systems. Evidence generated from it should be deterministic and signed, so an auditor can verify it offline and get the same answer twice.

We would also stress a limit. Metadata-based governance does not replace model validation, fair-lending testing or adverse-action review. It answers a different question: can you prove who and what was operating, under which permissions, and that oversight took place? That is the question regulators ask first, and the one most firms answer least well.

— Eleye

Preparing evidence before the examiner asks

For firms using AI agents in lending operations, AETHER Pulse provides a read-only governance layer: an agent inventory, identity graph, risk concentration mapping and signed evidence packs generated from metadata only. Details of the plans, including the Article 26 readiness audit, are on the pricing page, and the evidence infrastructure overview shows how the packs are produced.

If you want to see how deterministic controls support an audit trail, our guide to building deterministic controls for AI is a good next step.

FAQ

Is there a single US standard for auditing AI credit decisioning?

No. Expectations come from ECOA and Regulation B, FCRA, and supervisory model-risk guidance such as the OCC's 2026 revision. The OCC states that depth should be proportionate to the institution's risk profile and the model's significance and complexity, so the audit should be scoped accordingly.

Can we use a complex model if we cannot explain it simply?

You can use it, but you must still give specific, accurate adverse-action reasons. The CFPB has said that model complexity does not excuse noncompliance, and that creditors must disclose the actual reasons for a denial even when their link to creditworthiness is not obvious.

How often should fair-lending testing be repeated?

The CFPB's stated expectation is regular testing for disparate treatment and disparate impact, together with a search for less discriminatory alternatives. Sound practice is to repeat it after any retraining, data change or vendor update, and to keep the results and method on file.

Who is accountable when a vendor supplies the credit model?

The lender. Under FHFA guidance, the institution's validation group remains accountable for the quality of vendor validation, its recommendations and its opinions. Contract terms, documentation access and change notifications should support that accountability.

Sources

• FSB finalises sound practices for the responsible adoption of AI
• OCC Bulletin 2026-13: Model Risk Management, Revised Guidance
• OCC news release: Updated Model Risk Management Guidance
• Federal Register, Volume 89, Issue 75 (April 17, 2024)
• FHFA AB 2022-03: Supplemental Guidance on Model Risk Management
• FHFA AB 2022-02
• CFPB comment on uses, opportunities and risks of AI in financial services
• CFPB: An update on credit access and the Bureau's first No-Action Letter
• Algorithmic auditing of AI credit scoring (Emerald)
• CFPB: Providing adverse action notices when using AI/ML models
• CFPB Supervisory Highlights: Advanced Technologies Special Edition, Issue 38

Recommended

• Privacy Preserving AI Agent Audits for Compliance: No Customer Data
• Segregation of Duties for AI: Audit Ready ADEL for Compliance Teams
• Build Audit Ready Deterministic Controls for AI in Regulated Finance
• Audit Sampling for AI Decisions: A Defensible Approach