Introduction: Are Virtual IBANs Regulated in Turkey?

Virtual IBANs have become an increasingly important part of fintech, payment collection, marketplace, treasury and account-reconciliation infrastructure.

A business may use a virtual IBAN to provide each customer, merchant, invoice or transaction with a unique payment reference that allows incoming funds to be automatically identified and allocated.

Commercial use cases include:

• marketplace seller collections;
• business payment collection;
• customer-specific payment accounts;
• invoice reconciliation;
• international payment services;
• embedded finance;
• treasury management;
• payment institution accounts.

However, the expression “virtual IBAN” does not itself create a separate licence category under Turkish financial legislation.

Türkiye regulates the underlying financial function.

The decisive questions are therefore not:

“Does the company offer virtual IBANs?”

but rather:

“What legal account does the IBAN identify?”

“Who is the legal payment service provider?”

“Who owns or controls the funds?”

“Is a payment account opened in the customer’s name?”

“Are funds received on behalf of third parties?”

“Does the fintech merely provide technical reconciliation, or does it provide regulated payment services?”

As of July 2026, Turkish payment legislation regulates IBANs, payment accounts, payment transfers, payment institutions and electronic money institutions, but does not establish an independent financial licence named a Virtual IBAN Licence. The legal analysis therefore proceeds primarily under Law No. 6493, the CBRT Payment Services Regulation and the IBAN Communiqué.

This distinction is extremely important.

A lawful customer-specific IBAN structure operated by a licensed payment institution can be an ordinary part of the Turkish payment ecosystem.

By contrast, an unlicensed technology company that creates “virtual IBANs,” receives money belonging to customers or merchants and redistributes those funds may potentially cross into regulated payment services.

The consequences can be substantial.

Law No. 6493 provides criminal sanctions for persons operating as payment institutions or electronic money institutions without the legally required permission.

Accordingly, every virtual IBAN business model should be analysed by mapping:

account ownership → IBAN → incoming transfer → ledger allocation → safeguarding → outgoing transfer.

This guide examines the principal legal risks and compliance requirements for virtual IBAN services in Turkey in 2026.

1. What Is an IBAN Under Turkish Law?

IBAN means International Bank Account Number.

Under the Turkish IBAN framework, an IBAN is a standardised account identifier designed to allow payment accounts to be identified accurately during domestic and international money transfers.

Following the 2021 amendments, the Turkish IBAN regime was extended beyond banks to the payment service providers listed under Article 13 of Law No. 6493.

The CBRT expressly explained that this amendment allowed payment and electronic money institutions, in addition to banks and PTT, to generate IBANs for customer accounts used for money transfers.

This was an important development for Turkish fintech.

Before the change, IBAN was predominantly associated with traditional bank accounts.

The modern framework permits regulated non-bank payment service providers to operate customer accounts that can participate more directly in the Turkish payments infrastructure.

2. A Turkish IBAN Identifies an Account

The amended IBAN Communiqué states that an IBAN consists of 26 alphanumeric characters and points to an account.

The structure contains:

• 2 characters for the country code;
• 2 IBAN check digits;
• 5 digits identifying the payment service provider;
• 1 reserved digit;
• 16 characters for the account-number field.

The payment service provider codes used in the IBAN are determined by the CBRT.

This is a crucial legal point for virtual IBAN structures.

A Turkish IBAN is not simply a random payment reference.

Where a fintech represents a number as an actual Turkish IBAN, it should operate consistently with the regulatory IBAN structure.

An internal customer number, invoice reference or reconciliation code is not automatically an IBAN merely because it resembles one commercially.

3. What Is a “Virtual IBAN”?

Unlike “payment account” or “electronic money,” virtual IBAN is primarily a commercial and technological expression rather than a separate statutory category under Law No. 6493.

In practice, the term is commonly used for an account-identification structure in which a specific identifier is allocated to:

• a customer;
• merchant;
• invoice;
• business unit;
• transaction.

Incoming payments to that identifier can then be automatically attributed to the correct underlying customer or ledger.

The legal structure can vary significantly.

A virtual IBAN may represent:

A Genuine Customer Payment Account

The customer has a real payment account maintained by an authorised payment service provider and an IBAN is generated for that account.

A Collection Identifier

A unique identifier may route funds into a common master account, with software determining which customer or invoice should receive ledger credit.

A Technical Reconciliation Tool

The “virtual account” may merely allow an ordinary business to reconcile payments owed directly to that business.

These three structures are not necessarily regulated in the same manner.

4. Payment Accounts Are Legally Regulated

Law No. 6493 defines a payment account by reference to an account opened in the name of a payment service user and used for execution of payment transactions.

The operation of a payment account is itself a regulated payment service.

Article 12 includes:

• depositing funds into a payment account;
• withdrawing funds;
• operations necessary for managing the payment account.

Transfers of funds from such an account are separately included within Article 12(1)(b).

Therefore, a company cannot avoid payment regulation by describing the customer account as:

• “virtual account”;
• “collection account”;
• “wallet ledger”;
• “sub-account”;
• “virtual IBAN.”

If the economic and legal reality is that the company opens and operates a payment account for the customer, the Article 12 payment-services framework becomes relevant.

5. Who Can Provide Payment Accounts in Turkey?

