The following scenario is a composite illustration; the names and specific details are fictional and do not represent any identified individual, institution, or proceeding. At 4:18 on a Wednesday afternoon, a mortgage underwriter in Columbus named Derek cleared what he thought was the final file in his queue. The AI pre-scoring system had flagged the application as a decline. The applicant, a thirty-one-year-old warehouse supervisor applying for a $224,000 purchase loan, had a 641 credit score, a documented two-year employment history, and a debt-to-income ratio of 43 percent. The system had generated four draft adverse-action reason codes: "insufficient credit history," "excessive debt obligations," "insufficient income relative to loan request," and "recent derogatory information." Derek approved the notice, released it, and moved on. Three weeks later, the applicant called the bank's fair-lending hotline. He had pulled his file. His credit history was eleven years long. His revolving utilization was 28 percent. His income, at $61,400 annually, supported the requested payment with margin. The one true negative was a single 60-day late payment on a medical bill from 18 months prior. Three of the four reason codes on the notice did not accurately describe why his application was declined. The bank had sent a legally non-compliant adverse-action notice, and the only defense it had was to produce documentation showing the codes were verified before they went out. It could not. That call became a CFPB (Consumer Financial Protection Bureau) complaint, a fair-lending investigation, and a six-figure remediation settlement. The root problem was not the AI. It was the absence of the one discipline that makes AI-assisted adverse action defensible: drafting specific, accurate reason codes grounded in what the file actually shows.

Why Specificity and Accuracy Are Separate Requirements

