The call came in at 6:14 on a Thursday evening. A loan officer at a branch in the eastern region had been reviewing a batch of adverse-action notices generated by the institution's AI-assisted decisioning workflow, and something had caught his eye: the reason codes on thirty-seven notices all said the same thing, and that thing was wrong. The stated reason was "insufficient collateral," but the product was an unsecured personal loan. There was no collateral in the file. The adverse-action notice requirement under ECOA (the Equal Credit Opportunity Act) and Regulation B (the implementing regulation, 12 C.F.R. Part 1002) is that the notice must state specific and accurate reasons for the denial. These notices stated a reason that did not apply to the product. Thirty-seven of them had already been mailed. The compliance officer who took the call did one thing immediately: she opened the institution's AI incident response runbook and called the first name on the contact list. By 9 p.m., a five-person response team had been assembled. By the following morning, they had contained the error, documented the scope, identified the root cause, and had a draft remediation plan. By the end of the week, the institution had sent corrected notices to every affected applicant and had assembled the documentation file for the finding. No examiner ever saw the incident before the institution did. What prevented that event from becoming an enforcement action was the runbook, the team, and the discipline to follow the process at 6:14 p.m. on a Thursday. (The institution, individuals, and sequence of events in this scenario are a composite illustration drawn from common incident-response patterns; they do not describe any single institution's experience.)

What Counts as an AI Lending Incident

An AI-related lending incident is any event in which an AI or machine learning (ML) model or tool used in the lending function produces, contributes to, or fails to prevent an outcome that: (a) violates or potentially violates applicable law or regulation; (b) harms or potentially harms applicants, borrowers, or protected classes; (c) produces material operational or reputational risk for the institution; or (d) suggests that the model's performance has degraded or that the model is operating outside its intended parameters in a way that requires investigation.

The scope is deliberately broad, because the categories of things that can go wrong with AI in lending are broad. Incidents include:

Adverse-action reason code errors: The model risk or generative AI (GenAI) tool generates adverse-action reason codes that are inaccurate, internally inconsistent, generic rather than specific, or applied to the wrong applicant. Under Regulation B, an adverse-action notice must state the specific reasons for denial. A reason that does not accurately describe the basis for the credit decision is a Regulation B violation. Each incorrect notice is a separate violation exposure, and a batch error affecting dozens or hundreds of applicants is a material compliance incident.

Fair-lending performance anomalies: Model monitoring or fair-lending testing identifies a disparity in approval rates or credit terms between protected-class applicants and similarly qualified non-protected-class applicants that exceeds the institution's alert threshold, suggesting the model may be producing disparate impact under ECOA. Disparate impact means a model produces materially lower approval rates for a protected class even when no protected characteristic is an explicit model input, because a feature used by the model correlates with that protected characteristic. Even when the disparity does not yet rise to the level of a regulatory finding, it must be documented and investigated as an incident.

Silent vendor model changes: A vendor-provided AI model is updated, retrained, or reconfigured without the institution's knowledge or prior review, producing a change in the model's outputs. Under 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), vendor notification requirements for material model changes are a contractual and governance obligation. A silent vendor update that changes model behavior is both a governance failure and a potential performance incident requiring validation of the new behavior before continued production use.

Hallucinated or fabricated content: A GenAI tool used in credit memo drafting, adverse-action notice generation, or customer communications produces output containing information not supported by the file: invented income figures, fabricated covenants, wrong loan amounts, or inaccurate applicant data. Each such output that reaches a credit decision, a customer notice, or a regulatory filing is an incident.

Data integrity events: Errors in the input data fed to an AI model (incorrect income figures, wrong property values, corrupted credit bureau data) produce model outputs that are wrong because the inputs were wrong. These are incidents even if the model itself is operating correctly, because the wrong outputs may have influenced credit decisions.

Incident Severity Classification

Classification drives everything that follows: who is on the response team, how quickly they must respond, whether the board must be notified, whether a regulatory report must be filed, and what documentation the closure requires. Use a three-level severity scale and commit to it in writing in the runbook before any incident occurs.