Law No. 6493 identifies the recognised payment service providers as:

• banks;
• electronic money institutions;
• payment institutions;
• PTT.

The Law expressly provides that persons other than the CBRT and recognised payment service providers cannot provide payment services.

Accordingly, where a virtual IBAN structure effectively provides customers with payment accounts, the entity providing that service must have the appropriate Turkish regulatory status.

An ordinary fintech software company cannot simply open thousands of customer ledgers, collect third-party money into them and provide transfers merely by calling the structure a “virtual IBAN platform.”

6. Payment Institutions Can Generate IBANs

One of the most important regulatory developments occurred in 2021.

The CBRT expanded the IBAN Communiqué to cover all payment service providers under Article 13 of Law No. 6493.

As a result, non-bank payment service providers can generate IBANs for customer accounts subject to money transfers.

This enables licensed fintech companies to offer products that commercially resemble modern digital business accounts.

For example, a payment institution may potentially provide a corporate customer with:

a payment account + customer-specific IBAN + transfer functionality

provided the institution has the relevant payment-service permissions.

7. A Payment Institution Choosing IBAN Must Follow the CBRT Structure

The CBRT has provided an especially important clarification for payment and electronic money institutions.

In its 5 August 2021 communication to TÖDEB, the CBRT stated that payment and electronic money institutions that choose to use IBAN as their account structure—even where they are not participants in FAST—must generate a compliant IBAN for each customer account subject to money transfers, use that IBAN in transfers and show it in relevant documents.

This point is highly relevant to virtual IBAN services.

Where the fintech offers a genuine customer payment account, assigning an IBAN should not be treated merely as a marketing feature.

The IBAN should be part of the legally regulated customer-account structure.

8. A Virtual IBAN Should Not Be Confused With an Internal Customer Reference

Payment institutions can also use separate customer identifiers.

The Payment Services Regulation requires customers in continuing framework relationships to receive unique identifiers, and Turkish payment infrastructure can use customer numbers or other references for operational purposes.

Therefore:

IBAN ≠ customer number.

A company may internally assign:

• customer ID 123456;
• merchant ID ABC123;
• invoice number 98765.

These references can help reconcile incoming transactions.

But they should not automatically be represented as IBANs.

Where a fintech gives customers what appears to be a real Turkish IBAN, the IBAN regulatory framework becomes relevant.

9. Virtual IBAN vs KOLAS: They Are Not the Same Thing

Türkiye also operates the Kolay Adresleme Sistemi (“KOLAS”) through the FAST ecosystem.

KOLAS enables payment accounts to be reached without entering an IBAN by using aliases such as:

• telephone number;
• Turkish identification number;
• email address;
• passport number;
• tax identification number.

The CBRT confirms that FAST transactions can be initiated through these easy-address identifiers instead of an IBAN.

KOLAS should not be confused with virtual IBAN.

KOLAS is essentially an aliasing mechanism pointing to an existing account.

A virtual IBAN structure usually concerns the account or collection identifier itself.

This distinction matters for product design and consumer disclosures.

10. When Does a Virtual IBAN Require a Payment Institution Licence?

The answer depends on what happens behind the identifier.

Consider the following structure:

Customer receives IBAN → third party transfers funds → institution credits customer’s payment account → customer can transfer funds elsewhere.

This model strongly implicates:

• payment account operation under Article 12(1)(a); and
• money transfer under Article 12(1)(b).

A company providing this structure generally needs the appropriate payment-services authorisation unless another recognised payment service provider is legally providing the service.

The fact that the customer interface calls the account “virtual” does not alter the underlying legal function.

11. Virtual IBANs and Electronic Money

Some virtual IBAN models also include electronic money.

For example:

1. a customer transfers TRY 10,000 to a customer-specific IBAN;
2. the institution credits TRY 10,000 to an electronic wallet;
3. the customer can use that balance for purchases or transfers.

In such a structure, the business may involve both:

• payment-account/payment-transfer services; and
• electronic money issuance.

The CBRT currently confirms that authorised electronic money institutions may issue electronic money under Article 18(2), while their additional payment activities depend on their individual Article 12 licence scopes.

The regulatory model should therefore determine whether incoming virtual-IBAN funds create:

a payment-account balance

or

electronic money.

The distinction can materially affect licensing and regulatory capital.

12. 2026 Regulatory Capital Can Be Significant

Where the virtual IBAN provider itself becomes a regulated payment or electronic money institution, substantial financial requirements apply.

From 30 June 2026, the minimum own-funds requirements are:

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

Accordingly, a startup cannot economically treat regulated virtual IBAN infrastructure like an ordinary SaaS product.

The regulatory architecture may require tens of millions of Turkish lira in continuing own funds.

13. The Master Account + Virtual IBAN Model

One of the most common virtual-account architectures involves a master account.

For example:

Payment Institution A maintains a central account.

Merchant X is assigned virtual identifier 001.

Merchant Y is assigned virtual identifier 002.

Payments received into the system are automatically credited in the internal ledger to the appropriate merchant.

This model can be efficient for:

• reconciliation;
• merchant collection;
• marketplaces;
• corporate treasury.

However, the legal analysis should answer a fundamental question:

Does each merchant legally have a payment account, or is the merchant only a beneficiary recorded in an internal ledger?

