Introduction: Are Payment Aggregators Regulated in Turkey?

Payment aggregation has become a central infrastructure model in modern e-commerce.

Instead of every merchant independently negotiating and technically integrating with multiple banks and payment service providers, a payment aggregator may provide merchants with a unified payment acceptance infrastructure.

Commercially, the model can include:

• virtual POS services;
• card payment acceptance;
• checkout infrastructure;
• transaction routing;
• merchant onboarding;
• reconciliation;
• settlement reporting;
• fraud monitoring;
• access to several payment methods through one integration.

However, the expression “payment aggregator” is not itself a standalone licence category under Turkish payment legislation.

Turkish law follows a functional approach.

The regulatory analysis therefore does not begin by asking whether a company describes itself as a “payment aggregator,” “payment facilitator,” “PayFac,” “payment orchestration platform” or “payment gateway.”

Instead, the question is:

What does the company actually do in the payment transaction?

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”) is the principal regulator and supervisor of payment institutions and electronic money institutions. The CBRT’s current public register expressly identifies Article 12(1)(c) authorisation for payment institutions as limited to “acquiring payment instruments.”

Accordingly, a business commonly described internationally as a payment aggregator will often fall within the Turkish regulatory concept of payment instrument acquiring where it contracts with merchants, accepts and processes payment transactions and provides a service that ultimately results in funds being transferred to those merchants.

However, not every payment-related technology company requires this licence.

A pure technical payment gateway that provides data processing, security or routing infrastructure without becoming the provider of the regulated payment service or owner of transferred funds may potentially fall within the statutory technical-service-provider exclusion.

There are therefore at least three fundamentally different models:

licensed payment aggregator / merchant acquirer;

licensed payment institution using another payment service provider’s infrastructure;

and

unlicensed technical gateway supporting a licensed payment provider.

Confusing these models can create serious regulatory exposure.

This guide explains payment aggregator regulation in Turkey as of July 2026, including licensing, merchant contracts, infrastructure arrangements, merchant onboarding, regulatory capital, AML/KYC, data protection and cybersecurity requirements.

1. What Is a Payment Aggregator?

A payment aggregator generally provides a commercial layer between merchants and the underlying payment infrastructure.

Instead of a merchant establishing separate technical relationships with several financial institutions, the aggregator can allow the merchant to accept payments through one commercial and technological integration.

Depending on the model, the aggregator may:

• contract directly with merchants;
• provide virtual POS infrastructure;
• transmit authorisation requests;
• process card payments;
• arrange settlement to merchants;
• reconcile transactions;
• deduct commissions;
• provide merchant dashboards;
• manage fraud risks.

The model is commercially attractive because a small or medium-sized merchant may gain access to payment acceptance without developing separate integrations with numerous providers.

But the legal consequences depend on which of these functions the aggregator assumes.

A company providing only software is fundamentally different from a company undertaking legal responsibility for merchant payment acceptance.

2. Turkey Does Not Have a Separate “Payment Aggregator Licence”

Turkish legislation does not create a licence called:

Payment Aggregator Licence

or

Payment Facilitator Licence.

Instead, businesses are classified according to the payment services defined in Article 12 of Law No. 6493.

The CBRT’s current public list of authorised payment institutions therefore presents licences according to the statutory Article 12 service categories rather than commercial descriptions such as PayFac or aggregator. The CBRT also expressly states that institutions authorised under Article 12(1)(c) are authorised only for acquiring payment instruments within that paragraph.

This is important for international fintech companies.

A PayFac model used in another jurisdiction cannot simply be imported into Türkiye under the same terminology.

The Turkish structure must be mapped against Law No. 6493.

3. Merchant Acquiring Is the Core Payment Aggregator Licence

For most consumer-to-merchant payment aggregation structures, the most relevant regulated activity is acquiring payment instruments.

The current Payment Services Regulation defines acquiring as a service:

• involving an agreement with the merchant;
• enabling a payment transaction using a payment instrument to be accepted and processed;
• resulting in funds being transferred to the merchant.

The CBRT’s Business Models Guide explains the concept in the same way: acquiring involves the payment service provider accepting and processing transactions so that the relevant payment instrument can be used at the merchant and funds are transferred to that merchant.

This definition closely resembles the commercial function of many payment aggregators.

Therefore, where a company:

1. contracts with the merchant;
2. enables the merchant to accept regulated payment methods;
3. processes those transactions; and
4. participates in the structure resulting in settlement to the merchant,

the model should be analysed primarily as merchant acquiring under Article 12(1)(c).

4. Contracting With the Merchant Is a Critical Regulatory Indicator

One of the strongest indicators of merchant acquiring is the contractual relationship.

The Regulation does not define acquiring merely as providing a POS terminal or API.

It specifically includes entering into an arrangement with the merchant.

This means contractual architecture matters.

Consider two models.

Model A — Licensed Aggregator

Aggregator A signs a payment services agreement directly with Merchant X.

