By As of yesterday, March 24, 2026, M-Pesa no longer shows a sender's full phone number when you receive money. Where you used to see 0722 000 712, you now see 0722***712. The middle three digits are gone, replaced by asterisks, and only two names are displayed instead of the previous three.
That single change ( masking three characters in an SMS ) touches 37 million person-to-person transactions every day, worth Ksh 27 billion, processed by 14.1 million daily active users. It is the most visible privacy change M-Pesa has made since launch in 2007, and it has been building for six years.
For most Kenyans who send money to friends and family, the practical impact is minimal. The amount, date, and reference number are all still there. You know someone called John Mwangi sent you Ksh 500. What you no longer know automatically is whether that John Mwangi is the one you know because you cannot see the full number to verify. For everyday P2P use, that is a reasonable trade-off for privacy. For merchants, schools, landlords, and small business owners using M-Pesa SMS as their accounting system, it is a more complicated adjustment.
What Exactly Changed Yesterday
What you see now for a P2P transaction:
UCOJQ9ZECD Confirmed.You have received Ksh500.00 from John Mwangi 0722***712 on 24/3/26 at 12:20 PM New M-PESA balance is Ksh5,351.50. To view the Full Number, forward this message to 334.
What you used to see:
> UCOJQ9ZECD Confirmed.You have received Ksh500.00 from John Kamau Mwangi 0722000712 on 24/3/26 at 12:20 PM New M-PESA balance is Ksh5,351.50. To view the Full Number, forward this message to 334
Three things changed in that SMS:
The full phone number 0722 000 712 is now 0722***712 — middle three digits masked
Three names are now reduced to two names — first and last, with no option to choose which two are shown
The masking now applies to Paybill and Buy Goods SMS notifications for small merchants too, not just P2P transfers
What did not change: the transaction amount, the M-Pesa reference number, the date and time, and your running balance. The financial record of the transaction is complete. Only the sender's identity has been partially obscured.
Why This Happened Now, The Six-Year Context
This did not come from nowhere. Safaricom has been building toward full data minimisation across M-Pesa since 2020, in phases timed to avoid disrupting the platform all at once.
Pochi la Biashara launched in 2020 with number masking built in from the start. Internal staff data viewing was restricted in 2021. M-Pesa statement data was minimised in 2022. Large organisations integrated directly to M-Pesa's Buy Goods and C2B APIs had masking applied in 2023 and 2024. The March 24 rollout closes the last two remaining gaps, P2P transactions and SMS notifications to SME merchants.
The CBK approved the expansion of masking to include merchant payments and P2P, framing it as alignment with the Data Protection Act 2019. The timing also reflects a specific problem that has grown alongside M-Pesa's scale.
Customers have reported receiving unsolicited calls, being contacted after making payments, and exposure to potential scams. Every time a Kenyan sent money to a till or Paybill, their full phone number appeared in the merchant's notification SMS, accessible to the cashier, the business owner, and anyone else who handled that device. At 137.9 million daily transactions, that is an enormous daily harvest of phone numbers flowing into the hands of people who did not need them for any legitimate business purpose. A fraudster could see that someone paid Ksh 1,000, but without the phone number, they cannot reach them.
The Three Groups This Affects Differently
Everyday Users — Minimal Friction, Real Privacy Gain
If you primarily use M-Pesa to send money to friends, family, or pay personal bills, the change is largely positive with minimal disruption.
The masked number still contains enough information to identify the sender in most real-world scenarios — the first and last digits of the number are visible, two names are shown, and the reference number ties the transaction to a specific M-Pesa account in Safaricom's internal records. If you genuinely need to know who sent you money and the two names plus partial number are not enough, the 334 verification system provides a path.
The privacy gain is concrete. Your number is no longer broadcast to every till operator, Paybill recipient, and business whose number you pay. The unsolicited marketing calls that followed transactions ( "I saw you paid at our shop, would you like our loyalty card?") lose their data source.
Small Merchants and SMEs — The Reconciliation Challenge
For millions of Kenyan SMEs, the M-Pesa SMS is the accounting system. Schools use the phone number to match fees to students; landlords use it to match rent to tenants; water companies use it to credit accounts.
This is where the change creates real operational friction. A school bursar who receives 200 Paybill payments on fee deadline day and cross-references each sender's full phone number against the student database now has a masked number for each transaction. The reference number remains visible, if parents have been disciplined about using their child's admission number as the Paybill account reference, reconciliation is unaffected. If they have not (if the account reference field has been left blank or filled with random text, as is common ) the bursar now has less identifying information per transaction than before.
Landlords, water companies, chama treasurers, and any business relying on phone number matching for manual reconciliation face the same challenge. The answer Safaricom is implicitly pushing here is adoption of formal merchant tools (the M-Pesa Business App, integrated POS systems, and the C2B API ) all of which provide more structured transaction data than SMS parsing. Safaricom is essentially forcing the entire economy to move from checking their messages to using formal merchant tools. It is a subtle push toward digital formalisation.
That push is legitimate in direction. It is genuinely better for businesses to use structured payment data than to parse SMS messages manually. But the transition is not instantaneous and the merchants who have the least capacity to adopt new systems are exactly the ones most disrupted by the change.
The 334 Workaround — How It Works
For situations where a recipient genuinely needs a sender's full details, Safaricom has built a structured verification process:
1. Forward the transaction SMS to 334
2. Safaricom sends a request to the sender asking if they consent to sharing their full name and phone number
3. The sender has two hours to respond, approve or decline
4. If approved, you receive the full details by return message
5. If declined, you are notified of their decision
6. If the sender does not respond within two hours, the request automatically expires
The verification request will be limited to one attempt per transaction and will remain valid for 24 hours.
This is a consent-based system, which is the correct privacy design. The sender retains control, their details are only shared if they actively choose to share them. The limitation is the friction it introduces for dispute resolution. A merchant whose customer claims they sent money to the wrong till, or a landlord whose tenant denies sending rent, now needs the sender's voluntary cooperation to confirm the transaction independently. Whether internal Safaricom dispute channels ( customer care, the M-Pesa app dispute function ) still provide access to full transaction details for formal complaints is a question merchants should confirm directly with Safaricom.
What Is Coming Next: The 2026 Roadmap
Yesterday's rollout is not the final state. In a phased rollout starting with P2P transfers and expanding to merchant payments and bank transfers by late 2026, full phone numbers will not be visible across any M-Pesa channel.
The remaining phases:
Bank transfer notifications — masking applied to SMS confirmations from bank-to-M-Pesa and M-Pesa-to-bank transfers
Full merchant payment coverage — extending beyond the SME tier covered yesterday to all merchant categories
By the end of 2026, phone number masking will apply across every M-Pesa transaction type. The full number will exist only in Safaricom's internal records and in formal dispute resolution channels, not in the SMS that lands on a merchant's or recipient's phone.
The Developer Question: What Happens to the Daraja API?
We flagged this question in our Daraja C2B integration guide when the masking was first approved by CBK in February: does the M-Pesa callback to the Daraja API still return the full phone number, or does masking apply at the API layer too?
Based on current developer community reports and Safaricom's phased implementation approach, the `MSISDN` field in C2B and STK Push API callbacks continues to return the full phone number. The masking is being applied at the SMS notification layer ( what the recipient sees in their message ) not at the API data layer that businesses use for backend processing.
This is the correct implementation approach. A business receiving a payment through a Daraja C2B callback needs the full phone number to identify the customer, match the transaction to an account, and process the order. Masking the API response would break every M-Pesa integration in Kenya. The privacy concern that masking addresses ( the SMS being visible to anyone who handles the recipient's device ) does not apply to a server-to-server API callback.
That said, this should be confirmed with testing in your own integration. The safest position for any developer relying on `MSISDN` in API callbacks is to verify the field returns a full number in your next live test transaction, and to monitor Safaricom's developer changelog for any announced changes to the API data schema.
The Bigger Shift This Represents
Safaricom's move to mask numbers is an admission that M-Pesa has outgrown its 'village' roots. It is moving from a system based on social trust, I know your number, therefore I trust you to systemic trust, the system says it is paid, and that is enough.
That transition is not just a privacy feature. It is a maturation of Kenya's digital payments infrastructure toward global norms. Every mature payment system (Visa, Mastercard, bank transfers )operates on systemic trust rather than social transparency. The payer's phone number or account number is not broadcast to the merchant; the transaction record in the system is the source of truth.
M-Pesa built its original trust model on social transparency because Kenya's financial infrastructure in 2007 could not support anything more sophisticated. Displaying the full phone number was a feature, it let recipients verify who sent money in a world where the reference number alone was not enough to trust. Nineteen years later, the platform processes 137 million transactions a day and that social transparency model has become a fraud vector.
The masking does not eliminate fraud, scammers already have massive databases of numbers from previous leaks, and criminals are adaptive. But it removes the daily passive harvest of fresh phone numbers that every M-Pesa transaction was providing to anyone in a position to read a notification SMS.
For Kenyan consumers, that is a reasonable trade. For businesses still reconciling manually via SMS, the adjustment period will be uncomfortable. The platform has moved, the question is how quickly the ecosystem catches up.
Are you a merchant affected by the number masking change? Share how you are handling reconciliation in the comments. Developers with questions about the Daraja API MSISDN field , drop them below and we will follow up with confirmed information.
Comments