Introduction: Why Data Protection Is a Core Fintech Compliance Issue in Turkey

Financial technology businesses process some of the most commercially valuable and legally sensitive information in the modern economy.

A fintech company may process a customer’s name, identity number, mobile telephone number, bank account details, payment history, merchant transactions, wallet balance, device information, IP address, location-related technical information, fraud indicators, identity documents and behavioural patterns—often within the same digital ecosystem.

A crypto platform may additionally process blockchain addresses and information concerning transfers between wallets.

An open banking provider may obtain information from multiple payment accounts belonging to the same customer.

An electronic money institution may be capable of analysing where a customer spends money, how frequently funds are transferred and which merchants receive payments.

A Banking as a Service platform may combine financial information received from a bank with commercial information already available within its own digital ecosystem.

For these reasons, data protection compliance for fintech companies in Turkey is no longer a secondary legal issue.

It is a core element of financial regulatory compliance.

The principal Turkish data protection legislation is Law No. 6698 on the Protection of Personal Data, commonly known by its Turkish abbreviation KVKK.

Fintech businesses may simultaneously be subject to sector-specific legislation administered by authorities such as:

• the Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”);
• the Banking Regulation and Supervision Agency (“BRSA” or “BDDK”);
• the Capital Markets Board of Türkiye (“CMB” or “SPK”);
• the Financial Crimes Investigation Board (“MASAK”);
• the Personal Data Protection Authority.

This creates an important compliance principle:

A financial institution must comply with KVKK in addition to its sector-specific financial regulation.

Receiving a payment institution licence, electronic money licence, digital bank licence or crypto asset service provider permission does not remove data protection obligations.

The importance of sector-specific compliance was reinforced in July 2026, when the Turkish Personal Data Protection Authority published the Good Practices Guide on the Protection of Personal Data in the Payment and Electronic Money Sector, prepared together with the Türkiye Payment and Electronic Money Institutions Association (“TÖDEB”). The Guide specifically addresses controller and processor roles, categories of personal data processed in the sector, legal grounds, data transfers, controller obligations and information security.

This article explains the principal KVKK compliance requirements for fintech companies in Turkey as of July 2026.

1. What Is KVKK?

The Law on the Protection of Personal Data No. 6698 is Türkiye’s principal personal data protection statute.

Its purpose is broadly to protect fundamental rights and freedoms, particularly the privacy of individuals, in connection with the processing of personal data and to regulate the obligations of persons processing such information.

KVKK regulates matters including:

• lawful processing;
• general data-processing principles;
• special categories of personal data;
• disclosure obligations;
• data security;
• data subject rights;
• international data transfers;
• registration of data controllers;
• administrative sanctions.

A fintech business should therefore consider KVKK at every stage of the customer lifecycle:

customer acquisition → onboarding → KYC → transaction monitoring → payment processing → marketing → customer support → account closure → retention and deletion.

2. Why Fintech Companies Face Higher Data Protection Risk

A conventional business may process customer contact information and purchase records.

A fintech company can process significantly more revealing information.

Transaction data may demonstrate:

• where a person shops;
• when a person travels;
• which businesses they use;
• how much money they receive;
• how frequently they transfer money;
• which financial services they use;
• their spending behaviour;
• recurring payments;
• potential credit behaviour.

Even where individual financial information does not fall within the statutory definition of a special category of personal data, it can create significant privacy and security risks.

Fintech companies are also especially vulnerable to:

• identity theft;
• credential stuffing;
• account takeover;
• phishing;
• unauthorised employee access;
• API compromise;
• customer profiling;
• large-scale data breaches.

Article 12 of KVKK therefore becomes particularly important for fintech businesses because it requires data controllers to take necessary technical and administrative measures to prevent unlawful processing and access and to ensure proper preservation of personal data.

3. What Personal Data Does a Fintech Company Process?

The exact answer depends on the business model.

Common categories include:

Identity Information

• name and surname;
• Turkish identification number;
• passport;
• date of birth;
• nationality;
• identity document information.

Contact Information

• mobile telephone number;
• email;
• address.

Financial Information

• bank account details;
• IBAN;
• card information;
• wallet balance;
• payment history;
• merchant information;
• transfers;
• account movements.

Transaction Information

• payment date;
• payment amount;
• recipient;
• sender;
• transfer references;
• merchant category.

Customer Security Information

• login history;
• IP addresses;
• device information;
• authentication records;
• fraud alerts.

Compliance Information

• KYC documents;
• beneficial ownership records;
• sanctions screening;
• politically exposed person results;
• transaction monitoring records.

Crypto Information

• wallet addresses;
• blockchain transaction information;
• deposit and withdrawal details.

Open Banking Information

• information from accounts maintained with different payment service providers;
• account balances;
• payment transactions;
• card transactions where permitted.

The first practical step in a fintech KVKK project should therefore be a detailed data mapping exercise.