Aggregator A promises to enable Merchant X to accept card payments.

Aggregator A processes transactions and is responsible for arranging settlement.

This strongly resembles regulated acquiring.

Model B — Technical Gateway

Technology Company B licenses payment-routing software to Bank C.

Merchant X’s payment services contract is directly with Bank C.

Technology Company B never undertakes payment obligations toward Merchant X and never owns the funds.

That structure may instead qualify as a technical-service-provider model.

The technology may look similar.

The legal role is different.

5. Payment Gateway vs Payment Aggregator

The distinction between a payment gateway and payment aggregator is therefore crucial.

A gateway may provide:

• API connectivity;
• encrypted transmission;
• transaction routing;
• authentication;
• data processing;
• tokenisation;
• fraud technology.

Law No. 6493 excludes qualifying technical service providers from the definition of payment services where they support payment activity through services such as data processing, storage, security, authentication, IT and communications infrastructure and do not become the owner of the transferred funds at any stage. The CBRT’s Business Models Guide expressly reiterates this exclusion.

Accordingly:

A payment gateway may potentially operate without a payment institution licence where it remains genuinely technical.

But a company cannot rely on the technical-provider exemption merely because it describes its service as software.

6. When Does a Payment Gateway Cross Into Regulated Acquiring?

A gateway model becomes more difficult to classify as purely technical where the company begins to:

• contract directly with merchants as the payment provider;
• determine settlement terms;
• receive merchant payment funds;
• control when merchant funds are released;
• provide merchant payment accounts;
• independently execute payment transactions;
• assume responsibility toward merchants for payment acceptance.

The greater the company’s control over the regulated payment transaction, the weaker the technical-service exemption becomes.

The central question is therefore not:

“Does the company use an API?”

Almost every modern payment institution does.

The better question is:

Who legally provides the payment service to the merchant?

7. Fund Ownership Is Particularly Important

The Article 12 technical-services exclusion requires that the technical provider never become the owner of transferred funds.

Accordingly, a regulatory analysis should map the exact flow:

Consumer → Issuing Bank/PSP → Aggregator/Acquirer → Merchant

Questions should include:

Where are funds legally held?

Does the aggregator receive them in its own operational account?

Are funds transferred through regulated safeguarding or settlement accounts?

Can the technology company redirect the transaction?

Can it delay settlement independently?

Does it deduct its own fees before payment to the merchant?

Not every technical movement of money necessarily means the company becomes the legal owner of the funds.

But the structure should be documented carefully.

8. A Licensed Payment Aggregator Can Use Another PSP’s Infrastructure

An important feature of Turkish regulation is that a payment service provider does not necessarily need to own every underlying technical infrastructure itself.

Article 10 of the current Payment Services Regulation expressly addresses situations in which one payment service provider offers merchant services while using infrastructure supplied by another payment service provider.

In that case, the payment service provider dealing with the merchant must provide the infrastructure provider with specified merchant information within ten business days, including the relevant merchant code, appropriate identification/tax information and merchant name.

This creates a legally significant structure for payment aggregation.

For example:

Payment Institution A → contracts with Merchant X

while

Bank or Payment Service Provider B → provides underlying payment acceptance infrastructure.

Payment Institution A remains the payment service provider vis-à-vis its merchant.

Provider B supplies infrastructure.

This is substantially different from an unlicensed technology company presenting itself as the merchant’s payment provider.

9. Infrastructure Use Does Not Eliminate the Aggregator’s Licence

This is one of the most common mistakes in payment aggregator structuring.

A startup may say:

“We use Bank X’s virtual POS infrastructure, so we do not need a payment licence.”

That conclusion does not necessarily follow.

The Payment Services Regulation expressly contemplates one payment service provider using another payment service provider’s infrastructure while providing services to merchants.

Therefore, the mere existence of an acquiring bank in the background does not remove the front-end provider’s regulatory status.

If the aggregator itself contracts with merchants and provides the regulated acquiring service, it may still need CBRT authorisation.

10. Merchant Registration System

Payment aggregators operating as regulated payment service providers must pay particular attention to Türkiye’s Merchant Registration System (İşyeri Kayıt Sistemi – İKS).

The Payment Services Regulation requires a merchant accepting a payment method falling within regulated payment services to have a merchant-specific code.

The code is issued through the framework operated by the Interbank Card Center (“BKM”).

The code is linked to information such as:

• merchant address;
• Turkish identification number;
• tax identification number;
• corresponding foreign information for overseas merchants.

The payment service provider contracting with the merchant must take necessary measures to verify the accuracy of the relevant information.

This means merchant onboarding is not merely a commercial sales process.

It is a regulated activity.

11. One Merchant Cannot Simply Be Treated as an Anonymous Sub-Merchant

International aggregator models frequently use the concept of a “sub-merchant.”

Turkish operational infrastructure also recognises merchant-level identification.

