The compliance officer at a mid-size regional bank discovered the problem on a routine internal review. The institution had deployed an AI assistant in the underwriting department six months earlier. Underwriters were using it to answer policy questions, draft credit memo sections, and check whether a specific loan structure was within the institution's commercial real estate lending guidelines. The AI was giving answers. The answers were often confident, detailed, and plausible. But the compliance officer noticed that several of the answers cited guidelines that the institution's credit policy committee had revised eight months ago, before the AI tool was deployed. The AI had been trained on a version of the policy manual that no longer existed. When an underwriter asked whether a 78% loan-to-value ratio (LTV, the loan amount divided by the appraised or purchase value of the collateral) was within policy for a five-year balloon commercial real estate loan, the AI answered yes, citing the 80% LTV cap in the old policy. The current policy, revised after two commercial real estate charge-offs, set the cap at 75%. The underwriter, trusting the AI answer, had approved three loans in the intervening months that were outside current policy. None had yet defaulted. All three required retroactive exception documentation. The AI was accurate relative to what it knew. What it knew was eight months stale.

Why Grounded Retrieval Is the Foundation of Safe Lending AI

A generative AI model that operates from its training data alone is an unreliable partner in a regulated lending environment. Its training data has a cutoff date, and lending policy changes continuously in response to credit performance, market conditions, regulatory guidance, and board decisions. Its training data is also aggregated from many sources, and those sources include generic banking information that may differ from the institution's specific requirements on any particular point. When an underwriter asks the model whether a transaction is within policy, the model's answer reflects what is generally true of similar institutions and transactions based on its training data, not what is specifically true of this institution's current policy manual.

Retrieval-augmented generation, commonly abbreviated as RAG (retrieval-augmented generation, the technique of connecting a generative AI model to a specific document corpus so that its answers are grounded in retrieved content rather than training-data patterns), addresses this problem directly. In a RAG architecture, the AI model does not answer from training data alone. Before generating a response, the system retrieves the most relevant passages from a curated document corpus, which in a lending context means the institution's current credit policy, the loan origination system (LOS) rules, the applicable regulatory guidance, and the specific documents in the borrower's loan file. The model then generates its response grounded in those retrieved passages, citing them in the output so the user can verify the answer against the source.

The shift from training-data-only to retrieval-grounded is the single most important architectural decision in deploying AI for lending workflows. It converts the AI from a system that "knows" generic banking principles to a system that "reads" the institution's current, specific documents before answering. The distinction is the difference between an AI that confidently cites a stale policy and an AI that retrieves the current policy and cites the relevant section. OCC Bulletin 2026-13, the April 2026 interagency model-risk update that superseded OCC 2011-12 and brought generative AI under model-risk, fair-lending, third-party, and board-governance expectations, does not prescribe RAG by name. But its requirement that institutions understand and document the basis for AI outputs in credit decisions is effectively a grounding requirement: the institution must be able to explain what the AI's answer was based on, and "training data patterns" is not an acceptable answer for a policy or file-specific question.

The Two Retrieval Domains: Policy and File Data

In a lending context, grounded retrieval operates over two distinct document domains, each with different characteristics, update cadences, and retrieval requirements.

