Partnerships are central to modern financial products. A fintech may depend on a bank, payment service provider, cloud provider, identity-verification vendor, mobile-network operator, merchant network or outsourced customer-support team. Each relationship can also create a chain of personal-data collection, access and disclosure.
Under Kenya’s Data Protection Act, 2019 and the Data Protection (General) Regulations, 2021, the right question is not merely whether the commercial agreement contains a privacy clause. The parties should be able to explain what data moves, why it moves, who determines its use, where it is stored, how long it is retained and what happens when the relationship ends.
Data-protection due diligence should follow the real product and data flow—not the label placed on the vendor or agreement.
1. Map the data before negotiating the clause
Start with the actual customer and transaction journey. Identify the data collected at onboarding, during transactions, through device and fraud signals, in customer-support interactions and through regulatory reporting. Record where each category originates, the systems it enters and every party that can access it.
For example, a PSP engaging a KYC vendor may share identity documents, facial images, device information, watchlist results and case-review notes. A merchant-acquiring arrangement may additionally involve payer details, transaction identifiers, chargeback evidence and fraud scores. Describing either relationship simply as “verification” or “payment processing” is not enough to expose the legal and operational risks.
The map should also distinguish ordinary personal data, sensitive personal data and data relating to children or vulnerable individuals. That classification affects lawful processing, safeguards, access and escalation decisions.
2. Allocate controller and processor roles by function
Controller and processor roles follow the parties’ real decisions and conduct. A party that determines the purpose and means of processing is a controller. A provider processing personal data only on a controller’s documented instructions may be a processor for that function. A provider that begins using the same data for its own independent purposes may assume controller responsibilities for that separate activity.
This analysis should be performed activity by activity. The same organisation can be a processor for identity verification but a controller for its own fraud intelligence, legal retention or service-improvement activity. The due-diligence record should identify who:
- provides the privacy notice and establishes the lawful basis;
- responds to access, correction, erasure and objection requests;
- approves sub-processors and changes in processing locations;
- investigates incidents and communicates with affected parties;
- determines retention and deletion; and
- maintains evidence of compliance.
Ambiguous responsibility becomes costly when a complaint, audit or breach occurs.
3. Insist on the written processing terms required by law
Regulation 24 requires a controller engaging a processor to do so through a written contract. The contract should address the subject matter, duration, nature and purpose of processing; types of personal data and data subjects; the controller’s instructions; confidentiality; technical and organisational security measures; return or deletion at the end of the relationship; and audit and inspection rights.
The sub-processor position also matters. A processor should not appoint another provider without the controller’s prior authorisation, must impose corresponding contractual protections and remains accountable to the controller for that provider’s compliance. Fintechs should therefore obtain and review the actual sub-processor list rather than accepting an unrestricted right to change it.
A good contract translates these legal requirements into operational commitments: notification windows, evidence to be supplied, audit mechanics, remediation responsibilities, assistance with rights requests and a workable exit process.
4. Establish the lawful basis and test purpose compatibility
The fact that data is commercially useful does not make every use lawful. For each material purpose, document the legal basis before processing begins and assess whether later uses remain compatible with what the individual was told.
Consent should not be used as a universal answer. Where consent is relied upon, the organisation bears the burden of proving that it was express, unequivocal, free, specific and informed, and it must account for withdrawal. Depending on the facts, another activity may instead rely on contractual necessity, legal obligation, legitimate interests or another ground recognised under section 30 of the Act.
Particular scrutiny should be given to product cross-selling, secondary analytics, automated credit or risk decisions, model training, fraud consortiums and data enrichment. These uses often extend beyond the customer’s immediate expectation of completing a payment or verifying an identity.
5. Conduct the DPIA before the product is fixed
Section 31 requires a data protection impact assessment before processing that is likely to result in high risk to individuals. In fintech, relevant indicators may include systematic profiling, large-scale processing, combining datasets, biometric verification, location or device tracking, innovative technology, or automated decisions with significant effects.
A defensible DPIA describes the proposed processing, assesses necessity and proportionality, identifies risks to data subjects and records the measures chosen to address those risks. The Act also provides for submission of DPIA reports sixty days before processing. Where the assessment shows residual high risk, prior consultation with the Data Commissioner may be required.
The assessment should influence the architecture, onboarding journey and partner terms before launch. A retrospective document prepared after the integration is fixed cannot perform that function effectively.
6. Examine security evidence and incident readiness
Security due diligence should request evidence proportionate to the product and data: access-control design, encryption, logging, vulnerability management, staff controls, independent assurance, incident history, business continuity and disaster recovery. Assertions that a provider applies “industry-standard security” should be tested against evidence and clear accountability.
Incident clauses should reflect Kenya’s statutory escalation window. Where a processor becomes aware of a personal-data breach, the Act requires notification to the controller without delay and, where reasonably practicable, within forty-eight hours. Where unauthorised access or acquisition creates a real risk of harm, the controller must notify the Data Commissioner without delay and within seventy-two hours of awareness. Commercial terms should therefore require sufficiently early processor escalation to allow the controller to investigate and meet its own deadline.
7. Follow cross-border transfers and sub-processors
Cloud and vendor chains may store data outside Kenya or make it remotely accessible from another country. Identify hosting locations, support access, onward transfers and every relevant sub-processor.
Before transferring personal data outside Kenya, the parties should identify and document a lawful transfer basis. The Act and Regulations recognise routes including appropriate safeguards, an adequacy decision, specified necessity grounds or consent, depending on the facts. Sensitive personal data transferred outside Kenya attracts additional requirements.
The contract should require advance information about material changes to processing locations or sub-processors and preserve meaningful recourse where a new location changes the legal or security risk.
8. Build retention and exit into the relationship
Regulation 19 requires a retention schedule with defined periods, periodic review and an action when the purpose expires. A fintech should therefore align vendor retention with its own regulatory, evidential and operational requirements rather than accepting indefinite storage.
Exit provisions should address return, migration, deletion, legal-hold exceptions, deletion certification and treatment of backups. The parties should distinguish data retained by the vendor on the controller’s behalf from data the vendor must retain for an independent legal obligation. Access should be withdrawn promptly, while necessary migration and audit evidence remain available.
A practical pre-signing checklist
- Complete a data-flow and system-access map.
- Classify each party’s role for every processing activity.
- Record the lawful basis and customer-facing transparency position.
- Determine whether registration and a DPIA are required.
- Review the written processor terms against Regulation 24.
- Obtain the sub-processor list and change-control procedure.
- Test security, breach escalation and business-continuity evidence.
- Document cross-border locations, transfer grounds and safeguards.
- Set retention, deletion, migration and audit requirements.
- Assign internal owners for legal, compliance, security and product actions.
Practical takeaway
Good data-protection due diligence connects law, product design, information security and the commercial agreement. The strongest file is not necessarily the longest questionnaire. It is a current and usable record showing that the parties understood the data flow, tested the material risks and assigned workable controls before launch.
S.N. Nyaga & Company Advocates advises fintechs, payment providers and technology businesses on data protection and privacy, cross-border fintech structuring, regulatory compliance and KYC, AML and risk management.
Legal notice: This publication provides general information as at 20 July 2026. It is not legal advice and should not be relied upon as a substitute for advice on a specific processing activity, product, contract or cross-border arrangement.