This affects:

• licensing;
• contractual rights;
• safeguarding;
• insolvency treatment;
• customer disclosures;
• AML.

The accounting structure should match the legal structure.

14. A Virtual IBAN Does Not Automatically Mean a Separate Legal Account

Fintech companies should avoid assuming that every technical virtual account automatically creates an independent legal payment account.

The contract, ledger architecture and regulated institution’s books determine the legal relationship.

If several virtual identifiers ultimately point into a pooled account, the service provider should clearly establish:

• who owns the underlying funds;
• whether individual payment accounts exist;
• how balances are recorded;
• how customers can withdraw or transfer funds.

This issue is particularly important in insolvency and enforcement scenarios.

A customer should not discover after a regulatory or financial problem that what was marketed as “your own account” was actually only an internal reconciliation tag.

15. Marketing Can Create Regulatory Risk

The way a fintech describes a virtual IBAN matters.

Potentially problematic claims may include:

“You have your own Turkish bank account”

when the customer actually has only an internal ledger position with a non-bank fintech.

A payment institution is not a bank.

Law No. 6493 permits payment institutions to maintain payment accounts only for purposes connected with payment transactions and expressly distinguishes those funds from bank deposits.

Therefore, customer-facing terminology should accurately identify whether the account is:

• a bank account;
• a payment account;
• an electronic money account;
• a technical collection reference.

Avoiding regulatory confusion is particularly important for foreign customers who may assume that every TR IBAN represents a conventional deposit account.

16. Virtual IBAN Collection for a Company’s Own Receivables

Not every virtual-account collection product necessarily constitutes a payment service.

Consider a software company that sells its own products.

It receives payments owed to itself.

Its bank or payment provider allocates separate payment references to different invoices.

The software simply reconciles those incoming payments.

The software company is not necessarily providing payment services to third parties merely because it uses virtual account technology internally.

The regulatory risk becomes much greater when the company collects funds:

for other people.

17. Collecting Funds for Third Parties Changes the Analysis

Consider a marketplace.

Buyer A pays TRY 10,000 to a virtual IBAN associated with Seller B.

Platform C receives or controls the money.

Platform C later transfers TRY 9,000 to Seller B after deducting commission.

This structure can involve regulated payment activity.

The platform should analyse whether it is:

• operating payment accounts;
• conducting money transfers;
• acquiring payments;
• providing money remittance;
• relying on a legitimate statutory exception.

The simple fact that the payment arrived through a “virtual IBAN” does not create an exemption from Law No. 6493.

The underlying movement of funds remains decisive.

18. Technical Service Providers Can Remain Outside Licensing

Turkish law does create room for genuine technology providers.

Article 12(2)(ğ) excludes technical services supporting payment activity where the provider offers functions such as:

• data processing;
• data storage;
• information security;
• authentication;
• IT infrastructure;
• communications infrastructure,

and does not become owner of the transferred funds at any stage.

This can be highly relevant for virtual IBAN technology.

A company may potentially provide:

• virtual-account allocation software;
• reconciliation;
• APIs;
• invoice matching;
• merchant dashboards,

while a licensed bank or payment institution provides the actual payment account and receives the funds.

The roles must nevertheless remain genuinely separate.

19. Merely Calling the Company a Technology Provider Is Not Enough

The technical-services exclusion is based on substance.

A fintech creates greater licensing risk where it:

• receives customer funds into its own accounts;
• controls settlement;
• decides when merchants are paid;
• opens balances for customers;
• executes transfers;
• contracts as the payment service provider.

The safer technical-provider structure is generally:

payer → licensed PSP account → beneficiary

with the technology company only providing technical reconciliation.

The technology company’s terms, website and user interface should reflect that limited role.

20. Safeguarding Is Essential in Virtual IBAN Models

Where a payment institution receives customer payment funds, those funds must be handled under the Turkish safeguarding regime.

The current Payment Services Regulation contains dedicated provisions concerning protection of payment funds and electronic money funds. The framework requires separation of relevant customer funds from the institution’s own corporate money.

Virtual IBAN systems should therefore permit the institution to determine at all times:

• whose money has been received;
• which virtual IBAN received it;
• which customer balance must be credited;
• whether the funds have been transferred;
• how much remains protected.

A pooled bank account without reliable customer-level sub-ledger records creates serious regulatory and operational risk.

21. 2026 Safeguarding Rules Were Further Updated

The payment-services framework continued to evolve in 2026.

On 19 March 2026, the CBRT amended the Payment Services Regulation regarding payment and electronic money safeguarding accounts and introduced rules allowing qualifying Turkish-lira safeguarding balances to be remunerated through specified bank accounts, subject to the detailed regulatory structure.

This development reinforces an important principle:

Customer payment money remains part of a specifically regulated safeguarding architecture even where the underlying treasury structure changes.

Virtual IBAN providers should therefore avoid designing pooled-account structures based only on ordinary commercial bank-account logic.

22. Reconciliation Must Be Customer-Specific

Virtual IBANs are frequently adopted precisely because they improve reconciliation.

Regulatory compliance requires that this advantage be used properly.

A compliant system should be able to reconstruct:

virtual IBAN → incoming transfer → sender → beneficiary/customer → ledger entry → outgoing payment.

