India's DPDP Act doesn't replace RBI's KYC Master Directions it runs alongside them, with a different legal basis, different retention logic, and its own penalties. Here's what that means for a fintech's KYC stack, mapped to the controls that actually satisfy it.
Most fintechs operating in India built their KYC stack around one rulebook: RBI's KYC Master Directions collect documents, verify identity, retain records for years, done. The Digital Personal Data Protection Act 2023 doesn't replace that rulebook. It runs alongside it, with its own legal basis for data collection, its own rules on consent and retention, and its own Data Protection Board that can levy penalties reaching into the hundreds of crores for non-compliance. The compliance deadline gives teams roughly 18 months to get there which sounds like a long runway until you look at what actually has to change underneath a KYC flow that was never designed for it.
Where DPDP Actually Changes Your KYC Flow
The specific obligations that touch KYC directly:
- Consent has to be granular and revocable. Pre-checked boxes and bundled consent language don't satisfy DPDP. Regulatory-mandated KYC collection can rely on "legitimate use," but anything beyond it marketing, credit scoring, secondary profiling requires its own explicit, separately revocable consent.
- Purpose limitation is enforced, not aspirational. Data collected to verify identity can't quietly get reused for a different purpose without fresh consent tied to that new purpose.
- Retention has an expiry, not just a floor. RBI requires KYC records to be kept five years post-relationship, PMLA requires ten years for transaction records that part doesn't change. What changes is that DPDP requires deletion once the legal purpose for holding the data has genuinely ended, which means "keep everything indefinitely in the data warehouse" stops being a safe default.
- Data principals get enforceable rights. Access, correction, and deletion requests need a real workflow behind them, not a support email, with a 30-day response expectation.
- Vendor contracts need to name DPDP obligations explicitly. An ISO 27001 certificate on a KYC vendor's marketing page isn't a substitute for a contract that limits what that vendor can do with the data, how long they can hold it, and what happens if they're breached.
The Part That Actually Breaks Most KYC Stacks
It's rarely the consent checkbox. It's the retention logic underneath it. Most KYC systems were built to store everything, forever, because storage is cheap and deletion is risky if you get it wrong. DPDP inverts that: indefinite retention is now the risky default, and deletion has to be technically enforced, triggered by a defined event (relationship end, purpose completion, regulatory retention window closing), not left to a policy document nobody automates against. Add a vendor layer collecting biometric selfies, running liveness checks, storing documents and most fintechs discover their retention logic lives in three different systems with three different clocks.
Mapping DPDP Requirements to What a Compliant KYC Stack Needs
Rebuilding this from scratch inside an 18-month window is the hard way to do it. Here's how each requirement maps to infrastructure that should already exist in a KYC platform built for it:
Consent: purpose-based, not blanket
Consent needs to be captured per purpose identity verification, AML screening, document storage, and any marketing or secondary use each accepted or declined independently, versioned, and logged with a timestamp and cryptographic signature rather than a single "I agree" checkbox covering everything at once. When a purpose is withdrawn, systems downstream of that consent record need to actually stop processing for that purpose not just log the withdrawal and continue.
Data minimization: share less by design
The cleanest way to satisfy purpose limitation is to not hold or transmit more data than the purpose requires in the first place. Selective disclosure zero-knowledge proofs that let a verifier confirm "this user is over 18" or "this user passed KYC" without ever receiving the underlying date of birth or document scan turns data minimization from a policy commitment into a structural property of the verification itself.
Retention and deletion: enforced, not documented
Retention windows need to be configurable per data category and per regulatory regime KYC documents on one timeline, biometric templates on another, marketing consent on a third and deletion needs to execute automatically when a window closes: purge the record, anonymise what has to persist for audit purposes, fire a webhook so downstream systems know it happened, and produce a signed erasure certificate as proof. A user's deletion request should complete in seconds, not sit in a queue until the 30-day statutory deadline is nearly missed.
Vendor accountability: signed, auditable, contractual
Every webhook and API call moving verification data between systems should be cryptographically signed, session-scoped, and free of long-lived credentials sitting in a config file. And the data processing agreement with any verification vendor needs to say, explicitly, what DPDP requires it to say not rely on a certification badge to imply it.
India-specific data: handled where the regulator expects it
Aadhaar-based verification carries its own layer on top of DPDP: UIDAI's Offline Paperless KYC framework and masking norms require that only the last four digits of an Aadhaar number are ever returned to a frontend, and that Aadhaar data itself is processed and stored within India regardless of where the rest of a platform's infrastructure lives. That's a narrower, stricter requirement than general DPDP data residency, and it's easy to miss if a KYC vendor treats "data residency" as one setting instead of a per-data-category one.
Where This Gets Easier With Reusable Credentials
There's a second-order benefit that most DPDP compliance work misses: every time a user gets re-verified from scratch, that's another full set of documents collected, another consent captured, another retention clock started. A verifiable credential issued once a user passes KYC something the user holds and can present again lets a second verification event happen through selective disclosure of an already-verified claim, instead of a fresh document upload. Less new data collected per interaction means less data to justify, retain, and eventually delete which is the data minimization principle DPDP is built around, applied structurally rather than procedurally.
What This Looks Like in Practice
Hypersign's platform maps to each of these requirements directly rather than requiring a fintech to bolt DPDP logic onto an existing KYC stack:
- Consent management with purpose-based granular consent (identity verification, AML screening, document storage, marketing kept independently revocable), a timestamped and cryptographically signed audit trail, and consent receipts issued as W3C Verifiable Credentials DPDP Act 2023 is a configurable jurisdiction preset alongside GDPR and eIDAS 2.0.
- An identity vault with AES-256 encryption at rest, per-customer encryption keys, and access control that checks for active, purpose-matched consent before returning any record access is denied automatically if consent has been withdrawn, expired, or doesn't match the requested purpose.
- A right-to-erasure engine that purges and anonymises records, fires a webhook, and issues a signed erasure certificate on request, with configurable retention windows per data category well inside the 30-day statutory response window DPDP sets for data principal requests.
- Selective disclosure via zero-knowledge proofs and BBS+ signatures, so a verifier can receive a pass/fail or threshold result without the underlying document or biometric ever leaving the vault.
- Aadhaar verification handled the way UIDAI requires it masked to the last four digits on return, processed and stored within India, through a licensed Sub-AUA partner for OTP-based eKYC or UIDAI's Offline Paperless KYC framework for QR/XML verification.
- Signed, session-scoped API and webhook architecture HMAC-SHA256 signed callbacks, no long-lived credentials with data processing agreements in place for every sub-processor, and audit-ready SOC 2 Type I and ISO/IEC 27001:2022 controls.
None of this replaces a fintech's obligation to run its own DPDP gap analysis RBI's retention timelines, PMLA's transaction record requirements, and DPDP's purpose-based deletion still have to be reconciled against each other for a specific business. What infrastructure like this changes is how much of that reconciliation has to be built from zero versus configured against controls that were designed for exactly this overlap.
