In 2025, a community bank on the Gulf Coast purchased an "AI lending platform" from a vendor whose sales deck used the word "AI" fourteen times and never once explained which kind. The bank's chief lending officer signed the contract believing the platform would use AI to read income documents, score applications, and write adverse-action notices. The vendor's platform did all three. But it used three completely different AI models, each with entirely different accuracy profiles, different failure modes, and different regulatory obligations. Nobody at the bank knew this. The first examination after deployment produced three findings: an extraction model that had been misreading biweekly income as monthly on a material share of applications, a scoring model that had never been validated for disparate impact against the bank's lending market, and adverse-action notices drafted by the generative model that, on a significant percentage of denial files, stated reasons that did not match the underwriter's actual notes. In a representative case of this type, total remediation cost runs to six figures in legal fees, reprocessed loans, and regulatory fines, plus the reputational cost of a published examination finding. The bank did not buy bad AI. It bought good AI it did not understand. This lesson closes that gap.

Why Conflating the Three AIs Is an Expensive Mistake

The banking industry in 2026 is living through a period where the word "AI" is doing far too much work. A vendor who says "our AI reads your documents, scores your applications, and writes your compliance communications" is describing three different technologies that happen to share a marketing label. Treating them as interchangeable leads to four concrete failure modes that show up in examination findings and legal claims.

First, technology procurement decisions become incoherent. A bank comparing two vendors on "AI accuracy" without understanding that one vendor's claim refers to extraction accuracy and another's refers to scoring accuracy is comparing apples to regulatory findings. The questions that matter for a scoring model (validation methodology, protected-class outcome testing, adverse-action reason generation) are different from the questions that matter for an extraction model (field-level accuracy on non-standard documents, error-flagging capability, human review workflow) which are different again from the questions that matter for a generative model (grounding on actual file data, hallucination controls, human review before use in regulated communications).

Second, compliance oversight becomes misallocated. A compliance team that treats all AI as a single risk category will apply the wrong controls to each. A generative model used for adverse-action drafting needs a human reviewer who matches the stated reason to the actual decision logic on every file. A scoring model needs disparate-impact testing and ongoing performance monitoring. An extraction model needs field-level accuracy audits and a clear escalation path for low-confidence extractions. These are different control activities, performed at different stages of the workflow, by people with different skills.

Third, vendor accountability discussions collapse. When a problem emerges, a bank that does not understand which AI was involved cannot identify which contractual obligation was breached, cannot ask the right remediation questions, and cannot design the right control change. The remediation story above was made more expensive by the fact that the bank spent two months identifying which of the vendor's AI components had caused which finding.

Fourth, OCC Bulletin 2026-13 compliance becomes impossible without this clarity. The 2026 interagency guidance requires that each model be documented, validated, and subject to ongoing performance monitoring. A bank that treats its lending AI as a single platform has no way to satisfy these requirements for each component. An examiner asking for the validation documentation for the bank's "AI lending platform" needs to see separate documentation for each model type: the extraction model, the scoring model, and the generative model.

Scoring and Classification: How It Works and Where It Breaks

A scoring or classification model takes structured inputs and produces a numerical output (a score) or a categorical label (approve, refer, decline). The inputs are fields with defined values: credit score, debt-to-income (DTI) ratio, loan-to-value (LTV) ratio, months at current employer, years in residence, number of open tradelines, number of derogatory marks. The model has learned, from historical data, which combinations of these inputs are associated with which outcomes (delinquency, default, prepayment). Given a new application's inputs, it predicts a risk score or a decision category.