The regulatory emphasis is clear:

transactions must remain traceable to the actual merchant.

The Payment Services Regulation requires payment service providers to use the merchant code in payment services offered to merchants and to record and monitor transactions in a manner that allows them to be followed on a merchant-specific basis.

Accordingly, a payment aggregator should not structure thousands of unrelated merchants as though they were one single invisible merchant account.

The regulatory framework requires merchant-level transparency and monitoring.

12. Merchant Due Diligence Before Onboarding

Before beginning to provide merchant payment services, the payment service provider must check whether the proposed merchant is registered in the Merchant Registration System.

Where the merchant is not registered, the provider must arrange for registration.

Where it is registered, the provider must check for negative records concerning that merchant.

If the system indicates a legal prohibition on providing services, the provider must respect that prohibition.

Where no mandatory prohibition exists, the payment service provider must still consider the negative information within its risk management framework.

This produces an important operational requirement:

Merchant onboarding must contain both regulatory checks and risk assessment.

13. Existing Merchants Must Be Reviewed Continuously

Merchant due diligence is not completed once the merchant agreement is signed.

The Payment Services Regulation requires payment service providers to check periodically whether negative records exist concerning merchants to whom they provide services.

This check must occur at least once every year.

For higher-risk merchant categories, waiting twelve months may not be sufficient from an internal risk perspective.

Payment aggregators should therefore consider risk-based ongoing monitoring covering:

• fraud;
• chargeback ratios;
• abnormal transaction volumes;
• prohibited business activity;
• unusual refund patterns;
• changes in beneficial ownership;
• sanctions or AML concerns.

14. Merchant Agreements Must Address the Registration System

The Regulation requires the merchant to be informed about information sharing and inquiries made through the Merchant Registration System before execution of the merchant framework agreement.

The payment service provider must:

• clearly inform the merchant;
• obtain the merchant’s approval;
• ensure that relevant provisions concerning that approval are contained in the framework agreement.

Accordingly, a payment aggregator’s standard merchant agreement should not be copied directly from another jurisdiction.

Turkish regulatory provisions should be incorporated into the contract.

15. What Should a Payment Aggregator–Merchant Contract Cover?

A sophisticated merchant acquiring agreement should generally address at least:

Regulatory Role

Identify the licensed payment service provider.

Payment Methods

Specify which payment instruments and payment methods are supported.

Settlement

Define:

• settlement frequency;
• settlement account;
• cut-off times;
• deductions.

Fees

Set out merchant service fees, commissions and other charges transparently.

Refunds

Explain how refunds are processed.

Chargebacks

Allocate obligations concerning disputed card transactions.

Merchant Information

Require accurate corporate, tax and beneficial ownership information.

Prohibited Activities

Prevent use of the payment service for unlawful or contractually prohibited goods and services.

Fraud

Create rights to investigate suspicious transactions and apply proportionate risk controls.

Merchant Registration System

Include required notification and consent provisions.

Data Protection

Allocate KVKK responsibilities.

Cybersecurity

Impose minimum security standards.

Termination

Address immediate termination or suspension where required by legislation, fraud risk or regulator action.

The agreement should reflect actual payment flows.

16. Contracts Between the Aggregator and Infrastructure Provider

Where the licensed aggregator uses another payment service provider’s infrastructure, a second contractual layer is needed.

The infrastructure agreement should address:

• technical integration;
• transaction routing;
• settlement;
• merchant identifiers;
• fraud management;
• chargebacks;
• service availability;
• security;
• incident notification;
• reconciliation;
• regulatory audit;
• data use;
• termination.

Article 10 restricts how the infrastructure provider may use merchant information received through this relationship.

Information supplied for regulatory, risk and technical integration purposes cannot simply be repurposed for unrelated activities such as marketing or customer acquisition.

This is particularly important where the infrastructure provider and aggregator compete for merchants.

17. The Infrastructure Provider Cannot Arbitrarily Block Merchant Service

The current Regulation also contains an important competitive safeguard.

The infrastructure provider can require the front-end payment service provider not to serve a merchant based on appropriate risk-policy considerations.

However, it cannot arbitrarily prevent the payment service provider from providing merchant payment services through the relevant infrastructure.

This framework attempts to balance:

• infrastructure provider risk control; and
• competition between payment service providers.

It is particularly relevant to aggregators depending upon bank acquiring infrastructure.

18. Payment Aggregator vs Marketplace

A marketplace should not automatically be treated as a payment aggregator.

Article 12(2)(b) of Law No. 6493 excludes qualifying payment transactions conducted through a commercial representative authorised to negotiate or conclude the purchase or sale of goods or services on behalf of either the payer or payee.

The CBRT’s Business Models Guide recognises this statutory exclusion.

However, this exemption depends on the actual commercial agency relationship.

A platform cannot rely on it simply because its contract calls the platform an “agent.”