This becomes especially important during:

• CBRT inspections;
• customer disputes;
• fraud investigations;
• MASAK investigations;
• insolvency.

The system should not create a situation where the institution knows that TRY 50 million is held in an omnibus account but cannot reliably identify which customers own the underlying balances.

23. Framework Agreements and Customer Identifiers

Where a continuing payment relationship exists, the Payment Services Regulation requires the relationship to be governed through a framework agreement.

The current regulation also requires each customer under such an agreement to receive a separate identifier, which cannot be reassigned to another customer until ten years after termination of the prior relationship.

For a virtual IBAN provider, the contractual documentation should explain clearly:

• whether the IBAN belongs to a payment account;
• permitted use;
• incoming-transfer rules;
• fees;
• transfer rights;
• suspension and closure;
• safeguarding.

The customer should understand the legal nature of the product.

24. MASAK KYC Applies to Payment Institutions

Virtual IBANs can be especially attractive to criminals because account identifiers make it easy to collect money remotely.

Payment and electronic money institutions therefore operate within Türkiye’s AML/CFT framework administered by MASAK.

MASAK’s current obligations expressly require obliged institutions to know their customers, identify persons conducting transactions and identify persons on whose behalf or account transactions are carried out before relevant transactions.

For a virtual IBAN provider, KYC should therefore establish not only:

who the registered customer is

but, where relevant:

for whose account money is actually being received.

25. Merchant and Business Customers Need Beneficial Ownership Analysis

Virtual IBAN products are often marketed to businesses.

For corporate customers, simply collecting the company’s trade name is not sufficient for a robust AML programme.

The institution should understand:

• the customer’s business activity;
• authorised representatives;
• beneficial ownership;
• expected payment flows;
• countries involved;
• likely counterparties;
• anticipated transaction volume.

A newly incorporated company expecting TRY 50,000 of monthly revenue but receiving TRY 20 million through hundreds of unrelated payers should generate meaningful compliance review.

26. Virtual IBANs Can Increase Money Mule Risk

Virtual IBAN technology can make payment collection extremely efficient.

The same efficiency can be abused.

Potential risk scenarios include:

• accounts opened for shell companies;
• customers collecting payments for undisclosed third parties;
• fraudulent online sellers;
• investment scams;
• illegal gambling;
• money mule networks;
• rapid pass-through transactions.

These do not mean virtual IBANs are inherently suspicious.

They mean transaction monitoring should consider the economic purpose of the account rather than merely whether technical payment limits have been respected.

MASAK’s current sector framework emphasises risk-based monitoring, technological risk and enhanced measures for higher-risk relationships.

27. Incoming Payment Patterns Should Be Monitored

A virtual IBAN system provides useful data for transaction monitoring.

The institution can monitor factors such as:

• number of unique senders;
• transaction frequency;
• average transaction amount;
• geographic origin;
• rapid outgoing transfers;
• refund patterns;
• transactions inconsistent with customer profile.

This information can support detection of both:

• fraud;
• money laundering.

The system should therefore integrate virtual-IBAN reconciliation with compliance monitoring rather than operating the two functions independently.

28. Suspicious Transactions Must Be Escalated

Payment and electronic money institutions have a dedicated MASAK suspicious transaction reporting framework.

MASAK updated its payment/e-money sector reporting guide and reporting infrastructure to reflect modern financial technologies, new account and transaction types and evolving criminal typologies.

Accordingly, a virtual IBAN product should provide compliance personnel with sufficient transaction information to investigate suspicious flows.

Creating millions of payment identifiers without building an effective alert system would create a major AML weakness.

29. Records Must Be Retained

Virtual IBAN systems generate significant evidentiary data.

Law No. 6493 requires payment and electronic money institutions to retain relevant documents and records for at least ten years, securely and in a way that permits immediate access, with the statutory framework also addressing domestic record storage.

MASAK separately requires obliged entities to retain AML-related documents, books, records and identification materials for eight years, calculated according to the applicable starting point.

A virtual IBAN provider should therefore implement its retention schedule based on all applicable regulatory requirements rather than deleting transaction mapping after an ordinary commercial retention period.

30. Virtual IBANs and KVKK

Virtual IBAN products also process substantial personal data.

Depending on the model, this may include:

• customer identity;
• IBAN;
• payer identity;
• transaction history;
• account balance;
• device information;
• fraud indicators;
• beneficial-owner information.

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

The Guide specifically addresses processing conditions, controller/processor roles, transfers, data-controller obligations and data security within payment and electronic money activities.

Virtual IBAN architecture should therefore be reviewed simultaneously under payment regulation and KVKK.

31. An IBAN Is Personal Data When Linked to an Individual

Where an IBAN can be connected to an identified or identifiable natural person, it forms part of the customer’s financial information environment.

Accordingly, payment companies should avoid unnecessary disclosure of customer IBAN and transaction data.

Access controls should follow roles and legitimate operational needs.

For example, a customer-support employee may require access to:

• transaction status;
• payment reference.

That does not automatically mean the employee needs unrestricted access to:

• full KYC documentation;
• unrelated account activity;
• AML investigation notes.

The 2026 KVKK sector guidance emphasises appropriate processing and data-security practices across the payment sector.

