Regulatory Notification Windows

Prerequisite: US Payments Regulation, Incident Response

Your payment platform suffered a data breach at 11:47 PM on a Friday. Engineering contained the vulnerability by 2:00 AM. The postmortem can wait until Monday — but the regulatory notification cannot. The OCC requires notification within 36 hours of determination. New York DFS requires 72 hours. FinCEN may require a SAR within 30 days. Your CFPB complaint volume will spike within the week. Each regulator has a different clock, a different form, a different threshold for what constitutes a reportable event, and a different penalty for missing the deadline. The engineering team that contained the incident has done half the job. The other half is notifying every regulator who needs to know, in the right format, within the right window.

The Notification Landscape

Financial institutions face overlapping reporting obligations from federal regulators, state regulators, and self-regulatory organizations. A single incident can trigger notifications to five or more bodies, each with independent deadlines and content requirements.

Regulator	Trigger	Window	Penalty for late/missed filing
OCC (national banks, trust charters)	Computer-security incident causing harm	36 hours from determination	Enforcement action, consent orders
FDIC (state-chartered banks)	Computer-security incident	36 hours from determination	Supervisory action
Federal Reserve	Computer-security incident	36 hours from determination	Supervisory action
NYDFS (Part 500)	Cybersecurity event	72 hours from determination	Up to $250,000 per violation
State MSBs (varies by state)	Material change, breach, AML deficiency	1–30 days depending on state	Licence suspension or revocation
FinCEN	Suspicious activity	30 calendar days from detection	Civil penalties up to $1M per violation
CFPB	Consumer complaint	15 days to respond, 60 days to close	Supervisory escalation
SEC (broker-dealers)	Material cybersecurity incident	4 business days (Form 8-K)	SEC enforcement action
FINRA	Significant cybersecurity event	Prompt notification (no fixed deadline)	Disciplinary action

The windows are not interchangeable. “36 hours from determination” is not the same as “36 hours from discovery.” Determination means the moment you conclude the event meets the reporting threshold — not when the alert fired, not when the engineer acknowledged it, and not when the root cause was identified. An organization that delays making a determination to buy time is in worse regulatory position than one that determines quickly and files promptly.

Delaying determination to extend the notification window is a strategy regulators have seen before. The OCC’s 2023-15 bulletin explicitly addresses this: the clock starts when the institution has enough information to determine an incident is reportable, regardless of whether a formal determination has been made.

Federal Banking Regulators: The 36-Hour Rule

The joint final rule from the OCC, FDIC, and Federal Reserve (effective May 2022) requires banking organizations to notify their primary federal regulator within 36 hours after determining that a “computer-security incident” has occurred that rises to the level of a “notification incident.”

A notification incident is one that has materially disrupted or degraded — or is reasonably likely to materially disrupt or degrade — the banking organization’s ability to deliver services to a material portion of its customer base, business lines, or operations. The threshold is functional impact, not technical severity. A ransomware attack that encrypts a test environment is a computer-security incident but not a notification incident. A database failure that prevents balance inquiries for 200,000 customers is.

The notification itself is deliberately simple. The rule requires only that the institution notify its primary regulator — there is no prescribed form, no required format, and no expectation of a root cause analysis at this stage. A phone call or email to your supervisory team stating that a notification incident has occurred, with a brief description, satisfies the requirement.

Subject: Notification Incident — [Bank Name]

[Bank Name] has determined that a notification incident occurred
on [date] at approximately [time] ET.

