M-Pesa, USSD, and the Greatest Leapfrog in Financial History
The Money Stack — Episode 5 of 10
In 2007, two things launched that changed how the world handles money.
One was the iPhone. The other was a text-message service in Kenya.
The iPhone got the documentaries.
M-Pesa was not supposed to be a payments product. It began as a development project, partly funded by a British government grant, designed to let microfinance borrowers repay small loans by SMS. The team built it, ran a pilot, and received data that made no sense.
People were not repaying loans.
They were sending each other money. A man in Nairobi would buy airtime credit and send it to his mother in Kisumu, who would convert it to cash by selling it to neighbours at a slight discount. They had turned prepaid phone credit into a remittance network, by hand, without permission, because the formal financial system had nothing useful to offer them.
Safaricom did what good product teams rarely do. They abandoned the original plan and built what people were already doing.
Within four years, a country where most adults had never held a bank account was moving a significant share of its entire GDP through feature phones. No smartphones. No internet connection. No bank branch. No app.
The lesson that most of the industry still has not fully absorbed: the constraint was never the technology. It was the assumption that finance had to begin with a bank.
What the Technology Actually Was
M-Pesa is usually described as a mobile money system. That description is accurate but leaves out the most interesting part: how it actually ran on the devices people had.
The M-Pesa menu did not live on the phone. It lived on the SIM card.
A SIM Toolkit application is a small programme stored on the secure element inside the SIM card itself. When you select it from the phone's menu, the SIM executes its own logic directly, without going through the phone's operating system or requiring internet access. The distribution problem — how do you get your application onto millions of handsets? — was solved before the product launched. Safaricom already had SIM cards in the hands of their subscribers. The app shipped inside the card.
The transport layer underneath is USSD: Unstructured Supplementary Service Data. Unlike SMS, which is a store-and-forward service — a message queued and delivered when a connection is available — USSD is session-oriented. It opens a live, stateful connection over the GSM signalling channel: the same infrastructure that handles call setup and network management. The session persists until explicitly terminated or it times out. Each exchange carries approximately 182 characters, requires no data plan, and functions on the cheapest handset ever manufactured, on a signal weak enough to drop a voice call.
The practical consequence is that a USSD transaction either completes or dies. There is no half-delivered message. There is no queued packet. The session is live, and when it closes, the transaction is either done or it is not.
Anyone who has sent money via a USSD code in Nigeria has felt the CAP theorem in person. When the session times out mid-transaction, the system faces a genuinely hard problem: did the debit succeed? Did the credit follow? The engineering challenges around USSD reliability and idempotency are not trivial, and every mobile money operator that built on this stack has a war story to tell about reconciliation failures during network congestion.
The Agent Network Was the Real Product
It is tempting to describe M-Pesa as a technology story. It is more accurately a logistics story.
A digital wallet is useless unless the user can get cash in and cash out. Electronic money that cannot be converted to physical currency is not money for most of the people M-Pesa was built for. Solving the technology was necessary but not sufficient. Solving the last mile required a different kind of infrastructure entirely.
The M-Pesa agent network is the answer. A shopkeeper with a float of physical cash and a registered M-Pesa account becomes an ATM, a branch, and an onboarding desk simultaneously. A customer walks in with cash, hands it over, and receives the equivalent value in their mobile wallet. Another customer walks in with mobile money, transfers it to the agent, and walks out with cash. The agent profits from the spread and the volume.
Managing agent liquidity is one of the most demanding operational challenges in financial services, and it receives almost no attention in popular accounts of M-Pesa's success. An agent in a rural market town needs to hold enough physical cash to meet cash-out demand on market day, when volumes spike unpredictably. They need enough e-float to meet cash-in demand when traders receive payments. Running dry on either side means turning customers away and losing the transaction fee. Getting the liquidity right requires a sophisticated supply chain of cash distribution, e-float top-up mechanisms, and real-time agent monitoring.
Safaricom solved this. The companies that tried to copy M-Pesa and failed — and there were many — usually failed here, not at the technology layer. Distribution and liquidity beat product and interface, reliably, in markets where the last mile is hard.
USSD in Nigeria
If you have ever dialled a USSD banking code in Nigeria, you have used the same fundamental architecture that M-Pesa runs on, adapted to a market that presents its own distinct challenges.
The major Nigerian banks each operate their own USSD short codes: *737# for GTBank, *894# for First Bank, *901# for Access, and others. Through these codes, a customer can check a balance, transfer funds, pay bills, and buy airtime from a basic handset with no internet access. These services reached Nigerians who had bank accounts but no smartphones, and reached them before most of them had reliable mobile data.
The Nigerian USSD story has a chapter that most international accounts omit: the dispute over session fees.
Every USSD session incurs a cost on the telecoms network, paid by the bank to the mobile network operator per session initiated. This cost is small individually and substantial in aggregate across millions of transactions. For years, the CBN, the banks, and the telcos negotiated — and argued — over who should bear this cost and how it should be structured. The dispute resulted in several service disruptions as telcos threatened to or actually did suspend USSD banking services. At one point, millions of customers lost access to their mobile banking channels entirely while institutions sorted out their commercial arrangements.
The engineering is not the only constraint. The business model, the regulatory framework, and the relationships between institutions are all part of the infrastructure that a mobile money service runs on. A technically excellent product can be switched off by a billing dispute.
The Leapfrog
The phrase "leapfrog technology" is often applied to Africa as a kind of consolation: you missed the earlier wave, but here comes another one you can join. That framing misunderstands what actually happened.
Kenya did not skip mobile banking because it lacked the capability to build it the Western way. It built differently because the Western way assumed infrastructure that did not exist. No widespread branch network. No consumer credit bureaus. No reliable broadband. No installed base of point-of-sale terminals. No baseline of banked customers to cross-sell to.
In the absence of those things, M-Pesa was not a compromise. It was the correct solution for the problem as it actually existed. A system built for unreliable networks, unbanked users, feature phones, and cash-based economies is not a lesser system. It is a different system, optimised for different constraints.
The Western financial system, with its branch networks and card terminals and COBOL mainframes, was not available to leap past. The constraint became the design brief. The result was infrastructure that worked for people who had been written off by every prior model of financial inclusion.
The absence of legacy was the advantage. And the lesson matters beyond Kenya. Nigeria built NIP — the instant interbank payment system — in 2011, years before India's UPI and a decade before FedNow in the United States. Brazil built PIX in 2020 and achieved near-universal adoption in three years. These are not developing-world approximations of real payment systems. They are real payment systems, built for real constraints, that outperformed their counterparts in countries that had more.
What the SMS Era Left Unsolved
M-Pesa demonstrated that financial infrastructure could be built on top of a mobile network with no internet, no bank account, and no smartphone. It reached people that the entire prior history of financial innovation had failed to reach.
It did not solve everything.
USSD sessions are text-only, slow, and capped at 182 characters per exchange. Building a merchant payments product on this stack is possible but awkward. Cross-border transactions are difficult because USSD is network-specific and carries no interoperability across operators or across borders. The agent network depends on human intermediaries with their own failure modes: fraud, unavailability, and the structural cost of cash handling.
The question that followed was whether software could do what the SIM card had done, at a level of abstraction that made financial services as easy to integrate as a package from npm.
The answer came in seven lines of code.
Episode 6: APIs Ate Finance — how Stripe, Paystack, and Flutterwave turned payment infrastructure into a function call. Coming 22nd October, 2026.
The Money Stack is a ten-part series on the history and technology of how money moves. Written by David, a software engineer in Lagos
Top comments (0)