โ†
AI for Banking & Lending
Strategic ยท M10 ยท lesson 10 of 20 ยท queued
Preview โ€” browse every lesson free. Enroll to mark lessons complete, open partner links and save your progress. Login & enroll โ†’
Exam Readiness
๐Ÿ“–
now learning

Exam Readiness

15 min

The examiner's first request was a single sentence in an email sent the afternoon before the field work began: "Please have available the AI model inventory, the most recent fair-lending testing results for any AI or machine learning model used in credit decisioning, and the adverse-action audit trail for the current calendar year for any product where AI is involved in the decisioning workflow." The model risk manager read that sentence and felt, briefly, the specific discomfort of someone who knows exactly where the gaps are. The inventory existed, but it had not been updated in seven months. The fair-lending testing results existed, but they were in three different systems managed by three different teams, and they had not been consolidated into the model risk files as OCC Bulletin 2026-13, issued in April 2026 by the Office of the Comptroller of the Currency (OCC), the Federal Reserve, and the Federal Deposit Insurance Corporation (FDIC), requires. The adverse-action audit trail existed for the bank's traditional products but had not been extended to cover the outputs of the institution's new AI-assisted decisioning workflow, which had been in production for nine months. None of these were catastrophic deficiencies. All of them were findings. All of them were findings that would not have been findings if the institution had spent four hours per quarter assembling the exam file rather than thirty-six hours during the examination period assembling a substitute for it. The lesson of exam readiness in AI lending is not that the examiners are coming. It is that the work of assembling a defensible file and the work of operating a defensible AI program are the same work. Do it once, do it correctly, and put it where the examiner can find it. (The institution, individuals, and documentation gaps in this scenario are a composite illustration drawn from common examination patterns; they do not describe any single institution's experience.)

What the Examiner Is Actually Looking For

An OCC examiner reviewing an institution's AI lending program under 2026-13 is not trying to find a technical failure in a model. They do not have the data science background to evaluate whether a gradient-boosted ensemble is better calibrated than a logistic regression. What they are evaluating is governance: did the institution know what models it was running, did it validate and monitor them, did it test for fair-lending risk, does it know what the models produce, and does it have a documented accountability chain from the model's output to a human being who owns the decision? The examiner's file request is a governance test, not a technical audit.

This framing matters for how you prepare. You cannot prepare for an AI lending examination by polishing a model. You prepare by building the file that demonstrates your governance is functioning. The file answers the following questions before the examiner asks them:

What AI models are you running, and why? The model inventory answers this. It should show every AI and ML model used in any lending or credit function, including vendor-provided tools, with the model's purpose, risk rating, deployment date, and current status.

Are those models validated? The model-risk file for each model answers this. It should show the validation status, the findings from the most recent validation, the next scheduled revalidation date, and the open findings register with remediation status.

Are those models producing fair outcomes for protected-class applicants? The fair-lending testing record in the model-risk file answers this. It should show the methodology, the results by demographic stratum, the disparity ratios, whether any ratios crossed the alert threshold, what the institution did about any alerts, and whether the institution has conducted and documented a less-discriminatory-alternative (LDA) search for any features identified as potential proxy variables.

Are the adverse-action notices for AI-influenced decisions compliant with Regulation B? The adverse-action audit trail answers this. It should show the reason codes generated for a representative sample of denials, the process by which those codes were generated (model output, human review, or hybrid), and evidence that the codes are specific, accurate, and consistent with the basis for each decision.

Who is accountable when something goes wrong? The governance record answers this. It should show the governance committee structure, the model owner for each model, the escalation path for findings and incidents, and the board reporting chain.

If all five of those questions can be answered by directing the examiner to a specific, organized, current document or file, the examination will proceed as a review process. If any of them requires assembling documents from multiple systems, retrieving email threads, or explaining what the documents mean because they do not stand on their own, the examination will produce findings.

The Pre-Exam File Checklist

The pre-exam file is not something you build for the examination. It is something you maintain continuously and verify before the examination. The following checklist should be completed no less frequently than quarterly and should be completed in full before any examination cycle begins. Each item is either complete (the document exists, is current, and is organized in the model-risk file) or it is a gap that must be remediated before the exam opens.