If the platform’s real service is accepting payments for numerous independent merchants and settling those merchants without genuinely acting as the relevant commercial representative for the underlying sale, the payment-services analysis becomes substantially more difficult.

19. Payment Aggregator vs Technical Marketplace Checkout

A marketplace can also use a structure in which:

• the marketplace provides the shopping environment;
• a licensed payment institution provides the acquiring service;
• the marketplace only embeds the checkout technically.

In that model, it should be clear to the legal parties who provides the payment service.

The marketplace should avoid:

• holding itself out as the licensed payment institution;
• independently controlling merchant settlement;
• holding merchant funds outside the authorised structure.

The licence perimeter follows the actual service—not the appearance of the checkout page.

20. Payment Aggregator vs Payment Facilitator

The expression payment facilitator (PayFac) is widely used internationally.

A typical PayFac model may:

• onboard merchants;
• provide one integration;
• route transactions through an upstream acquirer;
• reconcile transactions;
• manage merchant-level risk.

Turkish law does not simply recognise “PayFac” as a regulatory safe harbour.

A Turkish PayFac model therefore needs to determine whether the company is:

1. a licensed payment service provider providing merchant acquiring;
2. another licensed payment service provider using an upstream PSP’s infrastructure; or
3. a genuine technical provider outside the regulated service.

This analysis must be completed before the business begins merchant onboarding.

21. Does a Payment Aggregator Need a Turkish Joint-Stock Company?

Where the aggregator needs to operate as a payment institution, the corporate requirements under Law No. 6493 apply.

An ordinary payment institution must generally be established as a Turkish:

Anonim Şirket — Joint-Stock Company (A.Ş.).

The company must also satisfy requirements concerning:

• shareholders;
• transparent ownership;
• management;
• technical infrastructure;
• internal control;
• risk management.

The current Regulation provides a statutory paid-in capital floor of TRY 2 million for payment institutions providing general payment services at the licensing application stage.

However, this amount should not be confused with the much higher ongoing own-funds requirement.

22. 2026 Minimum Own Funds for a Licensed Payment Aggregator

For a normal payment aggregator operating under the general payment institution category, the relevant minimum own-funds requirement is now:

TRY 40 million.

The CBRT’s 31 January 2026 Communiqué increased the minimum own-funds amounts effective 30 June 2026 to:

• TRY 20 million for the specified bill-payment intermediary category;
• TRY 40 million for other payment institutions excluding pure Account Information Service providers;
• TRY 105 million for electronic money institutions.

A merchant acquiring/payment aggregator institution therefore generally needs to plan around the TRY 40 million minimum own-funds category, subject to the detailed regulatory calculation rules.

This is one reason why the legal distinction between a licensed aggregator and an unlicensed technical gateway has major commercial consequences.

23. Own Funds Can Exceed the Published Minimum

The TRY 40 million figure should not automatically be treated as a fixed maximum regulatory capital requirement.

The Payment Services Regulation also contains transaction-volume-based calculations and gives the CBRT powers within the regulatory framework concerning financial adequacy.

Accordingly, a rapidly growing aggregator processing large volumes should model:

• statutory minimum own funds;
• transaction-based own-funds calculations;
• operating losses;
• capital buffers.

A business plan based only on the minimum headline figure can underestimate required financial resources.

24. Does an Aggregator Need an Electronic Money Licence?

Not necessarily.

Merchant acquiring and electronic money are separate regulated activities.

A conventional aggregator processing card payments for merchants does not automatically issue electronic money.

However, electronic money questions can arise if the business begins allowing merchants or customers to maintain stored monetary balances that satisfy the statutory e-money definition.

For example, if the platform creates reusable monetary value:

• issued against funds;
• stored electronically;
• usable for payment transactions;
• accepted by persons other than the issuer,

electronic money licensing should be examined separately.

An aggregator should therefore avoid creating “wallet balances” or “platform credits” without regulatory review.

25. Additional Payment Services May Require Additional Licence Scope

Article 12(1)(c) acquiring authorisation does not necessarily permit every other payment activity.

If the aggregator additionally offers:

• merchant payment accounts;
• account-to-account transfers;
• money remittance;
• Payment Initiation Services;
• digital wallet functionality,

additional Article 12 licence categories may be required.

The CBRT’s Business Models Guide emphasises that institutions can provide only those payment services included within their authorised licence scope and must obtain permission to add further payment services.

Fintech product teams should therefore conduct a licence review before every material service expansion.

26. Virtual POS Services

Virtual POS is one of the most commercially important aggregator products.

The CBRT has specifically treated virtual POS services supplied by payment service providers to merchants as part of the payment acceptance environment.

Its 2024 Annual Report notes supervisory work concerning virtual POS services offered by payment service providers for accepting payment cards and the need to ensure compliance with Turkish QR Code requirements across payment services.

Accordingly, virtual POS is not merely a web-development feature.

Where the provider contracts with merchants and provides payment acceptance, merchant acquiring rules should be analysed.

