The Interface Tax: What a 1990s Signalling Protocol Still Costs Kenya, in Hours

Why USSD persists, and why that is not a design failure

USSD (Unstructured Supplementary Service Data) was never built for this. It is a 1990s addition to the GSM signalling layer — the same channel that carries voice call setup, not the data layer — originally meant for operator-to-handset signalling, not financial services (Wikipedia, Unstructured Supplementary Service Data; World Economic Forum, "How a 20-year-old mobile technology protocol is revolutionizing Africa"). It works precisely because it asks almost nothing of the device: no data bundle, no app, no operating system newer than whatever shipped on a KES 2,000 feature phone. The World Economic Forum's accounting of the protocol's reach puts the number plainly — nine in ten mobile transactions across Sub-Saharan Africa flow through USSD, not an app.

That reach is not inertia. Nearly half of Sub-Saharan Africa's mobile subscribers are still on basic or feature phones, for whom USSD is not a fallback option but the only option (Arkesel, "USSD vs Mobile App in Africa: When Each One Wins"). And even for a provider with a smartphone user in hand, the economics are not close: acquiring a borrower through a USSD shortcode runs under USD 0.50 in fully-loaded session cost with a self-service completion rate above 70%, against a 20–30% completion rate for an app download (HelloDuty, "USSD Banking in Kenya: How Lenders Acquire Loan Customers"). Every one of these facts is a reasonable, rational decision from the side of the system. This paper is only interested in the side of the ledger nobody prices: the minutes that reach, reliability and near-zero cost are quietly funded by, on the other end of every session.

A framework built for government, applied somewhere it was not built for

Pamela Herd and Donald Moynihan coined administrative burden to describe the learning, compliance and psychological costs citizens absorb when they interact with the state — costs that are not neutral technical friction but frequently a product of design choices, deliberate or not (Moynihan, Herd & Harvey, "Administrative Burden: Learning, Psychological, and Compliance Costs in Citizen-State Interactions," Journal of Public Administration Research and Theory, 2014; Herd & Moynihan, Administrative Burden: Policymaking by Other Means, Russell Sage Foundation, 2018). The three costs map onto a USSD session almost exactly:

• Learning costs — memorising which star-code does what, which numbered option is "Send Money" this month, and which account menu hides "Buy Goods" four levels deep.
• Compliance costs — the actual keystrokes: dial, wait, select, re-enter the amount after a typo, re-enter the PIN after a timeout, wait again for the confirmation text that is the only proof the transaction happened at all.
• Psychological costs — the specific anxiety of watching a session die mid-transaction with no indication whether the money moved, and no path back to find out except redialing and hoping.

Herd and Moynihan built this framework for citizens and the state. Nothing in it requires a government on the other end — it requires only an interface a person must get through to receive something they need, where the interface's design is not neutral. A payment rail that routes tens of millions of people through a menu qualifies on every count. What is different here, and worth being honest about, is intent: administrative burden in its original context is often examined as something imposed, sometimes deliberately, to ration access. USSD's burden is mostly the opposite — an accidental inheritance of a 2G-era protocol that solved a harder problem (universal reach, zero data cost) and left this one unsolved as a side effect, not a design goal.

What one session actually costs

A USSD session has a hard outer bound and a softer typical duration. The inactivity timeout that silently kills a session is operator-configurable, typically somewhere between 60 and 180 seconds (GSMA, "Low-tech, high-impact: USSD in the time of COVID-19"; Arkesel, USSD menu design best practices). Within that bound, a simple, well-designed session — a popular action placed near the top of the main menu — gets a user through in roughly four to five key-presses and well under a minute; general research on menu-based USSD completion puts a typical transaction at twenty to forty-five seconds end to end (Mobile for Good, "Everything You Need to Know About USSD vs SMS"). A deeper transaction — paying a till number typed digit by digit, confirming a name, re-entering an amount after a typo — runs longer, and a session that times out once adds a full redial on top.

None of this is exotic. It is also not nothing. Hick's Law, one of the oldest stable findings in choice-reaction research, holds that decision time grows with the number of alternatives on offer — logarithmically, not linearly, but real and measurable at every step (Hick's law for choice reaction time: A review). A USSD menu is Hick's Law applied serially: every nested level is its own fresh decision, so a four-level menu does not cost four times a one-level menu's decision time, but it does cost meaningfully more than the designer's one-glance mental model suggests — which is exactly why "put the popular action higher in the menu" is the single most effective fix research on this interface keeps landing on, and exactly why it is never fully implemented, since every provider's menu is serving dozens of actions, not one.

