Introduction: Can Fintech Companies Outsource Technology in Turkey?

Modern fintech companies rarely build every part of their technology infrastructure internally.

A payment institution may rely on third-party providers for:

• cloud infrastructure;
• customer relationship management software;
• fraud monitoring;
• cybersecurity;
• identity verification;
• data analytics;
• customer support;
• API management;
• software development;
• database services;
• disaster recovery;
• transaction monitoring.

Electronic money institutions, digital wallets, open banking companies, crypto businesses and digital banking businesses are similarly dependent on external technology.

Outsourcing is therefore commercially unavoidable for many modern financial institutions.

Turkish financial regulation does not generally prohibit fintech outsourcing.

However, regulated financial companies cannot outsource responsibility together with the technology.

For payment and electronic money institutions, the principal rules are contained in Law No. 6493, the Payment Services Regulation and, most importantly for technology outsourcing, the Communiqué on Information Systems of Payment and Electronic Money Institutions and Data-Sharing Services of Payment Service Providers.

The Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”) currently lists this Communiqué as one of the central secondary regulations governing the Turkish payment and electronic money sector.

Article 16 of that Communiqué creates the core outsourcing framework.

It expressly allows a payment or electronic money institution to outsource all or part of its information systems, but only where the institution retains the decision-making power and responsibility regarding matters such as information-systems management, access, control, updating, reporting and related functions.

This creates the central rule of Turkish fintech outsourcing law:

A regulated fintech may outsource technology, but it cannot outsource regulatory responsibility.

That principle affects every cloud, SaaS, cybersecurity and technology contract entered into by a payment or electronic money institution.

It also means that an ordinary SaaS agreement drafted for an unregulated technology company may be insufficient for a Turkish regulated fintech.

The agreement may need to address:

• regulatory access;
• audit rights;
• business continuity;
• subcontractors;
• data destruction;
• service levels;
• cybersecurity;
• exit arrangements;
• data localization.

For foreign technology companies supplying Turkish fintech institutions, understanding these requirements can be just as important as understanding Turkish law for the regulated institution itself.

This guide explains the fintech outsourcing regulatory framework in Turkey as of July 2026.

1. What Is Fintech Outsourcing?

Outsourcing generally occurs where a financial institution obtains a function, service or technological capability from an external provider rather than performing it entirely through its own employees and systems.

Common fintech outsourcing examples include:

Cloud Infrastructure

A provider supplies:

• computing capacity;
• database infrastructure;
• storage;
• disaster recovery.

Software as a Service – SaaS

The institution uses third-party software for:

• CRM;
• fraud prevention;
• transaction monitoring;
• customer service;
• workflow management.

Cybersecurity Services

Third parties may provide:

• penetration testing;
• security monitoring;
• vulnerability management;
• threat intelligence.

Customer Technology

A vendor may provide:

• remote onboarding;
• biometric verification;
• digital identity technology;
• mobile application infrastructure.

Development Services

External software developers may build or maintain:

• APIs;
• payment applications;
• dashboards;
• back-office systems.

The legal treatment depends on how critical the outsourced activity is and which information the provider can access.

2. Payment and Electronic Money Institutions Can Outsource Information Systems

Article 16 of the CBRT Information Systems Communiqué expressly allows institutions to outsource all or part of their information systems.

However, the institution must retain decision-making authority and responsibility concerning relevant information-system functions.

This means the institution cannot tell the CBRT:

“Our cloud provider controls the system, so this issue is outside our responsibility.”

The regulated institution remains accountable.

The same applies where a third-party developer:

• operates the database;
• maintains security controls;
• manages access;
• runs part of the payment application.

Outsourcing changes who technically performs the function.

It does not change which entity is legally responsible to the regulator.

3. Management Responsibility Continues After Outsourcing

The Communiqué is particularly explicit on this issue.

Where an institution outsources information-system functions:

• the institution’s responsibility continues;
• senior management’s responsibility continues;
• obligations toward relevant third parties continue;
• licensing conditions applicable to the institution remain unchanged.

Therefore:

Outsourcing is not regulatory delegation.

A payment institution cannot transfer its statutory obligations to:

• Amazon-like cloud companies;
• software vendors;
• cybersecurity providers;
• payment processors;
• overseas group companies.

The institution must remain capable of demonstrating compliance itself.

4. Senior Management Must Establish Vendor Oversight

Fintech outsourcing is not merely a procurement decision.

Article 16 requires senior management to establish an adequate oversight structure capable of assessing and managing the risks created by outsourcing.

At minimum, management must monitor outsourced services concerning:

• availability;
• performance;
• quality;
• security incidents;
• the provider’s security controls;
• financial condition;
• contractual compliance.

These matters must be reported to the board at least annually.

Accordingly, vendor management should not end when the contract is signed.

A regulated fintech should maintain an active third-party risk-management programme.

5. Vendor Due Diligence Is Mandatory in Practice

The Communiqué requires the institution to exercise appropriate care when selecting an external service provider.

A proper vendor review may therefore examine:

Financial Condition

Can the provider continue operating?

Technology Capacity

Can it support required transaction volumes?

Cybersecurity

Does it maintain appropriate controls?

Data Access