27. Merchant-Level Transaction Monitoring

The Payment Services Regulation expressly requires merchant-service transactions to be recorded and monitored so that they can be tracked separately for each merchant.

A payment aggregator should therefore maintain systems capable of answering:

Which merchant generated this transaction?

What was the payment amount?

Which payment method was used?

Was the transaction refunded?

What is the merchant’s chargeback rate?

Is merchant transaction volume consistent with its business profile?

This is important for both fraud prevention and AML compliance.

28. MASAK Compliance for Payment Aggregators

A payment institution providing merchant acquiring is generally subject to the Turkish AML framework administered by MASAK.

The formal MASAK Compliance Programme Regulation requires payment institutions to establish a compliance programme, except for institutions exclusively providing certain specified services such as bill-payment intermediation, Payment Initiation Services and Account Information Services.

Merchant acquiring is not within those listed compliance-programme exceptions.

Accordingly, a licensed payment aggregator should generally establish a full institutional compliance programme including:

• AML policy and procedures;
• risk management;
• monitoring and control;
• compliance officer;
• compliance unit;
• employee training;
• internal audit.

Merchant acquiring should therefore be designed together with MASAK compliance.

29. Merchant KYC Is More Than Obtaining a Tax Certificate

Aggregators can face substantial financial crime risk through merchants.

Merchant due diligence should consider:

• legal identity;
• authorised representatives;
• shareholders;
• beneficial ownership;
• business activity;
• website;
• products and services;
• expected transaction volume;
• geographic exposure.

Higher-risk categories may require enhanced due diligence.

For example, a merchant declaring annual sales of TRY 2 million but suddenly processing TRY 50 million through the aggregator deserves investigation.

Merchant KYC should therefore remain dynamic throughout the relationship.

30. Suspicious Transaction Reporting

Payment and electronic money institutions are subject to sector-specific suspicious transaction reporting requirements.

MASAK updated its dedicated Payment and Electronic Money Institutions Suspicious Transaction Reporting Guide in June 2024 to reflect current fintech products, transaction types and financial crime typologies.

A payment aggregator should therefore implement systems capable of detecting patterns such as:

• fictitious merchant transactions;
• transaction laundering;
• repeated suspicious refunds;
• unusual merchant settlements;
• use of multiple merchant accounts to disguise activity;
• rapid transaction volume changes.

Merchant monitoring is therefore simultaneously:

payment regulation + fraud management + AML compliance.

31. Transaction Laundering Risk

Payment aggregators face a specific risk where a merchant appears to sell one type of product but actually processes payments for another activity.

For example, a merchant may register as an ordinary retail store but use the payment infrastructure to accept payments for:

• prohibited products;
• an unrelated third-party business;
• illegal gambling;
• fraudulent investment services.

This is sometimes described as transaction laundering.

Aggregators should therefore monitor not only merchant transaction amounts but also whether observed activity is consistent with the merchant’s declared business.

Website monitoring and merchant-category controls may be appropriate components of the risk programme.

32. Chargebacks and Fraud Allocation

Merchant acquiring agreements should clearly regulate chargebacks.

The contract should determine:

• when amounts can be debited;
• evidence required from merchants;
• applicable deadlines;
• treatment of refunds;
• consequences of excessive chargebacks;
• fraud reserve mechanisms.

However, contractual rights should remain proportionate and consistent with mandatory financial and commercial law.

An aggregator should not rely on vague clauses allowing indefinite retention of all merchant funds without objective criteria.

Risk controls should be documented.

33. Reserve and Holdback Arrangements

Aggregators may seek contractual protection through:

• rolling reserves;
• delayed settlement;
• security deposits;
• holdbacks.

These mechanisms can be commercially useful in higher-risk merchant acquiring.

However, the agreement should clearly explain:

• calculation method;
• duration;
• release conditions;
• circumstances permitting use of the reserve.

The funds should also be handled consistently with payment-services rules and the legal character of merchant/customer funds.

A contractual label does not determine the regulatory treatment of money held by a payment institution.

34. Safeguarding of Payment Funds

Law No. 6493 requires payment and electronic money institutions to protect relevant customer/payment funds through regulated safeguarding mechanisms.

The CBRT has publicly reiterated that funds belonging to payment service users at payment and electronic money institutions are protected through safeguarding accounts at banks under Article 22.

A payment aggregator should therefore maintain a clear distinction between:

• corporate money;
• merchant payment funds;
• fees earned by the institution.

Merchant settlement funds should not simply be treated as unrestricted working capital.

35. KVKK Compliance

Payment aggregators process substantial personal data.

Depending on the model, data may include:

• merchant representatives;
• beneficial owners;
• consumers;
• transaction information;
• card-related information;
• IP addresses;
• device data;
• fraud indicators.

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

The Guide specifically addresses:

• data controller and processor status;
• processed personal data;
• legal grounds;
• transfers;
• data-controller obligations;
• data security.

