The Interagency 36-Hour Computer-Security Incident Notification Rule Applied to Bank AI Systems

The Rule the Bank's AI Stack Did Not Inherit a Plan For

The federal banking agencies' 2021 final rule, Computer-Security Incident Notification Requirements for Banking Organizations and Their Bank Service Providers, gave covered banks a 36-hour clock to notify their primary federal regulator after determining a "notification incident" has occurred. The rule has been in effect since May 1, 2022 and full compliance was required by April 1, 2022 for OCC-supervised institutions. The rule codifies at 12 CFR Part 53 for national banks and federal savings associations, 12 CFR Part 304 Subpart C for FDIC-supervised institutions, and 12 CFR Part 225 Subpart N for Federal Reserve-supervised institutions and holding companies.

The rule is short and the operational consequences are not, which is why every bank we work with has an incident-response runbook that covers ransomware, DDoS, and vendor outages but does not contemplate the specific failure modes that arise when an AI agent sits on the customer channel. An AI agent that hallucinates and tells the wrong customer the wrong loan balance is not an event the existing runbook classifies. A prompt-injection-driven exfiltration of PII through an agent's tool surface is. A model-provider that swaps the underlying LLM mid-day and degrades the institution's call deflection rate is on a different question entirely, because the vendor side of the rule has its own clock and its own definitions.

We build the AI agent that sits on the bank's customer surface, so the incident classification has to happen at the agent's logging layer and feed the bank's internal determination process inside the 36-hour window. The architecture below is the one our customers' SOC and risk teams have validated against the rule's text and against the NYDFS Part 500.17(c) 72-hour notification that runs in parallel for New York-regulated institutions.

What the Rule Says, Restated for an AI Stack

The rule defines a "computer-security incident" at 12 CFR 53.2 as an occurrence that results in actual harm to the confidentiality, integrity, or availability of an information system or the information the system processes, stores, or transmits. The final rule narrowed this definition from the "actual or potential harm" wording the agencies had floated in the proposal, and the "reasonably likely" predicate the proposal had carried at this layer was moved up to the separate "notification incident" threshold. The practical effect is that an alert flagging a possible-but-not-actualized confidentiality risk does not yet qualify as a computer-security incident under the rule, and the SOC's runbook has to keep the two states separate so candidate alerts do not get classified prematurely. The narrower definition that drives the 36-hour clock is "notification incident," which the rule defines as a computer-security incident that has materially disrupted or degraded, or is reasonably likely to materially disrupt or degrade, the banking organization's ability to carry out banking operations or deliver banking products and services to a material portion of its customer base in the ordinary course of business, or a business line whose failure would result in a material loss of revenue, profit, or franchise value, or operations whose failure would pose a threat to the financial stability of the United States.

The 36-hour clock starts at the moment the banking organization "determines that a notification incident has occurred." The determination is the event, not the underlying occurrence. The Federal Register preamble made the point that the agencies did not want to require notification at the moment the SOC first sees the alert; the rule's clock starts at the moment the bank has run enough analysis to conclude the alert was, in fact, a notification incident. This is the operational fulcrum the bank designs around. A program that takes ninety-six hours to make the determination is not in compliance just because the determination event was late; the agencies will look at whether the determination process itself was unreasonably slow given the facts the bank saw.

The bank service provider side of the rule is at 12 CFR 53.3. A bank service provider is required to notify each affected banking-organization customer as soon as possible after determining that the bank service provider has experienced a computer-security incident that has caused, or is reasonably likely to cause, a material service disruption or degradation for four or more hours. The four-hour threshold is the entry condition, not the notification deadline; the deadline is "as soon as possible." The asymmetry matters when the AI vendor and the bank both look at the same outage and reach different conclusions about its materiality.

The AI Agent Failure Modes the Rule Reaches

The rule's text does not list AI failure modes. It does not need to, because the definitions reach the substance. The four categories the architecture has to classify against are the ones we see in deployment.

The first is a confidentiality breach driven by the agent. A prompt injection that elicits another customer's account information from the agent's retrieval surface is a confidentiality incident under the rule's first prong, and depending on the scale and the data category, it may rise to "notification incident" if a material customer subset is affected or if the institution's business line takes a material hit. We have written separately on the prompt-injection defenses that lower the probability of this failure; the rule's question is what happens when those defenses miss. The case from the bank's perspective is that the agent had a tool that read account records and the injection caused the tool to return records the requesting consumer was not entitled to.

The second is an integrity failure that produces a customer-facing wrong answer at scale. An agent that, because of a retrieval-corpus update gone wrong or a model swap, starts telling consumers their accounts are in a different status than they actually are produces a stream of incorrect statements about the bank's records. A material customer subset receiving wrong account information from the bank's customer channel is, on a fair reading, a material disruption to the delivery of banking services. The hard call is whether the failure is a "notification incident" or a quality issue that has not yet crossed the threshold, and the determination process has to engage that question quickly enough that the 36 hours do not start running while the team debates.

