AI Model Explainability Requirements for US Banks: Adverse Action, ECOA, and the SR 26-2 Gap

AI model explainability for US banks is the set of technical and governance controls that ensure every AI system touching a credit decision, a servicing outcome, or a consumer communication can produce accurate, specific, human-interpretable explanations for its outputs when law or supervisory expectation requires them. The clearest legal hook is ECOA and its implementing Regulation B: a creditor that denies or limits credit must provide the specific principal reasons, and a model’s complexity does not suspend that obligation. SR 26-2, the April 2026 interagency model risk guidance that replaced SR 11-7, explicitly carved generative and agentic AI out of model risk scope, but it did not carve them out of consumer protection law. The explainability gap that carve-out created is one each bank now owns to fill.

This guide is written for the Head of Model Risk, Chief Compliance Officer, and Chief Risk Officer who own that exposure together. It lays out the regulatory hooks that require explainability, the technical architecture for meeting them by model type, and the SR 26-2 gap that leaves generative and agentic AI systems in a governance space where consumer-protection obligations persist without a defined model-risk playbook.

The legal basis for explainability: ECOA and Regulation B

The Equal Credit Opportunity Act and its implementing regulation, Regulation B (12 C.F.R. Part 1002), prohibit discrimination in any aspect of a credit transaction and impose a specific disclosure duty when credit is denied or made less favorable. Regulation B Section 1002.9 requires that a creditor provide a statement of the specific reasons for adverse action. “Specific” is the operative word. A generic statement that the applicant did not meet the institution’s credit standards fails the test. The reasons must reflect the actual factors that drove the decision.

For traditional statistical models, meeting this requirement was operationally straightforward: a scorecard’s top negative factor codes had a direct relationship to the model’s logic. The compliance team and the model worked in the same language. For machine-learning models, the relationship between inputs and outputs is not always legible in that way, and for large language models it can be nearly opaque. The regulatory obligation does not change because the model does.

The CFPB has been explicit on this point since at least its September 2022 circular on adverse action and AI/ML. That circular stated that ECOA and Regulation B do not permit creditors to use black-box models when they cannot provide accurate reasons for adverse action. A lender that deploys a gradient-boosted ensemble, a neural network, or a generative AI system in a credit decision and cannot explain that decision to a denied applicant is not using a novel model type that regulators haven’t gotten to yet: they are violating a statute. The CFPB has continued to reinforce this expectation through 2025 and 2026 as AI deployment in lending has accelerated.

UDAP and its federal financial institution analogue, which prohibit unfair, deceptive, or abusive acts and practices, extend a related obligation to AI systems in servicing, collections, and customer communication. A chatbot or agentic system that produces a consequential outcome for a customer and cannot explain what drove that outcome creates deception exposure independent of any credit decision. The supervisory surface is broader than the adverse-action context alone.

What SR 26-2 changed, and what it did not

SR 26-2, issued jointly by the OCC, Federal Reserve, and FDIC on April 17, 2026, replaced SR 11-7 as the primary interagency model risk management guidance. Its model definition and scope carried forward the SR 11-7 core: a model is a quantitative method, system, or approach that applies statistical, economic, financial, or mathematical theories, techniques, and assumptions to process input data into quantitative estimates. The key addition in SR 26-2 was an explicit carve-out: generative AI and agentic AI were characterized as novel and rapidly evolving and placed outside the guidance’s model risk scope.

The practical effect of that carve-out is that a machine-learning credit model is inside SR 26-2’s model risk discipline, while a generative AI system used in credit communication or document review sits outside it. For the inside-scope models, SR 26-2 preserved and in some places sharpened the explainability expectations carried forward from SR 11-7: conceptual soundness assessment, sensitivity analysis, and outcomes analysis all implicitly require that a validation team can follow the model’s logic. The guidance also preserved the limitation documentation requirement, which includes describing where a model’s behavior is difficult to interpret and what compensating controls address that.

For the outside-scope systems, SR 26-2’s silence does not mean the systems are ungoverned. ECOA, UDAP, and third-party risk obligations apply in full. The gap SR 26-2 created is a framework gap, not a legal one: a bank that leaves its generative AI systems out of its governance program because SR 26-2 does not reach them has misread the carve-out. For a deeper treatment of what governance architecture applies when SR 26-2 does not, the agentic AI governance analysis for banks covers the consumer-protection and third-party risk framework in detail.

What explainability actually requires: a technical architecture

