Introduction: Why Fintech API Agreements Are Different From Ordinary Software Contracts

Application Programming Interfaces, commonly known as APIs, are now one of the most important pieces of infrastructure in modern financial services.

Banks, payment institutions, electronic money institutions, fintech startups, marketplaces, SaaS providers and embedded finance companies increasingly communicate through APIs rather than traditional manual processes.

An API may allow one company to:

• retrieve account information;
• initiate a payment;
• verify a customer;
• obtain transaction information;
• create a payment account;
• issue a virtual card;
• display a wallet balance;
• initiate a bank transfer;
• provide embedded banking services;
• reconcile merchant transactions.

Commercially, these relationships may appear similar to ordinary software integration.

Legally, however, fintech API arrangements can be significantly more complex.

A poorly structured API agreement can unintentionally place one party within the scope of regulated:

• payment services;
• open banking;
• Banking as a Service;
• electronic money;
• data processing;
• outsourcing.

For this reason, a fintech API agreement should not be treated simply as:

“Provider gives customer access to an API in return for a monthly fee.”

The agreement must reflect the regulatory role performed by each party.

This is particularly important in Türkiye because payment services are regulated under Law No. 6493 and the secondary rules administered by the Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”). The CBRT currently identifies the Payment Services Regulation and the Information Systems and Data-Sharing Communiqué as central components of the payment-services regulatory framework.

Turkish open banking has also become significantly more sophisticated.

On 17 March 2026, the CBRT announced the deployment of ÖHVPS version 2.0.0, expanding account and card information functionality and introducing future-dated and recurring payment initiation capabilities.

Accordingly, the regulatory importance of API documentation is increasing.

A modern Turkish fintech API agreement should answer at least five fundamental questions:

Who provides the regulated financial service?

Who controls the API and underlying data?

Who is responsible to the customer?

Who carries cybersecurity and transaction risk?

What happens when the integration fails or the relationship terminates?

These questions form the basis of legally sustainable fintech API architecture in Türkiye.

1. What Is a Fintech API Agreement?

A fintech API agreement is a contract governing electronic communication between financial or technology systems.

The agreement may regulate:

• API access;
• permitted functionality;
• credentials;
• transaction limits;
• testing;
• service levels;
• customer information;
• security;
• intellectual property;
• regulatory responsibilities.

In practice, the commercial relationship may be documented through several instruments rather than one contract.

For example:

Master Services Agreement

The overall commercial relationship.

API Terms

Technical and operational API use.

Service-Level Agreement

Availability, performance and incident requirements.

Security Annex

Authentication, encryption, access controls and vulnerability management.

Data Processing Agreement

Personal-data roles and processing.

Business Continuity Annex

Disaster recovery and migration.

The important point is that these documents should operate as one coherent regulatory architecture.

An SLA should not promise functionality that the licence agreement legally prohibits.

A data processing agreement should not allocate data roles inconsistently with the actual API flow.

2. API Access Does Not Automatically Mean Open Banking

One of the most important distinctions in Turkish law is between:

technical API connectivity

and

regulated open banking.

The CBRT’s Open Banking Data Sharing Services Guide expressly considers this distinction.

The Guide explains that where the customer contracts directly with the account-servicing financial institution, continues legally to receive the financial service from that institution and obtains only technical support from another provider, the technical service model is generally outside the regulated ÖHVPS open-banking perimeter.

This means a technology company can potentially provide:

• API consolidation software;
• treasury software;
• reconciliation infrastructure;
• banking connectivity tools

without automatically becoming a regulated Account Information Service Provider or Payment Initiation Service Provider.

But the details matter.

3. The Contractual Counterparty Is a Major Regulatory Indicator

The CBRT’s guidance places significant emphasis on which entity is:

• the technical counterparty;
• administrative counterparty;
• legal counterparty.

In a regulated account information model, the third-party provider may contract with the customer and become the party technically, administratively and legally responsible in relation to the account-service provider.

By contrast, where the bank continues to deal directly with the account holder and a technology company merely supplies software, the technical provider may remain outside the regulated open-banking service.

Therefore, API contracts should not casually change legal roles.

A clause stating:

“API Provider shall act as the customer’s financial service provider”

can have very different consequences from:

“API Provider supplies only technical connectivity software and does not provide the underlying financial service.”

Contract drafting should match operational reality.

4. Turkish Law Expressly Recognises Technical Service Providers

The CBRT Guide refers to the technical-service exclusion under Law No. 6493.

Technical services supporting payments can remain outside regulated payment services where they involve functions such as:

• data processing;
• storage;
• security;
• confidentiality;
• verification;
• information technology infrastructure;
• communications infrastructure;

provided the technical provider does not become owner of the funds transferred in the transaction.

This exclusion is extremely important for API companies.

A technology provider may therefore supply sophisticated financial infrastructure without necessarily obtaining a payment licence.

However:

The technical-service exception depends on what the provider actually does—not what the contract calls it.

If a supposedly technical API provider begins:

• contracting as the payment provider;
• receiving payment instructions;
• controlling customer funds;
• independently accessing accounts to provide regulated services,

its regulatory classification can change.

