An examination of the gap between the normative promises of DPI and the operational characteristics of existing DPI systems in India
Digital Public Infrastructure (DPI) is increasingly promoted as a foundational layer of digital development — a framework for expanding service delivery, fostering digital economies, and enabling identification, payments, and data exchange at a large scale. This paper examines the gap between the normative promises of DPI and the operational characteristics of existing DPI systems in India.
While DPI remains under-defined despite its growing prominence, there is still an emerging cohesion around what principles should motivate and inform its design. Academic and government resources often identify "interoperability," "openness", security, privacy and participatory governance as central to DPI. These attributes are also related to policy decisions such as who owns the infrastructure, who operates it, who holds user data, who bears liability for its maintenance, how open participation is to new entrants, and more. In an effort to evaluate the gap between these normative promises and the operational characteristics of existing DPI systems in India, we develop a framework spanning six dimensions: ownership, governance models, voluntariness of use, economic incentives, data collection and use, openness, and security.
We apply this framework to analyse six projects in India: FASTag, Aadhaar eKYC, DigiLocker, Account Aggregator, Bharat Connect and Unified Payments Interface. Our analysis relies primarily on government publications — legislation, regulatory rules, press notices, and official documentation — supplemented by published research, news coverage, and materials from private companies and industry bodies.
Our findings show that Indian DPI systems fall short not only of the aspirational principles articulated by academics and civil society, but of the Indian government's own stated claims. Our findings point to a need for a concerted effort in radically changing current deployments to be oriented towards the idealised vision that motivates the agenda: publicly controlled, privacy-respecting, open digital infrastructure.
Across ownership, development, and deployment, we find that key operational functions — and in some cases the regulatory functions meant to oversee them — are delegated to private companies largely insulated from public scrutiny.
In none of the six DPIs we studied was there an active forum or avenue for public participation. Some DPIs (DigiLocker, Account Aggregator and Bharat Connect) had initial public consultations, with no comparable practice during subsequent years of operation.
There are sparse repositories of open source code, but the core infrastructure remains a black box. In cases where API specifications are public, the API is closed to a set of entities — even for functionalities that could be made open.
DPIs bind user behaviour to government-issued identifiers, link activity across services that previously existed in silos, and concentrate data in centralised repositories accessible to state actors under broad statutory exemptions. In some cases, private-sector participation in these DPIs is incentivised by the ability to collect user data and derive behavioural inferences from it — permitting commercial exploitation of user data.
DPIs set their security boundaries to be at the core infrastructure, while third-party integrators and components (through whom most real-world breaches occur) are excluded from the security model.
| System | Public ownership | Public consultation | Open source code | Open API | Voluntariness | Privacy protections | Public security disclosure |
|---|---|---|---|---|---|---|---|
| FASTagNPCI / IHMCLElectronic toll collection | Run by NPCI's settlement layer and IHMCL, both of which have public-private shareholding. | Rolled out through ministry directives with no consultation on record. | No open-source components or publicly accessible APIs. | Integration is limited to acquirer banks. | Mandatory — vehicles without a FASTag are charged higher toll. | Movement data is linked to user identity with provisions for data sharing and unclear retention. | No public vulnerability-disclosure process, service providers must disclose incidents to NPCI |
| Aadhaar eKYCUIDAIBiometric identity verification | Owned and operated by UIDAI, a statutory public authority. | Enrolment and eKYC expanded without public consultation. | The CIDR and authentication stack are closed. | APIs are documented but usable only by UIDAI-designated KUAs/AUAs under agreement. | Essentially mandatory, required in practice for welfare, mobile connections and finance. | Links user activity to one identifier, broad statutory exemptions for state access. VID present, but not widely supported. | Bug bounty program limited to vetted researchers, disclosure to users is inconsistent. |
| DigiLockerMeitY / NeGDDigital document storage | Built and operated in-house by MeitY's National e-Governance Division. | Two public consultations, both after it was launched | Application code is not published. | Issuer and requester APIs exist but require formal onboarding. | Optional for most uses, though increasingly the default in government workflows. | Documents tie to Aadhaar; protections exist but the linkage raises exposure. | Participating entities have to report security breaches, but notification to users is not mandatory. |
| Account AggregatorRBIFinancial data sharing | RBI licenses the framework, but the AAs are private. | An initial 2016 consultation, but none as the framework evolved since. | N/ANo central codebase; ReBIT specifications enable some open libraries. | Specifications are public, but live access is gated to licensed participants. | Consent-based by design, though onboarding is often nudged inside lending flows. | A consent architecture exists; reuse for credit profiling and surveillance weakens it. | Security incidents must be reported to the RBI. |
| Bharat ConnectNBBL (NPCI subsidiary)Unified bill payment | Operated by NBBL, an explicitly for-profit subsidiary of NPCI, which is a private consortium. | Launched after public consultation. | The core BBPS processing infrastructure is closed. | Public API spec, access controlled by NPCI certification over a managed network. | Use is optional, but it is the default for many billers. | Bill-payment behaviour is repurposed to build consumer credit profiles. | No public vulnerability-disclosure or breach-reporting process. |
| Unified Payments InterfaceNPCIDigital payments system | Operated by NPCI, a private consortium. | Introduced through directives without public consultation. | Core software is closed-source. | Permissioned API. Specifications were public but have been withdrawn. | Optional, but near-unavoidable for everyday payments. | Transaction records linked to user identity (phone number/bank account/Aadhaar). | Data breaches associated with third-party intergrators were scoped out. |
Coming soon
Coming soon
Coming soon
Coming soon