Introduction: Cybersecurity Is Now a Core Fintech Regulatory Requirement in Turkey

Cybersecurity has become one of the most important legal and operational requirements for companies operating in the Turkish financial technology market.

A fintech business may provide its services entirely through digital channels. Customers can open accounts remotely, store electronic money, initiate payments, access banking information through open banking APIs, obtain digital banking services or trade crypto assets without entering a physical financial institution.

This digital model creates significant commercial opportunities.

However, it also creates systemic cybersecurity risks.

A successful cyberattack against a fintech platform may expose:

• customer identity information;
• payment credentials;
• financial transaction histories;
• electronic money balances;
• banking information;
• crypto private keys;
• wallet information;
• authentication credentials;
• personal data.

A cyber incident may also make the financial service completely unavailable.

For this reason, Turkish law increasingly treats cybersecurity not simply as a technical issue but as a financial regulatory, corporate governance and legal compliance obligation.

The regulatory framework is multi-layered.

The principal authorities include:

• the Cyber Security Presidency of Türkiye under the general Cybersecurity Law;
• the Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”) for payment institutions and electronic money institutions;
• the Banking Regulation and Supervision Agency (“BRSA” or “BDDK”) for banks, digital banks and banking information systems;
• the Capital Markets Board of Türkiye (“CMB” or “SPK”) for crypto asset service providers and capital-market institutions;
• the Personal Data Protection Authority under Law No. 6698 (“KVKK”).

The Turkish regulatory structure therefore does not impose one universal cybersecurity rule applicable identically to every fintech company.

Instead:

the applicable cybersecurity obligations depend heavily upon the regulatory classification of the company and the financial services it provides.

A payment institution, digital bank and crypto exchange may all operate through mobile applications, but they are subject to different sector-specific information systems rules.

In addition, the enactment of Cybersecurity Law No. 7545, published on 19 March 2025, introduced a broader national cybersecurity framework applying to entities operating in cyberspace, including private legal entities.

Fintech companies should therefore develop cybersecurity compliance through a coordinated framework covering sector regulation, the Cybersecurity Law, data protection and contractual obligations.

1. The New Turkish Cybersecurity Law

One of the most important recent developments is Law No. 7545 on Cybersecurity.

The Law was adopted on 12 March 2025 and published in Official Gazette No. 32846 on 19 March 2025.

Its scope is deliberately broad.

Article 2 applies to public authorities, professional public organisations, natural and legal persons and organisations without legal personality that operate, provide services or otherwise exist within cyberspace.

Consequently, fintech companies should not assume that cybersecurity regulation is limited to financial-sector legislation.

The Cybersecurity Law creates an additional national framework operating alongside CBRT, BRSA, CMB and KVKK requirements.

2. The Cyber Security Presidency

Türkiye established the Cyber Security Presidency as the principal national authority responsible for coordinating cybersecurity policy and protecting critical infrastructure.

The Presidency’s official website confirms that it was established under Presidential Decree No. 177 and that Cybersecurity Law No. 7545 provides the principal statutory framework for its powers.

The Presidency has responsibilities extending to matters such as:

• national cybersecurity strategy;
• critical infrastructure;
• cyber threat management;
• cybersecurity standards;
• certification;
• cybersecurity products and services;
• coordination of incident response.

For fintech businesses, this means financial regulators are no longer the only public authorities that may become relevant following a serious cyber incident.

3. General Cybersecurity Duties Under Law No. 7545

Article 7 of the Cybersecurity Law imposes direct responsibilities upon persons and organisations using information systems to provide services, collect data or conduct similar activities.

Among other obligations, covered entities must:

• provide requested data, information, documents, software and hardware to the Cyber Security Presidency within the scope of its lawful functions;
• take cybersecurity measures required under applicable legislation;
• report vulnerabilities and cyber incidents detected within their service area to the Presidency without delay;
• comply with policies, strategies, action plans and regulatory measures issued to improve cybersecurity maturity.

This creates an important new compliance question for fintech companies:

Does our cyber incident procedure include the Cyber Security Presidency in addition to our financial regulator and the Personal Data Protection Authority?

Depending on the incident, several notification channels may apply simultaneously.

4. Cybersecurity Law Enforcement and Penalties

The Cybersecurity Law also contains substantial penalties.

For example, failure to fulfil specified duties concerning cybersecurity measures and critical infrastructure procurement may result in administrative fines ranging from TRY 1 million to TRY 10 million under the statutory framework.

Failure by commercial companies to comply with certain cybersecurity inspection obligations can result in fines reaching up to 5% of annual gross sales revenue, subject to the statutory minimum.

The Law also contains criminal offences concerning obstruction of authorities, unlawful activities requiring cybersecurity permission, disclosure of protected information and certain cyberattacks.