The primary compliance obligation for scoring models is the adverse-action reason requirement under the Equal Credit Opportunity Act (ECOA, the federal law prohibiting credit discrimination) and Regulation B (the Federal Reserve's implementing regulation). When a scoring model influences a denial, the reasons provided on the adverse-action notice must be the actual factors that drove the model's output for this specific applicant. This requires that the model be interpretable enough to identify which factors were most influential for which applicants, and that the adverse-action reason generation process be tied to the actual model output rather than to a generic template. A model that simply says "insufficient score" without identifying the underlying factors satisfies the letter of some interpretations but not the examiner scrutiny that comes with a fair-lending review.

The second major compliance obligation is disparate impact testing. A scoring model that does not use protected characteristics as inputs can still produce outcomes that disparately affect protected classes if its inputs are proxy variables for those characteristics. ZIP code is the classic example: a model that uses ZIP code as an input, in a market where certain ZIP codes are predominantly non-white neighborhoods, may produce lower scores for applicants from those ZIP codes for reasons that are statistically correlated with race even though race was never a model input. The OCC Bulletin 2026-13 framework requires documented testing for disparate impact and a documented search for less-discriminatory alternatives when a disparity is identified. The defense is not "we didn't use race." The defense is "we tested for disparate impact, found no statistically significant disparity, and documented the test."

The Specific Failure Modes of Scoring Models

Scoring models fail in two characteristic ways. The first is data drift: the model was trained on historical applications, and the population of applicants the bank is now seeing is materially different from the training population. A model trained on 2019 to 2022 data does not know that interest rate environments changed in 2023 and that the income-to-payment ratios that predicted good performance in 2022 predict something different in 2024. Ongoing performance monitoring is the control for this failure mode, and OCC Bulletin 2026-13 makes that monitoring a documented requirement.

The second failure mode is the proxy variable problem described above. A model that appears accurate and neutral in backtesting on the historical population may, when deployed on the current population, produce outcomes that disparately affect groups the bank did not intend to disadvantage. Regular disparate-impact testing across the full application population, including applicants who were approved as well as denied, is the required control. Banks that test only the denial population miss the ways in which approval rates differ across demographic groups.

Document Extraction: How It Works and Where It Breaks

A document extraction model (also called intelligent document processing or IDP) reads an unstructured source document (a PDF, a scan, a photographed page) and produces structured data. The model uses optical character recognition (OCR) to read the text and a classification layer to identify which text belongs to which field. The output is a set of key-value pairs: gross monthly income is $5,400, pay period is biweekly, employer name is Greenfield Manufacturing, most recent pay date is March 14 2026.

In the loan origination system (LOS, the software platform managing the loan from intake through closing), these extracted fields feed directly into underwriting calculations. The DTI ratio the underwriter sees is based on the income figure the extraction model produced. The employment history summary is based on the employer data the extraction model read. The bank statement balance is based on the figure the extraction model pulled from the statement. If any of these are wrong, the underwriting is based on wrong data, and the credit decision (whether to approve, decline, or counteroffer) may be wrong as a result.

The extraction model has no awareness of this downstream consequence. It is optimized to produce the most likely field value given the document image. When the document is standard (a clean two-column paystub from a large employer, a W-2 from a well-known national company), accuracy is high. When the document is non-standard (a handwritten ledger from a self-employed contractor, a foreign-language tax document, a multi-employer pay stub from a gig-economy platform), accuracy drops and the failure mode changes character.

The Specific Failure Modes of Extraction Models

Three extraction failure modes occur with enough frequency to deserve specific attention in a lending context.

Period confusion. A paystub showing a biweekly gross pay of $2,700 should produce a monthly income of $5,850 (multiplied by 26 pay periods, then divided by 12). An extraction model that reads the period as monthly will extract gross monthly income as $2,700, cutting the borrower's qualifying income by more than half. This is not a rare edge case. It is the most common extraction error on paystubs, because the pay period field is in different locations across different employer pay templates, and some templates do not clearly label it. A DTI ratio calculated on $2,700 instead of $5,850 per month will often push a clean application over the policy threshold, resulting in a denial or counteroffer based on an income figure that is wrong by more than 50 percent.

Multi-column misreading. A two-column pay stub shows year-to-date (YTD) figures in one column and current period figures in another. On some document layouts, the extraction model reads the YTD column as the current period amount. A borrower three months into the year with $16,200 YTD earnings might have her monthly income extracted as $16,200 rather than $5,400. This inflates income in a way that understates credit risk. The resulting approval, based on an overstated income, exposes the bank to a fair-lending claim if the loan subsequently goes into default and a review shows the income was never verified against the actual figure.

Non-standard document rejection or silent error. An extraction model that encounters a document it was not trained on may do one of two things: flag the document for human review (the better outcome) or silently extract wrong values without flagging (the dangerous outcome). Many production extraction models are trained primarily on standard U.S. employer pay templates. A recent immigrant's foreign-language paystub, a domestic worker's informal earnings letter, or a seasonal agricultural worker's variable-income record may produce silent errors. These errors are particularly concerning from a fair-lending perspective: if the borrowers who receive wrong extraction-based income calculations are systematically from protected classes (because their income documentation is less likely to match the model's training distribution), the extraction error itself becomes a disparate-impact risk.

