Introduction: Can White-Label Fintech Solutions Operate Legally in Turkey?

Yes.

White-label fintech models can operate legally in Türkiye and can provide a highly efficient route for businesses seeking to offer financial technology products without developing every component internally.

However, the phrase “white label” has no magical regulatory effect.

A business cannot avoid a payment, electronic money, banking or crypto licence merely because the underlying technology is supplied by another company or because a regulated institution operates in the background.

Turkish financial regulation generally follows the actual function performed by each party.

The key questions are therefore:

• Who provides the regulated financial service?
• Who contracts with the customer?
• Who holds or controls customer money?
• Who issues electronic money or the payment instrument?
• Who accesses bank accounts?
• Who initiates payment orders?
• Who makes lending decisions?
• Who is presented to customers as the financial service provider?

This distinction is particularly important because “white-label fintech” can describe very different legal structures.

A company may simply licence software to a financial institution.

Another company may place its brand on a payment institution’s regulated infrastructure.

A marketplace may offer a branded wallet supplied by an electronic money institution.

A retail company may provide banking services through a Banking as a Service structure.

A technology company may provide a white-label open banking dashboard.

Although all of these structures may commercially be called white-label fintech, their regulatory treatment is fundamentally different.

The principal Turkish regulators include:

• the Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”) for payment and electronic money services;
• the Banking Regulation and Supervision Agency (“BRSA” or “BDDK”) for banking and Banking as a Service;
• the Capital Markets Board of Türkiye (“CMB” or “SPK”) for capital-market and crypto-asset service providers;
• MASAK for anti-money laundering and counter-terrorism financing;
• the Turkish Personal Data Protection Authority for KVKK compliance.

The CBRT currently identifies Law No. 6493, the Payment Services Regulation and the information-systems/data-sharing Communiqué as the core payment and electronic money regulatory framework.

Therefore, any company considering a white-label fintech product in Türkiye should carry out a regulatory perimeter analysis before launching the product under its own brand.

1. What Is a White-Label Fintech Solution?

A white-label solution is generally a product developed by one company but offered to end users under another company’s brand.

For example:

Technology Company A develops payment-account software.

Financial Institution B uses that software.

Retail Brand C may display the financial functionality inside its application.

The customer may see Brand C’s name and logo even though parts of the financial infrastructure are supplied by A and regulated services are legally provided by B.

White-label fintech products may include:

• mobile wallets;
• merchant payment platforms;
• payment gateways;
• prepaid cards;
• virtual IBAN services;
• open banking dashboards;
• payment initiation;
• business accounts;
• Banking as a Service products;
• crypto trading interfaces;
• financial management software.

The regulatory challenge is determining which party performs each legally regulated function.

2. White-Label Software Is Not Automatically a Financial Service

One of the strongest official examples comes directly from the CBRT’s open banking guidance.

The CBRT examines a scenario in which a corporate customer purchases or licences white-label software from a technology company.

The customer uses the software to consolidate information and transfer functionality relating to its own accounts at several banks.

The software:

• operates in the corporate customer’s environment;
• connects using the customer’s own access structure;
• is supplied and maintained by the technology company;
• does not make the technology company the contractual or regulatory counterparty of the banks.

The CBRT expressly defines white-label software in that scenario as third-party software that can be offered or used by the purchasing company under its own brand and logo.

Crucially, the CBRT concluded that the technology company’s activity in this model did not require Payment Initiation Service or Account Information Service authorisation.

This provides an extremely important principle for Turkish fintech:

A company can provide sophisticated white-label financial software without itself becoming a regulated payment institution where it genuinely remains a technical service provider.

3. Why Did the CBRT Treat the White-Label Provider as a Technical Company?

The legal basis lies in Law No. 6493.

Certain technical services supporting payment services are excluded from the definition of regulated payment services where the technical provider does not become the owner of the transferred funds.

The CBRT’s white-label scenario emphasises several facts:

• the corporate customer used the software for its own accounts;
• the banks’ legal and technical counterparty remained the corporate customer;
• the software provider had no independent contractual responsibility toward the banks;
• the technology company provided software licensing, integration, maintenance and technical support.

The CBRT therefore treated the company as a technical service provider rather than a regulated open banking provider.

This distinction is highly valuable for:

• SaaS companies;
• ERP providers;
• treasury-management platforms;
• accounting software;
• API infrastructure providers.

But the exemption depends on the actual structure.

4. White-Label Branding Does Not Determine the Licence

The fact that the customer uses its own brand does not determine whether the underlying provider needs a licence.

Regulators examine substance.

For example:

Model A — Pure White-Label SaaS

A fintech supplies software.

The licensed financial institution contracts directly with the customer.

The fintech never holds funds and does not independently provide the payment service.

This may remain a technology model.

Model B — Customer-Facing Financial Provider

The white-label company signs customers.

It holds itself out as providing the financial service.

It accepts payment instructions and controls customer funds.

This can move into regulated payment activity.

