Safaricom’s M-PESA Jumbe tackles a privacy problem hidden in payment confirmations

A new M-PESA confirmation format called Jumbe could make it easier for customers to share proof of payment without exposing sensitive account information. A notification reviewed by TechTrends via Wamathai shows a KSh1,800 payment to a Till number presented through a sanitised confirmation containing the transaction code, amount, merchant identifier, date and time, while leaving out information such as the customer’s M-PESA balance, full phone number and other identifying details.

The distinction is important because payment proof is often shared far beyond the person who receives the money. A customer may forward an M-PESA message to a seller, delivery rider, landlord, colleague or WhatsApp group to confirm that a payment has been made. The conventional confirmation can carry more information than that person needs to establish whether the transaction happened.

Jumbe appears designed to separate those two functions. The customer still gets evidence that money moved, but the confirmation can be shared without turning the message into a disclosure of unrelated account information. In the example reviewed, the transaction reference UJ30B8MY6N remains visible alongside the KSh1,800 amount, Till number 3296173, date and time, and a Jumbe ID.

That makes the transaction code particularly important. Earlier TechTrends reporting on M-PESA’s privacy changes found that as phone numbers and other identifying information become less visible, the transaction reference takes on a larger role in establishing that a payment actually occurred.

M-PESA’s privacy work has been moving in the same direction

Jumbe fits into a broader privacy programme at Safaricom rather than appearing as an isolated change to the M-PESA SMS experience.

In March, Safaricom began rolling out data minimisation for peer-to-peer M-PESA transfers, masking parts of customers’ phone numbers and reducing the amount of personal information displayed in transaction notifications. The company also introduced a mechanism through which fuller identity information could be disclosed when a customer approves a verification request. TechTrends reported at the time that merchant payments were on a separate rollout path because Buy Goods and PayBill transactions have more complicated operational requirements.

That distinction matters because a merchant payment is rarely just a notification. Businesses can use transaction information to reconcile sales, resolve payment disputes and connect a customer’s payment to an order. Large businesses may have APIs and dedicated systems for doing that, while smaller merchants can depend heavily on the SMS alert arriving on their phone.

Safaricom therefore has to reduce unnecessary personal-data exposure without making it harder for merchants to establish that a customer actually paid. The company has previously described customer privacy as a priority and says it safeguards customer data in line with its obligations and applicable law.

Jumbe offers an interesting way around part of that problem because it changes what the customer receives when they need to prove payment. Instead of requiring the payment recipient to see more personal information simply because the customer needs a receipt, the receipt itself can contain the information necessary for verification.

The balance problem is bigger than phone-number masking

There is a subtle difference between hiding a phone number and protecting a payment confirmation.

Number masking limits what the person receiving money can learn about the sender. A sanitised receipt addresses what happens after the transaction, when the customer decides to show somebody else that the payment took place.

That second situation is easy to overlook. A customer might pay a business and then send a screenshot to a third party. If the screenshot includes the M-PESA account balance, the customer has disclosed financial information that has nothing to do with the payment being verified.

This is where a format such as Jumbe can be useful. The payment recipient needs to know that KSh1,800 was sent to the relevant Till, together with a transaction reference that can be checked if necessary. They do not necessarily need to know whether the sender had KSh2,000, KSh20,000 or KSh200,000 remaining in the wallet.

The principle is straightforward: proof of payment should contain enough information to prove the payment, rather than enough information to expose the account.

That distinction becomes more important as M-PESA is used across more commercial settings. TechTrends previously reported that business payments had become a major component of Safaricom’s M-PESA business, while Pochi la Biashara had grown from 600,000 users in the 2024 financial year to 1.1 million and then 2.2 million in the following financial year.

Pochi la Biashara should be part of the conversation

This is where Safaricom could take the Jumbe concept further.

If the current pilot covers Till and PayBill payments, Pochi la Biashara should also be included in the privacy-preserving payment-proof experience.

Pochi is not a marginal product within the M-PESA ecosystem. TechTrends reported in May that its customer base had reached 2.2 million, while a separate GSMA-backed study reported that women accounted for just over 52% of active Pochi users at the end of 2025, representing more than 900,000 women merchants.

The product also has a particularly relevant privacy history. Pochi was built around separating a merchant’s business activity from their personal mobile identity. TechTrends’ March analysis of M-PESA data minimisation noted that Pochi had an advantage because that separation was incorporated into the product rather than being retrofitted into an older payment flow.

Extending Jumbe to Pochi would therefore make the privacy model more consistent across M-PESA’s merchant ecosystem. A customer paying a shop through a Till, settling a bill through PayBill or buying from a small trader using Pochi should not have to think about three different rules when deciding whether a payment confirmation is safe to share.

There is also a practical reason to make that coverage broad. Pochi is used heavily by micro and small businesses, where payment records can be closely tied to everyday commercial activity. The GSMA-backed research cited by TechTrends found that women entrepreneurs use Pochi to separate business income from household spending, keep clearer records and gain better visibility into daily cash flow.

Protecting the customer’s information on the other side of those transactions is part of the same data-minimisation principle.

The transaction code becomes more important

A privacy-friendly receipt also changes the role of the transaction code.

For much of M-PESA’s history, a payment confirmation combined several functions. It identified the sender, identified the recipient, recorded the amount and provided a transaction reference. The phone number was particularly useful because it gave merchants and customers a familiar way to identify who had paid.

As Safaricom reduces the amount of personal information displayed, the transaction reference becomes a cleaner piece of evidence. TechTrends reported in March that transaction codes were taking on a larger role as M-PESA reduced reliance on phone numbers as public identifiers.

Jumbe takes that logic into the act of sharing a receipt. The example reviewed retains the transaction code while stripping away information that is unnecessary for the person receiving the proof.

That is a useful design choice because the two needs do not have to compete. A merchant can have a reference for reconciliation, while a customer can have a receipt that does not expose their financial position.

Safaricom has an opportunity to make privacy the default

The broader M-PESA privacy programme will ultimately be judged by how consistently the principle works across different transaction types.

Safaricom has already shown that it can mask customer identifiers in P2P payments and introduce controlled disclosure where verification requires more information. Its merchant-payment roadmap has to account for the operational needs of businesses, particularly those that still depend on SMS notifications.

Jumbe approaches the problem from another direction. Rather than asking what information a merchant should receive, it asks what information a customer actually needs to expose when sharing payment proof.

That is a useful distinction.

If the Jumbe format proves reliable, extending it across Till, PayBill and Pochi would give M-PESA customers a consistent way to prove that they have paid without turning a routine receipt into a snapshot of their wallet.

For Safaricom, the opportunity is to make that privacy model broad enough that customers do not have to remember which type of M-PESA payment produces a safe-to-share confirmation and which one does not.

The simplest payment receipt may ultimately be the one that says exactly what happened, provides enough information to verify it, and leaves everything else private.

Real ESG impact doesn’t happen in panels alone, it happens in the rooms where financiers, operators, and policymakers actually align. Our GreenShift Forum 2026 cuts the noise, bringing together the people rewiring Africa’s sustainability and energy frameworks for one focused day in Nairobi. Secure your seat.

Go to TECHTRENDSKE.co.ke for more tech and business news from the African continent and across the world.

Follow us on WhatsApp, Telegram, Twitter, and Facebook, or subscribe to our weekly newsletter to ensure you don’t miss out on any future updates. Send tips to info@techtrendsmedia.co.ke