Which employees and subcontractors can access customer information?

Business Continuity

How will services continue after a data-centre failure?

Regulatory Cooperation

Will the provider permit CBRT and audit access?

Subcontractors

Which additional vendors are involved?

For a critical fintech vendor, a simple commercial reference check is unlikely to be sufficient.

6. Outsourcing Must Not Weaken Internal Control

Article 16 also requires outsourcing to be structured so that it does not reduce:

• the effectiveness of internal control;
• the quality of risk management;
• the CBRT’s ability to supervise the institution.

This is one of the most important regulatory principles for large SaaS providers.

A technology company may have a standard policy stating:

“Customers may not audit our systems.”

That provision can create serious problems where the customer is a regulated Turkish payment institution.

A fintech cannot accept contractual restrictions that make regulatory supervision ineffective.

7. Business Continuity Must Be Considered Before Outsourcing

The institution must structure outsourcing in light of its business continuity plan and identify an appropriate exit strategy for unexpected termination or interruption of the outsourced service.

This means a fintech should ask before signing:

• What happens if the provider fails?
• How quickly can systems be migrated?
• Can data be exported?
• In which format?
• Who assists migration?
• Can another supplier take over?

Vendor dependency itself is a regulatory risk.

8. Exit Strategy Is a Legal Requirement, Not Merely Good Practice

Article 16 specifically requires the institution to address the risks caused by unplanned termination or interruption of outsourcing and to establish an appropriate exit strategy.

This has particular importance for:

• core banking-like payment software;
• e-wallet infrastructure;
• transaction processing;
• customer databases;
• remote onboarding.

A fintech should not become technically trapped inside one proprietary platform with no realistic migration path.

An exit strategy may include:

• data portability;
• transition periods;
• migration support;
• source-code arrangements where relevant;
• continuity access;
• secure deletion after migration.

9. The Institution Is Responsible for the Outsourcing Provider’s Actions

The Communiqué states directly that the institution is responsible for the external service provider’s actions concerning the outsourced activities.

This has major contractual consequences.

Suppose a SaaS provider:

• exposes customer information;
• incorrectly processes payment data;
• loses records.

The regulated institution cannot necessarily avoid its regulatory responsibility merely by proving that the provider caused the failure.

The commercial agreement may provide indemnification between the parties.

But indemnification does not automatically eliminate regulatory responsibility toward the CBRT or customers.

10. Third-Party Access Must Follow Least-Privilege Principles

Access given to an outsourcing provider must be specially evaluated.

The institution must assess physical and logical access according to:

• the type of access required;
• value of the information;
• provider security controls;
• impact on institutional information security.

Article 16 also provides that access given to the provider must be limited to the information required for the work.

This is essentially a regulatory version of the least privilege principle.

A third-party developer should not automatically receive:

• production database administrator credentials;
• full KYC files;
• payment credentials

merely because technical support is easier with unrestricted access.

11. Cloud Computing Is Permitted—But Subject to Strict Conditions

One of the most important parts of Article 16 concerns cloud computing.

The Communiqué allows institutions to use cloud services established in Türkiye for data processing, storage and transmission.

However, the permitted cloud architecture depends heavily on the information involved.

The rules become substantially stricter where cloud systems process:

• sensitive customer data;
• competition-sensitive data;
• personal data;
• information capable of identifying or being associated with customers.

For such information, the ordinary rule is that cloud services must operate through a private cloud model using hardware and software resources dedicated exclusively to the institution.

12. Private Cloud Is a Central Regulatory Concept

The private-cloud requirement means that a regulated payment or electronic money institution cannot automatically move sensitive production systems into any ordinary shared multi-tenant public-cloud environment.

For covered customer-related data, Article 16 requires a structure in which hardware and software resources are allocated specifically to the institution, unless the relevant community-cloud alternative applies.

Therefore, when evaluating a global cloud provider, the key question is not:

“Does this company have a famous cloud brand?”

The question is:

“Does the proposed architecture satisfy the Turkish financial-sector requirements applicable to this specific data and system?”

13. Community Cloud Provides an Alternative

The CBRT also allows a community cloud architecture.

In that model, physical hardware and software resources can be shared, but separate logical resources are allocated to each payment service provider.

The environment must be restricted to payment service providers or other regulated credit/financial institutions meeting the conditions in the Communiqué, and the external service provider must be approved by the CBRT for community-cloud services.

Community cloud therefore creates a regulated alternative between:

fully dedicated private cloud

and

ordinary public multi-tenant cloud.

14. Community Cloud Providers Require CBRT Approval

Community cloud is not simply a marketing label.

The external service provider must satisfy the CBRT’s suitability framework.

The CBRT’s current Community Cloud Guide requires providers to satisfy detailed requirements concerning matters such as:

• corporate eligibility;
• technical personnel;
• data-centre standards;
• information-security certification;
• business continuity;
• cloud-security certification;
• penetration testing;
• risk management;
• domestic primary and secondary infrastructure.

At the time reflected in the CBRT’s 2025 Annual Report, six external service providers had received suitability approval to offer community-cloud services to payment and electronic money institutions, and nine additional payment/e-money institutions had been approved to use such environments during 2025.

