Kenya's Data Protection Act for Data Scientists

McTaba runs coding and data bootcamps in Kenya. This guide is written to be useful whether or not you ever join one.

Picture a client sending you an export of 50,000 M-Pesa payments for analysis. Each row has a phone number, a name, an amount and a timestamp. You want to build a model. Every one of those rows is a real person's money trail.

This guide covers two things. First, what the law says about handling that file. Second, how to strip it down in pandas so your analysis can go ahead with less risk. It is general information and not legal advice. Ask a lawyer or the regulator about your own case.

It does not repeat the full compliance walk-through in our Data Protection Act guide for AI builders. Read that for registration, rights and fines. For where this skill fits in a career, see the data science career guide for Kenya.

The Data Protection Act, 2019 is on Kenya Law. The Office of the Data Protection Commissioner (ODPC) publishes guidance and the Act's text at odpc.go.ke. Section numbers below were checked on 3 November 2026 against a published copy of the Act, so confirm them on Kenya Law before you quote them.

• Personal data (section 2). Any information relating to an identified or identifiable natural person. A phone number plus a timestamp can identify someone. So can a rare amount at a small shop.
• Anonymisation (section 2). The removal of personal identifiers from personal data so that the data subject is no longer identifiable. If this truly holds, the data stops being personal data in practice.
• Pseudonymisation (section 2). Processing personal data so it can no longer be attributed to a specific person without additional information, which must be kept separately and protected. The data is still personal, because the key exists.
• Principles (section 25). Among them: collect for a specified purpose, keep only what you need (data minimisation), keep it accurate, and store it no longer than necessary.
• Data protection by design and by default (section 41). Build safeguards in from the start. Pseudonymisation is named as one such measure. By default, process only what each purpose needs.
• Impact assessment (section 31). Where processing is likely to carry high risk to people's rights and freedoms, an assessment comes first.
• Transfers abroad (sections 48 and 49). Moving personal data out of Kenya needs safeguards, and sensitive data needs the subject's consent too. Uploading a raw file to a foreign cloud notebook counts.

Two lessons for a data scientist. Hashing a phone number is pseudonymisation, not anonymisation, so the Act still applies. And minimising early, by dropping columns you do not need, is the cheapest compliance step there is.

If you want to learn to work with such data responsibly, our Data Science programme in Nairobi builds its projects on M-Pesa style data.

For example, imagine a made-up file called payments.csv with the columns phone, name, amount, timestamp and till_area. None of it is real. The steps are in order of how much each reduces risk.

Step 1: drop what you do not need

import pandas as pd

df = pd.read_csv("payments.csv")
df = df.drop(columns=["name"])   # you never model on names

Step 2: replace phone numbers with a salted hash

A plain hash of a Kenyan phone number is easy to reverse. The list of possible numbers is short enough that an attacker can hash every one of them. A secret salt (a random string you keep outside the dataset) blocks that.

import hmac, hashlib, os

SALT = os.environ["PHONE_SALT"].encode()   # keep out of the repo

def pseudonym(phone):
    return hmac.new(SALT, str(phone).encode(), hashlib.sha256).hexdigest()[:16]

df["customer_id"] = df["phone"].map(pseudonym)
df = df.drop(columns=["phone"])

The same phone always maps to the same customer_id, so you can still count repeat customers. Store the salt separately and restrict who can read it. This is the "additional information, kept separately" the Act's definition talks about.

Step 3: generalise

Exact timestamps and exact amounts make people findable. Coarsen them.

df["timestamp"] = pd.to_datetime(df["timestamp"])
df["hour_band"] = df["timestamp"].dt.floor("3h")
df["day"] = df["timestamp"].dt.date
df["amount_band"] = pd.cut(
    df["amount"],
    bins=[0, 100, 500, 1000, 5000, 20000, 150000],
)
df = df.drop(columns=["timestamp", "amount"])

You lose precision, so ask what the analysis needs. A fraud model may need exact amounts. A footfall study does not. Decide per purpose, not once for all.

k-anonymity is a simple test. Choose the columns someone could combine to pick out a person, called quasi-identifiers. Here: till_area, day and amount_band. Every combination should appear at least k times, often 5. A combination that appears once is a person who can be found.

quasi = ["till_area", "day", "amount_band"]
sizes = df.groupby(quasi, observed=True).size()
print("smallest group:", sizes.min())
risky = sizes[sizes < 5]
print(len(risky), "combinations appear fewer than 5 times")

If risky combinations exist, generalise more (weekly instead of daily, wider amount bands, bigger areas) or drop those rows. Run the check again until the smallest group reaches your k.

Know the limits. k-anonymity does not stop someone who already knows facts about a target, and a very rare event, such as one large payment at a small stage, can still stand out. For data you will publish, take advice. For data you only analyse inside your team, pseudonymisation plus minimisation plus access control is a sensible baseline.

The same habits belong in the team data quality checklist, where "what is personal" is one of four governance lines. For the full analysis workflow on a statement, see analysing an M-Pesa statement in Python.

• Ask for the smallest extract that answers the question, not the full database.
• Do the anonymising inside the client's environment where you can, then export.
• Keep the salt and any lookup file away from the analysis folder and out of Git.
• Do not paste raw rows into public chatbots or foreign notebooks.
• Write down what you removed and why. A short note beats a long memory.
• When you only need practice data, use Kenyan open datasets instead of anyone's real payments.

Our Data Science programme in Nairobi teaches these habits next to the models, because a model built on data you were not allowed to hold helps nobody.