The company should identify what data exists, where it comes from, why it is processed, where it is stored and who receives it.

4. Data Controller vs Data Processor in Fintech

Determining whether a company acts as a data controller or data processor is fundamental.

A data controller determines the purposes and means of processing personal data.

A data processor processes personal data on behalf of a data controller.

A fintech company may act as a controller in one relationship and as a processor in another.

For example:

A payment institution determining how its customers are onboarded will generally have substantial data-controller responsibilities.

A cloud provider processing information solely according to the payment institution’s instructions may act as a processor.

However, relationships can become more complicated in:

• Banking as a Service;
• open banking;
• fraud prevention;
• group-company data sharing;
• outsourced KYC;
• merchant acquiring.

The new July 2026 Payment and Electronic Money Sector Good Practices Guide expressly addresses the distinction between data controller and data processor in sector-specific processing activities.

Parties should therefore avoid assuming contractual labels are decisive.

Calling a vendor a “processor” does not necessarily make it a processor if the vendor independently determines how and why data is used.

5. General Principles of Personal Data Processing

Even where a fintech company has a valid legal basis for processing personal data, it must still comply with the general principles under Article 4 of KVKK.

These principles require personal data to be processed:

• lawfully and fairly;
• accurately and, where necessary, kept up to date;
• for specified, explicit and legitimate purposes;
• in a manner relevant, limited and proportionate to the purpose;
• only for the period required by legislation or the purpose of processing.

These principles are particularly important for fintech businesses because technology makes it commercially tempting to collect as much data as possible.

However:

“We may need this information one day” is not a sufficient data protection strategy.

The Personal Data Protection Board has previously treated requesting personal data unnecessary for the relevant transaction as incompatible with the requirements of lawful, fair and purpose-limited processing.

Data minimisation should therefore begin at product-design level.

6. Legal Grounds for Processing Fintech Customer Data

Fintech companies sometimes incorrectly assume that all personal data processing requires explicit consent.

This is not correct.

Article 5 of KVKK provides several legal grounds under which ordinary personal data may be processed without explicit consent.

Depending on the specific activity, fintech processing may potentially rely on grounds including:

• processing expressly required by law;
• processing necessary for establishing or performing a contract;
• processing necessary to fulfil the controller’s legal obligations;
• processing necessary for establishment, exercise or protection of a legal right;
• processing necessary for the legitimate interests of the controller, provided that the fundamental rights and freedoms of the data subject are not harmed.

For example, a payment institution may need to process customer identity information because of legal identification requirements.

A fintech may need customer contact information to perform the service contract.

Transaction records may need to be retained because of financial regulatory or AML obligations.

Therefore, explicit consent should not automatically be used as the legal basis for every processing operation.

7. Explicit Consent Should Not Be Used Unnecessarily

One of the most important principles of Turkish data protection law is that explicit consent is only one lawful basis for processing.

Where another legal basis exists, requesting unnecessary consent may create legal and practical problems.

For example, it can create the false impression that the customer may withdraw consent and thereby prevent processing that the institution is legally required to perform.

A payment company cannot normally allow a customer to withdraw consent to statutory AML record keeping where retention is required by law.

The correct approach is therefore:

identify the true legal basis for each processing activity.

Only activities genuinely requiring consent should be placed within the consent mechanism.

8. Major 2026 Rule: Privacy Notices and Consent Must Be Separate

An especially important development occurred in 2026.

The Personal Data Protection Board adopted Principle Decision No. 2026/347 dated 18 February 2026 concerning the improper combination of privacy notices and explicit consent texts.

The Authority published the decision publicly on 20 July 2026.

The Board emphasised that:

• the privacy notice and explicit consent text represent legally different concepts;
• privacy information must be provided regardless of whether processing relies on consent;
• where consent is required, the notice and consent should be presented separately;
• where processing relies on another statutory ground, customers should not also be asked for unnecessary consent;
• privacy notices should clearly identify processed data, processing purposes and legal grounds;
• generic or misleading privacy notices should be avoided.

This decision is extremely important for fintech onboarding screens.

A checkbox stating:

“I have read the Privacy Notice and consent to processing of all my personal data”

is likely to create significant compliance risk where information and consent are mixed together indiscriminately.

9. Privacy Notice Requirements

Article 10 of KVKK requires a data controller to inform data subjects when their personal data is collected.

A fintech privacy notice should therefore clearly explain matters such as:

• identity of the data controller;
• purposes of processing;
• recipients and purposes of transfers;
• method and legal ground for collection;
• data subject rights.

The 2026 Principle Decision further emphasises that notices should be:

• clear;
• understandable;
• concise;
• specific;
• adapted to the company’s actual operations.

Copying another fintech company’s privacy notice without adapting it to the actual product is specifically identified as an improper practice.

A company operating a crypto platform should therefore not simply use the privacy notice of an electronic money institution.

The data flows are materially different.

10. Layered Privacy Notices for Mobile Fintech Applications

