The Module Is Not the Rail: Rethinking DPI in Africa

Digital identity, payments and data exchange are useful shared capabilities. Regional DPI will only work when those capabilities are composed under lawful public functions, with accountable institutions, authoritative records, validation, funding and remedy.

The module is not the rail. The module is the Digital Public Function.

Digital Public Infrastructure is usually explained through its most visible rails: digital identity, digital payments and data exchange. That explanation is useful, but it is not enough.

Those rails are shared capabilities. They can support many different public functions, but they do not themselves define the public function. A digital identity capability may support health access, social protection, tax services, mobility, business representation or professional qualification recognition. A data exchange layer may support customs, disease surveillance, licensing, education, trade logistics or public benefits. A payment rail may support fees, refunds, transfers, benefits, settlement or compensation.

The same capability can serve very different public functions. Each function has its own authority, institution, record, procedure, execution, public interface and remedy.

That is why DPI modularity should not begin with the rail. It should begin with the Digital Public Function.

A Digital Public Function is the lawful public task performed in digital form. It is the level at which public authority is defined, the competent institution is identified, the canonical record is established, the procedure is governed, the digital act produces effect, the public interface is accountable, and remedy is available.

Digital Public Infrastructure then becomes the shared capability layer used to enable domain-specific implementations. It can provide identity, authentication, payments, data exchange, wallets, signatures, seals, trust services, registries, hosting, APIs and other reusable capabilities. But those capabilities must be composed around the public function. They should not define it.

This distinction matters for Africa’s DPI debate.

The ECDPM guide on Digital Public Infrastructure in Africa is a useful contribution because it places DPI in the East African Community context. It treats DPI as a regional integration question, not only as national digital transformation. It also goes beyond the narrow three-pillar model by recognising that identity, payments and data exchange require connectivity, digital literacy, legal and regulatory frameworks, governance and institutions, cybersecurity and data protection, and open standards and interoperability. The guide describes the EAC’s broader DPI+ approach, which treats digital infrastructure, connectivity, digital skills and digital literacy as preconditions for DPI.

That broader view is welcome.

But the framing still starts too close to the stack. The harder question is not which rails should be built first. The harder question is which public functions should become digital, which should become regional, which institutions are competent, which records are authoritative, who funds the lifecycle, who carries the risk, and what remedy exists when reliance fails.

What the ECDPM framing gets right

The ECDPM framing is strongest where it moves DPI out of a narrow technology conversation and into a regional integration agenda. That matters.

In the East African Community, DPI is not only about improving national public services. It is also about cross-border payments, trade logistics, professional mobility, disease surveillance, portable health records and trusted regional services. These are not abstract digital transformation goals. They are practical tests of whether public evidence created in one Partner State can be trusted and acted upon in another.

The guide also recognises that DPI cannot be reduced to identity, payments and data exchange. Connectivity gaps, uneven legal frameworks, diverging institutional capacity, cybersecurity risks, data protection weaknesses, lack of data centres, skills shortages and sustainability concerns all shape whether DPI can work in practice.

That is a serious improvement over the usual stack narrative.

But it still leaves one problem unresolved. It treats the pillars as the main modules, while the real module should be the public function.

Three pillars are not sufficient modules

Digital identity, payments and data exchange are important. But they are not sufficient as the basic architecture of DPI.

They are shared capabilities. They become meaningful only when composed under a specific public function.

A digital identity capability may be needed for access to healthcare, but the health function also needs lawful access rules, clinical records, professional responsibility, emergency procedures, audit and correction. A payment capability may be needed for a public fee, but the fee function also needs authority to charge, settlement rules, refund procedures, accounting, dispute handling and remedy. A data exchange capability may be needed for professional qualification recognition, but recognition also requires an issuing authority, qualification register, validation procedure, legal effect and appeal route.

The three pillars can help explain DPI. They cannot govern it.

Common framing	Better framing
Digital identity as a DPI module	A public function may require identity, authentication, assurance and correction
Digital payments as a DPI module	A public function may require payment, settlement, reversal, supervision and remedy
Data exchange as a DPI module	A public function may require lawful access, authentic sources, provenance, audit and correction
Stack interoperability as the objective	Cross-border reliance as the objective
Code as the practical rule-set	Code as execution of lawfully defined procedure
Safeguards as principles	Safeguards as operable controls and remedies