5. White-Label APIs Can Still Be Technical Services

The CBRT’s Open Banking Guide contains a particularly useful white-label example.

A holding company obtains software from a technology company that consolidates web services from the holding company’s own banks.

The software is offered on a white-label basis and operates within the customer’s infrastructure.

The banks continue to treat the holding company—not the technology company—as their technical, administrative and legal counterparty.

The CBRT concludes that the technology provider does not require payment initiation or account information authorisation in that particular structure.

This demonstrates an important principle for API agreements:

White-label branding does not by itself transform a technical API provider into a regulated financial institution.

The real issue remains who is providing the regulated service.

6. Open Banking APIs Are Regulated Differently

The position changes when the fintech actually provides:

• Payment Initiation Services; or
• Account Information Services.

These services are regulated payment services under Article 12 of Law No. 6493.

The CBRT’s current payment-services architecture uses the Ödeme Hizmetleri Veri Paylaşım Servisleri – ÖHVPS framework and the BKM API Gateway, commonly referred to as GEÇİT.

The CBRT explains that account-servicing payment service providers expose the required services according to the ÖHVPS API standard, while authorised payment service providers access those services through the standardised infrastructure.

This is not merely a private commercial API ecosystem.

It is regulatory infrastructure.

7. A Private Contract Cannot Replace Open Banking Authorisation

Suppose Bank A signs a contract with Fintech B stating:

“Fintech B may initiate payments from Bank A customer accounts.”

That contract alone does not necessarily give Fintech B the regulatory authority to offer Payment Initiation Services.

The underlying activity must fall within Fintech B’s permitted licence scope.

The CBRT currently publishes payment and electronic money institutions together with their individual Article 12 service permissions, including specific permissions for payment initiation and account information services.

Therefore:

Contractual permission from a bank is not a substitute for regulatory authorisation.

Before executing an open banking API agreement, the parties should confirm the exact authorised service scope of each regulated participant.

8. Standard ÖHVPS Architecture Does Not Depend on a Bilateral HHS–YÖS Contract

This is one of the most important contractual points in Turkish open banking.

The CBRT Guide explains that, for services provided through the GEÇİT infrastructure, the Account Servicing Payment Service Provider (“HHS”) and the Authorised Payment Service Provider (“YÖS”) do not enter into a separate agreement, contract or undertaking with each other for that service.

Instead, both sides execute the required undertaking with BKM.

This has major practical significance.

Companies should not assume that every Turkish open-banking integration must be governed by a large bilateral “Open Banking API Agreement” between the bank and every authorised third party.

The regulatory architecture itself already determines important parts of:

• access;
• technical standards;
• responsibilities;
• certification.

Bilateral commercial arrangements may still be relevant for services outside the standard architecture, but they must not undermine regulated access rights.

9. API Agreements Must Not Restrict Statutory Open Banking Access

Where legislation requires account-servicing institutions to make open banking infrastructure available to authorised providers, the API contract should not introduce artificial commercial barriers inconsistent with regulatory obligations.

For example, provisions requiring:

• excessive exclusivity;
• arbitrary approval rights;
• discriminatory technical restrictions

may require careful regulatory analysis.

The ÖHVPS architecture was specifically designed to create a standardised, competitive open banking ecosystem in which authorised third-party payment providers can consume services made available by account-servicing providers through the standard API infrastructure.

Commercial contracts should support that structure rather than contradict it.

10. The API Standard Is Part of the Legal Risk Analysis

The technical specification should not be treated as irrelevant to lawyers.

The CBRT states that the technical and operational requirements for ÖHVPS are established through the ÖHVPS API Principles and Rules.

The architecture requires account-servicing providers to make services available through the BKM API Gateway according to the applicable standard.

Accordingly, an open banking agreement should address:

• compliance with the current API standard;
• certification;
• version management;
• technical changes;
• deprecation of endpoints.

A contract promising indefinite support for an old API version can become commercially problematic when regulatory infrastructure evolves.

11. API Version Management Became More Important in 2026

API contracts should contain a detailed change management clause.

This is particularly relevant because Turkish open banking functionality continues to expand.

In March 2026, the CBRT announced ÖHVPS version 2.0.0, introducing or expanding functionality involving:

• account information;
• card information;
• card transactions;
• future-dated payment initiation;
• recurring payment initiation.

An API agreement should therefore determine:

• notice periods for version changes;
• backward compatibility;
• testing obligations;
• certification responsibilities;
• migration deadlines.

A fintech that fails to update its API integration can lose the practical ability to provide its service even where its licence remains valid.

12. Scope of API Use Must Be Precisely Defined

One of the most important provisions in any fintech API agreement is the permitted use clause.

The contract should identify:

• which API endpoints may be used;
• which products are supported;
• which customers may access them;
• whether use is production or testing only;
• permitted transaction types.

Vague wording such as:

“The customer may use all APIs for financial services”

can create unnecessary regulatory ambiguity.

A better structure distinguishes between:

• account data;
• payment initiation;
• merchant services;
• customer onboarding;
• virtual card issuance;
• reconciliation.

Different API functions can have different regulatory consequences.

