The FTC's 30-Day Breach Notification Requirement: What Non-Bank Fintechs Keep Getting Wrong

TL;DR

• The FTC’s Safeguards Rule amendment has required non-bank financial institutions to notify the FTC within 30 days of discovery of a breach affecting 500+ consumers, since May 13, 2024
• The 30-day clock starts when any employee discovers the breach — not when legal decides it’s reportable
• The FTC posts all notifications publicly — this is not a quiet regulatory filing
• Most fintech incident response plans are built around the SEC’s 4-day rule or the banking agencies’ 36-hour rule, and don’t address the FTC requirement at all
• Non-bank fintechs performing mortgage, payment, lending, or advisory functions under GLBA are likely covered and may not know it

Most fintech incident response plans are built around the wrong clock.

The SEC’s 4-day materiality determination rule gets a lot of attention. The banking agencies’ 36-hour notification requirement is well-documented. State breach notification laws get checked. What often doesn’t make it into the incident response runbook is the obligation that applies to the largest category of fintechs — the ones that aren’t banking-supervised but are still financial institutions under the Gramm-Leach-Bliley Act: the FTC’s 30-day notification requirement.

It went into effect May 13, 2024. Two years later, it still doesn’t show up in most fintech IR plans.

What the Rule Actually Requires

In October 2023, the FTC amended the Standards for Safeguarding Customer Information — the Safeguards Rule — to add a mandatory breach notification requirement. The amendment took effect May 13, 2024.

The core requirement: non-banking financial institutions must notify the FTC no later than 30 days after discovery of a notification event affecting 500 or more consumers.

A “notification event” is defined as the unauthorized acquisition of unencrypted customer information without the authorization of the individual to whom it pertains. The definition focuses on what was taken, not how — so ransomware that exfiltrates unencrypted records triggers it, as does an unauthorized third-party accessing a misconfigured database.

The submission happens via a form on the FTC’s website. And here’s the part that surprises most compliance teams: the FTC posts breach notifications publicly. This isn’t a confidential regulatory filing. Submit a notification, and it appears in the FTC’s public breach repository, accessible to journalists, competitors, and customers.

Who This Covers (and Who Assumes It Doesn’t Apply to Them)

The FTC Safeguards Rule applies to financial institutions subject to the FTC’s jurisdiction under GLBA. The list is broader than most fintech compliance teams expect:

The common assumption that trips fintechs: “We’re not a bank, so the banking notification rules don’t apply to us.” That’s correct — and it leads to the wrong conclusion. The banking notification rules don’t apply. The FTC notification rules do.

A fintech that processes payments, extends credit, services loans, provides financial advisory services, or facilitates wire transfers — and that is not supervised by the OCC, FDIC, or Federal Reserve — is almost certainly a non-banking financial institution under the FTC Safeguards Rule.

The Detail That Makes This Hard to Manage: When Does the Clock Start?

The 30-day clock in the FTC’s rule starts from discovery — not from determination, not from legal sign-off, not from a formal incident declaration.

More specifically: the clock begins running when any employee of the institution has relevant knowledge of the notification event. Not when the CISO escalates it. Not when the breach response vendor confirms the scope. Not when legal determines it meets the notification threshold.

When the customer service rep who noticed the strange login pattern sends a Slack message to IT. When the engineer who found the misconfigured S3 bucket files the internal ticket. When the support agent who got a customer complaint about unauthorized charges flags it to their manager. The FTC doesn’t restart the clock when the incident formally enters your IR process — it started when the first employee knew.

This has structural implications for incident response planning. An IR plan built around the assumption that the notification clock starts when legal or compliance makes a threshold determination is operating with a 30-day window that may already be several days shorter. If there’s a week between initial discovery by a non-compliance employee and formal escalation into the IR process, the practical notification deadline is 23 days after the escalation, not 30.

The Map Doesn’t Match: Why Most IR Plans Miss This

The typical fintech IR plan is built around two notification frameworks:

If you’re publicly traded, the SEC’s cybersecurity disclosure rule drives the planning. The SEC’s 4-day materiality clock runs from when the company determines an incident is material — a determination that inherently involves legal and governance judgment. That framework shapes IR plans around the materiality determination process.

If you’re banking-supervised, the agencies’ Computer-Security Incident Notification Rule requires 36 hours after determining that a notification incident has occurred. Again, the clock runs from determination — which your primary federal regulator expects you to make promptly but which is still a determination.

The FTC’s 30-day rule doesn’t fit either model cleanly. The clock runs from discovery, not determination. The recipient is the FTC, not a primary federal regulator. And the disclosure is public, not regulatory-confidential.

Most fintech IR plans are built to handle the SEC or banking frameworks. The FTC requirement has different mechanics, a different starting trigger, and different consequence — and most plans don’t address it.