Fintech applications frequently operate through small mobile screens.

A fifteen-page privacy notice displayed before an account can be opened may technically contain large amounts of information while still failing to communicate meaningfully with customers.

A layered notice can often provide a better structure.

For example:

Layer One

A concise explanation identifying the controller, main processing purposes and major data transfers.

Layer Two

Detailed privacy information accessible through a link or expanded section.

The 2026 Board approach specifically warns against excessively long and complicated notices and emphasises clear and understandable disclosure.

11. Special Categories of Personal Data

KVKK identifies certain information as special categories of personal data.

These categories include information concerning matters such as:

• race;
• ethnicity;
• political opinion;
• religion;
• association or trade union membership;
• health;
• sex life;
• criminal convictions and security measures;
• biometric data;
• genetic data.

These categories receive stronger protection.

Fintech companies may encounter special-category data particularly during:

• remote identity verification;
• biometric authentication;
• employee processing;
• fraud investigation;
• compliance investigations.

12. Important 2024 Reform of Special Category Data Rules

Türkiye substantially amended Article 6 of KVKK through Law No. 7499, published on 12 March 2024.

The reform broadened and modernised the legal bases under which special categories of personal data can be processed.

The Personal Data Protection Authority subsequently published a dedicated Guide on Processing Special Categories of Personal Data to assist controllers in applying the new framework.

This means older legal analyses stating that almost all special-category processing requires explicit consent are no longer sufficient.

Fintech companies should examine the current Article 6 legal grounds rather than relying on pre-2024 compliance documents.

13. Biometric Data and Fintech

Biometric information is particularly relevant to fintech companies.

A digital bank, payment institution or crypto platform may consider using:

• facial recognition;
• voice recognition;
• fingerprints;
• other biometric authentication.

Biometric data qualifies as special-category personal data.

Therefore, the company should determine:

1. whether biometric processing is genuinely necessary;
2. which Article 6 legal ground applies;
3. whether less intrusive authentication methods could achieve the same objective;
4. which additional security measures are required.

Convenience alone should not automatically justify biometric processing.

The company’s sector-specific remote onboarding rules must also be considered separately from KVKK.

14. Remote Customer Onboarding and KVKK

Remote identification has become central to fintech.

The customer may upload identity documents, participate in video identification, provide photographs or use electronic identity verification.

This creates significant personal data processing.

A remote onboarding system should address:

• legal ground for processing;
• privacy disclosure;
• retention;
• biometric processing where applicable;
• security;
• access rights;
• third-party technology providers;
• international transfers.

Fintech companies should distinguish between information required by financial regulations and optional information requested for convenience or marketing.

The fact that an onboarding provider technically offers twenty different identity-analysis features does not mean every feature should be activated.

15. Payment and Electronic Money Institutions

Payment institutions and electronic money institutions now have particularly strong sector-specific data protection guidance.

On 14 July 2026, the Personal Data Protection Authority published the Good Practices Guide on the Protection of Personal Data in the Payment and Electronic Money Sector, prepared jointly with TÖDEB.

The Guide was designed to assist businesses including:

• electronic money institutions;
• POS service providers;
• mobile payment providers;
• bill-payment intermediaries;
• money-transfer intermediaries.

It addresses:

• processed personal data;
• controller and processor relationships;
• legal grounds;
• personal data transfers;
• data-controller obligations;
• data security.

For payment and EMI businesses, this Guide should now be treated as an important sector-specific reference when designing a KVKK compliance programme.

16. Open Banking and Data Protection

Open banking creates unique data protection issues because it involves access to payment-account information held by different institutions.

An Account Information Service Provider may receive:

• account balances;
• payment transactions;
• card information;
• account details;
• transaction descriptions.

A Payment Initiation Service Provider may process information necessary to initiate a customer’s payment.

However, regulated access does not mean unlimited use.

The Turkish payment-services framework itself restricts open banking providers to accessing and using information necessary to provide the authorised service.

KVKK adds an additional layer.

For example, an AISP should not automatically assume that account information obtained to provide aggregation services can subsequently be used for unrelated:

• advertising;
• profiling;
• credit scoring;
• marketing.

The purpose and legal basis for secondary use must be separately examined.

17. Crypto Platforms and Personal Data

Crypto platforms sometimes misunderstand blockchain technology as fundamentally anonymous.

From a KVKK perspective, this assumption can be dangerous.

A crypto platform may hold information linking:

a named customer → to a particular blockchain wallet → to a transaction history.

Once a wallet address can be connected to an identifiable individual, the information may become personal data within the institution’s ecosystem.

Crypto companies may process:

• identity documentation;
• blockchain addresses;
• transaction histories;
• IP addresses;
• device identifiers;
• sanctions information;
• fraud scores;
• Travel Rule information.

Accordingly, crypto compliance involves both CMB/MASAK regulation and KVKK.

18. Banking as a Service and Data Sharing