13. API Access Should Not Expand a Licence by Contract

This principle is especially important where one institution holds several regulated permissions and another does not.

Suppose an EMI has authority for:

• payment accounts;
• acquiring;
• electronic money,

but not Account Information Services.

An API agreement with a bank cannot automatically expand that EMI’s licence to include account information services.

The CBRT’s public registers make payment service permissions transparent on an institution-by-institution basis.

API functionality should therefore be mapped directly against the authorised regulatory scope.

14. Customer Consent Must Be Built Into the API Architecture

Open banking is not simply institution-to-institution data sharing.

The customer remains central.

The current Information Systems Communiqué requires separate customer approval for each:

• information request;
• payment initiation transaction

under the relevant payment initiation and account information services.

For account information services, consent regarding specified accounts and defined transactions can also be structured through the applicable agreement.

Therefore, an API provider should not assume that a broad clause stating:

“Customer authorises all future account access”

will necessarily be sufficient.

Consent and approval flows need to reflect the regulated service.

15. Customer Consent and KVKK Consent Are Not Always the Same Thing

This distinction is frequently overlooked.

An approval required to perform a payment transaction under payment-services legislation is not automatically identical to an explicit consent used as a personal-data processing ground under KVKK.

The legal basis for:

• payment execution;
• account access;
• personal data processing;
• marketing

should be analysed separately.

In July 2026, the Turkish Personal Data Protection Authority published a dedicated payment and electronic money sector guide addressing matters including:

• controller/processor roles;
• personal data categories;
• processing conditions;
• data transfers;
• security.

Fintech API agreements should therefore contain a detailed data-role analysis rather than repeatedly using the word “consent” as a universal legal solution.

16. Controller and Processor Roles Must Be Determined Function by Function

An API relationship can involve several different data roles.

For example:

Bank A maintains the account.

Fintech B obtains transaction data to provide account aggregation.

Technology Provider C hosts the API gateway.

Fintech B may be an independent controller for the financial service it provides.

Technology Provider C may act as a processor for some processing activities.

But these classifications cannot be determined solely from contract labels.

The KVKK sector guide expressly addresses the distinction between data controllers and processors in the payment/e-money sector.

A fintech API data annex should therefore identify:

data category → purpose → legal basis → receiving party → role → retention period.

17. API Data Should Be Limited to the Necessary Scope

API architecture should follow a data-minimisation approach.

If an embedded finance platform needs:

• customer name;
• account number;
• available balance

to provide a particular service, it should question whether it also needs:

• complete transaction history;
• identity documents;
• unrelated customer profile information.

Excessive API permissions increase:

• KVKK risk;
• cybersecurity exposure;
• regulatory risk.

A well-drafted API contract should therefore combine commercial access rights with data minimisation.

18. Security Obligations Should Be Detailed, Not Generic

A clause stating:

“The parties shall maintain appropriate cybersecurity”

is rarely enough for a significant fintech integration.

The contract should address:

• authentication;
• certificates;
• credential storage;
• access controls;
• API keys;
• encryption;
• penetration testing;
• vulnerability management;
• logging;
• incident response.

The CBRT’s ÖHVPS architecture is itself based on standardised security and certification rather than unrestricted bilateral technical access.

For embedded finance APIs outside ÖHVPS, the contractual security specification becomes even more important.

19. API Credentials Must Be Protected

API credentials can allow extremely sensitive operations.

Depending on the service, compromise could permit an attacker to:

• retrieve account data;
• initiate transactions;
• create accounts;
• modify beneficiaries.

API agreements should therefore specify:

• who may hold credentials;
• whether credentials can be shared;
• rotation periods;
• revocation procedures;
• storage requirements.

Credentials should not be treated as ordinary usernames and passwords.

20. Strong Authentication and Transaction Security Cannot Be Contracted Away

Where applicable financial regulation requires strong customer authentication or specific transaction-security controls, the parties cannot agree contractually to eliminate them for convenience.

This is particularly important for embedded banking.

Under the BDDK’s Service Model Banking framework, where customers access banking services through an interface provider, the service bank remains responsible for ensuring the customer-contract process is conducted correctly, while the service bank and interface provider are jointly responsible for specified authentication and transaction-security obligations relating to the customer-facing interface.

The API agreement should therefore allocate operational tasks without attempting to transfer away mandatory legal responsibility.

21. Embedded Finance API Agreements Require Different Analysis From Open Banking

Open banking and embedded finance are related but not identical.

Open Banking

Typically focuses on regulated:

• account information;
• payment initiation.

Embedded Finance

Can include:

• embedded bank accounts;
• payment accounts;
• cards;
• wallets;
• lending;
• BaaS.

An embedded finance API agreement may therefore involve a much broader service package.

The contract should identify the regulated institution behind each service.

22. Banking as a Service APIs Are Subject to BDDK Rules

Türkiye has a specific Service Model Banking framework.

In this model:

Service Bank → API/Open Banking Services → Interface Provider → Customer

The interface provider can offer banking functionality through its own application, but the underlying regulated banking service remains with the service bank.

BDDK’s current legislation continues to include the Digital Banks and Service Model Banking Regulation.

