On Monday, March 24, M-PESA begins masking sender phone numbers in peer-to-peer transactions. A number like 0722 000 712 will now arrive as 0722***712 in the receiving party’s SMS alert. By late 2026, Safaricom will extend the same treatment to merchant payments — Buy Goods tills, Paybill — and to bank transfers. The full phone number will disappear from the data layer entirely. M-PESA processes 137.9 million transactions daily, worth KES 118 billion ($914 million). The 37 million daily P2P transactions alone represent KES 27 billion. This is not a minor interface update.
When Safaricom announced the change, it framed it as a privacy upgrade. The merchant ecosystem heard something more disruptive: the removal of East Africa’s most widely used informal identity signal. For nearly two decades, a customer’s M-PESA phone number has functioned as far more than a payment identifier. It has been the connective tissue between mobile money and the broader fintech stack — the data point that let merchants reconcile transactions, PSPs build fraud models, and lenders cross-reference loan applicants against payment histories. Stripping full-number visibility from the merchant data layer does not just raise a technical integration challenge. It forces a reckoning with how much of East African fintech’s KYC infrastructure was built on a foundation that Safaricom never formally endorsed as an identity layer.
The Fraud Vectors It Closes
Beyond the compliance framing, the masking resolves three persistent fraud patterns that have exploited M-PESA phone number visibility for years.
SIM swap fraud requires the attacker to first obtain a target’s phone number. M-PESA transaction receipts — forwarded screenshots, merchant payment displays, paper printouts — have served as reliable number-harvesting vectors in documented SIM swap attacks. An attacker who intercepts a receipt has the number they need to impersonate the account holder at a mobile carrier.
Social engineering fraud uses visible phone numbers to impersonate known contacts. A fraudster who captures a legitimate M-PESA transaction receipt can use the visible sender number to spoof a follow-up message — appearing to come from the original payer — requesting a second transfer.
Number harvesting for phishing campaigns — systematically collecting phone numbers from merchant transaction logs or agent float reconciliation files — enables targeted bulk SMS fraud at scale. Individual merchants may not realise their records have become source data for a campaign targeting their customers.
Masking disrupts all three at the data layer, before any of the downstream attack steps can run. By ensuring the full number is never casually visible in the transaction stream, Safaricom removes an exposure category that user education alone cannot fully address.
The Merchant KYC Problem
In Kenya’s informal and semi-formal merchant economy, M-PESA phone numbers have served as a de facto customer identifier for years. A micro-merchant receiving a payment could verify a repeat customer by recognising their number. A small e-commerce operator could match an M-PESA confirmation against a customer database using the phone number as the join key. A credit provider embedded in a merchant’s checkout flow could initiate a soft credit pull using the same number.
None of this was Safaricom policy. All of it happened because M-PESA’s payment confirmation delivered a full phone number in a world where formal identity infrastructure was expensive, patchy, and rarely integrated.
“The phone number was our KYC shortcut,” said a Nairobi-based product lead at a payments-as-a-service company serving small businesses, speaking on condition of anonymity. “Not ideal, but it worked at scale. We now need to rebuild the verification layer properly — which honestly we should have done years ago.”
That rebuilding process is already underway at fintechs with the engineering capacity to move quickly. For smaller merchants and long-tail PSP integrations, the adjustment timeline is compressed. Year-end 2026 is nine months away.
What PSPs Must Now Do
The technical remediation is manageable in principle and demanding in practice.
PSPs that use M-PESA phone numbers in fraud detection models need to replace or augment that signal. Phone number visibility in transaction data has supported rule-based fraud logic: flagging unusual numbers, detecting velocity patterns against known accounts, cross-referencing against blocklists. Masked or withheld numbers break that logic unless PSPs shift to session-level tokenisation, device fingerprinting, or formal identity verification integrations.
Reconciliation systems that match inbound M-PESA payments to customer records using phone numbers as primary keys need to migrate to alternative identifiers. The technical fix is already available: Safaricom’s Daraja API delivers a unique alphanumeric transaction reference per payment on every C2B (Customer to Business) callback. That reference is unique and unambiguous. PSPs that have built reconciliation on transaction references — not phone numbers — will not be significantly affected. The more complex cases involve integrations built around personal-number confirmation flows, common in peer-to-merchant USSD and app-to-app payment flows, where the phone number was treated as the join key to a CRM or accounting system. Those need to migrate to transaction reference matching before Phase 2 lands.
Under Kenya’s Data Protection Act 2019, any merchant or PSP that currently receives full phone numbers through M-PESA is a data processor of that personal data. The change in data set — from full number to masked or omitted — technically amends the scope of data processing under their existing Data Protection Impact Assessments and privacy notices. Strict compliance means reviewing those documents before year-end, not after the first ODPC inquiry.
The Nigeria Contrast: Regulation vs. Corporate Action
The contrast with Nigeria’s approach to mobile money fraud reduction is instructive. Nigeria’s Central Bank drove change through mandate: the March 2026 liveness check directive requires every account opening to include real-time biometric verification against BVN and NIN databases, with a ₦20,000 device-activation transaction cap enforced at the infrastructure layer. The compliance burden lands simultaneously on every licensed institution; implementation is mandatory by July 1, 2026.
Safaricom’s move is the inverse model: a dominant operator acting ahead of regulation to implement data minimisation voluntarily at the platform layer. No central bank directive compelled it. The motivation is partly fraud economics — Safaricom bears brand risk for every SIM swap case traced to M-PESA — and partly regulatory pre-emption, getting ahead of an ODPC enforcement trajectory that Kenya’s data protection pipeline has made visible to any compliance team reading the case docket.
The policy question this raises for East African regulators is whether dominant platform operators should be required to implement data minimisation by default, or whether Safaricom’s voluntary posture is sufficient. Given the ODPC’s enforcement ambitions for 2026 through 2029 and active parliamentary interest in strengthening Kenya’s data framework, voluntary action today does not preclude regulatory codification tomorrow. Any PSP or merchant treating Safaricom’s move as an isolated product change should be watching both tracks simultaneously.
Why This Is Also a Regulatory Signal
The timing is not coincidental. Kenya’s Office of the Data Protection Commissioner issued 184 compensation orders in January 2026 alone and has confirmed active compliance audits across the fintech and mobile money sector throughout this year. Safaricom CEO Peter Ndegwa framed the change directly at the announcement: “keeping everyone safe” justifies the operational adjustment. CFO Esther Waititu was candid about what that means for merchants: “The main risk will be dispute management. The process will require an additional step, which could introduce some friction.” Both statements are true. Safaricom is moving before it is told to move — and in doing so, it is raising the implicit compliance floor for every merchant and PSP operating on its rails.
The ODPC’s enforcement posture under Commissioner Immaculate Kassait has been consistently clear: data minimisation is not aspirational. Section 25 of the Data Protection Act requires controllers and processors to implement technical and organisational measures appropriate to the data being processed. A company that processes full phone numbers when masked numbers would serve the same purpose faces an explainability problem if the regulator comes knocking.
Safaricom’s decision resolves that problem for itself. It simultaneously creates it for every downstream merchant and PSP that has been coasting on the assumption that M-PESA’s data-sharing defaults were someone else’s compliance problem.
The Broader Implication: Identity Infrastructure Cannot Be an Accident
What the M-PESA phone number change exposes — more than a specific technical integration challenge — is the fragility of informal identity infrastructure in African fintech.
The most sophisticated actors in Kenya’s merchant ecosystem built identity and verification flows that do not depend on payment-layer phone numbers. They integrated directly with IPRS (Integrated Population Registration Service), built biometric verification into their KYC flows, or used third-party identity APIs layered on top of NIIMS data. Those integrations are unaffected by this change.
The multi-market dimension compounds the challenge. Safaricom operates M-PESA across seven markets, each with a different data protection regime. Tanzania’s Personal Data Protection Act 2022 carries a data minimisation principle analogous to Kenya’s — a uniform group rollout would represent standard compliance. Ethiopia has no comprehensive data protection framework in force. DRC’s data regime is nascent. Egypt’s Personal Data Protection Law (2020) is enforced by the Personal Data Protection Centre, which has been active in issuing guidance. Mozambique and Lesotho sit closer to the regulatory frontier, with limited enforcement infrastructure. A Safaricom group-wide rollout applying Kenyan-standard data minimisation across markets where the regulatory floor is lower would represent a responsible data governance posture — and one that would give M-PESA’s cross-border product a compliance baseline ahead of several host-country regulators. Whether the rollout will be uniform or phased by market has not been confirmed.
Airtel Money, which competes directly with M-PESA across East and Central Africa, faces implicit pressure from the same logic: if full phone number exposure in transaction alerts creates a Kenya Data Protection Act liability for Safaricom, it creates a comparable exposure for any mobile money operator on the same regulatory terrain. The data minimisation standard Safaricom is setting voluntarily in Kenya will not stay voluntary indefinitely.
The actors who will feel it most are those who treated M-PESA phone number visibility as a permanent feature rather than a platform convenience. In that respect, Safaricom’s decision is not just a data governance update — it is a maturity test for the East African merchant fintech stack.
PSPs and merchants that use this transition to build proper identity infrastructure will emerge with more resilient compliance postures and better fraud models. Those that wait for the year-end deadline without planning will find themselves simultaneously managing a technical migration and an ODPC enquiry they were not ready for.
Phase 1 of that deadline is Monday. Phase 2 is nine months away. That is enough time to act. It is not enough time to delay.
— Technology Desk, BETAR.africa