32. Cross-Border Virtual IBAN Products Require Extra Analysis

Virtual IBAN services are widely used in international fintech.

A foreign business may seek:

• a Turkish TR IBAN;
• collection of TRY;
• automatic conversion;
• international settlement.

Such products may trigger multiple regulatory questions:

Who is the Turkish payment service provider?

Does the foreign company itself provide regulated payment services in Türkiye?

Where is the payment account located?

Where is personal data processed?

How are funds transferred abroad?

A foreign licence does not automatically create a Turkish payment-services passport.

Where Turkish payment services are provided, the Turkish regulatory perimeter must be analysed separately.

33. A Foreign Fintech Cannot Invent Turkish IBANs

The Turkish IBAN structure includes a payment service provider code determined by the CBRT.

Therefore, a foreign fintech cannot simply generate TR-formatted numbers and market them as Turkish IBANs without a proper regulated account structure.

A legitimate Turkish IBAN should originate within the authorised payment-services infrastructure.

This distinction is especially important for B2B fintech products marketed internationally as:

“Get a local Turkish IBAN instantly.”

The legal provider behind the IBAN should be clearly identified.

34. Virtual IBAN and Embedded Finance

Embedded finance businesses may wish to offer their customers account-like functionality inside a non-financial application.

For example:

Accounting Software Company A offers every SME customer a “business IBAN.”

The legal structure could be:

Software Company A → Licensed Payment Institution B → SME customer.

This may be workable where the payment account and IBAN are legally provided by Institution B and Software Company A genuinely remains within its permitted technical/commercial role.

However, Software Company A should not independently:

• hold customer money;
• provide payment accounts;
• execute transfers

unless it has the required regulatory authority.

The embedded-finance branding should clearly distinguish the technology interface from the licensed financial provider.

35. Virtual IBANs in Marketplace Structures

Marketplaces may also want to allocate a virtual IBAN to every seller.

This can simplify reconciliation enormously.

However, the payment flow must be examined carefully.

Lower Regulatory Risk Model

Buyer pays Seller X through a payment account provided by a licensed PSP.

Marketplace only displays transaction status through an API.

Higher Regulatory Risk Model

Marketplace itself receives buyer funds into pooled accounts, maintains balances for hundreds of sellers and later settles sellers.

The second structure can constitute regulated payment activity depending on the facts and any applicable statutory exceptions.

The marketplace should therefore complete a regulatory-perimeter analysis before launching seller-specific virtual IBANs.

36. Virtual IBANs and Invoice Collection

B2B invoice collection is another major use case.

A company can assign different account references to:

• customers;
• invoices;
• branches.

This allows incoming payments to be matched automatically.

Where the receiving company is collecting only its own receivables, the arrangement is fundamentally different from providing payment accounts to third parties.

The fintech provider can potentially remain a technical provider where it does not own or control transferred funds and the licensed PSP remains the actual financial-service provider. The technical-service exclusion under Article 12(2)(ğ) expressly recognises qualifying technology providers that never become owner of the funds.

37. Can a Virtual IBAN Be Used for Collections From Anyone?

Technically, a customer-specific IBAN may allow incoming transfers from many different senders.

However, from an AML perspective, unrestricted receipt of payments from unrelated third parties increases risk.

The institution should understand the intended account purpose.

A payroll company, marketplace merchant and ordinary consumer do not have the same expected incoming-payment profile.

Virtual IBAN limits and monitoring should therefore be risk based.

38. Customer Name Matching Is Important

A recurring operational risk arises when a sender believes money is being transferred to one person while the regulated account legally belongs to another entity.

Virtual IBAN systems should therefore minimise ambiguity regarding:

• account holder;
• payment beneficiary;
• platform;
• underlying merchant.

Payment flows should not be designed to obscure the person for whom funds are ultimately being received.

This is important both for fraud prevention and MASAK customer-due-diligence purposes.

39. Cybersecurity Is a Core Virtual IBAN Risk

Virtual IBAN systems depend on accurate routing.

A cybersecurity failure could cause:

• funds to be attributed to the wrong customer;
• IBAN substitution;
• fraudulent beneficiary changes;
• unauthorised transfers;
• data leakage.

The CBRT maintains a dedicated Information Systems Communiqué governing payment and electronic money institutions and payment-services data-sharing infrastructure.

Accordingly, regulated virtual IBAN services should include strong controls around:

• API authentication;
• privileged access;
• transaction integrity;
• logging;
• incident response;
• business continuity.

40. Do Not Allow Employees to Manually Change IBAN Mapping Without Controls

A particularly sensitive risk exists where staff can manually change:

virtual IBAN → customer account

mapping.

If such a function exists, an insider could potentially redirect incoming funds.

Appropriate controls should include:

• segregation of duties;
• dual approval;
• audit trails;
• role-based access;
• automatic alerts.

Even where the legislation does not use the expression “virtual IBAN mapping control,” these safeguards follow directly from the need to secure customer funds, information systems and transaction evidence.

41. Open Banking May Become Relevant

Where a virtual IBAN corresponds to a payment account that customers can directly access online, the broader Turkish open-banking framework may also become relevant.

The Turkish payment ecosystem now supports regulated Payment Initiation and Account Information Services, and the CBRT expanded ÖHVPS functionality further in March 2026.

