One-line takeaway: In Turkey, cross-border cooperation scope creep—where a “simple partnership” with a foreign payments/fintech partner slowly morphs into full payment intermediation—can trigger unlicensed activity risk under Law 6493, unless you secure the right CBRT approvals/notifications and keep the Turkish-licensed entity in the driver’s seat.
Why this matters (for founders, GCs, and investors)
Teams often begin with harmless-sounding pilots: a foreign PSP “just hosts a widget,” a group entity “only offers analytics,” or an overseas wallet “only settles cross-border refunds.” A quarter later, data and funds routes have changed, customer support scripts imply the foreign party is the real provider, and the product now looks like payment services—but the license sits with the Turkish entity. That drift is cross-border cooperation scope creep. In Turkey, it can look like unlicensed payment activity, create CBRT exposure, and spook banks and card schemes during diligence.
Symptoms to watch: the foreign partner touching Turkish consumer funds, instructing flows, holding escrow-like balances, marketing to Turkish users as “the provider,” or operating critical back-office processes without your oversight.
Quick legal frame
- Law No. 6493 defines and reserves payment services and e-money issuance to licensed providers. “Representatives” and “outsourcing” are allowed, but the licensed Turkish entity stays fully responsible for compliance, safeguarding, disclosures, and consumer redress.
- CBRT (TCMB) supervises and expects clear roles, auditable outsourcing and representation agreements, and (depending on the function) prior approval or notification—especially when cross-border parties are in the critical path.
- If cross-border cooperation scope creep results in a foreign party providing or intermediating payment services into Turkey without the proper structure, you face unlicensed activity risk, potential administrative measures, and banking partner pushback.
- Consumer-protection and AML overlays (6502 / 5549 MASAK) still apply; in practice, CBRT will ask “who is the provider of record?” and “can Turkish users get redress in Turkish law?”
Bottom line: Cross-border help is fine. Cross-border provision is not—unless architected through a compliant 6493 structure with the Turkish licensee in charge.
How scope creep happens in real life (five patterns)
- Widget becomes provider: You embed a foreign checkout widget “for FX quotes only.” Soon it collects PII, captures PAN/IBAN, and directs settlement. Users think they paid the foreign PSP.
- Back-office takeover: Foreign group company runs chargebacks, reconciliations, or payout instructions “temporarily.” Over time, it gives binding instructions to banks.
- Refunds and wallets: To “simplify cross-border refunds,” an overseas wallet starts holding balances for Turkish users—effectively e-money without a Turkish license.
- Messaging drift: Sales/CS scripts and email templates say “Your payment was processed by [ForeignCo],” undermining the Turkish licensee’s role and disclosures.
- Data → funds slippage: Data integration begets fund flows: after getting read access, the foreign partner starts to initiate or sequence payouts.
Each step feels operational. Together, they equal provision of payment services—and trigger unlicensed activity risk.
What CBRT looks for (simple, actionable checklist)
- Provider of record: Is the Turkish licensee clearly the provider in all UX, contracts, and receipts?
- Funds flow: Do Turkish-held customer funds touch only bank accounts/escrows that meet safeguarding rules and sit under Turkish control?
- Outsourcing & representatives: Are cross-border roles defined in written agreements, with scope, SLAs, audit rights, sub-outsourcing controls, and exit/step-in?
- Approvals/notifications: For critical functions (e.g., core processing, settlement file creation, ledger ops), has the licensee made the necessary CBRT notification or sought approval where required?
- Consumer redress: Can a Turkish user get refunds, complaints handling, and dispute resolution in Turkish law, without chasing a foreign entity?
- Data control: Is customer/transaction data access purpose-limited and supervised by the Turkish entity, with logs and DPIAs?
If any box is a “no,” you’re drifting into cross-border cooperation scope creep.
The architecture that keeps you safe
1) Provider-of-record model (POR)
- The Turkish PI/EMI is the provider in all public-facing materials, ToS, and receipts.
- Foreign affiliates/vendors are outsourcers or technical service providers under 6493-compliant agreements.
- Bank accounts for safeguarding, settlement, and redemption are in the Turkish entity’s control; no cross-pledge or set-off.
2) Two-lane flow separation
- Data lane: Cross-border vendors may process analytics, fraud scoring, or UX services under strict purpose limits.
- Funds lane: Only the Turkish licensee (and its Turkish banks/escrows) initiate or instruct fund movements for Turkish users/merchants.
3) Approval/notification hygiene
- Map functions to CBRT expectations: critical functions (core ledger, transaction processing, settlement file generation) usually need prior approval or notification; keep evidence.
- Maintain a register of all cross-border processors/representatives with scope, location, SLAs, DPAs, and last audit date.
4) Step-in and exit
- Contracts must give the Turkish licensee step-in rights to take over systems or switch providers on regulator instruction—without downtime.
Contract playbook (short, copy-ready clauses)
Provider of Record. The Parties acknowledge that [Turkish Licensee] is the sole provider of payment/e-money services in Türkiye under Law 6493. Foreign Service Provider acts exclusively as an outsourcer/technical service provider and shall not hold itself out as a payment provider to Turkish users.
Scope & Prohibitions. Foreign Service Provider shall not (i) accept or hold user funds, (ii) instruct or authorize fund transfers, (iii) issue e-money, or (iv) market to Turkish users as a payment provider, except as expressly permitted by [Turkish Licensee] and applicable law.
CBRT Approvals/Notifications. Services subject to CBRT approval/notification shall not commence until [Turkish Licensee] confirms completion of the required regulatory step. Foreign Service Provider shall furnish documents and cooperate with supervisory requests.
Audit & Data Controls. [Turkish Licensee] retains audit rights (on-site/remote), access to logs, and approval over sub-processors. Data use is purpose-limited, with retention and deletion aligned to Turkish law.
Step-In/Termination. Upon regulatory request or material breach, [Turkish Licensee] may step in to operate or transition the Services; Foreign Service Provider shall provide all tools, keys, and documentation necessary for continuity.
Operating guardrails (so scope creep can’t sneak in)
- RACI matrix: For every step (KYC, auth, capture, clearing, settlement, refunds), define Responsible = Turkish licensee; foreign party = Consulted or Performer under licensee’s instruction.
- Receipt test: All receipts, statements, and support emails must show the Turkish licensee’s name, address, and complaint channel.
- Funds flow review: Quarterly walk-through with Legal/Finance: trace a TRY 10 transaction end-to-end; update diagrams and sign off.
- Change control: Any change touching funds (file formats, signers, payout rules) needs Compliance + Legal + Ops approval and, if applicable, CBRT notification before go-live.
- Sub-outsourcing veto: No foreign vendor may appoint a sub-vendor for critical tasks without written consent and due diligence by the Turkish entity.
- Red team: Try to buy/sell as a Turkish user/merchant and see who the UX says the provider is. If it names the foreign party, fix immediately.
Common problem areas (and compliant alternatives)
- Foreign PSP wants to “settle Turkish merchants cross-border” → Not allowed as a de facto provider. Alternative: Turkish licensee acquires/settles domestically; foreign PSP can offer FX quote/analytics off-flow.
- Group company runs the ledger → Likely critical; seek CBRT approval/notification, maintain full control and real-time transparency, and be ready to step in.
- Overseas wallet holds Turkish user balances → E-money risk. Keep balances under the Turkish EMI’s safeguarded accounts; foreign party can do front-end UI only.
- Marketing names foreign brand as processor → Rephrase to “Technology provided by [ForeignCo]; payment services provided by [Turkish Licensee].”
Evidence pack for regulators, banks, and buyers
- Architecture diagrams (data vs. funds lanes), updated within last quarter.
- Contracts with cross-border parties: POR clause, scope limits, audit, step-in, sub-outsourcing controls.
- CBRT file: list of functions with approval/notification status; copies of correspondence.
- Receipts & UX captures showing Turkish licensee as provider.
- Runbook for step-in/exit; results of last failover drill.
- Monitoring logs: who initiated settlement files, who had signing authority, and where keys live.
A tidy evidence pack defuses “unlicensed activity” worries in weeks that would otherwise take months.
Board-level FAQs
Q: Can our foreign affiliate “temporarily” handle refunds?
A: Only if the Turkish licensee remains the instructing party and funds move through licensed accounts. Otherwise it’s scope creep.
Q: Do we always need CBRT approval?
A: Not for every vendor—but critical functions and representative arrangements often require approval/notification. Map each function and keep proof.
Q: What breaks deals?
A: Receipts naming the foreign party as provider; foreign-controlled funds accounts; no step-in rights; missing CBRT paper trail.
Conclusion
In Turkey, cross-border cooperation scope creep is a silent deal-killer: a partner starts as a helper and slowly becomes the provider. That’s unlicensed activity risk under Law 6493 unless you anchor the Turkish licensee as provider-of-record, separate data from funds, secure any CBRT approvals/notifications, and hard-wire audit and step-in rights. Do this, and cross-border cooperation scope creep turns from a regulatory hazard into a scalable, defensible operating model.
Yanıt yok