#DigiLocker and the DPDP Act: MeitY Is Empanelling Contractors to Sell India's Document Wallet to Banks, Insurers and Hospitals

The government is hiring outside agencies to grow DigiLocker's footprint inside private banks, insurers, hospitals and colleges — and the tender doing it never says whether those agencies are data fiduciaries or data processors under the DPDP Act. Responses close on 10 October 2026, roughly five weeks before the consent manager regime starts and seven months before the DPDP Act's substantive obligations bite in full.

The document is a Request for Empanelment (RFE) published on 21 September 2026 by the National e-Governance Division (NeGD), the MeitY body that runs DigiLocker. It was first reported by MediaNama on 25 September. It has attracted almost no scrutiny, which is odd for a procurement that proposes to put commercial intermediaries into the flow of government-issued identity documents belonging to 72.43 crore registered users.

#What the 21 September RFE Actually Asks For

NeGD is not buying technology. It is buying business development.

The RFE outsources the job of expanding DigiLocker's user and integration base: empanelled agencies are to identify institutions, work out use cases, bring those institutions onto the platform as "Requesters," and handle the technical integration. The agency's deliverable is adoption.

The indicative use cases are specific, and they are not small:

Financial services. Customer KYC and onboarding for lending, account opening and insurance. Income and address verification for underwriting. The documents named include Aadhaar, PAN, driving licences, voter ID, vehicle registration certificates and insurance policies.

Education. Admission and scholarship processing, plus verification of academic credentials — marksheets and degree certificates issued by CBSE, state boards, universities and institutions integrated with the National Academic Depository.

Health. Insurance claims processing, patient registration, and verification of practitioner credentials, drawing on Aadhaar, PAN, insurance policies and ABHA-linked documents.

The RFE states these are indicative only; agencies may propose their own use cases built on documents already integrated into DigiLocker. That is an open invitation to invent new ways of moving citizens' government documents into private hands.

To be clear about what the RFE does get right: it is not a careless document. Empanelled agencies must comply with the DPDP Act, 2023 and CERT-In directions. They cannot retain, store, cache, profile or put Issued Document content to any secondary use. They must act only on the Requester's documented instructions for the approved service. They must report suspected security incidents to NeGD and CERT-In within prescribed timelines, cannot hold production API credentials independently, must keep auditable logs, and must host all development, test and support infrastructure in India. There is an explicit no-vendor-lock-in clause: Requesters keep their DigiLocker access independent of the agency, and on exit the agency must hand over all Requester documentation and certify destruction of confidential information.

Those are better terms than most Indian government IT tenders carry. The problem is not the controls. It is what the controls leave undecided.

#The DPDP Act Question the RFE Does Not Answer: Who Is the Data Fiduciary?

"Comply with the DPDP Act" is not an allocation of responsibility. The Act works by assigning roles, and the roles here are genuinely unclear.

Section 2(i) defines a Data Fiduciary as the person who, alone or with others, determines the purpose and means of processing. A Data Processor processes on the fiduciary's behalf. The entire compliance architecture — notice, consent, breach reporting, erasure, grievance redress, penalties — hangs on that distinction.

Now map it. NeGD runs the platform. The Issuer (CBSE, a state transport authority, UIDAI) holds the source record. The Requester (a bank, a hospital) receives the document. And the empanelled agency sits across all three, deciding which institutions to approach, which use cases to build, and how the integration works.

The "documented instructions" language points at processor status, which is the natural reading for the integration work. But an agency that designs the use case, selects the institutions and shapes how citizens are onboarded is doing something closer to determining means — and possibly purpose. An agency running an onboarding drive is also collecting personal data from citizens directly in order to sign them up, which is not processing on anyone's documented instructions at all.

This matters because processors do not carry direct DPDP liability to data principals; fiduciaries do. Section 8(1) makes the Data Fiduciary responsible for compliance including for processing done by a processor on its behalf. If NeGD is the fiduciary for onboarding activity carried out by a commercial agency across four sectors, MeitY has taken on a large and poorly specified exposure. If it is not, then citizens onboarded by a contractor need to know who is. The RFE, on the available reporting, does not say.

There is a cleaner version of this: name the roles in the contract. Processor agreements are ordinary commercial instruments, and Rule 3's notice requirements in the DPDP Rules, 2025 will apply to whoever ends up on the fiduciary side of the line by May 2027. Deciding it now costs a paragraph. Deciding it after the Data Protection Board asks costs considerably more.

#Rule 9A's Deemed-Sharing Fiction Collides With the DPDP Act

DigiLocker's legal foundation predates the DPDP Act by seven years, and the two frameworks describe the same event differently.

Under Rule 9A of the Information Technology (Preservation and Retention of Information by Intermediaries Providing Digital Locker Facilities) Rules, 2016, documents in a subscriber's locker are treated at par with originals. Crucially, when a Requester accesses or accepts a certificate from a subscriber's account, it is deemed to have been shared by the Issuer directly in electronic form.

That deeming provision exists to solve an evidentiary problem — it makes the digital copy legally reliable. But read alongside the DPDP Act, it quietly relocates the transaction. The citizen pulls a document from their own locker and hands it to a bank; the law says the government issuer sent it. The data principal, who did the actual act of sharing, becomes invisible in the legal description of the event.

DigiLocker's own "My Consent" dashboard does real work here — users can see which applications have access and revoke it. Functionally, that is consent management. Formally, it is not a Consent Manager under Rule 4 of the DPDP Rules, which requires registration with the Data Protection Board, incorporation in India, a minimum net worth of ₹2 crore and demonstrated interoperability. Rule 4 comes into force on 13 November 2026.

