On a Thursday morning in early 2026, a compliance officer at a community bank pulled eleven recent adverse-action notices for a routine quality review. Seven of the eleven contained at least one reason that, on close inspection, could not be traced to a specific data point in the borrower's file. Two contained reasons that the officer concluded were technically accurate descriptions of the file but were not, in fact, the primary factors the bank's credit policy required for that type of denial. One contained a reason the officer could only describe as "plausible but not actually supported by anything in this file." The bank used an AI drafting assistant for adverse-action notices. No one had built a formal verification step. Each loan officer had a general instruction to "check the AI's work," but check meant different things to different officers. In some files the AI output had been reviewed carefully; in others it had been glanced at and released. The eleven files were from three different loan officers. The inconsistency was not malicious. It was the natural result of a team that had a principle ("verify AI output") without a procedure ("here is exactly how to verify this specific output, in this order, documented this way"). A checklist is not bureaucracy. In a regulated lending environment where every AI-touched credit decision carries fair-lending, ECOA, and model-risk implications, a repeatable verification checklist is the difference between a principle that is followed consistently and a principle that is followed when time permits.

Why a Checklist Works Where General Instructions Fail

General instructions fail in high-volume, time-pressured environments because they require the reviewer to independently determine the correct verification steps each time, under varying conditions of file complexity, time pressure, and reviewer experience. A general instruction to "verify the AI's income analysis" leaves every element of that verification to the reviewer: which documents to check, in what order, using which methodology, looking for which specific discrepancies, and documenting which outcomes. Experienced reviewers may do this well; newer reviewers may not. Experienced reviewers under end-of-quarter pressure may skip steps they would perform carefully when the queue is short. The result is inconsistency: some files are verified thoroughly and some are not, with no record of which is which.

