Crypto and data protection in Kenya: the ODPC duties on a VASP

A virtual asset service provider in Kenya is a data controller under the Data Protection Act (Cap. 411C), and that single fact creates a compliance track running in parallel to the VASP licence and the anti-money-laundering registration. The bottom line: every VASP must register with the Office of the Data Protection Commissioner under section 18(1) before it processes any personal data, must handle the KYC data it is legally forced to collect in a way that satisfies the Act, must run a Data Protection Impact Assessment for high-risk processing, must lawfully manage cross-border transfers to offshore parents and vendors, and must notify the ODPC of a personal-data breach. None of this is optional, and none of it waits for the VASP Regulations to be gazetted. The Data Protection Act has been in force since 2019, the ODPC is actively enforcing, and the Worldcoin case shows how the regulator treats a crypto-adjacent business that collects sensitive data at scale without doing the groundwork first.

Short answer: a VASP’s ODPC duties at a glance

A VASP is a data controller under section 2 of the Data Protection Act (Cap. 411C), and usually also a processor.
ODPC registration is mandatory under section 18(1): no person may act as a data controller or processor without being registered with the Data Commissioner.
The KYC and CDD data a VASP must collect under POCAMLA is personal data, so the AML duty and the DPA duty apply to the same records at the same time.
Cross-border transfers to an offshore parent, exchange-engine vendor or cloud host must meet the section 48 and 49 transfer conditions.
High-risk processing (large-scale biometric or financial profiling) triggers a mandatory Data Protection Impact Assessment under section 31.
A personal-data breach must be reported to the ODPC, and to affected data subjects where there is real risk of harm, under section 43.

Is a VASP a data controller under Kenyan data protection law?

Yes. A VASP holds national IDs, passports, KRA PINs, addresses, phone numbers, transaction histories, wallet addresses, IP logs and counterparty data. Almost all of that is personal data. The Data Protection Act (Cap. 411C) defines a “data controller” in section 2 as a person who, alone or jointly with others, determines the purpose and means of processing personal data. A VASP decides why it collects KYC records and how it stores and uses them, so it is a controller. It is frequently a processor too: when it runs customer data through a third-party KYC vendor, a chain-analytics provider or a hosted exchange engine. The Act applies to both roles and section 18(1) catches both.

Section 24(i) of the VASP Act reinforces the link. It requires every VASP to ensure that the recording, storing, protecting and transmission of the data it processes is in accordance with laws in Kenya. That is a direct statutory hook from the virtual-asset regime back into the Data Protection Act. A data-protection failure is also a VASP-licence conduct failure.

For the full virtual-asset licensing framework, the dual CBK and CMA regulator model and the AML build-out that sits behind this, see the pillar on VASP licensing in Kenya.

Why must a VASP register with the ODPC under section 18(1)?

Section 18(1) of the Data Protection Act is the gateway: no person may act as a data controller or data processor without being registered with the Data Commissioner. Registration is not a formality you complete after launch. It is a precondition to lawful processing. A VASP that onboards a single customer before it is registered is processing personal data unlawfully.

This sits on top of two other registrations a Kenyan VASP already has to make:

The VASP licence with the Central Bank of Kenya or the Capital Markets Authority, depending on the activity (see the pillar).
The reporting-institution registration with the Financial Reporting Centre under POCAMLA (Cap. 59A), a separate criminal-offence-backed obligation.

So a Kenyan VASP runs three parallel registrations, with three regulators, under three statutes. The ODPC registration is the one founders most often forget, because it does not feel like “crypto regulation”. It is. The ODPC operates a tiered model and charges fees scaled by the entity’s size and turnover. The fee band and renewal cycle sit in the Data Protection (Registration of Data Controllers and Data Processors) Regulations, which are periodically revised, so confirm the live figure at the point of registration.

Registration is not a one-off. A registered controller must keep its particulars current and renew on the ODPC’s cycle, reflecting any change in the categories of data processed, the cross-border transfer destinations, or the appointed contact.

How does AML and KYC data trigger data protection duties at the same time?