Explainability for regulatory purposes is not the same as explainability for a data scientist. A data scientist wants to understand feature importance in aggregate: which variables drive the model’s predictions most, and how stable is that signal across the training set. Regulators and the consumers they protect want something different: why did this model produce this output for this applicant, in terms that are accurate, specific, and intelligible.

That distinction shapes the technical architecture a bank needs. There are three layers.

Reason-code generation. For any AI model that produces an adverse credit decision, the first layer is a mechanism that maps the model’s outputs to a set of reason codes, each reflecting a specific factor that contributed to the adverse outcome for that applicant. For a logistic regression or scorecard, this is the model’s native logic. For a gradient-boosted model or neural network, it typically requires a post-hoc attribution method, with SHAP (SHapley Additive exPlanations) being the most commonly used in credit risk because it satisfies a set of mathematical fairness properties that regulators have found credible. Whatever method is used, the reason codes must reflect the actual decision drivers, not a plausible-sounding narrative generated independently.

Validation of reason-code accuracy. Generating reason codes is not the same as generating accurate ones. The second layer is an independent review, as part of model validation, that tests whether the reason codes stated actually correspond to the model’s behavior. A reason code that says “high debt-to-income ratio” for an applicant whose debt-to-income ratio was not a material driver for that individual is not a compliant explanation: it is a technically generated output that happens to be wrong. Validation teams need to sample individual-level reason code accuracy, not just confirm that the method is in place.

Audit logging and queryability. The third layer is the infrastructure that makes the explanation retrievable. When an applicant challenges a denial, when a regulator asks, or when a fair-lending examiner wants to verify that the stated reasons were the actual drivers, the bank needs to retrieve the explanation for a specific decision from a specific date. Batch archiving of model outputs and the associated reason-code attribution at the time of decision, stored in a format that is queryable by individual decision record, is what makes the paper trail real.

These three layers apply to every in-scope model under SR 26-2. For generative AI systems that are out of SR 26-2 scope but still affect consumers, the architecture is modified: reason-code generation as traditionally defined may not apply, but a decision-trail log and a human review mechanism that can explain what the system did for a specific customer are the functional equivalents that UDAP and operational risk governance require.

Explainability by model type and regulatory hook

The table below maps model categories to the relevant regulatory hook and the explainability architecture each requires. Treat it as a baseline, not a ceiling: each institution’s risk profile and model inventory will require adjustments.

Two rows deserve additional attention because they are where banks most often underestimate exposure. Gradient-boosted ensembles are the dominant production model type in consumer credit underwriting, and the quality of their SHAP-based reason codes is variable. A SHAP value tells you the contribution of each feature to the deviation from the expected prediction: it is mathematically principled, but it is a local approximation, and in high-dimensional feature spaces the top reason codes for one applicant may not be stable when tested against slightly different input values. Validation that treats reason-code generation as a box to check rather than a discipline to test will miss individual cases where the stated reason is inaccurate.

Large language models used in credit decision support are the growing edge of this exposure. A bank that deploys an LLM to draft declination letters, score document quality, or summarize applicant files is using a generative system whose output influences a credit decision, and ECOA’s obligation travels to wherever the consequential output goes, not to the model type. If the LLM’s summary misstates an applicant’s income and that misstatement drives a denial, the legal exposure is in the denial, not in the character of the model.

The fair lending connection

Explainability and fair lending share the same evidence base, which is one reason the disciplines belong together in a model risk program rather than assigned to separate teams. For the AI fair lending model validation framework, adverse-action explainability is the step that connects disparate-impact testing to the consumer-facing compliance obligation: it is not enough to show that the model’s overall outcomes are not disparate, because a denied applicant is entitled to the specific factors that drove their individual decision regardless of the aggregate.

The practical overlap is in Step 4 of the fair lending validation framework, where reason-code validation sits alongside disparate-impact testing. Banks that run those steps as parallel workflows with separate ownership and separate evidence files miss the integration point. An applicant’s denial reason codes are the unit-level evidence that supports or undermines the aggregate disparate-impact finding: if the reason codes for denied applicants in one protected group systematically reflect different factors than the codes for denied applicants in the comparison group, that pattern is itself a signal of potential disparate treatment that the aggregate metrics alone would not reveal.

The examiner who reviews fair lending at a bank with an AI-based credit model will look at both layers. Aggregate outcome disparity is the screening test; individual-level reason-code accuracy is the substantiation. A program that runs only the first is not ready for the second question.

Governance evidence a supervisory review expects

A supervisory review of AI explainability in a bank credit program is not looking for a description of the method: it is looking for the artifacts that show the method is real, tested, and operating. Six artifacts define an audit-ready explainability posture.

