Introduction: Can a Payment Facilitator Operate Legally in Turkey?

Yes, payment-facilitator-style business models can operate in Türkiye.

However, there is an extremely important qualification:

Turkish law does not provide a standalone regulatory licence called a “Payment Facilitator Licence” or “PayFac Licence.”

A company cannot therefore establish a Turkish entity, describe itself as a PayFac and assume that the commercial model used in the United States, European Union, United Kingdom or another jurisdiction can be imported directly into Türkiye.

Turkish payment law follows a functional regulatory approach.

The legal question is not:

“Is this company a Payment Facilitator?”

The legal question is:

“Which regulated payment services does this company actually provide?”

Depending on the structure, a PayFac may operate as:

• a licensed payment institution providing merchant acquiring;
• a payment institution using another payment service provider’s infrastructure;
• a technical payment gateway supporting a licensed payment service provider;
• a marketplace potentially relying on another specific statutory structure.

The applicable legal regime depends heavily on:

• who signs the merchant agreement;
• who legally provides payment acceptance;
• who controls settlement;
• whether customer or merchant funds pass through the fintech;
• whether payment accounts are operated;
• who performs merchant onboarding;
• whether the fintech acts merely as a software provider.

The principal legislation is Law No. 6493 on Payment and Securities Settlement Systems, Payment Services and Electronic Money Institutions, together with the Regulation on Payment Services and Electronic Money Issuance and Payment Service Providers.

The Central Bank of the Republic of Türkiye (“CBRT” or “TCMB”) regulates and supervises payment institutions and electronic money institutions. The CBRT’s current register identifies the exact Article 12 payment-service permissions held by each authorised payment institution and expressly confirms that the Article 12(1)(c) permission granted to payment institutions is limited to acquiring payment instruments.

This makes merchant acquiring the central regulatory concept for many PayFac structures.

But acquiring is not always the only permission required.

The CBRT’s own Business Models Guide states that the virtual POS business model examined in the Guide requires permissions under Article 12(1)(a), Article 12(1)(b) and Article 12(1)(c), with paragraph (c) limited to payment instrument acquiring.

Consequently, a sophisticated PayFac project in Türkiye should begin with a complete regulatory analysis of the transaction architecture rather than simply searching for a “PayFac licence.”

1. What Is a Payment Facilitator?

A Payment Facilitator, commonly abbreviated as PayFac, is generally a business that helps merchants access payment acceptance infrastructure.

Instead of each small merchant negotiating and technically integrating separately with an acquiring bank or payment provider, the PayFac provides a unified commercial and technical relationship.

Depending on the model, a PayFac may:

• onboard merchants;
• provide checkout infrastructure;
• supply virtual POS functionality;
• connect to acquiring banks;
• route card transactions;
• monitor fraud;
• reconcile payments;
• calculate commissions;
• manage merchant reporting;
• facilitate settlement.

The model is attractive to smaller merchants because it can reduce the time and technical complexity required to begin accepting payments.

From the PayFac’s perspective, the model can also create significant scale.

A single fintech platform may support thousands of merchants through one technology stack.

However, this aggregation function is exactly why PayFac models attract financial regulation.

2. Turkey Does Not Have a Separate PayFac Licence

The current Turkish payment-services framework identifies regulated services by reference to Article 12 of Law No. 6493.

The CBRT’s public registers identify authorisations by the statutory categories:

• payment account services;
• money transfers;
• issuing/acquiring payment instruments;
• money remittance;
• telecommunications-related payment services;
• bill-payment services;
• Payment Initiation Services;
• Account Information Services.

There is no separate regulatory category titled “PayFac.”

Therefore, “Payment Facilitator” should be treated primarily as a commercial business-model description, not as the name of a Turkish regulatory authorisation.

The PayFac’s actual functions must be mapped against the regulated payment services.

3. Merchant Acquiring Is Usually the Core PayFac Activity

For most merchant-facing PayFac structures, the most important regulated service is acquiring payment instruments.

The Payment Services Regulation defines acquiring as a service that includes an agreement with the merchant and is provided so that the relevant payment transaction using a payment instrument ultimately results in the transfer of funds to the merchant.

This definition captures the central commercial function of many PayFacs.

A company is moving strongly toward regulated acquiring where it:

1. enters into the payment-services relationship with merchants;
2. enables those merchants to accept payment instruments;
3. accepts or processes relevant payment transactions;
4. participates in the structure through which the merchant receives settlement.

The fact that another bank provides part of the underlying card infrastructure does not automatically change that conclusion.

4. The Merchant Contract Is One of the Most Important Tests

The legal relationship with the merchant is a powerful indicator of regulatory status.

Consider two models.

Model A: PayFac as Merchant Acquirer

PayFac A contracts directly with Merchant X.

The agreement states that PayFac A will enable Merchant X to accept card payments.

PayFac A controls merchant onboarding, payment acceptance and settlement arrangements.

