Fraud at Mobile Money Scale: AI Detection for a Billion Transactions
Mobile money moves more value across East Africa than the card networks, and it is defended largely by rules written years ago.
Mobile money moves more value across East Africa than the formal card networks, and it is defended largely by thresholds and blocklists written years ago. Fixed rules cannot see the patterns that actually cost money.
An agent float cycling in ways no legitimate business does. A SIM swap followed within minutes by a password reset and a maximum withdrawal. A mule network fanning small amounts through dozens of freshly registered wallets. These are graph problems, not threshold problems.
Model the network, not the transaction
A transaction viewed alone is almost never diagnostic. The same 200,000-shilling transfer is routine between two long-standing counterparties and highly suspicious between a wallet registered yesterday and one that has received eleven similar amounts in the last hour.
That means the primary data structure is a graph of wallets, agents, devices, and SIMs, with time-decayed edges. Most operators already hold every field needed to build it and have never assembled it, because the fraud team's tooling was designed around single-transaction rules.
A wrongly frozen wallet is someone's school fees. Precision is a customer protection requirement, not a technical preference.
The operational constraints are harsher than the modelling ones
Detection has to score in under a hundred milliseconds, degrade gracefully when a regional link drops, and keep working when an agent terminal is offline for hours. That rules out a cloud round trip per transaction as the only line of defence, and points to edge-side heuristics with centralised retraining, a lightweight local rule set updated from a model that learns centrally.
Failure behaviour has to be decided in advance and in writing: when the scoring service is unreachable, does the platform fail open and accept risk, or fail closed and block legitimate commerce? Both are defensible. Discovering you never decided, during an outage, is not.
False positives are not cosmetic
A wrongly frozen wallet is someone's school fees, a trader's stock payment, or a family's medical bill. Precision targets in this domain are not a technical preference; they are a customer protection requirement, and they should be set jointly with the customer operations team that will handle the calls.
The corollary is that the review path matters as much as the model. A flagged account needs a fast, staffed, documented route to resolution, measured in minutes, not in a support ticket queue.
Measure the current rules honestly first
Most operators cannot state the true recall of their existing rule set, because confirmed fraud is only labelled when a customer complains. Establishing a labelled baseline, through investigation sampling and reconciliation against dispute outcomes, is the first project, and it is the one that makes every subsequent model claim credible.
What this means in practice
- Build the wallet, agent, device, and SIM graph before evaluating any vendor detection product.
- Establish a labelled fraud baseline through investigation sampling so the current rule set's real recall is known.
- Decide and document fail-open versus fail-closed behaviour for scoring outages before deployment.
- Set precision targets and a minutes-not-days review path jointly with customer operations.
Frequently asked questions
- What is this analysis about?
- Mobile money moves more value across East Africa than the card networks, and it is defended largely by rules written years ago.
- What is the core argument?
- Mobile money moves more value across East Africa than the formal card networks, and it is defended largely by thresholds and blocklists written years ago. Fixed rules cannot see the patterns that actually cost money.
- Model the network, not the transaction?
- A transaction viewed alone is almost never diagnostic. The same 200,000-shilling transfer is routine between two long-standing counterparties and highly suspicious between a wallet registered yesterday and one that has received eleven similar amounts in the last hour.
- What should our organisation do about it?
- Build the wallet, agent, device, and SIM graph before evaluating any vendor detection product. Establish a labelled fraud baseline through investigation sampling so the current rule set's real recall is known. Decide and document fail-open versus fail-closed behaviour for scoring outages before deployment. Set precision targets and a minutes-not-days review path jointly with customer operations.
- Who published this and can we discuss it with Kwish?
- Kwish Research Team at Kwish Technologies published this on February 2026. Kwish works on finance programmes from offices in Uganda, Kenya, Sweden and Canada, and you can reach the team at info@kwishtechnologies.com.
Keep exploring
Turn this analysis into delivery
The services, sectors and case studies connected to this article.
Services that deliver this
Sectors where this applies
Related insights
Core Banking Won't Save You: Why African Banks Need AI-Native Risk Engines
A core system records transactions; it does not decide who deserves credit. That decision still runs on models imported from Basel-era Europe.
Why African Governments Need AI-Native Systems, Not Retrofits
The temptation when modernising government technology is to retrofit. That instinct is exactly what Africa cannot afford.
The Hidden AI Infrastructure Gap in East African Universities
Faculty want AI in the classroom. IT departments don't have the data plumbing to deliver it. Here's the gap nobody is funding.
Want this applied to your organisation?
Send us the decision you are trying to make. We reply with a scoped quotation.
Most quotations answered within one business day.