This demonstrates that community cloud is a functioning regulatory model rather than a theoretical exception.

15. The Community Cloud Provider Is Also Closely Supervised

The CBRT Community Cloud Guide requires approved providers to maintain significant technology and organisational infrastructure.

The February 2025 version of the Guide includes requirements concerning certifications such as information-security, business-continuity and cloud-security management standards and requires primary/secondary systems and data-backup infrastructure dedicated to the community-cloud service to be located in Türkiye.

This means a fintech selecting community cloud is not merely choosing a hosting vendor.

It is entering a regulated infrastructure relationship.

16. Customer-Free Test and Development Environments Receive More Flexibility

Article 16 contains an important practical exception.

The special cloud restrictions in paragraph seven do not apply in the same way to test and development environments that:

• contain no customer data;
• have appropriate security measures.

This can create greater flexibility for software development.

A fintech may therefore be able to use broader cloud tooling for:

• development;
• automated testing;
• CI/CD environments,

provided real customer data is not introduced into those systems and appropriate security controls remain in place.

A common compliance mistake is copying production data into development databases.

Doing so can fundamentally change the regulatory analysis.

17. SaaS Is Not Automatically the Same as Cloud Infrastructure

Software as a Service and cloud hosting should be distinguished.

A fintech may use SaaS for:

• project management;
• CRM;
• helpdesk;
• fraud detection;
• analytics.

The regulatory treatment depends on what the system does and which data it handles.

Article 16(12) provides proportionate treatment for services that:

• have no potential to affect confidentiality, integrity, availability or service continuity;
• do not require sharing sensitive customer or customer information;
• are not specially designed for the institution.

For such services, the detailed outsourcing contract requirements apply only to the extent compatible with the nature of the service.

This creates an important risk-based distinction.

A generic office productivity tool and a SaaS provider processing payment authentication information should not be treated as identical vendor risks.

18. Critical SaaS Requires Full Regulatory Analysis

A SaaS solution becomes much more sensitive where it processes:

• KYC information;
• transaction records;
• payment credentials;
• customer balances;
• fraud alerts;
• authentication data.

In those circumstances, the institution should examine:

• data location;
• service architecture;
• administrative access;
• subcontractors;
• backup location;
• encryption;
• audit rights;
• business continuity.

A SaaS provider’s standard GDPR compliance statement is not sufficient by itself.

Turkish sector-specific financial regulation must also be satisfied.

19. Primary and Secondary Systems Must Be in Turkey

Data localization is one of the most important features of the Turkish payment-sector outsourcing framework.

Article 21 requires payment and electronic money institutions to keep their:

• primary systems;
• secondary systems;
• data backup centres

in Türkiye.

The provision also states that information systems used to execute payment transactions between customers, together with their backups, must generally remain in Türkiye.

Where those functions are outsourced, the service provider’s relevant systems and backups must also be maintained domestically.

This has major consequences for international SaaS and cloud arrangements.

20. Data Localization and KVKK Are Separate Compliance Questions

One of the most common mistakes is assuming:

“Our overseas data transfer complies with KVKK, therefore our payment institution may host production systems abroad.”

That conclusion does not follow.

Two separate regimes need to be analysed.

Financial-Sector Localization

The CBRT Communiqué determines where certain systems and backups must be maintained.

KVKK International Transfer Rules

Law No. 6698 determines whether personal data may lawfully be transferred abroad.

Compliance with one regime does not automatically satisfy the other.

A contract can therefore be valid under KVKK cross-border transfer rules but still conflict with CBRT information-system localization requirements.

21. Limited Cross-Border Data Sharing Is Possible for International Payments

Article 21 contains an important cross-border payment rule.

Where a party to the payment transaction, or that party’s service provider, is located abroad, an institution can share data needed for execution of the payment with relevant foreign third parties where:

• the data continue to be stored in Türkiye;
• sharing is limited to what is necessary;
• proportionality is respected;
• sharing follows the customer’s request or instruction;
• KVKK Article 9 requirements remain satisfied.

This is fundamentally different from permanently relocating the Turkish fintech’s core database abroad.

The regulation distinguishes:

necessary cross-border transaction data exchange

from

offshore hosting of domestic regulated systems.

22. The 2026 KVKK Payment-Sector Guide Is Particularly Relevant

In July 2026, the Turkish Personal Data Protection Authority and TÖDEB completed a dedicated Good Practices Guide on Personal Data Protection in the Payment and Electronic Money Sector.

The Authority states that the Guide addresses:

• controller and processor roles;
• categories of personal data;
• processing grounds;
• transfers;
• controller obligations;
• data security.

This guidance is particularly important for outsourcing.

A cloud or SaaS vendor may be a data processor for certain purposes.

But that classification should not simply be assumed.

The factual role of the parties determines KVKK status.

23. A SaaS Vendor Is Not Automatically a Data Processor in Every Case

For example:

Payment Institution A sends customer information to Fraud Analytics Company B.

If Company B uses the information solely according to A’s instructions, it may operate in a processor-like role for that processing activity.

However, if Company B independently determines additional purposes and uses customer information for its own analytics products, the data-protection analysis may change.

Fintech outsourcing agreements should therefore map:

• data categories;
• purposes;
• instructions;
• access;
• retention;
• secondary use.

The CBRT outsourcing agreement and the KVKK data-processing framework should be drafted consistently.

24. Outsourcing Contracts Must Contain Mandatory Regulatory Provisions

Article 16(9) contains one of the most important requirements for fintech outsourcing agreements.

The contract must address, among other matters:

• service scope;
• service levels;
• rights and obligations;
• termination;
• destruction of data and records;
• business continuity;
• security and confidentiality;
• intellectual property;
• subcontractors;
• unexpected interruption;
• regulatory compliance;
• independent audit;
• CBRT access.

A standard SaaS subscription agreement will often fail to address several of these matters.

For regulated fintech, contract negotiation can therefore become a regulatory requirement.

25. Service-Level Agreements Are Required

The outsourcing agreement must define:

• scope of service;
• service levels;
• rights and obligations.

Furthermore, senior management is required to monitor provider performance using at least the service levels defined in the agreement.

This makes vague contractual language problematic.

Instead of:

“The provider will use commercially reasonable efforts to keep the service available,”

a regulated institution may need measurable standards concerning:

• uptime;
• recovery;
• incident response;
• support.

These measures become part of regulatory vendor monitoring.

26. Contracts Must Address Data Destruction at Termination

Article 16 requires contractual rules governing destruction of:

• data;
• information;
• documents;
• records

obtained by the service provider during the outsourcing relationship once the service terminates.

This is important for:

• cloud storage;
• CRM systems;
• customer support vendors;
• backup providers.

Termination should therefore include a documented:

return → migration → deletion → verification

process.

27. Subcontractors Must Be Contractually Controlled

Many global SaaS providers rely heavily on subcontractors.

Article 16 specifically requires obligations imposed on the principal external service provider to be passed into contracts with subcontractors.

This creates an important fintech principle:

Outsourcing does not end with the first vendor.

The institution should understand the full outsourcing chain.

Questions include:

• Which subprocessors have access?
• Where are they located?
• What information do they process?
• Can the main vendor change them unilaterally?

A vendor should not be able to defeat regulatory protections merely by delegating the sensitive function to another company.

28. Regulatory Audit Rights Are Mandatory

The contract must ensure that outsourced activities are subject to the same independent audit scope that would apply if the activity were performed internally.

It must also allow the CBRT, the institution and the independent auditor to obtain relevant information and documents from the external provider.

This requirement can conflict with standard contracts offered by large international technology vendors.

For example, a global provider may state:

“No customer-specific audit rights are granted.”

A regulated Turkish fintech should assess whether alternative assurance mechanisms genuinely satisfy the regulatory requirements.

29. The Provider Must Cooperate With the CBRT

The contract must require the provider to make available information and records requested by the CBRT and to maintain the systems and credentials necessary to make those records accessible and readable.

This is a significant requirement for foreign vendors.

A provider supplying critical fintech infrastructure into Türkiye should understand that the regulatory relationship is not limited to its direct customer.

The outsourcing contract must preserve supervisory access.

30. CBRT Instructions Must Be Technically Implementable

The contract must also provide for modifications required by the CBRT to be implemented by the provider within the instructed timeframe.

This means the provider cannot have unlimited discretion over release schedules where regulatory action requires urgent system modification.

For critical vendors, the institution should consider:

• emergency change procedures;
• priority escalation;
• regulatory change workflows.

31. Records Produced Through Outsourcing Belong to the Institution

The Communiqué requires contractual provisions confirming that information, documents and records relating to outsourced transactions belong to the regulated institution and must remain confidential.

This can become particularly important when the contract terminates.

A SaaS vendor should not be able to prevent the institution from accessing its legally required transaction records because of a commercial payment dispute.

32. Incident Management Must Be Built Into Vendor Contracts

Cybersecurity incidents involving third parties can quickly become regulatory incidents.

The institution should require vendors to:

• report incidents promptly;
• preserve logs;
• assist investigations;
• support regulatory reporting;
• cooperate in remediation.

The institution remains legally responsible for the outsourced activity.

Therefore, slow notification by the vendor can create significant problems for the fintech.

A contract stating that the vendor will report security incidents “when reasonably convenient” is unlikely to be suitable for critical financial infrastructure.

33. Vendor Business Continuity Must Be Tested

Business continuity should not remain theoretical.

The CBRT information-systems framework requires institutions to test their information-systems continuity plan at least annually and to plan those tests to include relevant third-party service providers connected to their systems.

For critical outsourced services, fintechs should therefore examine:

• disaster recovery;
• secondary systems;
• backup restoration;
• failover.

A vendor’s marketing statement that it has “99.99% availability” does not replace tested resilience.

34. Critical Technology Should Receive Additional Domestic-Risk Analysis

Article 16(13), added in 2023, provides that institutions should exercise maximum care to prefer critical information-system and security products that are:

• produced in Türkiye; or
• supplied by producers with R&D centres in Türkiye.

It also requires such providers/producers to have intervention teams in Türkiye. The CBRT may determine additional conditions for security products and other IT components.

This does not mean every technology component must automatically be Turkish-made.

But it creates a clear regulatory preference and a mandatory local intervention capability for covered critical providers.