This model strongly resembles regulated merchant acquiring.

Model B: Pure Technology Provider

Technology Company B provides checkout software to Payment Institution C.

Merchant X signs its regulated acquiring agreement directly with Payment Institution C.

Technology Company B only provides:

• API technology;
• transaction-routing software;
• tokenisation;
• fraud tools.

Technology Company B never becomes the payment service provider and never owns transferred funds.

This second model may potentially remain within the technical-services perimeter.

The technical user experience can appear similar.

The regulatory position can be fundamentally different.

5. Can a PayFac Operate as a Pure Technology Provider?

Potentially, yes.

Law No. 6493 excludes certain technical services supporting payment transactions from regulated payment services.

The exclusion covers functions such as:

• data processing;
• data storage;
• security;
• confidentiality;
• authentication;
• information technology;
• communication networks;
• supply and maintenance of tools used for payment services,

where the technical service provider does not become the owner of the funds being transferred at any time. The CBRT’s Business Models Guide expressly describes this technical-service-provider exclusion.

Therefore, a fintech may potentially provide PayFac-like technology without itself becoming a licensed payment institution.

But this requires genuine separation.

Calling the company a “technology provider” in the contract is not enough.

6. When Does the Technical Provider Become a Regulated PayFac?

Several factors increase the risk that a purported technical provider is actually supplying regulated payment services.

These include:

• signing merchant payment contracts in its own name;
• deciding which merchants may accept payments;
• receiving merchant funds;
• controlling settlement timing;
• independently deducting charges from settlement;
• maintaining merchant payment accounts;
• accepting legal responsibility for payment execution;
• presenting itself as the merchant’s payment provider.

The regulatory analysis should therefore focus on substance over branding.

A fintech is not outside payment regulation merely because an acquiring bank operates somewhere in the background.

7. Does Using an Acquiring Bank’s Infrastructure Eliminate the Need for a PayFac Licence?

No.

This is one of the most important rules for structuring PayFac models in Türkiye.

The current Payment Services Regulation expressly recognises situations where one payment service provider provides merchant services while using payment infrastructure supplied by another payment service provider.

Where this happens, the merchant-facing provider must communicate specified merchant information to the infrastructure provider within ten business days.

Therefore:

“We use Bank X’s virtual POS infrastructure”

does not automatically mean:

“We do not provide regulated payment services.”

Turkish law expressly anticipates that one licensed PSP can use another PSP’s infrastructure.

The correct question remains:

Who legally provides the acquiring service to the merchant?

8. A Turkish PayFac Can Use an Upstream PSP

This is commercially important because a PayFac does not necessarily need to build every element of the acquiring infrastructure internally.

A possible model is:

Merchant → Turkish PayFac/Payment Institution → Bank or upstream PSP infrastructure

The PayFac may own the merchant relationship while the upstream provider supplies parts of the:

• POS infrastructure;
• processing;
• card connectivity;
• settlement infrastructure.

The merchant-facing payment institution nevertheless remains responsible for its own regulated activities.

Outsourcing infrastructure and outsourcing the licence are not the same thing.

9. Merchant Information Must Be Shared With the Upstream Provider

Where another payment service provider’s infrastructure is used, Article 10 of the Payment Services Regulation requires the PSP dealing with the merchant to provide specified information to the infrastructure provider within ten business days.

This includes the merchant’s:

• merchant code;
• applicable tax, Turkish identity or foreign identity number;
• name.

The upstream PSP cannot demand unrelated merchant information except where permitted by the Regulation or other applicable legislation.

This rule provides an important legal basis for Turkish PayFac/upstream-acquirer structures.

10. The Upstream Acquirer Cannot Use Merchant Information to Poach Customers

The Regulation contains an important competitive protection.

Information provided to the infrastructure provider may be used for matters including:

• risk assessment;
• regulatory review;
• technical activation;
• necessary technical identification.

However, the data cannot be used for purposes unrelated to the reason for which it was obtained, expressly including marketing and customer acquisition.

For fintech PayFacs partnering with large banks, this provision is commercially significant.

A bank providing the backend payment infrastructure cannot simply treat the PayFac’s merchant portfolio as its own sales database.

11. The Upstream PSP Can Still Reject Risky Merchants

The upstream infrastructure provider retains risk-management rights.

Following its risk assessment, it may ask the merchant-facing payment service provider not to provide services to a particular merchant.

However, it cannot arbitrarily prevent the front-end PSP from providing payment services through its infrastructure.

This creates a balance between:

• legitimate AML/fraud/credit risk management;
• competitive independence of the merchant-facing PayFac.

The infrastructure agreement should reflect this structure.

12. Virtual POS PayFac Models Require Particular Care

Many PayFac models operate through virtual POS infrastructure.

The CBRT has provided direct regulatory guidance on virtual POS.