Banking as a Service creates another complicated data-sharing structure.

The customer may interact primarily through a fintech interface while the underlying banking service is supplied by a licensed service bank.

Data may therefore flow between:

• customer;
• interface provider;
• service bank;
• KYC service provider;
• cloud infrastructure;
• fraud prevention provider.

Each party’s role must be identified carefully.

In particular, banking confidentiality requirements may apply in addition to KVKK.

Therefore:

a transfer being lawful under KVKK does not automatically mean it is permitted under banking secrecy rules.

Fintech groups should analyse both regimes.

19. Artificial Intelligence, Profiling and Credit Scoring

Fintech businesses increasingly use automated models for:

• fraud detection;
• customer segmentation;
• credit scoring;
• transaction monitoring;
• marketing;
• risk management.

These activities involve personal data processing.

KVKK gives data subjects rights concerning results arising against them through analysis of personal data exclusively by automated systems.

Fintech businesses should therefore carefully examine systems where algorithmic analysis can lead to significant adverse decisions.

Examples may include:

• automatic account rejection;
• fraud blocking;
• lending eligibility;
• transaction restrictions.

The company should also ensure the underlying data is accurate, proportionate and used for a legitimate purpose.

20. Data Minimisation

Fintech applications often collect excessive information because it may later become commercially useful.

This approach conflicts with the KVKK principle that personal data should be relevant, limited and proportionate to the processing purpose.

For every field in an onboarding form, the company should ask:

Why do we need this information?

Which law or legitimate purpose requires it?

What happens if we do not collect it?

If the company cannot answer these questions, the data may not be necessary.

This is especially important for:

• identity documents;
• contact lists;
• location permissions;
• device information;
• biometric data.

21. Retention and Deletion

Personal data should not be kept indefinitely merely because storage is inexpensive.

Article 4 requires retention only for the period required by legislation or the processing purpose.

Fintech companies should therefore establish a retention and deletion matrix.

Different categories may require different retention periods.

For example:

• MASAK information may have statutory retention periods;
• payment records may be subject to sector-specific requirements;
• support tickets may require a different period;
• unsuccessful marketing leads may justify a substantially shorter period.

The correct retention period should be determined by the relevant legal purpose rather than a single company-wide rule.

22. Cross-Border Data Transfers: The New Article 9 Regime

One of the most significant reforms to Turkish data protection law concerns international transfers.

Article 9 of KVKK was substantially amended through Law No. 7499.

The new regime introduced a structure more closely focused on:

1. adequacy decisions;
2. appropriate safeguards;
3. limited exceptional transfer situations.

The Authority’s current international transfer guidance explains this three-stage system.

This reform is especially important for fintech companies because many use international:

• cloud providers;
• SaaS platforms;
• fraud analytics services;
• CRM systems;
• cybersecurity providers;
• global group-company infrastructure.

23. Adequacy Decisions

Under the new system, personal data can be transferred where an adequacy decision exists and the relevant domestic processing requirements are satisfied.

However, as of July 2026, the Personal Data Protection Authority states that no countries have yet been designated as countries providing adequate protection under the current regime.

This has significant practical consequences.

A fintech cannot currently rely simply on:

“Our cloud server is in the EU, therefore the transfer is automatically permitted.”

Another transfer mechanism will generally be required.

24. Standard Contracts for International Data Transfers

For many fintech companies, standard contracts have become one of the most practical cross-border transfer mechanisms.

The Authority adopted official standard contractual texts through its 4 June 2024 decision.

Where the statutory conditions are satisfied, parties may use the applicable standard contract without requesting individual pre-approval from the Board.

Different transfer relationships may require different standard contract structures depending on whether the exporter and importer are controllers or processors.

Companies should therefore select the correct template rather than using a generic data-processing agreement.

25. Five-Business-Day Notification Requirement

Signing the standard contract does not complete the process.

Article 9 requires the standard contract to be notified to the Authority within five business days after signature.

The Authority also operates a dedicated Standard Contract Notification Module allowing notifications to be submitted electronically.

This is a practical compliance issue for international fintech groups.

Companies using dozens of overseas vendors should maintain a central register containing:

• data importer;
• country;
• data categories;
• transfer purpose;
• contract type;
• signature date;
• five-business-day notification status.

Missing the notification requirement can create avoidable compliance exposure.

26. Binding Corporate Rules

Multinational fintech groups may also consider Binding Corporate Rules (“BCRs”).

The new Article 9 framework recognises Board-approved binding corporate rules as an appropriate safeguard for transfers within the same group of undertakings.

Once approved, qualifying transfers within the group can be made under that framework without seeking separate approval for each transfer.

BCRs may be attractive for international banking and fintech groups with extensive recurring internal data flows.

However, they are generally more complex to prepare than standard contracts.

27. Undertakings Requiring Board Permission

Another available safeguard involves a written undertaking containing sufficient protections together with Board approval.

This may be useful where standard contracts are unsuitable for the particular sectoral or regional structure.