35. Foreign SaaS Providers Face Practical Contracting Challenges

A foreign SaaS company selling to Turkish fintechs should expect contractual requirements that may be unfamiliar.

The customer may request:

• domestic data architecture;
• subcontractor disclosure;
• regulatory access;
• audit rights;
• local incident response;
• data deletion;
• transition support.

These requests are not necessarily unusual commercial demands.

They can arise directly from financial-sector regulation.

Foreign vendors seeking Turkish financial-sector clients should therefore design a regulated-financial-services contract package rather than insisting on the same standard SaaS terms used for ordinary businesses.

36. Group Company Outsourcing Is Still Outsourcing

A common misconception is:

“The technology company belongs to our corporate group, so outsourcing rules do not matter.”

Group relationships can create specific exceptions or special treatment in certain cloud structures, but group outsourcing does not generally eliminate the institution’s responsibility.

Where a group technology company:

• manages infrastructure;
• develops applications;
• processes data,

the regulated institution should still assess:

• access;
• continuity;
• security;
• data location;
• contractual responsibility.

Corporate ownership is not a substitute for regulatory controls.

37. Outsourced Customer Support

Customer service and call centres can also create sensitive outsourcing issues.

Support personnel may access:

• customer identity information;
• transaction histories;
• account information.

The institution should therefore consider:

• access permissions;
• authentication;
• call recording;
• confidentiality;
• social-engineering risk.

The CBRT information systems framework also requires institutions to address employee security awareness and fraud risks concerning customer-facing telephone services.

A low-cost call-centre outsourcing arrangement can therefore create significant financial-sector risk.

38. Outsourced KYC and Remote Onboarding

Fintech institutions often rely on specialist vendors for:

• NFC document reading;
• facial comparison;
• liveness tests;
• fraud detection.

Technology can be outsourced.

Regulatory responsibility for compliant customer identification remains with the regulated institution.

The CBRT framework classifies systems used in remote identification as critical information systems for purposes of the relevant technology-sourcing requirements.

Accordingly, remote onboarding vendors deserve enhanced due diligence.

39. Outsourced Fraud and AML Technology

Payment institutions commonly use SaaS products for:

• sanctions screening;
• transaction monitoring;
• fraud alerts;
• suspicious transaction analytics.

The software provider can help automate compliance.

The legal obligation remains with the regulated institution.

An institution cannot defend a regulatory failure simply by stating:

“Our AML software did not generate an alert.”

Fintech companies should therefore validate:

• rule design;
• data coverage;
• false-negative risk;
• model updates.

Outsourcing compliance technology is different from outsourcing compliance responsibility.

40. Banks Have a Separate BDDK Outsourcing Framework

The Turkish fintech sector does not operate under one universal outsourcing regulation.

Banks are subject primarily to the Banking Regulation and Supervision Agency (“BRSA” or “BDDK”), including the Bank Information Systems and Electronic Banking Services Regulation and related information-system regulations. BDDK’s current legislation database continues to list these as active banking-sector rules.

BDDK has specifically stated that its modern information-systems framework addresses matters including:

• cloud computing;
• cybersecurity;
• open banking;
• remote customer onboarding.

Therefore, a SaaS provider serving both:

• a bank;
• a payment institution

should not assume the same regulatory analysis applies to both customers.

41. BaaS Interface Providers Create Additional Outsourcing Complexity

Banking as a Service structures can involve:

• service bank;
• interface provider;
• additional technology providers.

The interface provider itself can function as a regulated support-service participant in the banking model.

Furthermore, BDDK has issued specific requirements for providers supplying identity authentication and transaction-signing technology to banks, regulated institutions and BaaS interface providers, including an authorisation/audit framework for such vendors.

This demonstrates a wider principle:

The closer a technology provider moves to a critical financial control, the more likely sector-specific requirements become.

42. Crypto Companies Also Have Their Own Technology-Regulation Layer

Crypto asset service providers are regulated by the SPK rather than the CBRT payment institution outsourcing rules.

The two Communiqués published in March 2025 regulate matters including:

• information systems;
• technological infrastructure;
• internal controls;
• risk management;
• independent audit;
• proof of reserves.

A crypto platform using:

• wallet technology;
• custody software;
• blockchain analytics;
• cloud infrastructure

must therefore conduct its outsourcing analysis under the capital-markets/crypto regime applicable to the service provider.

The SPK’s current application documentation also requests detailed information on external custody infrastructure and integrations with AML/CFT and other systems.

43. A Fintech Vendor May Face Multiple Regulators Through Different Customers

Consider Technology Company X.

It supplies the same identity verification software to:

• Payment Institution A;
• Bank B;
• Crypto Platform C.

The product is the same.

The regulatory requirements can be different.

Payment Institution A may apply CBRT Article 16.

Bank B applies the BDDK regime.

Crypto Platform C applies SPK crypto information-system requirements.

Technology companies should therefore avoid thinking:

“Our product is compliant with Turkish fintech regulation.”

There is no single fintech outsourcing standard.

The correct statement is:

“Our product has been structured to support the requirements of the specific regulated sector.”

44. Concentration Risk Is Becoming Increasingly Important

Financial institutions may become dependent on the same small group of:

• cloud providers;
• KYC vendors;
• cybersecurity platforms;
• payment processors.

This creates concentration risk.

A failure at one provider can affect many institutions simultaneously.

The CBRT Community Cloud framework addresses part of this problem by establishing detailed provider requirements and ongoing supervision.

Individual institutions should also assess:

• dependency;
• substitutability;
• migration time.

A technically excellent vendor can still create excessive concentration risk.

45. Outsourcing Register and Vendor Inventory

Even where not every third-party service receives identical regulatory treatment, a mature fintech should maintain a complete vendor inventory.

For each provider, the institution should know:

• service;
• owner;
• contract term;
• data accessed;
• system criticality;
• data location;
• subcontractors;
• recovery arrangement.

This allows the institution to identify which vendors require:

• enhanced monitoring;
• annual review;
• penetration-test evidence;
• continuity testing;
• regulatory audit rights.

Without a vendor inventory, effective third-party risk management becomes extremely difficult.

46. Contract Negotiation Should Begin Before Technology Integration

A common fintech mistake is:

1. technology team integrates the API;
2. product launches internally;
3. legal team receives the vendor agreement later.

This sequence creates unnecessary risk.

The correct process is:

classify service → classify data → assess vendor → negotiate contract → security review → integration → production.

A vendor may be technically excellent but legally unusable if it refuses:

• data localization;
• regulator access;
• required subcontractor obligations.

Fintech procurement should therefore involve legal and compliance teams early.

47. Outsourcing and M&A Due Diligence

Technology outsourcing is an important part of fintech acquisition due diligence.

An investor should determine:

Core Dependency

Which external companies operate critical infrastructure?

Data Location

Are primary systems and backups compliant?

Cloud Structure

Private cloud or approved community cloud?

SaaS Contracts

Do agreements contain mandatory Article 16 provisions?

Subcontractors

Are regulatory obligations passed down?

Audit Rights

Can CBRT and independent auditors obtain required access?

Exit

Can the business migrate if the vendor terminates service?

Cybersecurity

Have critical providers experienced incidents?

IP

Who owns custom-developed software?

A fintech may have an excellent licence and customer base but still carry serious regulatory exposure because of poorly structured vendor arrangements.

48. Common Fintech Outsourcing Mistakes in Turkey

Mistake 1: “Outsourcing Transfers Responsibility to the Vendor”

Incorrect.

The institution and senior management remain responsible.

Mistake 2: “Any Cloud Provider Can Host Payment Institution Data”

Incorrect.

Sensitive and identifiable customer information is subject to specific private-cloud/community-cloud requirements.

Mistake 3: “GDPR or KVKK Compliance Is Enough”

Incorrect.

Financial-sector localization and outsourcing rules apply independently.

Mistake 4: “All SaaS Providers Are Treated Equally”

Incorrect.

The regulatory treatment depends on data access, criticality and impact on confidentiality, integrity, availability and continuity.

Mistake 5: “A Group Company Does Not Count as Outsourcing”

Group relationships do not automatically eliminate regulatory responsibilities.

Mistake 6: “Our Vendor’s Standard Contract Cannot Be Changed”

That may make the vendor unsuitable for a regulated financial institution where mandatory audit, regulator-access or continuity requirements cannot be satisfied.

Mistake 7: “Subcontractors Are the Vendor’s Problem”

Article 16 requires relevant obligations to flow down into subcontractor contracts.

Mistake 8: “Exit Planning Can Be Done After Termination”

The institution is required to address unexpected termination and exit risk as part of the outsourcing framework.

Practical Fintech Outsourcing Compliance Checklist for Turkey

Before signing a cloud, SaaS or third-party services agreement, a Turkish fintech should answer the following questions.

Which Regulator Applies?

CBRT, BDDK or SPK?

What Is Being Outsourced?

Infrastructure, software, cybersecurity, KYC, customer support or another function?

Is the Service Critical?

Could failure interrupt regulated financial services?

What Data Will the Vendor Access?

Sensitive customer data, personal data, authentication data or ordinary corporate information?

Where Are Systems Located?

Verify primary, secondary and backup architecture.

Is Cloud Used?

Determine whether private-cloud or community-cloud conditions apply.

Is the Community Cloud Provider CBRT-Approved?

Suitability is part of the regulatory model.

Does the Vendor Use Subcontractors?

Map the entire supply chain.

Is Access Limited?

Apply least-privilege controls.

Has Vendor Risk Been Assessed?

Financial, operational, security and concentration risk should be reviewed.

Are Service Levels Measurable?

Define uptime, response and recovery requirements.

Does the Contract Protect Regulatory Audit Rights?

CBRT, the institution and relevant auditors must retain necessary access.

Does the Contract Address Data Ownership?

Records should remain under the institution’s control.

Is There an Exit Strategy?

Plan migration before the relationship fails.

Is Data Destruction Documented?

Define what happens after termination.

Does the Provider Support Business Continuity?

Include the provider in continuity planning and testing where appropriate.

Is KVKK Compliance Separately Analysed?

Data-processing and international-transfer rules remain applicable.

Can the Vendor Implement Regulatory Changes Quickly?

Include regulatory change mechanisms.

