The decision
- The company can offer data intermediation services through a dedicated legal entity. That entity may earn transaction fees, but it cannot use intermediated data for its own credit analytics. (Regulation (EU) 2022/868, Article 12(a)–(c), (f).)
- Keep any analytics business separately operated and supplied with independently secured, lawfully usable inputs. Incorporation alone does not authorise a marketplace data feed or preferential access for an affiliate. (DGA, Article 12(a)–(c), (f).)
- If proprietary analytics is the essential business, consider a genuine enriched-data product model. Its exclusion depends on substantial value creation and the absence of the commercial relationship between suppliers and buyers characteristic of intermediation. (DGA, Article 2(11)(a).)
- Complete the applicable EU representation and notification steps, alongside data rights, privacy and financial-permission checks. DGA notification does not provide a lawful basis for processing personal data. (DGA, Articles 1(2)–(3), 11.)
Classify the transaction before choosing the structure
The DGA definition concerns services that establish commercial relationships for data sharing between an undetermined population of holders or subjects and users. An open marketplace matching suppliers with potential buyers normally meets that description. Article 10(a) expressly covers exchanges, platforms and infrastructure connecting holders with users. The service need not take possession of every dataset. (DGA, Articles 2(11), 2(13), 10(a), recital 28.)
The company should map who contracts with whom, who grants the data licence, and what the buyer receives. If suppliers and buyers establish their data-sharing relationship through the platform, charging a commission is consistent with intermediation. Calling the platform a reseller or an analytics business does not change those relationships.
A different product can fall within Article 2(11)(a). The provider must obtain data, aggregate, enrich or transform it to add substantial value, and license the resulting data. It must do so without establishing a commercial relationship between the original holders and end users. Buying files and making minor formatting changes does not establish those cumulative conditions.
For the Kenyan company, this alternative would mean acquiring inputs for its own resulting product and selling that product under its own terms. If it also continues matching suppliers and buyers, that service needs a separate DGA assessment. The exclusion for one activity does not automatically cover another. (DGA, Article 2(11)(a), recital 28.)
Other exclusions depend on different facts: a service used exclusively by one holder, a genuine closed group, intermediation focused on copyright-protected content, or specified non-commercial public-sector activity. Standard onboarding contracts do not by themselves turn an open marketplace into a closed group. The altruism exception also does not fit this commercial matching model. (DGA, Articles 2(11)(b)–(d), 15.)
Separate the intermediary from the credit product
Article 12(a) restricts the intermediary's use of exchanged data to making it available to data users. It also requires intermediation through a separate legal person. A division, product name or internal policy cannot satisfy the legal-entity requirement where the same company conducts the other activity.
The proposed credit analytics creates the decisive conflict. The intermediary would use data entrusted for exchange to build a product serving its own commercial purpose. Adding a general analytics permission to marketplace terms does not waive Article 12(a). Anonymising the data does not remove this restriction because the DGA also covers non-personal data.
The recommended structure places intermediation and proprietary analytics in different companies. Common group ownership is not itself prohibited. The group should nevertheless separate contracts, access permissions and processing purposes, with records showing which company obtained each dataset and on what terms. These controls demonstrate compliance; a corporate chart alone cannot do that. (DGA, Article 12(a)–(b), recital 33.)
For launch, the analytics company should secure its inputs independently of the marketplace transaction flow. Do not give it a privileged copy of exchanged datasets or access to the intermediary's commercial intelligence. Any proposal for an affiliate to acquire data through the venue needs its own assessment of purpose, fair access and conflicts. Separate legal personality supplies no automatic exemption. (DGA, Article 12(a)–(c), (f).)
Transaction metadata has its own restriction. Information about service activity, including timing, location and connections, may be used only to develop that intermediation service. Fraud detection and cybersecurity can fall within that purpose. Building a separate credit score from those records does not. The relevant activity data must also be available to data holders on request. (DGA, Article 12(c).)
The intermediary can provide specified exchange-support tools, including temporary storage, curation and anonymisation, at the holder's or subject's explicit request or approval. Conversions have their own permitted purposes and opt-out rule. These provisions support exchange; they do not authorise an independent credit product. (DGA, Article 12(d)–(e).)
As of 6 November 2026, the Digital Omnibus data proposal has not replaced these requirements. The Council's October negotiating mandate proposes a different regime, including functional separation. The company should structure its launch against the operative DGA rather than assume that proposal has become law. (Council document ST 14756/26, 22 October 2026, p. 1 and recital 8; European Parliament procedure 2025/0360(COD).)
Establish the EU filing route
Deliberately offering the marketplace to EU suppliers creates the relevant EU-facing activity. Kenyan incorporation does not remove the DGA notification requirements. Mere website accessibility would be a weaker basis, but this company expressly plans to serve EU businesses. (DGA, Article 11(3), recital 42.)
If the provider has no EU establishment, it must appoint an EU-established legal representative in a Member State where it offers services. The mandate must allow that representative to receive communications and demonstrate compliance. The competent authority is the national DGA authority for that Member State. If the provider is established in the EU, identify the applicable establishment and actual central administration. (DGA, Articles 2(14), 2(21), 11(2)–(3), 13.)
Prepare the Data Governance Act notification with the provider's identity, legal form, ownership and relevant subsidiaries, registration details, address, public website and contacts. Describe the service, its Article 10 category and intended start date. A non-EU provider must include the representative's details. (DGA, Article 11(6).)
A compliant notification permits starting the service subject to Chapter III and supports provision across Member States. Check the selected authority's filing and completeness procedure. The optional declaration confirming notification is distinct from the compliance confirmation required before using the recognised-provider label and logo. Notify changes to filed information within 14 days and cessation within 15 days. (DGA, Article 11(4)–(5), (8)–(9), (12)–(13).)
Make neutrality visible in operations
The launch file should connect each duty to an owner and evidence:
- Publish clear access criteria, fees and service terms. Keep prices independent of whether customers use the group's analytics or other services. Record the basis for different service tiers and prevent preferential access for the analytics affiliate. (DGA, Article 12(b), (f).)
- Check participants and implement procedures against fraudulent or abusive use. Define suspension and investigation responsibilities in the marketplace terms. (DGA, Article 12(g).)
- Document security for storage, processing and transmission of non-personal data, with the highest level of security for storage and transmission of competitively sensitive information. Prepare notification procedures for unauthorised non-personal transfer, access or use without delay. (DGA, Article 12(j)–(l).)
- Plan reasonable continuity on insolvency. Where the service stores data, provide mechanisms for holders and users to access, transfer or retrieve it. Preserve data-subject rights where that limb applies, and test interoperability with other intermediaries. (DGA, Article 12(h)–(i).)
- Where the service assists individuals with their rights, act in their best interests. If it offers consent or permission tools, provide tools to give and withdraw consent or permission. Specify the third-country jurisdiction of intended use where relevant. (DGA, Article 12(m)–(n).)
- Maintain activity logs, access records and evidence of approved conversions and ancillary tools. The authority can request information needed to verify compliance. (DGA, Articles 12(d)–(e), (o), 14(2).)
The continuity plan should cover cloud dependencies as well as the platform's own export process. Where qualifying cloud services are involved, review the separate cloud exit terms under the EU Data Act. DGA insolvency continuity and cloud switching address different obligations.
For non-personal data held in the EU, assess international transfers and foreign governmental access that would conflict with EU or relevant national law. Article 31 requires reasonable protective measures and specific treatment of foreign demands. It does not impose a blanket ban on Kenya access or international commercial transfers. (DGA, Article 31.)
Keep data rights and privacy permissions separate
The supplier must have the right to share the particular data, and the buyer must have the right to use it. Require provenance evidence and a permitted-use schedule covering the dataset, purposes, recipients, locations and onward use. A licence should distinguish exchange from training or development of a separate product. The data licence terms for training, fine-tuning and RAG provide the related contract detail. (DGA, Article 2(8)–(10).)
For personal data, allocate GDPR roles by the actual decisions about purposes and means. The intermediary may be a processor for one operation and a controller for another. Establish the lawful basis, notices, purpose limits and any additional sensitive-data condition. Use processor or joint-controller terms where the facts require them. DGA neutrality does not decide those roles. (Regulation (EU) 2016/679, Articles 4(7)–(8), 5–6, 9, 13–14, 26, 28; DGA, Article 1(3).)
EU disclosure or remote access by a separate Kenyan recipient also requires a Chapter V transfer assessment. Kenya has no EU adequacy decision. Identify an applicable transfer safeguard and complete the necessary assessment, adding supplementary measures where required. Standard contractual clauses must fit the parties and processing concerned. EU hosting alone does not resolve overseas access. The Data Protection & GDPR for AI service addresses these connected processing and transfer questions. (GDPR, Articles 44–46; Decision (EU) 2021/914, Article 1 and Annex, clauses 14–15.)
Kenyan law requires a further check where the company processes personal data in Kenya or otherwise meets the Act's territorial scope. Commercial use engages section 37: express consent, or written-law authorisation with the prescribed notice, is required. A supplier's business contract alone does not establish either route. Anonymise the data where possible under section 37(2). Assess registration with the Office of the Data Protection Commissioner (ODPC) against the actual processing purpose and applicable exemption; possession of financial data does not automatically establish provision of financial services. (Data Protection Act 2019, sections 4, 18, 25, 30, 37; Data Protection (General) Regulations 2021, regulation 14; Registration Regulations 2021, regulation 13 and Third Schedule.)
ODPC guidance also expects recipients to respect purpose limits and restrictions on onward sharing or combining datasets. Address those expectations in the permissions review. (ODPC Data Sharing Code, 4 March 2025, sections 2.1, 3.4.)
For transfers out of Kenya, document the applicable ground and safeguards. Sensitive personal data processed outside Kenya requires consent and confirmed appropriate safeguards. Kenyan sensitive data includes property details, which can matter for financial datasets. The transfer file should also address the ODPC Code's notification expectation. The EU-to-Kenya and Kenya-outbound tests must each be satisfied where they apply. (Data Protection Act, sections 2, 48–49; General Regulations, regulations 39–48; ODPC Data Sharing Code, section 5, item 10.)
Check the adjacent activities before launch
The Digital Services Act requires a separate assessment if the marketplace hosts users' listings or disseminates them publicly. Its hosting and platform definitions can cover business users. Its representative duty and specific small-business exceptions do not follow automatically from DGA status. (Regulation (EU) 2022/2065, Articles 2–3, 13, 19.)
Dataset matching, payment services, lending and credit-reference activity require distinct classifications. Check the actual settlement arrangements and analytics outputs before adding those functions. Kenya's non-deposit credit rules, credit-bureau rules and payment legislation have separate permission requirements. DGA notification provides no financial-services passport. (DGA, Article 1(2); Central Bank of Kenya (Non-Deposit Taking Credit Providers) Regulations 2026, regulations 3–5; Banking (Credit Reference Bureau) Regulations 2020, regulations 2–4; National Payment System Act 2011, sections 2, 12–13.)
If the separate product uses AI to assess individuals' creditworthiness, assess the applicable AI Act timetable and automated-decision rules. The existing EU AI Act credit-scoring analysis for a Kenyan provider addresses that product decision. (Regulation (EU) 2024/1689, Article 6, Annex III, point 5(b), and Article 113, as amended by Regulation (EU) 2026/1744; GDPR, Article 22.)
Approve the model before admitting live datasets
The business lead should first choose between neutral matching and a genuine proprietary data product. Legal and engineering teams should then approve the entity structure, data-flow map and source permissions. Prepare marketplace terms, supplier and buyer licences, any separate analytics agreements, privacy and transfer documents, the representative mandate, notification and operating evidence.
Launch the intermediary only when the prohibited own-use feature has been removed and the applicable conditions are met. If the business depends on exploiting marketplace data for its own credit product, redesign that service and reclassify it before launch.
Plan the marketplace review
Review a cross-border data marketplace model with Licentium. Bring the proposed entity structure, data-flow map, pricing model and draft supplier and buyer terms.