Cybersecurity compliance should therefore be treated as a board-level legal risk rather than merely an IT department responsibility.

5. Payment and Electronic Money Institutions: The CBRT Information Systems Framework

Payment institutions and electronic money institutions operate primarily under:

Law No. 6493, and

the Communiqué on the Information Systems of Payment and Electronic Money Institutions and Data-Sharing Services of Payment Service Providers in the Payment Services Area.

The CBRT continues to list this Communiqué among the principal current regulations governing payment and electronic money institutions.

The Communiqué regulates both:

• internal information systems of payment/e-money institutions; and
• technical data-sharing services relevant to open banking.

It is therefore one of the principal cybersecurity regulations applicable to Turkish fintech businesses.

6. Information Security Is a Board-Level Responsibility

The CBRT framework does not permit senior management to treat cybersecurity as a matter delegated entirely to software engineers.

Payment and electronic money institutions must prepare written information systems policies consistent with their corporate strategy and objectives.

These policies must be reviewed regularly and approved by the board of directors.

Roles and responsibilities concerning information systems must also be clearly documented.

This creates a governance principle applicable throughout modern fintech regulation:

Management can outsource technical services, but it cannot outsource regulatory responsibility.

A board should therefore understand at least:

• major cyber risks;
• critical infrastructure;
• outsourcing arrangements;
• material cybersecurity incidents;
• business continuity;
• remediation programmes.

7. Information Systems Risk Assessment

Payment and electronic money institutions must perform structured information systems risk assessments.

The current framework requires a comprehensive assessment following important changes to information systems and at least annually.

The annual assessment and related action plan must be prepared concerning the preceding year and submitted to the board and the CBRT within the regulatory timetable.

Risk analysis should not focus only on the institution’s internal servers.

It should also consider dependencies involving:

• representatives;
• outsourced service providers;
• payment systems;
• other financial institutions;
• third-party technology.

This is particularly important for fintech startups whose technology stack may depend heavily on external providers.

8. Vulnerability Scanning Requirements

The CBRT framework contains relatively detailed technical testing obligations.

Payment and electronic money institutions must conduct vulnerability scanning of relevant servers and communication networks before initial operation and subsequently on a regular basis.

The current Communiqué requires vulnerability scans at least:

six times per year.

This means vulnerability management cannot be reduced to an annual compliance exercise.

A mature programme should include:

• asset discovery;
• automated vulnerability scanning;
• severity classification;
• remediation deadlines;
• verification of remediation;
• reporting to responsible management.

Critical vulnerabilities should not remain unresolved merely because the next regulatory penetration test has not yet arrived.

9. Annual Penetration Testing for Payment and E-Money Companies

The CBRT framework also requires payment and electronic money institutions to undergo penetration testing at least once each year.

The test must be conducted by persons independent from functions responsible for information security implementation and possessing appropriate national or international penetration-testing credentials.

Testing should address internal and external threats.

For a fintech platform, penetration testing may cover:

• mobile applications;
• web applications;
• APIs;
• networks;
• authentication systems;
• payment interfaces;
• privileged access pathways.

An annual penetration test should not be treated as a substitute for continuous security monitoring.

It is one component of the overall control environment.

10. Audit Logs and Ten-Year Retention

Payment institutions and electronic money institutions are required to establish audit-trail systems capable of tracking:

• customer information access;
• physical and logical information system access;
• unauthorised access attempts;
• relevant payment-related operations.

These audit trails must generally be preserved securely, redundantly and with timestamps for at least:

ten years.

The requirement has significant technical implications.

Logging infrastructure should therefore be designed to support:

• long-term storage;
• integrity;
• searchability;
• access controls;
• forensic investigation.

Deleting security logs after 30 or 90 days because of storage cost may therefore be inconsistent with sector-specific regulatory obligations.

11. Evidence From Security Incidents Must Also Be Preserved

The CBRT information systems framework separately requires evidence relating to security incidents to be preserved securely for at least ten years.

This is particularly important following:

• fraud;
• hacking;
• unauthorised transfers;
• insider abuse;
• credential compromise.

Fintech incident response teams should therefore coordinate with legal advisers regarding digital evidence.

Containment of the attack is important, but careless remediation should not destroy evidence potentially required by:

• regulators;
• prosecutors;
• courts;
• insurers;
• customers.

12. Information Systems Business Continuity

Fintech services often operate twenty-four hours a day.

Payment and electronic money institutions are therefore required to maintain an information systems continuity plan forming part of the broader business continuity framework.

The plan should identify matters including:

• recovery targets;
• backup and disaster recovery procedures;
• acceptable downtime;
• acceptable data loss;
• roles and responsibilities;
• communication procedures;
• return from secondary to primary systems.

The plan must be tested at least annually. The current framework requires the test, where applicable, to include conducting a full day’s operations successfully through the secondary centre.

