Introduction
Banking-as-a-Service, commonly known as BaaS, is one of the most important legal and commercial developments in Turkey’s financial technology sector. In a BaaS model, a licensed bank provides banking services through the digital interface of another business, usually a fintech platform, marketplace, e-commerce company, mobility application, telecom operator or digital ecosystem provider. The customer may experience the service through the fintech platform’s mobile application or website, while the underlying banking service is legally provided by the licensed bank.
In Turkey, the official regulatory concept is generally referred to as service model banking. The Regulation on the Operating Principles of Digital Banks and Banking as a Service Model, published in the Official Gazette on 29 December 2021, states that its purpose is to determine the principles for branchless digital banks and for the provision of banking services through a service model to financial technology companies and other businesses. The regulation defines an interface provider as a capital company that enables its customers to perform banking transactions by accessing banking services offered by a service bank through the bank’s open banking services via the interface provider’s mobile application or internet browser-based interface.
This framework creates significant opportunities. Banks can reach new customer segments. Fintech platforms can offer financial products without becoming full banks. E-commerce platforms can embed accounts, cards, loans, payments and financial management tools into their customer journeys. Consumers and SMEs can access banking services more easily.
However, BaaS is legally sensitive. It combines banking law, payment services law, outsourcing, open banking, customer data, banking secrecy, personal data protection, cybersecurity, consumer protection, anti-money laundering, marketing rules and contractual liability. A poorly structured BaaS agreement may create licensing violations, unauthorized banking activity, customer data breaches, unclear liability for fraud, unfair customer terms, regulatory sanctions and serious reputational damage.
This article explains Banking-as-a-Service agreements in Turkey, focusing on legal risks for banks and fintech platforms.
1. What Is Banking-as-a-Service?
Banking-as-a-Service is a business model where a licensed bank provides banking products or infrastructure through the interface of a third-party platform. The platform may design the customer experience, user interface, onboarding flow, branding, marketing journey and customer communication, while the regulated banking activity remains with the bank.
A typical BaaS model may include:
Digital account opening, debit cards, credit cards, payment transfers, money transfers, deposits, consumer loans, SME loans, investment access, wallet-like user interfaces, payment initiation, financial dashboards, embedded credit, embedded insurance, loyalty-based finance and merchant finance.
In a legally compliant BaaS structure, the fintech platform should not pretend to be a bank if it does not hold a banking license. The bank must remain responsible for the banking service it is legally authorized to provide. The fintech platform acts as an interface provider, technology partner, distribution channel or customer-facing digital layer, depending on the contractual and regulatory structure.
The legal risk begins when the platform crosses the line from being an interface provider into performing regulated banking activities without authorization.
2. BaaS and Service Model Banking Under Turkish Law
Turkey has a specific regulatory framework for service model banking. The Regulation on the Operating Principles of Digital Banks and Banking as a Service Model entered into force on 1 January 2022. It was prepared based on several provisions of Banking Law No. 5411 and directly regulates how banking services may be provided through digital and service model channels.
The regulation is important because it does not treat BaaS as an unregulated commercial partnership. It creates a defined structure involving:
A service bank, meaning the licensed bank providing banking services;
An interface provider, meaning the capital company offering the customer-facing digital interface;
Open banking services, APIs and electronic banking infrastructure;
Contractual obligations between the bank and interface provider;
BRSA notification and oversight;
Technical criteria and compliance controls.
The regulation makes clear that BaaS in Turkey is not merely a branding arrangement. It is a regulated banking service delivery model.
3. Difference Between BaaS, Open Banking and Embedded Finance
BaaS, open banking and embedded finance are connected but not identical.
Open banking generally refers to regulated data sharing or transaction initiation through secure interfaces such as APIs. Under the BRSA electronic banking regulation, open banking services are an electronic distribution channel through which customers or parties acting on behalf of customers may execute or instruct banking transactions through remote access to financial services offered by a bank.
Banking-as-a-Service is broader in commercial effect. It allows a platform to offer access to banking services through its own interface by relying on a licensed bank. It may use open banking infrastructure, but its commercial purpose is often embedded banking distribution.
Embedded finance is the broadest business concept. It refers to placing financial products inside non-financial customer journeys. A marketplace may offer seller loans. A mobility app may offer payment accounts. A retail platform may offer cards or installment financing. Embedded finance may be built through BaaS, payment institution licensing, e-money licensing, agency structures or direct bank partnerships.
The legal classification depends on the actual service. A product called “embedded finance” may be a payment service, banking service, credit product, insurance distribution model or investment service. Labels do not determine regulatory status.
4. Parties to a BaaS Agreement
A BaaS agreement usually involves two principal parties.
The first is the service bank. This is the licensed bank that provides the regulated banking service. It may be a deposit bank, participation bank or another type of bank depending on its license and authorized activities.
The second is the interface provider. Under the Turkish regulation, the interface provider must be a capital company that enables customers to access the bank’s services through its own digital interface. The interface provider is not the bank. Its legal role must be carefully limited and described in the BaaS agreement.
Other parties may also be involved: technology vendors, cloud providers, payment institutions, electronic money institutions, card processors, call centers, AML vendors, identity verification providers, data analytics providers, customer support providers and marketing partners.
The more parties involved, the more important it becomes to allocate responsibility clearly.
5. Licensing Risk for Fintech Platforms
The most important legal risk for fintech platforms is unauthorized regulated activity. A platform may want to offer “banking products” inside its application, but if it does not hold a banking license, it must avoid acting as the actual provider of banking services.
A fintech platform should not independently accept deposits, hold itself out as a bank, make credit decisions reserved for the bank, mislead customers about the licensed provider, or control customer funds outside the permitted structure.
In Turkey, payment services and electronic money activities are separately regulated under Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions. The law’s stated objective is to regulate payment systems, payment services, payment institutions and electronic money institutions.
Therefore, a fintech platform may need to analyze two separate licensing questions:
Does the business model require a banking license?
Does the business model require a payment institution or electronic money license?
A BaaS partnership with a bank does not automatically authorize every payment or e-money activity by the fintech platform. The platform’s own role must be reviewed independently.
6. Licensing and Responsibility of the Service Bank
A service bank may provide BaaS only within the scope of its own authorized banking activities. A bank cannot provide through an interface provider what it is not legally allowed to provide directly.
This is critical for credit products, deposit products, participation banking products, investment-related services and payment services. If the service involves lending, the bank must remain responsible for credit assessment, loan approval, loan documentation, risk classification and regulatory reporting. If the service involves deposit or participation funds, the bank must remain the regulated institution holding the account relationship.
Recent Turkish fintech commentary confirms that the procedures and principles governing BaaS are set out under the Digital and Service Banking Regulation, and that for a service to qualify as BaaS, customers must access banking services offered by the bank through the interface provided by an interface provider via open banking services. It also notes that the service bank must make decisions relating to banking services, such as credit allocation, and record relevant transactions on its own balance sheet.
This means that the fintech platform may support distribution and customer experience, but the bank cannot outsource its core regulatory judgment entirely.
7. Key Clauses in a BaaS Agreement
A Turkish BaaS agreement should be detailed and regulatory-compliant. It should not be a generic technology service agreement.
Key clauses should include:
Scope of banking services;
Role of the service bank;
Role of the interface provider;
Customer ownership and communication;
Licensing responsibilities;
Regulatory compliance obligations;
Open banking/API access;
Information security standards;
Data sharing and confidentiality;
Banking secrecy compliance;
KVKK compliance;
KYC and AML responsibilities;
Customer onboarding process;
Credit decision process;
Marketing approvals;
Customer complaint handling;
Incident response;
Audit rights;
Service levels;
Operational continuity;
Fees and revenue sharing;
Liability allocation;
Termination rights;
Transition and customer migration;
Regulatory notification duties.
A weak BaaS agreement may leave both parties exposed. If a fraud incident occurs, if customer data is leaked, or if the regulator questions the model, the parties must be able to show who was responsible for each function.
8. Banking Secrecy and Customer Data
Banking secrecy is one of the most important legal issues in BaaS agreements. Banks process customer secrets, and such information cannot be shared freely with fintech platforms.
The BRSA Regulation on the Disclosure of Confidential Information states that its purpose is to determine the scope, form, procedures and principles regarding the sharing and transfer of bank secrets and client secrets. It also requires proportionality: confidential information may be shared only for specified purposes and only to the extent required for those purposes.
This is crucial in BaaS. The interface provider may need access to customer data to display account balances, transaction details, loan status, card limits or payment history. But the bank must ensure that data sharing is legally permitted, proportionate, secure and purpose-limited.
A BaaS agreement should define:
Which customer data is shared;
Why it is shared;
Whether customer request or instruction is required;
How consent and instructions are recorded;
Who can access the data;
Whether data may be used for marketing;
Whether data may be transferred abroad;
How long data is retained;
How data is deleted after termination.
Customer data cannot become a commercial asset freely exploited by the interface provider.
9. KVKK and Personal Data Protection
BaaS models almost always involve personal data. Names, identity numbers, phone numbers, IBANs, transaction history, device data, IP addresses, loan applications, income data and card transactions may all qualify as personal data when relating to natural persons.
The parties must determine their roles under Turkish data protection law. In some cases, the bank may be the data controller. In other cases, the interface provider may be an independent data controller for its own platform services. In certain technical processing functions, the platform or vendors may act as processors. The roles should not be assumed; they should be legally analyzed.
A BaaS agreement should include privacy obligations, data processing rules, security measures, data subject request handling, cross-border transfer rules, breach notification duties and audit rights.
The privacy notice shown to customers must be clear. The customer should understand that the banking service is provided by a licensed bank, the interface is provided by another company, and data may be processed by both parties for defined purposes.
10. Cross-Border Data Transfer Risk
Many fintech platforms use cloud infrastructure, analytics tools, fraud monitoring systems, CRM tools, overseas development teams or global group companies. This may create cross-border data transfer risks.
For BaaS, cross-border transfer analysis is more complex than ordinary KVKK review because banking secrecy rules may also apply. Banking Law and BRSA rules may restrict transfer of customer secrets abroad, and the BRSA has authority in relation to sharing and transfer of bank and customer secrets.
A platform using foreign technology providers must therefore ask:
Is bank customer secret data being transferred abroad?
Is personal data being transferred abroad?
Is the transfer necessary for the service?
Has the required legal basis been established?
Are contractual safeguards in place?
Has the bank approved the vendor?
Can the bank audit the vendor?
Can the data be localized or minimized?
These issues should be resolved before launch, not after regulatory review.
11. Outsourcing and Support Service Risks
BaaS agreements often include outsourced technology, operational support, customer service or API management. Turkish banking regulation treats outsourcing seriously.
The BRSA Regulation on Procurement of Support Services by Banks regulates the purchase of support services by banks. In addition, the BRSA electronic banking regulation addresses information systems, security governance, outsourcing and electronic banking risk management. It requires banks to adopt policies and controls to manage information systems risks and protect information assets.
A bank cannot avoid responsibility by saying that the interface provider or technology vendor caused the failure. If the outsourced function affects banking services, the bank must manage vendor risk.
A BaaS agreement should include:
Audit rights;
Access to records;
Regulatory access rights;
Information security obligations;
Subcontracting restrictions;
Incident reporting;
Business continuity;
Exit and transition plans;
Data return and deletion;
Service level commitments.
12. KYC and Customer Onboarding
Customer onboarding is a major risk area. The interface provider may design the customer journey, but the bank must ensure that customer identification complies with banking, AML and remote onboarding rules.
If customer identification is weak, fraud, mule accounts, account takeover, illegal betting proceeds, money laundering and sanctions exposure may arise.
The agreement should clarify:
Who collects identity information?
Who verifies identity?
Which remote identification method is used?
Who screens customers against sanctions and watchlists?
Who approves or rejects onboarding?
Who stores KYC records?
Who responds to regulator requests?
Who bears liability for onboarding defects?
The customer interface may be controlled by the fintech platform, but regulatory accountability cannot be contractually hidden.
13. AML and Suspicious Transaction Reporting
BaaS models can increase AML risk because non-bank platforms may attract customer segments that banks do not traditionally serve directly. Marketplaces, gig platforms, gaming platforms, delivery platforms and retail ecosystems may generate high-volume, low-value, fast-moving transactions.
The service bank remains subject to anti-money laundering obligations. The platform may assist with customer data, transaction context and behavioral signals, but the bank must ensure legally compliant monitoring and reporting.
A BaaS agreement should define transaction monitoring responsibilities, suspicious activity escalation, data sharing for AML review, freezing or blocking procedures, response to law enforcement, and customer communication restrictions.
The interface provider must also be trained not to “tip off” customers where suspicious transaction reporting is involved.
14. Cybersecurity and API Risk
BaaS depends on APIs, open banking connections, mobile applications and secure data exchange. Cybersecurity is therefore central.
Risks include:
API abuse;
Unauthorized access;
Token theft;
Credential stuffing;
Man-in-the-middle attacks;
Fraudulent payment initiation;
Account takeover;
Data leakage;
DDoS attacks;
Mobile application vulnerabilities;
Insider access;
Misconfigured cloud storage.
The BRSA electronic banking regulation requires banks to manage information systems and electronic banking risks and maintain controls for integrity, reliability, confidentiality and continuity.
A BaaS agreement should require penetration testing, vulnerability management, encryption, secure authentication, logging, incident response, access management, regular audits and security reporting.
15. Liability for Unauthorized Transactions
Unauthorized transactions are one of the most likely litigation risks in BaaS models.
A customer may claim that money was transferred without authorization through the fintech interface. The bank may argue that the transaction came through a valid API instruction. The platform may argue that it only transmitted the customer’s instruction. The customer may argue that the interface was insecure or misleading.
The BaaS agreement should answer:
Who verifies customer authentication?
Who preserves transaction logs?
Who investigates fraud complaints?
Who refunds the customer if the transaction was unauthorized?
Who communicates with the customer?
Who bears losses caused by API failure?
Who bears losses caused by platform security breach?
Who bears losses caused by bank system failure?
Without clear liability rules, the customer may sue both parties, and the dispute may become technically complex.
16. Customer Communication and Branding Risk
BaaS depends heavily on customer trust. But branding must not mislead customers.
If the interface provider’s brand dominates the customer journey, the customer may believe that the fintech platform is the bank. This may create regulatory and consumer protection risk. The platform must clearly disclose the identity of the licensed bank providing the banking service.
Marketing materials should be reviewed by the bank before publication. The platform should not promise guaranteed loans, guaranteed returns, deposit protection beyond applicable legal limits, risk-free investment products or banking services that the bank has not approved.
The customer should understand:
Who provides the bank account;
Who issues the card;
Who grants the loan;
Who holds the funds;
Who handles complaints;
Which entity is licensed;
Which terms apply.
Transparency reduces litigation risk.
17. Consumer Protection Issues
If the BaaS product is offered to consumers, Turkish consumer protection rules may apply. This is especially important for consumer loans, credit cards, account fees, installment products, insurance-linked products and digital onboarding.
Consumer terms should be clear and fair. Fees, commissions, interest, repayment obligations, default consequences, complaint routes and cancellation rights should be disclosed transparently.
The interface provider’s user experience should not hide key loan or fee information behind confusing screens. Digital consent should be recorded. Pre-contractual information should be presented properly. If the customer later challenges the product, the bank and platform must prove that disclosure was adequate.
18. Credit Products in BaaS Models
Credit products are high-risk in BaaS. A platform may want to offer instant consumer loans, SME loans, seller financing or buy-now-pay-later style financing.
However, credit allocation is a regulated banking function. The bank must make the lending decision, assess credit risk, record the loan on its balance sheet where required, comply with loan classification rules, and maintain credit documentation.
The platform may provide data, customer interface or scoring support, but it should not independently approve bank loans unless legally authorized. If the platform’s algorithm influences credit decisions, the bank must understand, validate and control the model.
The agreement should address:
Credit policy;
Data used for scoring;
Algorithm governance;
Manual review;
Rejection reasons;
Consumer notices;
Discrimination risk;
Default management;
Collection communication;
Loan restructuring.
19. Deposits and Customer Funds
Deposit-taking is a core banking activity. An interface provider cannot collect deposits as if it were a bank. If customer funds are held in bank accounts, the legal relationship must show that the licensed bank is the account provider.
The platform should not commingle customer funds, represent itself as holding deposits, or use customer balances outside the authorized structure.
Customer terms should explain where the funds are held, who the account provider is, what protections apply, and what happens if the BaaS agreement terminates.
20. Payment Services and E-Money Overlap
Many fintech platforms already operate under payment institution or e-money licenses. A BaaS model may be combined with payment accounts, wallets, cards, QR payments, merchant acquiring or money transfers.
This creates overlap between banking regulation and payment services regulation. Law No. 6493 regulates payment and e-money institutions and payment services, while Banking Law No. 5411 governs banking activities.
A platform must determine whether a service is:
A bank account service;
A payment account service;
An e-money service;
A payment initiation service;
An account information service;
A card issuing service;
A credit product;
A banking service through BaaS.
Each classification has different licensing and compliance consequences.
21. Revenue Sharing and Fee Structures
BaaS agreements often include revenue sharing. The bank may charge the interface provider. The interface provider may charge customers or earn commissions. The parties may share interchange, loan commissions, subscription fees or service fees.
Fee structures must comply with banking, consumer, payment services and tax rules. A fee cannot be used to disguise unauthorized banking activity or mislead customers.
The agreement should specify:
Which party charges which fee;
Whether customer consent is required;
Who invoices whom;
Whether fees are disclosed to customers;
How refunds are handled;
How tax is allocated;
How chargebacks or reversals affect revenue.
22. Audit and Regulatory Access
Regulators may request documents, records, logs, contracts, customer complaints, security reports and data-sharing evidence.
The bank must be able to audit the interface provider. The regulator may also expect access to relevant outsourced or partner operations. The BaaS agreement should therefore include strong audit rights, information access obligations and regulatory cooperation clauses.
If the interface provider refuses audit access, the bank may face regulatory risk. If the bank cannot demonstrate control over the BaaS model, the regulator may question whether the arrangement is compliant.
23. Termination and Exit Risk
Termination is one of the most neglected areas in BaaS agreements. If the BaaS relationship ends, what happens to customers?
The agreement should regulate:
Customer notification;
Continuation or closure of accounts;
Migration to bank interface;
Outstanding loans;
Cards;
Recurring payments;
Data deletion;
Regulatory notification;
Customer complaints;
Pending disputes;
Access to records;
Transition support.
A sudden termination without a customer transition plan may cause operational chaos and regulatory concern.
24. Dispute Resolution Between Bank and Platform
BaaS disputes may arise from service outages, data breaches, unauthorized transactions, regulatory sanctions, customer complaints, unpaid fees, audit failures, misuse of brand, breach of exclusivity, customer ownership disputes or termination.
The agreement should include a clear dispute resolution mechanism. However, some issues may require immediate injunctive relief, especially where data, security, customer communication or regulatory compliance is at stake.
The parties should also define escalation procedures: operational committee, compliance committee, executive escalation, emergency incident response and legal escalation.
25. Evidence in BaaS Disputes
Evidence is critical. The parties should preserve:
API logs, customer consent records, authentication records, transaction instructions, IP logs, device data, customer complaint records, marketing approvals, KYC files, AML alerts, data-sharing logs, system incident reports, security test results, audit reports, customer disclosures and regulatory notifications.
If a customer sues, the bank and platform must reconstruct the digital journey. Without logs, liability defense becomes difficult.
26. Practical Checklist for Banks
A bank entering a BaaS agreement should:
Confirm that all services are within its license.
Conduct due diligence on the interface provider.
Review the provider’s corporate structure and financial capacity.
Assess cybersecurity and operational resilience.
Approve all customer-facing flows.
Control KYC and AML processes.
Define data-sharing limits.
Ensure banking secrecy compliance.
Maintain audit rights.
Require incident reporting.
Review marketing materials.
Define customer complaint procedures.
Create exit and transition plans.
Notify the BRSA where required.
Monitor the relationship continuously.
27. Practical Checklist for Fintech Platforms
A fintech platform should:
Confirm whether it qualifies as an interface provider.
Check whether it needs a payment or e-money license.
Avoid presenting itself as a bank.
Disclose the licensed bank clearly.
Use compliant customer consent flows.
Implement strong cybersecurity controls.
Limit data use to agreed purposes.
Avoid unauthorized credit decisions.
Maintain transaction and consent logs.
Prepare customer support scripts.
Comply with KVKK.
Review cross-border data transfers.
Coordinate marketing with the bank.
Prepare for audits.
Plan customer transition if the agreement ends.
28. Why Legal Support Is Important
Banking-as-a-Service agreements in Turkey require specialized legal analysis. They combine banking regulation, fintech licensing, payment services, electronic banking, outsourcing, personal data protection, banking secrecy, AML compliance, consumer law, cybersecurity and commercial contract law.
A Turkish banking and fintech lawyer may assist with regulatory classification, BaaS contract drafting, interface provider analysis, payment services licensing, data-sharing structures, KVKK documents, customer terms, API agreements, outsourcing clauses, audit rights, incident response procedures, marketing review, regulatory correspondence and dispute resolution.
Legal review should take place before product launch. Once customers are onboarded, correcting a defective BaaS structure becomes much harder.
Conclusion
Banking-as-a-Service in Turkey creates major opportunities for banks, fintech platforms, e-commerce companies, marketplaces, retailers and digital ecosystems. Through service model banking, licensed banks can offer banking services through the interfaces of capital companies, while fintech platforms can embed financial services into customer journeys.
However, BaaS is not a simple commercial partnership. It is a regulated banking model governed by the Digital Banks and Banking as a Service Regulation, Banking Law No. 5411, electronic banking rules, payment services law, banking secrecy, KVKK, AML obligations and consumer protection rules.
For banks, the key legal risks are outsourcing control, customer data sharing, cybersecurity, regulatory accountability, unauthorized product distribution, customer complaint handling and interface provider oversight. For fintech platforms, the main risks are unauthorized banking activity, unclear licensing status, misleading branding, misuse of customer data, weak security, unlawful credit decisions and contractual liability.
A successful BaaS agreement must clearly allocate roles, responsibilities, data access, customer communication, compliance duties, liability, audit rights and termination consequences. In Turkish fintech law, the strength of a BaaS model depends not only on technology and customer experience, but also on legal architecture. A compliant BaaS structure can create scalable financial innovation; a poorly structured one can create regulatory, civil and reputational risk for both the bank and the platform.
Yanıt yok