By For 18 years, paying with M-Pesa at a till or paybill meant handing over two things: your money and your phone number. The merchant received a confirmation SMS showing your full name and complete mobile number, automatically, with no option to withhold it. That data did not stay in the transaction, it went into WhatsApp marketing lists, spam databases, and in the worst cases, social engineering scripts used to defraud you later.
The Central Bank of Kenya approved a fix for this on February 27. Safaricom will now mask customer phone numbers across M-Pesa peer-to-peer transfers, Lipa na M-Pesa Till payments, and Paybill transactions. Merchants will still receive payment notifications, but instead of seeing 0722 123 456 they will see 0722XXXXXX. Your first name stays visible. Your money arrives. Your full contact details do not.
It is a good change. It is also long overdue, the Data Protection Act 2019 has been in force for six years, and M-Pesa has been non-compliant with its data minimisation principles for all of them. But the implementation raises practical questions that the announcement did not fully answer, particularly for the millions of small merchants and the developers building M-Pesa integrations who need to understand exactly what changes and what does not.
What Is Actually Changing
The masking works differently depending on what type of transaction you are making.
Peer-to-peer transfers— sending money directly from your M-Pesa to another person's M-Pesa, will partially mask your number in the recipient's confirmation SMS. If the recipient wants to see your full number, they can request it, and you get to decide whether to consent or decline. This is a meaningful privacy control. Previously, anyone you sent money to automatically had your number. Now you have a choice.
Lipa na M-Pesa Till and Paybill payments — the transactions most Kenyans make dozens of times a week at supermarkets, fuel stations, restaurants, and utility payments, will mask both your full name and phone number from the merchant's confirmation. The merchant sees that a payment arrived, the amount, and a partial number. That is enough to confirm the transaction. It is not enough to build a marketing database or hand off to a scammer.
Pochi la Biashara already had this protection. Safaricom piloted number masking through Pochi ( its small trader-focused product ) years ago, which is why mama mboga transactions have felt slightly different from supermarket till payments for anyone who noticed. This approval brings the rest of M-Pesa's merchant ecosystem up to that standard.
The CBK has also directed Safaricom to run extensive consumer education before the rollout goes live, monitor feedback, address complaints, and submit monthly reports to the regulator. A specific rollout date has not been publicly announced.
Why This Took Six Years
The Data Protection Act 2019 required data minimisation (collecting only what is strictly necessary) from the moment it came into force. A payment transaction strictly requires the amount, a timestamp, and a reference number. It does not require the payer's full name and mobile number. By that standard, M-Pesa has been operating outside the spirit of the Act since 2019.
Part of the delay is structural. The Communications Authority, not the CBK, regulates the telecommunications side of M-Pesa. Safaricom had already developed the number masking feature for merchant transactions. They built it, tested it with Pochi la Biashara, and were ready to deploy. But the CA's regulatory framework had not been updated to permit it for general M-Pesa transactions, creating a gap between what Safaricom could technically do and what it was permitted to do.
The CBK approval granted last month covers the payments side, P2P transfers and Lipa na M-Pesa transactions that flow through the National Payment System. The CA still needs to update its framework to permit full rollout across all M-Pesa use cases. This is why the announcement specifies CBK approval but does not confirm a full deployment date, the regulatory picture is not entirely complete.
The broader context is also worth noting. In 2025, the Directorate of Criminal Investigations arrested six cybercrime suspects in Mombasa running a scamming operation that relied heavily on harvested M-Pesa phone numbers. The pipeline from till payment to fraud attempt is not theoretical. It has been documented, prosecuted, and is still active. This feature closes one of the most exploited data leakage points in Kenya's mobile money ecosystem.
The "Nionyeshe" Dilemma: Proof vs. Privacy
This is where the practical disruption lands. The familiar ritual ("nionyeshe confirmation") is facing a forced evolution, but not for the reasons many think.
For 18 years, the informal verification standard for M-Pesa has been the customer’s phone. A customer pays at a till or Paybill, and the merchant asks to see the SMS. The problem isn't usually that the merchant needs to "verify the name"; the problem is that the merchant often doesn't have the phone that receives the payment notification. Whether it’s a mama mboga whose business phone is at home or a supermarket cashier waiting for a delayed system hit, the customer’s SMS is the only immediate proof of payment.
The Privacy Penalty
While "nionyeshe" solves the merchant's verification gap, it creates a massive privacy hole for the customer. Showing a confirmation message almost always means exposing your M-Pesa balance. In a busy queue or at a high-traffic stall, this "proof of payment" forces Kenyans to reveal their financial standing to strangers just to complete a transaction.
Why the System is Straining
With the move toward number masking and stricter data privacy, the "nionyeshe" ritual becomes even more problematic:
Masked Identity: Even if the merchant looks at your phone, if the data is masked, they lose the ability to cross-reference the sender with the person standing there, making the "proof" less reliable for them.
Security Risks: Forcing customers to show their screens is a practice the Office of the Data Protection Commissioner is actively discouraging to prevent social engineering and data theft.
What Merchants Must Do Differently
To move away from peering at customers' balances for proof, Safaricom and the ODPC are pushing for tools that put the "proof" back into the merchant's hands:
M-Pesa Business App: Real-time push notifications for the person actually running the till. It’s the cleanest way to see a transaction without asking the customer for a thing.
The *334# USSD Fallback: For the "non-smartphone" duka owner, dialing the USSD code is the official way to check the latest transactions on the business side without needing the customer to reveal their screen.
Daraja API Integration: For larger retailers, the payment should hit the POS system instantly, removing the human element entirely.
The Question Nobody Has Answered: What Does the Developer API Return?
When a customer makes an M-Pesa payment on a merchant's website or app using the Daraja STK Push API, Safaricom sends a callback to the merchant's server with the transaction details. That callback currently includes the customer's full phone number in the JSON payload , it is what merchants use to identify which customer made which payment and update their order or account records accordingly.
The masking approved by the CBK applies to the confirmation SMS the customer receives and the notification the merchant sees on their business app. What has not been publicly confirmed is whether Safaricom will also mask the phone number in the Daraja API callback sent to merchant backends.
If the answer is no ( if the full number still arrives in the callback even while being masked in the SMS ) then the privacy protection is partially cosmetic. Merchants integrating directly via the API, including any operator who builds their own payment system, would still receive and potentially store the full number server-side. The spam and fraud risk would not be eliminated, just shifted from the SMS layer to the database layer.
If the answer is yes ( if Safaricom masks the number at the API level too ) then merchants will need to update how they identify returning customers and match payments to accounts, since the phone number has historically been the primary identifier in M-Pesa integrations.
Safaricom has not addressed this publicly. Developers building on Daraja should watch the API changelog and the developer forum closely as the rollout approaches. This is the implementation detail that matters most for anyone running M-Pesa on the backend.
What This Means for You as a Consumer
If you use M-Pesa to pay at merchants (which covers virtually every adult Kenyan) the change is straightforwardly positive with one adjustment.
You will stop receiving unsolicited marketing messages from merchants after transactions, at least from the merchants who were harvesting your number from M-Pesa confirmations directly. You will face less exposure to social engineering attacks that start with a scammer who knows your M-Pesa number from a transaction record. Your data will travel with your money only as far as it needs to, to confirm the payment, not further.
For peer-to-peer transfers specifically, the consent model for full number sharing is a meaningful new control. You can send money to someone without automatically giving them your contact details. For people who use M-Pesa to pay individuals they do not know well ( splitting a bill with a new acquaintance, paying a freelancer for the first time) that control matters.
The Bigger Picture
Kenya's mobile money system has been a global benchmark for financial inclusion for nearly two decades. But the architecture that made M-Pesa remarkable in 2007 ( simple, transparent, identity-anchored) was designed before data privacy was a regulatory concern anywhere in the world, let alone in Kenya.
Number masking is a small technical change. What it represents is larger: the beginning of a serious attempt to retrofit modern data protection principles onto infrastructure that was never built with them in mind. The Data Protection Act 2019 was the legal mandate. The ODPC has been gradually enforcing it. The CBK's approval is the payments regulator catching up with a standard that the law set six years ago.
The next step, and one that consumer advocates and privacy researchers have flagged, is the CA updating its framework to permit full rollout and closing the gap that currently prevents Safaricom from deploying the merchant masking feature without regulatory ambiguity. Once that happens, M-Pesa will for the first time operate as a payment system where your identity travels only as far as the transaction requires. In a country where mobile money is effectively the financial nervous system, that is a more significant upgrade than it sounds.
Comments