The estimate — a range, not a number

Kenya had 54.0 million mobile money subscriptions by the end of FY2025/26, of which Safaricom's M-PESA held roughly 88–89% (Communications Authority of Kenya, Q4 FY2025/26 Sector Statistics Report) — consistent with Safaricom's own figure of roughly 40 million monthly active M-PESA customers as of mid-2026 (Safaricom, "M-PESA Hits 40 Million Customers Milestone as It Turns Nineteen"). Across FY26, M-PESA processed 46.4 billion transactions, up 25.1% year on year, of which 17.1 billion — 36.8% of volume — were "kadogo," micro-transactions under KES 101 for transfers or KES 201 for merchant payments: small, frequent, exactly the kind of transaction a quick USSD dial is built for (Techweez, "Kenyans Moved KES 41.7 Trillion Through M-PESA in a Single Year"; tech-ish, Safaricom FY26 results explained).

Not every one of those 46.4 billion transactions is a human manually dialing a menu — a real and growing share is STK Push (an app or merchant system prompting a PIN entry), API-driven business disbursement, or Safaricom's new My OneApp, which merged the former M-PESA app (roughly 6.7 million users) and MySafaricom app (roughly 2.8 million users) into one platform reporting about 6.5 million 30-day active users after the April 2026 merger (TechCabal, "Safaricom migrates M-PESA app users to My OneApp"; tech-ish, My OneApp coverage). Even taking that generously — assuming zero overlap and that every app user transacts exclusively through the app — fewer than 10 million of roughly 40 million monthly active M-PESA users are primarily on an app at all. The rest, on the order of 30 million people, are the population this paper is actually about.

The table below holds three scenarios, varying only the two inputs that are genuinely uncertain: what share of all transactions are still a manual USSD dial, and how long an average session actually runs once typos, timeouts and nested menus are accounted for.

At the midpoint scenario, Kenya spends on the order of 338 million hours a year dialing a payment menu — roughly 38,600 person-years of continuous human attention, annually, on one country's mobile-money rail alone, before counting the many other USSD-only services (airtime, other banks' own shortcodes, SACCOs, utility prepayment) this estimate does not even touch. For an individual at the midpoint, that is roughly eight hours a year, or a little over a working day across four years — toward the lower end of what an engaged, frequent user running small daily business transactions on top of personal ones would actually log, which is closer to the high scenario or beyond it.

What this is not

• Not a measured number. The one dataset that would settle this — telco-side session-duration logs, which Safaricom and the Communications Authority hold and do not publish at this granularity — is the actual ground truth. Everything here is a transparent estimate built from public transaction-volume and session-mechanics research, not a measurement.
• The USSD-share assumption is the weakest input. No public source states what fraction of M-PESA's 46.4 billion annual transactions are manually dialed versus app-, API- or merchant-initiated. The 60–85% range is this paper's own judgment call, bounded by the WEF's historical "nine in ten" figure for the region as a ceiling and the visible growth of STK Push and My OneApp as a reason the true current figure for Kenya specifically is very likely below that ceiling and falling.
• This number is shrinking, not fixed. My OneApp's April 2026 launch, Tap-to-Pay, and STK Push adoption are all live, ongoing substitutions away from manual dialing. A version of this paper written in 2029 should find a smaller number, and that would be the correct outcome, not a contradiction of this one.
• No per-transaction value weighting. A kadogo airtime top-up and a business payroll run cost the same few keystrokes but are not the same economic event; this estimate treats all transactions as equally time-costly, which is defensible for a time estimate and would not be for a value one.

What this changes

Two things. First, the administrative-burden framework travels further than its authors likely intended — it describes a private payment rail's menu as accurately as it describes a benefits office queue, and that portability is itself worth someone besides me following up on. Second, the honest next instrument is not a bigger national estimate but a smaller personal one: a simple tool that takes an individual's own M-Pesa statement — transaction count and type, nothing else, processed and discarded rather than stored — and returns that one person's own number against this same model, rather than a population average that necessarily erases the gap between a light user and someone running a business through the same menu. That tool does not exist yet. This paper is the argument for why it would be worth building before it is built.

This paper started as a question to myself, not a hypothesis: how many hours have I actually spent on USSD in the last four years. It does not give a clean answer — it gives a bounded range, with every input shown, because a single confident number would have been a worse answer dressed up as a better one. What the exercise actually surfaced is a thing nearly every Kenyan phone owner does without noticing has a real, specific, mostly unexamined cost — and the cost is not visible until someone sits down and multiplies the small number by the population it actually happens to.