Unlike standard contracts, however, the undertaking route requires regulatory approval before the transfer can proceed.

28. Exceptional Cross-Border Transfers

Where there is:

• no adequacy decision; and
• no appropriate safeguard,

Article 9 allows transfers only in specified occasional and exceptional circumstances.

Examples may include certain transfers necessary for:

• performance of a contract;
• establishment, exercise or protection of legal rights;
• overriding public interest;
• protection of life or physical integrity.

Explicit consent may also be available for an occasional transfer where the data subject is informed of possible risks.

However, the Authority emphasises that these exceptions are designed for occasional, non-regular transfers and should be interpreted narrowly.

Therefore, a fintech should not use “explicit consent” as the permanent legal basis for everyday international cloud hosting.

Regular cloud transfers should generally be structured through an appropriate safeguard.

29. Foreign Cloud Providers

Cloud computing creates one of the most important fintech KVKK issues.

A company may use:

• AWS;
• Microsoft Azure;
• Google Cloud;
• foreign SaaS vendors;
• international fraud prevention platforms.

The company should identify:

• where data is physically stored;
• whether foreign support personnel can access it;
• whether backups are located abroad;
• whether sub-processors receive data;
• whether telemetry or logs leave Türkiye.

Even where the primary server is located in Türkiye, remote foreign access may create an international transfer.

Therefore, the legal review should map actual data flows, not simply the contractual billing address of the cloud provider.

30. KVKK and Sector-Specific Data Localization Are Different

Fintech companies should also distinguish KVKK transfer rules from sector-specific localisation rules.

The CBRT maintains separate information systems requirements for payment and electronic money institutions within the payment services regulatory framework.

Banks are subject to separate BRSA information systems and confidentiality rules.

Crypto institutions may also face sector-specific information-systems requirements.

Therefore, complying with KVKK Article 9 does not necessarily mean that a foreign cloud arrangement is permissible under financial regulation.

The company should ask two separate questions:

Is the transfer lawful under KVKK?

and

Does our financial regulator permit this architecture?

Both must be satisfied.

31. Data Security Under Article 12

Article 12 requires a data controller to take all necessary technical and administrative measures to:

• prevent unlawful processing;
• prevent unlawful access;
• ensure proper preservation of personal data.

Where processing is performed by another party on behalf of the controller, the controller and processor have joint responsibilities concerning the necessary security measures.

For fintech companies, relevant technical measures may include:

• encryption;
• multi-factor authentication;
• access controls;
• logging;
• segregation of duties;
• privileged-access management;
• vulnerability management;
• penetration testing;
• backup;
• network segmentation;
• incident response.

Administrative measures may include:

• data protection policies;
• employee training;
• confidentiality undertakings;
• vendor due diligence;
• access-authorisation procedures;
• incident-management plans.

32. Account Security Measures

The Personal Data Protection Authority has issued specific recommendations concerning user account security.

Examples include:

• limiting failed login attempts;
• showing users successful and failed login attempts;
• encouraging unique passwords;
• implementing strong password policies;
• using CAPTCHA or comparable protection;
• restricting access by IP where appropriate;
• keeping third-party software updated.

The Authority has also highlighted the use of multi-factor or two-stage authentication as an important security measure against account compromise.

These recommendations are particularly relevant to fintech applications because compromised customer accounts may expose both personal and financial information.

33. Employee Access Is a Major Risk

Data breaches do not always come from external hackers.

An employee with excessive access rights can also create serious risk.

The Personal Data Protection Board has imposed sanctions in circumstances where employees used access permissions to view customer information for personal purposes.

Fintech companies should therefore implement:

• role-based access;
• least-privilege principles;
• audit logging;
• periodic access reviews;
• employee departure procedures;
• privileged account monitoring.

A customer-support employee should not automatically have access to every element of a customer’s financial history.

34. Vendor and Processor Management

Fintech companies rely heavily on vendors.

Common processors include:

• cloud providers;
• KYC platforms;
• call centres;
• software developers;
• fraud monitoring companies;
• analytics companies.

A processor agreement should address:

• instructions;
• confidentiality;
• security;
• sub-processing;
• data breaches;
• deletion;
• international transfers;
• audit rights.

However, signing a contract is not enough.

Article 12 requires the controller to ensure appropriate security where another person processes data on its behalf.

Fintech companies should therefore conduct real vendor due diligence.

35. Data Breach Notification: 72 Hours

Türkiye has a specific breach notification standard.

Article 12 requires data controllers to notify affected individuals and the Board where processed personal data is unlawfully obtained by others.

The Board interprets “as soon as possible” as requiring notification to the Board:

within a maximum of 72 hours after becoming aware of the breach.

Where the 72-hour period cannot be met for a justified reason, the reason for delay must accompany the notification.

Affected individuals should also be informed within the shortest reasonable period after they are identified.

This is particularly demanding for fintech companies operating continuously.

