M-PESA Data Minimization Rolls Out for P2P as SME Payments Lag Behind

Starting today, Safaricom switched on data minimization for M-PESA peer-to-peer transfers. The change is visible immediately: masked phone numbers, shortened names, and a new consent layer for sharing full identity. It is a clean intervention in a system where a phone number has long doubled as identity, receipt, and contact channel.

But the rollout is uneven by design.

The same briefing that outlines the P2P shift places full data minimization for SME-facing payment notifications—Buy Goods and Paybill—later in the year. That delay creates a temporary asymmetry: individuals transacting with each other gain privacy protections now, while small businesses receiving payments continue to see fuller customer data in SMS notifications.

Two Systems, Two Risk Models

P2P transactions are structurally simple. One sender, one recipient, a direct notification loop. At scale—14.1 million daily active users and tens of millions of transactions—the system is large, but its architecture is predictable. Masking a phone number in this context is a presentation-layer change with limited downstream dependencies. The sender and recipient still complete the transaction; only the visibility of personal data is reduced.

Buy Goods and Paybill flows sit on top of a more complex commercial stack. Transactions are not just confirmations; they are inputs into reconciliation systems, inventory tracking, accounting, customer service workflows, and sometimes third-party integrations. The SMS notification is often the first record a merchant sees, but it is rarely the only one they rely on.

Masking data here is not just about hiding a number. It risks breaking a chain of operational assumptions.

A merchant who receives hundreds of payments a day may depend on visible phone numbers to resolve disputes, confirm orders, or match transactions to customers outside formal systems. In informal or semi-digitized businesses, that SMS is the system of record. Reducing data at that point introduces friction that has to be absorbed somewhere else—either through new tools, APIs, or workflows that do not yet exist at scale.

Why Pochi Was Different

The contrast with Pochi la Biashara is instructive. When it launched in 2020, it was built with data minimization embedded from the start. It separated personal and business identities, allowing merchants to receive payments without exposing their primary phone numbers.

That worked because Pochi defined a new behavior.

Users opted into a different product with different rules. Expectations were reset at entry. There was no legacy dependency on full data visibility because the system never offered it in the first place.

Buy Goods and Paybill do not have that luxury. They are entrenched rails, used by a wide spectrum of businesses—from large organizations integrated via APIs to SMEs relying on basic SMS alerts. Retrofitting privacy into that environment is closer to infrastructure surgery than a feature update.

The Technical Constraint

The briefing hints at where the difficulty lies: large organizations integrated into Buy Goods and C2B APIs are part of the data minimization roadmap, but SME SMS notifications are treated as a separate phase.

That separation reflects two distinct technical problems.

For API-integrated merchants, data minimization can be managed within structured systems. Fields can be masked, permissions layered, and alternative identifiers introduced without collapsing workflows. These merchants already operate with databases, dashboards, and reconciliation logic that can adapt.

For SMS-dependent SMEs, the problem is harder. The SMS is unstructured, final, and user-facing. There is no secondary interface to compensate for lost data. Any reduction in visible information must be offset by something equally accessible—likely a new verification mechanism, lookup service, or lightweight merchant tool.

P2P introduces one such mechanism: verification via code 334, where recipients can request full details with sender consent. Translating that into a high-volume merchant context is not straightforward. A system that works once per transaction between individuals does not scale cleanly when a business processes hundreds of payments per hour.

Prioritization Is Not Neutral

The sequencing of this rollout is often framed as technical necessity, but it also reflects a prioritization of risk.

P2P exposes individuals directly to unwanted contact, spam, and social engineering. The briefing is explicit: masking reduces the ability to capture and reuse phone numbers for fraud or harassment. The harm is immediate and personal.

SME transactions distribute that risk differently. A business receiving a customer’s number is not automatically a threat vector in the same way an unknown individual might be. At the same time, businesses rely on that visibility to function. Reducing it without replacement tools risks economic friction.

In that sense, the rollout prioritizes personal privacy over commercial continuity—at least in the short term.

The Cost of the Gap

The result is a system where privacy is unevenly applied.

A customer sending money to another individual sees their number masked. The same customer paying a small merchant may still expose full details, depending on the channel used. From a user perspective, the logic is not obvious. The expectation of privacy becomes inconsistent across similar actions.

That inconsistency matters.

Data minimization works best when it is predictable. When users cannot anticipate what information is shared in each context, trust becomes conditional. The system signals that privacy is situational, not systemic.

What Closes the Gap

The path forward is implied in the briefing but not fully defined.

For SME environments, masking will require parallel investments: better merchant interfaces, alternative identifiers, and scalable verification mechanisms that do not rely on exposing raw phone numbers. It may also require rethinking the role of SMS itself, shifting from a primary record to a notification layer backed by richer digital tools.

Until then, the privacy gap remains a transitional state.

P2P demonstrates what a minimized data environment looks like in practice: limited exposure, user-controlled disclosure, and reduced risk surface. Extending that model to the commercial side of M-PESA is not just a technical upgrade. It is a redesign of how businesses see and use customer identity in a system that was originally built on full visibility.

The rollout has started. The system is not yet consistent.