The CBRT’s Business Models Guide explains that payment and electronic money institutions may establish relationships with different banks and integrate through APIs so that several banks’ POS services can effectively be offered to merchants through one software infrastructure.

This structure closely resembles many modern payment aggregator and PayFac businesses.

But the legal conclusion is important.

For the virtual POS model examined by the CBRT, the institution needs permission under:

• Article 12(1)(a);
• Article 12(1)(b); and
• Article 12(1)(c), limited to payment instrument acquiring.

Accordingly, a PayFac should not necessarily assume that acquiring authorisation alone is sufficient.

13. Why Can PayFacs Need Articles 12(a) and 12(b)?

Because the regulatory treatment depends on the fund flow.

The virtual POS model examined by the CBRT involves funds being received through payment infrastructure and subsequently transferred through the payment institution to merchants.

The CBRT therefore considers the structure to involve not only acquiring but also payment-account and money-transfer functionality in the model described in its Guide.

This demonstrates one of the central principles of Turkish payment regulation:

One PayFac product may require several Article 12 permissions.

The correct licence scope must be built around the actual transaction architecture.

14. Physical POS Can Produce the Same Result

The CBRT’s Business Models Guide reaches a similar conclusion for the physical POS model it examines.

For that structure, the Guide identifies required authorisation under Article 12(1)(a), Article 12(1)(b) and Article 12(1)(c), with paragraph (c) limited to acquiring.

The Guide also expressly notes that assessments under Law No. 5464 on Bank Cards and Credit Cards and the BRSA framework remain relevant to physical and virtual POS business models.

A PayFac dealing with card acceptance should therefore not look only at Law No. 6493.

15. The Merchant Registration System Is Critical for Turkish PayFacs

Türkiye operates a central Merchant Registration System, or İşyeri Kayıt Sistemi (“İKS”).

The system was developed to facilitate payment processes and combat:

• fraud;
• malicious payment activity.

The system is operated through BKM. The CBRT confirms that participation by banks and non-bank payment service providers offering merchant payment services has been completed and that new providers are integrated through BKM.

A Turkish PayFac cannot therefore build a merchant network completely outside the formal merchant-registration infrastructure.

16. Every Merchant Must Remain Identifiable

Under Article 9 of the current Payment Services Regulation, a merchant accepting regulated payment methods receives a merchant-specific code issued by BKM.

The merchant code is linked at minimum with information such as:

• address;
• Turkish identity number or tax identification number;
• equivalent information for overseas merchants.

A merchant cannot have more than one merchant code within this framework, and the PSP signing the merchant agreement must take necessary measures to verify the relevant information.

This creates a major implication for PayFacs:

A “sub-merchant” cannot simply disappear behind a master PayFac account.

The underlying merchant must remain identifiable within the Turkish payment infrastructure.

17. “Sub-Merchant” Is a Commercial Concept, Not a Regulatory Escape Route

International PayFac terminology often refers to merchants as sub-merchants.

This terminology can still be useful commercially.

However, describing a merchant as a sub-merchant does not remove the regulatory requirements relating to:

• merchant identification;
• merchant code;
• merchant due diligence;
• transaction monitoring.

The Turkish framework focuses on the actual merchant selling the goods or services.

A PayFac should therefore be capable of identifying every underlying merchant in its system.

18. PayFac Merchant Onboarding Must Include İKS Checks

Before beginning to provide merchant payment services, the PSP must determine whether the merchant is registered in the Merchant Registration System.

Where it is not registered, registration must be completed.

Where the merchant is already registered, the PSP must check whether a negative record exists.

Where legislation requires that services cannot be provided because of that record, the institution must comply with the prohibition.

Where no automatic prohibition exists, the negative record must still be evaluated through the PSP’s risk-management framework.

This makes merchant onboarding a regulated compliance function.

19. PayFacs Must Re-Screen Existing Merchants

The obligation does not end after initial approval.

The current Payment Services Regulation requires payment service providers to check the Merchant Registration System for negative records concerning existing merchants regularly and at least:

once per year.

High-risk merchants may require more frequent internal review.

A scalable PayFac should therefore automate merchant monitoring rather than relying only on manual onboarding files.

20. Merchant Agreements Must Address İKS

Before execution of the merchant framework agreement, the merchant must be clearly informed about information sharing and inquiries under the Merchant Registration System.

The PSP must obtain the merchant’s approval and ensure that the required matters concerning that approval are included in the framework agreement.

A foreign PayFac entering Türkiye should therefore not simply translate its standard US or European merchant agreement.

Turkish regulatory provisions need to be incorporated.

21. Merchant-Level Transaction Monitoring Is Mandatory

The current Regulation requires the PSP to record and monitor transactions so that they can be followed merchant by merchant.

This has important technical consequences.

The PayFac should be able to determine:

• which merchant generated each transaction;
• transaction amount;
• payment channel;
• refunds;
• chargebacks;
• settlement;
• suspicious behaviour.

