What is digital public infrastructure (DPI)? Explained

The three layers, concretely

Digital identity is DPI's foundation layer: a government-rooted way for a person to be enrolled once and verified many times, with the enrollment's quality setting the ceiling for everything built above it. The canonical example is India's Aadhaar, over a billion people enrolled with biometrics, with an authentication API any approved service can call, but the pattern now spans architectures: national ID cards gone digital like Malaysia's MyKad, credential wallets like Europe's EUDI program, and civil-registry modernizations where the first task is registration coverage itself. The identity layer's prerequisite is the oldest institution in the stack: civil registration, because a person never registered anywhere cannot be enrolled in anything, which is why registrar councils and their "no invisibles" missions sit at DPI's root.

Digital payments is the second layer: interoperable, low-cost rails exemplified by India's UPI and Brazil's Pix, systems that turned instant transfer into a public utility at volumes measured in billions of monthly transactions, and, notably, both grew atop their countries' identity layers rather than beside them. Data exchange is the third: consent-based sharing of verified records, a diploma, a tax status, a health record, between institutions, the layer Europe's health-data wallet rules are currently building in regulation and India's account aggregator framework builds in finance.

The layers compound: identity makes payments accountable, payments make identity valuable, and data exchange makes both portable, which is why countries that sequence identity first keep finding the other two layers arrive faster and cheaper than projected. That compounding is why the DPI argument has momentum, and why its failures would compound too.

The design arguments that matter

Underneath the acronym sit real architectural commitments, and they are worth knowing because they shape what gets built. Open standards and digital public goods: DPI's house style is openly specified protocols and reusable open-source building blocks, the MOSIP platform being the flagship, so countries assemble rather than procure monoliths, and no vendor owns the rails. Minimalism at the base: the strongest DPI designs keep the public layer thin, enrollment, authentication, consent, and leave services to the market, the "roads, not shopping malls" principle. Privacy by architecture: aggregation risk is DPI's standing critique, a national identity layer can become a national surveillance layer, so the credible designs answer structurally: tokenized identifiers that stop cross-service linking, consent artifacts for every data flow, selective disclosure in the credential layer, and audit trails the citizen can read. Where those protections are absent, the critique writes itself, and procurement documents are where the difference between DPI's promise and a surveillance stack gets decided.

What DPI changes for verification

For businesses that verify customers, DPI's maturation redraws the map in three ways. Coverage: every registry modernization and enrollment drive expands who can be verified at all, and the next hundred million onboarded identities will come disproportionately from newly covered, thin-file populations, which makes fallback routes and fairness engineering a business requirement rather than an ethics slide. Method: where identity rails expose verification APIs or credentials, onboarding shifts from document-photography toward layered flows, document forensics plus biometric binding plus registry or credential confirmation, each layer covering the others' gaps, with the reusable identity pattern as the end state. Dependency: a verification program wired to one country's rail inherits that rail's outages, politics, and coverage holes, so the durable architecture treats every national system as one weighted input to a decision plane rather than as the program itself.

The binding question DPI never answers by itself is the one this publication returns to weekly: the rail verifies the enrollment, not the present person. A national authentication API confirms that someone presented the right biometric or credential; whether that someone is a coerced relative, a replayed capture, or a synthetic enrollment depends on the liveness and capture-integrity layer in front of it, which remains the relying party's job in every architecture.

Reading a country's DPI maturity

Businesses expanding across markets can grade each country's identity rail with five questions, and the grading is worth doing formally, per market, on a refresh cycle, because the answers move. Coverage: what share of the adult population is enrolled, and who is systematically missing? Freshness: does the registry learn about deaths, name changes, and address moves, or does it fossilize? Access: is there a lawful, documented verification interface for private relying parties, and at what cost and latency? Privacy posture: tokenization, consent, and audit, or raw identifier lookups? And failure behavior: what happens to a legitimate person the rail cannot verify, is there a fallback, or does the rail's gap become the customer's exclusion? The grades translate directly into verification policy: strong rails earn weight in the decision plane, weak ones get corroboration requirements, and every market keeps a documents-plus-biometrics route for the people the rails miss.

The build-versus-adopt decision inside governments

For the governments doing the building, DPI's central procurement question is build, adapt, or buy, and the campaign infrastructure exists largely to change that answer. The traditional path, a monolithic national ID contract with a single vendor, produced the cautionary tales the open-standards movement defines itself against: lock-in priced in decades, systems that could not interoperate with the ministry next door, and upgrade cycles hostage to one supplier's roadmap. The DPI path assembles instead: open-source platforms like MOSIP adapted to national requirements, standard interfaces so registry, wallet, and authentication components can be swapped independently, and peer networks, the CLARCIEV webinars, the 50-in-5 workshops, substituting for the institutional knowledge countries previously had to buy. The trade-offs are honest ones: assembly requires in-house capability that procurement does not, pro-bono advisory partners mitigate but do not erase that, and open components still need hardening, operations, and accountable vendors around them. What the model has already changed is the default: a country modernizing its registry in 2026 starts from shared standards and working reference implementations, where a decade ago it started from a blank RFP, and the convergence that matters to relying parties, interfaces that look similar across borders, is the compounding result.