This is the modularity issue. The module is not the rail. The module is the Digital Public Function.

Code cannot be the law of DPI

There is a quiet danger in technology-first DPI. The stack is defined, modules are selected, standards are named, and then governance is fitted around what the system can do.

In practice, this can make code the law of the system.

What the platform permits becomes what the institution can do. What the workflow excludes becomes what the person cannot access. What the data model omits becomes what the service cannot recognise. What the API cannot transmit becomes what the relying party cannot see.

That is hidden governance.

Code may execute a public function, but it cannot lawfully define one. A workflow may automate a procedure, but it cannot decide which authority is competent. A data exchange layer may move information, but it cannot decide whether the data may be disclosed, which source is authoritative, who may rely on it, or what remedy applies when it is wrong. A payment module may process value, but it cannot settle questions of liability, reversal, fraud, exclusion or public accountability.

The correct order is not to build the stack and then govern it.

The correct order is to define the public function, establish the authority chain, identify the records, design the procedure, specify the effect, create the interface, define remedy and then compose the technical modules needed to execute it.

Technology will be needed. It should come after the public-function architecture, not before it.

National DPI builds the trusted source

National DPI and regional DPI solve different problems.

National DPI builds the trusted source. It establishes the domestic public functions, registers, institutions, service procedures, execution mechanisms, public interfaces and remedies that make digital services work inside a state.

The ECDPM guide shows that EAC Partner States are at very different stages of readiness. It points to connectivity gaps, limited data-centre capacity, uncoordinated regulatory and legal frameworks, shortage of locally skilled professionals and diverging institutional capacity. It also notes that systems may follow global interoperability standards but still fail to deliver seamless cross-border exchange because national configurations, governance arrangements and legal frameworks differ.

That point is essential. Regional interoperability cannot repair weak national authority. It can only expose it.

A national digital identity system needs lawful authority, a competent institution, authoritative records, assurance rules, correction procedures and safeguards against misuse. A national business register needs current legal-person records, representation data, correction mechanisms and reliable access for authorised relying parties. A national health data system needs lawful access, clinical provenance, identity binding, professional accountability and correction.

Without those national foundations, regional DPI has nothing reliable to connect.

Regional DPI builds the trust relationship

Regional DPI has a different task. It decides which national public functions can be recognised, validated and relied upon across borders.

A national population register may establish identity domestically. A regional mobility service must decide whether another Partner State can rely on that identity evidence, for which purpose, at what assurance level and with what correction mechanism.

A national business register may establish legal-person facts domestically. A regional trade service must decide whether another Partner State can rely on business status, representation authority, licences, tax status or mandates.

A national health system may maintain health records domestically. A regional health exchange must decide when data may be shared, who may access it, what lawful basis applies, how emergency use is governed, how errors are corrected and how misuse is remedied.

This is the central distinction:

National DPI builds the trusted source. Regional DPI builds the trust relationship.

Without the national layer, regional interoperability has no authoritative foundation. Without the regional layer, national DPI remains fragmented and cannot support a single digital market.

EAC use cases are public-function portability tests

The ECDPM guide identifies practical regional use cases: the East African Payment System, cross-border mobile money, the Trade Logistics Information Pipeline, mutual recognition of professional qualifications, the East African Integrated Disease Surveillance Network and portable individual health records.

These are exactly the right kinds of use cases to examine. But they should not be treated as stack use cases first. They are public-function portability tests.

Mutual recognition of professional qualifications is not a digital identity module plus a data exchange module. It requires a competent issuing body, an authoritative qualification record, a recognition procedure, a validation mechanism, legal effect and remedy if the record is wrong, expired, suspended or fraudulently presented.

Portable health records are not data exchange plus consent. They require lawful access, clinical provenance, identity binding, purpose limitation, emergency-use rules, correction procedures and sanctions for misuse.

Trade logistics is not a data exchange rail. It is a chain of public and private evidence: business identity, customs records, licences, inspection certificates, transport records, signatures, seals, payments and validation. Each item must have a source, status, scope and consequence.

Cross-border payments are not only payment interoperability. They require settlement rules, supervisory cooperation, liability allocation, fraud handling, reversal mechanisms and dispute resolution.

