Training Lending and Compliance Staff
Six weeks after a savings bank deployed its AI-assisted underwriting platform, the chief lending officer received a call from the OCC examiner assigned to the bank's upcoming safety-and-soundness review. The examiner's first question was not about the model's performance metrics or the vendor's validation report. It was this: "How have you trained your underwriters to operate the model?" The chief lending officer froze. The bank had run a two-hour vendor demonstration and emailed a PDF. The examiner's question revealed what the bank had not understood: OCC Bulletin 2026-13, the April 2026 interagency model-risk guidance that superseded OCC 2011-12, treats staff training not as a courtesy but as a governance control, one that is examined alongside the model itself. (The scenario above is a composite drawn from observed examination patterns; the institution and individuals are not real.)
Training lending and compliance staff is not the last step in an AI deployment; it is a concurrent and ongoing governance activity. The institution that completes implementation and then trains is building a liability. The institution that treats training as part of the model-risk program, designed before the model goes live, updated every time the model changes, and tested through the quality of the outputs the trained staff produce, is building a defensible program. This lesson is about the second institution: how to design and operationalize a training program that turns this certification curriculum into a functioning bank capability.
What Good Training Looks Like Under OCC Bulletin 2026-13
OCC Bulletin 2026-13 does not prescribe a training curriculum. What it does is establish the governance expectations that a training program must be designed to satisfy. Four of those expectations have direct training implications.
First, the bulletin requires that the institution's AI model-risk program include oversight by staff who understand what the model does, what its limitations are, and how to identify outputs that should be escalated. This is not a documentation requirement; it is a competency requirement. An examiner reviewing your model-risk program will ask to speak with the staff who operate the model, not just the staff who validated it. If your underwriters cannot describe the model's input variables, explain what a pre-score means and does not mean, or articulate the verification steps they perform before relying on an AI output, that is a finding.
Second, the bulletin pulls AI and generative AI (GenAI) explicitly under fair-lending expectations. Staff who use AI in credit decisioning need to understand the Equal Credit Opportunity Act (ECOA, the federal statute prohibiting discrimination in any aspect of a credit transaction), Regulation B (Reg B, the implementing regulation that governs adverse action notices and nondiscrimination in lending), and what disparate impact means in the context of a model that does not use protected characteristics as inputs but may use correlated proxies that produce discriminatory outcomes. An underwriter who has never heard the phrase "proxy variable" is not equipped to flag the fair-lending concern that a well-trained underwriter would surface.
Third, the bulletin requires that model risk governance cover third-party models, not just internally built ones. Most banks licensing AI underwriting tools from a vendor are using a third-party model, and their staff need to understand this distinction: the bank cannot delegate its model-risk obligations to the vendor. Compliance staff in particular need to understand that their vendor due diligence, ongoing monitoring, and contract oversight are part of the model-risk program, not peripheral to it.
Fourth, the bulletin extends board-governance expectations to AI. Senior leadership and the board receive reporting on AI model performance, fair-lending testing results, and material model changes. The executives and board members who receive that reporting need enough AI literacy to ask intelligent questions rather than accepting summaries at face value. Training for senior leadership is structurally different from training for front-line staff, but it is no less required under a defensible governance program.
Training is a governance control, not a communication exercise; OCC 2026-13 examinations test the competency of the staff operating the model, not just the documentation the institution produced before deployment.
Designing the Training Program by Role
A single training program for all staff is both inefficient and insufficient. The skill set an underwriter needs to operate an AI pre-scoring tool safely is different from the skill set a compliance officer needs to examine the model-risk record, which is different again from the skill set a loan officer needs to interpret an AI flag in the borrower conversation. Design the program in four tiers, each mapped to a specific role cluster.
Tier 1: Front-line operators (underwriters and loan officers)
Underwriters and loan officers are the primary interface between the AI tool and the credit decision. Their training needs to cover six areas in enough depth to produce measurable competency, not just awareness.
First, they need to understand what the AI does and does not do in their specific workflow. Not a conceptual overview of machine learning: a specific description of the inputs the model uses, how it generates its output signal, and what the signal means in the context of the bank's credit policy. If the pre-scoring model flags a file for "income variability," the underwriter needs to know what data points triggered that flag, how to verify them against the source documents, and what the credit policy says about income variability as a risk factor.
Second, they need to understand the verification requirement. This is the discipline that prevents an AI output from becoming an unverified decision. The training should walk through a complete verification workflow using real (or anonymized real) files, showing the underwriter exactly how to compare the AI's extracted data against the source documents, how to identify a discrepancy, and what to do when they find one. The verification checklist should be a physical or digital artifact that the underwriter completes for every file, not a mental check they perform and do not document.
Third, they need to understand adverse action under ECOA and Reg B. The adverse action training should be specific to the AI-assisted workflow: what does the AI produce that is relevant to the adverse-action reason codes, how does the underwriter verify that the AI-suggested reasons are accurate and grounded in the file, and what is the process for overriding an AI-suggested reason when the underwriter's judgment is that it does not accurately describe the basis for the decision. This training should include at least three worked examples: a straightforward denial where the AI-suggested reasons are accurate, a case where one AI-suggested reason is not supported by the file data, and a case where the AI produced a reason the underwriter believes is a proxy for a protected characteristic.
Fourth, they need to understand the escalation path. Who do they contact when the AI appears to have gotten something wrong? What is the expected response time? What documentation do they need to provide with the escalation? The escalation path should be tested in training, not just described. A training scenario where the participant has to identify an AI error and complete the escalation form produces much stronger retention than a lecture on when to escalate.
Fifth, they need to understand their role in fair-lending monitoring. Underwriters and loan officers are not expected to run disparate-impact analyses, but they are expected to flag file-level concerns that could indicate a systematic problem. Training should include examples of what those concerns look like: a pattern of AI flags on borrowers from a particular geography, a systematic discrepancy between the AI's income extraction and the actual figures on tax returns from a particular employer type, or a rate of AI-assisted exception denials that appears inconsistent with the exception-grant rate on comparable non-AI files.
Sixth, they need to understand that the AI-assisted workflow does not change their personal accountability for the decision. The credit decision and the adverse-action reasons are theirs. The verification step is theirs. The credit note is theirs. The AI is an input to their analysis, not a substitute for it. This accountability framing is not just a legal point; it is a professional dignity point. The underwriter who understands that AI makes them more capable rather than less relevant is a much more effective operator than the underwriter who feels the AI is making the decision and they are just validating it.
Tier 2: Compliance and fair-lending staff
Compliance and fair-lending staff have a different training requirement. They need to understand the AI tool well enough to examine the model-risk record, interpret the disparate-impact testing output, conduct adverse-action quality reviews, and respond to regulatory inquiries. Their training is less about operating the tool and more about governing it.
The core competencies for this tier are: reading a model validation report and identifying gaps; interpreting a disparate-impact analysis, including the statistical measures used and the threshold at which a disparity triggers a less-discriminatory-alternative search; conducting an adverse-action quality review across a sample of AI-assisted denials; and understanding the third-party model-risk obligations that apply when the AI tool is vendor-provided, including the contract terms, performance monitoring obligations, and incident-escalation requirements under OCC Bulletin 2026-13.
Compliance staff also need training on the specific fair-lending statutes that apply to AI-assisted lending. ECOA and Reg B govern credit decisions and adverse action. The Community Reinvestment Act (CRA, the statute that requires federally insured depository institutions to help meet the credit needs of their communities, including low-and-moderate income neighborhoods) creates obligations around geographic credit distribution that an AI model's geographic segmentation features can implicate. Unfair, Deceptive, or Abusive Acts or Practices (UDAAP, the standard under the Dodd-Frank Act and the Federal Trade Commission Act that prohibits consumer-harm practices) applies to any AI-assisted customer communication that could mislead borrowers about the basis for a credit decision. The compliance officer who can connect an AI model's design to each of these frameworks is a much more effective governance resource than one who has siloed knowledge of the regulations without understanding how AI intersects them.
Tier 3: BSA/AML analysts
BSA/AML (Bank Secrecy Act and Anti-Money Laundering, the combined federal regulatory framework requiring banks to detect and report suspicious financial activity) analysts face a specific training challenge. The AI tools used in BSA/AML transaction monitoring operate differently from the AI tools used in credit underwriting, and the governance obligations are also different. Transaction monitoring AI produces alerts at extremely high volume; the industry pain point is that roughly 90 to 95 percent of those alerts are false positives, meaning human analysts spend most of their time reviewing alerts that turn out not to involve suspicious activity.
BSA/AML analyst training for AI-assisted triage needs to cover three specific areas. First, the analyst needs to understand how the AI triage tool ranks and prioritizes alerts, what features drive a high-priority ranking, and how to override the AI's prioritization when their professional judgment suggests a different order. Second, the analyst needs to understand that the AI's false-positive reduction logic creates a risk: the algorithm that correctly de-prioritizes 94 percent of routine alerts may also incorrectly de-prioritize a small number of genuinely suspicious transactions. The Suspicious Activity Report (SAR) obligation belongs to the human analyst, not the AI. The training scenario that reinforces this is the one where a lower-priority AI alert turns out to contain a genuine suspicious activity pattern the analyst needs to work through. Third, BSA/AML analysts need to understand the documentation requirements for AI-assisted review: what they log when they accept an AI triage recommendation, what they log when they override it, and how that log functions as the audit trail when a regulatory examination reviews the BSA/AML program.
Tier 4: Senior leadership and board members
Senior leadership training is not operational training; it is governance literacy. The chief lending officer, chief risk officer, chief compliance officer, and board members who receive AI model-risk reporting need to understand enough about AI to ask the right questions rather than accepting management representations without interrogation.
The governance literacy curriculum for this tier covers: what model risk means in the context of AI (the risk that a model's predictions or recommendations are wrong in ways that cause financial harm or regulatory liability), how to read a model performance report and identify the metrics that matter for regulatory risk, what a disparate-impact testing result means and what remediation looks like, and the specific board oversight expectations under OCC Bulletin 2026-13, including what the board is expected to receive in regular reporting and what questions it is expected to ask in response. This tier also needs to understand the incident response framework: when does an AI-related lending problem require board notification, and what does the board's oversight role look like during and after an AI incident?
Operationalizing the Training Program
Designing the training program is the first half of the work. Operationalizing it, which means embedding it in the bank's governance infrastructure so it actually happens consistently and can be evidenced to a regulator, is the second half.
Tie training completion to model access. The single most effective operationalization lever is making model access conditional on completed training and passed assessment. An underwriter who has not completed the AI underwriting training and passed the assessment should not have access to the AI pre-scoring output in the LOS. This is not punitive; it is the same logic that governs access to any specialized system. The bank would not give a new employee access to the HMDA (Home Mortgage Disclosure Act, the federal law requiring financial institutions to report data about mortgage lending patterns) reporting system without first confirming they understood what HMDA data is and how it works. AI tools that influence credit decisions deserve the same discipline.
Embed training in the model-risk record. The model-risk record for each AI tool should include a training log: who received what training, when they completed it, what assessment score they achieved, and when they were recertified after a material model update. This log is evidence that the institution met its OCC Bulletin 2026-13 staff-competency obligation. The log should be maintained by model risk or compliance, not by the training team alone, because it is a governance artifact as much as an HR record.
Use this certification program as the curriculum spine. The AI for Banking and Lending certification program is designed to map to the competency levels that regulatory examination expects of different staff roles. The Level 1 content (AI-Aware Banker) is appropriate for loan officers and branch staff who interact with AI-assisted workflows without making credit decisions. The Level 2 content (AI-Assisted Lender/Analyst) is appropriate for underwriters who use AI in their daily workflow. The Level 3 content (AI-Integrated Practitioner) covers the workflow design and governance content that compliance officers and senior underwriters need. The Level 4 content (AI Lending Strategist) is the governance architecture content for chief lending officers, chief risk officers, and compliance leadership. The board and senior leadership tier can be satisfied with a condensed version of the Level 4 governance modules paired with a live briefing from the model-risk team.
Schedule recurring training, not just onboarding training. The AI tools your bank uses will change. Models will be updated. Vendors will release new versions. Regulatory guidance will be clarified or expanded. The training program needs to include a trigger-based recertification requirement: any material model update triggers retraining for front-line users, any significant regulatory guidance change triggers retraining for compliance staff, and any fair-lending testing finding that leads to a model change triggers retraining across all affected roles. The recertification requirement should be in the model governance policy document, not just in the training department's calendar.
Test competency through work product, not just assessment scores. Assessment scores measure knowledge; the examiner will want to see evidence of applied competency. Design quality review processes that test whether the training is producing the right behaviors: monthly adverse-action quality reviews that check whether AI-assisted denials have properly verified, specific reason codes; override rate analysis that checks whether underwriters are actively applying judgment rather than accepting AI signals without review; and escalation log review that checks whether the escalation process is being used as designed. When the work product quality is strong, the training is working. When it degrades, the training needs to be updated or reinforced.
The Curriculum Design Decisions That Matter Most
Every training program involves design choices about what to include, what to skip, and how to sequence the content. The following decisions disproportionately affect whether the program produces genuine competency or merely completed training hours.
Ground everything in real files. The most common failure mode in banking AI training is abstraction: the training teaches concepts without showing the concept applied to a real credit file, a real adverse action notice, or a real disparate-impact test. Lending professionals learn by doing; the best training is a guided walkthrough of a real workflow using anonymized but authentic files. Every training module should include at least one worked example where the participant has to make a decision, not just read about how a decision is made.
Cover failure modes explicitly. The most valuable thing a well-designed training program can teach is what an AI failure looks like in a lending context. Hallucinated income figures (the AI extracting a number from the wrong line of a tax return), wrong adverse-action reasons (the AI suggesting a reason that is not actually supported by the file), and proxy-variable bias (the model using a correlated factor like zip code as a proxy for a protected characteristic) are the specific failure modes that end careers and generate regulatory findings. Show them in training. The underwriter who has seen a hallucinated income figure in a training scenario is much more likely to catch one in production.
Distinguish between the AI's job and the human's job at every step. The training should never leave any ambiguity about who is responsible for what. The AI extracts data: the human verifies it. The AI pre-scores the file: the human decides. The AI draft-assists the adverse-action reasons: the human verifies each reason against the file data and signs the notice. These distinctions should be explicit and repeated. The greatest risk in an AI-assisted workflow is the gradual erosion of the distinction between "AI produced this" and "I verified this and I stand behind it."
Build the fair-lending thread throughout, not at the end. Fair-lending considerations are not a compliance addendum to AI training; they are structural to how every AI workflow decision is made. ECOA and Reg B should appear in the first training module as the framework that defines why human accountability matters, and they should recur in every subsequent module as the lens through which every AI output is evaluated. The underwriter who understands from the first day that their verification step is a fair-lending control, not just a quality control, is far more likely to take it seriously.
Measuring Whether the Training Is Working
The training program produces four measurable outputs that allow the institution to confirm it is working and to identify areas for improvement before an examiner does.
Assessment completion and pass rates by role. These are the basic governance metrics: did the right people complete the right training, and at what rate? A low pass rate on a particular module is a signal that the content is either too advanced for the audience or not clearly connected to their workflow. Both are fixable, but only if you are tracking the metric.
Adverse-action quality scores. A monthly sample of AI-assisted adverse action files reviewed by compliance against a rubric that checks for specific reasons, file-data grounding, and accurate borrower notice is the strongest behavioral indicator that the underwriter training is producing the right workflow behaviors. If the quality scores are high and stable, the training is working. If they are declining, the training needs reinforcement or the workflow is being shortcut in ways the training did not anticipate.
Override rate and pattern. The pattern of underwriter overrides of AI signals is an indirect indicator of training quality. Too few overrides suggests underwriters are not doing the independent verification the training requires; too many overrides suggests either that the model is unreliable or that underwriters did not internalize what the AI's signal is telling them. The training should set expectations for what a healthy override rate looks like, and the monitoring program should track against those expectations.
Escalation utilization and quality. The escalation path is only useful if staff know about it and use it. Track how many escalations are received per period, from which roles, and whether the escalation reports describe specific, identifiable issues (good) or vague concerns (suggests the training did not produce the diagnostic competency it was designed to produce). Regular reporting on escalation patterns to the model-risk committee turns individual staff observations into an institutional monitoring signal.
Key Takeaways
- Staff training is a governance control under OCC Bulletin 2026-13, not an onboarding courtesy; examiners test the competency of staff who operate AI models alongside the documentation the institution produced.
- Design training in four tiers mapped to role clusters: front-line operators (underwriters and loan officers), compliance and fair-lending staff, BSA/AML analysts, and senior leadership plus board members, each with different competency requirements.
- Front-line operator training must cover six areas: what the model does in their specific workflow, the verification requirement, adverse action under ECOA and Reg B, the escalation path (practiced, not just described), their role in fair-lending monitoring, and their personal accountability for the decision.
- Operationalize the program by tying model access to training completion, embedding training logs in the model-risk record, using this certification curriculum as the spine, requiring trigger-based recertification on material model changes, and testing competency through work product quality rather than assessment scores alone.
- Ground every module in real (anonymized) files and explicitly cover failure modes: hallucinated figures, wrong adverse-action reasons, and proxy-variable patterns are the scenarios that produce retention and front-line alertness.
- The four metrics that confirm the training is working are assessment pass rates by role, adverse-action quality scores, override rate pattern, and escalation utilization and quality; track all four and report them to the model-risk committee quarterly.
- The fair-lending thread (ECOA, Reg B, disparate impact, proxy variables) belongs in the first training module and throughout the curriculum, not in a standalone compliance session at the end.
Skill.re