When bankers and compliance officers talk about adverse-action reason codes, they often treat "specific" and "accurate" as synonyms. They are not. They are distinct legal requirements under the Equal Credit Opportunity Act (ECOA, the federal statute prohibiting credit discrimination enacted in 1974 and amended in 1976) and Regulation B (Reg B, 12 CFR Part 1002, the CFPB's implementing regulation for ECOA), and the difference between them is exactly where AI-assisted adverse action tends to fail.

Specificity is the requirement that the stated reason identifies a particular credit characteristic with enough precision that the applicant can understand it, potentially dispute it, and act on it. A reason like "credit history" fails the specificity test. A reason like "serious delinquency within the past 24 months" passes it. The CFPB's official commentary to Regulation B lists approximately thirty recognized reason-code categories, and the controlling principle is that the reason must point to a specific, identifiable element of the applicant's credit profile, not a general category of concern. The applicant must be able to read the reason and understand what specific fact about their file drove the denial.

Accuracy is the requirement that the stated reason genuinely reflects the actual factor that drove the credit decision, not just a fact that is true about the file. This is the harder standard, and it is the one AI systems are most likely to fail. A reason can be perfectly specific and still be inaccurate: "high revolving credit utilization" is a specific, recognizable reason-code category, but if the applicant's utilization is 22 percent and the actual denial driver was a recently opened auto loan that pushed the debt-to-income ratio over the institution's threshold, then the stated reason is both specific and false. A false reason is not a documentation gap. Under ECOA and Reg B, it is an independent violation, because the law's adverse-action notice requirement is a substantive civil rights protection. The applicant has the right to know the true reason for the denial so they can detect and challenge discrimination. A false reason actively obstructs that right.

The reason the two requirements matter separately is that AI systems have different failure modes for each. Generative AI tools are reasonably good at producing specific-sounding output. They are trained on large corpora that include many well-formatted adverse-action notices, so they know what a reason code is supposed to look like. What they cannot reliably do is verify that the specific-sounding reason they produced is accurate to this particular file, because accuracy requires tracing a stated reason to a specific data point in the applicant's financial record, and that tracing requires the kind of document-grounded attention that generative tools frequently substitute with pattern-matching against training data. The result is the exact failure mode in Derek's case: plausible-sounding reason codes that do not accurately describe the specific file in front of the underwriter.

Specificity is about form; accuracy is about truth. ECOA requires both, independently, and generative AI fails accuracy more often than specificity.

What Reg B Actually Requires from a Reason Code

To draft reason codes that will survive regulatory scrutiny, an underwriter or analyst needs a working understanding of what the regulation actually demands, not a rough sense of what sounds like compliance language. The requirements are more specific than most practitioners realize, and closing the gap between a "reasonable-sounding" code and a "legally sufficient" code is where the discipline of this chapter lives.

Regulation B Section 1002.9 requires that an adverse-action notice state the specific reasons for the action taken, or disclose that the applicant has the right to request a statement of specific reasons within sixty days of the notice, with the creditor then required to provide those reasons within thirty days of such a request. In practice, virtually all institutions use the statement-of-reasons path, because any institution that cannot state reasons at the time of denial has a much deeper problem than notice format.

The word "specific" in the regulation has been interpreted by the CFPB, its predecessor agencies, and the courts to mean: the reason must identify the particular characteristic of the applicant's credit profile that contributed to the adverse action, with sufficient precision that the applicant could identify the underlying data and, if incorrect, dispute it. That interpretive standard does the following work:

It rules out model references. "Our model determined your application did not meet our standards" is a process description, not a reason. The model is a decision instrument; the reasons are the inputs the instrument weighed. Saying "the model said no" is legally equivalent to saying nothing, because it tells the applicant nothing about the specific characteristic of their file that contributed to the denial.

It rules out score references without factor support. "Your credit score of 634 did not meet our minimum" is not a specific reason. The score is an output. The factors that produced the score are the reasons. If the score contributed to the denial, the institution must trace the score back to the underlying factors: the specific delinquency, the utilization level, the length of history, or whichever factors the scoring model documented as the primary drivers. The score alone, without the factor-level explanation, is not a Reg B-compliant reason.

It requires completeness as well as accuracy. The CFPB's commentary to Reg B makes clear that the reasons stated must give the applicant a fair picture of the basis for the denial, meaning they must cover the principal factors. If there were three material reasons for the denial and the notice only lists one, the notice is non-compliant even if the one it lists is specific and accurate. The "principal reasons" standard under CFPB interpretation requires that the stated reasons account for the dominant factors in the decision, not just one of them.

The recognized reason-code categories under Reg B's model forms (Forms C-1 through C-5) include codes like: "delinquent past or present credit obligations with others," "garnishment or attachment," "foreclosure or repossession," "collection action or judgment," "too many accounts with balances," "insufficient number of credit references provided," "unacceptable type of credit references provided," "unable to verify credit references," "temporary or irregular employment," "unable to verify employment," "length of employment," "insufficient income," "excessive obligations in relation to income," "unable to verify income," "length of residence," "temporary residence," "unacceptable type of residence," "no credit file," "limited credit experience," "poor credit performance with us," "delinquency on a previous loan with us," and a set of property-related codes for secured lending. These codes, or codes derived from them, are the framework within which most compliant adverse-action notices are written.

Notice the structure of these codes: each one names a specific characteristic of the applicant's credit profile (employment status, income level, past delinquency, type of credit reference) and can be traced to a specific data point in the file. When an AI system drafts a reason code, the underwriter's verification task is to confirm that the code maps cleanly to one of these categories, that the category applies to a specific, documented characteristic of this file, and that the characteristic is actually a material factor in the credit decision, not just something true about the file that the AI pulled in from pattern-matching.

How AI Drafts Reason Codes and Where It Goes Wrong

According to 2024 survey data, roughly 38 percent of mortgage lenders were using AI or machine learning somewhere in their underwriting process, up from 15 percent in 2023. A significant portion of those institutions are using AI not just for pre-scoring but for drafting the adverse-action reason codes that accompany denials. Understanding how that drafting process works, technically, is essential for understanding where it fails and why human verification is not optional.

A generative AI tool drafting adverse-action reason codes operates by processing the loan file (or a summary of it), identifying financial characteristics that appear unfavorable, and generating reason-code language that follows the patterns of the reason codes it encountered in its training data. The output looks authoritative because the tool has been trained on thousands of properly formatted adverse-action notices and has learned the vocabulary, structure, and style of compliant reason codes. The tool knows what a reason code is supposed to look like. It does not know whether the reason code it produced is accurate to this specific file, because that requires a step the tool cannot perform: comparing the generated reason to the actual credit decision logic and confirming that the stated factor is the actual driver of the denial, not just a coincidentally unfavorable characteristic of the file.

This creates three distinct failure modes that compliance teams see regularly in AI-assisted adverse-action workflows:

Failure mode one: the AI anchors on visible unfavorable file characteristics rather than the actual decision drivers. An AI tool reviewing a file sees a 43 percent debt-to-income ratio, a 641 credit score, limited savings, and a single 60-day late payment. It generates reason codes for all four unfavorable characteristics. But the actual denial under the institution's credit policy was driven primarily by the 43 percent debt-to-income ratio, which exceeded the institution's 42 percent threshold. The other characteristics may have been noted, but they did not drive the denial. The AI produced four reason codes when the accurate picture might require only one or two, and the codes for the non-determinative factors are technically true about the file but not accurate as adverse-action reasons, because they did not actually cause the denial.

Failure mode two: the AI generates reason codes that are plausible for the file type but inaccurate for the specific file. This is the failure mode in Derek's story. The AI, processing a file with a debt-to-income ratio above threshold, a modest credit score, and a recent late payment, generates boilerplate that fits a generic "borderline" mortgage applicant. The codes sound right for the file type. They may not be right for the specific file, because the specific file has characteristics that the generic boilerplate does not capture: the credit history length, the actual utilization rate, the income relative to the loan amount. The AI is pattern-matching to "what does a denial reason code look like for a file like this" rather than "what specific characteristic of this file drove this decision under this institution's credit policy."

Failure mode three: the AI invents reasons that are not in the file at all. This is the hallucination failure mode, and it is the most dangerous. A generative AI tool asked to explain a denial may produce a reason code for a delinquency that does not exist in the file, an income shortfall that does not match the actual income documentation, or an employment gap that is not in the application. The reason sounds specific and professional. It is false. A false adverse-action reason is an ECOA violation that the institution sent, in writing, to the applicant. The downstream consequences include the violation itself, the applicant's ability to dispute a stated reason that is simply wrong, and, in a pattern-or-practice context, the appearance that the institution is generating denial reasons that are not grounded in the actual file, which is the structure of a discriminatory-pretext case.

OCC Bulletin 2026-13, the April 2026 interagency model-risk guidance that superseded OCC 2011-12 and pulled AI and generative AI under model-risk, fair-lending, third-party, and board-governance expectations, speaks directly to this problem. The bulletin's framework requires that any AI model used in a credit decision be validated to confirm that its outputs accurately represent the factors driving the decision. For adverse-action reason generation, this means the institution must be able to demonstrate that the reason codes its AI produces are the actual drivers of the denial, not just plausible-sounding outputs that pattern-match to a file's unfavorable characteristics. That demonstration is the verification step, and it is a human step, not an AI step.

The Hallucinated Reason as a Redlining and CFPB Problem

A hallucinated adverse-action reason is not just a documentation problem. In a fair-lending context, it becomes a qualitatively different kind of violation: it can produce the pattern of a discriminatory pretext. Understanding how and why is critical for any lender using AI in the adverse-action process.

Redlining, in its modern regulatory meaning, refers to a pattern of denying credit on the basis of the racial or ethnic composition of a neighborhood, either through explicit policy or through practices that produce a systematic disparity in credit availability in protected-class areas. A traditional redlining case is built on pattern evidence: higher denial rates in census tracts with higher minority concentrations, controlling for creditworthiness. The evidence of the pattern is in the data. The evidence of intent (in cases that pursue it) is in the documentation.

Here is where AI-generated hallucinated reason codes create a redlining-adjacent problem. Suppose a lender's AI pre-scoring model has a bias in its outcomes: it assigns lower pre-scores to applicants from majority-minority census tracts at rates that exceed the creditworthiness differences between those applicants and applicants from majority-white census tracts. The bias may be driven by a proxy variable (zip code, grocery-store transaction patterns, employer classification) rather than race explicitly. When those applications are denied and the AI generates reason codes, the hallucinated reasons create a paper trail that cannot be used to investigate or explain the disparity, because the stated reasons do not reflect the model's actual decision logic. The disparity exists. The denial reasons do not explain the disparity. The institution cannot trace the denials to the model's actual drivers, because the AI-generated reasons replaced the model's actual reasoning with plausible-sounding boilerplate.

This is exactly the structure of a CFPB referral case. The CFPB's fair-lending examination protocol looks at geographic disparities in denial rates, compares denial rates across demographic groups controlling for credit factors, and then examines whether the stated adverse-action reasons can explain the disparity. When the stated reasons are hallucinated, the institution cannot provide the explanation. It cannot say: "This group received higher denial rates because they had higher debt-to-income ratios and we can demonstrate that by tracing each denial to the specific ratio in the file." It can only say: "The AI generated these reasons." That answer is not a defense. It confirms that the institution lacks the governance structure OCC Bulletin 2026-13 requires: the ability to validate that model outputs accurately represent decision logic for individual applications.

A CFPB investigation that finds a pattern of geographic disparities combined with an inability to trace denial reasons to specific file characteristics has the inputs for a discriminatory-pretext case. The institution's inability to explain the denials becomes part of the evidence of the violation, not a mitigating factor. The civil money penalty, the consent order, the remediation program, and the reputational cost are all proportional to the number of affected applicants and the severity of the disparity. For an institution processing hundreds of mortgage applications per month, the aggregate exposure from six months of hallucinated adverse-action reasons is substantial.

The preventive measure is the same in all cases: a verification workflow that requires a human to trace every stated reason to a specific data point in the file before the notice goes out. That workflow does not just satisfy Reg B. It produces the documentation the institution would need, in a fair-lending examination, to demonstrate that its denial reasons are grounded in the file rather than in an AI model's pattern-matching against a training corpus.

How to Assemble Specific, Accurate Reason Codes with AI

The practical workflow for drafting specific, accurate reason codes with AI assistance has five stages. Each stage has a specific human responsibility that cannot be delegated to the AI. Together they produce a reason-code package that satisfies Reg B, is defensible under OCC 2026-13, and is accurately grounded in the file.

Stage one: establish the actual decision basis before involving AI at all. Before using AI to draft any reason codes, the underwriter or analyst needs to establish, in their own analysis, why the application is being denied. Under the institution's credit policy, which specific factors made the application ineligible? Was it the debt-to-income ratio exceeding the threshold? A recent delinquency that triggered a disqualifying condition? An income verification failure? A property characteristic that required committee approval that was not sought? The decision basis must be established from the credit policy, not derived from an AI pre-score. The AI pre-score is an input to the analysis. It is not the analysis. This stage cannot be shortcut, because if the underwriter does not know the actual decision basis, they cannot verify whether the AI's reason codes are accurate.

Stage two: prompt the AI with the actual file data, not just a general description. When asking AI to draft adverse-action reasons, the prompt must include the specific, numerical file data: the debt-to-income ratio as calculated, the credit score, the specific delinquency history from the credit report, the income as documented, the loan-to-value ratio, and any other relevant file elements. A prompt that says "help me draft adverse action reasons for a file with a mid-range credit score and moderate debt" will produce generic output. A prompt that says "the applicant has a 43.2 percent debt-to-income ratio calculated against $61,400 documented income, a 641 FICO score with a 60-day late payment on a medical account in October 2024, and a requested loan amount of $224,000 on a $240,000 purchase" gives the AI the specific data it needs to generate reason codes that at least reference the right file characteristics. The quality of the AI's output is bounded by the specificity of the input. Always provide the actual numbers.

Stage three: verify each AI-generated reason code against the file, individually. For each reason code the AI proposes, the underwriter answers three questions: First, is there a specific, documented data point in the file that supports this reason? If the AI proposed "excessive obligations in relation to income," what is the specific debt-to-income calculation, drawn from which documents, that supports this code? Second, is this reason a material factor under the institution's credit policy? Not just present in the file, but actually a reason the policy requires a denial or flags for concern? Third, is this the most accurate available description of the contributing factor, or is the AI's phrasing imprecise in a way that could mislead the applicant? Each of these questions requires the underwriter to look at the actual document, the actual policy, and the actual reason. They cannot be answered by reading the AI's output alone.

Stage four: check for completeness and for reasons the AI omitted. The AI may not pick up every material denial factor. Policy-level reasons (the property is in a geographic category requiring committee review, the loan structure triggered an exception that was not approved) may not be reflected in the financial data the AI analyzed. Verification reasons (the AI cannot verify income because the documentation is inconsistent) may require the underwriter to flag a category the AI missed. After verifying the accuracy of the codes the AI did produce, the underwriter must consider what the AI did not produce and whether any omitted factor is material to the decision. Completeness is a Reg B requirement: the stated reasons must give the applicant a fair picture of the denial basis, not just an accurate partial list.

Stage five: document the verification before releasing the notice. The institution's LOS, document management system, or workflow tool should record that the adverse-action reason codes were reviewed and verified by a named individual before release, with the date of the review and, preferably, the specific data points the reviewer used to verify each code. This documentation is not administrative overhead. It is the institution's defense in any subsequent challenge: evidence that a human reviewed the AI's draft, traced each reason to the file, and confirmed accuracy before the notice was sent to the applicant. Under OCC Bulletin 2026-13's governance framework, this documentation is part of the model-risk record that supports the institution's ongoing ability to validate the AI's outputs. Without it, the institution cannot demonstrate the validation function the 2026 guidance requires.

Worked Example: From Hallucinated Codes to a Defensible Notice

Let us work through a concrete example that illustrates the difference between AI-generated codes without verification and a verified reason-code package. This example uses a composite drawn from the types of files underwriters encounter regularly, and the numbers are illustrative rather than from a specific case.

The application: Maria Diaz, age 34, applying for a $198,000 mortgage on a $215,000 purchase property. Documented income: $52,800 annual, via W-2 and two recent pay stubs. Credit score: 628 (FICO 8). Credit report highlights: one collection account for $1,400 (medical, opened October 2023, showing as unpaid), overall utilization 31 percent, 12 accounts, oldest account 8 years, no late payments on any revolving accounts in the past 24 months, no recent derogatory information other than the collection. DTI calculation: proposed PITI (principal, interest, taxes, insurance) of $1,380 plus existing obligations of $890 equals $2,270 total, against gross monthly income of $4,400, yielding a front-end DTI of 31 percent and a back-end DTI of 51.6 percent. The institution's credit policy maximum back-end DTI for a 628 credit score borrower is 45 percent. Loan-to-value ratio: 92 percent, which requires private mortgage insurance (PMI) and is within the institution's guidelines.

The AI's first-pass reason codes, without verification: "Insufficient credit history," "Recent derogatory information," "Excessive obligations in relation to income," "Insufficient income for the requested loan amount."

Verification analysis, code by code:

"Insufficient credit history": The file shows 12 accounts, an 8-year oldest account, and no serious delinquencies. The institution's credit policy does not flag this file for insufficient credit history. The AI produced this code because 628 is a lower credit score and it associated lower scores with thin credit profiles. But the profile here is not thin. This code is inaccurate. Strike it.

"Recent derogatory information": The file has one collection account from October 2023 for $1,400, showing as unpaid. The institution's credit policy requires underwriter review of any open collection over $500 and disqualifies files with more than one open collection. This file has one. The code is partially supportable, but the more accurate and specific statement is: "Unpaid collection account on credit report." The AI's phrasing ("recent derogatory information") is generic and would apply to many file types. The specific, accurate code uses the collection account category. Revise to the more specific code.

"Excessive obligations in relation to income": The back-end DTI is 51.6 percent against a 45 percent policy maximum for this credit score tier. This is accurate. It reflects a specific, calculable fact from the file. It is the primary denial driver. Keep and refine: "Debt-to-income ratio exceeds our guidelines based on your reported income and obligations (51.6% against a 45% maximum)." This level of specificity is ideal, though some institutions prefer not to print the exact ratio in the notice. At minimum, the code should be "excessive obligations in relation to income," specifically documented in the verification log as tracing to the DTI calculation.

"Insufficient income for the requested loan amount": The income is documented at $52,800. The institution's minimum income is not the binding constraint here: the binding constraint is the DTI. Income is $4,400/month, which is not flagged as insufficient under any policy threshold for a $198,000 loan. The income itself is not the denial reason; the debt level relative to income is the denial reason, which is already captured in the DTI code. This code is inaccurate. Strike it.

The verified notice contains two codes: "Unpaid collection account on credit report" and "Excessive obligations in relation to income." Both are specific. Both are accurate. Both trace to specific, documented characteristics of the file. Neither references the AI, the model, or the pre-score. The underwriter's verification log documents, for each code, the specific file data supporting it and the policy basis for the denial. The notice is defensible under Reg B. The verification log provides the documentation OCC 2026-13 requires. If an examiner or the applicant challenges the notice, the institution can trace every stated reason to the file data that supports it.

The AI's four codes were two wrong, one right but imprecise, and one partially overlapping with a better code. In a file where the underwriter does not perform verification, three of the four codes in the notice would have been inaccurate. This is the work the human must do. The AI built the draft. The human built the compliant notice.

The Human Accountability That OCC 2026-13 Requires

OCC Bulletin 2026-13 is the April 2026 interagency model-risk guidance issued jointly by the OCC (Office of the Comptroller of the Currency), the Federal Reserve, and the FDIC, superseding OCC 2011-12. It explicitly extends the model-risk management framework to AI and generative AI tools, and it pulls adverse-action reason generation under the model-risk, fair-lending, and governance expectations of that framework. For underwriters and analysts using AI in the adverse-action process, the bulletin's requirements translate into two concrete obligations.

First, the institution must be able to validate that its AI tool's adverse-action reason outputs accurately represent the actual decision factors for individual applications. This is not a population-level validation: "Our AI produces accurate reasons on average." It is a transaction-level validation: "For this application, the reasons in the notice match the actual decision logic." That transaction-level validation is the human verification step. It cannot be performed by the AI tool itself, because the AI cannot objectively evaluate the accuracy of its own output against a standard it does not have access to (the institution's credit policy applied to this specific file). The human underwriter, who has access to both the file and the policy, is the only party who can perform this validation.