A cyber incident discovered late on a Friday cannot simply wait for the following week’s ordinary compliance meeting.

36. What Should a Data Breach Notice Contain?

The Board has also established minimum information requirements for notices made to affected individuals.

The notification should use clear language and explain matters including:

• when the breach occurred;
• categories of personal data affected;
• likely consequences;
• measures taken or recommended to reduce harm;
• contact details through which additional information can be obtained.

Fintech companies should therefore prepare a breach response template before any incident occurs.

37. Data Breach Response Plan

The Board’s breach framework specifically recommends that organisations establish a documented data breach response plan identifying:

• internal reporting responsibilities;
• who evaluates the incident;
• who decides regulatory notifications;
• how affected individuals will be contacted.

A fintech company’s plan should involve:

• legal;
• compliance;
• information security;
• senior management;
• communications.

Cybersecurity and legal compliance teams should not operate independently during a breach.

38. VERBIS Registration

Article 16 of KVKK establishes the Data Controllers Registry (“VERBIS”) framework.

Data controllers generally have a registration obligation unless they fall within an exemption determined by the Board.

The VERBIS guidance was updated again in July 2026 to reflect current procedures.

Fintech companies should therefore determine whether registration is required before assuming that startup size automatically creates an exemption.

39. Current VERBIS Thresholds in 2026

Following the Board’s 2025 amendments, data controllers whose principal activity does not involve processing special-category personal data are exempt where both:

• annual employee count is fewer than 50; and
• annual balance sheet total is below TRY 100 million.

For businesses whose principal activity does involve special-category personal data, an exemption applies where both:

• annual employee count is fewer than 10; and
• annual balance sheet total is below TRY 10 million.

Therefore, exceeding one of the relevant criteria can result in registration becoming necessary.

Fintech companies experiencing rapid growth should monitor these thresholds annually.

40. VERBIS Is Not the Same as KVKK Compliance

An important misconception should be avoided:

registering with VERBIS does not mean a company is fully KVKK compliant.

VERBIS is only one component.

A compliant fintech may additionally need:

• processing inventory;
• privacy notices;
• retention policies;
• consent mechanisms;
• international transfer safeguards;
• security measures;
• vendor contracts;
• data subject request procedures;
• breach response systems.

Similarly, a company exempt from VERBIS is not exempt from KVKK.

Most substantive data protection obligations can continue to apply.

41. Data Subject Rights

Article 11 provides individuals with significant rights concerning their personal data.

Depending upon the circumstances, data subjects may request information regarding:

• whether their personal data is processed;
• the purpose of processing;
• recipients;
• correction;
• deletion or destruction;
• notification of certain corrections to recipients;
• results arising against them through exclusively automated analysis;
• compensation for unlawful processing.

Fintech companies should therefore establish a process for receiving and responding to data subject applications.

Customer-support employees should be trained to recognise when an ordinary complaint is actually a KVKK request.

42. Marketing Communications

A fintech company should distinguish between data needed to provide the regulated service and data used for marketing.

Customer information processed for:

• payment execution;
• AML compliance;
• account security

should not automatically be repurposed for promotional campaigns.

Marketing may also involve separate obligations under electronic communications legislation.

Therefore, the company should identify:

• what marketing data is used;
• which legal basis applies;
• whether commercial electronic communication consent is required;
• whether the customer can opt out.

A single “accept everything” checkbox is generally a poor compliance design.

43. Cookies, SDKs and Mobile Analytics

Fintech applications frequently integrate:

• analytics SDKs;
• crash reporting;
• advertising SDKs;
• behavioural analytics;
• attribution services.

These tools may send:

• device identifiers;
• IP addresses;
• application activity;
• behavioural data

to third parties.

The legal team should therefore be involved before SDK integration.

An apparently harmless analytics tool may create:

• new data recipients;
• international transfers;
• additional privacy notice requirements.

Fintech developers should maintain a register of third-party code and data flows within the mobile application.

44. Data Protection by Design

Although Turkish law does not use every GDPR concept in identical statutory terminology, fintech businesses should apply privacy-by-design principles in practice.

Before launching a new feature, the company should determine:

• what personal data will be collected;
• why it is necessary;
• which legal basis applies;
• who will access it;
• whether it leaves Türkiye;
• how long it will be retained;
• what happens if the system is breached.

This review should happen before development is completed.

Retrofitting privacy compliance after millions of customer records have already been collected can be extremely costly.

45. Data Protection Due Diligence in Fintech M&A

Data protection should be a major element of fintech mergers and acquisitions.

A buyer should review:

VERBIS

Is registration required and has it been completed correctly?

Privacy Notices

Do notices accurately reflect actual operations?

Legal Grounds

Has the target relied on unnecessary or invalid consent?

International Transfers

Are foreign cloud and SaaS transfers supported by Article 9 mechanisms?

Standard Contracts

Have required notifications been submitted within five business days?