This means a fintech offering customer payment accounts should not design the virtual IBAN product in isolation.

The account may eventually interact with:

• account-information services;
• payment initiation;
• open banking APIs.

The institution’s overall payment-account architecture should therefore be future-proofed for applicable data-sharing requirements.

42. Virtual IBANs and Consumer Protection

Consumer-facing virtual IBAN services should also clearly explain:

• whether the product is a bank account or payment account;
• who the regulated provider is;
• applicable fees;
• transfer rules;
• account closure;
• suspension;
• complaint process.

The wording is particularly important where a fintech brand sits between the customer and the licensed financial institution.

A customer should not be misled into believing that funds are held at a bank in the customer’s own bank deposit account if the legal product is actually a payment account provided by a non-bank institution.

43. Virtual IBANs Do Not Turn a Payment Institution Into a Bank

Receiving an individual TR IBAN can make a payment account look similar to a traditional current account.

Legally, however, a payment institution remains different from a bank.

Law No. 6493 provides that payment institutions can maintain payment accounts only for use in payment transactions and cannot engage in lending activity. Funds received in connection with payment services do not become ordinary bank deposits merely because the customer receives an IBAN.

This distinction should be communicated clearly in customer documentation.

44. Unlicensed Virtual IBAN Services Can Create Criminal Risk

The most serious regulatory risk arises where an unlicensed business effectively provides payment services.

Law No. 6493 Article 28 provides that persons who operate as payment institutions or electronic money institutions without the required permission may face:

one to three years’ imprisonment and judicial fines of up to 5,000 days.

The same Article also addresses creating the impression of operating as an authorised payment or electronic money institution without the required permission.

A startup should therefore not launch a payment-collection account product first and seek regulatory advice only after processing substantial customer funds.

45. CBRT Enforcement Is Active

The regulatory risk is not theoretical.

The CBRT reported that its 2025 supervision of payment and electronic money institutions resulted in:

• 7 licence revocations;
• 14 licence suspensions;
• dividend-distribution restrictions concerning 12 institutions;
• administrative fines totalling approximately TRY 373.2 million across 72 institutions;
• 331 suspected unauthorised-payment-service cases being referred to prosecutors and/or courts.

This makes regulatory-perimeter analysis especially important for fintech companies offering account-like or payment-collection products.

46. Virtual IBAN Due Diligence for Investors

An investor acquiring a Turkish fintech offering virtual IBAN services should examine far more than the product interface.

The regulatory due diligence should establish:

Who Issues the IBAN?

Is it generated by an authorised Turkish payment service provider?

What Account Does It Identify?

Is there a genuine customer payment account or only an internal collection reference?

Licence Scope

Does the regulated provider hold Article 12(a) and other permissions required by the actual service?

Electronic Money

Does incoming money create electronic money?

Master Account

Are funds pooled?

Safeguarding

Can customer funds be reconciled to protected accounts?

Third-Party Funds

Does the fintech collect money on behalf of merchants or unrelated customers?

MASAK

Are business-purpose and transaction-pattern controls effective?

Records

Can every virtual IBAN payment be reconstructed?

KVKK

Is personal and transaction data handled lawfully?

A failure in any of these areas may materially affect the target company’s regulatory risk and valuation.

47. Common Virtual IBAN Compliance Mistakes

Mistake 1: “Virtual IBAN Is Not Mentioned in the Law, So It Is Unregulated”

Incorrect.

The underlying payment account, transfer and fund-holding activities are regulated.

Mistake 2: “Every Customer Reference Can Be Called an IBAN”

Incorrect.

The Turkish IBAN framework defines a specific 26-character account identifier and requires payment service provider codes determined by the CBRT.

Mistake 3: “Only Banks Can Issue IBANs”

No longer correct.

Since the 2021 reforms, qualifying payment service providers can generate IBANs for customer accounts subject to money transfers.

Mistake 4: “A Payment Institution IBAN Is a Bank Deposit Account”

Incorrect.

Payment accounts maintained by payment institutions have a different statutory legal character.

Mistake 5: “The Fintech Is Only a Technology Company Because a Bank Holds the Master Account”

Not necessarily.

The fintech’s actual role in receiving, controlling, allocating and transferring funds determines the payment-services analysis.

Mistake 6: “A Pooled Account Does Not Need Customer-Level Reconciliation”

This creates significant safeguarding, AML and operational risk.

Mistake 7: “A Foreign Fintech Can Generate a TR IBAN Itself”

A genuine Turkish IBAN must operate within the Turkish IBAN/payment service provider structure.

Mistake 8: “Virtual IBAN and KOLAS Are the Same”

They are different concepts. KOLAS is an alias-based FAST service allowing payments without entering the IBAN.

Practical Virtual IBAN Compliance Checklist for Turkey

Before launching a virtual IBAN product in Türkiye, management should answer the following questions.

What Is the Legal Product?

Is it a payment account, electronic money account or technical reconciliation service?

Who Is the Payment Service Provider?

Bank, payment institution, electronic money institution or PTT?

Is the IBAN Genuine?

Does it comply with the Turkish IBAN structure?

Whose Account Does It Identify?

Customer-specific account or pooled master account?

Does the Customer Have a Legal Balance?

