Introduction
White-label fintech solutions are becoming increasingly common in Turkey’s digital finance market. A white-label model allows one company to offer a financial technology product under its own brand while the underlying technology, regulated infrastructure, payment rails, wallet system, banking service, card issuing service, crypto infrastructure, compliance tool, or software platform is provided by another company.
This model is commercially attractive. A marketplace can offer a wallet without building its own payment infrastructure. A bank can offer a fintech-style mobile interface through a technology partner. A fintech startup can launch a payment product using a licensed payment institution’s infrastructure. An e-commerce platform can offer installment payments, cards, merchant acquiring, reward wallets, or financial dashboards under its own brand. A crypto platform can use third-party custody or matching technology. A software vendor can provide a ready-made digital financial product to multiple brands.
However, white-label fintech is legally sensitive because branding can hide responsibility. Customers may interact only with the front-end brand, while the regulated service is provided by a licensed bank, payment institution, electronic money institution, crypto asset service provider, or another regulated entity. Regulators, however, do not focus only on branding. They examine who provides the regulated service, who holds customer funds, who processes personal data, who performs KYC, who controls the technology, who communicates with customers, and who bears responsibility when something goes wrong.
In Turkey, white-label fintech solutions may trigger Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions, banking and BaaS rules, Law No. 6698 on the Protection of Personal Data, Law No. 5549 on Prevention of Laundering Proceeds of Crime, consumer protection law, cybersecurity obligations, capital markets rules, and crypto asset service provider regulations depending on the product. Law No. 6493 regulates payment systems, payment services, payment institutions, and electronic money institutions, and its objective is to regulate the procedures and principles for these activities.
This article explains white-label fintech solutions in Turkey, focusing on who is responsible before regulators and customers, how contractual structures should be designed, and which legal risks must be managed before launch.
What Is a White-Label Fintech Solution?
A white-label fintech solution is a financial technology product or infrastructure developed by one provider but offered to end users under another company’s brand. The end user may see the brand of the platform, marketplace, retailer, bank, or digital application, while the technical or regulated service may be operated by a different entity.
White-label fintech solutions may include:
Digital wallet infrastructure
Payment gateway systems
Virtual POS and merchant acquiring tools
Electronic money wallet modules
Prepaid card programs
Banking-as-a-Service interfaces
Open banking dashboards
Digital lending origination tools
Buy Now Pay Later infrastructure
Merchant settlement systems
Reward wallet technology
KYC and onboarding systems
Fraud detection tools
Crypto trading interfaces
Crypto custody solutions
Investment platform interfaces
Insurance technology modules
RegTech and compliance dashboards
The legal risk depends on the product. A white-label invoicing tool may be relatively low risk. A white-label wallet, payment account, card, e-money balance, digital lending product, BaaS interface, or crypto trading platform may be highly regulated.
The central question is not “whose logo appears on the app?” The central question is “who legally provides the financial service?”
Why White-Label Fintech Is Legally Sensitive
White-label fintech is legally sensitive because it can create a gap between customer perception and legal reality. A customer may believe that the visible brand provides the service. The visible brand may believe that the infrastructure provider is responsible. The infrastructure provider may believe that the front-end brand is responsible for customer communication and data collection. Regulators may hold the licensed entity responsible. Courts may examine all parties depending on the facts.
This creates practical risks:
The customer may not know who holds their funds.
The customer may not know who provides the payment service.
The customer may not know which entity processes personal data.
The customer may not know where to complain.
The front-end brand may unknowingly perform regulated activity.
The licensed provider may lose control over the customer journey.
The white-label vendor may process sensitive data without proper legal basis.
The parties may fail to allocate responsibility for fraud, chargebacks, unauthorized transactions, data breaches, or account freezes.
The most dangerous white-label structures are those that treat regulated financial services as ordinary software. In Turkey, payment services, electronic money, banking, crypto asset services, consumer credit, investment services, and insurance intermediation cannot be freely offered simply because they are embedded into a branded app.
Main Legal Framework in Turkey
The legal framework for white-label fintech depends on the service.
For payment and e-money products, the key statute is Law No. 6493. It applies to payment systems, payment services, payment institutions, and electronic money institutions. TÖDEB also explains that payment institutions and electronic money institutions must obtain an operating license from the CBRT and may provide payment services only within the scope of that license.
For banking and BaaS models, the BRSA digital banking and Banking-as-a-Service regulation is critical. The regulation defines an interface provider as a capital company that enables customers to access banking services offered by a service bank through the bank’s open banking services via the provider’s mobile application or browser-based interface.
For personal data, KVKK applies. Law No. 6698 aims to protect fundamental rights and freedoms, particularly privacy, in relation to personal data processing, and sets obligations for natural and legal persons processing personal data.
For AML/CFT, Law No. 5549 applies. Its objective is to determine the principles and procedures for preventing laundering proceeds of crime.
For consumers, Law No. 6502 on Consumer Protection is relevant. Its purpose includes protecting consumers’ health, safety, and economic interests and compensating consumer losses.
For crypto asset services, the CMB’s 2025 communiqués regulate crypto asset service providers, including establishment, operation, activities, and capital adequacy.
White-Label Payment Services
White-label payment services are common in Turkey. A marketplace, SaaS company, retailer, mobile app, or digital platform may want to offer payment collection, virtual POS, payment links, QR payments, merchant acquiring, subscription billing, or wallet payments under its own brand.
However, payment services are regulated. If the visible brand contracts with merchants, accepts payment instruments, transfers funds, operates payment accounts, initiates payments, or manages merchant settlement, it may be performing payment services. Unless it is licensed, it must structure the model through an authorized payment service provider.
A lawful white-label payment model should clarify:
Who is the licensed payment service provider?
Who contracts with the merchant?
Who contracts with the end user?
Who receives funds?
Who safeguards funds?
Who processes refunds?
Who handles chargebacks?
Who performs merchant onboarding?
Who handles consumer complaints?
Who reports to the CBRT or other authorities?
The front-end brand may provide customer interface and marketing, but it should not perform regulated payment services unless licensed. The licensed provider must maintain real control over regulated activities and should not allow the white-label partner to operate as an unlicensed payment institution.
White-Label E-Money and Wallet Solutions
White-label e-money and wallet products create even higher legal risk. A brand may want to offer users a wallet balance, store credits, prepaid value, reward balance, gift balance, card-linked wallet, merchant wallet, or in-app spending balance.
If the wallet stores monetary value and allows users to make payments, electronic money rules may apply. A front-end brand cannot avoid e-money regulation by calling the balance “credits,” “points,” “tokens,” “cashback,” or “wallet rewards” if the balance functions like monetary value accepted for payment.
Important questions include:
Can users load funds?
Can users store balances?
Can users spend balances with third-party merchants?
Can users transfer balances?
Can users withdraw balances?
Who issues the value?
Who safeguards customer funds?
Is the value electronic money?
Which licensed institution provides the wallet?
If a licensed e-money institution provides the regulated wallet infrastructure, the white-label contract must ensure that the front-end brand does not mislead users about who issues the electronic money and who is responsible for fund protection.
White-Label Banking and BaaS
Banking-as-a-Service is one of the most legally sensitive white-label fintech models. In a BaaS model, a bank provides regulated banking services, while the customer accesses those services through an interface provider’s digital channel.
The BRSA regulation defines the service bank and interface provider roles in the BaaS structure. The interface provider enables customers to access banking services through its mobile application or browser-based interface, while the service bank provides the underlying banking services.
This structure creates several responsibility questions:
Does the customer know which bank provides the banking service?
Does the interface provider present itself as a bank?
Who obtains customer consent?
Who stores customer data?
Who performs customer support?
Who receives complaints?
Who is responsible for system outages?
Who handles unauthorized transactions?
Who bears liability for misleading interface design?
The bank cannot treat the fintech interface as a simple reseller. The bank must retain control over the regulated banking service, customer relationship, risk management, and compliance. The interface provider must avoid acting outside its role or implying that it is itself a licensed bank.
White-Label Crypto Platforms
White-label crypto infrastructure may include trading interfaces, order matching engines, custody modules, wallet systems, token listing tools, blockchain analytics, staking dashboards, or customer onboarding systems. This area is highly sensitive because crypto asset service providers in Turkey are now subject to the CMB framework.
The CMB’s Communiqué III-35/B.1 regulates principles on establishment and operation of crypto asset service providers, while Communiqué III-35/B.2 regulates operating procedures, activities, and capital adequacy.
A company should obtain legal review if a white-label crypto model involves:
Crypto trading under another brand.
Crypto custody or private key management.
Customer crypto wallets.
Token listing or delisting.
Staking services.
Transfer orders.
Exchange of crypto assets.
Marketing crypto services to Turkish users.
A white-label crypto front-end cannot assume that the technology provider’s infrastructure eliminates regulatory responsibility. If the visible platform markets crypto services, handles users, controls wallets, or performs crypto asset service provider functions, CMB rules may become relevant.
Technology Provider vs. Regulated Service Provider
One of the most important legal distinctions is the difference between a technology provider and a regulated service provider.
A technology provider may provide software, APIs, dashboards, cloud infrastructure, risk engines, KYC tools, UX design, or back-office systems. A regulated service provider performs legally regulated financial services such as payment services, e-money issuance, banking, credit, investment services, crypto asset services, or insurance intermediation.
The problem arises when a technology provider starts doing more than technology. Warning signs include:
Contracting directly with customers for the financial service.
Deciding whether customers can access the service.
Holding or controlling customer funds.
Approving or rejecting payment transactions.
Handling customer balances.
Setting fees for regulated services.
Performing KYC as if it were the obliged party.
Managing complaints without licensed entity oversight.
Advertising the product as its own financial service.
Making decisions on account freezes or suspicious activity.
If the technology provider performs regulated functions, it may need authorization. If it does not have authorization, the structure may create regulatory liability for both the technology provider and the licensed institution.
Customer Disclosure: Who Must Be Visible?
In white-label fintech, customer disclosure is essential. Customers should not be misled about who provides the regulated service.
A customer-facing interface should clearly disclose:
The front-end brand.
The licensed provider.
The type of service provided.
Whether the visible brand is licensed.
Whether customer funds are held by a licensed institution.
Which terms apply.
Which privacy notice applies.
Who handles complaints.
Who is responsible for unauthorized transactions.
Whether deposit insurance or fund protection applies, if relevant.
Misleading customer disclosure can create consumer protection, regulatory, and contractual risk. A beautiful white-label interface is not legally safe if it hides the regulated provider or confuses the customer about responsibility.
Regulatory Responsibility Before Authorities
Regulators usually look at the licensed entity first. If a bank provides the banking service, the BRSA may hold the bank responsible for compliance. If a payment institution provides the payment service, the CBRT may hold the payment institution responsible. If a crypto asset service provider provides the crypto service, the CMB may hold that provider responsible.
However, the front-end brand and technology provider may also face liability where they:
Act without required authorization.
Mislead customers.
Process personal data unlawfully.
Fail to implement required security.
Perform outsourced functions improperly.
Ignore AML or fraud risks.
Breach consumer protection rules.
Cause operational failures.
Use the licensed provider’s infrastructure beyond the agreed scope.
The contract may allocate indemnity between the parties, but it cannot eliminate regulator-facing responsibility. A licensed institution cannot fully outsource its legal obligations.
Responsibility Before Customers
Customer responsibility is more complicated because customers may sue or complain against the visible brand, the licensed provider, or both. The customer will often not understand the internal contractual allocation.
For example:
If a wallet balance disappears, the customer may complain to the visible app.
If a payment fails, the customer may complain to the merchant-facing platform.
If an account is frozen, the customer may demand explanation from the brand they know.
If personal data is breached, the customer may complain against both the controller and processor depending on the data flow.
If a crypto withdrawal is delayed, the customer may target the platform interface.
A strong white-label model should avoid forcing customers to guess who is responsible. Complaint routing should be clear and fast. Internal contracts should require cooperation between all parties in handling customer claims.
KVKK Responsibility in White-Label Fintech
White-label fintech almost always involves personal data. The parties must determine whether they are data controllers, joint controllers, independent controllers, or processors.
Typical data includes:
Identity data.
Contact data.
Transaction records.
Payment account data.
Wallet balances.
Device data.
IP addresses.
KYC documents.
Risk scores.
Fraud alerts.
Complaint records.
Customer support conversations.
Crypto wallet addresses.
Banking data.
KVKK requires lawful, fair, purpose-specific, proportionate, and secure processing of personal data. It also imposes obligations on persons processing personal data.
A white-label data structure should answer:
Who determines the purpose of processing?
Who determines the means of processing?
Which party gives the privacy notice?
Which party responds to data subject requests?
Can the white-label brand use data for marketing?
Can the technology provider reuse data for analytics?
Is data transferred abroad?
Are vendors and subprocessors involved?
What happens to data after termination?
The parties should not assume that the licensed provider automatically controls all data. In many white-label models, the visible brand also determines marketing, customer journey, analytics, and campaign purposes. This may make it a separate data controller for certain processing activities.
MASAK and AML/KYC Responsibility
AML and KYC allocation is critical. Law No. 5549 sets the legal framework for prevention of laundering proceeds of crime. In white-label fintech, the licensed financial institution may be the obliged party, but the white-label partner may collect documents, operate the interface, interact with the customer, or detect suspicious behavior.
The agreement should specify:
Who identifies the customer?
Who verifies identity documents?
Who identifies beneficial owners?
Who screens sanctions and PEP lists?
Who monitors transactions?
Who flags suspicious activity?
Who decides whether to file a suspicious transaction report?
Who retains AML records?
Who handles MASAK or law enforcement requests?
Who trains customer support staff?
Who bears liability if onboarding fails?
A white-label partner should not make final AML reporting decisions unless it is legally authorized and responsible. However, it must cooperate with the licensed entity and must not hide suspicious activity.
Cybersecurity and Information Systems
White-label fintech depends on APIs, mobile apps, cloud systems, dashboards, identity tools, payment engines, wallet ledgers, custody systems, and data integrations. Cybersecurity failures can create major liability.
For banks, the BRSA information systems regulation sets minimum procedures and principles for management of bank information systems, electronic banking services, related risks, and information systems controls. For payment and e-money institutions, CBRT information systems and audit expectations are also relevant through the payment services framework.
White-label contracts should include:
Security standards.
Encryption.
Authentication.
Access control.
API security.
Penetration testing.
Vulnerability management.
Incident response.
Business continuity.
Disaster recovery.
Audit logging.
Data breach notification.
Subcontractor security.
Regulatory access.
A generic clause saying “the vendor will use reasonable security measures” is not enough for financial technology. Security obligations should be operational, measurable, and auditable.
Outsourcing and Vendor Risk
White-label arrangements often qualify as outsourcing or support service relationships. The regulated entity may rely on a vendor for interface, software, customer onboarding, transaction monitoring, KYC technology, cloud hosting, call center support, or fraud detection.
The regulated entity should conduct due diligence before launch. This should include:
Corporate review.
Technical capability review.
Information security review.
Financial stability review.
Regulatory history review.
Data protection review.
Business continuity review.
Subcontractor review.
Incident history review.
Insurance coverage review.
The contract should allow audit, regulator access, service monitoring, corrective action, and termination if the vendor creates legal or operational risk.
Consumer Protection and Unfair Terms
Where the end users are consumers, Law No. 6502 becomes important. The law aims to protect consumers’ economic interests and compensate consumer losses.
Consumer-facing white-label fintech products should avoid:
Hidden fees.
Unclear service provider identity.
Broad liability exclusions.
Unfair account closure rights.
Unclear refund procedures.
Misleading license statements.
Misleading fund protection claims.
Unclear withdrawal or cancellation rights.
Overly broad data consent language.
Inaccessible complaint channels.
A standard user agreement should not shift all risk to the consumer, especially where the provider controls the technology, fund flow, or account access.
Contractual Structure of White-Label Fintech
A white-label fintech project should not rely on a simple software license agreement. It usually needs a more detailed legal package.
Key documents may include:
Master white-label agreement.
Service level agreement.
API agreement.
Data processing agreement.
Confidentiality agreement.
Regulatory compliance schedule.
AML/KYC responsibility matrix.
Customer support protocol.
Cybersecurity addendum.
Incident response plan.
Business continuity plan.
Branding and marketing guidelines.
Fund flow schedule.
Customer terms.
Privacy notices.
Termination and migration plan.
The contract must reflect operational reality. If the white-label brand handles first-line customer support, the agreement must regulate escalation. If the licensed provider holds funds, the fund flow schedule must show how funds move. If customer data is shared, the data schedule must specify roles and purposes.
Key Clauses in a White-Label Fintech Agreement
A strong agreement should include:
Regulatory status clause: Each party must state its licenses and permitted activities.
Scope clause: The services must be defined precisely.
No unauthorized activity clause: The white-label partner must not perform regulated activity outside its role.
Customer disclosure clause: The licensed provider and brand role must be visible to customers.
Fund flow clause: The contract must explain who receives, holds, safeguards, and transfers funds.
AML/KYC clause: Responsibilities for onboarding, screening, monitoring, and reporting must be allocated.
KVKK clause: Data controller and processor roles must be mapped.
Confidentiality clause: Customer, bank, payment, and business data must be protected.
Cybersecurity clause: Security obligations must be measurable.
Audit rights clause: The licensed provider and regulators must access relevant records.
Service level clause: Uptime, incident response, and support obligations must be defined.
Liability clause: Loss allocation for fraud, data breach, outages, regulatory sanctions, and customer claims must be clear.
Termination clause: Customer migration, data return, fund handling, and continuity must be planned.
Liability for Unauthorized Transactions
Unauthorized transactions are common fintech disputes. In a white-label model, a customer may not know whether to complain to the brand, licensed provider, bank, wallet provider, or technology vendor.
The contract should define:
Who receives the complaint?
Who freezes the account?
Who investigates authentication logs?
Who communicates with the customer?
Who bears loss if the app was compromised?
Who bears loss if the licensed payment engine failed?
Who bears loss if customer support delayed escalation?
Who preserves evidence?
The customer-facing process must be simple. The internal allocation can be complex, but the customer should not be pushed between parties.
Liability for Account Freezes
Account freezes may arise from AML review, fraud, suspicious activity, chargebacks, sanctions, KYC deficiencies, court orders, or security incidents. White-label structures often create confusion because the front-end brand receives customer complaints, while the licensed entity makes compliance decisions.
The agreement should specify:
Who can freeze accounts?
Who can request additional documents?
Who decides whether to release funds?
What information may be disclosed to the customer?
How AML confidentiality is protected?
Who handles regulator requests?
Who records the decision?
Account freeze powers should not be arbitrary. They should be based on legal, regulatory, fraud, AML, security, or contractual grounds.
Liability for Data Breaches
Data breaches in white-label fintech can affect multiple parties. The breach may occur in the white-label app, licensed provider system, cloud provider, API integration, KYC vendor, customer support system, or analytics tool.
The contract should regulate:
Incident detection.
Notification deadlines.
Forensic investigation.
Customer communication.
KVKK notification analysis.
Regulator communication.
Remediation.
Cost allocation.
Public statements.
Evidence preservation.
A data breach response plan should be prepared before launch. Waiting until after a breach occurs usually leads to confusion and delay.
Termination and Exit Planning
Exit planning is essential. A white-label fintech partnership may end, but customers may still have funds, accounts, transaction histories, complaints, disputes, personal data, cards, wallet balances, or crypto assets.
The termination plan should address:
Customer notification.
Continuation of critical services.
Return or transfer of funds.
Migration of customer accounts.
Data return and deletion.
Regulatory notification.
Complaint handling after termination.
Access to historical logs.
Final settlement.
Transition support.
Brand removal.
Subcontractor termination.
A poor exit can harm customers and expose both parties to regulatory scrutiny.
Practical Compliance Checklist
A white-label fintech project in Turkey should consider:
Classify the product before launch.
Identify whether payment, e-money, banking, lending, crypto, investment, or insurance rules apply.
Determine which party is licensed.
Define the white-label partner’s permitted role.
Make customer disclosure clear.
Map fund flows.
Map data flows.
Prepare KVKK documentation.
Allocate AML/KYC responsibilities.
Prepare cybersecurity requirements.
Include audit and regulator access rights.
Draft customer complaint procedures.
Prepare unauthorized transaction workflows.
Prepare account freeze procedures.
Review consumer protection risks.
Review marketing and branding.
Prepare service level obligations.
Plan termination and migration.
Train customer support teams.
Maintain audit-ready records.
Review regulatory changes continuously.
This checklist must be adapted to the business model. A white-label payment gateway, e-money wallet, BaaS app, crypto platform, lending interface, or insurance technology solution will not have identical obligations.
Why Legal Support Is Important
White-label fintech requires legal support because responsibility is divided across visible brands, licensed providers, technology vendors, banks, payment institutions, e-money institutions, crypto providers, and outsourced service providers. Without careful structuring, a company may unintentionally perform regulated activity or mislead customers.
A fintech lawyer can assist with:
Regulatory classification.
Payment and e-money licensing review.
BaaS structuring.
White-label agreement drafting.
Fund flow analysis.
Customer disclosure drafting.
KVKK compliance.
AML/KYC responsibility matrix.
Cybersecurity clauses.
Consumer protection review.
Crypto platform compliance.
Outsourcing risk analysis.
Termination planning.
Regulatory correspondence.
Dispute resolution strategy.
Legal review should begin before technical integration. Once customers are onboarded, funds are processed, and data flows begin, restructuring the model becomes more difficult.
Conclusion
White-label fintech solutions in Turkey offer major commercial advantages. They allow brands to launch financial products quickly, help licensed institutions expand distribution, and enable technology providers to scale infrastructure. However, white-label fintech also creates serious legal risk because branding can obscure responsibility.
The decisive legal question is not whose logo appears on the app. The decisive question is who provides the regulated service, who holds funds, who processes personal data, who performs KYC, who controls transactions, and who answers to customers and regulators.
Turkey’s regulatory framework is clear in one respect: regulated financial services require proper authorization and compliance. Law No. 6493 governs payment services and e-money. The BRSA framework governs digital banking and BaaS. KVKK governs personal data. MASAK rules govern AML/CFT. Consumer protection rules govern customer-facing fairness and transparency. Crypto asset services are subject to the CMB framework.
A legally sound white-label model should be transparent, documented, auditable, secure, and customer-friendly. The licensed entity must retain control over regulated activities. The white-label brand must stay within its permitted role. The technology provider must meet security and continuity standards. Customers must know who provides the service and where to complain.
Yanıt yok