Data Breaches

Has the target experienced reportable incidents?

Vendors

Are processor agreements adequate?

Security

Have penetration tests or security incidents revealed systemic deficiencies?

Retention

Does the company retain unnecessary legacy customer data?

Regulatory Correspondence

Has the Personal Data Protection Authority investigated the company?

A large customer database can appear to be a valuable acquisition asset.

However, unlawfully collected data may instead represent a substantial liability.

46. Special Considerations for Foreign Fintech Companies

International fintech groups entering Türkiye should not simply copy their GDPR privacy programme.

KVKK and GDPR share many concepts, but they are not identical.

Turkish operations must separately analyse:

• Article 5 legal grounds;
• Article 6 special-category rules;
• Article 9 international transfers;
• VERBIS;
• Turkish privacy notice requirements;
• the 72-hour breach rule;
• sector-specific financial regulations.

The Article 9 reform has made Turkish international transfer law more structurally familiar to international privacy teams, but local procedures remain important.

In particular:

standard contracts must use the Turkish Authority’s framework and must be notified within five business days.

47. 2026 Fintech KVKK Compliance Checklist

A fintech company operating in Türkiye should review at least the following areas.

Data Inventory

Identify all customer, merchant, employee and transaction information.

Controller/Processor Roles

Determine the legal position of each business partner.

Legal Grounds

Map every processing purpose to the correct Article 5 or Article 6 basis.

Privacy Notices

Prepare clear and business-specific notices.

Consent

Use separate consent mechanisms only where legally necessary.

Special Categories

Identify biometric, criminal-record and other protected information.

Remote Onboarding

Review identity and biometric data flows.

Open Banking

Limit access and use to authorised purposes.

Crypto

Map wallet and blockchain information to identifiable customers.

Retention

Create legally justified retention schedules.

VERBIS

Confirm whether registration is required under the current thresholds.

International Transfers

Map every transfer outside Türkiye.

Standard Contracts

Select the correct KVKK standard contract and submit the required notification within five business days.

Cloud

Analyse hosting, backups, support access and sub-processors.

Vendors

Conduct processor due diligence.

Security

Implement appropriate administrative and technical controls.

Incident Management

Maintain a 72-hour breach notification procedure.

Data Subject Rights

Create a reliable internal response mechanism.

Frequently Asked Questions About KVKK Compliance for Fintech Companies

Does KVKK apply to fintech companies in Turkey?

Yes.

Fintech companies processing personal data in Türkiye may be subject to Law No. 6698 regardless of whether they are also regulated by the CBRT, BRSA, CMB or MASAK.

Are payment institutions subject to KVKK?

Yes. Payment institutions are subject to KVKK, and in July 2026 the Personal Data Protection Authority published a dedicated Good Practices Guide covering the payment and electronic money sector.

Are electronic money institutions subject to KVKK?

Yes. Digital wallets, payment transactions, identity information and financial records processed by electronic money institutions fall within the data protection framework.

Are crypto exchanges subject to KVKK?

Yes. Where wallet addresses, blockchain transactions and customer accounts can be linked to identifiable individuals, the platform may process personal data in addition to its ordinary identity, KYC and financial records.

Does all personal data processing require consent?

No.

KVKK provides multiple legal grounds for processing. Explicit consent should generally be used only where another applicable statutory ground does not justify the processing.

Should the privacy notice and consent be combined?

No.

The Board’s 2026/347 Principle Decision expressly states that privacy notices and explicit consent represent different legal concepts and should be presented separately.

Does KVKK apply to biometric verification?

Yes. Biometric information is special-category personal data and must satisfy Article 6 and the applicable security requirements.

Can fintech customer data be transferred abroad?

Potentially, but Article 9 must be satisfied.

The current framework uses adequacy decisions, appropriate safeguards such as standard contracts and BCRs, and limited occasional exceptions.

Has Türkiye published an adequacy-country list?

As of July 2026, the Authority states that no countries have yet been designated as providing adequate protection under the current system.

How quickly must a standard contract be reported?

The signed standard contract must be notified to the Authority within five business days.

Can a fintech use AWS, Azure or another foreign cloud service?

Potentially, but the company must review both KVKK international transfer requirements and any stricter sector-specific financial information-systems or localisation requirements.

How quickly must a personal data breach be reported?

The Board interprets the statutory requirement to notify “as soon as possible” as requiring notification to the Board no later than 72 hours after the controller becomes aware of the breach.

Does every fintech need VERBIS registration?

Not necessarily. Registration depends upon the applicable exemption criteria. Current exemptions consider employee numbers, balance-sheet totals and whether the controller’s principal activity involves special-category personal data.

Does VERBIS registration mean a company is KVKK compliant?

No.

VERBIS registration is only one obligation. A company must separately address lawful processing, privacy notices, security, international transfers, data subject rights and other requirements.

Conclusion: Building a KVKK-Compliant Fintech Business in Turkey