Aggregators should therefore treat KVKK compliance as a sector-specific operational requirement.

36. Merchant Data Shared With Infrastructure Providers

Where one payment service provider uses another provider’s infrastructure, merchant information may need to be shared.

However, the Payment Services Regulation restricts use of that information.

Data supplied for:

• regulatory risk analysis;
• technical onboarding;
• infrastructure operation

cannot be repurposed for unrelated purposes such as marketing or merchant acquisition.

This rule is especially important where an aggregator depends on a larger bank or PSP that competes for the same merchants.

Contracts and technical access controls should reflect the regulatory restriction.

37. Cross-Border Data Transfers

International aggregators frequently rely on foreign:

• cloud providers;
• fraud platforms;
• CRM systems;
• analytics providers;
• group-company systems.

These arrangements must be analysed under KVKK Article 9.

A valid personal data transfer mechanism may include the Turkish standard contractual framework or another legally recognised mechanism.

However, payment institutions must also comply with CBRT information systems requirements.

Therefore:

KVKK permission alone does not automatically make a foreign technology architecture permissible for a licensed payment aggregator.

The sector-specific payment rules must also be satisfied.

38. Information Systems and Cybersecurity

Payment aggregators are technology-intensive regulated institutions.

The CBRT’s current payment-services legal framework expressly includes the Information Systems Communiqué governing payment and electronic money institutions.

A regulated aggregator should maintain controls concerning:

• access management;
• encryption;
• authentication;
• transaction logging;
• vulnerability management;
• penetration testing;
• business continuity;
• incident response;
• outsourcing.

Cybersecurity weakness can create:

• customer fraud;
• merchant loss;
• regulatory sanctions;
• data breaches.

Information security should therefore be integrated directly into merchant acquiring infrastructure.

39. Foreign Payment Aggregators Entering Turkey

A payment aggregator authorised in another country does not automatically receive Turkish acquiring permission.

Türkiye does not operate a general payment-services passport allowing a foreign licence to replace CBRT authorisation.

A foreign aggregator seeking to:

• contract Turkish merchants;
• provide payment acceptance;
• operate Turkish merchant settlement

should therefore determine whether a Turkish regulated structure is required.

Possible market-entry structures may include:

• obtaining a Turkish payment institution licence;
• acquiring a licensed Turkish payment institution;
• partnering with a licensed Turkish PSP while remaining genuinely technical.

The appropriate structure depends on the actual service allocation.

40. Acquiring a Licensed Payment Aggregator

Investors acquiring a Turkish aggregator should conduct specialised regulatory due diligence.

The review should include:

Licence Scope

Does the target hold Article 12(1)(c) acquiring permission?

Infrastructure

Does it use banks or other PSP infrastructure?

Merchant Agreements

Are merchants legally contracted by the correct entity?

Merchant Registry

Are BKM merchant codes correctly maintained?

Merchant Monitoring

Are transactions identifiable at merchant level?

Regulatory Capital

Does the company maintain the 2026 TRY 40 million minimum own funds?

MASAK

Does the compliance programme actually work?

Customer Funds

Are safeguarding and settlement arrangements correct?

KVKK

Is merchant/customer data processed lawfully?

Cybersecurity

Have information systems been audited appropriately?

A company with attractive merchant volume but weak regulatory infrastructure may create significant post-acquisition liabilities.

41. Common Payment Aggregator Compliance Mistakes

Assuming “Aggregator” Is an Exemption

It is not an independent exemption under Law No. 6493.

Relying on an Upstream Bank’s Licence

Using a bank’s infrastructure does not automatically remove the front-end provider’s acquiring obligations.

Calling Acquiring a Technical Gateway

Actual merchant contracts and settlement responsibility matter.

Failing to Register Merchants Properly

Merchant-specific identification is an express part of the Turkish framework.

Treating All Merchants as One Master Merchant

Transactions must remain traceable and monitorable at merchant level.

Ignoring Merchant Negative Records

Pre-onboarding and ongoing Merchant Registration System checks are required.

Using Merchant Data for Marketing

Infrastructure providers face restrictions on repurposing merchant information obtained for regulatory/technical purposes.

Underestimating Capital

A general payment institution is subject to a TRY 40 million minimum own-funds requirement from 30 June 2026.

Treating AML as Consumer KYC Only

Merchant acquiring creates its own fraud, beneficial ownership and transaction laundering risks.

42. Payment Aggregator Compliance Checklist

Before launching a payment aggregation business in Türkiye, management should answer the following.

Business Model

Do we contract with merchants?

Regulatory Service

Are we actually acquiring payment instruments?

Licence

Do we hold Article 12(1)(c) permission?

Infrastructure

Are we using another licensed PSP’s infrastructure?

Merchant Registration

Does each merchant have the required BKM merchant code?

Merchant Due Diligence

Have identity, tax and business information been verified?

Negative Records

Do we check the Merchant Registration System before onboarding?

