Two kinds of interoperability

The word interoperability has been carrying two different meanings, and separating them is what makes the problem tractable.

Technical interoperability lets systems exchange information. Agreed formats, common definitions, APIs, security mechanisms. Africa has built a great deal of this, and where it is absent nothing else works.

Institutional interoperability lets organizations complete one service together. It is a different achievement, and it is not produced by the first one. Five things constitute it, and none of them is technical.

• Authority. Which institution is entitled to make each determination in the chain, and on what legal basis. Two agencies can exchange a record and still disagree about which of them may decide eligibility on the strength of it.
• Service levels. What each institution owes the others, in time and in quality. A verification that returns in four seconds and one that returns in four days both satisfy a technical specification.
• Exception ownership. Who handles the case that does not fit. Exceptions are where services actually fail, and they are the part most often left unassigned because each institution reasonably regards them as another’s.
• Redress. How a citizen corrects a record or challenges an outcome when the error originated in an institution they never dealt with.
• Funding accountability. Who pays for the work one institution performs inside another’s service, and what happens when that work grows.

A national identity platform, a payment rail, and a data-exchange layer can all be in production while none of these five exists for a particular service. That is the condition in which the citizen becomes the integration layer.

DPI is usually drawn from the infrastructure upward. Identity, payments, and data exchange sit at the base; applications and services sit above them. That view is useful for understanding the technology. For service design the diagram should be turned upside down. Start with the citizen outcome, identify every institution needed to deliver it, and only then ask which digital rails can support those relationships.

Imagine a benefit that requires identity verification, an eligibility decision using information held elsewhere, and payment after approval. Each digital component may already work. Yet the service still needs answers to operational questions. Who owns the end-to-end outcome. Who resolves an identity mismatch. Where responsibility passes between institutions, and where the citizen goes if the payment fails after eligibility has already been confirmed.

When institutions are misaligned, the citizen becomes the integration layer.

A person may be asked to retrieve information from one agency, present it to another, and return when two records do not match. Digitizing each institution independently can reproduce the same journey across several screens.

Read the stack from the outcome down

The management view we use begins at the top, with the outcome the citizen experiences. It treats institutional interoperability as the layer that turns rails into a service.

Building the rails is essential; it is not the same as aligning the service.

Safeguards are part of alignment

The Universal DPI Safeguards Framework, first released in 2024, addresses safety, inclusion, and structural vulnerabilities across the DPI lifecycle. It does not treat safeguards as controls added after implementation. [3] In practice those safeguards change how institutions align. Privacy influences what one organization needs from another; inclusion changes channel design and assisted access; accountability determines ownership of exceptions; redress determines how a citizen corrects information or challenges an outcome. A technically interoperable infrastructure with unresolved redress is still misaligned from the citizen’s perspective.

What institutional interoperability costs

The reason this layer is thin is not that anyone has failed to see it. It is that building it requires institutions to accept something they are not structured to accept.

An agency that commits to a service level inside another institution’s service takes on an obligation to an outcome it does not control. It will not be credited for that outcome either. It will be measured against its own mandate, budgeted against its own mandate, and audited against its own mandate. The commitment it made to a neighboring institution appears in none of those.

If the joint service fails, the institution that owns the citizen-facing outcome absorbs the criticism. So the contributing institution’s incentive to hold its commitment is weaker than its incentive to serve its own reporting line.

Institutional interoperability therefore does not emerge from goodwill or from technical integration. It requires somebody with authority over more than one institution to make the joint outcome matter to each of them. That is usually a center-of-government function, sometimes a legal instrument, and occasionally a funder. It is rarely the program.

Reuse the institutional pattern, not only the rail

UNDP launched the Africa Accelerator for Digital Public Infrastructure in June 2026. It combines digital building blocks such as identity, payments, and data exchange with institutional strengthening, policy support, safeguards, and investment facilitation. [4] That combination matters because the real economic value of infrastructure comes from reuse. The first service assembled across several institutions may require substantial work to clarify ownership, service levels, exceptions, and redress. A second service using the same institutions should not have to recreate every arrangement from the beginning. Technology can be reused, and so can institutional patterns.

For governments, development partners, and DFIs, the investment question therefore changes. A national identity platform, payment rail, or data-exchange layer is a foundational asset. The program should also identify the priority services that will use it, and fund the institutional work required to change those journeys. Start with one consequential service, map the institutions required to deliver it, determine where the current journey breaks across organizational boundaries, and identify which existing digital rails can remove those breaks. Then design the alignment layer.

Africa has an opportunity to move beyond treating DPI as another generation of large technology platforms. The more powerful proposition is reusable institutional capability supported by reusable digital rails.

Technical interoperability is what lets the systems talk. Institutional interoperability is what lets the citizen finish.

‍