Nature: [Brief description — e.g., "Unauthorized access to
customer transaction data via compromised API credentials"]

Impact: [Scope — e.g., "Approximately 15,000 customer accounts
affected; no funds movement detected"]

Current status: [Containment status — e.g., "Incident contained;
affected credentials rotated; monitoring in progress"]

Point of contact: [Name, title, phone, email]

The simplicity is intentional. The regulator wants to know it happened, not why. The detailed incident report comes later, through supervisory channels, on a timeline negotiated with your examiner.

NYDFS Part 500: The 72-Hour Cybersecurity Window

The New York Department of Financial Services requires covered entities to notify the superintendent within 72 hours of determining that a “cybersecurity event” has occurred. The definition is broader than the federal rule: any act or attempt, successful or not, to gain unauthorized access to, disrupt, or misuse an information system or the information stored on it.

Part 500 also requires notification within 24 hours for ransomware events, whether or not the ransom is paid and whether or not the attack was successful. The 24-hour clock for ransomware starts at determination, not at resolution.

Filing is through the DFS cybersecurity portal. The submission requires:

• Date and time of the event
• Description of how the event was discovered
• Description of the event including type and scope
• Affected information systems and data
• Remediation steps taken or planned
• Whether law enforcement has been contacted

The 72-hour window applies per event. If a single breach affects multiple NYDFS-regulated entities within the same corporate family, each entity files independently.

State MSB Reporting: 50 Jurisdictions, 50 Rules

Money services businesses hold licences in every state where they operate, and each state has its own reporting requirements for material events. There is no uniform standard.

Event type	Typical state requirement	States with strictest rules
Data breach affecting customers	30–60 days to notify customers; regulator notification varies	CA (72 hours to AG), NY (72 hours to DFS)
Material change in business	15–30 days advance notice	TX (15 days), CA (15 days), FL (30 days)
AML program deficiency	Varies; some require immediate notification	NY, CA
Change of control	30–90 days advance notice or prior approval	Most states require prior approval
Licence revocation in another state	Immediate or within 10 days	NY, CT, WA
Customer complaint volume spike	Varies by state	WA (quarterly report), FL (annual)

The operational burden is managing 48+ state reporting calendars simultaneously. A single data breach can trigger separate notifications to every state where affected customers reside, each with a different deadline, form, and content requirement.

Most MSBs maintain a notification matrix — a lookup table mapping event types to states, deadlines, required content, and filing mechanisms. The matrix is maintained by compliance, but the data that populates it comes from engineering: which customers were affected, what data was exposed, what the timeline of the incident was.

SELECT
  s.state_code,
  s.regulator_name,
  s.notification_deadline_hours,
  s.filing_method,
  COUNT(c.id) AS affected_customers
FROM state_notification_requirements s
JOIN affected_customers c
  ON c.state = s.state_code
WHERE s.event_type = 'data_breach'
GROUP BY s.state_code, s.regulator_name,
         s.notification_deadline_hours, s.filing_method
ORDER BY s.notification_deadline_hours ASC;

See US Payments Regulation. State MSB licences carry ongoing obligations beyond the initial application. Reporting is not optional — a missed filing in one state can trigger licence revocation that cascades to other states.

FinCEN: The SAR Filing Obligation

Suspicious Activity Reports operate on a different cadence than incident notifications. The filing deadline is 30 calendar days from the date the suspicious activity is first detected. If no suspect is identified, the deadline extends to 60 days.

A SAR is not an incident report. It is a confidential filing that describes activity the institution believes may involve money laundering, terrorist financing, fraud, or other financial crime. The filing is made through BSA E-Filing, and the content includes a structured data section and a free-text narrative.

The engineering relevance: if an incident involves unauthorized fund movements, structuring patterns, or compromised accounts used for money laundering, the 30-day SAR clock starts at the moment your transaction monitoring system (or a human analyst) detects the suspicious activity — not when the incident postmortem concludes. A breach discovered on March 1 that reveals suspicious transactions dating back to January means the SAR clock for those January transactions has already been running for 30–60 days.

SAR timeline	Clock starts	Deadline	Extension
Standard	Date of detection	30 calendar days	60 days if no suspect identified
Continuing activity	End of 90-day review period	120 calendar days from initial SAR	None
Joint filing	Date of detection by any filer	30 calendar days	Same as standard

FinCEN examines both filing timeliness and filing quality. A SAR filed on day 29 with a two-sentence narrative and no supporting data is technically timely but will draw examiner scrutiny. The narrative must describe the who, what, when, where, and why of the suspicious activity in enough detail that a law enforcement agent can act on it without contacting the filer.

CFPB Complaints: The Consumer-Driven Clock

The Consumer Financial Protection Bureau operates a public complaint database. When a consumer files a complaint, the CFPB forwards it to the institution with a 15-day deadline to respond and a 60-day deadline to close.

CFPB complaints are not regulatory notifications — you do not initiate them. But a significant incident generates a wave of complaints, and the institution’s response to that wave is itself subject to regulatory scrutiny.

The operational pattern: a payment processing outage on Tuesday generates 400 CFPB complaints by Thursday. Each complaint requires an individual response. The response must address the specific consumer’s experience, not provide a generic incident summary. A template response that says “We experienced a system outage and apologize for the inconvenience” across 400 complaints will draw a CFPB inquiry into whether the institution is meaningfully engaging with consumer concerns.

Metric	CFPB expectation
Initial response	15 calendar days
Final response	60 calendar days
Response rate	100% — every complaint must be addressed
Timely response rate	Publicly reported; below 95% draws scrutiny
Narrative quality	Must address the individual consumer’s complaint

SEC and FINRA: Broker-Dealer Obligations

Broker-dealers registered with the SEC must disclose material cybersecurity incidents on Form 8-K within four business days of determining the incident is material. Materiality is assessed from an investor’s perspective — would a reasonable investor consider this information important in making an investment decision?

FINRA Rule 4370 requires member firms to maintain business continuity plans and to notify FINRA promptly in the event of a significant business disruption. “Promptly” is not defined with a fixed deadline, which means the regulatory expectation is effectively “as soon as reasonably possible.” Waiting until the following business week to report a Friday evening incident is not prompt.

FINRA also requires suspicious activity reporting through its own SAR filing process, independent of FinCEN. A single event involving a broker-dealer customer can require both a FinCEN SAR and a FINRA report.

Engineering the Notification Pipeline

The gap between “incident contained” and “all regulators notified” is where organizations fail. Engineering builds the systems that detect incidents and contain them. Compliance files the notifications. The handoff between the two is where deadlines get missed.

The notification pipeline has four stages:

1. Detection and classification. The incident response system classifies the event against the notification matrix. Is this a computer-security incident (federal banking), a cybersecurity event (NYDFS), a data breach (state consumer protection), suspicious activity (FinCEN), or some combination?

2. Impact assessment. Engineering provides the data compliance needs to file: affected customer count by state, data elements exposed, systems impacted, timeline of the incident, containment status. This data must be queryable, not estimated.

3. Parallel filing. Notifications to multiple regulators proceed simultaneously, not sequentially. The 36-hour federal window and the 72-hour NYDFS window run concurrently from the same determination event.

4. Tracking and escalation. Each filing has its own deadline, confirmation receipt, and follow-up requirements. A dashboard tracks filing status across all applicable regulators with countdown timers.

Incident IR-2024-0847
Determination: 2024-03-15 14:30 ET

Federal (OCC)    — Due: 2024-03-17 02:30 ET — Status: FILED
NYDFS (Part 500) — Due: 2024-03-18 14:30 ET — Status: FILED
CA AG            — Due: 2024-03-15 (ASAP)   — Status: PENDING
TX DOB           — Due: 2024-03-30 14:30 ET — Status: DRAFTING
FinCEN SAR       — Due: 2024-04-14          — Status: INVESTIGATION
CFPB (reactive)  — Due: per complaint        — Status: MONITORING

The system that tracks these deadlines must be independent of the systems that experienced the incident. If your notification tracking lives in the same infrastructure that went down, your deadlines are invisible during the period when they matter most.

A missed regulatory notification deadline is its own reportable event. If you miss the OCC’s 36-hour window, you must disclose the late filing — creating a second notification obligation on top of the first. The compounding effect of missed deadlines is why notification pipeline reliability matters as much as incident detection.