Severity 1 is a confirmed or highly probable violation of applicable law or regulation (Regulation B, ECOA, the Fair Housing Act, BSA/AML requirements); any incident affecting more than fifty applicants or borrowers; any incident that may require a regulatory notification or filing; any incident involving a vendor model changed without notification; or any incident that senior management determines creates material reputational or financial risk. Severity 1 incidents require response team assembly within two hours, notification of the Chief Compliance Officer and Chief Risk Officer within two hours, and notification of the board risk committee chair within twenty-four hours. Regulatory notification requirements must be assessed within twenty-four hours of classification.

Severity 2 is a potential violation of applicable law or regulation not yet confirmed; a fair-lending monitoring alert that may reflect a systemic model problem rather than statistical noise; an incident affecting between five and fifty applicants; or a data integrity error that has affected model outputs and may have influenced credit decisions. Severity 2 incidents require response team assembly within twenty-four hours and notification of the Chief Compliance Officer within four hours. Board notification follows the next regular reporting cycle unless the incident is re-classified to Severity 1.

Severity 3 is a model behavior anomaly or performance decline that does not yet have a known impact on credit decisions or applicants; a single-applicant incident with no systemic implication; or a process failure that was caught before it affected any applicant. Severity 3 incidents are managed by the model risk management (MRM) function and the compliance function on the normal business schedule, without emergency escalation, but must be documented in the incident log and reviewed at the next governance committee meeting.

The classification decision should be made by the compliance officer in consultation with the model risk manager within two hours of the initial report for Severity 1 candidates and within eight hours for all other incidents. Classification can be upgraded but should not routinely be downgraded: if there is genuine uncertainty about whether an incident is Severity 1 or 2, classify it as Severity 1 and allow the response team to reconsider with more information in hand.

An incident classified as Severity 3 that later turns out to have been Severity 1 is an exam finding. An incident classified as Severity 1 that turns out to have been Severity 3 is a training exercise you got for free.

Containment: The First Forty-Eight Hours

Containment means stopping the incident from producing additional harm. Containment decisions must be made quickly, before the full root cause is understood, on the basis of the best available information about the scope and severity of the problem. Speed matters more than certainty at the containment stage: the cost of operating a broken model for an additional twenty-four hours while the team gathers more information is typically much higher than the cost of one day's manual fallback processing.

For a Severity 1 incident, the default containment action is to suspend the affected AI tool or model until the response team can assess whether it is safe to operate. This means pausing the model's use in the production workflow and reverting to the fallback process: manual underwriting, human review of all outputs, or temporary suspension of automated decisioning. The decision to suspend a production AI tool will face resistance from the lending function, which will point to origination pipeline backlogs and customer service impacts. The runbook must specify who has the authority to make that call and make clear that suspension is the default, not the exception, for Severity 1 events.

For adverse-action reason code errors specifically, containment has two components: stopping the generation of new incorrect notices, and identifying all previously generated notices that are affected. The second component requires a scope assessment: how many notices were generated with the incorrect reason code, over what time period, and were any mailed to applicants before the error was caught. A notice that was generated but not yet mailed is a containment success. A notice that was mailed to an applicant is already a Regulation B compliance event that requires remediation regardless of what happens going forward.

For fair-lending performance anomalies, containment may not require suspending the model immediately. It requires: confirming the scope and statistical significance of the observed disparity; reviewing a sample of the affected decisions to determine whether the disparity is a model artifact or reflects legitimate credit risk differences; and making a documented decision about whether to continue operating the model while the investigation is conducted or to suspend pending the investigation outcome. This decision must be documented with the rationale, the information available at the time of the decision, and the conditions under which the model will be suspended if the investigation confirms a systemic problem. The documentation of a reasonable, information-based decision to continue operating under investigation is itself a governance demonstration: it shows the committee weighed the evidence and made a deliberate choice, rather than continuing to operate because nobody bothered to decide.

The response team for a Severity 1 incident should include, at minimum: the compliance officer (lead), the model risk manager, the fair-lending officer, the model owner, and general counsel. For incidents involving vendor models, the vendor relationship manager must be included and the vendor must be notified within twenty-four hours. For incidents with BSA/AML implications, the BSA officer must be added immediately. The team should have a dedicated communication channel (a secure group message or conference bridge), a shared document for the running decision log, and a committed schedule for check-ins until the incident is contained.