The API contract between a service bank and interface provider therefore sits inside a regulated banking arrangement rather than a simple software partnership.

23. The Customer Must Still Have a Relationship With the Service Bank

One of the most important BaaS principles is that the customer must have a contractual relationship with the service bank.

BDDK expressly states that the service bank may provide banking services to the interface provider’s customer only after the required contractual relationship with the bank has been established.

Where that relationship is established electronically through the interface provider’s application, the service bank remains responsible for compliant customer identification and the integrity of the digital contracting process.

Therefore, an API contract cannot lawfully create the fiction that:

“The fintech is the bank’s customer and all end users are only customers of the fintech.”

The actual regulated banking relationship matters.

24. Security Responsibility Can Be Joint in BaaS

BDDK goes further in the BaaS framework.

The service bank and interface provider are jointly responsible for compliance with specified authentication and transaction-security requirements applicable to the interface through which the customer accesses the bank.

This has direct contractual consequences.

An API agreement should address:

• allocation of security controls;
• incident escalation;
• vulnerability remediation;
• authentication failure;
• fraud investigation.

But the agreement should also acknowledge that private indemnification does not necessarily eliminate statutory joint responsibility.

25. BaaS Is Already Being Implemented in Practice

This is no longer merely a theoretical model.

BDDK’s 2025 Annual Report states that three banks were authorised during the year to provide banking services as service banks through fintech interface providers using open-banking services.

Accordingly, service bank–interface provider API agreements are becoming an increasingly significant area of Turkish fintech contracting.

26. Service-Level Agreements Are Critical

Fintech API downtime can have immediate financial consequences.

If an API fails:

• customers may be unable to pay;
• merchants may not settle transactions;
• account data may become unavailable;
• payment orders may fail.

The SLA should therefore specify measurable metrics such as:

• uptime;
• response time;
• transaction latency;
• error rate;
• scheduled maintenance;
• recovery time.

It should also classify incidents according to severity.

For example:

Critical Incident: payment initiation unavailable.

High Incident: delayed account information.

Low Incident: reporting dashboard issue.

27. Service Credits Are Not Enough for Critical Financial APIs

Many SaaS contracts provide only:

“10% service credit if uptime falls below target.”

That remedy may be commercially insufficient for regulated financial infrastructure.

Where API failure creates:

• regulatory breach;
• customer loss;
• fraud;
• large-scale operational disruption,

the parties should consider whether the agreement requires broader remedies.

Financial APIs should not be treated like ordinary website-hosting contracts.

28. Liability Must Follow Regulatory Reality

API agreements often include very broad liability exclusions.

For example:

“Provider shall not be liable for any transaction performed through the API.”

Such wording may not be commercially or legally realistic.

The parties should determine responsibility for:

• unauthorised transactions;
• duplicate payment instructions;
• incorrect API data;
• delayed settlement;
• credential compromise;
• service interruption.

The allocation should correspond to which party controlled the relevant risk.

A contract cannot always eliminate statutory responsibilities toward customers merely by reallocating liability internally.

29. Indemnification Should Be Specific

A fintech API agreement may include indemnities covering:

• data breaches;
• regulatory violations;
• intellectual property infringement;
• unauthorised use.

However, extremely broad clauses such as:

“Fintech shall indemnify Bank for everything related to the API”

should be approached carefully.

A more sustainable model aligns indemnification with:

• control;
• causation;
• breach.

The bank should not transfer its own regulatory failures entirely to the fintech merely because an API is involved.

30. Regulatory Fines Need Special Treatment

Contracts frequently attempt to allocate regulatory fines.

The legal effectiveness of such clauses can depend on the nature and cause of the fine.

From a commercial perspective, the agreement can provide indemnification where one party’s contractual or legal breach causes the other party to incur regulatory loss.

But a party should not assume that a contractual indemnity prevents the regulator from imposing direct responsibility on the regulated institution.

This is especially important given the CBRT’s active enforcement approach.

For 2025 supervision, the CBRT reported seven licence revocations, fourteen licence suspensions and administrative fines totalling approximately TRY 373.2 million against 72 institutions.

API compliance should therefore be treated as a genuine regulatory issue.

31. Incident Notification Deadlines Should Be Contractually Short

Cyber incidents can require rapid regulatory and customer response.

The API agreement should define:

• what constitutes an incident;
• when the clock starts;
• who must be notified;
• what information must be supplied.

The contract should distinguish:

awareness of an incident

from

completion of the investigation.

A provider should not wait three weeks to notify the regulated institution because the root cause has not yet been identified.

Early warning is essential.

32. Logs and Evidence Must Be Preserved

When payment disputes arise, API logs may become decisive evidence.

Records can show:

• authentication time;
• payment instruction;
• data received;
• API response;
• error codes.

The agreement should therefore specify:

• logging requirements;
• log retention;
• integrity;
• access.

Logs should also identify the relevant party or system sufficiently to allocate responsibility.

33. Audit Rights Are Essential

Fintech API relationships frequently qualify as or interact with regulated outsourcing.