Model Inventory

  • The lending AI model inventory is current: all models deployed in the past twelve months appear in the inventory, including any models deployed by the technology team or a vendor without going through the governance committee approval process.
  • Each inventory entry includes: model name and version, vendor name if applicable, purpose and function, risk rating, deployment date, model owner (named individual), validation status and date, fair-lending testing status and date, open findings count, and monitoring cadence.
  • The inventory has been reviewed and confirmed by the model risk manager within the past ninety days.
  • Retired models appear in the inventory with their retirement date and reason, because an examiner may ask about a model that was in production during the period under review even if it has since been retired.

Model-Risk Files (one per model)

  • Each model in the inventory has a consolidated model-risk file containing all four documentation domains required by OCC 2026-13: development and validation records, production monitoring and performance records, fair-lending and compliance records, and governance and decision records.
  • The development and validation record includes the most recent validation report, the conceptual soundness assessment, the data quality assessment, the performance benchmarking results, and the model limitations documentation.
  • The production monitoring record is current: it includes the most recent monitoring cycle results with population stability index (PSI) measurements, performance metrics, outcome rates by product and geography, and override and exception rates.
  • The fair-lending testing record is in the model-risk file, not only in the compliance department's records. It includes the testing methodology, the sample size, the disparity ratios by demographic group and credit quality stratum, the statistical significance assessment, and the LDA search documentation for any features identified as potential proxy variables.
  • The governance record includes the initial model approval with the approving body and conditions, the current model owner attestation, and the record of any material model changes since deployment.
  • The open findings register for each model is current, with a status and responsible owner for each finding.

Fair-Lending Testing Record

  • Disparate-impact testing has been conducted within the past twelve months for every AI or ML model used in credit decisioning, including pre-screening models, underwriting support models, and any automated decisioning rules derived from or validated against AI model outputs.
  • The testing methodology is documented: it should specify the basis for comparator group construction, the demographic estimation methodology (such as Bayesian Improved Surname Geocoding, or BISG), the statistical tests applied, and the sample size for each credit quality stratum tested.
  • The disparity ratios are documented for key demographic groups at minimum, and the institution can explain the basis for its alert thresholds and whether any ratios crossed those thresholds.
  • The LDA search record exists for any model feature identified as a potential proxy variable through the proxy variable analysis. A proxy variable is a model input that is facially neutral but correlates with a protected characteristic (under ECOA: race, color, religion, national origin, sex, marital status, age, or receipt of public assistance income) in a way that can produce disparate impact even without any discriminatory intent. The LDA search documents what alternatives were considered, what the performance trade-off was, and what the institution decided and why.
  • Any fair-lending findings from prior examination cycles are reflected in the open findings register with their remediation status, and post-remediation testing results are documented.

Adverse-Action Audit Trail

  • An adverse-action audit trail exists for every AI-influenced credit decision: it documents the applicant, the product, the decision, the AI model or tool involved in the decision, the reason codes generated, whether those codes were generated by the model, modified by a human reviewer, or independently determined by the human underwriter, and the date the notice was issued.
  • A sample review has been conducted within the past six months by the compliance function or the fair-lending officer, verifying that the reason codes in the audit trail are specific (not generic category codes), accurate (they reflect the actual basis for the decision as documented in the credit file), and consistent (similar decisions produce consistent reason codes across branches and underwriters).
  • The override and exception log is current: it documents the number and rate of manual overrides of AI model recommendations, the direction of those overrides (approving above the model recommendation or declining below it), and the demographic distribution of override decisions to the extent required by the institution's fair-lending monitoring program.

Governance Documentation

  • The lending AI governance committee charter is current, has been reviewed and approved by the board risk committee within the past twelve months, and is version-controlled.
  • Committee meeting minutes for the past twelve months are complete, signed, and filed.
  • Board reporting records for the past twelve months are complete, showing that the board received the required periodic reporting on the AI model inventory, model performance, fair-lending monitoring results, and any incidents or findings.
  • Any AI-related incidents in the past twelve months are documented in the incident log and in the affected model-risk files, with the incident classification, containment actions, root cause analysis, remediation actions, and committee closure decision.

The Disparate-Impact Test Record in Detail