Generative Drafting: How It Works and Where It Breaks

A generative model (a large language model or LLM) takes a text prompt and generates a text response. In a lending context, the use cases include drafting credit memos, summarizing loan files, writing adverse-action notices, producing plain-language borrower disclosures, and answering questions about credit policy or regulatory requirements. The model predicts text that is statistically consistent with patterns learned from its training data. It does not look up facts. It generates the most plausible continuation of the prompt.

The practical consequence is that a generative model is excellent at producing professional, well-structured text and unreliable at producing accurate text when the accuracy depends on specific details it was not given in the prompt. A model asked to write a credit memo for a $1.5 million small business loan will produce a memo that reads like a professional credit memo. The section headings will be correct. The prose will be polished. The risk factors section will contain plausible risk factors. The financial analysis section will reference plausible financial metrics. If the actual borrower's financials were not included in the prompt, the metrics cited will not be the borrower's actual metrics. They will be metrics that are plausible for a small business loan of that size and type.

The Specific Failure Modes of Generative Models in Lending

Three failure modes deserve names because they appear repeatedly in bank compliance findings related to generative AI.

The fabricated reason code. An adverse-action notice drafted by a generative model without grounding on the underwriter's actual decision logic will produce the reasons that are most statistically common for that type of application. If the actual reason for denial was a specific underwriting exception that was not granted, and the common adverse-action reasons for that loan type are high DTI ratio and insufficient credit depth, the AI-generated notice may say "high debt obligations relative to income" and "limited credit history" even if the applicant's DTI was within policy guidelines and her credit history was strong. The notice is specific. It is not accurate. Under ECOA and Regulation B, a specific but inaccurate reason is a statutory violation, not a documentation error.

The invented covenant or collateral term. A generative model drafting a commercial credit memo will include the sections a commercial credit memo usually contains, including collateral and covenant sections. If the actual file does not include a completed security agreement or defined covenants, the model may generate plausible-sounding collateral descriptions and covenants that are not in the actual agreement. A credit approval memorandum that references collateral or terms not in the legal documents creates a discrepancy between the approved credit and the documented credit. This can affect legal enforceability, examiner confidence in the credit file, and, in litigation, the bank's ability to enforce the terms it believed it had secured.

The outdated regulatory citation. A generative model asked to reference a regulatory requirement (a Reg B timeframe, an OCC model-risk expectation, a Bank Secrecy Act (BSA) or Anti-Money Laundering (AML) filing obligation) will cite the regulation as it was described in its training data. If the regulation has changed since the model's training cutoff, the citation may be wrong. OCC Bulletin 2026-13, issued April 2026, substantially changed the model-risk framework. A model whose training predates April 2026 does not know the updated requirements and will describe the prior framework. A compliance document citing the prior framework is not compliant with the current requirements regardless of how accurately it describes the prior ones.

The Compliance Triangle: Matching Controls to Categories

Each AI category requires a different compliance control architecture. A bank that applies the same review process to all three types will over-control some risks and miss others entirely.

For scoring and classification models, the required controls are: (1) initial validation before deployment, documenting methodology, performance metrics, and protected-class outcome testing; (2) ongoing performance monitoring at a defined frequency (typically quarterly) to detect data drift and model degradation; (3) regular disparate-impact testing across the full application population; (4) a documented adverse-action reason generation methodology that ties reason codes to the actual model outputs for each applicant; and (5) a change management process for model updates that triggers re-validation when the model or its inputs change materially.