Annual Review

Do we periodically check merchant records?

Transaction Monitoring

Can every transaction be traced to the relevant merchant?

Merchant Contract

Does the agreement contain mandatory Turkish regulatory provisions?

Settlement

Are settlement arrangements clearly documented?

Safeguarding

Are merchant/customer funds properly protected?

Capital

Can the institution maintain at least the applicable TRY 40 million own-funds floor?

MASAK

Is a full compliance programme established?

Fraud

Are merchant fraud and transaction laundering controls operating?

Data Protection

Is merchant and customer data handled under KVKK?

Infrastructure Data

Is merchant information shared with upstream PSPs only for permitted purposes?

Cybersecurity

Are payment infrastructure and APIs adequately protected?

Frequently Asked Questions About Payment Aggregators in Turkey

Is “payment aggregator” a separate licence category in Turkey?

No.

Turkish law classifies the actual payment activity rather than creating a separate payment aggregator licence. A typical merchant-facing aggregator may fall within Article 12(1)(c) acquiring payment instruments.

Who regulates payment aggregators?

Where the business provides regulated payment services, the principal regulator is the Central Bank of the Republic of Türkiye.

What is payment instrument acquiring?

It is a service involving agreement with a merchant and accepting and processing payments using a payment instrument in a manner resulting in funds being transferred to the merchant.

Does a payment gateway need a licence?

Not necessarily.

A pure technical provider that processes or transmits data and never becomes owner of transferred funds may potentially fall within the Article 12(2) technical services exclusion.

Can a licensed payment aggregator use a bank’s infrastructure?

Yes, depending on the structure. The Payment Services Regulation expressly addresses merchant services provided by one payment service provider using infrastructure supplied by another payment service provider.

Does using a bank’s virtual POS eliminate the need for a licence?

Not automatically.

Where the aggregator itself contracts with merchants and provides the regulated acquiring service, an upstream bank’s infrastructure does not by itself remove the aggregator’s licensing obligation.

Must merchants be registered?

Yes. The current Regulation establishes a Merchant Registration System using merchant-specific codes issued through BKM.

Must merchant transactions be tracked separately?

Yes. Payment service providers must record and monitor merchant-service transactions so that they can be followed at merchant level.

Must merchants be checked before onboarding?

Yes. The provider must check the Merchant Registration System and consider relevant negative information before beginning the service.

Are existing merchants checked again?

Yes. The Regulation requires periodic checks, at least annually.

What is the minimum own-funds requirement for a payment aggregator in 2026?

A normal acquiring payment institution generally falls within the other-payment-institution category, for which the minimum own-funds amount is TRY 40 million from 30 June 2026, subject to the detailed own-funds calculation framework.

Are payment aggregators subject to MASAK?

A licensed payment institution providing merchant acquiring will generally be subject to MASAK’s full institutional compliance programme because acquiring is not among the limited payment-institution exceptions specified in the Compliance Programme Regulation.

Does KVKK apply to payment aggregators?

Yes. The Turkish Personal Data Protection Authority’s 2026 sector guide expressly covers payment-sector businesses, including POS-related activities, and addresses data processing, transfer and security.

Can a foreign payment aggregator serve Turkish merchants under its foreign licence?

A foreign payment licence does not automatically passport into Türkiye. The Turkish regulatory perimeter must be analysed separately.

Conclusion: How to Structure a Payment Aggregator Legally in Turkey

Payment aggregator regulation in Turkey should be approached through the legal function performed by the business rather than the commercial terminology used to market it.

There is no independent Turkish regulatory category called a “payment aggregator licence.”

For most merchant-facing aggregation models, the central regulated activity is instead payment instrument acquiring under Article 12(1)(c) of Law No. 6493.

The CBRT’s current authorised-institution register expressly identifies Article 12(1)(c) permissions for payment institutions as limited to acquiring payment instruments.

The acquiring definition provides the key legal test.

Where the company enters into an agreement with the merchant, accepts and processes transactions conducted using payment instruments and provides the service resulting in funds being transferred to the merchant, the structure falls squarely within the regulatory territory that a payment aggregator should analyse as acquiring.

The distinction from a payment gateway is equally important.

A technology provider may remain outside regulated payment services where its activity is limited to matters such as:

• data processing;
• authentication;
• security;
• communication infrastructure;
• payment technology,

and where it never becomes the owner of funds being transferred.

The CBRT’s Business Models Guide expressly confirms the technical-service-provider exclusion within the Turkish framework.

Accordingly, two companies can offer technologically similar APIs while having completely different regulatory obligations.

The difference may lie in:

who contracts with the merchant;

who legally provides acquiring;

who controls settlement;

who assumes payment-service liability.

Turkish regulation also expressly permits sophisticated layered infrastructure structures.

A licensed payment service provider may supply payment services to merchants while using payment infrastructure belonging to another payment service provider.