This is where firms get the design wrong. POCAMLA (Cap. 59A) forces a VASP to collect identifying data: section 45 requires customer due diligence, section 44 requires ongoing transaction monitoring, and section 46 requires those records to be kept for at least seven years. Every one of those records is personal data, so the same KYC file the FRC regime makes you collect and retain is also a file the ODPC regime makes you collect lawfully, secure and eventually erase.

The two regimes pull against each other on retention: POCAMLA mandates a seven-year minimum hold, while the Data Protection Act’s principles in section 25 require data be kept no longer than necessary. The reconciliation is that the seven-year POCAMLA retention is itself the lawful basis and the necessity justification for holding KYC data that long. It is not a loophole, it is the obligation that satisfies the principle. Document it: KYC and transaction records are held for seven years because section 46 requires it, then deleted.

Practical design points that follow:

The lawful basis for KYC data is compliance with a legal obligation under section 30, not consent. The customer cannot meaningfully refuse, and you cannot delete the data on a consent withdrawal without breaching POCAMLA.
Suspicious Transaction Reports to the FRC are a lawful disclosure mandated by law, not a breach of confidence. The customer is not told (tipping-off is itself an offence).
Data minimisation still applies inside the AML envelope. Collect what CDD requires, not more. A risk-based approach justifies enhanced due diligence on higher-risk customers; it does not justify hoarding documents you have no reason to hold.

For the full anti-money-laundering picture, including the FRC registration, the goAML portal and the reporting thresholds, see Crypto AML and KYC in Kenya.

What are the rules on cross-border transfers to offshore parents and vendors?

Most Kenyan VASPs are not standalone. They are subsidiaries of a foreign exchange group, run on infrastructure hosted outside Kenya, or push KYC documents to a verification vendor abroad. Every one of those flows is a cross-border transfer of personal data, and the Data Protection Act regulates it directly.

Sections 48 and 49 govern transfers outside Kenya. A transfer is permitted where the controller has given the data subject the relevant information and one of the lawful conditions is met: appropriate safeguards, necessity for the performance of a contract, or the data subject’s consent, among the recognised grounds. The controller must also be able to demonstrate that the destination ensures an adequate level of protection.

What this means in practice:

A flow of KYC data to a foreign parent for group compliance needs a documented transfer basis and an intra-group transfer agreement, not just an informal “they are our parent” assumption.
A flow to an offshore KYC or chain-analytics vendor needs a data-processing agreement binding the vendor to equivalent protection, plus a transfer basis under sections 48 and 49.
A flow to a cloud or hosting provider outside Kenya is itself a cross-border transfer. Where the data physically rests, and where the support team that can access it sits, both count.
Some data categories may carry localisation or strict-conditions requirements under section 50 and its regulations. Whether the specific KYC and biometric categories a given VASP processes fall within any localisation or strict-conditions designation under the Data Protection (General) Regulations should be confirmed before finalising an offshore-hosting architecture.

The choice between incorporating and hosting in Kenya and running off an offshore stack carries a direct data-protection cost. We cover that trade-off in Crypto business: offshore vs Kenya.

When does a VASP need a Data Protection Impact Assessment? The Worldcoin lesson

Section 31 requires a controller to carry out a Data Protection Impact Assessment where processing is likely to result in a high risk to the rights and freedoms of data subjects. Large-scale processing of sensitive data, extensive profiling, and the use of new technologies are the classic triggers. A VASP doing large-scale identity verification, AML profiling, or any biometric onboarding is squarely in DPIA territory.

The Worldcoin case is the Kenyan precedent every crypto founder should read before designing an onboarding flow. Worldcoin collected iris biometric data from large numbers of Kenyans in exchange for cryptocurrency. The fallout (regulatory scrutiny, suspension of the local operation, investigation by the data-protection regulator) turned on exactly the questions a DPIA is designed to surface in advance: was the biometric collection proportionate, was there a valid lawful basis, was consent freely given when tied to a token payment, were the cross-border flows of biometric data lawful, and had the high-risk processing been assessed before it began rather than after.

The lesson is not “avoid biometrics”. It is that high-risk processing launched without a documented, reasoned DPIA is the most dangerous data-protection posture a crypto business can take in Kenya, because the regulator has already shown it will act on this fact pattern. A DPIA done properly identifies and describes the high-risk processing, tests the lawful basis and the proportionality of the data against the purpose, assesses the risks to data subjects and sets out mitigations, and documents the decision so the VASP can show it assessed the risk before processing, not after a complaint.