The CBRT Information Systems Communiqué imposes detailed requirements on outsourced services, including the ability of the institution, auditors and CBRT to obtain information and records relating to outsourced functions.

An API contract involving significant outsourced infrastructure should therefore include appropriate:

• inspection rights;
• audit rights;
• regulatory access rights.

A vendor’s standard statement that “no audits are permitted” can be incompatible with financial-sector needs.

34. Subcontracting Must Be Controlled

The API provider may itself rely on:

• cloud providers;
• KYC providers;
• cybersecurity vendors;
• data centres.

The agreement should determine:

• whether subcontracting is permitted;
• whether notice is required;
• whether consent is required for material subcontractors;
• whether subcontractors are subject to equivalent security obligations.

A fintech should know who is actually processing its financial data.

35. Data Localization Can Restrict API Architecture

A technically global API model may face Turkish localization rules.

The CBRT Information Systems Communiqué requires payment and electronic money institutions to maintain primary systems, secondary systems and relevant backups in Türkiye and contains additional rules for systems used in payment transactions.

Therefore, a contract allowing the API provider to move Turkish production infrastructure to any global region at its sole discretion may create regulatory problems.

Infrastructure geography should be contractually controlled.

36. API Agreements Need Business Continuity Provisions

The contract should define what happens if the API provider becomes unavailable.

Important issues include:

• backup connectivity;
• recovery procedures;
• failover;
• alternative providers.

Financial institutions cannot always simply wait until the service is restored.

Critical APIs may support thousands of transactions every minute.

Business continuity should therefore be a contractual obligation.

37. Exit Strategy Is as Important as Integration

Fintech companies often spend months planning integration and almost no time planning termination.

An API agreement should address:

• data export;
• migration;
• credential revocation;
• transition assistance;
• deletion.

The objective is to avoid regulatory and operational lock-in.

The institution should be capable of terminating the API relationship without losing legally required records or completely disabling customer services.

38. API Portability Can Reduce Vendor Lock-In

Where commercially possible, API integrations should use:

• standard formats;
• documented schemas;
• exportable data.

Proprietary systems can create dependency.

Vendor lock-in becomes particularly dangerous when:

• the provider increases prices;
• the provider loses regulatory eligibility;
• a security incident occurs.

Portability should therefore be treated as both a commercial and compliance issue.

39. Intellectual Property Must Be Separated From Customer Data

Fintech API agreements often contain disputes concerning ownership.

The provider may own:

• source code;
• API architecture;
• documentation.

The customer may own:

• customer data;
• transaction records;
• configuration.

The agreement should distinguish these clearly.

A provider should not claim ownership over regulated customer records merely because those records pass through its API.

40. API Documentation Should Be Contractually Controlled

Developers depend on:

• schemas;
• endpoint definitions;
• sandbox documentation;
• error codes.

The agreement should specify:

• who maintains documentation;
• how changes are announced;
• which version is legally authoritative.

A mismatch between actual API behaviour and documentation can create financial loss.

Documentation should therefore form part of the contractual framework.

41. Sandbox and Production Environments Must Be Separated

Testing should occur within dedicated sandbox environments where possible.

Production customer credentials should not be casually used for development.

The Turkish open-banking architecture itself incorporates testing and certification processes through BKM’s central infrastructure.

For private embedded-finance APIs, the parties should adopt similarly disciplined environment separation.

42. Rate Limits and Transaction Limits Should Be Transparent

API providers frequently impose:

• requests per second;
• daily transaction limits;
• throttling.

These controls may be necessary for security and system stability.

But they should not unexpectedly prevent a regulated fintech from serving customers.

The contract should distinguish:

• normal rate limits;
• emergency throttling;
• suspicious activity restrictions.

Material restrictions should be communicated clearly.

43. Suspension Rights Must Be Carefully Drafted

A provider may need to suspend API access because of:

• security incidents;
• legal requirements;
• fraud;
• unpaid fees.

But unrestricted clauses such as:

“Provider may suspend the API at any time for any reason”

can create significant operational risk.

The agreement should distinguish between:

Immediate Emergency Suspension

Security or regulatory emergency.

Ordinary Suspension

Commercial breach after notice.

Critical financial services require predictable suspension rules.

44. Regulatory Change Clauses Are Essential

Fintech regulation changes rapidly.

An API agreement signed today may be affected later by:

• CBRT rules;
• BDDK rules;
• KVKK changes;
• new API standards.

The contract should provide mechanisms to:

• implement mandatory changes;
• revise specifications;
• allocate implementation costs;
• terminate if compliance becomes impossible.

The March 2026 expansion of ÖHVPS is a practical example of why API relationships must be capable of regulatory evolution.

45. API Agreements With Foreign Providers

Foreign technology providers present additional issues.

The parties should review:

• governing law;
• jurisdiction;
• data transfer;
• infrastructure location;
• regulatory audit.

A contract governed by foreign law does not eliminate Turkish mandatory financial regulations where the API supports regulated Turkish financial activity.

Likewise, using an overseas API does not automatically permit the Turkish institution to transfer all customer data abroad.

46. Governing Law and Dispute Resolution

For substantial international API relationships, parties frequently choose:

