← Back to blogAropet Joel

One Data Centre Took Uganda's Mobile Money Down. Interoperability Will Make the Next Outage Worse.

On July 5, 2026, MTN Uganda’s Mutundwe data centre in Kampala hit an abnormal power event. A protection circuit tripped, one of six on-site generators failed, and the UPS shut down part of the facility to protect itself. Within an hour, voice, mobile data, and MTN Mobile Money were down for millions across the country. Service was restored the same day, and MTN later compensated more than a million customers whose bundles expired mid-outage.

To put the stakes in one number: Uganda’s mobile money channels moved UGX 326.3 trillion in the year to June 2025, across 8.4 billion transactions, on 35.6 million active accounts. When the rail stops, a large fraction of the economy stops with it.

The story most outlets ran was some version of “power failure at a data centre, service restored, apologies issued.” That is technically accurate. It also misses the point.

MTN Uganda operates six data centres. Two are parent sites, Mutundwe and Mbuya. Four are smaller sites in Mbarara, Masindi, Lira, and Tororo. On paper, this is a redundant, distributed setup. In practice, a single failure at one parent site cascaded to the whole network. The problem was not that redundancy failed. The problem was that the architecture depends on a small number of centralised parent sites, and one of those went down. “Single point of failure” still applies, even for a system that markets 99% uptime.

This is the second time in six months mobile money stopped working for reasons no customer could control. In January, during the general election, the Uganda Communications Commission ordered a 100-hour internet blackout. MTN Mobile Money and Airtel Money went dark alongside the internet. In July, MTN went dark alongside its own data centre. Different causes. Identical outcome for anyone trying to buy lunch, pay a boda, or send school fees.

The fix currently being rolled out was designed for a different problem.

The Bank of Uganda is deploying what it calls the Digital Drive Project. The headline features are a single merchant code that works across MTN and Airtel, dedicated merchant wallets separate from personal accounts, and a national QR code standard. Reporting has been enthusiastic. Traders will not juggle multiple codes. Customers on any network can pay any merchant. Costs should come down. All of that is real.

What has not been discussed is that shared rails also share failure modes. If a national switch routes payments across MTN, Airtel, banks, and third-party wallets through one interoperable spec, then a fault in that switch does not fail one operator. It fails all of them at once. The Digital Drive Project, as designed today, moves the country from “MTN outage takes MTN customers down” to “one incident takes every merchant in Uganda down.” That is a straightforward consequence of centralising routing without also decentralising fallback.

The odd thing is that Uganda has already solved a version of this problem in a completely different sector.

The health sector’s answer

Uganda’s Ministry of Health runs a national electronic medical records system called UgandaEMR+, a customisation of the open-source OpenMRS platform. It sits alongside eAFYA, designed from the start to run offline, and ClinicMaster, first used in HIV clinics and later extended to other facility types. According to Ministry data, EMR coverage now sits around 92% of targeted hospitals. Fourteen hospitals have been fitted with solar backups specifically to keep records flowing through power cuts. When there is no internet, hospitals keep charting patients locally. When connectivity returns, records reconcile back to DHIS2, the national data warehouse. The reporting lag is real. The warehouse falls behind until connectivity returns. But clinical work does not stop.

Through both the January blackout and the July MTN outage, this architecture kept doing its job. Mobile money did not.

It is tempting to conclude that mobile money should simply copy the hospitals. That is not quite right, and it is worth being honest about why.

Patient records can be eventually consistent. If two clinics update the same chart offline and reconcile later, staff can resolve conflicts by hand, and the underlying data model, which is mostly append-only, cooperates. Money balances cannot work this way. If Agent A in Nakawa and Agent B in Wakiso both authorise a 100,000 UGX cash-out against the same account because their cached view of the ledger is stale, you have not built resilience. You have built a double-spend. The reason mobile money is centralised is not that fintech engineers never heard of edge computing. It is that a shared, authoritative ledger is the only cheap way to prevent one shilling from being spent twice.

The real design question

So the useful question is not “why is mobile money not offline-first like the EMR.” It is “which subset of payments could safely tolerate a temporary outage, and how much economic activity would that recover?”

The honest answer is: quite a lot. Low-value merchant payments below a threshold (say 20,000 UGX) could be authorised against a signed offline token issued when the phone last had connectivity, with settlement deferred and losses capped by an insurance pool funded through per-transaction fees.

This is not theoretical. EMV chip cards have executed offline authorisation on aircraft, ships, and remote terminals for decades, precisely because connectivity to an issuer is not guaranteed. India’s UPI Lite goes further and does it on phones: users pre-load a small on-device wallet while online, then pay merchants without any network at all, with per-transaction and daily caps set by the National Payments Corporation of India (currently ₹500 per transaction, ₹4,000 per day, ₹2,000 maximum wallet balance for UPI Lite X). Neither system tries to run the whole payment network offline. Both carve out a bounded slice where offline is safe, and pin down the rules in advance.

A properly specified offline profile could keep boda riders, market vendors, and small restaurants trading through the next Mutundwe event, while high-value transfers continue to fail-safe by rejecting when the switch is unreachable.

None of this appears in the Digital Drive Project spec, at least not in what has been published so far. That is the specific thing worth watching over the next quarter. If the Bank of Uganda’s national QR standard mandates online-only authorisation across the board, Uganda will have built a more elegant nation-wide failure mode. If it defines a bounded offline authorisation profile with clear rules on limits, expiry, and reconciliation, then interoperability becomes a structural upgrade rather than a bigger blast radius.

What to watch, and who this affects

For merchants, agents, and traders, the practical question is: on the day of the next outage, will your customers be able to pay you for a 3,000 UGX rolex, a 5,000 UGX boda ride, or a 15,000 UGX ka-order? Under the current design, no. Under a design that includes an offline profile, yes.

For fintech builders, including those of us working on payments infrastructure aimed at exactly these markets, the takeaway is not to blame MTN for a generator or to credit the Ministry of Health for setting a good example. It is that Uganda’s next mobile money outage is a question of when, not if, and the fastest way to reduce its economic cost is to specify, in advance, which transactions are allowed to keep flowing without a live central connection.

For the Bank of Uganda specifically, the concrete recommendation is short. Publish the offline authorisation section of the national QR standard before the switch goes live. Define the limits, the token format, the settlement window, the loss cap, and who pays for it. Everything else in the Digital Drive Project is a UX improvement. This is the piece that decides whether the next outage is an inconvenience or a national economic event.

The health sector accepted that connectivity would fail and designed around it a decade ago. The payments sector is being asked to make the same choice this year. The choice worth arguing for is not “no interoperability.” It is interoperability with a defined offline profile, specified before the switch goes live, not after the next outage.

Sources