The software may be exactly the same in both models.

The legal role of the parties determines the regulatory outcome.

5. The Most Important Question: Who Is the Regulated Service Provider?

Every white-label fintech arrangement should identify the legally responsible provider.

For payment services, this may be:

• a bank;
• payment institution;
• electronic money institution;
• another legally recognised payment service provider.

For banking, the provider must be the relevant bank.

For crypto-asset services, the provider must fall within the CMB-authorised framework.

The white-label technology contract does not transfer the financial licence from the licensed institution to the brand owner.

This means:

A licence cannot simply be “rented.”

A company using another institution’s infrastructure cannot automatically perform every regulated activity permitted by that institution.

6. White-Label Payment Solutions

White-label payment solutions are among the most common Turkish fintech structures.

Possible products include:

• checkout platforms;
• virtual POS;
• merchant dashboards;
• payment APIs;
• reconciliation systems.

A technology provider may remain outside payment licensing where it genuinely supplies only technical infrastructure.

However, the position changes where the branded company:

• contracts with merchants as the payment provider;
• accepts payment instructions;
• receives or controls payment funds;
• provides payment accounts;
• determines merchant settlement.

The relevant activity must then be mapped against Article 12 of Law No. 6493.

The CBRT’s current authorised institution registers continue to identify payment institutions according to their precise Article 12 permissions, illustrating that a payment institution may provide only those regulated services falling within its licence scope.

7. White-Label Electronic Money Products

Electronic money creates an even more significant licensing issue.

Suppose Retail Brand A launches:

“A Pay”

Customers load TRY 10,000.

The balance is stored electronically and can be spent at third-party merchants.

Even where Electronic Money Institution B supplies all backend infrastructure, the parties must determine clearly:

• who legally receives the funds;
• who issues the electronic money;
• who safeguards the funds;
• whose customer the user is;
• who is responsible for redemption.

The CBRT confirms that every institution listed as an authorised electronic money institution has electronic money issuance authority under Article 18(2), while additional payment services depend on individual licence scope.

The white-label brand should therefore not independently describe itself as the electronic money issuer unless it actually holds the required authority.

8. Regulatory Capital Makes the Distinction Commercially Important

The distinction between a technology company and licensed financial institution creates major financial consequences.

Effective 30 June 2026, the CBRT increased minimum own-funds requirements to:

• TRY 20 million for the specified bill-payment category;
• TRY 40 million for ordinary payment institutions, excluding the separately treated pure Account Information Service category;
• TRY 105 million for electronic money institutions.

A company that genuinely remains a software provider does not become subject to these prudential thresholds merely because its software is used in payments.

By contrast, once it becomes the regulated payment or electronic money provider, regulatory capital becomes a core part of the business model.

9. White-Label Digital Wallets

Digital wallets now require particular attention.

Article 4/A of the Payment Services Regulation specifically regulates digital wallets.

The Regulation provides that digital wallet services may be offered by payment service providers and requires the provider, at minimum, to hold the relevant payment-instrument issuance authority. Additional authorisations can be required depending on functionality.

Therefore, a retail brand cannot necessarily launch a full regulated wallet merely by purchasing white-label wallet software.

The structure must identify the regulated payment service provider.

10. There Is a Specific Technical Provider Exclusion for Wallet Infrastructure

The Regulation also provides a particularly important exclusion.

A company that stores sensitive customer information on behalf of a merchant or payment service provider may remain outside the digital-wallet classification where, among other conditions:

• it does not become directly party to the customer’s payment transaction;
• it does not create the impression that payment occurs through that technology company;
• it never owns the payment funds;
• contractual responsibilities are clearly allocated.

The technical provider also cannot be the sole visible face of the service toward the customer.

This is highly relevant for white-label:

• card vaults;
• tokenisation providers;
• wallet software;
• checkout technology.

The distinction between white-label technology and white-label regulated wallet therefore needs to be carefully maintained.

11. White-Label Open Banking

Open banking is another area where white-label structures are particularly common.

A fintech may provide software allowing businesses to:

• consolidate bank balances;
• view transactions;
• prepare transfers;
• manage treasury functions.

The CBRT’s guidance provides direct examples distinguishing technical providers from regulated open banking providers.

Where the technology company merely supplies software and the bank relationship remains with the account-owning corporate customer, the technology provider does not need open banking authorisation in the scenario analysed by the CBRT.

But the result changes when the fintech itself becomes the regulated intermediary.

12. When Does White-Label Open Banking Require a Licence?

The CBRT also examines structures where a payment institution directly contracts with account-servicing institutions and customers.

Where the institution itself obtains and presents customers’ account information, the CBRT treats the activity as regulated Account Information Services.

Where it receives and forwards customers’ payment instructions, it can constitute Payment Initiation Services.

The CBRT expressly states in those scenarios that the provider requires authorisation under Article 12(1)(f) and/or (g), depending on the functions performed.

The practical distinction is clear:

software supporting the customer’s own banking relationship may remain technical;

providing consolidated account information or initiating payments as a service to customers can require a licence.

13. Open Banking Expanded Further in 2026

The regulatory importance of this issue is increasing.

On 17 March 2026, the CBRT announced ÖHVPS version 2.0.0, expanding Turkish open banking functionality.

The expanded framework includes more comprehensive account and card information and adds functionality for:

• future-dated payment initiation;
• recurring payment initiation.

White-label fintech companies building treasury, accounting or payment applications should therefore review regulatory classification whenever they introduce new open banking functionality.

A product that was previously only informational may become regulated after new transaction functionality is introduced.

14. White-Label Banking Is Different: Turkey Has a Specific BaaS Regime

White-label banking requires a separate legal analysis.

Türkiye has expressly regulated Banking as a Service (“BaaS”) through the Regulation on the Operating Principles of Digital Banks and Service Model Banking.

Under the Regulation:

• a service bank provides banking services;
• an interface provider supplies the customer-facing mobile or web interface.

The service bank may provide BaaS only to interface providers resident in Türkiye and only within the bank’s authorised banking activities. Banks themselves cannot act as interface providers.

This creates an express legal route for white-label and embedded banking models.

15. The White-Label Brand Does Not Become the Bank

This is one of the most important BaaS principles.

The interface provider cannot, without the necessary permissions, use descriptions or branding that create the impression that it is:

• a bank;
• payment institution;
• electronic money institution;
• entity accepting deposits or payment funds.

The service bank decides whether banking services—including credit—are provided, and the services are carried on the bank’s balance sheet.

Therefore, white-label branding does not transfer banking status to the fintech.

16. The Customer Must Have a Legal Relationship With the Service Bank

In a Turkish BaaS structure, the customer’s regulated banking relationship must exist with the service bank.

The Regulation requires a contractual relationship between the service bank and customer.

Where onboarding occurs electronically through the interface provider’s application, customer identification remains subject to banking remote-identification rules and the service bank’s responsibilities.

The fintech therefore supplies the interface.

The bank supplies the regulated banking product.

This distinction should be visible in:

• customer contracts;
• terms of use;
• product screens;
• marketing materials.

17. Interface Providers Carry Real Regulatory Responsibilities

The fact that the interface provider is not the bank does not mean it is unregulated in practice.

The BaaS Regulation treats the interface provider as a support-service provider for relevant functions.

The Regulation also makes the interface provider and service bank jointly responsible for compliance with specified electronic banking authentication and transaction-security requirements applicable to the customer-facing interface.

Therefore, a white-label BaaS company cannot outsource cybersecurity responsibility entirely to the bank.

18. BaaS Is Not a General Fintech Licence

The Banking as a Service framework should also not be misunderstood as a general licence exemption.

A company can act as an interface provider for banking services but may still require separate authorisation where it independently provides:

• payment services;
• electronic money;
• other regulated financial activities.

BaaS permission does not automatically authorise the fintech to become a payment institution.

Each activity must be classified separately.

19. White-Label Prepaid Cards

Prepaid cards are another common white-label model.

A retail brand may launch:

“Brand X Card”

while an electronic money institution handles:

• card issuance;
• stored balance;
• customer funds;
• redemption;
• payment processing.

This can be commercially viable.

But the regulated issuer must remain clearly identifiable.

The brand should not independently claim that it issues electronic money where another institution is legally the issuer.

The same principle applies to:

• youth cards;
• employee benefit products;
• merchant cards;
• virtual prepaid cards.

20. White-Label Virtual IBANs

A similar model can apply to virtual IBANs.

A software or commercial platform may present a customer with a branded account experience while an authorised bank, payment institution or electronic money institution legally maintains the underlying account.

This requires clear allocation of:

• account provider;
• IBAN issuer;
• funds ownership;
• transfer authority;
• safeguarding.

Calling the product:

“Your Brand X Bank Account”

can create regulatory and consumer-law problems where Brand X is merely a technology company.

The product should accurately identify whether the underlying account is:

• a bank account;
• payment account;
• electronic money account.

21. White-Label Lending Is Particularly Sensitive

Lending should not be treated as ordinary white-label software.

A technology company can provide:

• credit scoring software;
• loan origination interfaces;
• onboarding technology;
• repayment dashboards.

However, actual lending decisions and provision of regulated bank credit must remain with an appropriately authorised financial institution.

The BaaS Regulation expressly confirms that even where the customer accesses services through the interface provider, the decision whether banking services—including credit—will be offered is taken by the service bank.

A white-label brand should therefore avoid creating the impression that it independently lends money where the legal creditor is a bank or other authorised lender.

22. White-Label Crypto Solutions

Crypto white-label products require a separate regulatory perimeter analysis.

Following the 2024 amendments to the Capital Markets Law and the two major CMB Communiqués published on 13 March 2025, crypto asset service providers fall within the CMB’s regulatory and supervisory framework.

The CMB framework regulates, among other matters:

• establishment and operating permission;
• shareholders;
• management;
• internal controls;
• risk management;
• information systems;
• crypto custody;
• trading-platform activities;
• capital adequacy.

A company therefore cannot become a lawful Turkish crypto trading platform simply by purchasing white-label exchange technology.

Technology and authorisation remain separate issues.

23. A Crypto Software Provider Does Not Transfer Its Customer a CMB Licence

A white-label technology company may potentially provide:

• trading-engine software;
• wallet infrastructure;
• cybersecurity technology;
• reporting systems.

But where the branded business itself provides crypto-asset services falling within the Turkish regulatory perimeter, it must separately determine whether CMB establishment and operating permissions are required.

The CMB’s current application framework distinguishes regulated crypto platforms and custody institutions and requires formal applications under Communiqués III-35/B.1 and III-35/B.2.

A technology agreement therefore cannot substitute for a CMB licence.

24. Outsourcing Does Not Transfer Regulatory Responsibility

This is perhaps the most important principle across every white-label fintech model.

A licensed financial institution may outsource technology.

But it does not outsource away its regulatory obligations.

The CBRT’s 2021 regulatory framework specifically strengthened rules relating to:

• representatives;
• outsourcing;
• information systems;
• strong authentication;
• data security.

Accordingly, a regulated payment institution remains responsible for ensuring that its outsourced white-label technology is compatible with financial-sector regulation.

25. White-Label Technology Contracts Need Regulatory Clauses

An ordinary software licence agreement is rarely sufficient for a regulated fintech white-label arrangement.

The agreement should normally address:

Regulatory Role Allocation

Which party is the regulated provider?

Licence Scope

Which services may legally be offered?

Customer Relationship

Which entity contracts with the customer?

Funds

Which party receives and safeguards customer money?

AML/KYC

Who conducts identification and ongoing monitoring?

Data Protection

Which party acts as controller or processor for each activity?

Cybersecurity

Which party manages authentication, incidents and vulnerabilities?

Audit Rights

Can the licensed institution and regulator obtain required access?

Business Continuity

What happens if the technology provider fails?

Subcontracting

Can the vendor use other service providers?

Exit

How are customers, data and systems migrated when the agreement terminates?

In a regulated fintech environment, the contract is part of the compliance infrastructure.

26. Branding and Customer Disclosure Are Legal Issues

White-label products are designed precisely so that one company can offer another company’s technology under its own brand.

This creates an inherent regulatory tension.

The end user may not know which company actually provides the financial service.

Turkish regulation therefore places importance on avoiding misleading representations.

The BaaS rules expressly prohibit interface providers from creating the impression that they are banks or payment/e-money institutions without the necessary permissions.

Similarly, the digital-wallet rules prevent qualifying technical storage providers from becoming the only visible face of the payment service where they rely on the technical-provider exclusion.

Therefore:

White-label does not mean invisible licence holder.

The regulated provider should remain legally identifiable to the customer.

27. MASAK Responsibilities

AML compliance depends heavily on the regulatory role.

Electronic money institutions and most payment institutions are subject to formal MASAK compliance-programme requirements.

MASAK currently identifies the required programme as including:

• policies and procedures;
• risk management;
• monitoring and control;
• compliance officer and compliance unit;
• training;
• internal audit.

Certain payment institutions providing only specifically excluded services are treated differently, but ordinary full-service payment and e-money institutions fall within the formal programme structure.

A white-label company that is merely a software vendor does not become a MASAK obliged financial institution simply because its software is used by one.

But the regulated partner must ensure that the technology supports its AML responsibilities.

28. White-Label Technology Must Support KYC

The regulated institution should remain capable of controlling:

• customer identification;
• beneficial ownership;
• sanctions screening;
• PEP screening;
• transaction monitoring;
• suspicious transaction escalation.

The customer interface should not prevent the licensed institution from obtaining the information required to satisfy MASAK.

A fintech partner should therefore not design onboarding around the principle:

“Our customers should never know the licensed provider exists.”

That approach can directly conflict with regulatory responsibility.

29. KVKK: Who Is the Data Controller?

White-label fintech structures frequently create complicated personal-data relationships.

Depending on the actual processing activity:

• the licensed financial institution may be the data controller;
• the technology provider may be a processor;
• both parties may separately act as controllers for different purposes.

The Turkish Personal Data Protection Authority published a dedicated Payment and Electronic Money Sector Good Practices Guide in July 2026.

The Guide specifically addresses:

• controller and processor status;
• categories of personal data;
• legal grounds;
• data transfers;
• controller obligations;
• data security.

White-label contracts should therefore avoid assuming that the technology company is automatically a processor in every situation.

The factual purposes and means of processing matter.

30. Marketing Data Requires Separate Attention

A common white-label arrangement involves the regulated institution processing customer data for financial services while the brand owner wants to use the same data for:

• advertising;
• cross-selling;
• profiling;
• loyalty programmes.