• Turkish courts;
• arbitration;
• foreign courts.

The dispute clause should consider:

• urgency of service restoration;
• confidentiality;
• enforcement.

A five-year litigation process may not be a realistic remedy when access to a critical payment API has been suspended.

Interim relief and technical transition rights therefore deserve particular attention.

47. Source Code Escrow May Be Appropriate for Critical APIs

Not every API requires source code escrow.

However, for highly critical proprietary systems, the regulated institution may consider whether source-code or continuity arrangements are appropriate where:

• the provider becomes insolvent;
• support permanently ends;
• operations cease.

The objective is not necessarily to obtain ownership of the vendor’s software.

It is to prevent the institution from becoming incapable of servicing customers because a critical vendor disappears.

48. Fintech API M&A Due Diligence

Investors acquiring an API-driven fintech should review more than revenue and user growth.

Important questions include:

Regulatory Classification

Is the company really technical, or is it providing regulated payment services?

Licence Scope

Do its functions match its licence?

API Agreements

Are important integrations properly documented?

Customer Consent

Are open-banking approvals compliant?

Data Rights

Does the company have lawful access to all data used?

SLA

Can counterparties terminate essential integrations easily?

Security

Has the company suffered major API incidents?

Change of Control

Do contracts terminate upon acquisition?

Exclusivity

Is the company locked to one bank or payment provider?

Vendor Dependency

Can integrations be migrated?

API contracts can directly affect fintech valuation.

49. Change-of-Control Clauses Can Become Deal Risks

A fintech may depend on one bank API representing 60% of its revenue.

If the API agreement states:

“Agreement terminates automatically if more than 25% of Fintech’s shares are transferred,”

an acquisition can destroy the target’s business.

Investors should therefore identify:

• consent rights;
• assignment restrictions;
• change-of-control triggers

before signing an acquisition agreement.

50. Exclusivity Should Be Used Carefully

A bank may ask a fintech not to integrate competitors.

A fintech may ask a bank not to work with competing platforms.

Such provisions may have:

• commercial consequences;
• competition-law implications;
• open-banking regulatory implications.

Exclusivity should therefore be narrowly drafted according to legitimate commercial needs.

In regulated open-banking infrastructure, contractual exclusivity should never be used to defeat access obligations established by financial legislation.

51. Common Fintech API Agreement Mistakes

Mistake 1: “An API Contract Gives Us Regulatory Permission”

Incorrect.

A commercial agreement cannot replace the required payment-service authorisation.

Mistake 2: “Every API Integration Is Open Banking”

Incorrect.

The CBRT expressly distinguishes regulated account information/payment initiation services from technical-service models.

Mistake 3: “Calling Us a Technical Provider Makes Us Unregulated”

Incorrect.

Actual functionality and responsibility determine classification.

Mistake 4: “HHS and YÖS Must Always Sign a Bilateral API Agreement”

Not within the standard GEÇİT structure. The CBRT Guide explains that both sides instead execute the relevant undertaking with BKM for that architecture.

Mistake 5: “One Broad Customer Consent Covers Everything”

Open-banking approvals, payment consent and KVKK processing grounds should be analysed separately.

Mistake 6: “The Vendor Owns All Data Because It Owns the API”

API intellectual property and regulated customer/transaction records are separate legal concepts.

Mistake 7: “An SLA Service Credit Solves All Downtime Risk”

Financial API outages can produce regulatory and customer consequences far beyond monthly subscription fees.

Mistake 8: “The Bank Can Transfer All Cybersecurity Responsibility to the Fintech”

In BaaS, BDDK imposes joint responsibility for specified customer-interface authentication and transaction-security obligations.

Mistake 9: “Foreign Governing Law Means Turkish Fintech Rules Do Not Apply”

Mandatory Turkish financial regulation can continue to apply to regulated Turkish services.

Practical Fintech API Agreement Checklist for Turkey

Before signing a fintech API agreement, the parties should review the following.

Regulatory Roles

Who is the bank, payment institution, EMI, technical provider or interface provider?

Licence Scope

Does each regulated function fall within the relevant permission?

API Scope

Which endpoints and services are covered?

Customer Relationship

Who contracts with the end user?

Customer Consent

How are payment initiation and account information approvals collected?

KVKK

Who is controller or processor for each data flow?

Data Minimisation

Is API access restricted to necessary information?

Authentication

How are customers, systems and credentials authenticated?

Security

What encryption, logging, penetration testing and access controls apply?

API Standards

Does the integration comply with the relevant ÖHVPS or other required standard?

Version Management

How will updates and deprecation be handled?

SLA

What are uptime, latency and recovery requirements?

Incident Response

How quickly must security and operational incidents be reported?

Liability

Who bears losses from incorrect data or transactions?

Regulatory Fines

How is breach-related financial exposure allocated internally?

Audit

Does the regulated institution retain adequate audit and regulator-access rights?

Subcontracting

Who are the subprocessors and infrastructure providers?

Data Location

Are Turkish localization requirements satisfied?

Business Continuity

Can services continue if the API fails?

Termination

What happens to customer services and data?

Exit and Migration