The fair-lending testing record is the area most likely to produce findings in an AI lending examination, because it sits at the intersection of three regulatory frameworks (ECOA, OCC 2026-13's model risk requirements, and the interagency fair-lending examination procedures) and because the integration of fair-lending records into the model-risk file is one of the structural changes that 2026-13 introduced that many institutions have not yet fully implemented.

A complete disparate-impact test record for an AI credit model contains the following elements, organized chronologically within the model's fair-lending section of the consolidated model-risk file.

Testing scope and frequency statement: A brief statement confirming that disparate-impact testing is conducted for this model on the required cadence (at minimum annually, and at each material model change), identifying the products and geographies to which the model is applied, and identifying the demographic groups for which testing is required under the institution's fair-lending testing program.

Methodology documentation: How applicant demographics are estimated (BISG is the standard where applicants do not self-report, combining surname and geocoding probability distributions to estimate race and ethnicity); the statistical methodology for disparity analysis (approval rate ratio, the key metric, comparing the approval rate for a protected-class group to the approval rate for the most-favored comparison group at the same credit quality stratum); the credit quality stratification methodology (how the testing controls for legitimate credit risk differences between groups so that the testing isolates the effect of the model from the effect of credit quality differences); and the statistical significance thresholds used to determine when an observed disparity is material versus random variation.

Testing results by period: The results for each testing period since the model's deployment, showing the approval rate ratios by demographic group and credit quality stratum, the statistical significance of any identified disparities, and the disparity ratio relative to the institution's alert thresholds. A result that shows a disparity ratio of 0.87 for a protected-class group (meaning the approval rate for that group is 87% of the approval rate for the most-favored comparison group at the same credit quality level) should be documented along with the institution's assessment of whether that ratio requires escalation, investigation, or remediation under the program's alert thresholds.

Proxy variable analysis results: The proxy variable analysis reviews the model's features for correlation with protected characteristics. A feature like "neighborhood median income" may correlate with race in ways that produce disparate impact even when the model does not use race as a variable. The proxy variable analysis identifies which features have significant correlation with protected characteristics and documents the remove-and-retest analysis: what happened to the model's fair-lending performance when each correlated feature was removed, and whether a less correlated alternative produced equivalent or better credit performance.

LDA search documentation: For any feature identified through proxy variable analysis as producing or contributing to disparate impact, the LDA search documents: the alternative features tested; the testing methodology; the results showing the trade-off between disparate-impact reduction and credit performance; and the disposition decision with supporting rationale. An institution that has done this analysis and decided to retain a feature because the less correlated alternative produced a material degradation in predictive accuracy has a defensible position. An institution that has never conducted the analysis does not, regardless of what its current disparity ratios look like.

The Model Risk Record: What Examiners Prioritize

Examiners reviewing AI model risk records under 2026-13 consistently focus on four areas that many institutions handle less completely than other documentation domains. Understanding these priorities helps the institution allocate its pre-exam preparation effort.

Model owner attestations: OCC 2026-13 requires that every AI model have a named individual owner who is personally accountable for the model's performance, and that this accountability be demonstrated through a recurring attestation process at each monitoring cycle. An attestation that says "I have reviewed the Q1 2026 monitoring results for the consumer pre-screening model. No threshold triggers were activated. One open finding from the prior period is on schedule for remediation. Signed: [name, title, date]" is what the regulation contemplates. A model owner assignment in the inventory with no attestations on record is a gap that examiners will note. The pre-exam file review should confirm that attestations exist for the past four quarters for every model in production, with no gaps.

Vendor model documentation: For vendor-provided AI models, the examination focus is on: whether the institution has conducted independent outcomes testing (not just accepted the vendor's validation documentation); whether the contract includes notification requirements for material model changes and access to validation-relevant information; whether the institution has documented what it knows and does not know about the vendor model's architecture and training data; and whether any vendor model changes during the review period were identified, reviewed, and approved through the governance committee process. A vendor model that has been in production for three years with no independent outcomes testing and no vendor model change review is a finding regardless of how well the model performs on the institution's fair-lending tests.

GenAI tool documentation: Generative AI tools used in credit-related workflows are an area of active examination focus because many institutions deployed them before OCC 2026-13 made the documentation requirements explicit. The examination will focus on: the intended use definition for each GenAI tool (what specifically is it authorized to produce and in what workflows); the human review process (what does the reviewer verify, not merely that review occurs); the output validation testing conducted before deployment; the prompt and configuration record with version control; and the production output monitoring program. A GenAI adverse-action notice generator that has been running in production for a year with no documented human review process and no output monitoring is a Severity 1 governance finding.

The override tracking record: Override tracking is one of the areas most frequently cited in 2026-13 examination findings. Many institutions have robust model monitoring programs that track model performance but do not systematically track the rate, direction, and demographic distribution of manual overrides. The pre-exam file review should confirm that the override log captures, for each override: the date; the model recommendation; the human decision; the direction of the override (approve above or decline below); the reason for the override; and the demographic information required by the institution's fair-lending monitoring program. An override log that does not capture demographic distribution cannot serve the fair-lending governance function that 2026-13 requires, and its absence in the pre-exam file is a predictable finding.

The Adverse-Action Trail: A Walkthrough

The adverse-action audit trail is the record that connects a specific credit denial to a specific AI model output to a specific adverse-action notice sent to a specific applicant. For an AI-assisted lending operation, this connection is not automatic. It must be deliberately engineered into the workflow and documented in a way that allows the institution to produce the full chain for any specific application when asked.

Walk through the chain for a single hypothetical denial: an applicant applies for a $25,000 unsecured personal loan through the bank's online origination system on a specific date. The application is processed by the document extraction AI tool, which pulls income, employment, and identity information from the applicant's uploaded documents. The pre-screening scoring model generates a pre-qualification score. The score falls in the refer range, triggering human underwriter review. The underwriter reviews the file and declines the application. The adverse-action notice is generated by the GenAI notice tool, which produces reason codes based on the underwriter's documented denial rationale and the model's top adverse factors.

The adverse-action audit trail for this application should be able to answer, from a single query against the institution's records: What documents were extracted by the AI document extraction tool, and were any extraction errors identified in human review? What was the pre-screening score and what were the model's top adverse factors? What was the underwriter's documented rationale for the denial? What reason codes were generated by the GenAI notice tool, and what was the input to the notice generation (the underwriter's rationale, the model's adverse factors, or both)? Was the notice reviewed by a human before it was sent, and was it reviewed against the specific rules for the product and the specific facts in the file? What notice was sent to the applicant and when?

If any link in this chain is broken or undocumented, the institution cannot demonstrate Regulation B compliance for that application. If the chain is broken systematically across hundreds or thousands of applications because the workflow was not engineered to capture it, the institution has a systemic adverse-action documentation failure that will produce examination findings regardless of whether the individual notices are facially correct.

The pre-exam walkthrough exercise is straightforward: pull five denied applications at random from the AI-assisted decisioning workflow for the prior twelve months and attempt to reconstruct the full adverse-action chain for each one using only the documented record. If any link in the chain requires asking the underwriter, calling the vendor, or searching email, that link is a documentation gap. Document the gaps, remediate them, and then run the exercise again before the exam opens.

Key Takeaways

  • An OCC examination of AI lending governance under 2026-13 is a governance review, not a technical model audit: the examiner is evaluating whether the institution knows what models it is running, validates and monitors them, tests them for fair-lending risk, documents the adverse-action chain, and has a human accountability structure from model output to named decision-maker.
  • The pre-exam file includes five core components: the current model inventory, a consolidated model-risk file for each model (with all four documentation domains required by 2026-13), the disparate-impact testing record integrated into each model-risk file, the adverse-action audit trail for AI-influenced decisions, and the governance documentation record including committee minutes and board reporting.
  • A disparate-impact test record that exists only in the compliance department's records, rather than in the model-risk file, does not satisfy the 2026-13 integration requirement regardless of how thorough the underlying testing is; the structural integration of fair-lending records into model-risk files is itself a documentation standard, not a suggestion.
  • An LDA search record must exist for any model feature identified as a potential proxy variable through the proxy variable analysis; an institution that has current disparity ratios below its alert threshold but has never conducted a proxy variable analysis and LDA search does not have a clean fair-lending file under 2026-13.
  • Model owner attestations must exist for the past four quarters for every model in production; a model owner name in the inventory without attestations is an accountability-chain gap that examiners consistently cite as a finding under the 2026-13 governance requirements.
  • The override log must capture the demographic distribution of manual override decisions, not merely the rate and direction; an override log that does not capture demographics cannot serve the fair-lending governance function that 2026-13 requires and will be identified as a documentation deficiency in examination.
  • The pre-exam walkthrough exercise, pulling five denied applications and reconstructing the full adverse-action chain from documentation alone, reveals every structural documentation gap before the examiner finds them; running this exercise quarterly rather than the week before an exam is what separates an exam-ready institution from one that spends thirty-six hours assembling a substitute for the file it should have already had.