The EAC does not only need systems that connect. It needs public functions that can travel.

The overlooked business identity layer

The ECDPM framing gives proper attention to payments, mobile money, private-sector innovation and trade logistics. It also recognises regional integration towards a single digital market as an opportunity.

But the legal-person and economic-actor layer is not developed strongly enough.

That is a serious gap.

Regional economic integration is not only about individuals accessing services or consumers making payments. It is also about businesses proving who they are, who may represent them, which licences they hold, whether they are tax-registered, whether they may trade, whether they may sign, whether they may seal, and whether another Partner State can rely on that evidence.

A digital single market cannot be built only on citizen identity, payment rails and data exchange. It needs trusted organisational evidence.

Business need	What DPI must support
Legal-person identity	Authoritative business registers and current legal status
Representation	Evidence that a natural person may act for the legal person
Mandates	Current, limited and revocable authority to perform defined acts
Licences and permits	Sector-specific authority to operate, trade or provide a regulated service
Signatures and seals	Reliable execution of documents, submissions, contracts and official communications
Trade evidence	Certificates, inspection results, customs documents and logistics records
Relying party trust	Rules on what banks, customs authorities, regulators, procurement bodies and private parties may request and accept

This is not an optional add-on. It is the core of cross-border economic integration.

Without this layer, DPI risks remaining citizen-centric and payment-centric while the harder single-market questions remain unresolved.

Interoperability is not reliance

The ECDPM roadmap calls for interoperability by design, open-source approaches, regional standards, sandboxes, a regional DPI Blueprint and a working group for digital identity, payments and data exchange.

These are sensible recommendations. They are not enough.

Technical interoperability allows systems to connect. It does not automatically create legal reliance.

A system may exchange data and still fail to answer whether the data is authoritative. A credential may be presented and still fail to show whether the issuer was competent. A payment may be initiated and still fail to resolve liability. A certificate may be transmitted and still fail to preserve legal meaning in another jurisdiction.

Regional DPI needs several forms of interoperability at once.

Interoperability type	What must be aligned
Legal interoperability	Legal effect of identity evidence, payments, signatures, seals, records, certificates and decisions
Institutional interoperability	Mandates, supervisory roles, escalation channels and correction responsibilities
Evidential interoperability	Authentic sources, provenance, validity, status, assurance and auditability
Semantic interoperability	Shared meaning of data fields, statuses, identifiers, decisions and evidence types
Technical interoperability	Protocols, formats, APIs, trust lists, security controls and service interfaces
Remedial interoperability	Correction, revocation, suspension, appeal, reversal, dispute resolution and redress

The last layer is often missing. Yet remedy is where trust becomes real.

If a cross-border service works only when everything is correct, it is not yet trustworthy. Records will be wrong. Credentials will expire. Payments will fail. People will be excluded. Businesses will be misidentified. Mandates will be abused. Data will be stale. Systems will be compromised.

A regional trust framework must be designed for failure, not only for successful transactions.

Safeguards must become operable controls

The ECDPM roadmap rightly calls for privacy, data protection, cybersecurity, meaningful civil-society involvement and human rights-centred DPI design. It also warns against exclusion risks and rights violations.

That is necessary. But safeguards alone do not create cross-border reliance.

Safeguards help identify risks. They do not by themselves define competent issuers, register relying parties, create validation mechanisms, specify legal effect, allocate liability, supervise trust services or make one jurisdiction’s records reliable in another jurisdiction.

A region that wants interoperability must move from principles to institutions. It must convert public-interest safeguards into enforceable obligations, formats, supervision, validation and remedies.

Safeguard principle	Operable control
Inclusion	Assisted access, alternative channels, accessibility standards and exclusion review
Privacy	Purpose limitation, minimisation, access logs, auditability and sanctions for misuse
Cybersecurity	Incident response, continuity planning, vulnerability handling and supervisory reporting
Data protection	Correction, restriction, lawful access control and independent oversight
Human rights	Limits on function creep, proportionality, complaint routes and effective remedy
Civil-society involvement	Structured consultation, transparency, monitoring and accountability mechanisms

A helpdesk is not remedy. A complaint inbox is not remedy. Monitoring is not remedy.