Data Protection and KVKK compliance for fintech companies in Turkey should be treated as part of the regulatory infrastructure of the business rather than a privacy notice added to the website shortly before launch.

Modern fintech platforms process large and interconnected data sets.

A payment institution may know who a customer pays.

An electronic money institution may know how funds enter and leave a wallet.

An open banking company may consolidate information held across multiple financial institutions.

A crypto platform may connect an identified customer with blockchain transactions.

A BaaS interface provider may combine banking information with an existing digital ecosystem.

These capabilities create substantial commercial value.

They also create substantial legal responsibility.

The first compliance step is to understand the data.

Every fintech company should create a detailed inventory identifying:

what personal data is processed, why it is processed, where it is stored, who has access and where it is transferred.

The legal basis should then be determined separately for each processing purpose.

One of the most important principles is that explicit consent should not be treated as a universal solution.

Where personal data is required to perform a contract, comply with a legal obligation or satisfy another Article 5 condition, the institution should identify that legal ground accurately.

This issue became even more important following the Board’s 2026/347 Principle Decision, publicly announced on 20 July 2026.

The Board made clear that privacy notices and explicit consent must not be improperly merged, that unnecessary consent should not be requested where another legal basis applies and that privacy notices must clearly identify actual processing activities and legal grounds.

For payment institutions and electronic money businesses, another major 2026 development is the new Good Practices Guide on the Protection of Personal Data in the Payment and Electronic Money Sector, published on 14 July 2026.

The Guide provides sector-specific direction concerning processed data, controller/processor relationships, legal grounds, personal data transfers, security and controller responsibilities.

International data transfers represent another critical area.

The 2024 amendment of Article 9 fundamentally changed Türkiye’s cross-border transfer regime.

As of July 2026, no countries have yet been formally designated as adequate by the Board. Fintech companies using international cloud, SaaS, cybersecurity or group-company systems must therefore generally identify another legally valid transfer mechanism.

For many businesses, the most practical option will be the Authority’s standard contracts.

However, the correct contract must be selected and the signed document must be notified to the Authority within five business days. Multinational groups may alternatively consider Binding Corporate Rules, while customised undertakings may require Board approval.

Fintech companies should also remember that KVKK compliance does not automatically satisfy financial-sector information systems regulation.

A cloud transfer may satisfy Article 9 but still violate a CBRT, BRSA or other sector-specific localisation requirement.

The compliance analysis should therefore always consider both:

general data protection law, and

sector-specific financial regulation.

Cybersecurity is equally central.

Article 12 requires controllers to take necessary technical and administrative measures to prevent unlawful processing, prevent unlawful access and protect personal data. The Authority’s guidance places particular emphasis on security measures appropriate to the nature and risks of the data processed.

Where a breach nevertheless occurs, the incident response process must move rapidly.

The Board’s established interpretation requires notification to the Authority within no more than 72 hours after becoming aware of the breach, together with timely notification to affected individuals.

For a 24/7 fintech platform, this requires an incident management structure capable of operating outside ordinary office hours.

VERBIS must also be reviewed.

Following the 2025 amendments, exemptions are generally available for non-special-category-primary-business controllers only where both the employee count is below 50 and the annual balance-sheet total is below TRY 100 million. Different lower thresholds apply where processing special-category personal data is the principal activity.

Rapidly growing fintech startups should therefore reassess VERBIS status each year.

Ultimately, effective fintech data protection requires cooperation between:

• legal;
• compliance;
• product;
• information security;
• software development;
• management.

The legal department cannot achieve KVKK compliance alone.

Developers determine which SDKs collect information.

Product teams determine which fields customers complete.

Compliance teams determine what KYC data must be retained.

Cybersecurity teams determine who can access information.

Management determines whether sufficient resources are allocated.

The most effective approach is therefore to embed privacy into the design of the fintech product itself.

Before launching a feature, the company should ask:

Do we need this data?

What legal basis allows us to process it?

Who will receive it?

Will it leave Türkiye?

How long will we keep it?

How will we protect it?

What happens if it is compromised?

For businesses seeking to establish or operate a payment institution, electronic money institution, digital wallet, open banking company, digital bank, BaaS platform, crypto exchange or other fintech company in Turkey, these questions should be answered before customer data begins flowing through the platform.

A well-designed KVKK compliance programme can reduce regulatory exposure, improve cybersecurity, strengthen investor confidence and increase customer trust.

More importantly, as Turkish financial services become increasingly digital, the ability to protect customer data will increasingly become inseparable from the ability to operate a sustainable fintech business.

Legal Disclaimer: This publication provides general information concerning personal data protection and KVKK compliance for fintech companies in Türkiye as of July 2026. It does not constitute legal advice. Data protection rules, VERBIS thresholds, international transfer procedures, sector-specific information systems requirements and Board practices may change. Every fintech business should be analysed individually based on its products, customer profile, technology infrastructure, data flows and regulatory status.