Domain 1: Credit Policy and Regulatory Guidance. This domain includes the institution's credit policy manual (covering all loan types, underwriting standards, exception thresholds, and credit committee authorities), the LOS configuration rules and decisioning parameters, the institution's fair-lending and ECOA (Equal Credit Opportunity Act, the federal statute prohibiting credit discrimination on enumerated protected bases) compliance policies, Regulation B (Reg B, the CFPB's implementing regulation for ECOA, 12 CFR Part 1002) guidance and adverse-action requirements, applicable OCC guidance including OCC Bulletin 2026-13, and any internal memos or guidance letters issued by the compliance or credit policy team between formal policy revisions.

The policy domain has three important characteristics. It is authoritative: the institution's policy manual is the binding rule, not the AI's interpretation of general banking practice. It changes on a defined but irregular schedule: the credit policy committee may update the manual quarterly, annually, or in response to specific events. And it is hierarchical: when the policy manual conflicts with an older internal guidance memo, the manual supersedes the memo; when applicable regulation conflicts with the policy manual, the regulation supersedes the policy. The retrieval system must respect this hierarchy, and the document corpus must be structured to reflect it.

Practically, this means the policy domain corpus should include metadata for each document: effective date, supersession relationships (which documents this one supersedes, which documents supersede this one), the policy area covered, and the loan types or programs to which it applies. When the AI retrieves a policy document to answer a question, the retrieval output should include the effective date and any supersession notices so the user can confirm they are working from the current version. An AI system that retrieves the most semantically similar policy passage without checking effective dates will reproduce the failure mode from the opening story, just with better-looking citations.

Domain 2: The Loan File. This domain includes every document in the specific borrower's loan file: the application, the credit report, pay stubs, W-2s, federal tax returns, bank statements, asset statements, the appraisal, the purchase and sale agreement, title commitment, and any borrower-supplied supplemental documentation. For commercial credits, the file also includes operating statements, rent rolls, entity documents, and guarantor financial statements. The loan file is specific, bounded, and changes only when new documents are added to the file by the processor or underwriter.

The file domain has different characteristics from the policy domain. It is specific to a single borrower and transaction: the AI should retrieve from this file and no other when answering questions about this borrower's income, assets, or collateral. It is sensitive: the file contains personal financial information that must be handled under the institution's privacy and data-security policies, and the retrieval system must enforce access controls so that an AI assistant working on file A cannot inadvertently retrieve content from file B. And it is dynamic during processing: documents are added to the file over the course of the origination process, and the retrieval corpus for the file must be updated as new documents arrive so that the AI's answers reflect the current state of the file rather than a snapshot from the last corpus refresh.

The combined retrieval architecture for a lending AI system manages both domains simultaneously, routing questions to the appropriate domain (or both, when the question requires comparing a file-specific figure to a policy threshold) and structuring the retrieval output to make it clear which domain each retrieved passage came from. When the underwriter asks "does this borrower's income qualify under the self-employment calculation method in our policy?", the system should retrieve the self-employment income calculation section from the policy manual and the relevant income figures from the loan file, present both, and allow the underwriter to confirm that the calculation is correct. The AI does the retrieval and the synthesis; the underwriter confirms the result.

Building the RAG Corpus for a Lending Institution

Building a RAG (retrieval-augmented generation) corpus for a lending institution is a document management and data engineering task before it is an AI task. The quality of the retrieval output is bounded by the quality and completeness of the corpus. A corpus that is missing three current credit policy sections, contains two superseded policy versions with no supersession metadata, and has no mechanism for regular updates will produce retrieval outputs that look grounded but are unreliable in exactly the ways that matter most: policy thresholds, income calculation methods, and exception authorities.

The practical steps for building a policy domain corpus are as follows.

Step 1: Inventory all authoritative policy documents. Starting with the credit policy committee's most recent complete policy manual, enumerate every section and annex. Add to the inventory all supplemental guidance issued since the last manual revision (board-approved exception memos, compliance-team interpretive letters, regulatory guidance adopted by reference). For each document, record the effective date, the loan types or programs covered, and whether it supersedes or is superseded by any other document in the inventory.

Step 2: Resolve conflicts and gaps in the inventory. Before loading any documents into the corpus, the compliance team should review the inventory for conflicts (two documents stating different policy thresholds for the same parameter) and gaps (loan types or situations not covered by any current document). Conflicts and gaps should be resolved by the appropriate authority (credit policy committee for underwriting standards, compliance for regulatory guidance interpretation) before the corpus is built. An AI system cannot resolve a genuine policy conflict; it will retrieve whichever version is most semantically similar to the question asked, and that result may be the wrong version. The conflict resolution must happen in the document before the document enters the corpus.

Step 3: Structure documents for retrieval. PDF scans without selectable text cannot be reliably chunked and indexed for retrieval. Every document in the corpus should be in a text-accessible format, with clear section headings, consistent numbering, and metadata fields populated. For the policy manual, this typically means converting it from its current format (often a Word document or a locked PDF) into a structured format with clean metadata. The investment in document structure pays dividends in retrieval precision: a well-structured corpus retrieves the right section more reliably than one where the sections are long, unnumbered, and formatted inconsistently.

Step 4: Build the chunking and embedding pipeline. RAG systems work by dividing documents into chunks (sections of a defined length, typically 200 to 800 tokens), embedding each chunk as a vector (a numerical representation that captures the semantic meaning of the text), and storing those vectors in a searchable index. When a query arrives, the system embeds the query and retrieves the chunks whose embeddings are most similar to the query embedding. The chunking strategy matters: chunks that are too short lose context, chunks that are too long retrieve irrelevant content. For a credit policy manual, chunking at the section level (one chunk per numbered section or subsection) is generally more reliable than chunking at a fixed token length, because policy sections are designed to be coherent units.

Step 5: Implement the effective-date filter. Every chunk in the policy corpus should carry the effective date of the document it came from. The retrieval pipeline should filter the candidate set to chunks from documents with effective dates on or before the current date and no supersession by a more recent document. This filter prevents the system from retrieving stale policy sections even if they are semantically similar to the query. The compliance officer in the opening story's institution was dealing with a system that lacked this filter: the old 80% LTV policy section was semantically indistinguishable from the new 75% LTV section for most retrieval purposes, because the text was nearly identical except for the threshold figure. An effective-date filter would have excluded the old section from the retrieval candidate set.

Step 6: Build the update workflow. The policy corpus is not a build-once artifact. Every time the credit policy committee revises the policy manual, every time the compliance team issues new interpretive guidance, and every time a regulatory update is adopted by reference, the corpus must be updated. The update workflow should specify who is responsible for adding new documents to the corpus, what metadata is required, how superseded documents are marked (removed from the active retrieval set, preserved in an archive for audit purposes), and how the update is tested before it is live for production use. A corpus update that introduces a new policy section with an incorrect effective date, or that fails to mark the superseded version as inactive, can cause the same class of failure as the original ungrounded deployment. The update workflow is as important as the initial corpus build.

Grounding AI on the Loan File

File-domain retrieval is operationally different from policy-domain retrieval in three important ways. The corpus is per-file, not shared: each borrower's file is its own retrieval universe, and the system must enforce that an AI assistant working on a given file retrieves only from that file's documents. The documents are added dynamically throughout the origination process: the corpus for a file that is at the income-verification stage is different from the corpus for the same file at the underwriter-review stage, and the retrieval system must reflect the current state of the file. And the documents contain personally identifiable financial information (PII) that requires strict access controls and data governance.

For file-domain retrieval, the practical implementation involves integrating the retrieval system with the institution's LOS document management system so that the retrieval corpus for each file is automatically built from the documents stored in the LOS file folder. When a processor uploads a new W-2 to the file, the document is added to the file's retrieval corpus. When the AI assistant is queried about the borrower's income, it retrieves from the corpus that includes the uploaded W-2, not from a static snapshot that may predate the document upload.

The access-control requirement is enforced at the retrieval index level: each file's corpus exists in an isolated index that is associated with the file's LOS identifier. The AI assistant can only query the index associated with the file the user has open in the LOS. A user who has the authority to open file A does not have access to the retrieval index for file B, even if the AI assistant is the same system serving both users. This access control mirrors the LOS's document-level permissions and should be implemented as a gate on every retrieval query, not as a trust control on the AI assistant's behavior.

Within the file corpus, the retrieval system should also understand the document hierarchy that applies in lending: a more recent document supersedes an older one for the same income period (the 2024 W-2 supersedes the 2023 W-2 for current-year income verification), a verified and certified document carries more weight than a borrower-supplied estimate, and a document classified as "required" by the loan program checklist carries different significance than a supplemental document. Metadata on each document in the file corpus should capture the document type, the period covered, the upload date, and the classification (required, supplemental, exception support). The retrieval output should present this metadata alongside the retrieved content so that the underwriter can assess the reliability of the retrieved information in context.

When the AI assistant retrieves a figure from the loan file, it must cite the specific document, the page, and the field. An income figure that the AI reports should be accompanied by: "Source: 2024 W-2, Employer: ABC Manufacturing, Box 1 Wages: $94,200, uploaded by processor [name] on [date], document status: required, received." This citation structure allows the underwriter to verify the AI's retrieval, confirm that the document was the current applicable version, and trace any discrepancy between the AI's answer and the underwriter's own reading of the document. Citation is not optional in file-domain retrieval; it is the chain-of-custody that makes the retrieval output auditable.

Managing Hallucination Risk in a RAG System

RAG substantially reduces but does not eliminate hallucination risk. A well-designed RAG system grounds the AI's responses in retrieved content, which means the model is less likely to generate a plausible-but-invented answer when the relevant content is present in the corpus. But several failure modes remain that a lending institution must design against.

Retrieval failure. If the relevant content is not in the corpus (because the policy section was not loaded, because the document was uploaded to the wrong file folder, or because the query is phrased in a way that does not match any chunk semantically), the retrieval step returns nothing or returns irrelevant content. In this case, the AI may generate a response based on its training data, effectively falling back to the ungrounded behavior the RAG architecture was designed to prevent. The system must be designed to recognize low-confidence or empty retrieval results and respond with "I could not find relevant content in the policy corpus or loan file for this question" rather than generating an answer from training data. A system that always produces a confident answer regardless of retrieval confidence is more dangerous than one that acknowledges uncertainty, because the confident wrong answer is the failure mode that costs institutions money and causes compliance events.

Synthesis error. Even when the retrieval step returns the correct passages, the model may synthesize them incorrectly, particularly when the answer requires combining information from multiple retrieved chunks or applying a formula to retrieved figures. For example, if the AI retrieves the self-employment income calculation method from the policy and the Schedule C net income from the loan file, and the calculation method requires a two-year average with a specific add-back treatment, the AI's synthesis may apply the formula incorrectly. The verification requirement for synthesis outputs (the underwriter checks the calculation, not just the retrieved inputs) remains in force even in a RAG system. Grounding reduces the probability of raw hallucination; it does not eliminate the need for human verification of calculations and multi-step reasoning.

Context window limits. When a loan file is large (a commercial real estate file may contain hundreds of pages of financial documents), not all of the file's content can be included in a single AI context window. The retrieval step prioritizes the most relevant chunks, but the most relevant chunks as determined by embedding similarity may not be the most relevant chunks for the specific question. A question about the borrower's entity structure may retrieve the formation documents but miss a later amendment that changes the ownership percentages. The underwriter must understand that the AI is working from retrieved excerpts, not from a complete reading of the file, and must apply judgment about what the AI might have missed.

Out-of-date corpus without update workflow. The corpus staleness problem from the opening story is not solved by building a RAG system once. Without an active update workflow, the corpus drifts out of currency exactly as the opening institution's AI tool did, except now the stale content looks more authoritative because it is retrieved and cited rather than generated from training patterns. The update workflow described in the corpus-building section is the structural defense against this failure mode. Without it, a RAG deployment is a grounded-at-deployment, ungrounded-over-time system.

The practical guard against these failure modes is the verification principle that runs through this entire program: AI output in a lending workflow is a draft, a recommendation, or a retrieval result, and human review before reliance is the control. In a RAG system, the human review step is supported by citations that make verification faster, but it is not eliminated by those citations. The underwriter who reads "DTI of 43.2%, source: borrower-supplied income worksheet dated April 15" should still check the LOS to confirm the income worksheet is the most current applicable document and that the AI's DTI calculation is arithmetically correct from the retrieved figures. The citation makes the verification faster; it does not make it unnecessary.

RAG in Practice: A Worked Example

To make the architecture concrete, consider how a RAG-grounded AI assistant handles a specific underwriting question in a residential mortgage context. The underwriter is reviewing a file for a self-employed borrower who operates a sole proprietorship. The question is: does this borrower's qualifying income meet the threshold for the requested loan amount?

In a RAG-grounded system, the AI assistant processes this question by first decomposing it into the retrieval queries it needs to answer: (1) what is the institution's policy for calculating qualifying income for a self-employed sole proprietor? (2) what income figures are in the borrower's loan file? (3) what is the income threshold for the requested loan amount given the loan terms and the standard DTI limit?

For query (1), the system retrieves from the policy corpus. It finds the income calculation policy section (effective date: March 1, 2026, supersedes: October 2024 version). The retrieved section states: "Self-employment income for a sole proprietor is calculated as a two-year average of Schedule C net income plus non-cash expenses (depreciation, depletion, amortization) as reported on lines 8d, 12, and 13 of IRS Form Schedule C, less applicable business-use deductions per current IRS guidance, using the two most recent federal tax returns filed by the borrower."

For query (2), the system retrieves from the loan file corpus. It finds the 2024 federal tax return (Schedule C, net income: $67,400; depreciation: $8,200; depletion: $0; amortization: $1,400) and the 2023 federal tax return (Schedule C, net income: $59,100; depreciation: $7,600; depletion: $0; amortization: $1,200). Both documents are verified as "required, received, current year and prior year" per the loan type checklist.

For query (3), the system retrieves from the policy corpus. It finds the DTI limit for the applicable loan type: maximum DTI of 43% for conventional fixed-rate products. It retrieves the proposed loan terms from the LOS active loan record: $380,000 loan at 7.125% for 30 years, monthly principal and interest payment of $2,559. It retrieves from the credit report (also in the file corpus): total existing monthly obligations of $847 (auto loan, student loan, minimum credit card payments).

With these retrieved inputs, the AI synthesizes: "Per the March 2026 self-employment income policy, the two-year average qualifying income is: [(67,400 + 8,200 + 1,400) + (59,100 + 7,600 + 1,200)] divided by 24 months = [(77,000) + (67,900)] divided by 24 = 144,900 divided by 24 = $6,037.50 per month. Proposed DTI: (2,559 + 847) divided by 6,037.50 = 3,406 divided by 6,037.50 = 56.4%. This exceeds the 43% DTI limit for the loan type. Sources: income policy [March 2026 version, section 4.3.2]; 2024 Schedule C [file, uploaded April 22]; 2023 Schedule C [file, uploaded April 22]; DTI policy [March 2026 version, section 6.1]; proposed terms [LOS active record]; credit obligations [credit report, pulled April 19]."

The underwriter receives this synthesis with full citations. The underwriter's job is to verify: is the income policy citation current? (Yes, effective March 2026.) Are the Schedule C figures accurate from the documents? (Underwriter spot-checks: yes.) Is the arithmetic correct? (Underwriter confirms: 144,900 divided by 24 equals 6,037.50; 3,406 divided by 6,037.50 equals 56.4%.) Is the 43% DTI limit the correct policy threshold for this loan type? (Underwriter confirms: yes.) Conclusion: file does not qualify under current policy at the requested loan amount.

The underwriter now has a basis for the credit decision that is grounded in current policy and current file data, with citations that allow verification and that will be preserved in the LOS record as part of the audit trail. The AI did not make the decision; it retrieved the policy, retrieved the file data, synthesized the calculation, and presented it with citations. The underwriter verified and decided. This is the workflow that OCC 2026-13 contemplates: AI as a retrieval and synthesis engine, human as the decision-maker and verifier.

Key Takeaways

• RAG (retrieval-augmented generation) grounds AI answers in the institution's current, specific documents rather than in generic training-data patterns, converting the AI from a system that "knows" general banking principles to one that "reads" the current policy and the specific loan file before answering.
• A lending RAG system operates over two distinct domains: the policy domain (the institution's credit policy manual, LOS rules, applicable regulatory guidance, and internal compliance guidance) and the file domain (the specific borrower's loan documents, accessed via the LOS document management system with per-file access controls).
• The policy corpus requires effective-date metadata and supersession tracking: the most dangerous class of RAG failure in a lending context is retrieval of a superseded policy section that is semantically similar to the current section but states a different threshold or calculation method, exactly the failure mode that caused the three non-conforming loans in the opening story.
• File-domain retrieval must enforce per-file access controls so that an AI assistant working on one borrower's file cannot retrieve content from another file, and must integrate with the LOS document management system to stay current as documents are added during origination.
• RAG reduces but does not eliminate hallucination risk: retrieval failure (no relevant content found), synthesis error (incorrect combination of retrieved inputs), and context-window limits (relevant sections not retrieved) all require the same human verification discipline that governs AI use across all lending workflows.
• Every AI output from a RAG system in a lending workflow must cite the specific retrieved source, including document name, section, and effective date, so the underwriter can verify the citation and the LOS can preserve it in the audit trail as evidence of the basis for the AI's contribution to the credit analysis.
• The corpus update workflow is as important as the initial corpus build: without an active process for adding new policy documents, marking superseded versions inactive, and testing updates before live deployment, the RAG system reproduces the staleness failure mode of ungrounded AI over time, just with better-looking citations attached to the stale content.
• The worked example, in which a RAG system retrieves the income policy, the tax return figures, and the DTI limit to produce a cited income calculation that the underwriter verifies, illustrates the proper division of labor: AI retrieves and synthesizes, human verifies and decides, and the LOS preserves both the AI output and the human decision as distinct, attributable events in the audit trail.