A business owner applies for a licence and is asked to submit information that another public office already holds. The application is then sent to a different portal for payment, while a missing record requires a visit to an office. Each step has been digitised. The journey remains fragmented.
That failure is often described as a lack of digitalisation. More often, it reflects a failure to build shared capability around work that institutions and citizens repeatedly need to do together.
In June 2026, the United Nations Development Programme launched the Africa Accelerator for Digital Public Infrastructure, or AA4DPI, alongside a policy report on digital public infrastructure. UNDP frames digital public infrastructure around three foundational components: digital identity, digital payments and data exchange. The Accelerator is a programme, not a new law or a prescription for one national platform. Its significance lies in what it acknowledges: countries need help to move from disconnected initiatives to integrated systems that can be governed, financed and sustained.
Digital public infrastructure creates public value when it connects a priority service journey under shared rules. Technology alone cannot turn fragmented systems into a coherent service.
This is a practical distinction. A portal may make an existing process easier to find. It cannot by itself resolve duplicate verification, inconsistent records, opaque handoffs or unclear accountability between institutions. Those require an architecture of services, standards, governance and operating capability that outlives the launch of a single application.
A portal cannot repair a fragmented service
Applications matter. They give people and businesses a front door to a public service. But when every agency creates a separate identity check, payment flow, database and support route, digitisation can reproduce the same institutional fragmentation at higher speed.
Digital public infrastructure is different because it provides common capabilities that several services can use. That does not mean a single database holding every citizen record, nor does it require uniformity across every institution. It means agreeing where identity can be verified, where payments can be made and reconciled, and how authorised information can move between systems without repeatedly burdening the person who needs the service.
The relevant leadership question is therefore not “Which platform should we buy?” It is “Which recurring point of friction appears across priority services, and which shared capability would remove it?” A ministry may identify business licensing, benefits delivery, health referrals or trade documentation as the place to begin. The choice should be driven by service consequence, not by what technology is most visible.
The three rails are valuable only when they work together. Digital identity, payments and data exchange are often discussed as separate projects. Their value emerges when they support one coherent journey.
Identity establishes who or what is entitled to act. A trustworthy identity layer can reduce repeated enrolment and manual checks. Its quality, however, depends on inclusion, correction mechanisms, accessible enrolment and redress. A system that works smoothly for urban smartphone users but excludes people with incomplete records or assisted-service needs has merely created a new barrier.
Payments move value and close the transaction. Public fees, benefits, subsidies and business payments become more reliable when the payment rail is secure, interoperable and accessible through the channels that people use. The operational test is not just transaction volume. It is whether users receive a usable confirmation, institutions can reconcile funds, and the process remains practical when connectivity or device access is limited.
Data exchange enables the decision. It allows an authorised institution to verify what it needs without asking a person to carry the same evidence between offices. This is not an argument for unrestricted access to data. Trusted exchange requires a defined purpose, lawful authority or consent, access controls, quality rules, logs and a route to correct errors.
A shared rail creates public value only when it reduces real service friction while preserving a clear right to understand, correct and challenge what the system does.
That is the difference between connecting databases and building trusted public infrastructure.
Interoperability begins before the API
Technical interfaces are necessary, but interoperability is not primarily an API problem. Two systems can exchange data and still fail the public if they disagree about what the data means, who can use it, how long it remains valid or who must resolve an error.
The difficult work starts before integration. Institutions need agreement on the service outcome, the evidence needed to reach it, the roles of each party and the safeguards that apply. They also need to decide how smaller organisations, local governments and non-digital channels will participate. If those questions are avoided, technical connectivity may simply create a faster route for institutional confusion.
This is especially relevant across African public systems, where digitisation is uneven and service delivery can involve national agencies, local authorities, regulated private providers and community-facing intermediaries. A design that assumes one stable registry, universal device access and a single capable operator may work in a demonstration but falter in use.
Countries that are still building shared rails can define open interfaces, ownership arrangements and safeguards before vendor-specific dependencies harden. They can develop infrastructure that fits mobile-first access, multilingual communication, assisted channels and local operating capacity from the outset.
Start where the service journey is breaking
The strongest starting point is a journey with visible public cost. In business registration and licensing, an entrepreneur may interact with a national registry, local authority, tax system, regulator, payment provider and bank. The combined experience can still be slow, repetitive and difficult to resolve when something goes wrong.
A useful discovery exercise asks what decision the service is trying to reach, which actors and evidence it requires, where people wait or repeat information, what must remain private or contestable, and which shared capability could support another priority service.
It prevents institutions from procuring an impressive component before identifying the decision, workflow and operating model that should govern it.
The test is reuse with accountability. If a capability cannot reduce friction in more than one appropriate service, it may still be useful software. It is not yet infrastructure. If it can be reused but no institution owns its performance, safeguards or improvement, it is not yet trustworthy infrastructure.
Trust lives in the operating model
Public confidence is not earned by speed alone. A fast service that cannot explain an error, provide an assisted alternative or resolve a mistaken record is likely to deepen mistrust.
A credible operating model begins with a clear public purpose. “Digital transformation” is too vague to govern. Reducing permit turnaround times, making benefit payments more reliable, or lowering the number of times a small business must submit the same evidence are concrete aims that can be measured.
It also needs accountable governance. Policy, service operation, cybersecurity, data protection, incident response and independent oversight cannot be left as afterthoughts once a platform is live. Nor can an institution remain dependent on an external supplier for every change, security update and operating decision. Local capability, documentation, open interfaces and workable handover arrangements are part of the infrastructure itself.
Inclusion must be designed into the service rather than added in response to complaints. That means considering shared devices, intermittent connectivity, language, disability, assisted channels and the needs of people whose records are incomplete. Digital-first should improve choice and reliability; it should not make digital-only the price of access.
Distributed trust has a specific, limited role
Distributed ledger technology is sometimes offered as a shortcut to trust. It is not. A ledger cannot establish that the source data is correct, repair poor service design or decide who is accountable when a citizen is harmed by an error.
It can be appropriate where several independent parties need a shared, tamper-evident record; where settlement must be coordinated; or where credentials and provenance must be verified across organisational boundaries. Trade documentation, shared registries and multi-party supply chains may present such conditions.
For most public services, a hybrid approach is stronger. Operational and personal data should remain in governed databases. Authorised data exchange should handle the information needed for a service decision. Verifiable credentials can reduce the need to disclose more than is necessary. Registries or ledgers should be introduced only where distributed governance, shared state, provenance or settlement makes them materially useful.
That architecture avoids a familiar distraction: treating blockchain as the centre of a public-service strategy when the real work is service design, data governance and institutional coordination.
Build the rail in stages, then earn the right to scale
AA4DPI describes support across diagnose-and-design, scale-and-connect, and implement-and-build stages. The sequence is useful because public infrastructure cannot be responsibly rushed from policy ambition to national rollout.
Discover. Choose a priority journey and establish the baseline: time, cost, error, exclusion and user effort. Map existing systems, institutions, data sources and channels before assuming that a new platform is required.
Design. Define the public-value case, ownership model, safeguards, interoperability approach and investment case. Decide what should remain in existing systems and which common capability is worth strengthening.
Build and enable. Implement the smallest shared capability that can be tested with real users and real operational conditions. Train the people who operate it, resolve incidents and support service users. Document the model before dependency on individual suppliers or staff becomes a risk.
Scale on evidence. Extend a rail when service outcomes improve and governance holds. Measure completion, turnaround time, error and exclusion rates, cost per transaction, complaints, availability and participation by underserved users. Growth without those measures is expansion, not proof of public value.
The strategic choice is institutional, not technical
Africa’s digital public infrastructure agenda should not become a race to launch more applications. The difficult, consequential work is often less visible: improving data quality, coordinating institutions, setting safeguards, developing delivery capability and measuring whether people actually experience a better service.
The UNDP Accelerator rightly brings this implementation challenge to the foreground. It recognises that countries need investment-ready programmes, institutional coordination and practical capacity alongside technology. That is where durable public systems are made.
For leaders, the choice is clear. They can digitise fragmented processes one agency at a time, or build the shared rails that allow priority services to work together without giving up accountability. The latter demands more discipline at the beginning. It creates far more value over time.
Countries and development partners assessing fragmented public services can begin by mapping recurring identity, payment and data-exchange problems across priority journeys. Xelius supports this work through service design, data architecture, interoperable platform design and implementation support.