Second, the institution must maintain a record of the validation for each denied application. The model-risk record under OCC 2026-13 is not just a model-level document describing how the AI works. It is also a transaction-level trail that demonstrates the institution's ongoing governance of the AI's outputs. For adverse-action purposes, that trail includes: the AI's draft reason codes, the underwriter's verification analysis, the final reason codes in the notice, and the documentation linking each code to the file data that supports it. This record is what the institution produces when an examiner asks: "For this denial, show me how you know the stated reasons are accurate."

The accountability principle embedded in both ECOA and OCC 2026-13 is the same principle: the institution and its human officers are responsible for the accuracy of credit decisions and their stated reasons, regardless of what technology was used in the process. "The AI generated the reason codes" is not a defense to a Reg B violation. It is a description of a step in a process that also required human verification. If that verification did not happen, the institution failed to meet its obligations, and the stated reasons in the notice are not defensible. This accountability is also the underwriter's professional accountability: the human who releases the adverse-action notice is, in practice, the person who is professionally responsible for the accuracy of the stated reasons, because that human is the last human in the chain before the notice reaches the applicant.

The practical implication for a working underwriter or analyst is straightforward: the shift that AI creates in this role is not from "draft the reasons" to "approve whatever the AI drafted." It is from "draft the reasons" to "verify that the AI's draft is accurate, grounded in the file, and complete." That is still the underwriter's work. The AI drafted the starting point. The underwriter built the defensible deliverable. That distinction is the difference between a compliant adverse-action process and a CFPB investigation.