Remedy means that an individual or business can correct an authoritative record, challenge a decision, revoke a credential, reverse a failed transaction, suspend misuse, obtain redress and see the correction propagate to the systems that relied on the wrong data.

Without remedy, reliance becomes risky. Without reliance, regional DPI remains a technical aspiration.

What should come before the East Africa Stack

The recommendation is not to delay technology. The recommendation is to sequence it properly.

Before an East Africa Stack is delivered, the EAC and its Partner States should define the public problems and public functions the stack is meant to serve.

Pre-stack question	Why it matters
What problem is being resolved?	Prevents DPI from becoming a solution in search of a public purpose
For whom is the problem being resolved?	Distinguishes citizens, residents, refugees, migrants, businesses, public authorities, health providers, regulators and relying parties
Why is public authority involved?	Clarifies whether the issue requires a public function, market coordination, regulation or shared infrastructure
Which institution is competent?	Establishes accountability for operation, supervision, correction and failure
Which record is authoritative?	Prevents services from relying on copied, stale or uncorrectable data
What legal or operational effect follows?	Determines whether a credential, payment, document, decision or transaction can be relied upon
Who may rely on it?	Defines relying party rights, duties, limits and liability
Who funds the lifecycle?	Avoids pilot dependency and unfunded public obligations
Who benefits and who carries risk?	Makes exclusion, surveillance, fraud and dependency risks visible
What remedy exists?	Ensures that people and businesses can correct errors, challenge outcomes and recover from failures
Which technical modules are actually needed?	Keeps identity, payments, data exchange, wallets, signatures and seals subordinate to the function they serve

This is the guiding principle:

Technology is composed around the Digital Public Function. The Digital Public Function is not reverse-engineered from technology.

Equivalence by design, not copy-paste reform

The ECDPM guide situates African DPI within a global context that includes India, Brazil, the EU, GovStack, the Digital Public Goods Alliance and international development financing. It also notes that Africa has an opportunity to shape the DPI discourse and that the African Union has its own Digital ID Interoperability Framework.

That global framing is useful. It also needs caution.

Africa should not frame DPI as copying India, Europe, Brazil or any donor-backed stack. The better question is whether African regional systems can become equivalence-ready on their own terms.

Equivalence-ready does not mean identical. It means that a framework can prove its trust chain well enough to be assessed, mapped, connected or recognised. It can show who issued the data, which authentic source stands behind it, how the relying party is governed, how validation works, what legal effect follows, how errors are corrected and who supervises the ecosystem.

For the EAC, equivalence by design means that national systems should be built with regional reliance in mind from the beginning.

A national digital identity programme should already consider future cross-border assurance. A business register modernisation programme should consider regional legal-person identity and mandate verification. A payment system should consider regional settlement, dispute handling and reversals. A health-record system should consider lawful access, emergency use and correction across borders. A trade-logistics system should consider whether certificates, licences and inspection results can be validated by another Partner State.

This is not technology transplantation. It is strategic interoperability.

The point is not to import another region’s institutional form. The point is to solve the same functional problem: how can digital public authority, trusted records and legally meaningful evidence travel safely beyond their original jurisdiction?

From a regional stack to a regional trust framework

The ECDPM guide is right to treat DPI in the East African Community as a regional integration agenda. It is right to recognise that identity, payments and data exchange require wider foundations. It is right to point to connectivity, legal frameworks, governance, cybersecurity, standards, skills, national coordination, regional leadership, sustainability and civil-society involvement.

The next step is to change the organising unit.

The EAC should not begin with the stack. It should begin with the Digital Public Function.

That means asking which public functions should become digitally operable at national level, which should become portable at regional level, which institutions are accountable, which records are authoritative, what procedures govern the decision, what digital act creates effect, how people and businesses access the service, and what remedy exists when reliance fails.

National DPI builds the trusted source.

Regional DPI builds the trust relationship.

Without the national layer, regional interoperability has no authoritative foundation.

Without the regional layer, national DPI remains fragmented and cannot support a single digital market.

That is why the EAC does not only need a regional stack. It needs a regional trust framework built on nationally accountable Digital Public Functions.

The task is not merely to connect systems.

It is to make reliance lawful, accountable and correctable. That is where DPI becomes more than infrastructure. It becomes regional public trust architecture.