edidiong umana · writing
home
Agentic commerce in Africa6 min read

Mobile money already runs on agents

Long before AI agents, African payments ran on people at kiosks and on savings circles held together by trust. Here are five problems they already solved, and the design rule each one gives anyone building agent payments.

You're designing an AI agent that pays for things: an API call, a delivery, a supplier's invoice. The hard questions arrive fast. How does the person on the other end get money they can actually spend? What happens when the agent's wallet runs dry halfway through a task? Why should anyone trust it? And what happens when it pays the wrong person?

None of these questions is new. Across Africa they have been answered at scale, by people: the mobile money agent at the corner kiosk, and the organiser of a savings circle.

Two systems that already work

GSMA's State of the Industry Report on Mobile Money 2026 counts 2.3 billion registered mobile money accounts in 2025, 593 million of them active in a 30-day period, with most new accounts coming from Sub-Saharan Africa. Behind them sit 30 million registered agents, 11 million of them active each month, who took in $430 billion of cash deposits in 2025. The World Bank's Global Findex 2025 puts account ownership in Sub-Saharan Africa at 58% of adults, up from 49% in 2021, and says the region's use of mobile money accounts is the highest in the world.

GSMA's glossary describes the agent as the human touchpoint of the service: someone who turns cash into e-money (cash-in) and back again (cash-out), and who often teaches new users how to transact. Agents typically run another business alongside mobile money; small traders, chain stores and bank branches all serve as agents in some markets.

The second system is older. A rotating savings and credit association, or ROSCA, is a group whose members each pay a fixed amount at every meeting into a pot that goes to one member in turn. Readers here know them as ajo, esusu, susu or chama. A Philadelphia Fed survey of ROSCAs lists esusu across West Africa, and osusu and adashi in Nigeria, among dozens of local names worldwide. Here is what the two systems worked out.

1. Cash-out is the real product

For most users, e-money matters because it can become something else: cash, school fees, stock for the shop. That's why access to agents shows up in GSMA's consumer survey: "lack of access to agents" and "agents don't have cash" are both among the barriers people cite for not having an account.

Design rule: design the exit first. Before your agent pays anyone, know how the recipient turns that payment into something they can spend, whether that's local currency, airtime, inventory or a bank balance. Measure the time and cost from "paid" to "spendable", not from "sent" to "confirmed". A payment that settles in two seconds and takes three days to cash out is a three-day payment.

2. Float and liquidity live at the edge

GSMA defines an agent's float as the e-money, cash or bank balance they can use immediately to serve customers, and liquidity management as balancing cash against e-money so they can serve both cash-ins and cash-outs. An agent with plenty of e-money and an empty cash drawer can't pay anyone out. GSMA's 2026 report also notes that float requirements, among other rules, can decide whether agent networks grow or stall.

Design rule: give every agent a float it can see, and limits it can't argue with. An AI agent that fails halfway through a paid task because its wallet emptied is a kiosk with no cash. So check the float before committing, say "can't serve this now" cleanly when it's short, and top up by a written rule, not in a panic. These checks belong in ordinary code that runs before any payment, outside the model:

type Payment = { id: string; to: string; amount: number };

type Policy = {
  perPaymentCap: number;   // largest single payment
  dailyCap: number;        // total the agent may spend today
  allowlist: Set<string>;  // counterparties this agent has earned
  askHumanAbove: number;   // a person confirms anything larger
};

type State = { spentToday: number; float: number; seenIds: Set<string> };

type Decision =
  | { ok: true; needsHuman: boolean }
  | { ok: false; reason: string };

function check(p: Payment, policy: Policy, s: State): Decision {
  if (s.seenIds.has(p.id)) return { ok: false, reason: "duplicate payment" };
  if (!policy.allowlist.has(p.to)) return { ok: false, reason: "unknown recipient" };
  if (p.amount > policy.perPaymentCap) return { ok: false, reason: "over per-payment cap" };
  if (s.spentToday + p.amount > policy.dailyCap) return { ok: false, reason: "over daily cap" };
  if (p.amount > s.float) return { ok: false, reason: "not enough float" };
  return { ok: true, needsHuman: p.amount > policy.askHumanAbove };
}