The system architecture should never make it impossible to determine the real merchant behind a payment.

22. Can a Turkish PayFac Maintain a Single Master Merchant Account?

A pure “master merchant” structure in which all transactions are recorded only under the PayFac and the real merchant becomes invisible is highly problematic.

Turkish regulation requires merchant-specific coding and monitoring.

A PayFac may commercially aggregate merchant access to payment infrastructure, but regulatory traceability should continue to the individual merchant level.

Accordingly:

aggregation is permitted; anonymity of the underlying merchant is not the objective of the Turkish model.

23. MASAK Regulation Makes Merchant Onboarding Even More Important

PayFacs operating as payment institutions are subject to Türkiye’s AML framework administered by MASAK.

Electronic money institutions and most payment institutions are required to maintain a formal compliance programme.

The principal exceptions for payment institutions concern institutions exclusively providing:

• bill-payment intermediation;
• Payment Initiation Services;
• Account Information Services.

Merchant acquiring is not among those exceptions.

A licensed PayFac therefore generally needs an institutional AML programme.

24. MASAK Has Specific Enhanced Measures for Merchant Acquiring

The importance of merchant risk has increased further under the current MASAK framework.

MASAK specifically requires enhanced measures for terminal payment services provided under:

• Article 12(1)(a);
• Article 12(1)(b);
• the acquiring element of Article 12(1)(c).

For relationships with merchants and other transactions requiring identification, at least the specified enhanced measures under the Compliance Programme Regulation must be applied. The provider must also regularly check whether payment terminals are used in accordance with the purpose of the business relationship and whether they are improperly made available to other persons. Where violations are identified, necessary measures may include termination of the relationship.

This is particularly important for PayFacs operating large merchant networks.

25. Merchant KYC Must Go Beyond Company Registration Documents

A PayFac should understand the real commercial activity of every merchant.

A robust merchant KYC programme should normally consider:

• legal identity;
• trade registry information;
• tax identification;
• authorised representatives;
• beneficial owners;
• business activity;
• website/application;
• expected transaction volume;
• geographic markets;
• source of settlement activity.

The objective is not simply to prove that the merchant company exists.

The PayFac should understand why the merchant needs the payment service and whether transaction activity is consistent with that purpose.

26. Transaction Laundering Is a Major PayFac Risk

Payment facilitators are particularly exposed to transaction laundering.

A merchant may claim to sell legitimate consumer products but actually process transactions on behalf of:

• another merchant;
• prohibited businesses;
• illegal gambling;
• fraudulent investment schemes;
• unlicensed financial services.

A PayFac should therefore monitor factors such as:

• sudden transaction growth;
• unusual average transaction size;
• excessive refunds;
• merchant-category inconsistency;
• website changes;
• transaction geography.

Merchant due diligence should be continuous.

27. Suspicious Transaction Reporting

Payment institutions are obliged entities under Turkish AML legislation.

Where transaction activity creates reasonable suspicion concerning:

• money laundering;
• terrorism financing;
• other relevant financial crime,

the institution must follow MASAK suspicious transaction reporting procedures.

This means PayFac fraud systems should communicate with the AML compliance function.

A transaction may be both:

a fraud event, and

an AML event.

The two should not be managed in completely isolated operational systems.

28. Can an Unlicensed Marketplace Use a PayFac Model?

Potentially, but the structure must be analysed carefully.

A marketplace that simply connects buyers and sellers is not automatically a payment institution.

Law No. 6493 also contains a commercial-agent exclusion for certain transactions where a genuine commercial representative is authorised to negotiate or conclude the sale or purchase of goods or services on behalf of the payer or payee.

However, a marketplace should not assume that inserting “commercial agent” into the contract eliminates licensing.

Where the practical function becomes:

• merchant onboarding;
• payment acceptance;
• settlement to unrelated sellers,

the model can increasingly resemble merchant acquiring.

The flow of money and contractual authority must be analysed together.

29. A PayFac Can Partner With a Licensed Turkish Payment Institution

A foreign fintech or Turkish technology startup may decide not to become the regulated merchant acquirer itself.

Instead, it may provide:

• technology;
• merchant interface;
• analytics;
• reconciliation software,

while a licensed Turkish PSP provides acquiring.

This can be a viable model provided that the role allocation is real.

The licensed PSP should remain responsible for the regulated payment service.

The technology company should not simultaneously create the impression that it independently provides regulated acquiring while attempting to rely on the technical-provider exemption.

30. Branding Can Change Regulatory Risk

The customer and merchant experience matters.

Suppose the contract identifies Payment Institution B as the licensed provider.

But every screen, invoice and communication says:

“PayFac A processes and holds all your payments.”

That inconsistency creates risk.

A technical provider should avoid holding itself out as the independent regulated institution.

Conversely, where the PayFac is itself licensed, customer-facing materials should accurately identify the licence and service provider.

