California's Delete Act (officially the Data Removal and Opt-Out Platform Act) creates an obligation most fintechs aren't engineered for: a single mechanism through which California residents can request deletion of their personal data across every business that holds it. The platform deadline is August 1.
Most coverage of the law focuses on data brokers — the businesses explicitly named. But fintechs that touch California residents' data are downstream of this. If a broker you share data with receives a deletion request and propagates it to you, you have a downstream obligation. Buyers running due diligence on you will ask.
Here's what the engineering work actually looks like:
1. Personal data inventory
Every data store that holds California-resident PII. Postgres, S3 buckets, Redshift tables, third-party services like Segment or Mixpanel, support ticket systems, log archives. The inventory needs to be queryable, not a stale spreadsheet. Most fintechs we audit have some version of this, but maintained manually and 6–12 months out of date.
2. Identity resolution
A deletion request comes in for an email or a state ID. You need to find every record connected to that person across every store. This is harder than it sounds when you have pre-marriage and post-marriage records, email aliases the user has used, phone numbers updated over time, and records created by household members on shared devices.
3. Deletion APIs, idempotent and versioned
Not a script someone runs. A versioned API with verifiable receipts. Soft-delete first with a documented retention window (typically 30–90 days for fintechs, due to regulatory hold requirements), hard-delete after.
4. Retention conflicts resolution
Some data you legally cannot delete on demand — transaction records, AML evidence, anti-fraud signals. Your deletion service has to know which records are deletable, which are subject to retention, and which trigger a "we cannot delete this for X regulatory reason, here is the timeline when we will" response.
5. Verifiable receipts
When you tell the user (or the platform, or an auditor) "we deleted this," you need cryptographic or timestamped evidence. A log line is not enough. The receipt has to survive your data warehouse re-engineering.
6. Third-party propagation
Every vendor that received the user's data needs the deletion request. Segment, Mixpanel, your KYC provider, your support tool. This is usually the gap that kills compliance — first-party deletion works, third-party propagation is missing or manual.
7. Audit trail
Every deletion request, every action taken, every receipt issued. Append-only. Six-year retention recommended, ten-year for some fintech contexts.
Where to prioritize
The full implementation is 4–8 engineering weeks for a fintech that hasn't built it. The platform deadline matters less than the procurement-due-diligence reality: enterprise buyers are now asking "show me your data deletion architecture" as part of security review.
If you're building this between now and August, prioritize identity resolution and third-party propagation — those are the two areas where in-house teams underestimate the work and end up with a deletion service that "works" but fails real audits.
