Kenya’s $310 Billion Mobile Economy Has a Data Problem at Its Core
Kenya’s mobile money ecosystem processes transaction volumes that rival entire national payment systems, yet most businesses extract almost no strategic value from it. The issue is not infrastructure — M-Pesa works exactly as designed — but what happens after the transaction.
Payment data enters organisations through finance, where it is reconciled, archived, and effectively abandoned. Without integration into CRM, operations, or analytics layers, these transactions remain isolated events rather than behavioural signals. This structural choice limits visibility into churn, demand shifts, and customer response patterns.
Kenya processed an estimated $310 billion in mobile money transactions in 2024, according to the Central Bank of Kenya’s Payment System Annual Report and Safaricom’s FY2024 Annual Report. To put that figure in context: Kenya’s mobile money volume relative to GDP exceeds that of most developed payment markets globally. The infrastructure is not the problem. The pipes are extraordinary.
What flows through those pipes, however, and what Kenyan businesses actually receive from them, is where the paradox sits. When a payment is completed via M-Pesa Paybill, the Daraja API callback delivers four fields to the receiving organisation: a phone number, an amount, a timestamp, and a transaction ID. That is the complete informational universe of the event, as far as the business is concerned.
This is worth comparing to what a merchant using Stripe, Square, or even a basic Shopify Payments integration receives as a matter of course: device type, session behaviour, geographic coordinates, purchase frequency relative to account history, cross-merchant spend signals where applicable, and cohort-level analytics built into the dashboard by default. None of this requires a separate analytics contract. It is the baseline.
The M-Pesa architecture was built to move money at population scale with near-zero friction, and it succeeded definitively at that objective. It was not built to produce customer intelligence for the businesses it serves. The analytical metadata that every global payment platform now treats as a minimum viable product — behavioural context, frequency signals, geographic granularity below county level, customer-level longitudinal data — is simply absent from the callback architecture. Kenyan businesses receiving Paybill payments are operating with the transactional equivalent of a cash register receipt in an era when their international counterparts are working with full customer data platforms.
The $310 billion is not the story. The story is what that $310 billion is not telling anyone.
Transaction data is treated as a filing task
There is a structural explanation for why this gap persists, and it is not a technology explanation. It is an organisational one. In most Kenyan enterprises, the M-Pesa statement entered the organisation through the finance department, because M-Pesa is a payment mechanism and payments are finance’s domain. Finance’s job with that data is reconciliation: confirm receipt, match to invoice or order, close the period. Once reconciliation is complete, the data has served its purpose and is archived. Nobody in that workflow was asked to extract customer behaviour from a phone number and a timestamp, and so nobody did.
The uncomfortable truth is this: your organisation decided, by default, that transaction data is the finance team’s filing problem — and nobody in your leadership team has ever formally reversed that decision. The intelligence already exists in your systems. What does not exist is the organisational will to use it.
This is a leadership failure, not a technology limitation. The data required to answer the CFO’s Monday morning questions is not missing. It is sitting in an archived M-Pesa statement, unjoined to anything, unanalysed, and overwritten next month.
The sectoral costs of this default decision are specific. For Kenyan commercial banks, churn prediction based on declining transaction frequency is not operationally possible without treating M-Pesa behaviour as a first-party signal. Banks currently rely on exit surveys, direct debit failures, or account dormancy notices — all of which arrive after the customer has already decided to leave. For FMCG companies with distributor Paybill networks, regional demand shifts are invisible until they surface as stock variance in monthly reports. Marketing attribution for campaigns that drive M-Pesa responses is essentially unmeasurable, because there is no mechanism connecting the payment event to the campaign exposure. For insurers, policy lapse prediction — one of the highest-value analytics problems in the sector — is being addressed with actuarial models built on lagging demographic indicators, when real-time mobile transaction behaviour is a demonstrably better predictor of financial stress. The data exists. The architecture to use it does not.
A Business Daily Africa analysis of enterprise data practices found that big data adoption among Kenyan firms remains significantly below peer markets, with most organisations describing their analytics capability as primarily retrospective and operational rather than predictive and strategic. That finding is not surprising. It is the logical outcome of treating the continent’s richest behavioural data stream as an accounting input.
Payment data needs a three-layer architecture
Addressing this gap does not require replacing M-Pesa or renegotiating with Safaricom. It requires building the analytical layer that the Daraja API does not provide, on the business’s own infrastructure. This architecture has three distinct components, and understanding what each does — and why each requires deliberate investment — is important for any leader considering this problem seriously.
The first tier is ingestion and centralisation. Every Paybill callback, across every channel and every business unit, must flow into a single structured data store in real time rather than into disconnected settlement files. This sounds straightforward, but most Kenyan organisations with multiple Paybill numbers, multiple banks, and multiple reconciliation workflows have transaction data distributed across finance systems, ERP modules, and email inboxes simultaneously. Centralisation is the prerequisite for everything else, and it is not automatic.
The second tier is contextual enrichment. A phone number and a timestamp have limited analytical value in isolation. Their value becomes substantial when the phone number is joined to the organisation’s CRM record, purchase history, support ticket log, loyalty programme status, and geographic account data. This join — the process of stitching the M-Pesa identifier to a complete customer profile — is where most of the intelligence is created. It is also where most organisations stop, because it requires data governance decisions about identity resolution, consent frameworks under the ODPC’s December 2024 Conduct of Compliance Audit Regulations, and integration between systems that were not built to talk to each other. These are solvable problems, but they are not one-click problems.
The third tier is predictive visualisation — the layer that translates enriched transaction data into decision-relevant outputs for operational and C-suite users. This is not a dashboard of historical totals. It is a system that surfaces forward-looking signals: declining frequency in a customer segment three weeks before expected churn, regional transaction anomalies that warrant a supply chain review, cohort-level response to a pricing change within 48 hours of implementation. The CFO opening her Monday morning report should be reading that output, not a settlement reconciliation.
Each tier requires deliberate investment in architecture, data governance, and integration capability. None of it is a software purchase.
Data capability is already driving competitive advantage
The organisations that will define Kenya’s next decade of financial services, retail, and insurance are not necessarily those with the best payment acceptance infrastructure. That race is largely over and M-Pesa won it for everyone. The organisations that will pull ahead are those that have made a deliberate decision to treat payment events as intelligence assets rather than accounting entries.
This distinction is already creating measurable competitive separation. A bank that can identify declining M-Pesa transaction frequency in a customer’s account — not declining balance, declining frequency — three weeks before the customer stops using the account has a fundamentally different cost of retention than a bank that discovers the same customer has churned during a quarterly review. The intervention when frequency drops is a proactive offer, a relationship call, a targeted product. The intervention after churn is an expensive win-back campaign with low conversion rates. Mobile money data analytics in Kenya, applied at this level of precision, is not a reporting upgrade. It is a structural cost advantage.
The same logic applies to FMCG distributors who can identify regional demand shifts from distributor payment patterns before they become stockout events. It applies to insurers who can flag financial stress signals from transaction behaviour before a premium lapses. It applies to any organisation operating at scale in a market where M-Pesa is the primary transaction channel — which is to say, virtually every significant Kenyan enterprise.
The pushback here, and it is common, is that the Daraja API provides sufficient data for these purposes. It does not. The API callback confirms that a transaction occurred. It provides transactional confirmation. There is a categorical difference between knowing a payment happened and understanding what that payment means in the context of a customer’s financial life — their frequency trend, their basket composition over time, their geographic consistency, their response to pricing changes. The callback gives you the event. The analytical architecture gives you the meaning. These are not the same thing, and treating them as equivalent is precisely the assumption that has kept most Kenyan organisations in the filing mindset.
This is the kind of infrastructure problem that Jansen Tech was built to address. See Jansen Tech Document & Content Management . Designing the ingestion, enrichment, and predictive visualisation architecture described above requires deep familiarity with Kenya’s specific integration landscape — the Daraja API’s actual data structure, the ODPC’s compliance requirements, the ERP and CRM systems most commonly in use across Kenyan enterprises, and the organisational change management that determines whether a system gets used or archived. A globally generic business intelligence vendor cannot provide that context. Jansen Tech builds for this market specifically, because the solutions that work here are not the solutions built for somewhere else.
The GSMA’s 2024 projection of KSh 662 billion in digital economy growth will not distribute itself evenly across Kenyan enterprises. It will flow toward the organisations that built the infrastructure to understand what their transactions were already telling them. The ones that did not will process those transactions, archive the statements, and wonder why their customer retention costs are rising while their competitors’ are falling.
In three years, the Kenyan enterprises that have made this investment will have something their competitors cannot quickly replicate: two to three years of enriched, longitudinal customer data built on their own transaction history. That data compound. A churn model trained on three years of mobile behaviour is categorically more accurate than one trained on six months. The organisations that start now are not just solving today’s analytics problem — they are building a proprietary intelligence asset that grows more valuable with every transaction that flows through it.
The question is not whether to invest in transaction intelligence. The question is whether you build it before or after your competitors do, and whether that gap will still be closeable when you decide.