const policy: Policy = {
  perPaymentCap: 50, dailyCap: 120, allowlist: new Set(["shop-17"]), askHumanAbove: 10,
};
const state: State = { spentToday: 90, float: 20, seenIds: new Set(["a0"]) };

console.log(check({ id: "a1", to: "shop-17", amount: 8 }, policy, state));  // ok, no human
console.log(check({ id: "a2", to: "shop-17", amount: 15 }, policy, state)); // ok, needs human
console.log(check({ id: "a3", to: "shop-17", amount: 25 }, policy, state)); // not enough float
console.log(check({ id: "a4", to: "shop-17", amount: 35 }, policy, state)); // over daily cap
console.log(check({ id: "a5", to: "stranger", amount: 5 }, policy, state)); // unknown recipient
console.log(check({ id: "a0", to: "shop-17", amount: 5 }, policy, state));  // duplicate payment

Save it as pay.ts and it runs as written with node pay.ts on Node 24, or with any TypeScript runner. Amounts are in whatever unit your rail settles in.

3. Trust comes from local reputation

A savings circle has no contract and no collateral, so it runs on what the Philadelphia Fed paper calls social capital. Organisers recruit people from their own networks whom they can depend on. Members join when they see the organiser as credible, and the organiser may even cover a defaulting member's payments. In some traditions, new members take the pot in the last rounds and move up the order once they've shown they pay. Defaulting costs a member their standing, and with it their future access to credit.

Mobile money leans on something similar. Because agents usually run another business, the till tends to sit inside an existing shop rather than behind an anonymous screen.

Design rule: let trust be earned in small, visible steps. New counterparties start with low limits and late positions, like the new member of an ajo. Limits rise with a record of payments made and goods delivered, and that record should be one the other side can check. And someone accountable stands behind every agent, the way the organiser stands behind the circle.

4. Limits and reversals were there from the start

Mobile money assumes people make mistakes. Safaricom's M-PESA, for example, publishes hard ceilings on its tariffs page: KES 250,000 per transaction, and KES 500,000 a day and in balance. Its Hakikisha service shows the recipient's name before the sender confirms. And its reversal process lets a sender forward the confirmation SMS to 456, after which Safaricom follows up with the recipient before any money comes back.

Design rule: cap in code, confirm the name, and build the way back. Hard limits belong outside the model, as in the snippet above. Show a human-readable name for the counterparty before any payment that can't be undone. If your payment rail is final, as many are, the reversal path won't exist unless you build it: hold funds for a short window before release, or keep a refund route with an accountable person on each side.

5. Dollar balances where the currency is losing value

Where a local currency loses value quickly, people look for a steadier place to keep their money. Chainalysis reported a spike in the region's activity in March 2025, driven largely by exchange activity in Nigeria after a sudden currency devaluation. It also described stablecoins working as a dollar substitute where official and parallel exchange rates diverge, with people using these rails for informal FX, payments and savings.

Design rule: hold in the unit people trust, pay out in the unit they spend. Whatever rail you build on, whether bank, card, mobile money or a blockchain, let users keep balances in a stable unit and quote everything in local currency at the moment of conversion, with the rate and fees shown. Be plain about the trade-off: a dollar-denominated balance is only as good as whoever issues it and your ability to convert it back.

The rules on one page

What already workedProblem it solvedRule for agent payments
Agents who cash outMoney people can actually spendDesign the exit first; measure paid-to-spendable
Agent floatLiquidity at the edgeVisible float, hard caps, a clean "can't serve now"
Savings circlesTrust without contractsStart small, earn limits, someone accountable behind each agent
Limits and reversalsHuman errorCaps in code, confirm the name, build the way back
Dollar-like balancesA currency losing valueHold stable, pay out local, show rate and fees
In AfricaNext time you use a mobile money kiosk, ask the operator, if they have a minute, what they do when the cash runs low. Write their answer down as your agent's float policy.

Learn it properly

For the accountability side of rules 3 and 4, Track 2 of the AI Study Group, Ethical AI in Africa, is free, needs no coding, and covers documenting your system and launching with complaint routes and pause rules.

Sources