Every African wallet works. Few of them talk to each other

Mobile money is the most successful payments story of the century, and it was built as a set of islands.

Each operator built its own wallet, its own agent network, its own merchant codes and its own rules. That was the right call. It is how M-Pesa, MTN MoMo, Orange Money and Airtel Money each reached tens of millions of people. GSMA estimates roughly $1.4 trillion moved through mobile money in Africa in 2025 ¹. No committee designed that. Competing operators did.

But the islands are now the constraint. Value that can move freely inside one operator stalls at the border of the next one, and stalls harder at a national border.

#The cost of islands

Consider three ordinary payments.

A shopkeeper in Kigali on MTN MoMo wants to pay a supplier on Airtel Money. Inside Rwanda that may work through domestic arrangements. Now make the supplier sit in Kampala. Now make him sit in Dar es Salaam.

A Senegalese family on Wave wants to send money to a cousin on Orange Money in Ivory Coast. Same currency, the XOF, same monetary union. Different networks.

A software company in Lisbon wants to collect from customers on M-Pesa in Mozambique and on MTN MoMo in Cameroon. Two currencies, two operators, two integrations, two settlement files.

Each of these is solvable. Each is usually solved by a bilateral deal, a correspondent bank, or an aggregator that integrates both sides one at a time. The World Bank's remittance price data has shown for years that sending money to Sub-Saharan Africa is costlier than to any other region ³. Fragmentation is a big part of why. Every hop adds a fee, a delay and a reconciliation file.

#Bilateral links do not scale

With two networks you need one link. With ten you need 45. With fifty you need 1,225. That is the arithmetic of point-to-point integration: n times n minus one, over two.

Nobody actually builds 1,225 links. What happens instead is that the big operators link with each other, the small ones link with an aggregator, and the long tail stays isolated. The customer of a small network pays the cost of that, every time.

The BIS Committee on Payments and Market Infrastructures named this directly in its G20 cross-border roadmap: fragmented messaging standards, limited interlinking of payment systems and the cost of compliance are among the frictions that make cross-border payments slow and expensive ². Its building blocks include interlinking systems and harmonising message formats. Those are not African problems. They are network problems that Africa feels harder than most.

#What interoperability actually requires

"Interoperability" gets used loosely, often to mean "we built an API". An API is a door. Interoperability is an agreement about what happens on both sides of it. At minimum, five things:

#1. A shared address

A sender has to be able to name the recipient in a way every network understands, then find out who serves that address, in which country, in which currency. Without a directory, every sender needs to know every network's internal format.

#2. A shared message

The payment has to mean the same thing at both ends: who is paying, who receives, how much, why. If each network describes a payment in its own vocabulary, every link carries a translator, and translators drift.

#3. A price before commitment

The sender should know, before money moves, what the recipient will receive, at what rate and for what fee. A payment that is priced after the fact is a dispute waiting to happen.

#4. A state everyone agrees on

"Pending" in one system and "processing" in another is how money goes missing between two databases. A payment needs a single state machine, one-directional, with defined failure states and timeouts.

#5. Settlement and reconciliation that do not depend on trust

At the end of the day someone owes someone. That obligation has to be recorded at the moment the payment completes, netted on a schedule, and reconciled mechanically. Not reconstructed later from two spreadsheets.

An API is a door. Interoperability is an agreement about what happens on both sides of it.

#Domestic schemes proved the idea

Several African markets already proved that operators can interoperate domestically without killing competition. Tanzania's operators connected their wallets to each other years ago, and other markets have built national switches. Open-source work such as Mojaloop exists precisely to give central banks and operators a common foundation for inclusive, interoperable instant payment systems ⁴.

Those efforts answer the domestic question well. The open question is the one that crosses borders and currencies, and the one that includes participants who are not operators at all: banks, fintechs, PSPs, remittance companies and global processors that want to reach African wallets.

#How Ultraner Network approaches it

Ultraner Network is our attempt at that cross-network layer. It is a separate product from Ultraner's merchant payments business, and its shape is Network A -> Ultraner Network -> Network B, not merchant -> gateway -> rail. The design is public on the network overview and the full contract is on the protocol page.

In short, the five requirements above map to five pieces of the protocol:

• Directory. A participant resolves a payment address and gets back identity, country, currency and the rails that can reach it.
• Message types. A small, fixed set: resolve, quote, authorize, execute, status, reverse, refund, plus signed callbacks. Each one only triggers transitions in a single transaction state machine.
• Quote before payment. Authorization is illegal without a live, unconsumed quote that locks the rate and the fee.
• One state machine. Created, validating, authenticating, routing, authorized, processing, destination accepted, settled, reconciled, with explicit failure states and maximum dwell times.
• Settlement as a primitive. Every payment that reaches the destination creates exactly one settlement obligation in the same database transaction, and obligations net into windows that must reconcile before they can be marked settled.

We want to be precise about the stage. The protocol, the directory, routing, the state machine and settlement modelling are built and running in sandbox. There are no live participants on the network today, and settlement windows model obligations rather than moving money. Real connectors come after the core has been proven against simulated participants, not before.

#Why this matters to an operator

If you run a mobile money service, interoperability can feel like giving away the moat. Your agent network and your merchant base are hard-won.

The counter-argument is the one card networks made decades ago: issuers kept competing for customers while sharing a common rail between them. The rail did not erase the competition. It expanded the number of places each customer's money could go, which made every issuer's product more useful.

For an operator, a shared protocol means three practical things. Your customers can pay and be paid by people on networks you have no deal with. You integrate once instead of negotiating link after link. And the settlement position across all of it arrives as one reconciled ledger rather than a pile of files.

#What to do next

If you are evaluating interoperability for your network, three questions sort serious options from slideware:

1. Is there a written message contract, with an error taxonomy, that you could implement without reading the vendor's code?
2. Where is the settlement obligation recorded, and when? If the answer is "in a nightly report", keep asking.
3. How does a participant prove it is ready before touching real money?

Our answers are on the protocol page, and the onboarding path is on connect. Read them as a specification, and hold us to it.