First, an explainability method document per model class: what attribution method is used, why it was selected, what its known limitations are, and how those limitations are compensated. This is a model-specific document, not a generic reference to SHAP.

Second, an adverse-action workflow integration record: documentation showing how the reason codes are generated, reviewed for accuracy, and transmitted to the consumer at the point of decision. This includes the systems that archive the codes and the retention period.

Third, a validation record for reason-code accuracy: not just a description of the method but test results showing that sampled individual-level reason codes reflected actual model drivers. The sampling methodology and pass/fail criteria should be explicit.

Fourth, a decision-trail log: a queryable archive of individual model outputs and their associated reason codes, retained for the period required by record-keeping rules, accessible for regulatory review without manual reconstruction.

Fifth, a vendor-model treatment record for any third-party AI in the credit decision path: documentation showing that the bank validated the vendor’s explainability claims rather than accepting them by contract. A vendor’s SOC 2 report and a contractual assertion that the model is explainable are not the same as a validation finding.

Sixth, a fair-lending integration record: documentation that the reason-code generation is reviewed as part of the fair-lending testing cycle, not in isolation.

These six artifacts are what DSE structures when preparing a bank for examination. DSE prepares organizations to meet that evidence standard; we do not certify and we do not guarantee any exam or audit outcome.

What an explainability gap costs in practice

A bank that cannot produce accurate reason codes for a denied applicant is not primarily at risk of an explainability finding. The primary risk is a fair-lending finding, because the inference from “we could not explain why this applicant was denied” to “we cannot demonstrate the denial was lawful” is short. ECOA enforcement does not require proof of discriminatory intent, and an adverse-action notice that states inaccurate reasons can be evidence in both a regulatory examination and private litigation.

For generative AI systems out of SR 26-2 scope, the comparable risk is a UDAP finding. An agentic system that denies a customer a servicing outcome, makes a payment arrangement, or communicates a consequential decision without a recoverable trail of what drove that outcome creates deception exposure even where no credit decision was involved. The regulatory path is different from ECOA, but the governance requirement, a decision trail that can be retrieved and explained, is structurally the same.

The operational cost of an explainability gap is compounded by the compliance posture it creates for downstream functions. A legal team that cannot explain a model decision cannot respond to a consumer complaint without risk. A compliance function that cannot produce reason-code accuracy evidence cannot respond to a fair-lending inquiry. An internal audit that cannot trace the explanation to the validation report cannot close its own finding. Building explainability into the model architecture from the start is a shorter path than retrofitting it after a supervisory question or a consumer challenge.

How to close the gap: a practical sequence

Closing an explainability gap is a three-quarter program for most banks, not a multi-year rebuild. The sequence that works follows the model inventory.

Start with the credit models already inside SR 26-2 scope, because those carry the clearest legal obligation. For each model, confirm that a reason-code generation method exists, that it has been independently validated for individual-level accuracy, that the reason codes are archived at decision time, and that a fair-lending reviewer has reviewed the method as part of the most recent validation cycle. This is a reconciliation of work that should already exist, and the gaps it reveals are where new work concentrates.

Next, map the generative AI and agentic AI systems that touch a consumer outcome. These are outside SR 26-2 model risk scope, but each one needs a decision-trail log, a scope definition that says what consumer outcomes the system can influence, and a human review capability for any high-stakes output. For LLMs that draft consumer-facing communications, the scope definition answers whether the LLM output goes directly to the consumer or through a human review gate: the answer shapes the explainability obligation.

Then close the vendor gap. For every third-party AI in the credit or servicing path, obtain the vendor’s documentation of their explainability approach and validate it against sampled outputs rather than accepting the documentation at face value. This is an extension of the third-party risk governance a bank already runs under the June 2023 Interagency Guidance on Third-Party Relationships: Risk Management, targeted at the explainability dimension specifically.

Finally, integrate the three evidence streams, the validation record, the fair-lending testing record, and the decision-trail log, into a single file per model that a reviewer can follow end to end. The integration is not a technology project: it is a documentation and ownership discipline.

What this guide is / What it is not

What it is: A practitioner guide to AI model explainability requirements for US banks, covering the ECOA and Regulation B adverse action obligation, the SR 26-2 model risk scope and its generative AI carve-out, the technical explainability architecture for each model type, and the six governance artifacts that constitute an audit-ready posture. It is intended for the Head of Model Risk, Chief Compliance Officer, and Chief Risk Officer who jointly own the fair lending, consumer protection, and model risk exposure that explainability touches.