For document extraction models, the required controls are: (1) a pre-deployment accuracy assessment across the document types the model will encounter in actual production (which may differ significantly from the vendor's test set); (2) a field-level confidence threshold policy that routes low-confidence extractions to human review rather than flowing silently to the LOS; (3) a random-sample quality assurance process that compares extracted values to source documents on an ongoing basis; and (4) a specific review protocol for non-standard documents (self-employment, foreign-language, non-traditional income sources) that ensures extraction accuracy on the document types most likely to affect underserved borrowers.

For generative models, the required controls are: (1) a grounding requirement that mandates the actual file, the actual underwriting notes, and the actual credit policy be included in the prompt when the output will be used in a regulated document; (2) a human review requirement before any AI-generated adverse-action language is sent to a borrower, with a specific check confirming the stated reasons match the actual decision rationale; (3) a currency policy that establishes how frequently the model's regulatory knowledge is reviewed and updated; and (4) documentation that AI was used in the drafting process, as required under OCC Bulletin 2026-13's audit trail expectations.

The Technology Buying Conversation Every Banker Needs to Have

The next time a lending AI vendor presents to your institution, the questions that distinguish a well-governed technology purchase from the six-figure remediation story described above are simple to ask once you know the categories.

For every AI tool in the platform: "Which of the three categories does this component fall into: scoring and classification, document extraction, or generative drafting?" If the vendor cannot answer clearly, the product is not ready for a regulated lending environment.

For scoring models: "How was the model validated? What are the performance metrics on protected-class subgroups? How does the model generate adverse-action reason codes, and are those codes tied to the model's actual outputs for each applicant or generated from a template?"

For extraction models: "What is the field-level accuracy rate on the document types we see most frequently? How does the model handle non-standard documents? Does it flag low-confidence extractions for human review, and what threshold triggers that flag?"

For generative models: "Is the model grounded on the actual file data, or is it generating from general patterns? What is the process for human review before AI-generated text reaches a borrower or a credit file? What is the training data cutoff date, and how does the vendor handle regulatory updates that post-date that cutoff?"

A vendor who answers all of these questions clearly, with documentation, is selling a product that can be governed under OCC Bulletin 2026-13. A vendor who deflects, reframes, or says "our AI handles all of that" is selling marketing copy. The difference costs nothing to establish in a pre-purchase conversation. It costs a great deal to establish in an examination.

Key Takeaways

• There are three distinct AI categories in lending: scoring and classification models (structured inputs to a score or label), document extraction models (reading documents to populate structured fields), and generative drafting models (producing prose from prompts). They have different architectures, different failure modes, and require different compliance controls. Treating them as a single technology is the source of most AI-related examination findings at banks.
• Scoring and classification models carry the most complex compliance obligations, including adverse-action reason generation tied to actual model outputs, disparate-impact testing across the full application population, and ongoing performance monitoring under OCC Bulletin 2026-13. "The model scored them low" is not a Regulation B reason.
• Document extraction models fail silently: a misread paystub populates the LOS with a wrong income figure, and the underwriting engine proceeds on that figure without flags. Period confusion (biweekly read as monthly) is the most common extraction error, and it is capable of changing a clean application into an apparent policy violation.
• Generative drafting models produce the most statistically plausible text for the document type being drafted. In adverse-action notices, this means the model produces common adverse-action reasons, not necessarily the reasons that actually drove this specific decision. The fabricated reason code failure mode is a direct Regulation B violation.
• The Community Reinvestment Act (CRA, which requires banks to meet the credit needs of their entire community including low- and moderate-income areas), fair-lending obligations, and UDAAP (Unfair, Deceptive, or Abusive Acts or Practices) exposure all apply across all three AI categories, but in different ways. Extraction errors that disproportionately affect protected classes create disparate-impact risk. Generative errors that produce inaccurate adverse-action reasons create UDAAP exposure. Scoring model proxy variables create disparate-impact risk.
• OCC Bulletin 2026-13 requires separate documentation and validation for each model. A bank that has deployed a three-component AI lending platform as a single undifferentiated product cannot satisfy OCC 2026-13's model-risk requirements without reconstructing the documentation for each component separately.
• The vendor buying conversation must address each AI category separately. Questions about accuracy, validation, adverse-action reason generation, protected-class testing, and human-review requirements are category-specific. A vendor who answers them at the platform level rather than the component level is not ready for a regulated lending environment.
• The right question for any AI procurement is not "is this AI?" but "which type of AI is this, what are its specific failure modes in our lending context, and what are the documented controls for each failure mode?" The answer to that question, from a vendor who can give it, is the beginning of a defensible model-risk file under OCC Bulletin 2026-13.