The third is an availability failure. The agent goes down or the model vendor's API returns errors at high rate, and the bank's customer-facing channel degrades. If the channel is the primary customer touchpoint and the degradation runs long enough to meet "materially disrupted ... a material portion of its customer base," the availability event qualifies. Voice channels are particularly exposed here because a degraded voice agent that routes everything to human handoff overwhelms the call center and the customer experience collapses on both surfaces, not just the AI one.

The fourth is an unauthorized-action failure. An agent that, because of a tool-gating gap or an injection, executes an action the consumer did not authorize, such as opening a dispute that starts a Regulation E clock or initiating a transfer, is producing actual harm to integrity at the institution level. A single such action is not necessarily a "notification incident"; a series of them on a coordinated injection campaign is. The detection mechanism has to be sensitive enough to see the pattern at the institution level rather than at the per-call level.

The Determination Event the Architecture Has to Produce

The rule places the 36-hour clock at the determination event, so the program's incident-response runbook has to define what the determination event looks like procedurally and who is empowered to issue it. The institutions we work with have settled on a designated incident commander (commonly the CISO or a deputy with explicit delegation) who issues the determination on a documented record. The determination has a timestamp, the underlying facts considered, the classification rationale, and the basis for the notification-incident judgment. A program that lets the determination event be implicit in an email thread is a program whose 36-hour clock is genuinely ambiguous, and the regulator's after-the-fact reconstruction will read it against the institution.

The agent's contribution to the determination event is the structured evidence the incident commander needs to make the call quickly. We instrument the agent to emit per-incident telemetry that maps to the rule's categories: a confidentiality classification with the data categories and the affected record count, an integrity classification with the accuracy posture and the affected request volume, an availability classification with the outage window and the customer-impact estimate, and an action-trigger classification with the count and the kind of unauthorized actions taken. The telemetry is not the determination; it is the input the determination event runs on. The institution that gets the telemetry inside the first hour after detection is the institution whose determination event can issue inside the first six and whose 36-hour window has thirty hours of working time to produce the notification.

The rule explicitly contemplates that the bank may make a notification on incomplete information. The notification can be made by phone or email to the primary federal regulator's designated contact, and the bank is expected to update as facts develop. A risk-management posture that says "we will not notify until we are certain" is a posture that runs the clock down. The institutions we serve treat the initial notification as a status update rather than a final report, and the conservative bias is toward notifying earlier and supplementing later rather than waiting for the full forensic picture.

The Bank Service Provider Clock and the LLM Vendor

The asymmetric question is what counts as a "bank service provider" for purposes of the four-hour notification obligation. The rule incorporates the definition from the Bank Service Company Act, 12 U.S.C. 1867, which covers entities providing services such as check and deposit sorting and posting, computation and posting of interest, preparation and mailing of statements, and "other clerical, bookkeeping, accounting, statistical, or similar functions performed for a depository institution." The LLM vendor that powers the bank's customer-facing agent is, on a reasonable reading, providing a service that performs a function for the bank, and the institutions we work with have either confirmed the vendor's coverage at the contract level or have layered a contractual notification obligation that mirrors Part 53.3's substance.

The four-hour threshold in 53.3 is the materiality entry condition. A vendor outage that lasts forty-five minutes does not require vendor-side notification under the rule. An outage of four hours that has caused or is reasonably likely to cause a material service disruption does. The vendor's determination event has its own definition and its own clock. The bank, on the receiving end of the vendor notification, has to integrate the vendor's information into the bank's own determination process and make its own call on whether the bank-side notification incident threshold has been met.

The contract we recommend bank customers negotiate with their AI vendor closes the gap the regulation leaves open in two places. The first is the data-flow telemetry, which the bank needs to make its determination event. The second is the vendor's commitment to a notification window shorter than four hours when the outage is going to be long, because the bank's customer experience runs on the vendor's plumbing and the bank's risk teams have to be the second-fastest party to know, not the third or fourth.

The third-party risk management posture we wrote about separately is where this notification obligation lives in the vendor file. The TPRM program for the AI vendor includes the incident-notification SLA, the test record showing the SLA actually fires when an incident hits the threshold, and the change-notification commitment for material model swaps, because a model swap that degrades accuracy is a vendor change the bank needs to know about whether or not it crosses Part 53.3's threshold.

The State and Federal Notification Stack the AI Incident Touches

The 36-hour federal rule is not the only clock that runs on an AI incident at a bank. The architecture has to produce the determination event in a way that feeds the parallel clocks without the institution having to redo the analysis for each one.

NYDFS Part 500.17(c) requires notification within 72 hours of determining that a cybersecurity event has occurred at a covered entity or its third-party service provider, with a narrower threshold than the federal rule's "notification incident." The NYDFS clock runs on different definitions and a different threshold, but the underlying determination process is the same one. The state notification stack also includes California Civil Code 1798.82 and the parallel state breach-notification statutes that fire when personal information is compromised, with their own clocks that are typically tied to consumer notification rather than regulator notification. The SEC's Item 1.05 of Form 8-K requires public banks to disclose material cybersecurity incidents within four business days of determining materiality, on a different definition of "material" than the federal banking rule uses.

