What the DPDP Act 2023 means for KYC-collecting institutions
India's Digital Personal Data Protection (DPDP) Act 2023is the country's first comprehensive data protection law. For regulated financial institutions — banks, NBFCs, insurers, brokers — it creates specific obligations around how personal data collected during KYC is handled, retained, and protected.
The core principles that affect KYC operations are:
- Purpose limitation: Data may only be used for the specific purpose it was collected.
- Data minimisation: Only data necessary for the stated purpose may be collected.
- Storage limitation: Data must not be retained beyond the period necessary.
- Consent: Processing requires explicit, specific, informed, and revocable consent.
- Data fiduciary obligations: Institutions become liable for breaches and non-compliance.
The Act frames two parties that matter here: the Data Principal (the individual the data is about) and the Data Fiduciary (the institution that determines why and how the data is processed). A KYC-collecting bank or NBFC is a Data Fiduciary, and that role — not the technology it uses — is where accountability sits. The design question is therefore not whether to verify identity, but how to do so while moving the smallest possible amount of personal data and keeping a clear record of the consent that authorised it.
The DPDP liability problem in traditional KYC
Traditional KYC creates significant DPDP exposure:
- Document copies: Banks store Aadhaar, PAN, and passport scans — all sensitive personal data requiring DPDP consent and purpose limitation.
- Duplicate storage: The same Aadhaar card stored independently by a bank, mutual fund, insurer, and broker — each a separate liability.
- Retention ambiguity: KYC regulations require five-year retention after relationship ends, while DPDP's minimisation principle creates tension with this.
- Breach exposure: A DPDP breach involving KYC data can attract penalties up to ₹250 crore per instance.
Key insight: The DPDP Act does not eliminate KYC — it changes what institutions are allowed to store. The goal is to verify identity without retaining the underlying documents unnecessarily.
How verifiable credentials solve the DPDP problem
A verifiable-credential model does not remove any DPDP obligation from the institution. What it changes is the surface area of personal data the institution has to hold, and the clarity of the consent record behind each use. Each core principle maps onto a concrete architectural property.
Data minimisation by design
Instead of storing a copy of the customer's Aadhaar card, an institution stores a cryptographic assertion: "This customer has been verified to KYC assurance level HIGH by AssureLocker, with Aadhaar OTP and face liveness as evidence."No Aadhaar number, no document image, no raw biometric. Minimisation is not a policy the institution has to remember to enforce at collection time — it is the default state of what gets stored, because the raw document never has to land in the institution's systems in the first place. That shifts minimisation from a procedural control (which can lapse) to a structural one.
Selective disclosure
Using SD-JWT credentials, holders share only the specific claims needed for a transaction. A loan application might need proof of address but not date of birth; an age check might need only a "yes/no" over-18 assertion rather than a full date of birth — with selective disclosure, verifiers never receive data they do not need. This is the operational expression of purpose limitation at the level of individual attributes: the verifier cannot later re-purpose data it was never given.
Consent-driven presentation
Every credential presentation under OID4VP requires an active, per-transaction consent step by the holder. Rather than a one-time blanket authorisation signed at account opening, each share is a specific, informed act tied to a named purpose — which is closer to what the Act means by consent that is specific and informed. Because the presentation is cryptographically bound to the request, the consent record is not a checkbox in a form but a verifiable event.
Purpose limitation and storage limitation
When an institution receives an attribute-level assertion for a stated purpose, there is simply less to re-use for anything else, and less to retain once the purpose is served. KYC record-keeping rules still apply — regulated entities have their own retention duties — but those duties can increasingly be met with a credential reference, an assurance level and an audit record rather than a warehouse of document scans. Where a document scan genuinely must be kept to satisfy a sectoral rule, that becomes a deliberate, narrow exception rather than the default posture for every customer.
Data-principal rights
The DPDP Act gives Data Principals rights to access a summary of their data, to seek correction and erasure, and to withdraw consent. A model where the individual holds their own credentials and each institutional use is a discrete, logged consent event makes these rights more tractable to honour: the consent trail shows what was shared, with whom, for what, and when; and because the institution holds derived assertions rather than sprawling raw copies, responding to a correction or erasure request touches a far smaller footprint. None of this transfers the duty to respond away from the institution — it lowers the cost of discharging it.
Mapping DPDP principles to a consented, reusable KYC model
The table below sets out, principle by principle, what the Act broadly requires and how a consent-based, verifiable-credential approach helps an institution move toward it. It is a general mapping for orientation, not a compliance determination — the responsibility for meeting each obligation stays with the institution as Data Fiduciary.
| DPDP principle | What it requires | How reusable/consented KYC helps |
|---|---|---|
| Consent | Processing on a specific, informed, freely-given and withdrawable consent tied to a stated purpose | Per-presentation consent under OID4VP, cryptographically bound to each request, produces a discrete, verifiable consent event instead of a one-time blanket authorisation |
| Data minimisation | Collecting only the personal data necessary for the stated purpose | Institutions receive attribute-level assertions (an assurance level, a verified claim) rather than full document copies, so the raw document need not enter their systems at all |
| Purpose limitation | Using data only for the purpose for which it was collected | Selective disclosure hands over only the specific claims a transaction needs, so there is nothing surplus to silently re-purpose |
| Storage limitation | Not retaining personal data longer than necessary for the purpose | A credential reference, assurance level and audit record can satisfy much record-keeping, shrinking long-lived stores of raw PII to deliberate, narrow exceptions |
| Data-principal rights | Honouring access, correction, erasure and consent-withdrawal requests | A logged consent trail and a smaller retained footprint make it more tractable to locate, correct or erase what was actually shared |
| Data-fiduciary accountability | Remaining answerable for security, breach notification and lawful processing | Less raw PII in scope narrows breach exposure, but the accountability itself stays with the institution — the model reduces surface area, it does not transfer the duty |
DPDP compliance posture comparison
| Obligation | Traditional KYC | DigiKYC with Verifiable Credentials |
|---|---|---|
| Data minimisation | ❌ Full document copies stored | ✅ Only cryptographic assertions |
| Purpose limitation | ⚠️ Documents reused broadly | ✅ Selective disclosure per transaction |
| Storage limitation | ❌ Raw data retained indefinitely | ✅ Credential metadata only, defined expiry |
| Consent | ⚠️ One-time blanket consent | ✅ Per-presentation consent via OID4VP |
| Breach exposure | ❌ High — Aadhaar/PAN data at risk | ✅ Minimal — no raw PII stored |
What this means for your compliance roadmap
The DPDP Act Rules — currently being finalised by MeitY — will create specific obligations for retention periods, consent mechanisms, and breach notification in the financial sector. Institutions migrating to a verifiable credentials model now will be well-positioned before enforcement begins. Those continuing to accumulate raw document stores will face a complex, costly remediation exercise.
A note on where responsibility sits. AssureLocker is a technology service provider: DigiKYCsupplies the consent-based, minimal-disclosure identity infrastructure — selective-disclosure credentials, per-presentation consent, and an auditable consent trail — that makes a data-minimising posture practical to build. It does not make an institution DPDP-compliant on its own, and it does not make compliance decisions on an institution's behalf. Under the Act the institution remains the Data Fiduciary, responsible for its own lawful basis, retention choices, breach handling and rights fulfilment. The right way to read this article is: the architecture can materially reduce the personal-data surface area you have to defend, but the compliance obligations — and the accountability for meeting them — stay with you. This is an educational overview, not legal advice; assess your obligations with qualified counsel.
To discuss how AssureLocker maps to your DPDP compliance roadmap, book a demo with our team.