Legal documentation, money flows and branding should tell the same regulatory story.

31. Does a PayFac Need to Be an A.Ş.?

Where the PayFac itself requires payment institution authorisation, the corporate requirements applicable to payment institutions apply.

The licence framework requires an appropriate Turkish joint-stock company structure together with qualified:

• shareholders;
• governance;
• management;
• technical infrastructure;
• internal controls.

The current Payment Services Regulation specifies an application-stage paid-in capital floor of TRY 2 million for ordinary payment services.

However, this amount should not be confused with the far higher ongoing prudential requirement.

32. 2026 PayFac Own-Funds Requirement: TRY 40 Million

As of 30 June 2026, the minimum own-funds requirement applicable to the general payment institution category is:

TRY 40 million.

The same 2026 CBRT Communiqué sets:

• TRY 20 million for the specified bill-payment category;
• TRY 40 million for other payment institutions excluding pure account-information providers;
• TRY 105 million for electronic money institutions.

A PayFac operating as a merchant-acquiring payment institution would generally fall within the ordinary payment institution category rather than the special bill-payment or pure AISP categories.

Therefore, founders should build the financial model around the current TRY 40 million minimum own-funds level, subject to the detailed calculation rules and any higher amount generated under the prudential framework.

33. Paid-In Capital and Own Funds Are Different

This distinction deserves emphasis.

The application-stage paid-in capital threshold and the ongoing own-funds requirement are different concepts.

A company cannot assume:

“We incorporated with TRY 2 million, therefore we satisfy the financial requirements.”

The relevant ongoing minimum for an ordinary PayFac-type payment institution is now substantially higher.

The company must also fund:

• technology;
• regulatory staff;
• cybersecurity;
• merchant support;
• AML;
• legal costs;
• fraud losses;
• working capital.

The economic cost of operating a PayFac is therefore considerably higher than the nominal establishment capital.

34. Payment Institution Licensing Process

A PayFac that requires payment-institution status must obtain CBRT authorisation before beginning regulated operations.

The current Payment Services Regulation establishes an application process including:

• initial trade-name/application stage;
• intelligence review;
• final approval.

The application requires detailed information concerning the company’s:

• business plan;
• organisation;
• shareholders;
• management;
• financial position;
• fraud-data methodology;
• information systems.

The current Regulation also provides for a TRY 500,000 application fee at the initial stage.

The licensing process should therefore begin only after the PayFac’s operating model has been fully designed.

35. Does a PayFac Need an Electronic Money Licence?

Not automatically.

Merchant acquiring and electronic money issuance are separate regulated activities.

A PayFac that merely enables merchants to accept card transactions does not necessarily issue electronic money.

However, the position changes if the PayFac introduces a customer or merchant wallet containing stored monetary value.

Where monetary value:

• is issued against funds;
• is stored electronically;
• can be used for payment;
• is accepted by persons other than the issuer,

electronic money authorisation may become relevant.

This would materially affect capital and regulatory requirements.

A PayFac should therefore obtain legal review before adding reusable wallet balances.

36. Settlement and Safeguarding

The flow of merchant settlement funds is a central part of PayFac architecture.

The institution should distinguish between:

• its own earned commission;
• amounts that must be transferred to merchants;
• other payment-service-user funds.

The PayFac should not treat merchant settlement balances as unrestricted company working capital.

Settlement architecture should be consistent with the safeguarding requirements imposed on payment institutions.

Contracts, accounting and bank-account structures should reflect the legal character of the funds.

37. Rolling Reserves and Merchant Holdbacks

PayFacs commonly use mechanisms such as:

• rolling reserves;
• settlement delays;
• chargeback reserves;
• security deposits.

These can be legitimate risk-management tools.

However, the merchant agreement should clearly explain:

• when a reserve can be created;
• how much may be retained;
• how long it lasts;
• when it is released;
• when it can be applied against losses.

A clause allowing the PayFac to hold all merchant funds indefinitely at its sole discretion creates significant contractual and regulatory risk.

Risk controls should be objective and documented.

38. Chargeback Management

Card-based PayFacs should maintain a structured chargeback process.

The merchant agreement should address:

• chargeback notices;
• evidence requirements;
• merchant response periods;
• debit rights;
• dispute handling;
• reserve mechanisms.

The PayFac’s system should also monitor merchants whose chargeback ratios exceed expected levels.

An unusually high chargeback rate can indicate:

• poor merchant quality;
• fraud;
• transaction laundering;
• consumer-law problems.

39. Information Systems and Cybersecurity

A licensed PayFac is a technology-intensive regulated financial institution.

The CBRT’s current payment-services framework includes the dedicated information systems and data-sharing Communiqué applicable to payment and electronic money institutions.

The PayFac should therefore maintain appropriate controls concerning:

• access management;
• authentication;
• encryption;
• vulnerability management;
• penetration testing;
• transaction logging;
• fraud monitoring;
• incident response;
• disaster recovery;
• outsourcing.