Those uses may involve different processing purposes and legal grounds.

The fact that information was collected for KYC or transaction execution does not automatically mean it can be freely repurposed for marketing.

The July 2026 sector guide reinforces the need for payment and e-money companies to map processing purposes, legal grounds, transfers and security measures carefully.

31. International White-Label Providers and Cross-Border Data

Many white-label fintech vendors are global technology companies.

They may operate:

• foreign cloud infrastructure;
• international fraud systems;
• CRM platforms;
• overseas customer support.

This can trigger KVKK international data-transfer analysis.

At the same time, regulated payment and electronic money companies must satisfy sector-specific information-systems requirements.

Therefore:

A cross-border transfer being lawful under KVKK does not automatically mean the financial-sector outsourcing architecture is permissible.

Both regimes must be reviewed.

32. Cloud Infrastructure Is Heavily Regulated for Payment Institutions

The CBRT’s payment-sector cloud rules deserve particular attention for white-label fintech vendors.

The information-systems framework allows payment and electronic money institutions to use domestic cloud services, but processing or storing sensitive customer data, competition-sensitive data and customer-identifiable information is subject to stricter architecture requirements.

The CBRT’s Community Cloud Guide sets out the conditions under which qualifying community-cloud services can be used, including CBRT suitability requirements for providers.

The CBRT reported that as of 2025, six external service providers were authorised to offer qualifying community-cloud services under the relevant framework, and additional institutions had obtained approval to use those environments.

A global SaaS provider should therefore not assume that an ordinary foreign public-cloud deployment can simply be used unchanged by a Turkish licensed payment institution.

33. Cybersecurity Responsibility Cannot Be Contracted Away

A white-label provider may operate the entire customer-facing application.

That makes cybersecurity one of the most important contractual risks.

The regulated institution must ensure that outsourced technology complies with requirements relating to matters such as:

• authentication;
• access control;
• vulnerability management;
• logging;
• penetration testing;
• incident response;
• business continuity.

In the BaaS context, Turkish regulation goes further and expressly creates joint responsibility between the service bank and interface provider regarding specified customer-interface authentication and transaction-security obligations.

Cybersecurity provisions should therefore receive the same contractual attention as pricing and intellectual property.

34. Intellectual Property and Source Code

White-label fintech agreements should clearly allocate intellectual property rights.

The agreement should determine:

• ownership of source code;
• licence scope;
• modifications;
• APIs;
• customer-specific developments;
• branding;
• documentation.

Regulated institutions should also consider operational dependence.

A licence may be legally valid, but if the institution cannot access or migrate critical technology after the vendor becomes insolvent, regulatory continuity can still be threatened.

For mission-critical systems, arrangements may include appropriate:

• source-code escrow;
• transition support;
• data portability;
• exit assistance.

35. Service Levels and Business Continuity

Financial services require greater operational resilience than ordinary SaaS products.

White-label agreements should establish measurable:

• uptime;
• incident response;
• disaster recovery;
• recovery objectives;
• support times.

The contract should also address regulatory emergencies.

For example:

What happens if the CBRT orders the licensed institution to suspend a particular service?

Can the technology provider immediately disable the affected functionality?

Can customer records still be accessed?

Regulatory suspension must be technically enforceable.

36. The Licensed Institution Must Control the Product Scope

A white-label provider may want to release new functionality rapidly.

However, regulated financial institutions cannot always deploy new features like ordinary technology startups.

A feature may change the legal classification of the service.

Examples include adding:

• customer wallets;
• money transfers;
• merchant acquiring;
• Payment Initiation Services;
• Account Information Services.

The CBRT’s current payment institution register shows authorisation service by service rather than through a single unlimited “fintech licence.”

Therefore, product governance should require regulatory approval before major new functionality goes live.

37. Foreign White-Label Fintech Companies

A foreign technology company can potentially supply software into Türkiye without itself obtaining a Turkish payment licence where it genuinely remains a technology provider.

But the situation changes if it directly offers regulated financial services to Turkish customers.

A foreign payment licence does not automatically passport into the Turkish market.

Turkish payment regulation provides specific approved cooperation mechanisms for services involving foreign legal entities. The CBRT currently publishes authorised Article 19 cooperation arrangements involving Turkish payment institutions and foreign providers including Wise Payments, TransferGo, Dlocal and Global Collect.

A foreign fintech should therefore distinguish:

exporting technology to Türkiye

from

providing regulated financial services in Türkiye.

38. White-Label Fintech M&A Due Diligence

White-label models create special risks for investors.

A target may describe itself as:

“a technology company that does not need a licence.”

That statement should not be accepted without analysis.

Due diligence should examine:

Customer Contracts

Who legally provides the service?

Money Flow

Does the target ever receive or control customer funds?

Branding

Does the target appear to customers as the financial institution?

Licence Scope

Does the regulated partner hold the correct permissions?

White-Label Agreement

Are responsibilities clearly allocated?

AML

