Build1 publisher2 min readPublished
DPDP turns indefinite KYC retention into the risky default
India's data protection law runs alongside RBI's KYC directions with its own legal basis and its own penalties. The obligation that reaches furthest into a KYC stack is deletion that some service has to fire on a defined event.
The Engineer · Build desk
What happened
- The Digital Personal Data Protection Act 2023 runs alongside RBI's KYC Master Directions, with its own legal basis for collection, its own consent and retention rules, and its own Data Protection Board.
- Regulatory-mandated KYC collection can rest on legitimate use, while marketing, credit scoring and secondary profiling each need explicit consent that can be revoked separately.
- Access, correction and deletion requests from data principals now need a workflow behind them instead of a support inbox, with a 30-day response expectation.
- According to the post, DPDP requires deletion once the legal purpose for holding data has genuinely ended, so an indefinite warehouse copy stops being a safe default.
- Once a vendor collects biometric selfies, runs liveness checks and stores documents, the post says most fintechs find retention logic spread across three systems with three clocks.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Someone has to name one system as the authority for each retention clock. The alternative is reconciling three of them by hand at every audit.
- constraint Purpose withdrawal has to be enforced in every read path, so each new analytics or scoring consumer of KYC data costs a consent lookup to build and a test to prove.
- exposure The KYC vendor holding biometrics becomes a contractual problem for the fintech, and a certification page does not limit how long that vendor keeps documents or what it owes after a breach.
- cost Retrofitting per-category expiry into systems designed to keep everything is engineering time nobody budgeted, and it lands on the same teams running the existing onboarding flow.
Withdrawal is the obligation that reaches into running code. The post's recommendation is to capture consent per purpose, with identity verification, AML screening, document storage and any marketing use each accepted or declined independently, versioned, and logged with a timestamp and cryptographic signature [13]. So far this is a record format. The harder half is at read time: when a purpose is withdrawn, systems downstream of that consent record have to stop processing for that purpose, not log the withdrawal and continue [14]. A nightly scoring job that joins a feature table and never reads the consent table will keep scoring.
Five years separate the two retention floors [19]. RBI requires KYC records for five years after the relationship ends, and PMLA requires ten years for transaction records, and the post says that part does not change [6]. Deletion under DPDP therefore has to fire on a defined event, which the post lists as relationship end, purpose completion, or a regulatory retention window closing [11]. On where stacks fail, the post wrote: "It's rarely the consent checkbox. It's the retention logic underneath it." [10]
Most KYC systems were built to store everything forever, because storage is cheap and deletion is risky if you get it wrong [20]. That default is the thing being inverted, and inverting it is schema work: retention windows configurable per data category and per regulatory regime, KYC documents on one timeline and biometric templates on another [17].
The second half of the post maps each requirement to "infrastructure that should already exist in a KYC platform built for it", and calls rebuilding from scratch inside the window "the hard way to do it" [18]. The pitch there is build versus buy. The data minimisation argument underneath it holds anyway: selective disclosure lets a verifier confirm "this user is over 18" or "this user passed KYC" without ever receiving the date of birth or the document scan [16]. Selective disclosure changes what the verifier receives, but whichever system still holds the document needs a clock on it [17].
This is one practitioner post. It puts the runway at roughly 18 months [15] and the Data Protection Board's penalties in the hundreds of crores [2], and it does not give a start date or cite the sections. The calendar and the cap have to come from the Act and the rules before anyone sizes a programme against them.
What to watch
- Whether the DPDP Rules fix a start date that turns the post's rough 18 months into an actual calendar.
- The first Data Protection Board order against a regulated fintech, and whether it turns on retention or on consent capture.
- Whether KYC vendors start publishing contract terms that name DPDP obligations and hold periods instead of pointing at an ISO 27001 certificate.