Horizon research dossier · Türkiye · Financial and professional services · reviewed 2026-10-11
Türkiye payments and open banking: a full decision dossier for a defined regulated workflow proposition
Decision question: Under what evidence conditions should a payments, fintech, merchant-services, data, software or financial-services proposition progress from Türkiye’s public ecosystem context to a named lawful and commercially controlled workflow?
Verified facts
Central Bank material establishes a regulated payment-services framework and enhanced open-banking service features; association, multilateral and macro sources provide context. None establishes an individual provider’s licence, API access, sponsor relationship, merchant relationship, customer demand or contract.
Horizon view
The relevant entry unit is a single classified workflow with separately evidenced money, data and authority paths; not a generic claim about Türkiye’s fintech ecosystem.
Commercial implication
Advance only through an activity-specific, authorised and bounded proof after confirming regulatory role, customer need, access route, settlement model, data/security controls, delivery ownership and economics.
Dossier sequence
01
1. Decision scope and non-claim boundary
This dossier is a research instrument for one defined Türkiye payments, fintech, merchant-services, data, software or financial-services workflow. It does not assess the entire financial sector, recommend a bank or payment institution, clear a licence, validate a technical interface or promise a customer route. The working brief must name the product, customer segment, use case, participant role, intended money and data flows, commercial objective, delivery model, decision owner and reason for choosing Türkiye. Account information, payment initiation, merchant collection, wallet support, e-money, fraud tooling, treasury, reconciliation and analytics are not interchangeable activities. Each may involve different permissions, contracts, controls and counterparties. The central decision is whether a named workflow can be investigated responsibly with named accountable parties. Until those elements are defined, the item should remain a monitored ecosystem note rather than become a sales assertion, partner claim or market-entry commitment.
02
2. What the dated public evidence establishes
The Central Bank of the Republic of Türkiye describes the payment-services framework and has published material on enhanced open-banking services. The Banks Association offers institutional context on technology and payment systems. World Bank, IMF, EBRD and OECD material adds financial-inclusion, macroeconomic, private-sector and digital-governance context. These sources support a disciplined research question: which specific regulated or non-regulated workflow is being proposed, for whom and through which authorised operating route? They do not establish participant eligibility, a commercial interface, production access, sponsor arrangement, customer consent implementation, merchant acquisition, fee schedule or contract. Preserve the original source, date, precise statement and scope. Distinguish law, regulatory framework, service feature, public statistic, association context, provider claim, supplier quotation and internal assumption. A national feature announcement must never be silently converted into a claim that a particular external provider can use it.
03
3. Classify the activity before selecting a route
The first gate is functional classification. Record exactly what the external provider does and does not do: software supply, implementation, account-information support, payment initiation support, merchant-service support, analytics, fraud tooling, identity workflow, customer interface, treasury workflow or another service. Identify who receives instructions, holds credentials, holds or controls funds, contracts with the customer, sends or receives payment messages, performs screening, resolves exceptions and owns the regulated function. The inquiry requires current professional confirmation because terminology and operating facts matter. A product label, a generic fintech classification or a prospective partner’s opinion is insufficient. The output should be a role matrix with each activity, possible legal/operator role, current evidence source, unresolved question, accountable reviewer and stop condition. If a proposition cannot be described without assuming that an authorised institution will sponsor, connect or operate it, that assumption must be treated as unverified rather than built into the commercial plan.
04
4. Map money, data and authority separately
A payment proposition is not decision-ready until three maps exist. The money map identifies payer, payee, merchant, account or instrument, issuer/acquirer or other authorised participant, clearing, settlement, refund, chargeback, reconciliation and exception route. The data map identifies customer, transaction and credential data; purpose, authorised basis or consent pathway, interface, hosting, retention, access, security controls, incident route and deletion/exit process. The authority map identifies economic buyer, user, legal signatory, technical owner, compliance owner, security owner and the party that can approve a connection. These maps must not be merged: an organisation may be a commercial buyer without authority to approve data access, or an authorised participant without a budget or implementation owner. Public infrastructure context does not complete any map. For each arrow, record its source, confidence level, owner and the written proof needed before an external representation, pilot or production configuration.
05
5. Access, consent and data-security gate
A public framework or feature does not create an access right. Before any account, payment, customer, transaction or credential data is requested, determine the relevant data categories, controller/processor or contractual roles, purpose limitation, customer notice or consent mechanism where applicable, authorisation, integration method, environments, hosting, retention, support access, logging, encryption, incident escalation, subcontractor position and exit/delete process. Do not treat a demonstration, sandbox, meeting, referral or association membership as production access. The proof file should identify which facts are established by the authoritative participant, which require specialist assessment and which are simply unknown. Use synthetic or non-production information unless a lawful, documented production arrangement is in place. The Review corpus itself must contain no customer or personal data. No product claim should state that it is compliant, secure, connected or authorised unless that claim can be bounded to current evidence and the defined service scope.
06
6. Define demand as an operating problem
Country-level usage, inclusion or digital-economy indicators can support segmentation; they cannot identify a buyer who has a budget, authority and implementation capacity. The commercial question is practical: what named operating problem is being solved; reconciliation, collection, recurring payment, merchant onboarding, fraud handling, reporting, cash visibility, customer service, workflow automation or another defined need? For each buyer hypothesis, document the current process, pain point, volume or workload, existing alternative, measurable cost or risk, decision cycle, procurement path, security/compliance review, integration dependencies, success metric and reason for action now. Negative evidence matters: an incumbent contract, unavailable data, unsuitable volume, absent budget, non-aligned priority or unwillingness to change is a valid reason to stop. A conference contact, introduction or expression of interest is a research lead, not evidence of customer demand, authority, a commercial route or a transaction.
07
7. Customer, merchant and institutional diligence
A proposed customer, merchant, bank, payment institution, acquirer, implementation firm, reseller or adviser should be assessed as a distinct operating entity. Confirm legal identity, ownership and control, signatory authority, actual role in the intended workflow, relevant authorisations or regulated relationships, technical capability, security posture, financial/payment capacity, conflicts, subcontracting, support coverage, reference relevance, sanctions/integrity escalation and exit cooperation. Public visibility, a website or participation in an industry body does not prove any of these points. The diligence record should identify the source, date, confidence, reviewer and open issue for each material statement. Do not present an entity as a Horizon-approved partner or represent its customer/merchant access unless that relationship is expressly authorised and independently sufficient for the described scope. Where information cannot be verified, reduce the commitment, use a controlled clarification step or hold the case. A commercial relationship should never be inferred from an ecosystem map.
08
8. Settlement, economics and customer exposure
Build a labelled economics model before marketing a payment-related workflow. Include implementation and integration, onboarding, recurring fees, transaction or processing fees where relevant, customer support, local delivery, partner margin, reserves, payment timing, reconciliation, refund/chargeback or dispute exposure, fraud loss, compliance support, insurance, currency, taxes, working capital, termination and service-credit assumptions. Identify who bears each cost, loss and timing risk. Mark every number as a public benchmark, provider quotation, customer indication, contract term or internal scenario; do not present planning assumptions as market facts. Test base and adverse cases, including delayed integration, lower volume, higher support use, disputed transactions, late collection, currency movement and a failed counterparty handover. A positive user interview does not make the economics viable. Likewise, a published payment statistic does not identify the cost of acquiring, serving, reconciling or supporting a defined customer.
09
9. Local delivery and operating-responsibility model
The delivery model must allocate responsibility, not merely name a local contact. Compare direct remote delivery, authorised institutional collaboration, reseller, systems integrator, locally incorporated team or a hybrid approach. For the selected model, map lead generation, marketing approval, contracting, invoicing, onboarding, implementation, interface management, first-line support, escalation, reconciliation assistance, security coordination, compliance liaison, language coverage, reporting, renewal, termination and incident response. Each responsibility needs a named owner, capability evidence, cost basis and hand-off rule. A referral chain cannot carry an undefined support, payment or security burden. The model should define service hours, support-language capacity, training, documentation, staffing continuity, subcontractor control and how access or customer materials are returned or revoked at exit. If a local party is expected to perform regulated or customer-facing functions, do not presume eligibility: require specific confirmation from the appropriate responsible party and specialist advice. The operating matrix is a precondition for a credible price and pilot design.
10
10. Controlled proof or proof-of-value design
The first serious engagement should test one material uncertainty, not launch a payment product. A valid proof has a named customer or authorised route, defined role, authorised environment, data boundary, test or production boundary, security controls, transaction or simulation limits, timeline, cost owner, success measures, evidence retention, incident and escalation process, communications restriction and stop condition. It should distinguish a product demonstration, sandbox evaluation, paid discovery, technical proof, procurement evaluation and production pilot because these have different legal, financial and operational consequences. Prefer synthetic or non-production data unless the relevant parties document a lawful production arrangement. A successful demonstration does not establish a licence, bank sponsorship, API right, merchant availability, regulatory acceptance or contract. Close the proof with a factual record: what was tested, what evidence was obtained, exceptions, cost, failure points, customer decision and whether any bounded next step is justified.
11
11. Procurement, contracting and communications discipline
Before a proposal, clarify the customer’s contracting party, sourcing route, qualification conditions, language, approval authority, security and data review, commercial evaluation, payment terms, acceptance test, service levels, IP, confidentiality, liability, audit, subcontracting, termination, dispute route and renewal logic. For regulated institutions or public buyers, procurement and compliance may be a separate workstream from sales discovery. A relationship with an employee, adviser or technical team does not establish an authorised contract path. Maintain a prohibited-claims list: do not state that Horizon or a provider is licensed, connected, sponsored, approved, compliant, partnered, able to process payments or able to access data unless the relevant scope is explicitly evidenced. External communication should describe only verified facts and a clearly bounded proposition. A memorandum, meeting or verbal intention is not a procurement outcome or contractual permission to build, connect, market or operate.
12
12. Regulatory, financial-crime and consumer-protection escalation
The dossier does not give regulatory, AML/CFT, sanctions, tax, consumer-protection, advertising, data or cybersecurity advice. It requires an escalation matrix. For each relevant issue, record the activity, factual trigger, prospective responsible party, authoritative source or professional adviser, confirmation date, decision needed, contract impact and hold condition. Financial products and payment workflows may create obligations that do not arise in ordinary software sales, especially where money movement, credential handling, onboarding, customer communications, transaction monitoring, complaints, marketing or cross-border functions are involved. The correct response to ambiguity is not a broad disclaimer after launch; it is a pause until the defined activity and responsibilities are assessed by those authorised and qualified to do so. Preserve the evidence of that assessment in the transaction file. No commercial timeline, partner promise or event opportunity should override an unresolved material compliance or customer-harm issue.
13
13. Risk register and stopping conditions
Key risks include misclassification of the activity, unauthorised data or interface assumptions, failed consent/customer journey, settlement or reconciliation failure, fraud or dispute exposure, security incident, weak counterparty diligence, unsuitable local delivery, unpriced support, non-payment, currency/tax exposure, customer concentration, overstatement of regulatory position, conflicted partner incentives and unclear contractual liability. Each risk requires a source, owner, mitigation, residual exposure, early warning and explicit stop trigger. Stop before taking production data, moving money, making public claims, granting exclusivity, spending beyond a stated discovery cap, quoting binding terms, integrating systems or signing a contract if role, authority, access, security, settlement, customer need, economics or delivery ownership remains unproven. A documented hold is a positive research outcome when it prevents a poorly governed commitment. The risk file should state who can stop work, who receives incident reports and which evidence would permit resumption.
14
14. Decision sequencing and evidence expiry
Sequence the work in a controlled order: define offer and use case; classify activity and map money/data/authority; identify a named buyer or authorised route; confirm access, security and regulatory questions; test diligence, delivery and economics; authorise a bounded proof; then consider a contract or implementation. Do not reverse the sequence because public infrastructure, an industry event or a persuasive partner presentation creates urgency. Set expiry dates for source material, customer statements, technical assumptions, access conditions, counterparty facts, economic estimates and any professional advice. Reopen the case if the product, country delivery model, customer, regulated role, funding/payment path, data category, security architecture, contractual party or commercial purpose changes. The dossier must retain the older evidence alongside the newer evidence and explain the change. This is a living decision record, not a permanent statement that a national market is ready.
15
15. Final decision gate
Advance only when one precise workflow is linked to a named customer or documented authorised route; the external provider’s role is classified; money, data and authority maps are complete enough for the proposed step; access and security are evidenced; settlement and economics are viable; delivery and support have accountable owners; material regulatory questions have been escalated; and a controlled proof or contract path is defined. The decision record must visibly separate verified facts, Horizon inference and commercial implication; name missing evidence, source expiry, accountable approver, permitted spend, prohibited actions and re-review date. A go authorises only the stated clarification, proof, proposal or negotiation. It does not approve a licence, payment institution, bank relationship, API access, merchant route, customer, data transfer, settlement, contract or transaction. If the evidence remains at policy, platform, ecosystem, event or general statistics level, the correct outcome is a monitored evidence request rather than an opportunity claim. This dossier cannot replace specialist legal, regulatory, financial, security, tax, insurance, procurement or investment approval.
What to verify before acting
This completed research dossier is not Türkiye legal, banking, payments, open-banking, AML/CFT, data-protection, cybersecurity, consumer-protection, tax, sanctions, insurance, procurement, investment or financial advice. It does not approve a regulated activity, licence, provider, bank, payment institution, merchant, interface, data transfer, settlement, customer, contract or transaction.
Current market intelligence
Signals connected to this dossier
11 October 2026
World Bank documents more than USD 21 billion of private capital mobilised in Türkiye since 2022
For a Türkiye financing case, identify the exact programme, participating financial intermediary, borrower and use of proceeds; confirm eligibility, tenor, collateral, currency, pricing and environmental or social conditions; and separate any supplier opportunity from the financing itself. For Antalya-linked opportunities, verify the operator, project phase, package owner, procurement route, technical scope and commercial timetable before treating the investment figures as addressable demand.
12 October 2026
TIF and BSTDB establish a framework for joint project preparation and financing
Companies and sponsors should prepare a financing-ready project note rather than a generic expression of interest: country and asset, sponsor and ownership, total cost and requested instrument, use of proceeds, revenue and repayment source, permits and land, procurement status, environmental and social position, local delivery model and evidence of additionality. Confirm whether TIF, BSTDB or a financial intermediary is the appropriate first counterpart.
15 October 2026
Türkiye’s services output grows 2.3%, led by information and communication
Digital, logistics, hospitality, property and professional-services firms should compare the official index with customer-specific indicators: buyer revenues and investment, procurement cycles, sector regulation, locations, pricing and channel conditions. Treat the index as a screening signal and validate with named counterparties before committing sales resources.
Relationship platforms