Introduction
Fintech partnerships with banks are one of the most important legal structures in Turkey’s digital finance market. Many fintech companies do not want to become fully licensed banks, but they still want to offer financial products through digital channels. Banks, on the other hand, want to reach new customer segments, modernize distribution, integrate with digital platforms, and compete with fast-moving technology companies. This creates a growing market for bank-fintech partnerships, including Banking-as-a-Service, embedded finance, digital onboarding, open banking integrations, wallet partnerships, lending partnerships, payment solutions, merchant acquiring, data analytics, customer interface models, and white-label financial services.
However, a fintech-bank partnership is not a simple commercial cooperation agreement. It may involve regulated banking services, payment services, electronic money, outsourcing, customer secrets, personal data, AML/KYC, cybersecurity, consumer protection, service continuity, complaint handling, regulatory reporting, audit rights, and liability allocation. The bank may remain legally responsible for regulated banking activity even if the customer interacts through a fintech interface. The fintech company may also face liability if it misleads customers, processes data unlawfully, fails to protect systems, performs unauthorized financial activity, or exceeds the contractual and regulatory limits of its role.
Turkey has a specific legal framework relevant to digital banks and Banking-as-a-Service. The BRSA Regulation on the Operating Principles of Digital Banks and Banking as a Service Model states that its purpose is to determine the procedures and principles for branchless banks serving only through electronic banking service channels and for the provision of banking services as a service model to fintech companies and other businesses. It 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.
This article explains how fintech partnerships with banks should be structured in Turkey, focusing on contractual architecture, outsourcing, BaaS, open banking, customer relationship allocation, data protection, bank secrecy, payment services, MASAK compliance, cybersecurity, consumer protection, and regulatory liability.
1. What Is a Fintech-Bank Partnership?
A fintech-bank partnership is a commercial and regulatory cooperation between a bank and a technology-driven financial company. The fintech company may provide software, user interface, customer acquisition, risk analytics, digital onboarding, payment technology, credit scoring, data analytics, customer support tools, or product distribution. The bank may provide regulated banking infrastructure, accounts, deposits, credit, payment accounts, card issuing, settlement, compliance oversight, or banking services.
Common fintech-bank partnership models include:
Banking-as-a-Service
Embedded finance
White-label banking products
Co-branded digital lending
Open banking integrations
Card issuing partnerships
Merchant acquiring partnerships
Digital wallet connections
Payment initiation and account information services
Bank-backed BNPL or consumer credit
Marketplace lending structures
API-based account access
KYC and onboarding cooperation
Digital customer interface partnerships
Loyalty and reward finance partnerships
The legal classification depends on what the fintech does. A fintech that merely provides software to a bank is different from a fintech that interfaces directly with customers, collects data, initiates transactions, markets financial products, or provides ongoing customer support. The more the fintech interacts with customers and influences regulated financial services, the greater the legal risk.
2. Banking-as-a-Service in Turkey
Banking-as-a-Service, or BaaS, is a regulated model in Turkey. In a BaaS structure, a bank provides banking services through open banking services, while an interface provider offers the customer-facing digital interface. The BRSA regulation defines the service bank as the bank providing service model banking services and defines the BaaS model as one where customers perform banking transactions by directly connecting with the systems of service banks through open banking services via interfaces offered by interface providers.
This model is not merely a technology resale arrangement. It creates a regulated structure involving customer access, banking service delivery, interface responsibility, data sharing, service continuity, and compliance obligations. The customer may experience the fintech interface as the primary app, but the banking service is still provided by the licensed bank.
A BaaS agreement should therefore clearly identify:
The service bank.
The interface provider.
The banking services offered.
The customer journey.
The legal relationship between customer and bank.
The legal relationship between customer and interface provider.
The scope of open banking access.
The data shared between parties.
The role of the fintech in onboarding, support, marketing, and complaints.
The bank’s audit and control rights.
The process for regulatory notifications and inspections.
The consequences of termination.
The bank must avoid losing control over the regulated banking activity. The fintech must avoid presenting itself as a bank if it is only an interface provider.
3. Open Banking and API-Based Cooperation
Open banking is central to modern fintech-bank partnerships. The BRSA information systems regulation defines open banking services as an electronic distribution channel through which customers or persons acting for customers may execute banking transactions or instruct the bank through remote access to financial services via methods such as APIs, web services, or file transfer protocols. It also defines API as an application programming interface enabling software to use functions defined in another software.
In practice, open banking enables fintechs to connect to bank systems and offer account information, payment initiation, financial dashboards, budgeting tools, lending analytics, merchant tools, or embedded banking experiences. However, API access creates serious legal and technical risks.
An API partnership agreement should address:
Permitted API use.
Authentication and authorization.
Customer consent.
Data scope.
Transaction limits.
Access tokens.
Security requirements.
API credentials.
Audit logs.
Error handling.
Service availability.
Incident notification.
Data retention.
Subcontracting.
Regulatory cooperation.
Termination and access revocation.
The contract must match the technical architecture. If the fintech can initiate transactions, the contract must regulate payment order responsibility. If the fintech can access account data, the contract must regulate customer consent, data minimization, confidentiality, and KVKK compliance.
4. Outsourcing and Support Services
Many fintech-bank partnerships involve outsourcing. A bank may procure software, infrastructure, customer support, cloud services, onboarding technology, fraud monitoring, data analytics, call center support, card processing, or interface technology from fintech providers.
The BRSA Regulation on Procurement of Support Services by Banks states that its objective is to set procedures and principles regarding the purchase of support services by banks. The digital banking and BaaS regulation also refers to outsourcing and external service concepts and links them to the broader banking information systems framework.
Outsourcing is legally sensitive because a bank cannot transfer its regulatory responsibility simply by outsourcing a function. The bank must conduct due diligence, manage the risk, preserve audit rights, protect customer information, monitor performance, and ensure continuity.
A bank-fintech outsourcing agreement should include:
Detailed service scope.
Regulatory compliance obligations.
Service levels.
Audit rights.
BRSA and regulator access rights.
Confidentiality.
Bank and customer secret protection.
KVKK clauses.
Cybersecurity requirements.
Business continuity.
Disaster recovery.
Subcontracting restrictions.
Incident notification.
Data localization or access rules where applicable.
Termination assistance.
Step-in rights.
Liability and indemnity.
The bank should also be able to prove that outsourcing does not weaken internal control, risk management, or compliance capacity.
5. Bank Secrecy and Customer Secrets
Bank-fintech partnerships frequently involve customer data. This may include account information, identity records, transaction history, credit data, spending behavior, income data, merchant activity, risk scores, complaint records, and authentication logs. Turkish banking law imposes strict confidentiality duties concerning bank secrets and customer secrets.
The BRSA Regulation on Disclosure of Confidential Information states that its purpose is to determine the scope, form, procedures, and principles for sharing and transferring bank secrets and client secrets. It is based on Articles 73 and 93 of Banking Law No. 5411.
This is critical for fintech partnerships. Even if a customer gives general consent, the bank must still analyze whether sharing customer secret information is lawful, necessary, proportionate, and consistent with regulatory requirements. Banks should avoid excessive data sharing with fintech partners. The fintech should receive only the information necessary for the agreed service.
Contracts should include:
Definition of bank secret and customer secret data.
Permitted data-sharing purposes.
Data minimization obligations.
Customer instruction or consent mechanism where required.
Access restrictions.
Confidentiality undertakings.
Employee confidentiality obligations.
Logging of access.
Prohibition on unauthorized reuse.
Restrictions on analytics and profiling.
Restrictions on onward transfer.
Return or deletion at termination.
Regulatory inspection rights.
A fintech company that receives bank customer data should treat it as highly sensitive regulated information, not ordinary commercial data.
6. KVKK and Personal Data Protection
Bank-fintech partnerships also trigger personal data protection obligations under Law No. 6698 on the Protection of Personal Data, known as KVKK. The official law states that its purpose is to protect fundamental rights and freedoms, particularly privacy, in relation to personal data processing, and to set obligations, principles, and procedures for persons processing personal data.
A bank-fintech partnership should determine whether each party acts as a data controller, joint controller, independent controller, or data processor. The answer may differ by activity. For example, the bank may be controller for banking services, while the fintech may be controller for its own app analytics and processor for bank customer support functions.
KVKK compliance should address:
Privacy notices.
Lawful basis for processing.
Explicit consent where required.
Data minimization.
Purpose limitation.
Cross-border transfer rules.
Data processing agreements.
Retention and deletion.
Data subject rights.
Breach notification process.
Access control.
Security measures.
Vendor and subprocessor control.
Fintech partnerships often fail when product teams design data flows before legal teams map data roles. A proper data protection structure must be built before launch.
7. Payment Services and E-Money Partnerships
Some bank-fintech partnerships involve payment services, electronic money, digital wallets, card issuing, QR payments, merchant acquiring, or payment initiation. Law No. 6493 regulates payment systems, payment services, payment institutions, and electronic money institutions.
A bank may partner with a licensed payment institution or e-money institution. Alternatively, a fintech may provide technology to a bank for payment-related services. The legal issue is whether the fintech itself provides regulated payment services or merely supports the licensed institution.
TÖDEB states that payment institutions and electronic money institutions must obtain an operating license from the CBRT, establish complaint and appeal units, have sufficient personnel and technical equipment, and take measures for business continuity and security and confidentiality of funds and user information. It also states that payment and e-money institutions are subject to CBRT supervision and MASAK liability audits.
If the partnership involves customer funds, wallet balances, merchant settlement, or e-money issuance, contracts must clearly regulate:
Who holds customer funds.
Whether funds are payment funds or e-money funds.
Who safeguards funds.
Who performs reconciliation.
Who handles refunds.
Who handles chargebacks.
Who bears unauthorized transaction risk.
Who reports to regulators.
Who handles customer complaints.
The fintech should not hold or control customer funds unless it is authorized or the structure is otherwise legally compliant.
8. Protection of Funds and Reconciliation
Fund protection is critical in bank-fintech partnerships involving payment services or e-money. TÖDEB explains that funds collected for payment services and electronic money issuance must be protected under regulatory procedures. It also states that funds received for payment purposes must be kept separately, deposited into preservation accounts where required, followed on a customer basis, and reconciled daily with bank statements.
This matters in embedded finance and marketplace models. If a fintech platform collects funds from customers and later transfers them to merchants, borrowers, sellers, or users, the structure must be reviewed carefully. A platform cannot treat customer funds as its own operating cash.
The contract should define:
Customer fund flow.
Timing of receipt and transfer.
Settlement accounts.
Preservation account duties.
Reconciliation frequency.
Shortfall responsibility.
Reporting obligations.
Audit access.
Insolvency protection.
Treatment of refunds and reversals.
Use restrictions.
If funds are not properly segregated, customer protection, regulatory compliance, and insolvency risk become serious concerns.
9. MASAK and AML/KYC Responsibility
Bank-fintech partnerships must address anti-money laundering and counter-terrorist financing obligations. Law No. 5549 on Prevention of Laundering Proceeds of Crime states that its objective is to determine the principles and procedures for preventing laundering proceeds of crime.
Banks, payment institutions, e-money institutions, and other regulated financial actors may have customer identification, beneficial ownership, sanctions screening, suspicious transaction reporting, recordkeeping, and compliance program obligations. A fintech partner may perform some operational tasks, but regulated institutions remain responsible for legal compliance.
The partnership agreement should answer:
Who performs customer identification?
Who verifies identity documents?
Who identifies beneficial owners?
Who screens sanctions and PEP lists?
Who monitors transactions?
Who reviews suspicious activity?
Who files suspicious transaction reports?
Who preserves KYC records?
Who handles law enforcement or MASAK requests?
Who trains employees?
Who bears liability for KYC failure?
The fintech should not independently decide whether to file or not file suspicious transaction reports unless it is the legally responsible obliged party. If the fintech supports AML operations, the bank must retain oversight and control.
10. Customer Relationship and Disclosure
A common problem in fintech-bank partnerships is customer confusion. The customer may download a fintech app, see fintech branding, receive fintech notifications, and contact fintech support, but the underlying bank may provide the regulated financial service.
The customer interface must clearly disclose:
Which entity provides the banking service.
Which entity provides the interface.
Whether the fintech is a bank.
Whether deposits, accounts, cards, or loans are issued by the bank.
Which terms apply.
Which privacy notices apply.
Who handles complaints.
Who is responsible for customer funds.
Whether the product is covered by deposit insurance, where applicable.
Whether the fintech receives commission or fees.
Misleading branding can create regulatory and consumer protection risk. A fintech should not use language that makes customers believe it is a licensed bank if it is not. The bank should ensure that its role is visible where required.
11. Contractual Structure of Bank-Fintech Partnerships
A bank-fintech partnership usually requires more than one contract. The legal documentation may include:
Master cooperation agreement.
BaaS agreement.
API agreement.
Outsourcing or support services agreement.
Data processing agreement.
Confidentiality agreement.
Service level agreement.
Information security addendum.
Business continuity agreement.
Customer terms.
Banking product terms.
Complaint handling protocol.
Regulatory reporting protocol.
Marketing and brand use agreement.
Incident response procedure.
The master agreement should clearly identify the commercial model and regulatory allocation. Technical schedules should be precise. Data schedules should map all data flows. Service schedules should define uptime, support, incident severity, and escalation. Compliance schedules should define KYC, AML, audit, complaint, reporting, and regulatory obligations.
A vague “strategic partnership agreement” is not enough for regulated financial services.
12. Key Clauses in a Bank-Fintech Partnership Agreement
A strong partnership agreement should include the following clauses:
Regulatory status clause: The parties should identify their licenses, regulatory status, and permitted activities.
Scope of services clause: The contract must define exactly what the bank provides and what the fintech provides.
No unauthorized activity clause: The fintech should not perform banking, payment, credit, investment, insurance, or e-money services unless authorized.
Customer relationship clause: The contract should define whether the customer contracts with the bank, fintech, or both.
Data protection clause: KVKK roles, purposes, transfers, retention, security, and data subject rights must be addressed.
Bank secrecy clause: Customer and bank secrets must be protected with strict access and disclosure controls.
AML/KYC clause: Identity verification, suspicious activity escalation, and recordkeeping responsibilities must be allocated.
Cybersecurity clause: Security standards, testing, incident reporting, access control, and audit logs must be defined.
Audit rights clause: The bank and regulators must be able to inspect relevant systems and records.
Service level clause: Uptime, maintenance, response times, and business continuity must be regulated.
Liability clause: Loss allocation for fraud, outages, unauthorized transactions, data breaches, and regulatory sanctions must be clear.
Termination clause: Exit, customer migration, data return, service continuity, and regulatory communication must be addressed.
13. Regulatory Liability
One of the most important legal principles is that regulatory responsibility cannot be fully outsourced. A bank may outsource technical or operational functions, but it remains responsible for banking services provided to customers. A payment institution may use vendors, but it remains responsible for regulated payment services. A fintech interface provider may have contractual obligations, but the bank must maintain regulatory oversight.
Regulatory liability may arise from:
Unauthorized banking activity.
Unlawful outsourcing.
Weak KYC controls.
Data breach.
Unlawful data sharing.
Customer secret violation.
Payment service failure.
Consumer misinformation.
System outage.
Failure to report incidents.
Failure to maintain audit records.
Unlawful fund handling.
Improper complaint handling.
Misleading marketing.
Contracts should allocate economic liability between bank and fintech, but they cannot eliminate regulator-facing responsibility. If the bank is the licensed provider, regulators may hold the bank accountable even if the fintech caused the operational failure. The bank may then seek indemnity from the fintech under the contract.
14. Cybersecurity and Operational Resilience
Fintech-bank partnerships depend on APIs, mobile applications, cloud infrastructure, authentication tools, data transfer channels, and third-party systems. Cybersecurity failures can lead to account takeover, unauthorized transactions, data breaches, payment failures, service outages, or loss of customer trust.
The BRSA information systems regulation sets minimum procedures and principles for managing bank information systems, electronic banking services, related risks, and information systems controls. This makes cybersecurity a core legal requirement, not merely a technical issue.
Contracts should require:
Security architecture review.
Encryption.
Strong authentication.
Penetration testing.
Vulnerability management.
Access control.
Privileged access monitoring.
Secure software development.
API security.
Incident reporting timelines.
Business continuity testing.
Disaster recovery.
Security audit rights.
Regulatory cooperation.
Cybersecurity requirements should be measurable and enforceable. The bank should not rely only on general statements that the fintech will use “reasonable security measures.”
15. Consumer Protection and Complaint Handling
Bank-fintech partnerships often serve consumers. Digital financial products must be transparent, fair, and understandable. A customer should know who provides the financial service, what fees apply, how funds are protected, how complaints are handled, and what happens if the fintech app stops working.
Complaint handling should be coordinated between the bank and fintech. The contract should define:
Complaint intake channel.
Complaint ownership.
Response deadlines.
Fraud escalation.
Data breach escalation.
Payment dispute handling.
Loan dispute handling.
Unauthorized transaction process.
Regulatory complaint coordination.
Customer communication rules.
Recordkeeping.
If the fintech receives a complaint but fails to escalate it to the bank, regulatory risk may arise. If the bank ignores complaints because they came through the fintech interface, consumer disputes may escalate.
16. Marketing, Branding, and Misrepresentation
Marketing is a major risk area. A fintech app may advertise “banking services,” “instant accounts,” “digital loans,” “wallet balances,” or “bank-backed protection.” If the wording is inaccurate, customers may be misled.
The marketing agreement should regulate:
Use of bank name and logo.
Use of fintech brand.
Pre-approval of campaigns.
Prohibited statements.
Disclosure of bank role.
Disclosure of fintech role.
Product risk warnings.
Fee disclosures.
Influencer campaigns.
Social media content.
Customer acquisition messages.
A fintech should not imply that it is licensed as a bank unless it is. A bank should not allow its license or reputation to be used in a way that hides the fintech’s role or creates false expectations.
17. Termination and Exit Planning
Termination is one of the most important issues in bank-fintech partnerships. If the partnership ends, customers may still have accounts, loans, wallet balances, cards, payment orders, pending complaints, open disputes, or stored personal data.
The agreement should regulate:
Termination grounds.
Regulatory termination triggers.
Exit timeline.
Customer notification.
Migration of customers.
Continuation of critical services.
Handling of pending transactions.
Data return and deletion.
Complaint handling after termination.
Regulatory notifications.
Transfer of records.
Access to logs.
Final settlement.
Post-termination confidentiality.
Support during audits and disputes.
A poorly planned exit can harm customers and create regulatory problems. Banks and fintechs should prepare exit plans before launch, not after the relationship breaks down.
18. Practical Compliance Checklist
A bank-fintech partnership in Turkey should consider the following checklist:
Classify the partnership model.
Identify whether BaaS, outsourcing, open banking, payment services, or lending rules apply.
Confirm the bank’s role and fintech’s role.
Define customer-facing disclosures.
Review whether fintech activity requires a license.
Draft a detailed master agreement.
Prepare API and technical schedules.
Prepare outsourcing and service level terms.
Map data flows.
Determine KVKK controller and processor roles.
Review bank secrecy and customer secret rules.
Prepare AML/KYC responsibility matrix.
Create complaint handling workflows.
Set cybersecurity standards.
Define audit and regulator access rights.
Prepare business continuity and disaster recovery rules.
Define liability and indemnity.
Prepare termination and exit plan.
Review marketing materials.
Train operational teams.
Monitor regulatory developments.
This checklist should be adapted to each model. A BaaS app, lending partnership, card issuing model, payment cooperation, open banking integration, or white-label account product will not have identical requirements.
Why Legal Support Is Important
Fintech-bank partnerships require legal support because they involve banking law, payment services, outsourcing, data protection, bank secrecy, AML, cybersecurity, consumer protection, contract law, and regulatory liability. A commercial agreement alone is not enough.
A fintech lawyer can assist with:
BaaS structuring.
Open banking contracts.
Outsourcing analysis.
Support service agreements.
Bank secrecy clauses.
KVKK compliance.
AML/KYC responsibility allocation.
Payment services analysis.
Digital lending structures.
Consumer disclosures.
Marketing compliance.
Cybersecurity and incident clauses.
Regulatory correspondence.
Exit planning.
Dispute resolution.
Legal review should begin before the product is launched. Once customers are onboarded and data flows begin, correcting a non-compliant partnership structure becomes more difficult.
Conclusion
Fintech partnerships with banks in Turkey offer major opportunities for innovation, customer access, embedded finance, digital banking, lending, payments, and open banking. However, these partnerships are legally complex. They must be structured around regulatory responsibility, customer protection, data security, bank secrecy, outsourcing controls, MASAK compliance, and clear contracts.
The BRSA has a specific framework for digital banking and Banking-as-a-Service, including definitions of service bank, interface provider, open banking services, and BaaS model. Law No. 6493 governs payment services and electronic money, while KVKK governs personal data processing. Bank secrecy and confidential information rules require careful treatment of customer data.
The most important legal principle is that substance prevails over labels. A fintech cannot avoid regulation by calling itself a technology provider if it effectively performs regulated financial services. A bank cannot avoid responsibility by outsourcing customer-facing functions to a fintech. The customer journey, data flow, fund flow, contractual role, and regulatory license must all align.
A successful bank-fintech partnership should be transparent, documented, secure, auditable, and regulator-ready. The bank must maintain control over regulated services. The fintech must operate within its role. Customers must understand who provides the financial service. Data must be protected. Funds must be safeguarded. Complaints must be handled. Regulators must be able to inspect the structure.
In Turkey’s growing fintech market, the strongest partnerships will be those that combine innovation with legal discipline. A well-drafted contract is not merely a commercial document. It is the legal architecture that determines responsibility, protects customers, supports compliance, and allows the partnership to scale safely.
Yanıt yok