The Public Posting Problem

If you’re building the case internally for why this deserves attention in your IR plan, the FTC’s public posting policy makes it straightforward.

When a non-banking financial institution submits a breach notification to the FTC, the FTC posts that notification on its public website. The information made publicly available includes the name of the reporting institution and information about the breach event.

This changes the reputational calculus of notification. A banking organization that notifies its primary federal regulator through regulatory channels has made a regulatory disclosure. A non-banking financial institution that notifies the FTC has effectively published a breach announcement that anyone can find.

The practical effect: the IR decision process can’t treat FTC notification as purely a compliance filing. It’s a communications event with public consequence. The timing of the FTC notification relative to any voluntary consumer disclosure and press statement becomes operationally important — because the FTC may publish the notification before the company has communicated with its customers.

Running Multiple Clocks Simultaneously

For most non-bank fintechs, a breach affecting 500 customers doesn’t trigger just the FTC notification requirement. It likely triggers:

FTC Safeguards Rule: 30 days from discovery, notification to FTC, public posting.

State breach notification laws: Applicable based on where affected consumers reside. State breach notification timelines vary significantly — California’s CCPA notification requirement for 500+ residents operates on different timing than New York’s SHIELD Act. If consumers are spread across multiple states, multiple state obligations run simultaneously, some shorter than 30 days.

CFPB examination expectations: Fintechs subject to CFPB supervision may have additional notification and examination obligations. The CFPB does not have its own breach notification rule, but it treats incident response adequacy as a UDAAP and data security examination issue.

Contractual notification obligations: Bank partners typically require notification of security incidents within 24–72 hours under the partnership agreement. This obligation runs separately from any regulatory reporting requirement and is often the shortest clock in the room.

Managing these simultaneously requires a single incident fact record with separate obligation-tracking fields for each regime. The approach of identifying clocks serially — “first figure out if this is reportable, then figure out to whom” — doesn’t work when four clocks are running from different trigger events with different recipients.

What an FTC-Ready IR Plan Looks Like

Specifically for the FTC Safeguards Rule obligation, an adequate incident response plan addresses six things that generic IR plans typically omit:

1. Confirms coverage. The plan explicitly identifies whether the organization is a non-banking financial institution under the GLBA, and who made that determination. This isn’t assumed — it’s documented.

2. Defines “discovery” operationally. The plan establishes that employee-level awareness of a potential breach event triggers the internal escalation process, and that the 30-day clock begins at that moment. It includes a clear internal reporting protocol so that the first employee with relevant knowledge notifies someone in the IR chain within 24 hours.

3. Assigns notification ownership. One person has authority to submit the FTC notification. The plan identifies them by role, with a backup, and includes credentials to access the FTC notification portal.

4. Addresses the public posting consequence. The plan includes a communication protocol for coordinating the timing of the FTC notification with customer communication and any press response. The compliance team doesn’t make the notification filing in isolation without the communications team knowing.

5. Maps state obligations simultaneously. The plan includes a state breach notification checklist that runs in parallel with the FTC clock — not sequentially after it.

6. Documents the threshold analysis. The plan includes a formal process for determining whether the event affects 500+ consumers, because that threshold determination gates whether the FTC requirement is triggered. An event that is definitively below 500 consumers doesn’t require FTC notification; one that is above it does; one that might be above it requires a documented scope assessment before the deadline.

So What?

The FTC’s 30-day breach notification requirement has been in effect since May 2024. The covered population — non-banking financial institutions under GLBA — is large and includes most of the fintech industry.

The rule has two features that distinguish it from the SEC and banking agency frameworks that most IR plans are built around: the clock starts at discovery (not determination), and the notification is posted publicly (not filed confidentially).

Neither of those features reduces the importance of the obligation. If anything, they increase it. A 30-day clock that starts when any employee knows — not when legal confirms — is a shorter clock in practice than it appears on paper. A public posting that precedes your customer communication is a communications crisis if you weren’t planning for it.

Every non-bank fintech with a bank partnership, lending program, payment product, or financial advisory service should verify that its incident response plan explicitly addresses the FTC Safeguards Rule. The right question is not whether you need a separate section of your IR plan for the FTC requirement. You do. The question is whether your plan already has it.

Related reading: Cyber Incident Notification: Bank, SEC, State, and Future CIRCIA Clocks | State Breach Notification Laws: 50-State Comparison

Build the incident response program that covers all your notification obligations. The Incident Response & Breach Notification Kit includes multi-regulator notification tracking, a threshold analysis worksheet, consumer notification templates, and a tabletop exercise scenario covering the moment of discovery — the trigger event most IR plans underprepare for.