Business continuity is therefore much more than keeping a backup database.

The institution must be capable of continuing the actual financial service.

13. Cloud Computing for Payment and Electronic Money Institutions

Cloud computing is one of the most significant legal issues for Turkish fintech companies.

The CBRT framework permits institutions to obtain cloud services established within Türkiye.

However, where the cloud environment will process sensitive customer information, competitively sensitive information, personal data or other information capable of identifying customers, stricter rules apply.

The regulatory framework generally requires the use of qualifying private cloud structures or authorised community cloud models.

Therefore, a Turkish payment institution cannot necessarily move its entire production infrastructure into an ordinary global public cloud merely because the provider is internationally recognised.

The precise architecture must be reviewed under CBRT rules.

14. Community Cloud Requirements

The CBRT has issued a specific guide governing providers offering community cloud services to payment and electronic money institutions.

The framework includes requirements concerning matters such as:

• regulated nature of the service provider;
• qualified personnel;
• technological infrastructure;
• information security certifications;
• business continuity standards.

The guide, for example, requires relevant providers to maintain recognised information-security and business-continuity certifications, including ISO/IEC 27001 and ISO 22301 standards within the applicable framework.

Cloud procurement is therefore a regulated outsourcing decision rather than an ordinary IT purchasing exercise.

15. Outsourcing Does Not Transfer Responsibility

The CBRT framework expressly states that outsourcing information systems does not remove the institution’s responsibilities.

The fintech remains responsible to customers and regulators.

Outsourcing must not:

• weaken internal control;
• reduce risk-management quality;
• obstruct CBRT supervision;
• undermine business continuity.

Accordingly, contracts with technology providers should address matters including:

• audit rights;
• cybersecurity;
• service levels;
• incident notification;
• business continuity;
• subcontracting;
• access to records;
• exit assistance.

A fintech cannot defend a major cyber incident simply by saying:

“Our cloud provider was responsible.”

16. Open Banking Cybersecurity

Open banking increases the number of connections into financial systems.

Türkiye’s open banking infrastructure operates through the Payment Services Data Sharing Services (“ÖHVPS”) framework.

In March 2026, the CBRT launched ÖHVPS 2.0.0, adding expanded account information, card information, scheduled payment initiation and recurring payment functionality.

As the range of accessible financial information expands, API security becomes increasingly important.

Open banking businesses should address:

• strong authentication;
• API access control;
• encrypted communication;
• consent management;
• transaction integrity;
• certificate management;
• rate limiting;
• anomalous access detection.

A compromised API may expose financial information belonging to thousands or millions of customers.

17. Banking Cybersecurity: BRSA Framework

Banks and digital banks operate under a separate information systems framework administered by the BRSA.

The principal regulation is the Regulation on Banks’ Information Systems and Electronic Banking Services.

The BRSA continues to list this Regulation, together with separate regulations concerning:

• remote identification;
• electronic banking authentication;
• independent information systems audits;
• penetration testing

within its current banking information systems legislation.

The Regulation governs information systems management and the controls banks must maintain in providing electronic banking services.

18. Domestic Primary and Secondary Banking Systems

The banking framework contains important localisation rules.

Banks are required to maintain their primary and secondary systems in Türkiye.

Backups qualifying as part of those primary systems are treated as secondary systems and are also subject to the localisation requirement.

The regulatory approach is intended to ensure that Turkish banking services can continue domestically even where international communications are disrupted.

This distinction is especially important for international banks and technology groups.

A foreign-parent infrastructure model cannot simply be replicated in Türkiye without analysing banking localisation requirements.

19. Cloud Computing for Banks

Banks can use cloud computing, but the structure is regulated.

The banking information systems framework permits qualifying private cloud arrangements and provides for community cloud structures subject to BRSA approval.

For primary and secondary systems, private cloud models generally require dedicated hardware and software resources for the particular bank, while qualifying community cloud arrangements are subject to the regulatory conditions and Board approval.

Accordingly, cloud architecture for a bank should be reviewed before—not after—the commercial cloud agreement is signed.

20. Electronic Banking Authentication and Transaction Security

The BRSA framework specifically regulates authentication and transaction security for:

• internet banking;
• mobile banking;
• open banking;
• electronic contracts.

The BRSA also issued Circular No. 2023/1 concerning criteria for authentication and transaction security in electronic banking and electronic contract formation.

Fintech businesses partnering with banks should understand that the customer-facing interface may therefore need to satisfy banking-grade requirements concerning:

• customer authentication;
• transaction approval;
• attribution of responsibility;
• non-repudiation;
• session security.

This is particularly relevant in BaaS structures.

21. Digital Banks Have a 99.8% Continuity Requirement

Digital banks are almost completely dependent upon electronic channels.