A payment facilitator with thousands of merchants can create systemic cyber risk if its API or merchant dashboard is compromised.

40. KVKK and Merchant Data

PayFacs process large volumes of personal data concerning:

• individual merchants;
• company representatives;
• beneficial owners;
• customers;
• transactions;
• fraud investigations.

The Turkish Personal Data Protection Authority published a dedicated Good Practices Guide for the Payment and Electronic Money Sector in July 2026 together with TÖDEB.

The Guide covers matters including:

• categories of personal data;
• controller and processor roles;
• processing legal grounds;
• transfers;
• data security;
• data-controller obligations.

PayFacs should therefore prepare a specific payment-sector KVKK compliance programme rather than relying solely on a generic website privacy policy.

41. Foreign Cloud and SaaS Providers

International PayFac platforms frequently use global:

• cloud infrastructure;
• fraud engines;
• CRM software;
• analytics tools;
• customer-support systems.

These services may create international personal data transfers under KVKK.

At the same time, payment institutions are subject to sector-specific CBRT information systems requirements.

Therefore, two separate questions must be answered:

Is the international transfer lawful under KVKK?

Does the payment-sector regulatory framework permit the relevant infrastructure architecture?

A valid KVKK transfer mechanism does not automatically override CBRT financial-sector restrictions.

42. Can a Foreign PayFac Operate Directly in Turkey?

A foreign PayFac licence does not automatically passport into Türkiye.

Türkiye does not operate a general payment-services passport that permits an overseas PayFac to contract Turkish merchants under its foreign licence without separate Turkish regulatory analysis.

A foreign PayFac considering Türkiye may instead examine:

Establishing a Turkish Licensed Payment Institution

This provides direct control but requires licensing, capital and local compliance.

Acquiring an Existing Licensed Institution

This can provide faster market access but requires regulatory M&A due diligence and potentially CBRT share-transfer approval.

Partnering With a Turkish PSP

The foreign company remains genuinely technical while the Turkish licensed PSP provides regulated acquiring.

The appropriate solution depends on the intended merchant relationship and money flow.

43. Can PayFac Models Be Used for Cross-Border Merchants?

Potentially, but cross-border structures involve an additional regulatory layer.

Turkish payment service providers may cooperate with foreign legal entities under specific conditions.

The CBRT currently publishes a list of payment service providers authorised under Article 19(7) of the Payment Services Regulation to provide services together with foreign legal entities.

A global PayFac structure involving foreign payment companies should therefore not assume that cross-border cooperation can be implemented without CBRT analysis.

44. PayFac M&A Due Diligence

An investor acquiring a Turkish PayFac or payment aggregator should conduct specialised regulatory due diligence.

The review should establish:

Licence Scope

Does the company hold the permissions actually required by its transaction model?

Acquiring

Does it hold Article 12(1)(c) acquiring permission?

Virtual POS

Does its model also require Article 12(a) and (b) permissions?

Merchant Contracts

Which entity legally contracts with merchants?

İKS

Are merchants properly coded and screened?

Sub-Merchants

Can every underlying merchant be identified?

Upstream Infrastructure

Are relationships with banks and other PSPs properly structured?

Merchant AML

Are enhanced acquiring measures actually implemented?

Regulatory Capital

Is the current TRY 40 million minimum satisfied?

Customer Funds

Is settlement architecture compliant?

Cybersecurity

Have material incidents or penetration-test findings occurred?

KVKK

Is merchant/customer data processed lawfully?

These findings can materially affect acquisition value.

45. The Most Common PayFac Regulatory Mistakes

Mistake 1: “PayFac Is Not Mentioned in the Law, So No Licence Is Required”

Incorrect.

The model is mapped to the payment services actually performed.

Mistake 2: “The Bank Has the Licence, So We Do Not Need One”

Not necessarily.

The Regulation expressly permits one PSP to use another PSP’s infrastructure.

Mistake 3: “All Our Merchants Are Sub-Merchants, So We Only Need One Merchant Record”

Risky.

Türkiye requires merchant-specific codes and merchant-level transaction monitoring.

Mistake 4: “We Are Only a Payment Gateway”

That depends on the facts.

A genuine technical provider may qualify for the exclusion, but a company contracting merchants and controlling acquiring is different.

Mistake 5: “Article 12(c) Alone Covers Every Virtual POS Model”

Not necessarily.

The CBRT Business Models Guide identifies (a), (b) and acquiring under (c) for the virtual POS model it examines.

Mistake 6: “Merchant KYC Is Finished When the Contract Is Signed”

No.

İKS negative-record checks must be repeated at least annually, and MASAK requires continuing controls.

Mistake 7: “TRY 2 Million Is the Capital Requirement”

That confuses the application-stage paid-in capital threshold with the current ongoing own-funds requirement.

From 30 June 2026, the ordinary payment institution minimum own funds are TRY 40 million.