Can another provider take over?

Change of Control

Could investment or M&A terminate the agreement?

Regulatory Change

Can mandatory changes be implemented quickly?

Frequently Asked Questions About Fintech API Agreements in Turkey

Are fintech API agreements regulated in Turkey?

There is no single law titled “Fintech API Agreements Law.” However, API relationships can fall within payment, open banking, banking, information-systems, outsourcing and KVKK regulation depending on the services involved.

Is an API integration automatically an open banking service?

No. The CBRT distinguishes regulated Payment Initiation and Account Information Services from technical-service structures in which the customer continues dealing directly with the financial institution.

Can a software company provide banking API connectivity without a payment licence?

Potentially yes where it genuinely remains a technical provider. The CBRT has specifically analysed white-label technical software models that did not require payment initiation/account information authorisation.

Does a bank contract give the fintech permission to provide open banking?

No. Where the fintech itself provides regulated Account Information or Payment Initiation Services, the appropriate regulatory authorisation remains necessary.

What are ÖHVPS APIs?

They are the regulated data-sharing services supporting Turkish Payment Initiation and Account Information Services through the standard architecture involving account-servicing providers, authorised providers and the BKM API Gateway.

Do banks and open banking providers always sign direct agreements?

Not for the standard GEÇİT model described in the CBRT Guide. HHS and YÖS do not execute a bilateral agreement for that service; each executes the required undertaking with BKM.

What changed in Turkish open banking in 2026?

The CBRT launched ÖHVPS version 2.0.0 in March 2026, expanding account/card information and introducing future-dated and recurring payment initiation functionality.

Can an API contract expand a payment institution’s licence?

No. Contractual scope and regulatory licence scope are separate. A company should provide only regulated services for which it holds the necessary authority.

Is customer consent required?

Yes. The Information Systems Communiqué contains specific customer-approval rules for Payment Initiation and Account Information Services.

Is open banking consent the same as KVKK explicit consent?

Not necessarily. Payment-service authorisation and personal-data processing must be analysed separately under their respective legal frameworks.

Does KVKK apply to API data?

Yes. The 2026 payment/e-money sector guide specifically addresses processing conditions, controller/processor status, data transfers and security.

Can a foreign SaaS provider host API data abroad?

The answer depends on both KVKK and sector-specific financial regulation. Turkish payment institutions are subject to CBRT system and data localization rules that must be analysed separately from KVKK international-transfer rules.

What is BaaS in Turkey?

Service Model Banking allows customers to access banking services of a service bank through an interface provider. The arrangement is governed by BDDK regulation.

Does the BaaS fintech become the bank?

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

Who is responsible for security in BaaS?

For specified electronic banking authentication and transaction-security obligations applicable to the interface, the service bank and interface provider are jointly responsible.

Should an API agreement contain an SLA?

Yes. For important fintech APIs, measurable availability, incident response and recovery obligations are essential to operational and regulatory risk management.

Should API agreements contain audit rights?

Where the API service forms part of regulated outsourcing or important financial infrastructure, appropriate audit and regulatory access provisions are highly important. The CBRT outsourcing framework expressly preserves institutional, auditor and regulatory access to relevant outsourced information.

What happens if the API provider changes its subcontractors?

The agreement should require appropriate notice and regulatory safeguards, particularly where subcontractors process customer or financial information.

Can an API agreement be governed by foreign law?

Commercially, foreign governing law may be selected in appropriate circumstances. However, that does not eliminate mandatory Turkish financial, banking, data-protection or regulatory requirements.

Conclusion: How Should Fintech API Agreements Be Structured in Turkey?

Fintech API agreements are becoming one of the most important contract categories in the Turkish financial technology sector.

But they should not be drafted as ordinary IT agreements.

The correct legal analysis begins by identifying what the API actually does.

An API may provide only:

• data transmission;
• software connectivity;
• technical infrastructure.

Or it may facilitate:

• payment initiation;
• account information;
• banking;
• payment accounts;
• electronic money.

Those functions can produce completely different licensing consequences.

The CBRT’s Open Banking Guide provides one of the clearest examples.

Where the customer continues to contract directly with its banks and obtains only technical software from another provider, the technical company may remain outside regulated open banking.

The CBRT’s white-label example reinforces the same principle.

A technology provider supplied software that consolidated a corporate customer’s bank web services, while the customer remained the banks’ technical, administrative and legal counterparty.

The CBRT concluded that the technology provider did not require payment initiation/account information authorisation in that model.

This creates meaningful room for:

• treasury platforms;
• ERP providers;
• fintech SaaS businesses;
• API aggregators

to provide technology without automatically becoming regulated payment institutions.

But the opposite is equally important.

Where the API company becomes the entity directly providing customers with regulated account information or payment initiation, the licence analysis changes.

An API contract cannot manufacture regulatory authorisation.

This is why the regulatory perimeter should be reviewed before the API agreement is signed.

The second major issue is that regulated open banking has its own infrastructure.

Turkish ÖHVPS is built around standardised API requirements and the BKM GEÇİT architecture.

In that standard model, HHS and YÖS do not need to negotiate a private bilateral open-banking agreement with one another for the regulated service; each undertakes the necessary relationship through BKM.