Turkish law therefore imposes a specific continuity obligation.

For internet banking and mobile banking, a digital bank’s announced service continuity commitment cannot be lower than:

99.8%

The digital bank must publish its committed continuity level and report metrics such as MTBF and MTTR within the regulatory framework.

This requirement demonstrates how technology performance itself can become a direct regulatory metric.

Repeated downtime is therefore not merely a customer experience problem.

It can become a banking compliance problem.

22. Banking as a Service Creates Shared Cybersecurity Risk

In a Banking as a Service arrangement, the customer may access banking services through the application of an interface provider rather than through the service bank’s own application.

This creates an important security dependency.

The BaaS structure links:

• interface provider;
• service bank;
• open banking APIs;
• customer authentication.

The service bank cannot treat the interface provider’s cybersecurity as somebody else’s problem.

Because the regulated banking service is accessed through that interface, the service bank must ensure that security and authentication requirements are properly satisfied.

Third-party cybersecurity due diligence should therefore occur before a BaaS partnership becomes operational.

23. Crypto Asset Service Providers: New CMB Information Systems Framework

Crypto companies became subject to a substantially more detailed information systems regime in 2025.

On 13 March 2025, the CMB introduced:

• Communiqué III-35/B.1 governing crypto asset service providers; and
• the new Communiqué VII-128.10 on Procedures and Principles Regarding Information Systems Management.

Crypto asset service providers are expressly included within the entities subject to VII-128.10.

The crypto CASP framework also specifically regulates information systems and technological infrastructure.

Crypto cybersecurity is therefore now an express capital-markets regulatory requirement.

24. Board Responsibility Under CMB Information Systems Rules

Under Communiqué VII-128.10, information systems management forms part of corporate governance.

The board is responsible for ensuring the effective, adequate and compliant establishment and oversight of information systems controls.

Critical information systems projects must be reviewed by senior management, and the organisation must allocate appropriate resources to information security.

This is especially important for crypto platforms.

A board cannot reasonably approve a custody or wallet architecture without understanding the major risks associated with:

• private keys;
• hot wallets;
• privileged access;
• blockchain infrastructure;
• cybersecurity incidents.

25. Dedicated Information Security Officer

Communiqué VII-128.10 requires covered institutions to appoint an information security officer with appropriate technical expertise.

The person must have at least five years of relevant experience in areas such as information security, information systems auditing, governance or controls.

The officer should report to senior management and should be organisationally separated from functions responsible for fulfilling the underlying information systems management requirements.

For fintech investors, this means cybersecurity staffing requirements should be considered as part of the regulated operating model.

26. Annual Penetration Testing Under CMB Rules

Covered capital market institutions, including crypto asset service providers, must undergo penetration testing:

at least once every year.

The testing must be conducted independently by appropriately qualified persons.

The resulting penetration-testing report must generally be submitted to the CMB within one month after completion and, in any event, no later than the following 31 January.

Cybersecurity remediation should therefore operate on a formal annual regulatory cycle.

27. Network Security and Multi-Factor Authentication

The CMB information systems framework contains detailed security controls.

Among other things:

• remote access must use multi-factor authentication;
• remote access must be appropriately authorised;
• access should occur only from updated systems;
• audit trails must be maintained;
• incoming and outgoing network traffic should be analysed;
• malicious or anomalous network segments should be capable of isolation.

These requirements show that regulator expectations now extend well beyond high-level statements such as:

“The institution shall use appropriate cybersecurity.”

The rules increasingly impose operational controls.

28. Centralised Logging and Security Monitoring

Communiqué VII-128.10 requires extensive audit logging.

Audit trails must be monitored continuously, and automatic warning mechanisms should be established for unusual activity.

The framework also requires centralised log monitoring and analysis, including correlation rules designed to detect possible security incidents at an early stage.

In practical terms, regulated crypto and capital-market institutions should consider maintaining functions equivalent to:

• SIEM;
• security operations monitoring;
• automated alerting;
• incident investigation.

Merely storing logs without analysing them does not satisfy the modern regulatory objective.

29. Cyber Incident Response for Crypto and Capital-Market Institutions

Communiqué VII-128.10 requires institutions to establish controls for managing information security incidents and vulnerabilities.

A formal incident response plan must address:

• incident response team;
• responsibilities;
• communication;
• assessment;
• notification;
• recovery;
• reporting;
• lessons learned.

Where an incident has the potential to disrupt critical operations or result in a data leak, the CMB, customers and other relevant authorities must be informed immediately within the applicable framework.

Where critical systems or sensitive data are affected, the incident report must also be submitted to the CMB.

30. Computer Emergency Response Teams

The CMB framework also integrates the national SOME cyber incident response structure.

Where the sectoral SOME determines that an institution must establish an institutional SOME, the institution must create one and operate it in accordance with the relevant rules.