Can the regulated provider perform required KYC and monitoring?

KVKK

Are controller and processor roles accurate?

Cybersecurity

Can the regulated institution audit the vendor?

Business Continuity

Can the service operate if the vendor relationship ends?

Regulatory Dependency

What happens if the licence holder loses its authorisation?

White-label fintech companies can be commercially valuable but highly dependent upon one or more regulated partners.

39. Licence-Holder Dependency Is a Major Commercial Risk

A white-label fintech business may depend entirely on one:

• payment institution;
• EMI;
• bank;
• crypto service provider.

If that institution loses its licence, the fintech may lose the ability to provide its product immediately.

This is not theoretical.

The CBRT reported that during 2025:

• 14 payment/e-money institution licences were temporarily suspended;
• 7 were cancelled;
• multiple share-transfer and licence-extension decisions were processed.

The CBRT’s current EMI register also contains a substantial list of institutions whose operating permissions have been cancelled.

White-label companies should therefore perform continuous regulatory due diligence on their licensed partners rather than checking licence status only when the agreement is signed.

40. Multi-Provider Architecture Can Reduce Risk

Where commercially feasible, a white-label fintech may consider whether the system can support more than one regulated provider.

This can reduce dependency on one institution.

However, multi-provider architecture creates its own compliance complexity.

The fintech must ensure that customers understand:

• which institution provides which service;
• where funds are held;
• which terms apply;
• which institution handles complaints.

Operational resilience should never create customer confusion.

41. Common White-Label Fintech Compliance Mistakes

Mistake 1: “The Licence Belongs to Our Partner, So We Can Do Anything Under It”

Incorrect.

The partner’s licence does not automatically become the white-label company’s licence.

Mistake 2: “We Are a Technology Company Because Our Contract Says So”

Regulators examine actual functions, contracts, funds and customer relationships.

Mistake 3: “White-Label Open Banking Is Always Unregulated”

Incorrect.

The CBRT distinguishes pure software models from businesses actually providing Payment Initiation or Account Information Services.

Mistake 4: “We Can Hide the Licensed Institution Completely”

This can create significant risk.

Both BaaS and wallet rules contain provisions preventing unlicensed/technical parties from misleading customers about who provides the regulated service.

Mistake 5: “Outsourcing Transfers Regulatory Responsibility”

It does not.

Mistake 6: “Our Foreign Cloud Provider Is GDPR-Compliant, So It Is Automatically Acceptable”

Financial-sector cloud and information-systems requirements must also be satisfied.

Mistake 7: “A Foreign Financial Licence Works in Turkey”

There is no general payment-services passport into Türkiye.

Mistake 8: “White-Label Crypto Software Means We Can Operate an Exchange”

Technology infrastructure does not replace CMB authorisation where the branded company itself performs regulated crypto-asset services.

42. White-Label Fintech Compliance Checklist

Before launching a white-label fintech product in Türkiye, management should answer the following questions.

What Is the Product?

Payment, wallet, open banking, BaaS, lending, crypto or pure software?

Who Is the Regulated Provider?

Identify the legal provider for each financial function.

Who Contracts With the Customer?

The terms should match the regulatory structure.

Who Holds the Funds?

The technology company should not accidentally become the fund holder.

Who Issues Electronic Money?

Only the authorised issuer should assume this role.

Is a Digital Wallet Licence Scope Required?

Analyse Article 4/A functionality.

Does the Platform Initiate Payments?

Article 12(1)(f) may become relevant.

Does It Aggregate Account Information?

Article 12(1)(g) may become relevant.

Is It BaaS?

Determine whether the company qualifies as an interface provider and identify the service bank.

Is the Brand Misleading?

Customer interfaces should not imply that an unlicensed company is a bank, EMI or payment institution.

AML

Can the regulated institution perform full customer due diligence and transaction monitoring?

Data Protection

Who is controller and who is processor?

Cloud

Does the hosting architecture satisfy Turkish financial-sector requirements?

Cybersecurity

Are responsibilities and audit rights documented?

Outsourcing

Can the regulator obtain necessary information and access?

Business Continuity

What happens if the vendor fails?

Licence Dependency

What happens if the financial partner’s licence is suspended?

Foreign Providers

Does cross-border activity require additional Turkish regulatory arrangements?

Frequently Asked Questions About White-Label Fintech in Turkey

Are white-label fintech services legal in Turkey?

Yes. Properly structured white-label fintech services can operate legally. The regulatory outcome depends on which company actually provides the regulated financial service.

Does a white-label software provider need a payment institution licence?

Not necessarily.

The CBRT has expressly examined a white-label software model and concluded that the technology provider did not need Payment Initiation or Account Information Service authorisation where it remained a genuine technical provider and the corporate customer maintained the direct banking relationship.

What is the technical service provider exemption?

Law No. 6493 excludes qualifying technical services supporting payment activity where the provider remains technical and does not become owner of transferred funds. The CBRT relied on this principle in its white-label open banking example.