Remediation: Fixing the Harm and the Cause

Remediation addresses the harm that has occurred and fixes the underlying cause of the incident. These are two separate activities, and both are required. An institution that fixes the broken model feature but does not remediate the applicants who received incorrect adverse-action notices has addressed the source but not the harm. An institution that sends corrected notices but does not fix the model will generate additional incidents.

Applicant remediation for adverse-action reason code errors requires sending corrected adverse-action notices to every affected applicant. The corrected notice must: state the accurate reason for the credit decision; explain that the original notice contained an error; state the applicant's rights under ECOA and Regulation B, including the right to request the specific reasons for the decision; and provide the applicant a reasonable opportunity to respond or reapply if the error affected their ability to understand and respond to the denial. The cover letter accompanying the corrected notice should not be generated by the AI tool that produced the error. It should be drafted by a human, reviewed by the fair-lending officer and general counsel, and sent through a process that does not involve the affected model.

For fair-lending incidents where a model is found to have produced disparate impact over a period of time, applicant remediation is more complex. It requires identifying the affected applicant population; assessing whether any applicants were denied credit they would have received under a non-discriminatory model; and determining the appropriate form of remediation, which may include proactive reconsideration of affected denials, restitution for applicants who were charged higher rates due to the model's error, or both. The Consumer Financial Protection Bureau (CFPB) and OCC have established precedent for what remediation looks like in fair-lending enforcement contexts, and that precedent should inform the institution's remediation plan even when the incident is self-identified before regulatory involvement.

Root cause and model remediation must identify the specific mechanism that produced the incident. For a reason code error, the root cause might be: a system integration error between the decisioning model and the notice-generation system; a prompt configuration error in the GenAI tool that generates notice language; a data mapping error that matched the wrong reason codes to the wrong products; or a model validation gap that did not include testing of reason code accuracy across all product types. Each root cause has a different fix, and the fix must be validated before the model is returned to production.

The model risk manager must review and approve the root cause analysis and the proposed fix before the model is restored to production. The governance committee must approve restoration for any Severity 1 incident. The production restoration should be accompanied by a post-remediation monitoring period with increased frequency and scope: if monthly monitoring is normal, run weekly monitoring for the first two months after restoration, and document the results in the incident file.

Regulatory Notifications and the SAR Question

Not every AI lending incident requires a regulatory notification. But several categories of incidents require immediate assessment of whether a notification is required, and that assessment must be made by counsel and the appropriate compliance officer, not by the response team operating on its own judgment. The runbook must specify that the regulatory notification assessment is a mandatory step for every Severity 1 incident, completed within twenty-four hours of classification, and documented in the incident file.

Suspicious Activity Reports (SARs) are required filings under the BSA/AML framework when a financial institution knows, suspects, or has reason to suspect that a transaction involves funds from illegal activity, is designed to evade reporting requirements, or has no lawful purpose. If an AI incident in the lending function reveals that AI outputs were used to facilitate a transaction that triggers SAR filing criteria, the BSA officer must be engaged in the response team immediately. The BSA officer's determination about whether a SAR is required is not a committee decision: it is an individual compliance officer decision with specific legal obligations and thirty-day filing deadlines under the BSA. Federal law also prohibits any person involved in a SAR filing from disclosing the existence of that filing to the subject of the report or to others not involved in the compliance process; the incident response team must be briefed on this confidentiality restriction as part of any response that implicates BSA/AML obligations. The committee's role is to ensure the BSA officer has all relevant information from the incident response, not to make the SAR determination itself.

For fair-lending incidents, the notification question involves ECOA and the Fair Housing Act. The CFPB and the OCC both have supervisory jurisdiction over fair-lending compliance, and each has its own reporting expectations for self-identified fair-lending findings. An institution that self-identifies a fair-lending problem, remediates it fully, and documents the entire process is in a substantially better supervisory posture than one that has the same problem identified in examination. Self-reporting a corrected fair-lending error before examination is not a guarantee of no enforcement action: it is a demonstrated commitment to the compliance obligation that regulators weigh heavily in their supervisory responses.