Relevant annual activity reporting must also be submitted within the regulatory timetable.

This is another example of how the financial cybersecurity regime increasingly intersects with Türkiye’s national cybersecurity architecture.

31. Business Continuity for Crypto Companies

Communiqué VII-128.10 contains detailed continuity requirements.

Primary and secondary systems of covered institutions are required to be located in Türkiye.

The secondary site should not be exposed to the same natural or environmental risks as the primary site.

The institution must establish recovery procedures and conduct annual continuity testing.

Most importantly, where the primary system completely fails, the regulatory objective is that operations become capable of continuing within:

24 hours.

This is a powerful example of cybersecurity translating directly into operational resilience obligations.

32. Secure Software Development

Cybersecurity regulation increasingly extends into the software development process itself.

The CMB information systems framework requires personnel involved in software development to receive secure development training.

It also requires controls concerning:

• production-system access;
• source-code changes;
• version control;
• testing;
• change management.

This is highly relevant for fintech companies developing software rapidly through agile methods.

“Move fast and break things” is not an appropriate regulatory philosophy for software controlling customer funds.

A secure development lifecycle should incorporate:

• code review;
• vulnerability testing;
• dependency management;
• release approval;
• rollback procedures.

33. Third-Party Technology Risk

Fintech companies rarely build every component internally.

External providers may supply:

• cloud infrastructure;
• KYC services;
• fraud detection;
• blockchain analytics;
• cybersecurity tools;
• software development;
• customer communication.

The CMB framework requires outsourced information systems services to be compatible with the institution’s own risk management, information security and customer confidentiality standards.

Where data is transferred to an outsourcing provider, the vendor’s information security practices should generally be at least equivalent to the institution’s own level.

Access granted to external providers should be based on:

• risk assessment;
• least privilege;
• time limitations where appropriate;
• monitoring.

Outsourcing contracts therefore need to reflect regulatory requirements rather than ordinary technology procurement terms.

34. KVKK Article 12 and Cybersecurity

Financial regulation is not the only source of cybersecurity obligations.

Article 12 of Law No. 6698 on the Protection of Personal Data requires data controllers to take appropriate technical and administrative measures to:

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

Fintech companies process substantial quantities of personal and financial information, making this requirement particularly important.

The new July 2026 sector guide for payment and electronic money institutions also specifically addresses data security alongside controller/processor roles, processing grounds and data transfers.

A fintech may therefore face simultaneous cybersecurity responsibilities under both financial regulation and KVKK.

35. KVKK Data Breach Notification: 72 Hours

Where personal data is unlawfully obtained by third parties, Article 12 of KVKK requires notification to the affected persons and the Personal Data Protection Board.

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

72 hours after the controller becomes aware of the breach.

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

This deadline should be built into the cybersecurity incident response procedure.

36. One Cyberattack Can Trigger Multiple Notification Obligations

This is one of the most important practical issues in Turkish fintech cybersecurity.

Consider a major cyberattack against an electronic money institution that exposes customer data and disrupts payment operations.

Potential notification obligations may include:

CBRT
because the institution is regulated under Law No. 6493.

Personal Data Protection Board
where personal data has been unlawfully obtained.

Affected customers
where the KVKK breach notification requirements apply.

Cyber Security Presidency
where Article 7 of the Cybersecurity Law requires the vulnerability or cyber incident to be reported without delay.

Other authorities or law enforcement bodies may also become relevant depending on the incident.

Accordingly, a fintech should not maintain separate incident response plans that do not communicate with each other.

The incident-management matrix should identify every potentially relevant regulator.

37. Cybersecurity Incident Response Team

Every material fintech should establish a multidisciplinary cyber incident response structure.

The team should include representatives from:

• information security;
• IT operations;
• legal;
• compliance;
• data protection;
• senior management;
• communications.

The first questions following an incident should include:

What happened?

Is the attack continuing?

Which systems are affected?

Are customer funds at risk?

Has personal data been accessed?

Must customers be notified?

Which regulator must be informed?

What evidence must be preserved?

Incident response should not begin by debating who is responsible for the problem.

Containment, evidence preservation and legal reporting deadlines come first.

38. Ransomware and Fintech Companies

Ransomware can create particularly serious problems for financial institutions.

Potential consequences include:

• encryption of payment systems;
• inability to access customer accounts;
• data theft;
• extortion;
• disruption of financial services.

A ransomware attack should therefore be analysed as:

• cybersecurity incident;
• business continuity event;
• potential personal data breach;
• potential criminal matter.

Backup and recovery capability is particularly important.

A backup system that is connected permanently to the compromised network may itself become encrypted and provide little resilience.

39. Multi-Factor Authentication

Multi-factor authentication (“MFA”) is increasingly a regulatory baseline.