So India is about to have two parallel consent layers for the same citizen: a registered, regulated Consent Manager ecosystem, and a 72-crore-user government wallet with its own consent dashboard operating under 2016 intermediary rules. Pushing DigiLocker deeper into private-sector KYC — precisely the use case Consent Managers were designed to intermediate — before that relationship is resolved is a sequencing choice, and not obviously the right one. Businesses building consent infrastructure now should be planning for both surfaces; our consent manager guidance covers what Rule 4 registration actually demands.

#Section 17 Protects NeGD. It Does Not Protect the Contractor.

There is an asymmetry in this arrangement that deserves more attention than it gets.

Section 17 of the DPDP Act carves out the State. For processing by the State or any instrumentality of the State, Section 8(7) — the erasure obligation — and Section 12(3) do not apply, and Section 12(2) falls away where processing does not involve a decision affecting the data principal. Section 17(2)(a) goes further, letting the Central Government exempt notified state instrumentalities from all or part of the Act by gazette notification, without Parliament.

Section 17(2)(a) exempts notified state instrumentalities. It does not exempt their private contractors.

An empanelled agency is a company. It gets no Section 17 shelter. By 13 May 2027 it will be fully exposed to the Act's penalty schedule — up to ₹250 crore for a security failure leading to a breach, ₹200 crore for breach-notification failures, ₹150 crore for general fiduciary obligations. Meanwhile the government body that designed the programme, set its objectives and defined its use cases sits behind a statutory carve-out.

That is not an argument against the programme. It is an argument for pricing the risk honestly. Any agency responding by 10 October should be modelling DPDP liability as a real cost line, not a compliance checkbox — and negotiating indemnity accordingly.

#Growth Targets and the Consent Problem

The structural risk here is not malice. It is incentive design.

When the deliverable is adoption, the pressure runs toward volume. Onboarding drives, bundled permissions, pre-ticked flows, "link your DigiLocker for faster processing" prompts at moments when the citizen wants the loan or the admission or the claim settled. None of that requires anyone to break the RFE's rules about retention and secondary use. All of it produces consent that is technically recorded and substantively hollow.

Section 6(1) of the DPDP Act requires consent that is free, specific, informed, unconditional and unambiguous, given by a clear affirmative action, limited to the personal data necessary for the specified purpose. A growth-incentivised intermediary is structurally in tension with "free" and "specific."

Indian regulators have started noticing this pattern. IRDAI's 23 September consultation paper treated forcing consumers to hand over personal details before seeing insurance prices as a dark pattern — using consumer law to reach a data minimisation outcome twenty months before the DPDP Act gets there. The same logic applies to document-wallet onboarding. If a college cannot process an admission without a DigiLocker link, the consent is conditional, and conditional consent is not consent under Section 6.

The fix is unglamorous and well understood: define the purpose narrowly per use case, keep the fetch scoped to the specific documents the transaction needs, make DigiLocker one option among several rather than the fast lane, and log refusals as well as approvals. Whether an empanelment programme measured on adoption will do any of that is a question worth asking before contracts are signed.

#Health Data Raises the Stakes

The health use cases are the ones to watch.

Practitioner credential verification is comparatively benign. Patient registration and insurance claims processing are not. Claims data reveals diagnoses. ABHA-linked documents sit inside the Ayushman Bharat Digital Mission's federated architecture, which has its own consent layer and, under the Health Data Management Policy, its own localisation requirement.

The DPDP Act does not create a special category for sensitive personal data — a well-known divergence from the GDPR, which treats health data under Article 9 with heightened protections. India instead relies on general obligations applying uniformly. That design choice means an intermediary handling hospital registration data faces the same baseline framework as one handling degree certificates, even though the harm profiles are nothing alike.

Adding a commercially incentivised third party to health-document flows, in a statute with no sensitive-data tier, before the Data Protection Board has a single appointed member, is worth pausing on. MeitY invited applications for the Board's Chairperson and Members on 6 May 2026. The Board exists in law. It is not yet staffed to supervise anything.

#What Organisations Should Do Before 10 October

For banks, insurers, hospitals and educational institutions being approached as Requesters:

Ask who your counterparty is. If an empanelled agency onboards you, establish in writing whether it is acting as your processor, NeGD's processor, or an independent fiduciary. Get it into the integration agreement.

Scope the fetch. Pull the specific documents the transaction requires. An underwriting decision needing income verification does not need a vehicle registration certificate because the API makes it convenient.

Do not let convenience become conditionality. Keep a non-DigiLocker path open and equally usable. A DigiLocker-only workflow converts platform adoption into compelled consent.

Map it against May 2027, not today. MeitY Secretary S. Krishnan told a Startup Policy Forum compliance clinic on 31 August that the notified deadlines will not be extended. An integration architected in October 2026 will be operating under the full Act well within its contract term.

For agencies considering a response: the ten-day window closing on 10 October is short for a procurement whose DPDP role allocation is undefined. Seek clarification in writing before bidding.

#The Bigger Point

India built its digital public infrastructure on a premise that citizens control the flow of their own documents. DigiLocker's consent dashboard, Rule 9A's authenticity guarantee and the Act's consent architecture all point the same way.

Introducing commercial intermediaries whose success is measured by adoption does not break that premise. But it does put pressure on it at exactly the moment the DPDP Act's enforcement machinery is least able to respond — a Board without members, a consent manager regime six weeks from starting, and substantive obligations still seven months out.

Getting the roles written down before the contracts are signed is cheap. Litigating them in 2028 will not be.

---

Building DPDP-compliant consent flows or assessing third-party integration risk? Our resources library covers data fiduciary obligations, processor agreements and Rule 4 registration. If you are designing consent architecture ahead of the 13 November 2026 milestone, start with our consent manager breakdown.