Where the DPIA shows a residual high risk the VASP cannot mitigate, the Act contemplates prior consultation with the Data Commissioner. Build the DPIA into the product timeline before launch, not as a remediation exercise after onboarding has started.

What must a VASP do when there is a personal data breach?

A VASP holds identity documents, financial histories and, in some designs, custody-adjacent data. It is a high-value target, and a breach is a question of when, not if.

Section 43 requires a controller to notify the Data Commissioner of a personal-data breach where there is a real risk of harm to the data subject. Notification must be made without undue delay and, where feasible, within seventy-two hours of becoming aware of the breach. Where the breach is likely to result in real risk to the data subject, the controller must also communicate it to the affected data subjects in plain language.

The practical readiness items:

A written incident-response plan naming who declares a breach, who notifies the ODPC, and within what internal deadline (build for inside seventy-two hours).
A breach register recording each incident, the facts, the risk assessment and the decision on whether to notify. The register is itself evidence of accountability.
Coordination with the CEO’s notification duty. Section 25 of the VASP Act places a personal duty on the CEO to notify the regulator of a cyber-security incident with a written mitigation report within seven working days. A breach can therefore trigger both an ODPC notification and a CBK or CMA notification, on two different clocks. Map both into one incident playbook.

Frequently asked questions

Do I need ODPC registration even before the VASP Regulations are gazetted? Yes. The Data Protection Act is fully in force and entirely independent of the VASP Regulations. You cannot get a VASP licence in Kenya today because the VASP Regulations are still in draft, but the ODPC registration and DPA duties apply the moment you process personal data. Do not wait. See the VASP licensing in Kenya pillar for the licensing timeline.

What is the lawful basis for processing KYC data? Compliance with a legal obligation under section 30 of the Data Protection Act, because POCAMLA (Cap. 59A) requires the CDD. Do not rely on consent for AML data: the customer cannot refuse it, and you cannot delete it on a consent withdrawal without breaching the seven-year POCAMLA retention duty.

How do I reconcile the seven-year AML retention with data-protection erasure rights? The seven-year retention in section 46 of POCAMLA is the legal obligation that justifies holding KYC and transaction records that long. An erasure request does not override a statutory retention duty, but you should still erase the data once the seven years expire and the business purpose ends. Document it in your retention policy.

Can I host my customer data with my offshore parent or an overseas cloud provider? Only if the cross-border transfer meets the conditions in sections 48 and 49: a documented transfer basis, appropriate safeguards, and a destination that ensures adequate protection. Put an intra-group transfer agreement or a data-processing agreement in place, and check whether any data categories carry localisation requirements before you finalise the architecture.

When do I have to do a Data Protection Impact Assessment? Whenever processing is likely to result in a high risk to data subjects, under section 31. For a VASP that means large-scale identity verification, AML profiling, or any biometric onboarding. Do the DPIA before you launch the processing. The Worldcoin case shows the regulator will act on high-risk biometric and identity processing that was launched without one.

What is the deadline to report a data breach? Notify the Data Commissioner without undue delay and, where feasible, within seventy-two hours of becoming aware of the breach where there is a real risk of harm, under section 43. Where the breach is likely to harm data subjects, also tell the affected individuals in plain language. Remember the CEO’s separate seven-working-day duty to notify CBK or CMA of a cyber-security incident under the VASP Act.

Are the three registrations connected, or do I do them separately? Separately, with three regulators: the VASP licence with CBK or CMA, the FRC reporting-institution registration under POCAMLA, and the data-controller registration with the ODPC under the Data Protection Act. All three are mandatory and each has its own consequences for non-compliance.

Building a crypto exchange, custodian, wallet or stablecoin business for Kenyan users means building the data-protection layer at the same time as the licence and the AML stack, not after. We help founders and foreign groups put the ODPC registration, the DPIA, the cross-border transfer agreements, the retention policy and the breach-response plan in place so the data layer is defensible from day one. Book a consultation and we will scope your file.