This workbook is the companion to KPLR's Fintech Data Law & Regulatory Compliance (Kenya) programme, built specifically for digital credit providers (DCPs) and financial technology platforms. It moves from the concurrent six-instrument regulatory stack through data lineage mapping, consent architecture, algorithmic underwriting, ethical debt recovery, subject access requests and DPIAs — with worked templates and clause language drafted for direct adaptation.
This is a legal reference and internal planning tool, not legal advice. Each module contains statutory citations, practitioner boxes drawn from Kenyan fintech enforcement practice, worked examples, reflection questions, and a module completion checklist.
Module 1 · Regulatory Landscape & Registration Architecture
Article 31(c)–(d) of the Constitution is the starting point for any DCP processing borrower data — a fundamental right enforceable independently of the DPA 2019. Six instruments apply concurrently to a Digital Credit Provider: the Constitution (Art. 31); the Data Protection Act, 2019; the Data Protection (General) Regulations, 2021; the Data Protection (Registration) Regulations, 2021; the CBK (Digital Credit Providers) Regulations, 2022; and POCAMLA, Cap. 59B.
The ODPC's Section 8 powers include maintaining the controller/processor register, reviewing DPIAs, investigating complaints, issuing enforcement notices, and imposing fines up to KES 5,000,000 or 1% of turnover, whichever is lower. As of 2025, the ODPC had issued over 40 formal enforcement notices to digital credit providers — commonly for unregistered operation, invalid consent flows, failure to appoint a DPO, and debt-shaming via contact-list scraping.
The POCAMLA vs DPA Retention-Erasure Conflict
Where a closed loan account's data is subject to an erasure request, s.28(2)(c) DPA exempts erasure where retention is required by law — and POCAMLA s.40 requires 7-year retention of KYC and transaction records. The resolution: restrict (rather than delete) the data into a non-operational archive, notify the subject in writing of the retention period and their right to complain to the ODPC, and execute automated, logged deletion once the 7-year window expires. Article 17(3)(b) GDPR contains an identical exemption for EU data subjects.
Registration runs a seven-step path: determine your tier; create an ODPC portal account; specify processing activities; declare your security architecture; upload a board-approved Data Protection Policy; pay the fee via eCitizen; and receive a certificate valid for 24 months.
Module 2 · Data Architecture, Lineage & Mapping
Data lineage is the auditable trail of every personal data element from capture to deletion. In 2024 ODPC inspections, 73% of enforcement findings related not to unlawful processing itself but to the DCP's inability to produce a documented lineage trail proving the processing was lawful.
Section 2 distinguishes standard from sensitive personal data, each with different legal-basis and storage requirements — national ID numbers require contract performance plus a legal obligation and 7-year POCAMLA retention; biometric face images require explicit consent, isolated storage and a 90-day maximum retention; racial or ethnic origin data is prohibited from credit-scoring use entirely under Article 27 of the Constitution.
A compliant data mapping registry — the first document an ODPC audit requests — records, for every data element: legal basis, storage location, access level, external sharing, and retention period, cross-referenced against the Data Protection Policy, vendor DPAs, and the ODPC registration filing.
Role-based access control implements the data-minimisation principle (s.3(c)) across four tiers: a masking customer-care portal with zero export rights; machine-to-machine access for the credit-scoring engine with immutable audit logging; the highest human access tier for Compliance & Legal; and pseudonymised, DPO-approved datasets only for Data Science.
Module 3 · Lawful Bases, Consent Architecture & User Journey Design
Section 30 sets out seven lawful bases. Contract performance is the strongest basis for core lending operations; legitimate interests (fraud prevention, security logging) is medium-risk and requires a documented Legitimate Interests Assessment; consent is high-risk if invalid, since it renders all downstream processing unlawful.
Section 32 establishes four pillars of valid consent, identical in substance to GDPR Article 7: freely given (a loan cannot be conditioned on unrelated processing, e.g. contact-list access); specific (one checkbox per purpose — a single box covering scoring, marketing and sharing is invalid as to all three); informed (identity of the controller, categories of data, purposes, retention, recipients, cross-border transfer, and withdrawal method must all be disclosed); and unambiguous (an affirmative click or toggle — pre-ticked boxes and "by continuing to browse" language never constitute valid consent).
The workbook supplies production-ready consent screen copy for core registration and CRB access authorisation, and a worked table converting three common non-compliant clauses (all-in-one device-sensor access; unrestricted third-party sharing; "use constitutes acceptance") into compliant, purpose-specific replacements.
Module 4 · Automated Decision-Making & Algorithmic Underwriting
Section 35(1) DPA gives data subjects a right against decisions based solely on automated processing that significantly affects them — a threshold that loan approval or rejection plainly meets, triggering Section 35 for virtually every digital lending platform's core business activity. GDPR Article 22 is substantively identical for EU-linked platforms.
Section 35 imposes three mandatory safeguards: proactive, plain-language transparency about the automated logic before processing begins; a right to human intervention via an accessible appeal mechanism, reviewed by a compliance officer empowered to override the algorithm; and a right to express a view, giving the borrower a meaningful chance to submit further evidence before the review concludes.
Article 27 of the Constitution prohibits discrimination on protected grounds, which an algorithm can violate indirectly through proxy variables — neighbourhood as a socio-economic/ethnic proxy, SMS activity patterns reflecting religious observance, or historical loan data that encodes past discriminatory outcomes. The recommended safeguard is an independent bias audit every six months, retained and producible to the ODPC on request.
Module 5 · Ethical Debt Collection & Third-Party Data Risk
DPA s.3/s.25 and CBK Regulation 19(2) create a dual-liability zone for every recovery contact. Direct calls, in-app notices, emails and SMS to the borrower's own registered channels are authorised; a call to the borrower's employer disclosing debt status, WhatsApp messages to the borrower's contact list, or social-media posting of debt details are prohibited outright, carrying civil and criminal exposure under Sections 25 and 72.
Where a Debt Collection Agency (DCA) is engaged, it acts as a Data Processor and the DCP remains fully liable as Controller. The workbook sets out six mandatory DPA clauses: purpose limitation restricting the DCA to the specific assigned debt; a 48-hour mandatory destruction clause on account recall or full recovery, evidenced in writing; a sub-processing prohibition; unannounced audit rights; indemnification; and a schedule of prohibited conduct and required call scripts.
Module 6 · Subject Access Requests & Data Portability
Sections 26–33 grant eight operational rights — access, rectification, erasure, restriction, portability, objection, protection against automated decisions, and the right to complain to the ODPC — most carrying a 21-day response deadline (rectification: 14 days). The six-step SAR protocol runs: log the request on receipt (Day 0, the clock does not pause for verification); verify identity proportionately, without requiring notarised documents; assess scope across every system including archives and call recordings; apply only narrowly justified exemptions (trade secrets, third-party data, active AML investigations, privileged communications); package the response with a cover letter; and deliver within 21 days via encrypted channel, logging completion in the SAR register.
Section 33 portability is best implemented as a self-service, in-app JSON export containing verified identity, account history, third-party transmission logs and consent history — satisfying both s.33 DPA and Article 20 GDPR simultaneously.
Module 7 · Data Protection Impact Assessments
Section 35(2) makes a DPIA mandatory wherever processing is likely to create high risk, with six fintech-specific triggers including any ML-based credit scoring system, large-scale sensitive-data processing, systematic financial or location monitoring, new technology deployment, database linkage with external registries, and any cross-border transfer. Where residual risk stays high after mitigation, s.35(6) requires ODPC consultation before commencing processing — the ODPC has up to eight weeks to respond, and proceeding before that response is a criminal offence.
A worked six-section DPIA for a 50,000-profile ML credit scoring system is provided in full, including a necessity-and-proportionality table (concluding, for example, that contact-list data is not necessary or proportionate for credit assessment and its processing should be prohibited) and a risk-identification table scoring inherent versus residual risk for proxy-discrimination, biometric breach, DCA misuse and cross-border transfer risks.
Quick Reference Glossary
The workbook closes with a statutory glossary (personal data, sensitive personal data, controller, processor, consent, processing, DPIA, DPO, profiling, pseudonymisation) cross-referenced to the DPA 2019 and, where incorporated by reference, the GDPR.