Where this occurs, the merchant-facing institution must provide specified merchant information to the infrastructure provider within ten business days.

This rule provides an important legal foundation for payment aggregator structures that depend on upstream banks or other payment service providers.

But it also demonstrates why the argument:

“We use another company’s infrastructure, therefore we are not regulated”

is usually too simplistic.

Infrastructure and regulatory responsibility are different concepts.

Merchant compliance is another central element of the Turkish model.

The Merchant Registration System requires merchant-specific identification and allows payment service providers to review information relating to merchants before entering into a relationship.

Providers must check whether a merchant is registered, investigate negative records and repeat relevant checks periodically.

Transactions must also be recorded and monitored so that they can be identified at merchant level.

This makes highly opaque “master merchant” arrangements difficult to reconcile with the Turkish regulatory approach.

The actual merchant must remain visible within the regulatory infrastructure.

Merchant contracts should also be localised.

In addition to ordinary commercial terms concerning:

• pricing;
• settlement;
• refunds;
• chargebacks;
• reserves;
• termination,

the framework agreement should incorporate Turkish regulatory requirements concerning merchant registration, information sharing and risk management.

Where another PSP’s infrastructure is used, a second agreement must clearly allocate technical and regulatory responsibility.

The infrastructure provider’s access to merchant information is also restricted.

Information received for regulatory, risk and technical purposes cannot simply be used for unrelated marketing or merchant acquisition.

From a financial perspective, becoming a licensed aggregator requires meaningful capital.

From 30 June 2026, the minimum own-funds requirement applying to the general payment institution category is TRY 40 million.

This amount is significantly higher than the nominal statutory paid-in capital floor relevant at the application stage and should be treated as an ongoing regulatory requirement rather than a one-time licensing cost.

For payment aggregators processing large transaction volumes, actual regulatory capital requirements may require further calculation and buffers.

AML compliance also has a particularly important role.

Merchant acquiring businesses fall within the institutional MASAK compliance regime.

The exceptions applicable to certain payment institutions providing only bill-payment, Payment Initiation or Account Information Services do not include ordinary merchant acquiring.

A payment aggregator should therefore establish:

• a compliance officer structure;
• merchant KYC;
• beneficial ownership review;
• transaction monitoring;
• suspicious transaction reporting;
• risk management;
• training;
• internal audit.

Merchant acquiring is particularly vulnerable to risks such as transaction laundering, fictitious merchants, fraudulent refunds and the use of legitimate-looking merchant accounts for unrelated prohibited activity.

MASAK’s sector-specific suspicious transaction guide for payment and electronic money institutions has been updated specifically to reflect changing fintech transaction types and crime typologies.

Data protection and cybersecurity must likewise be treated as part of the acquiring product.

The Turkish Personal Data Protection Authority’s 2026 Payment and Electronic Money Sector Good Practices Guide specifically includes POS-service activities and provides guidance on controller/processor status, processing grounds, transfers and information security.

Payment aggregators handling large merchant networks should therefore maintain clear rules concerning:

• merchant data;
• consumer transaction information;
• fraud data;
• upstream infrastructure sharing;
• international technology vendors.

Finally, regulatory enforcement should not be treated as theoretical.

In January 2026, the CBRT reported that its 2025 supervision resulted in:

• 7 licence cancellations;
• 14 temporary licence suspensions;
• TRY 373.2 million of administrative fines across 72 institutions;
• 331 suspected unauthorised payment-service cases being referred to prosecutors and/or courts.

For payment aggregator founders and investors, the lesson is clear:

The commercial model must be designed around the licence—not the licence around a model that has already been launched.

The correct regulatory sequence is generally:

map the merchant relationship → map the flow of funds → identify who provides acquiring → determine whether Article 12(1)(c) authorisation is required → structure upstream infrastructure relationships → establish merchant-registration procedures → prepare merchant agreements → satisfy capital requirements → implement MASAK/KVKK/cybersecurity controls → obtain CBRT authorisation → launch within the approved licence scope.

For foreign payment facilitators and aggregators considering the Turkish market, the same analysis should be completed before Turkish merchants are actively onboarded.

A foreign PayFac label, overseas acquiring licence or international bank partnership does not itself determine the Turkish legal result.

The key principle is:

If the company is merely providing technology, it may be a payment gateway. If it contracts with merchants and undertakes the regulated payment acceptance function that leads to merchant settlement, it is moving into merchant acquiring—and Turkish payment institution licensing becomes a central issue.

Legal Disclaimer: This publication provides general information concerning payment aggregators, merchant acquiring, payment gateways and related payment-services regulation in Türkiye as of July 2026. It does not constitute legal, financial or regulatory advice. The regulatory classification of an aggregator depends on the exact merchant contract, flow of funds, settlement structure, payment instruments, upstream infrastructure, customer-facing role and additional services provided. Each payment aggregation or PayFac model should therefore be individually analysed under Law No. 6493 and current CBRT regulations before launch.