The architecture we run produces one determination-event record per incident with classifications against each applicable regime. The same incident may be a "notification incident" under Part 53, a "cybersecurity event" under Part 500.17(c), a "breach" under the state statutes if PII is involved, and a "material cybersecurity incident" under Item 1.05 for the public bank-holding company. The four classifications are made separately because the legal thresholds are different, but they share the underlying facts. A program that runs four parallel determination processes against four sets of definitions of the same facts is a program whose state and federal notifications will diverge in ways no regulator wants to read.

The Agent's Self-Monitoring That Feeds the Process

The agent itself is the closest sensor to the incident, and the architecture has to use that proximity rather than waiting for an aggregated alert from the SOC. The agent emits per-conversation health signals that flow into the central detection plane: the model's classification of the conversation's success or failure, the validator's rejection counts, the tool-gating denials, the retrieval-grounding failures, the customer-side disposition (escalation requested, complaint mentioned), and a per-conversation risk score the SOC tunes against.

When the signals cross thresholds the SOC has defined, the agent's detection layer emits a candidate-incident record into the institution's incident-response pipeline. The candidate is not an incident; it is the artifact the SOC reviews. A spike in tool-gating denials in a fifteen-minute window suggests an injection campaign in progress. A spike in retrieval-grounding failures suggests a corpus update went wrong. A spike in customer-side disposition flags suggests the agent is producing wrong answers at scale. Each signal is on its own time series and the SOC's correlation rules turn the combination into a candidate-incident record fast enough that the determination event can issue inside the first few hours rather than the last few of the 36-hour window.

The agent also records what it did not do. A tool-gating denial is an event the validator wrote a stop on, and the cumulative count of stops by tool over the recent window is the dataset the institution uses to recognize that something is trying to push the agent through controls that are holding. An institution whose agent stops a thousand attempted exfiltrations and never sees the data is the institution whose architecture is working as intended; an institution whose agent stops nothing because the validator is too permissive is the institution whose first determination event is reactive to a customer complaint rather than to the agent's own telemetry. The validator's design and the threshold-tuning loop sit at the center of the program because they are where the agent's incident posture is decided.

The Case File the Examiner Will Ask For

The per-incident record we keep is the artifact the bank's primary federal regulator and the state authorities will ask for in the post-incident review and in subsequent examination cycles. The file contains the underlying telemetry that produced the candidate-incident record with the time series and the signal sources, the SOC's review notes turning the candidate into a confirmed incident with the classifications applied, the determination event with the timestamp, the incident commander identity, the rule classifications across the federal, state, NYDFS, and SEC regimes if applicable, the notifications made with the recipient, the channel, the timestamp, and the content, the subsequent supplements and updates with each timestamp, the containment and remediation actions with the responsible owner and the close-out timestamp, the vendor-side communications received under the bank service provider obligation with the vendor's own classification, the customer-side communications made under any state breach-notification statute with the recipient list and the contents, and the post-incident review with the lessons applied to the agent's controls and the validator's thresholds.

A program that produces this per incident is a program whose 36-hour window the regulator can verify on the institution's own records. A program whose incident file is reconstructed from email threads and the SOC's recollection is a program whose next examination cycle will be longer.

The Honest Limit

The 36-hour clock is short and the determination event is supposed to be the deliberate, reasoned conclusion of a process that has run on the facts available. Those two things are in tension in incidents where the facts develop over days. The architecture above is built to compress the determination process by feeding it structured telemetry quickly enough that the incident commander has the picture by hour two or three of an incident detected at minute zero. The compression is not infinite. An incident whose facts take twenty hours to assemble produces a determination event late in the window and a regulator notification that is on time but supplemented heavily over the following weeks. We have not had a case where the architecture missed the 36-hour window in production, but the cases we have had where it came close were the cases where the vendor's notification arrived later than the contract committed to, and the bank's own determination event waited on the vendor's facts to firm up. The contractual SLAs and the in-house telemetry are the two levers that keep the window from collapsing. The model-risk and SR 11-7 program we wrote about separately is the long-cycle context the incident file feeds, because every incident is a stress-test result for the controls the model-risk program signed off on, and the loop closes at the next change-control review.

The right way to think about Part 53 and the AI agent on the bank's customer surface is that the agent is a new kind of operational dependency the rule covers the same way it covers the core banking platform, and the SOC, the vendor-management team, and the model-risk team have to work the same problem from three angles inside one timeline. The institutions whose AI program had a separate incident posture from the rest of the cyber program are the institutions whose first material incident produced a notification that was procedurally late by a margin the regulator measured. The institutions that built the AI program inside the cyber program from day one are the institutions whose first incident, when it comes, is notified on time and resolved on the institution's terms rather than on the regulator's.