# The case for one protocol between Africa's payment networks

> Bilateral links, national switches and aggregators each solve part of Africa's payment fragmentation. The argument for a shared participant protocol.

Published 2026-10-20 by the Ultraner team. Topic: connect. Tags: interoperability, protocol, network, policy.
Canonical: https://ultraner.com/blog/case-for-an-interoperable-african-payment-network

Africa does not have a payments problem. It has a connections problem.

The individual systems work, often better than their equivalents elsewhere. Mobile money moved around $1.4 trillion across the continent in 2025, by GSMA's estimate [1]. What does not work well is the space between systems: between operators, between countries, between a wallet in Kampala and a company in Seoul.

Three approaches have tried to fill that space. Each solves part of it. This is the case for adding a fourth, and for being clear about what it must and must not be.

## What exists, and what each one solves

### Bilateral links

Two operators or two banks sign an agreement and build a direct connection. Bilateral links are fast to start and fully under the parties' control.

They do not scale. Connecting n participants pairwise takes n(n-1)/2 links. Each link has its own message format, its own reconciliation file and its own dispute process. The biggest players link to each other; the long tail is left out.

### National switches

A central switch connects every participant in one country. Several African markets have built them, and open-source platforms like Mojaloop exist to make inclusive, interoperable national systems easier to build [5].

National switches solve the domestic case well. By design they stop at the border, and they do not usually reach participants outside the domestic regulated perimeter, such as a global PSP wanting to collect from local wallets.

### Aggregators

An aggregator integrates with many rails and resells access through one API. This is how most global companies reach African customers today, and it works. Ultraner's own merchant product is one.

But an aggregator is a hub, not a protocol. Its connections are private, its rules are its code, and participants on one side cannot use the aggregator to reach participants on the other unless it builds that product for them.

### Regional settlement

PAPSS was established to let cross-border payments between African countries settle in local currencies, reducing reliance on hard-currency intermediaries [4]. That addresses the final step, settlement between central banks and commercial banks. It needs layers above it that decide what is owed.

## The gap that remains

Put the four together and a gap is visible. There is no open, written contract that lets any qualified participant (an operator, a bank, a fintech, a remittance company, a global PSP) connect once and transact with every other participant across borders, with shared rules for addressing, pricing, state, errors, settlement obligations and readiness.

The cost of that gap shows up where it always does: in price and in time. The World Bank's remittance price data has shown sending money to Sub-Saharan Africa to be more expensive than to any other region [3]. The BIS's cross-border roadmap attributes much of that kind of friction to fragmented standards, limited interlinking and opaque processes [2].

## What a shared protocol has to be

A protocol earns adoption only if it is narrow, explicit and neutral. Concretely:

**Narrow.** It describes financial intent: who is paying, who receives, how much, why. It does not encode any one rail's internal quirks. A small set of messages (resolve, quote, authorize, execute, status, reverse, refund, callback) is enough.

**Explicit.** Every state, every error and every timeout is written down. Payments move through one state machine, one direction only. Every non-terminal state has a maximum dwell time. Errors come from a fixed taxonomy, so `QUOTE_EXPIRED` means the same thing to every participant.

**Priced up front.** No payment is authorized without a live quote that locks the rate and fee. Nobody is repriced after the fact.

**Ledger-first.** Every completed payment creates its settlement obligation in the same transaction as the state change. Windows net those obligations and must reconcile before they are marked settled. Corrections are new entries, never edits.

**Earned access.** Sandbox access is immediate; production access is earned through a certification suite (success, insufficient funds, timeout, reversal, refund, malformed input, idempotent replay, bad signatures) and a human review.

> A protocol earns adoption by being narrow, explicit and neutral. Everything else is marketing.

## What it must not be

Just as important:

- **Not a replacement for national switches or regional settlement.** It sits alongside them, and should route through them where they are the best path.
- **Not a rail.** It holds no end-user accounts. Customers stay with their operators and banks.
- **Not a single partner's integration with a nicer name.** If the design only works for one operator's API, it is a bilateral link.

## Where Ultraner Network stands

Ultraner Network is our implementation of that protocol, and it is separate from Ultraner's merchant payments product. The specification is public on the [protocol page](/network/protocol); the architecture is on the [network overview](/network).

The honest status: participants, directory, quotes, routing, the transaction state machine, settlement windows with netting and reconciliation, certification and a participant portal are built and running in sandbox against simulated participants. No participants are live. Settlement models obligations; it does not yet move money between banks, which requires licensing and participant agreements. Compliance and risk scoring are named in the architecture and not yet implemented as engines. Real connectors to operators and banks come next, as adapters behind a provider-neutral interface.

That order is deliberate. A protocol designed around its first big partner ends up as that partner's integration. One proven against neutral simulators first has a better chance of being fair to the second, third and fiftieth.

## What would make it work

A protocol becomes a network only when participants use it. The case for joining rests on three things a participant can verify independently:

1. **The contract is readable.** You can implement it from the specification without reading the operator's code.
2. **The rules are mechanical.** Settlement, timeouts and failover are enforced by the system, not by goodwill.
3. **Access is symmetric.** Every certified participant can reach every other one on the same terms.

If you run an operator, bank, PSP or remittance business and those three tests matter to you, read the [protocol](/network/protocol) critically and tell us where it falls short. The path to sandbox access is on [connect](/network/connect).

## Sources

[1] State of the Industry Report on Mobile Money, GSMA. https://www.gsma.com/sotir/
[2] Enhancing cross-border payments: building blocks of a global roadmap, BIS Committee on Payments and Market Infrastructures. https://www.bis.org/cpmi/publ/d193.htm
[3] Remittance Prices Worldwide, World Bank. https://remittanceprices.worldbank.org/
[4] Pan-African Payment and Settlement System, PAPSS. https://papss.com/
[5] Mojaloop open source payments software, Mojaloop Foundation. https://mojaloop.io/