A design idea, not a product
When people talk about India's digital stack, they often describe it as a set of apps. It is closer to a set of agreements. Identity through Aadhaar, payments through UPI, and consent based data sharing through the Account Aggregator framework are protocols and rules that many private and public parties build on. The government supplies the rails. Banks, fintechs and developers supply the products.
That distinction is the most useful thing to take from the Indian experience, and it travels better than any single technology. This piece looks at what the design teaches, where it is specific to India, and what a country such as Nigeria or Ghana might reasonably borrow. It is a discussion of design, not a verdict on any government or its choices.
The pattern: thin public layer, thick private layer
The stack works because the public layer is deliberately small. UPI is an interoperable payment system run under the National Payments Corporation of India. It defines how money moves between participating banks and apps and leaves the customer experience to others. A user can pay from one provider's app to an account at a different bank, and neither side needs a bilateral deal.
The same shape appears elsewhere in the stack. A shared identity layer lets providers verify a person without each building their own onboarding. A consent layer lets a person choose to share financial data with a lender for a stated purpose. In each case the public component answers one narrow question reliably and then gets out of the way.
Compare this with a platform model, where one organisation owns the whole experience. Platforms can move fast, but they concentrate power and become a single point of commercial and technical failure. A protocol model moves slower to set up and then lets competition happen on top.
Three lessons that hold up
Interoperability is the product. Payments are worth little if they only work inside one network. The design goal was that any participant could connect to any other through a common standard, with open specifications and published rules. When you evaluate a national initiative, ask first who can plug in, on what terms, and who decides.
Make the right thing cheap. Low or zero cost for basic person to person transfers was a policy decision as much as a technical one. It pushed adoption by making the new rail the easy default. Whether a rail is free, subsidised or priced is a question every country answers differently, but the principle stands: if the rail costs more than the alternative, people will not move.
Consent must be real. The data sharing layer is built on the idea that a person, not an institution, decides who sees their records. That is a design constraint, with consent artefacts, purpose limits and revocation. It echoes the logic of modern data protection laws such as GDPR and the Nigeria Data Protection Act 2023, which also centre lawful purpose and individual control.
What does not transfer cleanly
Honest analysis has to include the limits.
India's context is specific. A very large single market, a national identity programme with broad enrolment, a central bank with a clear mandate and a long political commitment to the approach all shaped the outcome. Smaller or more fragmented markets will not replicate the scale effects, and some of the cost advantages depend on volume.
The identity layer has also drawn serious debate there, about privacy, exclusion when authentication fails, and whether participation was effectively required. Those arguments are part of the lesson. A shared identity system is powerful precisely because it is hard to opt out of, and that power needs oversight, legal limits and a way to challenge errors. Nigeria and Ghana, each with their own national identity programmes and instant payment systems, face versions of the same trade offs.
And infrastructure does not remove the need for institutions. Dispute handling, fraud response, grievance processes and clear liability rules are what let ordinary people trust the rails. The technology is the visible part. The rulebook is the load bearing part.
What builders should take from it
If you build products on top of public infrastructure, a few habits help.
- Design for the protocol, not for one provider's interpretation of it. Keep your integration layer thin so a change in the rules does not become a rewrite.
- Treat the shared rail as unreliable at the edges. Timeouts, duplicate callbacks and delayed settlement are normal, so build reconciliation in from the start.
- Store consent and purpose with the data. If you cannot say why you hold a record and who agreed to it, you cannot defend it.
- Expect the rules to change. Public infrastructure evolves under policy pressure, and the teams that survive are the ones whose architecture assumed it.
Questions worth asking of any national stack
When a government or regulator announces a digital public infrastructure plan, a short checklist keeps the conversation grounded:
- Is the specification open, so independent parties can implement it?
- Who governs changes, and how are participants consulted?
- What happens when a person is wrongly rejected or wrongly charged?
- Can a private provider build a competitive product on top without special access?
The strongest part of the Indian approach is not any one system. It is the habit of building small, shared, rule based layers and leaving the rest to the market. That habit is available to every country, whatever its size.