The precise obligations depend on the regulated activity, but both banking and capital-markets information systems regulations contain strong authentication requirements.

At a minimum, privileged administrative accounts should be subject to strong authentication.

Remote access should be particularly protected.

For customer transactions, authentication mechanisms should also be structured consistently with the relevant payment or banking rules.

Password-only cybersecurity is increasingly difficult to justify for high-risk financial systems.

40. Privileged Access Management

Cyber incidents frequently involve excessive administrative access.

Fintech companies should implement the least privilege principle.

Employees should receive only the access necessary for their role.

Access rights should be reviewed when:

• responsibilities change;
• employees change departments;
• employment ends;
• external consultants complete projects.

The CMB information systems framework, for example, restricts unnecessary local administrator rights and requires special approval where such rights are needed.

Privileged access should also be logged and monitored.

41. Insider Threat Risk

Not every cybersecurity incident comes from an external hacker.

An employee may:

• copy customer data;
• misuse administrator access;
• redirect payments;
• disclose credentials;
• intentionally weaken security.

Insider risk should therefore be addressed through:

• segregation of duties;
• least privilege;
• audit logs;
• employee screening where lawful;
• monitoring;
• exit procedures.

Strong external firewalls are of limited value where one employee has unrestricted access to every critical system.

42. API Security

APIs are central to fintech.

They connect:

• banks;
• payment institutions;
• open banking providers;
• merchants;
• BaaS platforms;
• identity providers.

API vulnerabilities can allow:

• unauthorised data access;
• payment manipulation;
• customer impersonation;
• large-scale extraction of information.

A compliant API security programme should consider:

• authentication;
• authorisation;
• encryption;
• token management;
• rate limiting;
• input validation;
• logging;
• anomaly detection;
• version management.

As Turkish open banking infrastructure expands, API security will become increasingly important.

43. Cybersecurity Due Diligence Before Acquiring a Fintech Company

Cybersecurity should be a major workstream in fintech M&A.

An investor should examine:

Regulatory Framework

Which information systems regulation applies?

Cybersecurity Policies

Are policies current and board approved?

Penetration Tests

When was the last test performed and which critical findings remain unresolved?

Vulnerability Management

Are vulnerabilities identified and remediated systematically?

Security Incidents

Has the company experienced ransomware, data breaches or customer account compromise?

Regulatory Notifications

Were required incidents reported properly?

Business Continuity

Has disaster recovery actually been tested?

Logs

Are regulatory retention periods satisfied?

Cloud

Does the cloud architecture comply with sector-specific requirements?

Outsourcing

Do major vendors satisfy regulatory information security standards?

Access

Are privileged users monitored?

A company may have excellent revenue growth but still carry enormous hidden cybersecurity liabilities.

44. Common Cybersecurity Compliance Mistakes in Turkish Fintech

Treating Cybersecurity as an IT Department Issue

Boards and senior management have express regulatory responsibilities.

Using Generic ISO Policies Without Operational Controls

Policies must reflect actual systems and regulatory requirements.

Running Penetration Tests but Ignoring Findings

Testing without remediation does not meaningfully reduce risk.

Allowing Excessive Administrator Access

Least privilege and segregation of duties are fundamental.

Using Foreign Cloud Infrastructure Without Sector Review

KVKK compliance alone does not override CBRT or BRSA localisation rules.

Failing to Test Disaster Recovery

A continuity plan that has never been tested provides little assurance.

Keeping Logs for Too Short a Period

Sector regulations can impose long retention periods, including ten-year requirements for payment/e-money audit trails.

Failing to Coordinate Incident Reporting

One cyberattack may trigger CBRT, CMB, BRSA, KVKK and Cyber Security Presidency obligations.

Relying Completely on Vendors

Regulated institutions generally retain ultimate responsibility for outsourced systems.

45. Practical Cybersecurity Compliance Checklist for Fintech Companies in Turkey

Before launching or expanding a fintech business, management should verify:

Regulatory Classification

Is the company a payment institution, EMI, bank, digital bank, CASP or unregulated technology provider?

Cybersecurity Law

Has Law No. 7545 been incorporated into the incident-response framework?

Governance

Has the board approved appropriate information security policies?

Risk Assessment

Are cyber risks assessed at least at the frequency required by sector regulation?

Asset Inventory

Does the institution know which systems, data and infrastructure are critical?

Access Control

Is least privilege implemented?

MFA

Is strong authentication used for high-risk access?

Vulnerability Management

Are scans performed at required intervals?

Penetration Testing

Are annual tests completed where required?

Remediation

Are test findings tracked to closure?

Logging

Are audit trails complete, protected and retained for the statutory period?

Incident Response

Is there a formal cyber incident plan?

Regulatory Notification