The aviation safety and surgical literature has documented this failure mode exhaustively, and the banking regulatory community has been explicit about the parallel: in high-consequence environments where errors are costly and accountability is individual, proceduralized checklists outperform individual expertise under time pressure because they transfer the cognitive load of "remembering what to check" to the checklist itself, leaving the reviewer's cognitive resources for the substantive judgment steps that actually require expertise. Atul Gawande's foundational work on surgical checklists found that procedural steps done from memory had meaningfully higher failure rates than checklist-guided procedures (studies in that literature, including Gawande's WHO Surgical Safety Checklist work, found relative reductions in major complications of roughly one-third or more, though exact figures vary by study and setting). The implication for AI-assisted credit work is direct: the reviewer's expertise should go into evaluating whether the AI's stated income figure looks right for this specific borrower, not into remembering which Schedule C line the policy requires for self-employment income verification.

The checklist also provides an audit trail. A completed checklist is documentation that verification occurred, what steps were taken, and which items passed or required correction. That documentation is what the institution needs to demonstrate, in a fair-lending examination or an adverse-action challenge, that its AI-assisted workflows were verified consistently, by every reviewer, for every file. A general instruction produces no such documentation: a reviewer who "checked the AI's work" but kept no record has left the institution unable to demonstrate what checking occurred.

A checklist is not bureaucracy. It is the documented proof that a principle was followed, not just stated.

Anatomy of a Verification Checklist for AI Lending Output

A verification checklist for AI lending output has five components, each serving a distinct governance purpose. Understanding the purpose of each component is what allows you to adapt the checklist to different use cases without losing the elements that make it defensible.

Component one: the header. Every checklist instance must record: the application or file identifier; the date and time of review; the name of the reviewing officer; the AI tool and version used to generate the output; and the specific output type being reviewed (credit memo, adverse-action package, income analysis, SAR narrative draft). The header is the audit trail anchor: it links this specific checklist instance to a specific file, a specific person, a specific tool version, and a specific output. Without it, a completed checklist is evidence that verification happened somewhere but not demonstrably for this file.

Component two: the existence checks. Before reviewing content, confirm that the AI output contains what it is supposed to contain. For an income analysis, existence checks confirm that all income sources identified in the file submission are represented in the output, that source citation fields are populated for every figure, that flag fields are present, and that the verification status field is present and set to a known value. Existence checks are fast and binary: either the element is present or it is not. A checklist that fails an existence check should stop and return the output to the AI tool with a note about what is missing, before any content review begins.

Component three: the source verification checks. For each figure, reason, or factual claim in the AI output, the reviewer confirms that: the cited source document is in the file; the figure in the output matches the figure at the cited location in the source document; and the figure represents the correct methodology (for income analysis: has the correct adjustment been applied, such as depreciation addback from Schedule C line 13?). Source verification checks are the most time-intensive component, but they are the component that catches hallucinated or incorrectly calculated figures. Each source verification check should produce a documented outcome: "verified" or "discrepancy: [description]."

Component four: the policy compliance checks. After verifying that the figures are accurate, confirm that the analysis correctly applies the institution's credit policy to those figures. Policy compliance checks ask: has the AI correctly identified which figures trigger a policy flag? Has the AI correctly applied the policy threshold (43 percent DTI ceiling, not some other figure)? Are the policy flags accurate (a file the AI flagged as compliant actually should have triggered a committee review exception)? Are there policy-relevant factors the AI omitted (a property type exception, a credit policy exclusion for a specific business category)? Policy compliance checks require the reviewer to know the credit policy, not just the file, and they are the component most likely to require escalation when the AI's policy application is wrong.

Component five: the completeness checks. Finally, confirm that nothing material is missing from the output. Completeness checks ask: are all income sources in the file represented in the income analysis? Are all denial factors represented in the adverse-action package (including policy-level factors that the AI may not have weighted as heavily as financial ratio factors)? For a BSA/AML (Bank Secrecy Act/Anti-Money Laundering) alert, are all accounts associated with the alert represented in the analysis? Completeness checks are distinct from existence checks: existence asks whether the required structural elements are present in the output; completeness asks whether the output's substantive content covers the full scope of the file's relevant information.

The Income Verification Checklist for Credit Analysis

The income verification checklist is the most universally applicable verification tool for AI-assisted credit work, because income analysis touches every credit decision and is the AI failure mode that directly produces incorrect debt-to-income (DTI) ratios. The following is a production-quality checklist, designed to run in 10 to 15 minutes per file for a reviewer familiar with the institution's income methodology.

INCOME VERIFICATION CHECKLIST
Application ID: _______________  Date/Time: _______________ 
Reviewer: _______________  AI Tool Version: _______________

EXISTENCE CHECKS (complete before content review)
[ ] Output contains all income sources flagged in the submission cover sheet
[ ] Source citation fields are populated for every income figure
[ ] Declining income flag field is present (Boolean, not empty)
[ ] Total qualifying income field is present
[ ] Verification status field is set to PENDING_HUMAN_REVIEW

--- STOP if any existence check fails. Return to AI tool with note. ---

W-2 EMPLOYMENT INCOME (complete for each employer)
Employer: _______________
[ ] Year 1 gross wages: Output $_______ | W-2 Box 1 Tax Year ____: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Year 2 gross wages: Output $_______ | W-2 Box 1 Tax Year ____: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Two-year average calculation verified: ($___ + $___)  /  2 / 12 = $_______
    [ ] MATCH   [ ] CALCULATION ERROR: ___________________
[ ] Overtime income (if included): Output $_______ | Pay stub source: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________ 

SELF-EMPLOYMENT INCOME (complete for each Schedule C entity)
Entity name: _______________
[ ] Net profit Year 1: Output $_______ | Sch. C Line 31, Tax Year ____: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Depreciation addback Year 1: Output $_______ | Sch. C Line 13, Tax Year ____: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Adjusted net income Year 1: Output $_______ | Verified calculation: $_______
    [ ] MATCH   [ ] CALCULATION ERROR: ___________________
[ ] Net profit Year 2: Output $_______ | Sch. C Line 31, Tax Year ____: $_______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Declining income assessment: Output flag = [true/false] | 
    Calculated: Year 2 ($______) vs Year 1 ($______) -- declining? [YES/NO]
    [ ] FLAG ACCURATE   [ ] FLAG ERROR: _______________________

ADDITIONAL INCOME SOURCES
[ ] Rental income: Sch. E reviewed [ ] | included? [YES/NO] | Amount: $_______
[ ] Social Security/pension: Award letter reviewed [ ] | Amount: $_______
[ ] Other sources: _______________  | Source doc reviewed [ ] | Amount: $_______
[ ] Completeness: All income sources in file are represented in output [ ]

POLICY COMPLIANCE
[ ] DTI calculated correctly: Monthly debt $______ / Monthly income $_______ = _____%
[ ] DTI threshold applied correctly (policy maximum: _____%)
[ ] DTI within policy ceiling? [YES / NO -- exception required]
[ ] Exception flag accurate in output? [YES / NO / N/A]

FINAL DISPOSITION
[ ] All discrepancies resolved
[ ] All flags verified
Verified total qualifying monthly income: $_______
Verification status updated to: [ ] APPROVED_FOR_LOS_ENTRY  [ ] RETURNED FOR CORRECTION
Reviewer signature/initials: _______________  Date: _______________

This checklist is designed to catch the three most common AI income analysis failure modes: incorrect figures (a stated income that does not match the source document), incorrect calculations (a correctly stated income figure that is arithmetically processed incorrectly), and missed sources (an income type present in the file that the AI omitted from its analysis). The checklist catches all three because it requires the reviewer to verify figures against sources, verify calculations arithmetically, and confirm completeness against the full file.

The Adverse-Action Verification Checklist

The adverse-action verification checklist is the most legally significant verification checklist in lending AI, because it governs the documents that create direct ECOA (Equal Credit Opportunity Act) and Regulation B (Reg B, 12 CFR Part 1002) legal exposure if wrong. Each adverse-action reason in a notice must be specific, accurate, and grounded in the actual file under Reg B Section 1002.9. A checklist that ensures each reason meets this standard is an institution's documented defense against a later challenge that its AI-generated notices contained inaccurate or unsupported reasons.

ADVERSE-ACTION VERIFICATION CHECKLIST
Application ID: _______________  Decision date: _______________
Reviewer: _______________  AI Tool Version: _______________

EXISTENCE CHECKS
[ ] Output contains at least three proposed adverse-action reasons
[ ] Each reason has a populated source_document citation field
[ ] Each reason has a reg_b_category field mapping it to a Reg B code
[ ] Each reason has verified: false (requires human review)
[ ] Verification status is PENDING_HUMAN_REVIEW
[ ] FCRA review_required flag is present

REASON-BY-REASON VERIFICATION (complete for each proposed reason)

Reason 1: _______________________________________________
[ ] Source document cited: _______________________________
[ ] Source document is in the file: [YES / NO -- locate before proceeding]
[ ] Figure in reason matches source document: Output: $______ | Doc: $______
    [ ] MATCH   [ ] DISCREPANCY: _______________________
[ ] Reason reflects this applicant's file, not a general description: [YES / NO]
[ ] Reason is specific enough for applicant to understand and dispute: [YES / NO]
[ ] This factor contributed to the denial under the credit policy: [YES / NO]
[ ] Reason verified? [YES / NO -- note if NO]
[ ] verified_by: _______________ Date: _______________

Reason 2: _______________________________________________
[Repeat all checks above]

Reason 3: _______________________________________________
[Repeat all checks above]

COMPLETENESS CHECK
[ ] All material denial factors represented (including policy exceptions, not just financial ratios)
[ ] Policy-level denial factors present (property type exclusion, geographic restriction, etc.): [NONE / YES -- describe: _______________]
[ ] Omitted material factor: [NONE / YES -- describe and add to reasons: _______________]

FCRA DETERMINATION (complete separately from reason verification)
[ ] Was a consumer report (credit report) obtained for this decision? [YES / NO]
[ ] If YES: Consumer reporting agency identified: _______________
[ ] FCRA disclosure completed by: _______________ Date: _______________

FINAL DISPOSITION
[ ] All reasons verified against source documents
[ ] Reason set is complete
[ ] FCRA determination documented
Verification status: [ ] APPROVED_FOR_NOTICE_ISSUANCE  [ ] RETURNED FOR CORRECTION
Reviewer signature: _______________  Date: _______________

Two elements of this checklist require specific explanation. First, the "Reason reflects this applicant's file, not a general description" check is designed to catch the hallucination failure mode described throughout this program: an AI that drafts a reason that is accurate as a description of a typical file with this profile but does not actually reflect the specific factors that drove this specific decision. The check requires the reviewer to ask: if I were this borrower and I read this reason, could I open my file and find the specific data point being referenced? If the answer is no, the reason fails the specificity check regardless of whether it sounds reasonable.

Second, the "This factor contributed to the denial under the credit policy" check addresses the incompleteness failure mode: an AI that identifies real, file-grounded financial factors but misses the actual primary denial reason, which may be a policy exception, a geographic restriction, or a product-type exclusion that the AI did not weight as heavily as the financial ratios. The review of policy-level denial factors in the completeness check is essential for files where the AI's proposed reasons are accurate but incomplete.

The BSA/AML Verification Checklist for SAR Narratives

BSA/AML (Bank Secrecy Act/Anti-Money Laundering) work presents a distinct verification challenge: the AI's output is a SAR (Suspicious Activity Report) narrative draft that will be reviewed by a BSA officer before any filing decision. The BSA officer who uses a checklist to review the AI's draft is doing two things simultaneously: verifying the draft's factual accuracy (does every transaction amount, date, and account reference in the narrative match the underlying alert data?), and assessing the draft's analytical completeness (did the AI surface all the relevant transaction patterns, and are there open questions the BSA officer needs to resolve before deciding whether to file?). The checklist for SAR narrative review is therefore both a fact-check and a completeness-check, with the addition of a hard boundary check: confirming the AI has not made any characterization that constitutes a suspicious-activity determination or a SAR filing recommendation.

BSA/AML SAR NARRATIVE REVIEW CHECKLIST
Alert ID: _______________  Review date: _______________
BSA Analyst: _______________  AI Tool Version: _______________

EXISTENCE AND BOUNDARY CHECKS
[ ] Narrative contains no SAR filing recommendation: [CONFIRMED / FOUND -- describe: ___]
[ ] Narrative contains no characterization of activity as suspicious or non-suspicious: 
    [CONFIRMED / FOUND -- describe: _______________]
[ ] sar_recommendation field is null: [CONFIRMED / ERROR]
[ ] sar_decision field is null: [CONFIRMED / ERROR]
[ ] bsa_officer_review_required field is true: [CONFIRMED / ERROR]

--- STOP if any boundary check fails. SAR decision boundary has been violated. ---

FACTUAL ACCURACY VERIFICATION
[ ] Alert ID in narrative matches alert system: [MATCH / ERROR]
[ ] Account IDs in narrative match alert data: [MATCH / ERROR -- note: _______________]
[ ] Transaction count: Narrative says ___ | Alert data shows ___: [MATCH / ERROR]
[ ] Total cash volume: Narrative $_______ | Alert data $_______: [MATCH / ERROR]
[ ] Transactions near CTR threshold: 
    Narrative count: ___ | Alert data count: ___: [MATCH / ERROR]
[ ] Date range: Start _______ End _______: [MATCH / ERROR]
[ ] Individual transactions cited: each verified against alert records [ ]
[ ] CTR filings count: Narrative says ___ | Records show ___: [MATCH / ERROR]

PATTERN DESCRIPTION ACCURACY
[ ] Transaction amounts cited in narrative are accurate: [YES / NO -- note discrepancies]
[ ] Transaction dates cited are accurate: [YES / NO -- note discrepancies]
[ ] Account relationships described are accurate: [YES / NO -- note discrepancies]
[ ] Statutory reference (if present) is appropriate: [YES / NO / N/A]
[ ] Pattern_flag value aligns with described transactions: [YES / NO]

COMPLETENESS CHECK
[ ] All accounts in alert data are represented in narrative: [YES / NO -- list omitted: ___]
[ ] All transaction types are represented: [YES / NO -- note omitted: _______________]
[ ] Open questions field reviewed: [YES] -- questions to resolve before SAR decision:
    1. _______________________________________________
    2. _______________________________________________
    3. _______________________________________________
[ ] Additional context needed before SAR decision: [NONE / YES -- describe: ___________]

BSA OFFICER DETERMINATION (separate from narrative review)
[ ] Open questions from AI output reviewed and assessed
[ ] Decision: [ ] FILE SAR  [ ] CLOSE ALERT  [ ] CONTINUE MONITORING
[ ] Decision rationale: ______________________________________________
[ ] Decision date: _______________  BSA Officer: _______________

The hard boundary check at the top of this checklist is non-negotiable. FinCEN (the Financial Crimes Enforcement Network), the Treasury bureau to which SARs are submitted, has been explicit that SAR filing decisions must be made by a responsible individual at the institution with the authority and knowledge to make them. An AI tool that makes the decision, even implicitly through a strong recommendation, is operating outside the boundary of its authorized role. The checklist's boundary check confirms this boundary was respected before any content review begins.

Running the Checklists Consistently Across a Team

A checklist that exists but is not run the same way by every member of the team is not a governance control. Consistency requires three elements: a standard version of the checklist, a defined standard for what "completed" means, and a quality review cycle that catches and corrects inconsistent application before it becomes a pattern.

Standard version control. Every team member must use the same version of the checklist, updated whenever the institution's credit policy, AI tool, or regulatory requirements change. Checklist versions should be maintained under the same version control system as the institution's system prompts and AI output schemas, with change dates, change rationale, and the approver's identity recorded. When the credit policy changes, the checklist changes to match: the DTI threshold in the policy compliance section must reflect the current ceiling, not last year's. When the AI tool is updated and its output format changes, the existence checks must be updated to match the new structure.

Defining "completed." A completed checklist is one in which every check was performed and the outcome was recorded. A checklist with blank items is not completed; it is partially completed, and partially completed is not documented evidence of verification. The institution's policy should specify that every item must be checked: if a specific income type is not applicable (no rental income in this file), the reviewer checks "N/A" rather than leaving the item blank. N/A is an outcome; blank is ambiguous. This distinction matters in an examination when a compliance officer needs to demonstrate that the reviewer affirmatively considered each item.

Quality review cycle. Checklists should be reviewed by a second reviewer on a sample basis: some percentage of files each week (or each month, depending on volume) should have the checklist reviewed against the actual AI output and source documents to confirm that the reviewer's documented outcomes are accurate. This second-level review is not primarily about catching reviewer errors (though it does that); it is primarily about calibrating the team's understanding of each checklist item so that "verified" means the same thing to every reviewer. The compliance officer's 2026 review of eleven files in the opening scenario would have been the quality review catching a systematic problem that individual checklists had not surfaced. An institution that runs this quality review proactively finds its calibration problems before an examiner does.

Operationalizing the checklist at scale:

• Build the checklist into the LOS workflow as a required step before adverse-action notices can be released or income figures can advance to the underwriting decision stage. A workflow gate that requires a completed checklist ID before a file progresses is the technical implementation of the consistency requirement.
• Store completed checklists electronically, linked to the application file by application ID, in the document management system. Paper checklists that are completed and then filed separately from the loan file are not useful in an examination when the examiner wants to see the checklist for a specific application.
• Treat the checklist as a model-risk control under OCC Bulletin 2026-13 (the April 2026 interagency model-risk update). It requires documentation, versioning, ownership, and a change process. The person responsible for the checklist's content should be identified explicitly, with the same specificity the institution applies to system prompt ownership.
• When a checklist reveals a systematic problem (the AI tool is consistently misapplying the depreciation addback from Schedule C, for example), treat it as a model performance issue, not just an individual reviewer correction. The systematic error belongs in the model-risk file, with a note on when it was identified, how it was corrected, and what review was conducted to confirm the correction held.

Checklists as Fair-Lending Evidence

The final dimension of verification checklists in a lending AI context is their role as fair-lending evidence. Fair-lending examinations under ECOA look not just at outcomes (disparate denial rates) but at processes (whether the institution's credit decision process was applied consistently across all applicants). Verification checklists are one of the most direct forms of process consistency evidence: they show that the same steps were taken for every file, by every reviewer, regardless of which demographic group the applicant belongs to.

An institution that can demonstrate uniform checklist completion across a representative sample of approved and denied files, across all loan officer reviewers, and across different demographic groups has evidence that its AI verification process was consistent. That consistency evidence supports the institution's defense in a fair-lending examination or an individual ECOA claim: the process was the same for this applicant as it was for every other applicant, and the adverse-action reasons produced by that process were specifically verified against the file before the notice was sent.

The inverse is also important. An institution that cannot produce completed verification checklists for a sample of denied applications cannot demonstrate that its AI-assisted adverse-action workflow was applied consistently. Even if the adverse-action notices look correct, the absence of documented verification means the institution cannot rule out that some denials were verified carefully and some were not, and cannot demonstrate that the care applied to verification did not vary by demographic group. Absence of documentation is itself a fair-lending concern in an AI-assisted workflow, because it prevents the institution from demonstrating that the AI was used consistently.

Under OCC Bulletin 2026-13's model-risk framework, the verification checklist is part of the model's ongoing monitoring controls. Model monitoring under the 2026 guidance requires the institution to demonstrate that AI model outputs are reviewed on an ongoing basis, that systematic errors are identified and corrected, and that the model's performance is consistent over time. A well-maintained verification checklist system is the operational mechanism for all of these requirements: it catches individual errors (source verification checks), catches systematic errors (quality review cycle), and creates the documentation the institution needs to demonstrate ongoing oversight.

Key Takeaways

• General instructions to "verify AI output" fail under time pressure because they require each reviewer to independently determine what checking means on each occasion. A checklist transfers the cognitive load of "what to check" to the checklist, reserving the reviewer's expertise for substantive judgment.
• A completed verification checklist is the documented proof that a verification principle was followed, not just stated. In a fair-lending examination or an adverse-action challenge, a completed checklist is the institution's evidence that AI output was reviewed consistently, by every reviewer, for every file.
• The five components of a verification checklist are: the header (audit trail anchor), existence checks (structural completeness), source verification checks (figure accuracy), policy compliance checks (correct application of credit policy), and completeness checks (nothing material omitted).
• The adverse-action verification checklist must include a per-reason check asking whether the stated reason reflects this specific applicant's file rather than a general description, and whether this factor actually contributed to the denial under the credit policy. These checks catch both the hallucination failure mode and the incompleteness failure mode.
• The BSA/AML SAR narrative checklist must begin with a hard boundary check confirming the AI made no SAR filing recommendation and no characterization of activity as suspicious or non-suspicious. These are decisions that belong to the BSA officer; a checklist that catches boundary violations before content review is the governance control that enforces that boundary.
• Checklist consistency requires standard version control (every reviewer uses the same version), a defined standard for completion (every item marked, N/A for not applicable, never blank), and a quality review cycle (sample-based second review that calibrates the team's shared understanding of what each check means).
• Consistent checklist completion across all reviewers and all applicant groups is fair-lending process evidence: it demonstrates the AI verification process was applied the same way regardless of who the applicant was. The absence of documented verification checklists prevents the institution from making this demonstration.
• Under OCC Bulletin 2026-13's model-risk framework, the verification checklist system is an ongoing monitoring control. It catches individual and systematic AI errors, creates documentation of ongoing oversight, and satisfies the model-risk requirement to demonstrate that AI outputs are reviewed and that systematic errors are identified and corrected.