What it is not: Legal or regulatory advice. DSE prepares organizations for examination and does not certify, and does not guarantee any exam or audit outcome. ECOA compliance and the UDAP prohibition are legal obligations that a qualified attorney should assess in the context of each institution’s specific AI deployment. Nothing in this guide should be read as a determination that any particular model or practice is compliant.

FAQ

What explainability requirements does ECOA impose on banks using AI in credit decisions? ECOA and its implementing Regulation B require that a creditor provide specific, accurate principal reasons when taking adverse action on a credit application. The CFPB has stated clearly that a model’s complexity does not suspend this obligation: a bank using a machine-learning model, a gradient-boosted ensemble, or a large language model in a credit decision must still be able to produce specific, accurate reasons for a denial. A black-box model that cannot support reason-code generation fails the ECOA obligation regardless of its predictive accuracy. The reasons must reflect the actual factors that drove the individual decision, not a plausible narrative generated after the fact.

Does SR 26-2’s generative AI carve-out reduce the explainability obligation for AI chatbots and agents used in banking? No. SR 26-2 (April 17, 2026) excluded generative AI and agentic AI from model risk guidance scope, but that carve-out is a model risk management scope decision, not a reduction in consumer protection obligations. ECOA and Regulation B apply in full to any AI system that influences a credit decision. UDAP and UDAAP prohibitions apply to any AI system that affects a consumer’s financial outcome in a way that could be deceptive or unfair. The carve-out means generative AI systems are not governed under model risk management, but they must still be governed, and the consumer-protection obligations that require explainability travel with the consumer outcome, not with the model type.

What is the right explainability method for machine-learning credit models? For gradient-boosted ensembles and random forests, SHAP is the most widely used post-hoc attribution method in credit risk because it satisfies a set of mathematical properties regulators have found credible. For logistic regressions and scorecards, native factor weights map directly to reason codes. For neural networks, SHAP-based local attribution or LIME can be used, with documented limitations where local attribution is unreliable. Whatever method is used, it must produce individual-level reason codes that reflect the actual drivers of the specific decision, and model validation must test reason-code accuracy at the individual level.

What governance artifacts does a bank need to demonstrate audit-ready explainability? Six artifacts: an explainability method document per model class, an adverse-action workflow integration record, a validation record for reason-code accuracy, a decision-trail log queryable by individual decision record, a vendor-model treatment record for any third-party AI in the decision path, and a fair-lending integration record showing reason-code review is part of the fair-lending testing cycle.

How does AI explainability relate to fair lending examination at a US bank? Aggregate disparate-impact testing tells an examiner whether a model’s outcomes differ across protected groups. Individual-level reason-code accuracy tells the examiner whether denied applicants received explanations that reflect actual decision drivers. A bank that passes aggregate fairness testing but cannot produce accurate individual reason codes has passed the screening test and failed the substantiation test. Reason codes for denied applicants can also reveal disparate-treatment signals that aggregate metrics miss, which is why explainability review belongs inside the fair-lending validation cycle rather than alongside it.

The Bottom Line

AI model explainability for US banks is not a technical preference or a forward-looking regulatory question. It is a current legal obligation under ECOA for every AI system that influences a credit decision, and a consumer-protection obligation under UDAP for AI systems that affect financial outcomes more broadly. SR 26-2’s generative AI carve-out removed those systems from model risk guidance scope but left all of their consumer-protection obligations intact. The gap that carve-out created is a governance gap, not a legal safe harbor.

The practical path to closing it follows the model inventory: start with the credit models inside SR 26-2 scope and confirm that reason-code generation, validation, and archiving are all operating; map the generative and agentic systems that touch consumer outcomes and build decision-trail logging and human review gates for each; close the vendor gap by validating third-party explainability claims rather than accepting contractual assertions; and integrate the evidence into a file that connects the validation record, the fair-lending testing record, and the decision-trail log per model.

That architecture is what turns an explainability claim into an audit-ready posture, and it is what a Banking AI governance engagement is built to deliver. If you want to assess where your current inventory stands against this framework, the AI Governance Checklist covers the evidence fields and validation criteria a finserv program needs to start the inventory.

If you are mapping your AI credit models to the adverse-action explainability obligation and want a structured starting point, the AI Governance Checklist covers the inventory fields and explainability evidence a finserv program needs. When you are ready for a senior team to assess your model portfolio against ECOA’s explainability obligation and build the audit-ready evidence architecture, the Banking AI Governance engagement does exactly that.