Mobile money made East Africa a payments pioneer. Building reliably on top of it is an engineering problem before it is a product one.
East Africa did not follow the global playbook for financial technology. Most markets digitised the bank first and reached the customer later. Here it happened in reverse: mobile money reached people who had never held a bank account, and formal institutions spent the following years working out how to connect to a rail they did not own.
That inversion still shapes nearly every fintech decision made in the region. It explains why a savings product often launches through a USSD menu before it appears in an app, why reconciliation is harder here than in markets with a single clearing system, and why the most valuable engineering work is rarely the part the customer sees.
The integration surface is the product
For most institutions we speak to, the hard part is not the customer-facing application. It is everything behind it.
A lending product that disburses to mobile wallets has to reconcile against a payment processor, a core banking system, a credit reference bureau, and an internal ledger. Each has its own availability guarantees, its own idea of what a transaction identifier means, and its own failure modes. The application is a few screens. The integration is the system.
This is why payment work is better treated as infrastructure engineering than as feature development. The questions that decide whether a product survives contact with real volume are unglamorous ones:
- What happens to a disbursement when the callback never arrives?
- How do you distinguish a genuinely failed transaction from one that succeeded but whose confirmation was lost?
- Can you replay a day's settlement from your own records without asking the processor for a file?
- When two systems disagree about a balance, which is authoritative, and how do you prove it?
An institution that can answer those four questions confidently can ship almost any product on top. One that cannot will be firefighting regardless of how good the app looks.
Idempotency is not optional
The most common defect we find in payment integrations is the absence of a reliable idempotency strategy.
Mobile money callbacks are delivered at least once, not exactly once. Networks retry. Users tap twice. A processor that times out on its side may still have moved the money. If a system treats every inbound notification as a new event, it will eventually credit the same transaction twice — and it will find out from a customer rather than from its own monitoring.
The remedy is well understood and rarely implemented thoroughly. Every request that moves money carries a caller-generated key. The receiving system records that key durably before acting. A repeat of the same key returns the original result instead of performing the work again. It costs very little to build in from the start and is genuinely painful to retrofit under load.
Reconciliation deserves first-class treatment
Reconciliation is often treated as an operational chore: a report someone runs, a spreadsheet someone checks. In a mobile-money-first market it is closer to a core system requirement.
Institutions that handle it well tend to share a pattern:
- They keep an internal double-entry ledger that is independent of any processor.
- They record every external interaction with enough context to reconstruct it later.
- They run automated matching continuously rather than at month end.
When a discrepancy appears, it surfaces within hours — while the counterparty still has logs — rather than in a quarterly review when nobody can reconstruct what happened.
The alternative is treating the processor's statement as the source of truth. That works right up until it doesn't, and by then the institution has no independent record with which to argue.
Regulation has become an engineering constraint
Compliance in the region has moved from paperwork to system design. Data protection obligations affect where customer records may be stored and how long they are kept. Reporting requirements affect what must be captured at the moment a transaction occurs, not reconstructed afterwards. Consumer protection rules affect what a customer must be shown before they confirm.
None of that can be bolted on at the end. A system that did not capture consent at onboarding cannot produce evidence of it later. A system that stores personal data with no retention policy cannot honour a deletion request without a migration. Building these obligations into the data model early is considerably cheaper than proving compliance retroactively.
What the next decade rewards
Mobile money solved distribution. It did not solve credit assessment, treasury management, cross-border settlement, or the long tail of business banking — and those are where the interesting problems now sit.
The institutions best placed to take them on share three traits. They own their ledger rather than renting it. They can onboard a new partner in weeks, because integration is an abstraction in their system rather than a bespoke project every time. And they treat internal tooling — reconciliation views, transaction search, replay — as product surface for their own staff rather than an afterthought.
None of that is exotic. It is ordinary, careful engineering applied to a market with unusual constraints.
Where we fit
We build payment integrations, core banking interfaces, SACCO management systems, and the reconciliation tooling that sits underneath them. Much of this work is not greenfield: it is making an institution's existing systems reliable enough to launch something new on top of.
If you are weighing a payments build, the most useful first conversation is usually about your ledger and your failure modes rather than your roadmap. You can see the shape of that work on our banking and fintech page, or tell us what you are building.