Practical PayFac Compliance Checklist for Turkey

Before launching a Turkish PayFac model, founders should answer the following questions.

Regulatory Classification

Who legally provides merchant acquiring?

Merchant Agreement

Does the PayFac or another PSP sign the merchant contract?

Funds

Does the PayFac receive or control merchant settlement funds?

Licence Scope

Are Articles 12(a), (b) and/or acquiring under (c) required?

Upstream PSP

Is another bank/payment institution infrastructure being used?

Merchant Registration

Does every merchant have the required İKS merchant code?

Merchant Screening

Are negative records checked before onboarding?

Ongoing Monitoring

Are İKS checks repeated at least annually?

Sub-Merchant Visibility

Can every underlying merchant be individually identified?

MASAK

Are acquiring-specific enhanced measures applied?

Transaction Monitoring

Can suspicious merchant activity and transaction laundering be detected?

Capital

Can the company continuously maintain the required TRY 40 million minimum own funds?

Settlement

Are merchant funds legally separated and properly managed?

Cybersecurity

Are API, POS and merchant-dashboard systems sufficiently protected?

KVKK

Is merchant and customer data processing properly documented?

Cross-Border Operations

Have foreign PSP cooperation and international data arrangements been separately analysed?

Frequently Asked Questions About Payment Facilitators in Turkey

Are PayFac models legal in Turkey?

Yes, properly structured PayFac models can operate legally. However, Turkish law does not create a standalone PayFac licence. The business must be classified under the regulated payment services it actually performs.

Does a PayFac need a payment institution licence?

Often yes where it contracts with merchants and provides regulated acquiring/payment services. A purely technical PayFac-type platform may potentially remain outside licensing where the statutory technical-service conditions are genuinely satisfied.

What is the main licence for a PayFac?

For merchant-facing models, payment instrument acquiring under Article 12(1)(c) is generally central. The CBRT’s current payment-institution register confirms that Article 12(c) authorisation for payment institutions is limited to acquiring.

Does a virtual POS PayFac need only Article 12(c)?

Not necessarily. The CBRT’s Business Models Guide states that the virtual POS model examined requires Article 12(a), Article 12(b) and acquiring under Article 12(c).

Can a PayFac use a bank’s virtual POS infrastructure?

Yes, subject to proper structuring. The Payment Services Regulation expressly regulates situations where one PSP provides merchant services using another PSP’s infrastructure.

Does using bank infrastructure remove the PayFac’s licensing obligation?

No, not automatically. Licensing depends on which entity actually provides the regulated service to merchants.

Are sub-merchants permitted?

A PayFac may commercially work with sub-merchants, but the underlying merchants must remain identifiable and subject to the merchant-registration and monitoring framework.

What is the Merchant Registration System?

İKS is the central merchant-registration framework operated through BKM. It gives merchants specific merchant codes and supports fraud prevention and merchant monitoring.

How frequently must merchant records be reviewed?

Relevant negative records must be checked periodically and at least once a year.

Are PayFacs subject to MASAK?

A merchant-acquiring payment institution will generally fall within MASAK’s formal compliance-programme regime. Merchant acquiring is not among the limited payment-institution exceptions.

Are there special AML requirements for merchant acquiring?

Yes. The current MASAK framework expressly imposes enhanced measures on terminal services involving Article 12(a), (b) and payment instrument acquiring under Article 12(c).

What is the minimum own-funds requirement in 2026?

From 30 June 2026, the minimum for ordinary payment institutions is TRY 40 million, excluding the separately regulated categories identified by the CBRT.

Does a foreign PayFac licence work automatically in Turkey?

No general passporting system makes a foreign PayFac or payment-institution licence automatically valid for Turkish regulated payment services.

Does KVKK apply to PayFacs?

Yes. PayFacs process merchant, beneficial-owner, consumer, transaction and fraud data. The Personal Data Protection Authority published dedicated payment/e-money sector guidance in July 2026.

Conclusion: How to Operate a PayFac Model Legally in Turkey

The answer to the question “Can Payment Facilitator models operate legally in Turkey?” is yes.

But they must be adapted to the Turkish regulatory architecture.

The first and most important point is that Türkiye does not recognise “Payment Facilitator” as a standalone financial licence.

Instead, the CBRT examines the actual payment services performed.

For most merchant-facing PayFac models, merchant acquiring will be one of the central regulated activities.

The current CBRT register confirms that the Article 12(1)(c) authorisation held by payment institutions is limited to payment instrument acquiring.

But the full licence scope can be broader.

For the virtual POS model expressly analysed in the CBRT’s Business Models Guide, the regulator identifies Article 12(1)(a), Article 12(1)(b) and acquiring under Article 12(1)(c) as required permissions.

This is why the starting point for every PayFac legal analysis should be a complete transaction diagram.

The diagram should identify:

customer → payment instrument → issuing PSP → upstream infrastructure → PayFac → merchant

and answer:

Who contracts with the merchant?

Who receives the payment instruction?

Who controls settlement?

Whose payment account is used?

Who bears legal responsibility for execution?

Once these questions are answered, the required Article 12 permissions can be assessed properly.

The technical-service-provider exclusion remains important.

A company that genuinely supplies only payment technology, security, data processing or communications infrastructure and never owns the transferred funds may remain outside regulated payment services.

This creates a legitimate route for international PayFac technology companies that do not wish to become regulated Turkish financial institutions.

They may provide the technology while a licensed Turkish PSP supplies the actual merchant acquiring.

But the separation must be genuine.

A company cannot simultaneously:

• contract with merchants as the payment provider;
• control settlement;
• present itself as the merchant’s acquirer;

and then argue that it is merely a software company because a bank provides the backend POS.

Turkish regulation expressly recognises a structure where one regulated payment service provider uses another PSP’s infrastructure.

Therefore, using an upstream bank does not itself determine licensing.

For a licensed PayFac, merchant compliance is one of the most important operational workstreams.

Türkiye’s Merchant Registration System requires merchant-specific identification.

The PSP signing the merchant agreement must verify relevant merchant information, and payment services must use the appropriate merchant code.

The institution must also:

• check the merchant before onboarding;
• assess negative records;
• repeat the review at least annually;
• monitor transactions merchant by merchant.

This means the classic international “sub-merchant” model requires Turkish localisation.

The PayFac can aggregate technical and commercial access, but the regulatory system still expects visibility into the underlying merchant.

From an AML perspective, merchant acquiring is now particularly sensitive.

MASAK’s current Compliance Programme Regulation expressly imposes enhanced measures on relationships involving terminal services under Article 12(a), Article 12(b) and the acquiring component of Article 12(c).

A serious PayFac compliance programme should therefore include:

merchant KYC → beneficial ownership → business activity verification → risk classification → İKS review → transaction monitoring → periodic review → suspicious transaction escalation.

Financial resources are another major barrier to entry.

The ordinary payment institution minimum own-funds requirement increased to TRY 40 million from 30 June 2026.

This is separate from the lower application-stage paid-in capital threshold contained in the Payment Services Regulation.

A PayFac should therefore be funded as a regulated financial institution, not merely as a software startup.

Data protection and cybersecurity should likewise be included in the architecture from the beginning.

The July 2026 KVKK/TÖDEB good-practices work for the payment and electronic money sector reflects the increasingly sector-specific expectations concerning:

• controller and processor roles;
• legal processing grounds;
• personal data transfers;
• information security.

For global PayFacs using foreign cloud, fraud, CRM or analytics infrastructure, this requires a separate cross-border data-transfer analysis together with the applicable CBRT information systems rules.

Finally, regulatory enforcement should be taken seriously.

The CBRT announced in January 2026 that its 2025 supervisory activities resulted in 7 licence cancellations, 14 temporary suspensions and administrative fines totalling TRY 373,243,560.30 across 72 institutions. It also referred 331 files involving suspected unauthorised payment activity to prosecutors and/or courts.

This enforcement record demonstrates the risk of adopting a foreign PayFac structure first and asking Turkish regulatory questions later.

The better strategy is the opposite.

A Turkish PayFac project should generally proceed through the following sequence:

map merchant and money flows → determine whether the company is a technical provider or regulated PSP → identify Article 12 permissions → determine acquiring/virtual POS requirements → structure upstream PSP relationships → establish merchant registration and AML onboarding → satisfy capital requirements → implement KVKK and cybersecurity → obtain CBRT authorisation → launch merchant services.

For foreign Payment Facilitators entering Türkiye, the strategic choice will usually be between:

obtaining a Turkish payment institution licence, acquiring an existing licensed institution, or remaining a genuine technology provider while partnering with an authorised Turkish PSP.

Which route is appropriate depends primarily on how much control the foreign fintech wants over:

• merchant contracts;
• settlement;
• pricing;
• onboarding;
• customer experience.

The central legal principle can therefore be summarised as follows:

PayFac models can operate legally in Türkiye, but “PayFac” is not a regulatory shortcut. Once the fintech becomes the merchant-facing provider of payment acceptance and settlement, it must be analysed as a regulated payment service provider under Turkish law.

Legal Disclaimer: This publication provides general information concerning Payment Facilitator, PayFac, merchant acquiring, virtual POS and payment-institution regulation in Türkiye as of July 2026. It does not constitute legal, financial or regulatory advice. The classification of a PayFac depends on the exact merchant agreement, money flow, settlement process, payment accounts, upstream acquirer relationship, services and technological architecture. The CBRT’s Business Models Guide itself notes that regulatory assessment may differ according to the specific characteristics or combination of a proposed business model. Each PayFac structure should therefore be individually reviewed before Turkish merchant onboarding begins.