Frequently Asked Questions About Fintech Outsourcing in Turkey

Can payment institutions outsource their information systems?

Yes. Article 16 expressly permits outsourcing of all or part of information systems provided decision-making power and responsibility remain with the regulated institution.

Does outsourcing transfer regulatory responsibility?

No. The institution and its senior management remain responsible, and licensing obligations do not change because a function is outsourced.

Can Turkish payment institutions use cloud computing?

Yes, but cloud use is subject to specific CBRT requirements. Cloud services under the framework must be established in Türkiye, and sensitive/customer-identifiable data trigger stricter private or approved community-cloud requirements.

Can a payment institution use an ordinary public cloud for sensitive customer data?

The CBRT rule requires sensitive customer, personal and customer-identifiable information to be processed within the permitted dedicated private-cloud or approved community-cloud structures. An ordinary architecture that does not meet those conditions should not be assumed compliant.

What is private cloud under the Turkish fintech rules?

For relevant sensitive information, the private-cloud model uses hardware and software resources dedicated exclusively to the institution.

What is community cloud?

Community cloud allows physical resources to be shared among qualifying regulated institutions while logical resources are separately allocated to each institution, provided the service is offered by a provider satisfying the CBRT framework.

Does the community cloud provider need CBRT approval?

Yes. The community-cloud model requires an external service provider deemed suitable by the CBRT.

How many community-cloud providers were approved?

The CBRT’s 2025 Annual Report states that six external service providers had received suitability approval at the relevant reporting point.

Can development systems use broader cloud solutions?

Article 16’s special cloud restriction does not apply in the same way to test and development environments containing no customer data where appropriate security measures are implemented.

Must payment institution systems be located in Turkey?

Primary systems, secondary systems and data backup centres must generally be located in Türkiye. Information systems and backups used for customer payment transactions are also subject to domestic-location requirements.

Can payment data ever be shared abroad?

Where a party to the transaction or its service provider is abroad, necessary transaction data may be shared under the conditions in Article 21(4), while data continue to be stored in Türkiye and KVKK Article 9 obligations remain applicable.

Does KVKK compliance allow core fintech systems to be hosted abroad?

Not automatically. KVKK international transfer compliance and CBRT financial-sector data/system localization are separate legal questions.

What must an outsourcing contract contain?

Article 16 requires matters including service scope, service levels, termination, data destruction, continuity, security, IP, subcontractors, audit rights, regulator access and unexpected interruption risk to be addressed.

Must subcontractors comply with the same requirements?

The contract must ensure applicable obligations imposed on the main provider are also included as binding provisions in subcontractor agreements.

Can the CBRT inspect an outsourcing provider?

The outsourcing contract must preserve the CBRT’s right to obtain relevant information and documents and access required records and systems.

Can the CBRT require outsourcing to stop?

Yes. Article 16 authorises the CBRT to require termination of outsourcing where it concludes that outsourcing negatively affects proper operation of the system or where the provider obstructs supervisory activities.

Are banks subject to the same outsourcing rules as payment institutions?

Not exactly. Banks are primarily governed by the BDDK banking information-systems framework rather than the CBRT payment/e-money information systems outsourcing regime.

Are crypto companies subject to the CBRT outsourcing regulation?

Crypto asset service providers operate principally under the SPK crypto regulatory framework. The 2025 crypto Communiqués impose separate information-systems, internal-control, audit and technological infrastructure requirements.

Conclusion: How Should Fintech Outsourcing Be Structured in Turkey?

Fintech outsourcing regulation in Turkey is based on a principle that is easy to state but demanding to implement:

Technology can be outsourced. Regulatory responsibility cannot.

For payment and electronic money institutions, Article 16 of the CBRT Information Systems Communiqué is the core provision.

It expressly permits outsourcing of information systems, but only where decision-making authority and responsibility remain with the regulated institution.

Senior management must therefore remain involved.

Management must assess outsourcing risk, establish adequate vendor oversight and monitor matters including:

• availability;
• performance;
• security incidents;
• financial condition;
• contractual compliance.

The results must be reported to the board at least annually.

This makes third-party risk management a board-level fintech governance issue.

Cloud computing creates the next major regulatory layer.

Turkish payment institutions are not prohibited from using cloud technology.

However, the architecture matters.

For sensitive customer data, competition-sensitive data, personal data and customer-identifiable information, Article 16 generally requires a dedicated private cloud structure or the regulated community cloud alternative.

This means cloud procurement should not start with:

“Which global provider is cheapest?”

It should start with:

“Which architecture is legally permissible for the data and systems we intend to process?”

Community cloud provides an important alternative.

Where the CBRT approves the external service provider, physical infrastructure can be shared among qualifying financial institutions while logical resources remain separated for each regulated customer.

The CBRT’s Community Cloud Guide establishes substantial requirements concerning:

• technical capacity;
• information-security certification;
• business continuity;
• penetration testing;
• risk management;
• domestic infrastructure.

The model is already operational. The CBRT’s 2025 Annual Report recorded six approved community-cloud service providers at the relevant reporting point.

Data localization represents another central issue.

Payment and electronic money institutions must generally keep their primary systems, secondary systems and backup centres in Türkiye.