How is that balance recorded?

Is Article 12(a) Permission Required?

Is the provider operating a payment account?

Is Article 12(b) Permission Required?

Can customers transfer funds?

Is Electronic Money Issued?

Does incoming value create an e-money balance?

Who Owns the Funds?

Customer, merchant, platform or PSP?

Are Third-Party Funds Collected?

Does the fintech receive payments belonging to others?

Does the Technical-Provider Exclusion Apply?

Does the technology company avoid ownership and control of funds?

Safeguarding

Can every incoming amount be matched to the relevant customer?

MASAK

Has each customer’s expected account use been documented?

Transaction Monitoring

Can unusual incoming and outgoing flows be detected?

Record Retention

Can IBAN mapping and transaction history be reproduced years later?

KVKK

Are payer, customer and transaction data processed lawfully?

Cybersecurity

Can virtual-account mappings be modified only through controlled and auditable procedures?

Customer Disclosure

Does the user know whether the account is a bank account, payment account or e-money product?

Frequently Asked Questions About Virtual IBANs in Turkey

Are virtual IBANs legal in Turkey?

A properly structured customer-specific IBAN or virtual-account model can be lawful. However, “virtual IBAN” is not itself a separate licence category. The underlying account and payment activities determine the regulatory requirements.

Is there a Virtual IBAN Licence in Turkey?

No separate licence with that name exists under Law No. 6493. A provider may instead require payment institution, electronic money institution or banking authority depending on the product.

Can payment institutions issue Turkish IBANs?

Yes. The 2021 reform extended the IBAN framework to payment service providers and allowed non-bank payment providers to generate IBANs for money-transfer customer accounts.

What does a Turkish IBAN look like?

The Turkish IBAN structure uses 26 characters, including the TR country code, check digits, a five-digit payment service provider code, a reserved field and the account-number field.

Can a payment institution give every customer an IBAN?

Where it uses IBAN as the account structure for customer accounts subject to transfers, the CBRT has stated that compliant IBANs should be generated for each such customer account and used in transfers and relevant documentation.

Is a virtual IBAN the same as a bank account?

Not necessarily.

It may correspond to a payment account provided by a non-bank payment institution, an electronic money account or merely a technical collection reference.

Can a fintech collect payments into one master IBAN and allocate them to customers?

Potentially, but the legal structure requires careful analysis. If the fintech effectively holds and transfers money for third parties, payment-services licensing and safeguarding obligations may arise.

Can a SaaS company provide virtual IBAN technology without a licence?

Potentially, where it remains a genuine technical provider and never becomes owner of transferred funds. Law No. 6493 expressly excludes qualifying technical services from payment services under Article 12(2)(ğ).

Is KOLAS a virtual IBAN?

No. KOLAS allows existing accounts to be addressed using information such as telephone number, email or identification number instead of entering an IBAN.

Does a virtual IBAN provider need MASAK compliance?

Where the provider is a payment or electronic money institution, extensive MASAK customer-due-diligence, monitoring and suspicious transaction obligations apply.

How long must payment records be retained?

Law No. 6493 requires relevant records of payment and electronic money institutions to be retained for at least ten years. MASAK separately applies an eight-year retention framework to AML-related records.

What are the 2026 minimum own-funds requirements?

From 30 June 2026, the relevant minimum is TRY 40 million for the ordinary payment institution category and TRY 105 million for electronic money institutions, subject to the detailed regulatory calculations and separately treated categories.

Can a foreign fintech provide Turkish virtual IBANs?

A foreign company cannot assume that its overseas licence automatically authorises Turkish payment-account services. The Turkish account must be provided through an appropriately authorised Turkish payment service structure.

Does KVKK apply to virtual IBAN information?

Yes. Customer, payment and transaction information is subject to Turkish personal data protection requirements where it relates to identified or identifiable natural persons. The KVKK Authority issued dedicated payment/e-money sector guidance in July 2026.

Conclusion: How Should a Virtual IBAN Business Be Structured in Turkey?

Virtual IBAN regulation in Turkey should not be approached by searching for a specific statute containing the words “virtual IBAN.”

The key legal issue is the financial function performed behind the number.

Turkish law already regulates:

• payment accounts;
• money transfers;
• payment service providers;
• electronic money;
• IBAN generation.

The modern virtual IBAN business model therefore sits inside this existing regulatory framework.

The first important development occurred in 2021, when the CBRT expanded the Turkish IBAN regime beyond conventional banks.

Payment and electronic money institutions were enabled to generate IBANs for customer accounts used for money transfers.

This change provides a clear legal basis for modern fintech payment-account products to participate more directly in IBAN-based transfers.

The CBRT went further in its guidance to the sector.

Payment and electronic money institutions that choose an IBAN-based account structure are required to generate a compliant IBAN for each customer account subject to money transfer, use that IBAN in transfers and display it in relevant documentation.

For fintech companies, this means a genuine customer IBAN is not merely a user-interface feature.

It forms part of the regulated account architecture.

The next question is therefore:

What legal account sits behind the IBAN?

If the customer has a payment account maintained by an authorised payment institution, Article 12(a) becomes directly relevant.

Where the customer can transfer funds from that account, Article 12(b) is also relevant.

Where the balance constitutes electronic money, electronic money authority must be considered separately.