Does the plan identify CBRT, BRSA, CMB, KVKK and Cyber Security Presidency triggers?

Business Continuity

Are recovery objectives documented?

Disaster Recovery

Is the secondary environment operational and regularly tested?

Cloud

Does the cloud structure comply with applicable localisation and outsourcing rules?

Outsourcing

Are vendor security and audit rights adequate?

Secure Development

Are security reviews integrated into software development?

Data Protection

Does the security programme satisfy KVKK Article 12?

Training

Do employees receive regular cybersecurity awareness training?

Frequently Asked Questions About Fintech Cybersecurity in Turkey

Is cybersecurity specifically regulated for fintech companies in Turkey?

Yes.

Different fintech sectors are subject to specific information systems regulations issued by the CBRT, BRSA and CMB. Since March 2025, Cybersecurity Law No. 7545 has also created a broader national cybersecurity framework.

Who regulates cybersecurity for payment institutions?

The CBRT regulates information systems used by payment and electronic money institutions under Law No. 6493 and the dedicated Information Systems Communiqué.

How often must payment institutions perform penetration testing?

The CBRT framework requires relevant payment and e-money information systems to be subjected to penetration testing at least once per year.

How often must they perform vulnerability scans?

Relevant servers and communication networks must be scanned at least six times annually under the current payment/e-money information systems framework.

How long must payment institution audit logs be kept?

Relevant audit trails are generally required to be retained securely for at least ten years.

Can a Turkish payment institution use public cloud services abroad?

The answer requires careful sector-specific analysis. The CBRT framework generally focuses regulated cloud use on infrastructure established domestically and imposes stricter private/community cloud conditions where customer and sensitive data are processed.

Are bank systems required to be located in Turkey?

The BRSA banking information systems framework requires banks’ primary and secondary systems to be located domestically.

What is the minimum digital-bank uptime commitment?

A digital bank’s internet and mobile banking channels cannot have a committed continuity level below 99.8%.

Are crypto exchanges subject to information systems regulation?

Yes.

Crypto asset service providers are expressly included in CMB Communiqué VII-128.10 and are also subject to information systems and technological infrastructure requirements under the dedicated CASP regulatory framework.

How often must a crypto service provider perform penetration testing?

Under VII-128.10, covered institutions must generally undergo penetration testing at least once annually, with the report submitted within the specified regulatory timetable.

Must crypto platforms maintain their systems in Turkey?

Communiqué VII-128.10 requires primary and secondary systems of covered institutions, including CASPs, to be located in Türkiye.

How quickly must a crypto institution recover from total primary-system failure?

The CMB information systems framework establishes an objective of restoring the ability to continue operations within 24 hours following complete failure of the primary system.

Does KVKK require cyber incident reporting?

Where personal data is unlawfully obtained by third parties, the controller must notify the Board and affected individuals. The Board interprets the notification deadline to the Authority as no later than 72 hours after awareness.

Does the new Cybersecurity Law create a separate notification obligation?

Yes. Article 7 requires covered entities to report vulnerabilities or cyber incidents detected within their service area to the Cyber Security Presidency without delay.

Can cybersecurity be outsourced?

Technology and cybersecurity functions can be outsourced within sector-specific limits, but regulatory responsibility generally remains with the regulated fintech institution.

Conclusion: Building a Cybersecurity-Compliant Fintech Company in Turkey

Cybersecurity and information systems compliance for fintech companies in Turkey has evolved into a sophisticated multi-regulator legal framework.

For many fintech businesses, cybersecurity is now as important as regulatory capital or licensing.

A payment institution cannot operate sustainably if its payment infrastructure is unreliable.

An electronic money institution cannot protect customer funds if attackers can obtain privileged wallet access.

A digital bank cannot operate if its mobile platform is repeatedly unavailable.

A crypto exchange cannot protect customer assets without secure wallet, custody and private-key architecture.

The legal framework reflects this reality.

At the national level, Cybersecurity Law No. 7545, effective since March 2025, applies broadly to entities operating in cyberspace. Covered organisations must take required cybersecurity measures, cooperate with the Cyber Security Presidency and report vulnerabilities and cyber incidents within their service area without delay.

For payment and electronic money companies, the CBRT information systems framework goes considerably further.

It requires board-level governance, information systems risk management, repeated vulnerability scanning, annual penetration tests, security incident controls, audit trails and business continuity arrangements.

The technical requirements are substantial.

Servers and networks must undergo vulnerability scanning at least six times per year.

Independent penetration testing must generally occur annually.

Audit trails must be securely maintained for at least ten years.

Business continuity arrangements must be tested.

Cloud infrastructure is also regulated.

Payment and electronic money institutions cannot simply move sensitive customer data to any global cloud architecture. The CBRT framework requires domestic infrastructure and imposes specific conditions concerning private and community cloud models.

