M-Pesa phone numbers are personal data

A successful Lipa na M-Pesa transaction produces a callback to your server containing the transaction identifiers you expected and two things most integrations do not think about carefully: the customer mobile number and, depending on the endpoint, a name from Safaricom’s KYC record.

Both go straight into a database in almost every integration, usually into the same row as the amount and the reference, because that is the convenient shape for a reconciliation query. That single design decision is the point at which an engineering task becomes a compliance one.

The Data Protection Act, 2019 came into force in November 2019 and gives effect to the privacy right in Article 31 of the Constitution. If you determine why and how personal data is processed, you are a data controller, and controllers have duties that do not wait for scale.

In practice, for a business storing M-Pesa transactions, that means four things. Registration with the Office of the Data Protection Commissioner where the thresholds apply. A lawful basis for processing, which for transaction records is usually contractual necessity rather than consent, and knowing which one you are relying on matters because they carry different rights. A published privacy notice that describes what you actually do rather than a template. And a retention period that somebody decided, rather than the default of forever that a database gives you for free.

In March 2026 the Central Bank of Kenya approved masking of customer phone numbers in Lipa na M-Pesa Till and Paybill transactions. The immediate effect is on what merchants can see. The signal is broader: the regulatory expectation is moving toward merchants holding less identifying data by default, not more.

If your reconciliation logic depends on a full MSISDN being visible in a merchant statement, that is now a design assumption with a shelf life. Build against the transaction identifiers, which are stable and are not personal data, and treat the phone number as something you hold because you need it rather than because it arrived.

Separate the transaction record from the person record. The transaction needs an amount, a reference, a timestamp and Safaricom’s identifiers. It does not need a phone number embedded in it. Link to a customer record instead, so that deleting or restricting one person does not mean surgery on your financial history.

Do not log callbacks verbatim. The most common leak in Kenyan integrations is not a database breach, it is an application log containing raw callback bodies, shipped to a third-party log service, retained for ninety days, and readable by anyone with dashboard access. Redact the MSISDN and the KYC name at the logging boundary.

Write down the retention period and enforce it in code. A cron job that deletes or anonymises customer records after the retention period is a few hours of work and is the difference between a policy and a claim.

Check where the data physically sits. Cross-border transfer has its own requirements, and a default managed database in a European or American region is a transfer whether or not anyone framed it that way.

This is groundwork, not legal advice, and the distinction is not a disclaimer. Registration thresholds, whether your specific processing needs a data protection impact assessment, and the correct lawful basis for your particular model are questions for a qualified advocate.

What engineering can do is arrive at that conversation with the processing already mapped: what is collected, from where, on what basis, held for how long, and in which jurisdiction. That makes the legal engagement shorter and considerably cheaper, and it is work nobody else can do for you.