At a fair-lending examination in late 2025, a large community bank's chief compliance officer was asked by the lead examiner to explain how the bank's AI underwriting model handled "disparate impact." The compliance officer paused and then said the model "was designed to be fair." The examiner set down her pen. Over the next two hours, she walked the compliance officer through the difference between disparate treatment (intentional discrimination based on a protected characteristic) and disparate impact (neutral-looking practices that produce discriminatory outcomes), asked about the bank's less-discriminatory-alternative search (documentation that the bank had considered and rejected fairer model alternatives), and inquired about the adverse-action reason generation process, the model risk management documentation, and the proxy variable analysis for the ZIP code input. The compliance officer could not answer any of these questions with specificity. The examination resulted in a matter requiring attention (MRA) that consumed six months of remediation work and a new model validation project. The entire situation turned on vocabulary. The compliance officer knew the bank was "doing AI." She did not know the language that regulators use to evaluate whether the bank is doing AI lawfully. This lesson gives you that language, defined in the terms of a credit file and a fair-lending exam rather than a data-science lecture.

The Vocabulary That Separates Defensible AI from Expensive AI

Every field develops specialized vocabulary for a reason: precise terms allow practitioners to communicate complex concepts without lengthy explanations, and they signal to regulators and counterparties that the user understands the domain well enough to operate in it responsibly. In AI-assisted lending, the vocabulary is the compliance infrastructure. A banker who can use terms like "disparate impact," "proxy variable," "adverse action," "model risk," and "explainability" correctly and confidently is a banker who can participate in examination conversations, evaluate vendor claims, challenge model outputs that do not make sense, and design workflows that will survive regulatory scrutiny. A banker who cannot use these terms is at the mercy of vendors who do, and vendors have interests that do not always align with the bank's compliance posture.

This lesson covers twelve terms organized into four groups: the fair-lending vocabulary (the terms that describe how lending decisions can harm protected classes), the credit-decision vocabulary (the terms that describe how AI influences whether a borrower gets credit and on what terms), the model-risk vocabulary (the terms that describe how banks govern, document, and validate their AI models), and the generative-AI vocabulary (the terms that describe how large language models produce and sometimes fabricate content). Each term is defined in the context of how an examiner, a credit officer, or a compliance professional uses it, not in the abstract language of academic AI research.

The Fair-Lending Vocabulary

Fair-lending terms are the highest-stakes vocabulary in AI-assisted lending because they connect the technical characteristics of a model to legal liability. Getting these definitions right is the difference between explaining your AI to an examiner and explaining it to a consent-order negotiating team.

Disparate Impact

Disparate impact is the legal doctrine under which a lending practice that is neutral on its face and does not involve intentional discrimination can still violate fair-lending law if it produces significantly different outcomes for members of protected classes. The protected classes in lending are defined by the Equal Credit Opportunity Act (ECOA, which prohibits credit discrimination on the basis of race, color, religion, national origin, sex, marital status, age, or receipt of public assistance) and the Fair Housing Act (FHA, which adds familial status and disability for housing-related credit).

In an AI context, disparate impact is the primary fair-lending risk because AI models can produce discriminatory outcomes without using protected characteristics as inputs. A scoring model that uses ZIP code, grocery-store brand loyalty, or social media activity as inputs may produce lower scores for applicants who are disproportionately from protected classes, not because the model "intended" to discriminate, but because those inputs are statistically correlated with protected characteristics in the model's training data. The model has learned a proxy for the protected characteristic, and the outcome is discriminatory regardless of intent.