For Regulation B violations (incorrect adverse-action notices), the institution must assess whether the volume or nature of the violations rises to a level that requires supervisory self-disclosure. Individual notice errors that are quickly corrected are generally handled through the complaint resolution process without a separate regulatory notification. Batch errors affecting large numbers of applicants may require more proactive engagement with the OCC or CFPB. General counsel makes this judgment with input from the Chief Compliance Officer and with awareness of the institution's existing supervisory relationship with its primary regulator.

Documentation and Closure

An incident is not closed when the model is fixed and the applicants have been remediated. It is closed when the documentation is complete. The documentation requirement under OCC 2026-13 is that every AI model incident must be captured in the model's risk file as a lifecycle event, with the full incident record including the initial detection report, the classification decision, the containment actions taken, the root cause analysis, the remediation actions taken, the post-remediation test results, and the governance committee's closure decision.

The incident documentation file should include: the initial incident report with the date and time of detection, the reporter, the initial description, and the classification decision; the response team log including who was on the team, when they were convened, and all significant decisions made during the response with date, time, decision-maker, information available, and rationale for each decision; the scope assessment showing how many applicants or transactions were affected, over what period, and what the nature of the harm was; the containment actions taken and the documented rationale; the root cause analysis; the remediation plan with specific actions, responsible owners, and target completion dates; evidence of remediation completion (corrected notices mailed, confirmation of delivery, model fix validation results); post-remediation monitoring results for the period following restoration; and the committee's formal closure decision with the date, voting members present, closure determination, and any conditions attached to closure such as enhanced monitoring duration.

The documentation serves three purposes simultaneously. It is the evidence that the institution managed the incident responsibly, which is the primary defense in any regulatory review. It is the input to the committee's root cause review, which should produce changes to the monitoring program, the vendor management program, or the model configuration to prevent recurrence. And it is the institutional memory that allows a future response team dealing with a similar incident to benefit from what the institution already learned, rather than discovering the same root causes and making the same containment decisions for the second time.

The closure review meeting should be a standing agenda item added to the governance committee meeting following the incident. At that meeting, the response team lead presents: a summary of the incident and response; the root cause analysis conclusions; the remediation actions completed; the post-remediation monitoring results; and a recommendation regarding changes to the institution's monitoring program, vendor management requirements, or model configuration to prevent recurrence. The committee formally votes to close the incident or to extend the monitoring period before closure. The closure vote and any conditions are recorded in the committee minutes, and the incident file is filed in the affected model's consolidated risk record.

Key Takeaways

• An AI-related lending incident is any event in which a model produces, contributes to, or fails to prevent an outcome that violates applicable law, harms applicants, creates material risk, or suggests the model is operating outside its intended parameters; the category is deliberately broad because the failure modes of AI in lending are broad.
• A three-level severity classification (Severity 1: confirmed or probable regulatory violation or large-scale impact; Severity 2: potential violation or smaller-scale impact; Severity 3: anomaly without known applicant impact) drives escalation speed, response team composition, board notification timing, and documentation requirements, and the default for genuine uncertainty is always the higher severity level.
• Containment and remediation are two separate obligations: containment stops the incident from producing additional harm (which may require suspending the AI model pending investigation), while remediation addresses both the harm to affected applicants and the root cause that produced the incident.
• For adverse-action reason code errors, every applicant who received an incorrect notice must receive a corrected notice with accurate reasons, because each incorrect notice is a separate Regulation B violation exposure, and correcting the model without correcting the notices leaves the harm unaddressed.
• OCC 2026-13, issued in April 2026 by the OCC, Federal Reserve, and FDIC, requires that AI model incidents be documented in the model's risk file as lifecycle events with the full record of detection, classification, containment, root cause analysis, remediation, and committee closure; an incident that was handled well but documented poorly is an examination finding.
• SAR filing obligations and fair-lending self-disclosure assessments must be made by the BSA officer and general counsel respectively, not by the response team, because these are individual compliance obligations with specific legal deadlines and consequences for error.
• The incident documentation record serves three purposes simultaneously: regulatory defense, internal root cause learning, and institutional memory for future response teams; all three purposes require documentation that is complete, contemporaneous, and organized in the affected model's consolidated risk file.