In Episode 2 we built continuous governance. Now the part that breaks it: proving you deleted a specific customer's non-regulatory data from core, warehouse, support, backups, and the KYC vendor, with an evidence log.
Retention is not a policy problem. It is a field-level engineering problem with a legal overlay. Most BFSI teams are solving the wrong version of it.
Two corrections before you build anything
Most DPDP retention guidance is written for consumer platforms and then applied to finance. That produces two expensive errors.
The 3-year inactivity erasure and 48-hour pre-erasure notice bind only three classes. A bank, NBFC, digital lender, PA, or broker is none of these.
Caveat: a group marketplace, BNPL-in-ecommerce, or gaming-adjacent product above threshold may catch that entity. Scope at entity level, not group level.
Retain personal data, traffic data and processing logs for a minimum of one year, then erase them unless another law requires further retention. It reaches processors too.
DPDP does not just tell you what to keep. It tells you when to stop keeping it. Indefinite retention now needs a positive legal basis, per field.
The BFSI problem is over-retention, not under-retention
Pre-DPDP, uniform 10-year schedules were rational. Under DPDP that logic inverts: data without a lawful basis is unlawful processing, a larger breach blast radius, and discovery liability.
The largest gap is not a missing record. It is years of data nobody can justify: closed-account KYC packs, dormant rows, Drive CSVs, marketing DBs, call recordings, support transcripts, analytics copies. Fix with controlled retention: every field, mapped to a basis, with an expiry and a trigger.
Five years is not one clock
Same duration, different triggers. One job keyed to account_closed_date gets transaction records wrong. Keyed to transaction_date deletes KYC five years too early.
Retention is a (field, basis, trigger event, duration, action) tuple. Anything less fails at the edges, and auditors sample the edges.
The retention register that actually matters
Stop writing a retention policy. Build a field-level register with the legal basis cited per row. Indicative for a lending NBFC. Verify against your primary circulars.
Exposure lives in the bottom half: marketing, support, warehouse copies, collections recordings, analytics derivatives. No regulatory retention mandate. Precisely what nobody deletes.
The three buckets
Resolve an erasure request per field, not per customer. A blanket "we are RBI-regulated" refusal is a finding, not a defence.
On refusal: still erase MUST-DELETE fields, communicate the basis in plain language, and document the decision for DPB scrutiny.
Deletion engineering: where it actually breaks
Deleting from the primary database is not deletion. Personal data lives in at least seven places.
Backups: crypto-shred per-record keys, or document rotation and no reintroduction on restore. Silence is not defensible. Cite NIST SP 800-88 and ISO/IEC 27040 in policy.
Legal hold must beat everything
An engine that deletes under litigation, an STR, or an RBI inspection creates spoliation. Hold is a first-class citizen with priority over every expiry rule.
Vendors, LSPs and processors
Rule 8(3) extends to processing on your behalf. If your KYC vendor still holds the data, you still hold the liability. Contract for it, then verify it.
The deletion evidence pack
Deletion you cannot prove is deletion that did not happen. Every event should write an immutable record.
Measuring it
If you track only one number: over-retention debt. It converts abstract risk into a Board metric that moves.
Common mistakes in regulated finance
The first 90 days
Build the register, engineer the pipeline, prove it. Over-retention debt compounds daily until 13 May 2027, and every month is unnecessary breach exposure.
Next: Episode 4 on breach readiness and the four-clock incident runbook. This episode reflects DPDP Rule 8 and Schedules, RBI KYC MD, PML Rules, Digital Lending Directions 2025, CERT-In 2022, and the CIC Act. Retention periods are indicative. Verify against your entity class. Not legal advice.