An examination of the gap between the normative promises of DPI and the operational characteristics of existing DPI systems in India
Abstract
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 'digital public infrastructure' remains under-defined despite its growing prominence, there is still an emerging cohesion around what principles should motivate and inform the design of DPI. 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 all aspects of a DPI system, we develop an evaluation framework that interrogates DPI systems across 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; 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, genuinely open digital infrastructure.
Findings
Across ownership, development, and deployment, we find that key operational functions — and in several 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. Only Account Aggregator and Bharat Connect had some initial public consultations, with no comparable practice in the decade since.
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.
Scorecard
| System | Public ownership | Public consultation | Open source code | Open API | Voluntariness | Privacy protections | Public security disclosure |
|---|---|---|---|---|---|---|---|
| FASTagNPCI / IHMCL | 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 eKYCUIDAI | 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. | |
| DigiLockerMeitY / NeGD | Built and operated in-house by MeitY's National e-Governance Division. | The 2016 rules drew no meaningful public consultation. | 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. | |
| Account AggregatorRBI | RBI licenses the framework, but the AAs are private. | An initial 2016 consultation, but none as the framework evolved since. | No 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. | |
| Bharat ConnectNBBL (NPCI subsidiary) | 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. | |
| Unified Payments InterfaceNPCI | 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). |
The DPIs
Enables toll payments using RFID tags affixed to vehicles. Operated by IHMCL with NPCI handling settlement; tags distributed by banks; toll-plaza hardware run by private vendors.
Authentication and KYC built atop UIDAI's Central Identity Data Repository. Service delivery is delegated to private AUAs, KUAs, and ASAs operating under UIDAI access agreements.
Government-issued document wallet operated in-house by MeitY's National e-Governance Division. The 2016 Digital Locker Rules envisioned a federation of licensed DLSPs; none materialised, leaving MeitY simultaneously regulator and sole operator.
RBI-licensed framework for sharing financial data across banks and lenders, with over 100 FIPs and FIUs. Coordination is performed in practice by Sahamati, a private industry alliance.
Centralised bill-payment platform, formerly Bharat BillPay, operated by NBBL — an explicitly for-profit subsidiary of NPCI. Settlement and routing run on a managed private network. Bill-payment behaviour is repurposed for credit-profile construction.
Operated by National Payments Corporation of India (NPCI), an organisation comprised of public and private banks. Processed over 85% of India's digital payments in 2026. Software and specifications are closed-source. Binds digital transactions to user identity and allows payment providers to user monetize transaction history.
Essays in response
Placeholder summary for essay #1 — the final dek will appear here once the essay is confirmed.
Placeholder summary for essay #2 — the final dek will appear here once the essay is confirmed.
Placeholder summary for essay #3 — the final dek will appear here once the essay is confirmed.
Placeholder summary for essay #4 — the final dek will appear here once the essay is confirmed.
Placeholder summary for essay #5 — the final dek will appear here once the essay is confirmed.