Banks and digital banks face a different but similarly sophisticated framework under the BRSA.

The Regulation on Banks’ Information Systems and Electronic Banking Services governs information systems management, electronic banking, security, authentication and related risks. The BRSA also maintains separate rules concerning penetration testing, remote customer identification and electronic transaction security.

For digital banks, technological resilience is particularly visible because the regulation requires a minimum 99.8% committed continuity level for internet and mobile banking.

In the crypto sector, cybersecurity regulation has advanced even more rapidly.

Following the 2024 crypto reform and the CMB’s March 2025 secondary regulations, crypto asset service providers became subject to extensive information systems controls.

Communiqué VII-128.10 expressly applies to CASPs and addresses governance, risk management, network security, access management, outsourcing, audit trails, incident response, secure software development and business continuity.

The CMB framework requires annual penetration testing and provides detailed expectations regarding centralised monitoring and anomalous activity detection.

Primary and secondary information systems must be maintained domestically, and the continuity framework seeks restoration of operations within 24 hours following complete primary-system failure.

The development of the Turkish regulatory framework therefore demonstrates a broader trend:

Cybersecurity rules are moving away from vague obligations to maintain “appropriate security” and toward measurable operational requirements.

Regulators increasingly expect to see:

• defined security governance;
• annual or more frequent testing;
• documented remediation;
• strong access controls;
• continuous monitoring;
• secure outsourcing;
• tested disaster recovery;
• documented incident response.

Personal data regulation adds another layer.

Under Article 12 of KVKK, fintech companies must protect personal data against unlawful access and processing.

Where a personal data breach occurs, the Personal Data Protection Board generally expects notification within 72 hours after awareness.

This creates one of the most important practical lessons for fintech businesses:

A single cyber incident may trigger several legal regimes simultaneously.

The incident may need to be reported to:

• the financial regulator;
• the Personal Data Protection Board;
• affected customers;
• the Cyber Security Presidency;
• potentially other public authorities.

A fragmented incident response structure is therefore dangerous.

The fintech should maintain one central incident-management framework capable of determining all applicable regulatory notification obligations.

For foreign investors, outsourcing and cloud technology require particular caution.

A platform successfully used by the parent company in London, New York, Dubai or Singapore cannot automatically be adopted by the Turkish regulated subsidiary.

Turkish regulation may require:

• domestic primary systems;
• domestic backup systems;
• approved cloud architecture;
• specific audit rights;
• regulator access.

Cybersecurity due diligence should therefore occur before technology procurement.

The same principle applies to acquisitions.

A buyer considering a Turkish fintech should request:

• information systems audit reports;
• penetration-testing reports;
• vulnerability remediation records;
• regulator correspondence;
• cyber incident history;
• cloud architecture;
• access-control matrix;
• disaster recovery tests.

Cybersecurity liabilities are often invisible in ordinary financial statements.

A fintech may appear profitable while simultaneously operating an outdated system containing critical vulnerabilities.

Ultimately, successful fintech cybersecurity requires cooperation between:

board members, executives, cybersecurity professionals, software developers, compliance officers, data protection professionals and lawyers.

No single department can satisfy the regulatory framework alone.

Management determines resources.

Technology teams design systems.

Security teams identify vulnerabilities.

Compliance teams manage regulatory obligations.

Legal teams evaluate notifications, contracts and liabilities.

Boards remain responsible for governance.

The most effective strategy is therefore to treat cybersecurity as part of the product architecture from the beginning.

Before launching a fintech product, management should ask:

What happens if this system is compromised?

Can we detect an attacker quickly?

Can we identify exactly what the attacker accessed?

Can we continue operations if the primary system fails?

Can we restore from backup?

Do we know which regulator must be notified?

Can we prove what happened six months or five years later?

A fintech capable of answering these questions is substantially better prepared for both regulatory supervision and real-world cyber threats.

For businesses planning to establish or operate a payment institution, electronic money institution, digital wallet, open banking company, digital bank, BaaS platform, crypto exchange, crypto custody company or other financial technology business in Turkey, cybersecurity should therefore be considered one of the principal legal workstreams of the project.

The central principle is clear:

In Turkish fintech regulation, cybersecurity is no longer merely about protecting technology—it is about protecting the licence, customer assets and the continued legal ability to operate the business.

Legal Disclaimer: This publication provides general information concerning cybersecurity and information systems requirements applicable to fintech companies in Türkiye as of July 2026. It does not constitute legal, cybersecurity or investment advice. The applicable requirements depend on the institution’s regulatory classification, information systems architecture, services and data flows. Cybersecurity Presidency, CBRT, BRSA, CMB and KVKK requirements may change or be supplemented through future secondary legislation, regulatory decisions and technical standards. Each fintech company’s cybersecurity framework should therefore be reviewed individually.