Key Takeaways

• Specificity and accuracy are separate Reg B requirements. Specificity means the reason identifies a particular credit characteristic precisely enough to be understood and disputed. Accuracy means the stated reason reflects the actual factor that drove the decision, not just a true fact about the file. AI systems are more likely to fail accuracy than specificity, because they can produce well-formatted codes that do not accurately describe the specific denial driver.
• AI drafts adverse-action reasons by pattern-matching to file characteristics and training-data examples of reason codes. This produces plausible-sounding output that may not accurately reflect the institution's credit-policy basis for this specific denial. The three AI failure modes are: anchoring on visible file characteristics that were not the decision drivers, generating boilerplate for the file type that does not match the specific file, and hallucinating reasons that are not in the file at all.
• A hallucinated adverse-action reason is an ECOA violation regardless of how it was produced. In a fair-lending context, a pattern of hallucinated reasons that cannot be traced to file data is the structure of a discriminatory-pretext finding: geographic disparities in denial rates combined with an inability to document the actual denial basis.
• The five-stage verification workflow is the non-negotiable control: establish the actual decision basis before involving AI; prompt with specific numerical file data; verify each code against the file individually; check for omitted material factors; and document the verification before releasing the notice. The AI builds the draft; the human builds the compliant notice.
• OCC Bulletin 2026-13 requires transaction-level validation that AI-generated reason codes accurately represent the actual decision factors for each individual application. That validation is a human function. The institution must maintain a record of the validation as part of its model-risk file.
• "The model said no" and "the AI generated the reasons" are not defenses to an adverse-action violation. Accountability for the accuracy of stated reasons belongs to the institution and the human officer who released the notice. The professional who verifies AI-generated reasons before release is fulfilling that accountability; the one who does not is creating the institution's next compliance finding.
• The worked example illustrates the practical scope of AI error in reason-code drafting: two of four AI-generated codes were inaccurate, one was imprecise, and one was partially redundant with a better code. Without verification, three of the four codes in the notice would have been wrong. That is the quality gap the human verification step closes.
• Drafting specific, accurate reason codes with AI is faster than doing it from scratch, but the speed benefit only exists if the verification step is genuinely performed, not rubber-stamped. The goal is a notice that is faster to produce and more accurate than unaided human drafting, with a verification log that documents exactly why every stated reason is true.