The rule extends to outsourced systems involved in domestic payment transactions.

Therefore, a fintech should not confuse:

lawful international personal-data transfer

with

lawful offshore hosting of regulated financial infrastructure.

They are separate questions.

Article 21 does allow limited cross-border transaction data sharing where a party or its provider is abroad, but the information must continue to be stored in Türkiye and the transfer must remain necessary, proportionate and compliant with KVKK Article 9.

This architecture enables international payments without removing domestic regulatory control over the Turkish institution’s core systems.

SaaS services require a more nuanced analysis.

Not every SaaS subscription should receive the same compliance treatment.

A generic collaboration tool that never processes customer data is different from a cloud fraud engine processing:

• customer identities;
• balances;
• transactions.

Article 16 itself applies a proportional approach to services that do not affect system confidentiality, integrity, availability or continuity and do not involve sensitive customer information.

This makes vendor classification essential.

A fintech should therefore classify third-party services according to:

criticality → data → access → operational dependency.

The outsourcing contract is equally important.

Article 16 requires detailed provisions addressing:

• service levels;
• termination;
• data destruction;
• business continuity;
• security;
• intellectual property;
• subcontractors;
• regulatory compliance;
• audit;
• CBRT access.

For this reason, standard SaaS contracts often require significant amendment before they are suitable for a Turkish regulated fintech.

Subcontractors deserve particular attention.

Modern technology supply chains can involve:

fintech → SaaS provider → cloud company → security vendor → support provider.

Article 16 requires relevant contractual obligations to flow into subcontracting arrangements.

Therefore, the regulated institution should understand not merely its immediate supplier but the full chain through which sensitive systems and information are processed.

Exit planning is another mandatory element.

The CBRT requires institutions to prepare for unexpected termination or interruption.

For critical outsourcing, a fintech should be able to answer:

How quickly could we replace this provider?

Can our data be exported?

Can another provider operate the system?

Will regulatory records remain accessible?

A vendor that cannot realistically be replaced may create a substantial operational concentration risk.

The regulatory structure also preserves strong supervisory rights.

The CBRT, the institution and relevant independent auditors must be able to obtain the information necessary to examine outsourced functions.

Moreover, the CBRT can require an institution to stop outsourcing where the arrangement harms the system’s proper functioning or obstructs regulatory supervision.

Accordingly, the regulated institution should never sign a technology agreement that effectively places the provider beyond regulatory reach.

KVKK now adds an increasingly detailed data-protection layer.

The Personal Data Protection Authority’s July 2026 sector guide specifically covers controller/processor relationships, processing, transfers and data security in the payment and electronic money sector.

Every major fintech outsourcing project should therefore contain both:

a regulatory outsourcing analysis

and

a KVKK data-processing analysis.

For banks and crypto companies, the framework changes.

Banks operate principally under BDDK information-system and outsourcing regulation, while crypto asset service providers are governed by the SPK’s post-2024 capital-markets framework and the two major crypto Communiqués adopted in March 2025.

This produces an important practical conclusion for technology companies:

There is no single Turkish “fintech outsourcing compliance” standard applicable to every financial customer.

A vendor selling the same SaaS product to a:

• payment institution;
• bank;
• crypto platform

may face three different regulatory analyses.

For fintech founders and investors, the recommended outsourcing process is therefore:

classify service → identify regulator → classify data → determine system criticality → assess localization → assess cloud architecture → perform vendor due diligence → review subcontractors → negotiate regulatory contract → create exit strategy → complete cybersecurity/KVKK review → obtain internal approval → deploy → monitor continuously.

The final step—continuous monitoring—is just as important as the initial contract.

Financial technology changes rapidly.

Vendors change infrastructure.

Subprocessors change.

Cloud regions change.

Security risks change.

A contract that was compliant when signed can become problematic if the technical architecture later changes without regulatory review.

The best Turkish fintech outsourcing model is therefore not simply one with a strong contract.

It is one with continuous vendor governance.

The central rule can ultimately be stated as follows:

Outsourcing should allow the fintech to benefit from specialist technology without reducing the regulator’s visibility, the institution’s control or the customer’s protection.

When that principle is respected, cloud, SaaS and third-party technology can be used extensively within the Turkish fintech ecosystem.

When it is ignored, outsourcing can become a direct threat to:

• licence compliance;
• information security;
• business continuity;
• personal data protection;
• regulatory supervision.

For payment institutions, electronic money institutions, banks, crypto companies and the technology companies serving them, fintech outsourcing should therefore be treated not merely as procurement—but as a core element of financial regulatory compliance.

Legal Disclaimer: This publication provides general information concerning fintech outsourcing, cloud computing, SaaS, information-system services and third-party providers in Türkiye as of July 2026. It does not constitute legal, cybersecurity, financial or regulatory advice. Outsourcing requirements depend on the regulated institution, service, data categories, cloud architecture, system criticality, provider location and subcontracting structure. Each outsourcing arrangement should therefore be individually reviewed under Law No. 6493, the current CBRT Payment Services Regulation and Information Systems Communiqué, BDDK regulations where applicable, SPK regulations for capital-market and crypto institutions, Law No. 6698 and current sector-specific guidance before implementation.