Can a white-label company offer open banking?

Yes, but regulatory classification depends on the role.

Supplying software may remain technical. Independently providing account information or payment initiation to customers can require Article 12(1)(g) or (f) authorisation.

Can a retailer offer a white-label wallet?

Potentially, through a properly structured relationship with an authorised payment or electronic money institution. The legal issuer and regulated provider must remain correctly identified.

Can the retail company itself issue electronic money using another company’s licence?

No. A commercial partnership does not transfer an EMI licence.

What are the 2026 minimum own-funds requirements?

From 30 June 2026, minimum own funds are TRY 40 million for the general payment institution category and TRY 105 million for electronic money institutions, with separate treatment for specified other categories.

Can a non-bank company provide white-label banking?

Türkiye has a specific Banking as a Service regime.

A Türkiye-resident interface provider can provide customer access to banking services supplied by a service bank under the BDDK framework.

Does the interface provider become the bank?

No.

The service bank remains the banking provider, makes the banking decision and performs the banking service on its own balance sheet.

Can the white-label banking company call itself a bank?

Not without the required legal status. The BaaS Regulation expressly restricts misleading use of banking and payment-service terminology by interface providers.

Who contracts with the customer in BaaS?

A banking-services contractual relationship must exist between the customer and the service bank.

Is the interface provider responsible for cybersecurity?

Yes, in part. The BaaS framework imposes joint responsibility on the interface provider and service bank regarding specified authentication and transaction-security obligations of the interface.

Can white-label fintech providers use cloud infrastructure?

Yes, subject to applicable financial-sector information-systems rules. Payment and e-money institutions face specific requirements for cloud outsourcing and sensitive information.

Does MASAK apply to white-label fintech?

It depends on the role. A pure technology provider is not automatically transformed into a MASAK financial obliged entity. However, electronic money institutions and most payment institutions fall within the formal MASAK compliance-programme framework.

Does KVKK apply?

Yes. White-label structures frequently involve extensive sharing of customer information between the financial institution, brand owner and technology provider. The KVKK Authority’s July 2026 payment/e-money sector guide specifically addresses controller/processor status, processing, transfers and data security.

Can a foreign white-label provider serve Turkey?

A foreign technology vendor may potentially supply software without becoming a Turkish financial institution where it remains genuinely technical. If the foreign company itself provides regulated financial services to Turkish customers, separate Turkish licensing and cross-border regulatory analysis are required.

Can a company operate a white-label crypto exchange?

Merely purchasing exchange software does not provide regulatory authorisation. Türkiye’s crypto-asset service provider framework requires CMB analysis and formal establishment/operating permissions for regulated providers.

Conclusion: How to Structure White-Label Fintech Legally in Turkey

White-label fintech solutions in Turkey offer substantial commercial opportunities.

They allow retailers, marketplaces, software companies, telecommunications businesses and international fintech groups to integrate sophisticated financial functionality without independently developing every financial system from the beginning.

But white-label technology should never be confused with white-label regulation.

The fundamental principle is:

The brand can be white-labelled; the regulatory responsibility cannot.

The CBRT’s own open banking guidance demonstrates this distinction particularly clearly.

In the white-label scenario analysed by the CBRT, a technology company licensed software to a corporate customer that used the software for its own banking relationships.

Because the software company remained a genuine technical provider and did not become the bank’s technical, administrative or legal counterparty for the regulated financial service, the CBRT concluded that the technology provider did not require Payment Initiation or Account Information Service authorisation.

This provides substantial room for Turkish and international fintech software companies.

A technology business can potentially supply:

• APIs;
• dashboards;
• reconciliation;
• payment software;
• banking integrations;
• wallet infrastructure

without itself becoming a financial institution.

However, the opposite scenario is equally important.

The CBRT also identifies situations where a company directly contracts with financial institutions and customers and itself provides account information or payment initiation.

In those circumstances, Article 12(1)(f) and/or Article 12(1)(g) authorisation can be required.

Therefore, the difference between licensed and unlicensed white-label fintech often turns on four issues:

contract → funds → customer relationship → regulatory responsibility.

Digital wallets provide another useful illustration.

A technology provider can potentially store sensitive payment information on behalf of a merchant or payment service provider without becoming the regulated wallet provider, but only where the detailed Article 4/A conditions are satisfied.

The technical provider cannot become owner of payment funds or the sole visible face of the financial service while attempting to rely on the technical-provider treatment.

This directly affects white-label branding.

A fintech company should not build a customer experience that completely hides the licensed financial provider where the legal structure depends on that institution being the regulated service provider.

The same idea is even more explicit in Banking as a Service.

Türkiye’s BDDK regime creates a formal structure in which an interface provider can provide the branded customer-facing experience while a service bank supplies the actual banking services.

But the interface provider does not become the bank.

The service bank determines whether banking services are provided, banking activity occurs on the bank’s balance sheet and a contractual relationship must exist between the customer and service bank.