This is why a virtual IBAN product should never be designed without a complete money-flow diagram.

The diagram should show:

payer → IBAN → regulated account → internal ledger → customer balance → outgoing transfer.

Every step should have a legally identified actor.

The same principle applies to master-account models.

Pooling funds is not automatically prohibited merely because customer-specific technical references are used.

But the institution must be able to demonstrate whose money is held and why.

A fintech that receives TRY 100 million into an omnibus account but cannot reliably reconcile that amount to the underlying customers creates obvious problems concerning:

• safeguarding;
• AML;
• disputes;
• insolvency.

Virtual IBAN technology should therefore improve regulatory traceability rather than reduce it.

For unlicensed technology companies, the distinction between technical infrastructure and payment service is particularly important.

Turkish law expressly excludes genuine technical service providers that support payment transactions but never become owner of transferred funds.

This creates a legitimate model for fintech software companies.

A provider can potentially build:

• IBAN allocation technology;
• reconciliation software;
• payment APIs;
• merchant dashboards,

while a bank or licensed payment institution provides the regulated account.

This model is fundamentally different from a fintech receiving and redistributing customer money itself.

The correct structuring principle is:

Technology can be outsourced; regulatory responsibility cannot be invented away.

The virtual IBAN model also creates significant AML exposure.

MASAK requires obliged institutions to know customers and persons for whose name or account transactions are conducted.

This becomes especially important where a business customer receives payments from hundreds or thousands of unrelated senders.

The institution should understand whether those payments are consistent with the customer’s declared activity.

A virtual IBAN should not become an invisible payment collection channel for:

• undisclosed third parties;
• fake merchants;
• scams;
• money mules.

Transaction monitoring should therefore analyse both incoming and outgoing patterns.

MASAK’s sector-specific payment/e-money suspicious transaction framework has been updated specifically to account for modern fintech account and transaction types.

This is particularly useful for virtual-account systems because their detailed reconciliation data can improve compliance monitoring.

Data protection is another important layer.

In July 2026, the Personal Data Protection Authority and TÖDEB published dedicated sector guidance covering payment and electronic money companies, including data processing, transfers and data security.

A virtual IBAN provider can process information concerning:

• customers;
• payers;
• beneficiaries;
• transaction histories;
• balances;
• fraud.

Those data flows should be mapped alongside the payment flows.

The regulatory financial burden should also be considered before launch.

From 30 June 2026, the minimum own-funds requirement for the ordinary payment institution category is TRY 40 million, while an electronic money institution is subject to a TRY 105 million minimum.

Consequently, the choice between:

technical virtual IBAN provider

and

regulated customer-account provider

has a very significant economic impact.

The former may be capable of operating as a SaaS or infrastructure company where the technical-service exclusion genuinely applies.

The latter requires the capital, governance, risk management, information systems and regulatory infrastructure of a financial institution.

For marketplaces and platforms, a further distinction is essential.

Collecting a company’s own receivables through invoice-specific virtual identifiers is not the same as accepting and redistributing payments for independent merchants.

Once a platform receives funds economically belonging to third parties, the payment-services analysis becomes much more significant.

Foreign fintech companies should take the same approach.

A company that offers virtual IBANs in Europe or the United Kingdom should not simply add a “TR IBAN” option to its product.

A Turkish IBAN contains a payment service provider code determined within the Turkish regulatory system.

The foreign fintech should determine:

which Turkish regulated provider generates the IBAN, which entity maintains the account, who safeguards the money and who is contractually responsible to the customer.

Finally, regulatory enforcement should be treated seriously.

The CBRT’s latest published annual enforcement results show active licence revocations, suspensions, major administrative fines and hundreds of suspected unauthorised payment-service cases referred to judicial authorities.

Law No. 6493 also makes unauthorised payment-institution activity a criminal offence.

The recommended legal sequence for a virtual IBAN project is therefore:

define the business model → determine what the IBAN identifies → identify the legal account holder → map the flow of funds → determine payment/e-money licence requirements → separate technical and regulated roles → structure safeguarding → implement MASAK/KYC → establish customer-level reconciliation → address KVKK and cybersecurity → verify IBAN compliance → launch only within the authorised framework.

The central legal principle can be stated simply:

A virtual IBAN is not a regulatory shortcut. The law follows the account and the money behind the IBAN.

Where the number merely helps reconcile a company’s own payments, the model may remain predominantly technical.

Where it gives customers payment accounts, receives third-party funds and enables transfers, it moves directly into the Turkish payment-services regulatory perimeter.

For fintech founders, marketplaces, payment companies and foreign investors, understanding that distinction before launch is essential to building a sustainable virtual IBAN business in Türkiye.

Legal Disclaimer: This publication provides general information concerning virtual IBAN, payment accounts and fintech regulation in Türkiye as of July 2026. It does not constitute legal, financial, tax or regulatory advice. “Virtual IBAN” is a commercial expression and the legal classification of each model depends on the actual account structure, flow of funds, customer relationship, payment-service provider, electronic-money functionality and technical architecture. Each virtual IBAN project should therefore be individually reviewed under Law No. 6493, the IBAN Communiqué, the current CBRT Payment Services Regulation, MASAK legislation and KVKK before launch.