The legal standard for a disparate-impact claim (established in Supreme Court case law and the CFPB's fair-lending guidance) involves three steps. The plaintiff (or examiner) demonstrates a statistically significant disparity in outcomes across protected classes. The creditor must then demonstrate a "business necessity" for the practice that causes the disparity. If the creditor does that, the plaintiff may still prevail by showing there is a "less-discriminatory alternative" (a practice that achieves the same business purpose with less discriminatory impact) that the creditor failed to adopt. Documented testing for disparate impact and a documented search for less-discriminatory alternatives are the bank's defenses, and OCC Bulletin 2026-13 expects them to be present in the model-risk file for every model used in a credit decision.

Disparate Treatment

Disparate treatment is the other form of prohibited discrimination, and it is easier to understand: treating a credit applicant differently because of a protected characteristic, whether that treatment is explicit or implicit. An AI model is unlikely to engage in explicit disparate treatment (banks do not typically encode race as a model input), but implicit disparate treatment can occur when a model is trained on historical data reflecting past discriminatory practices. If the historical lending data shows that applicants from certain neighborhoods were systematically denied credit at higher rates due to past redlining, a model trained on that data will learn to deny applicants from those neighborhoods at higher rates, not because it is using race, but because the historical outcome data contains the imprint of prior discrimination. This is sometimes called feedback loop amplification and is a recognized risk under OCC Bulletin 2026-13.

Proxy Variable

A proxy variable is a model input that is not a protected characteristic but is statistically correlated with one, such that using it in a model effectively uses the protected characteristic indirectly. ZIP code is the canonical example in consumer lending: in many U.S. markets, ZIP codes are highly correlated with racial composition due to historical residential segregation patterns. A model that uses ZIP code as an input may effectively be using race as an input through that correlation. Other commonly identified proxy variables in lending models include grocery store chain preferences (correlated with income and race in some markets), payment of certain utility types (correlated with geography and race), certain types of employment (correlated with national origin), and certain categories of debt (correlated with age and income). The bank's obligation under fair-lending law is not merely to exclude protected characteristics from model inputs; it is to evaluate whether the inputs used are serving as proxies for protected characteristics in the population being scored.

Less-Discriminatory Alternative (LDA)

A less-discriminatory alternative is a model, practice, or policy that achieves the same or comparable business objective (credit risk prediction, income verification, document processing) with meaningfully less discriminatory impact on protected classes. Under the disparate-impact framework, a creditor who identifies a disparity in model outcomes has a legal obligation to search for and, if found, adopt a less-discriminatory alternative. The search itself must be documented even when no viable alternative is found. A bank that identifies a disparate-impact problem in its scoring model but cannot demonstrate it searched for a less-discriminatory alternative has an incomplete defense. The documented search is the defense. Under OCC Bulletin 2026-13, the LDA search and documentation belong in the model-risk file.

The Credit-Decision Vocabulary

Credit-decision terms describe the legal framework within which every AI-touched decision must operate. These are the terms that appear most frequently in examination findings related to AI.

Adverse Action

Adverse action, as defined by ECOA and Regulation B (the Federal Reserve's implementing regulation for ECOA, governing credit applications, adverse-action notices, and record retention), is a denial of credit, a revocation of credit, a change in the terms of credit that is unfavorable to the applicant, or a refusal to grant credit in substantially the amount or on the terms requested. The significance of the term for AI purposes is in the obligations it triggers. When an adverse action occurs, the creditor must notify the applicant within 30 days of a completed application, provide the specific principal reasons for the action, and include the name and contact information of the applicant's consumer reporting agency if the action was based on information from a credit report. The reasons must be specific and accurate.

The specific-and-accurate standard is where AI creates the most liability. "Insufficient score" satisfies the specific-and-accurate requirement only if the model's score was actually the operative reason for the denial and the score is explainable in terms the borrower can understand and, if necessary, challenge. A vague reference to model output ("your application did not meet our risk criteria") does not satisfy the requirement. A reason that was generated by a large language model from general patterns rather than from the actual file does not satisfy the requirement. An examiner reviewing adverse-action notices is comparing stated reasons to underwriting notes. If they do not match, the finding is a Regulation B violation.

Explainability

Explainability in AI lending refers to the capacity of a model to generate an intelligible explanation of why it produced a specific output for a specific applicant. A fully explainable model can say, for applicant A: "The three factors that most negatively affected this application's score were the 42-percent debt-to-income ratio, the two 30-day late payments in the past 12 months, and the loan-to-value ratio of 92 percent." An unexplainable model can say only "the score for applicant A was 614." The unexplainable model is a legal liability in lending, not a technical inconvenience, because a denial based on an unexplainable score cannot satisfy the Regulation B specific-reasons requirement without additional mechanism to translate the score into factors.

Explainability exists on a spectrum. Traditional linear scorecards are fully explainable: each factor and weight is documented, and the adverse-action reason generation is deterministic. Logistic regression models are highly explainable. Gradient-boosted tree models can be made explainable using post-hoc interpretation techniques such as SHAP (SHapley Additive exPlanations, a method for assigning each input variable a contribution score for a specific prediction) or LIME (Local Interpretable Model-agnostic Explanations). Deep learning models and complex neural networks are generally less explainable without significant additional methodology. OCC Bulletin 2026-13's model-risk framework expects that the level of explanation capability is documented and appropriate for the model's use in credit decisions.

Adverse-Action Reason Code

An adverse-action reason code is a specific statement of a principal reason for an adverse action on a credit application. The reasons must be stated in clear, understandable language, must be the actual principal reasons (not a summary, not a vague reference to model output, and not a list of every possible factor), and must be grounded in the applicant's actual file. The Regulation B appendix provides sample reasons that satisfy the specific-and-accurate standard; these include items like "income insufficient for amount of credit requested," "insufficient number of credit references provided," and "proportion of balances to credit limits on revolving accounts too high." AI-generated reason codes that do not match the actual underwriting rationale for this specific applicant are a Regulation B violation even if they match the sample reasons in the appendix, because they are accurate to the template but not to the file.

The Model Risk Vocabulary

Model risk terms describe the governance framework that banks are required to maintain for their AI systems under OCC Bulletin 2026-13 and the broader regulatory framework. These terms come up most frequently in model-risk examinations and in board-level discussions about AI governance.

Model Risk

Model risk is the risk of adverse outcomes resulting from decisions based on incorrect or misused models. In banking, this includes both the risk that a model produces wrong outputs (model error) and the risk that a model's outputs are used in ways that were not intended or validated (model misuse). OCC Bulletin 2026-13 defines model risk broadly enough to include AI and generative AI tools used in credit decisions, document processing, and compliance communications. A bank that uses an AI vendor's platform in a credit decision without documenting the platform as a model, validating its performance, and establishing ongoing monitoring is accepting model risk without managing it, which is itself a model-risk violation under OCC 2026-13.

Model Validation

Model validation is the independent assessment of a model's performance, methodology, and fitness for the intended use. Under OCC Bulletin 2026-13, every model used in a credit decision must be validated before deployment and re-validated when the model, its inputs, or its operating environment change materially. Validation for a scoring model includes: (1) conceptual soundness review (does the model methodology make sense for the intended use?), (2) outcomes analysis (does the model produce accurate predictions on out-of-sample data?), (3) ongoing monitoring review (is performance being tracked and reported appropriately?), and (4) protected-class outcome analysis (do outcomes differ significantly across protected classes, and if so, has the LDA search been documented?). A vendor-provided model is not exempt from validation requirements. The bank is responsible for validating every model it uses, including models whose underlying code it cannot inspect.

Model Inventory

A model inventory is a complete, current catalog of all models used by the bank, including their purpose, their inputs and outputs, their validation status, their ongoing monitoring results, and their business owners. OCC Bulletin 2026-13 expects banks to maintain a model inventory that covers AI and generative AI tools deployed in any decision-relevant context. A bank that purchased an AI lending platform and recorded it in the accounts-payable system as a software vendor without adding it to the model inventory has a model-inventory gap that will appear in the examination findings. The model inventory is the starting point for every model-risk examination and the document that demonstrates the bank knows what AI it is running.

Champion-Challenger

Champion-challenger is a model deployment methodology in which the current production model (the champion) is continuously tested against one or more candidate replacement models (challengers) on real application data, with the challenger model receiving a defined percentage of new applications (often 10 to 20 percent) and its performance compared to the champion on identical data. This methodology allows a bank to empirically test whether a new model (including a less-discriminatory alternative to a model with an identified disparate-impact problem) performs better before committing to a full deployment. Under OCC Bulletin 2026-13, champion-challenger is a recognized approach to ongoing model performance monitoring and to the LDA search documentation that fair-lending compliance requires.

The Generative AI Vocabulary

Generative AI terms describe the specific ways large language models work and fail. These are the terms needed to evaluate whether a GenAI tool is being used responsibly in a lending context.

Hallucination

Hallucination is the term used for the phenomenon in which a generative AI model produces text that is fluent and confident but factually incorrect or entirely invented. In a lending context, hallucinations include: invented covenant terms in commercial credit memos, fabricated income figures in loan file summaries, wrong adverse-action reasons in denial notices, and outdated regulatory citations in compliance documents. Hallucination is not a bug that will be fixed in the next model version. It is a structural consequence of how large language models work: they generate statistically plausible text, and "statistically plausible" and "factually accurate" are different standards. The only reliable control for hallucination in regulated lending documents is human verification before use.

Grounding and Retrieval-Augmented Generation

Grounding is the practice of providing a generative model with the actual source material it should draw on before generating output. Retrieval-augmented generation (RAG) is the automated implementation of grounding: a RAG system retrieves relevant documents from a database (the actual paystub, the actual credit policy section, the actual regulatory text) and includes them in the model's context before generation. A grounded generative model summarizing a borrower's income has the actual paystub in context; an ungrounded model generates what income statements for that type of borrower usually look like. Grounding substantially reduces hallucination in the retrieved domain. A bank evaluating any AI tool that drafts lending documents should ask whether the system is grounded on the actual file data or generating from general patterns, and should treat the answer as a key risk factor in the model-risk assessment.

Prompt

A prompt is the input to a generative AI model: the instruction, question, or context given to the model before it generates a response. In a lending context, prompt design is an operational skill with compliance implications. A well-designed prompt for an adverse-action notice might include: the borrower's actual file data, the bank's credit policy, the applicable Regulation B adverse-action reason codes, and a specific instruction to "state only reasons that are supported by the borrower's actual file and the bank's underwriting rationale for this specific application." A poorly designed prompt might simply ask the model to "write an adverse-action notice for a declined mortgage application." The second prompt will produce a plausible-sounding notice with a high probability of hallucinated reasons. The first prompt will produce a more grounded draft with a lower probability, though verification is still required because even a grounded model can misread or misweight the information provided.

Putting the Vocabulary to Work

These twelve terms are not abstract definitions. They are operational tools that change how a banker interacts with AI vendors, credit committees, compliance teams, and examiners. Consider how the vocabulary changes three practical conversations.

The vendor evaluation conversation. A vendor says their scoring model "is designed to be fair and uses only credit-relevant inputs." A banker who knows the vocabulary asks: "Have you tested for disparate impact across protected classes in the full application population? Is there documentation of the less-discriminatory-alternative search in your model validation report? Can the model generate adverse-action reason codes tied to individual applicants' actual factors rather than generic templates? Is your model in our model inventory as a model or as a software vendor?" The vendor's answers to these questions are the entire difference between a model-risk defensible procurement and an examination finding waiting to happen.

The credit committee conversation. An underwriter presents a decline recommendation with an AI-generated adverse-action notice citing "high debt obligations relative to income." A banker who knows the vocabulary asks: "Were those the actual operative factors for this specific applicant, or did the AI generate the most common adverse-action reasons for this loan type? Do the stated reasons match the underwriting notes? If the applicant challenges this decision, can we trace the stated reason to the actual file data?" If the answer to any of these is uncertain, the adverse-action notice needs to be verified before it goes out.

The examination conversation. An examiner asks about the bank's approach to disparate impact in its AI scoring model. A banker who knows the vocabulary says: "We conduct quarterly disparate-impact testing across all protected classes in the full application population, including approvals and denials. We use the 80-percent rule and a regression analysis for statistical significance. We have conducted and documented a less-discriminatory-alternative search in the model-risk file. Our adverse-action reason generation is tied to individual SHAP values for each applicant rather than template-based. I can pull the model validation report and the most recent disparate-impact test summary." That answer ends the disparate-impact inquiry. Its absence extends it.

Key Takeaways

• Disparate impact is the primary fair-lending risk in AI lending: a model that does not use protected characteristics as inputs can still produce discriminatory outcomes through proxy variables (inputs correlated with protected characteristics). The bank's defense is documented testing for disparate impact and a documented search for less-discriminatory alternatives, both required under OCC Bulletin 2026-13.
• A proxy variable is a model input that correlates with a protected characteristic, such as ZIP code correlating with race. Using a proxy variable is not a defense against a disparate-impact finding. The bank must evaluate whether its model inputs are serving as proxies and document that analysis.
• Adverse action under ECOA and Regulation B triggers specific obligations: notice within 30 days, specific and accurate principal reasons, and (if based on credit-report information) identification of the consumer reporting agency. "Specific" and "accurate" are both required; a specific but inaccurate reason is a Regulation B violation.
• Explainability is a legal requirement in lending, not a feature preference. A model that cannot generate specific reasons tied to the individual applicant's actual factors cannot produce compliant adverse-action notices. The level of explainability capability must be documented in the model-risk file under OCC Bulletin 2026-13.
• Model validation is the bank's responsibility, including for vendor-supplied models. OCC Bulletin 2026-13 requires conceptual soundness review, outcomes analysis, ongoing monitoring, and protected-class outcome analysis for every model in a credit decision. The model inventory is the governance starting point.
• Hallucination in generative AI is structural, not a version-specific bug: large language models generate statistically plausible text whether or not it is factually accurate. In lending, every AI-drafted adverse-action reason, covenant term, income figure, and regulatory citation must be verified against the actual source before use. Grounding and RAG substantially reduce (but do not eliminate) hallucination risk.
• The compliance officer who can use these twelve terms correctly in an examination conversation is the compliance officer who ends a fair-lending inquiry quickly. The examination from the opening of this lesson turned on vocabulary. The right vocabulary is available to every banker who reads this lesson and uses it.