This makes BaaS one of the clearest legally recognised forms of white-label finance in Türkiye.

However, it also demonstrates the regulatory principle perfectly:

technology and branding can be separated from the licence, but the legal banking provider must remain identifiable.

The same logic applies to electronic money.

A supermarket, telecommunications company or marketplace may brand a wallet or prepaid card.

But if Electronic Money Institution B is the legal issuer, the brand owner cannot independently become the e-money issuer merely through a commercial agreement.

This distinction has enormous financial consequences.

From 30 June 2026, an ordinary payment institution must maintain at least TRY 40 million in own funds, while an electronic money institution must maintain at least TRY 105 million, subject to the wider prudential calculation framework.

Choosing between:

technology provider

and

licensed financial institution

therefore affects the entire economics of the business.

Outsourcing and white-label models also create important operational responsibilities.

A regulated financial institution cannot simply sign an SaaS contract and assume the vendor becomes responsible for compliance.

CBRT regulation places extensive requirements on information systems and outsourcing, while cloud architecture used by payment and electronic money institutions is itself subject to sector-specific rules.

This means financial institutions should negotiate white-label agreements very differently from ordinary software contracts.

The agreement should provide for:

• regulatory audit;
• cybersecurity;
• business continuity;
• data access;
• incident management;
• subcontracting;
• exit migration.

The regulated institution should always retain sufficient control to satisfy its regulator.

AML produces a similar result.

Electronic money institutions and most payment institutions fall within MASAK’s institutional compliance-programme requirements.

They cannot outsource KYC to a white-label brand in a way that prevents them from knowing their own customers.

The technology can facilitate onboarding.

The regulated institution must remain capable of proving that legally required:

• identification;
• sanctions screening;
• transaction monitoring;
• suspicious transaction management

are functioning correctly.

KVKK compliance should be structured in the same way.

The July 2026 Payment and Electronic Money Sector Good Practices Guide demonstrates that controller/processor allocation, processing grounds, data transfers and information security are now important sector-specific compliance issues.

A white-label agreement should therefore map the data flow as carefully as the money flow.

For each customer-data category, the parties should determine:

who collects it → who determines the processing purpose → who can access it → where it is stored → whether it leaves Türkiye → when it is deleted.

White-label crypto models require similarly careful treatment.

The CMB’s post-2024 crypto framework now regulates platforms and custody providers under dedicated Communiqués addressing operating permission, shareholders, governance, information systems, custody and capital adequacy.

Purchasing a trading engine from a licensed technology company does not itself create a crypto licence.

The branded business must separately determine whether it is legally acting as a regulated crypto-asset service provider.

Investors should pay particular attention to all of these distinctions.

A white-label fintech target may appear to be a low-regulation technology company while its actual customer journey looks like a regulated financial institution.

The investor should therefore perform a regulatory perimeter test using the following sequence:

identify customer → identify contract → identify funds → identify financial decision maker → identify licence holder → identify software provider → identify customer-facing brand.

Where those seven elements are inconsistent, regulatory risk usually increases.

Partner risk should also be examined.

The CBRT’s 2025 activity data shows that payment and e-money licensing is actively supervised: operating permissions were suspended or cancelled for multiple institutions during the year.

A white-label fintech company entirely dependent on one regulated institution should therefore prepare a contingency plan.

The business should know what happens if the partner:

• loses its licence;
• is suspended;
• terminates the contract;
• cannot provide technology access;
• becomes subject to regulatory intervention.

Where possible, technical portability should be designed into the platform from the beginning.

For founders and foreign fintech companies, the most reliable legal sequence is therefore:

define the product → map regulated functions → choose licensed provider → determine whether the white-label company is technical provider, interface provider or regulated institution → draft customer-facing disclosures → structure contracts → build MASAK and KVKK allocation → verify cloud/cybersecurity requirements → establish regulatory exit plan → launch only after confirming the licence perimeter.

The central rule is ultimately simple:

A company may use another firm’s technology and another firm’s regulated infrastructure, but it cannot use white-label branding to disguise who is legally providing the financial service.

When that distinction is respected, white-label fintech can be an effective mechanism for launching innovative payment, wallet, open banking and Banking as a Service products in Türkiye.

When it is ignored, the same model can create risks involving:

• unauthorised financial services;
• misleading branding;
• AML failures;
• unlawful data processing;
• outsourcing deficiencies;
• regulatory enforcement.

White-label fintech therefore works best when the legal architecture is designed at the same time as the technical architecture.

Legal Disclaimer: This publication provides general information regarding white-label fintech, payment services, electronic money, digital wallets, open banking, Banking as a Service and related regulatory matters in Türkiye as of July 2026. It does not constitute legal, financial or regulatory advice. Regulatory classification depends on the precise customer contract, funds flow, technology architecture, branding, data processing, functionality and responsibilities of each participant. Every white-label fintech model should therefore be individually reviewed under applicable CBRT, BDDK, CMB, MASAK and KVKK requirements before launch.