This substantially changes the commercial contracting analysis.

A bank should not use API terms to re-create unnecessary barriers to regulated access.

An authorised fintech should not assume that a private commercial contract grants wider rights than the regulatory standard.

Technical standards also matter.

The ÖHVPS ecosystem continues to evolve.

In March 2026, the CBRT deployed version 2.0.0, expanding account and card information and enabling future-dated and recurring payment initiation.

For this reason, a good API contract needs a strong:

version control + change management + migration

framework.

An agreement designed around one static API will age badly in a regulated fintech environment.

The third major issue is customer approval.

Open banking is not simply a data-sharing agreement between two companies.

The customer must remain in control of the relevant service.

The CBRT Information Systems Communiqué requires separate approval in connection with individual information requests and payment initiation transactions, while account information consent can be structured for specified accounts and transactions in the applicable contractual framework.

Fintech developers should therefore design consent screens together with legal teams.

A consent clause hidden inside general terms cannot always replace a properly structured transaction-level authorisation mechanism.

The fourth major issue is personal data.

Financial APIs can expose highly sensitive:

• identity information;
• account balances;
• transaction histories;
• merchant information.

The KVKK Authority’s July 2026 payment/e-money sector guide confirms the importance of controller/processor classification, lawful processing grounds, transfers and data security in this sector.

A fintech API contract should therefore contain a genuine data architecture.

It should answer:

who receives which data → for what purpose → under which legal basis → for how long → with whom it can be shared.

The fifth major issue is embedded banking.

Türkiye’s BaaS rules create a direct relationship between the service bank and interface provider.

The end user accesses banking through the fintech interface, but the regulated banking relationship remains with the service bank.

BDDK expressly requires a contractual relationship between the service bank and the customer.

More importantly, BDDK imposes joint responsibility on the interface provider and service bank for specified authentication and transaction-security requirements in the customer-facing interface.

This means an API agreement cannot simply state:

“All cybersecurity responsibility belongs to the API provider.”

Nor can it state:

“All cybersecurity responsibility belongs to the bank.”

The contract should allocate operational duties while acknowledging mandatory regulatory responsibility.

BaaS is also becoming increasingly practical in Türkiye.

BDDK’s 2025 Annual Report states that three banks were permitted to provide service-model banking through fintech interface providers using open-banking services.

API agreements between banks and fintech interface providers will therefore likely become increasingly important.

The sixth issue is service continuity.

A traditional software API outage may inconvenience a user.

A financial API outage can prevent:

• a payment;
• access to funds;
• banking transactions.

This is why fintech SLA provisions should be significantly more sophisticated than ordinary SaaS clauses.

They should define:

• uptime;
• latency;
• recovery;
• incident classification;
• escalation.

The contract should also provide a credible exit strategy.

Fintechs should avoid becoming operationally dependent on one provider to such an extent that termination would make continued regulated service impossible.

This is also why data portability and transition assistance are commercially important.

The seventh issue is regulatory access.

Financial API infrastructure may form part of regulated outsourcing.

The CBRT’s information systems framework requires the institution to preserve the ability of the CBRT and auditors to obtain relevant information concerning outsourced activities.

An international SaaS vendor’s standard:

“No audit rights”

clause may therefore not be suitable for a Turkish regulated financial customer.

The eighth issue is enforcement.

These are not merely theoretical drafting concerns.

The CBRT reported that its 2025 supervision resulted in:

• seven licence revocations;
• fourteen licence suspensions;
• administrative fines exceeding TRY 373 million.

For a regulated fintech, compliance failures can therefore affect far more than contractual damages.

They can affect the licence itself.

For founders, banks and fintech companies, the recommended sequence for an API project is therefore:

identify functionality → classify regulated activity → identify licence holder → determine customer relationship → map data → design consent → determine API standard → negotiate SLA/security → allocate liability → establish audit rights → control subcontracting → plan continuity and exit → test integration → launch.

The most important principle is:

Never allow the API architecture, regulatory architecture and contract architecture to tell three different stories.

If the technology says the fintech controls the payment,

the customer agreement says the bank controls the payment,

and the API contract says nobody is responsible for the payment,

the model contains obvious regulatory risk.

A sustainable fintech API structure should instead ensure that:

technology function = contractual function = regulated function.

When those three elements are aligned, APIs can support highly scalable:

• open banking;
• embedded payments;
• embedded finance;
• Banking as a Service

business models in Türkiye.

Legal Disclaimer: This publication provides general information concerning fintech API agreements, open banking, embedded finance, Banking as a Service, payment services, data protection and related regulation in Türkiye as of July 2026. It does not constitute legal, financial, cybersecurity or regulatory advice. API regulatory classification depends on the services, licence scope, customer relationship, funds flow, data processing, security architecture and contractual allocation applicable to the relevant project. Each fintech API arrangement should therefore be individually reviewed under Law No. 6493, the current CBRT Payment Services Regulation and Information Systems Communiqué, applicable BDDK regulations, Law No. 6698 and other relevant Turkish legislation before integration or commercial launch.