Quick answer: Launching SMS into Turkey on Devotel Orbit means two parallel regimes, not one. KVKK (Law No. 6698) governs who processes personal data and where it can move; BTK (Regulation 6/A) governs which sender identities are legal. The pairs that trip teams most often: a sender ID prefixed GOV, BANK, SGK, MEB, or DEVLET returns restricted_prefix before anything queues; Turkish opt-outs like DUR, İPTAL, and ÇIKIŞ hit the alias table; and a doc_… upload is what makes a Turkey entry on your sender-ID registration carryable. This walks KVKK vs GDPR in scope, the prefix list with the exact strict-mode error, the registration and checklist flow on Orbit, the keyword family, and how residency and SMS-call recording land for a TR destination.
Everything below is a tenant-owned onboarding playbook, not legal advice and not a delivery guarantee. Final approval sits with the KVKK-registered controller and the BTK registry in each market; coverage is enabled per tenant, so a country listed here is not necessarily enabled on your account.
KVKK vs GDPR: the scope that decides the clause
KVKK applies to natural and legal persons processing personal data, the same way GDPR does on paper — but the first-class difference is that KVKK does not give the GDPR exemptions (public interest, journalistic purpose) their blanket pass. The carve-outs are narrower, so treat any inbound Turkish list as in-scope until proven otherwise.
Who is a controller. The natural or legal person who determines the purpose and means of processing is the data controller (veri sorumlusu), and that duty travels with the brand. Orbit is the processor at the messaging layer; your Turkish program's KVKK Article 11 duty (inform the data subject, name the contact for requests) sits with the controller entity, registered on VERBİS (the Data Controllers Registry) where required. Orbit carries the KYC evidence; Turkey-KVKK posture is a tenant-owned control statement, a control you set up yourself.
Two GDPR myths to retire early.
- Article 27 representative. If your entity incorporated outside Turkey and processes Turkish residents' data, KVKK's VERBİS regime requires a Turkish-based point of registration (a foreign-entity representative), not just a GDPR Article 27 EU representative. The titles look the same; the jurisdiction does not.
- Cross-border transfer. KVKK Article 8/1a-b is a closed list — adequacy decisions, explicit consent, or a signed undertaking approved by the KVKK Board. There is no SCC-analogue blanket clause. A transfer that clears under GDPR still misses Turkey if the Board filing was skipped; the DPIA you run for the route must name both regimes.
BTK sender rules: GOV / BANK / SGK prefixes and the restricted_prefix error
BTK Regulation 6/A reserves the government and public-institution namespace. Turkish operators additionally pre-filter BANK* to stop bank-impersonation fraud, which is a charged matter in the market. Orbit's strict sender-ID mode reads the same list at the destination layer, and the per-country rules endpoint returns it as a structured row.
The reserved prefix set (from the BTK 6/A list plus the operator pre-filter, applied case-insensitively):
| Reserved prefixes | Class |
|---|---|
GOV, GOVT, BANK, BTK, SGK, STK, MEB, EBA, DEVLET, DEVLETBANK | Government / public |
MALİYE, MALIYE, EMNİYET, EMNIYET, JANDARMA, TSK, DİYANET, DIYANET | Finance / security forces |
TRT, PTT | Public broadcast / postal |
Strict mode's return is a structured reject, not a carrier-side failure. A send from BANKNOW to a +90 destination returns:
{
"error": {
"code": "SENDER_INVALID_FOR_DESTINATION",
"message": "Sender ID violates destination-country format rules",
"details": {
"country": "TR",
"sender": "BANKNOW",
"rule": "restricted_prefix",
"matchedPrefix": "BANK"
}
}
}The decide-or-route choice is on you: fix the sender name, or route to a sender pool whose members are already conform per destination. The catalogue of rule codes and the strict-permissive toggle map are on the FAQ page — on a permissive account the same value queues with a deliverability advisory instead.
Sender-ID registration for Turkey on Orbit
Turkey is a required-class market in the GET /api/v1/compliance/country-rules reference: the per-country row for TR on the sms channel returns registration: "required" with sender_types: ["alphanumeric", "long_code"]. The row ships next to the same structured payload every other deep-dive regime returns. The gate that enforces it is the same send gate, the registration workflow is the same POST /api/v1/compliance/sender-id-registrations, and the KYC document upload is the same doc_… tracer — nothing Turkey-specific runs through a bespoke side door.
A Turkey-carrying entry:
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/sender-id-registrations \
-H "Authorization: Bearer $ORBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"sender_id": "MyBrand",
"countries": [
{
"country": "TR",
"document_refs": ["doc_7f2a1c9bde42"],
"notes": "Transactional + OTP use case, KVKK controller registration on VERBIS"
}
]
}'The request body is validated by the same schema as every other market — countries is 1–20 entries, document_refs per entry is 1–20 doc_… IDs. What changes is the purpose: file the document set that satisfies the Turkish operator's vetting and the BTK reservation logic, which in practice is the business registration (Ticaret Sicil Gazetesi), the VERBIS registration number, and the use-case note. The upload mechanics, doc_… ID echo, and lifecycle are the KYC documents page.
Turkey sits next to Georgia (ComCom's marketing-whitelist regime) — the first of the whitelisting-wave markets — on the sender-ID country playbook. The TR row has a full filing regime; the Georgia row is the waitlist pattern. One playbook, two regimes.
Opt-out vocabulary for Turkey: DUR, İPTAL, ÇIKIŞ
BTK expects a recognized opt-out vocabulary. Orbit's canonical STOP alias table ships the Turkish family by default, and the strict-mode inbound matcher resolves the dotted-İ / dotless-i Turkish variants as one family. The shipped TR opt-out set:
| Language | Opt-out aliases | Market |
|---|---|---|
| Turkish | DUR, RED, IPTAL, İPTAL, IPTAL ET, DURDUR, ÇIKIŞ, CIKIS, IPTL | TR |
The reciprocating opt-in family ships BAŞLA, BASLA, EVET, KATIL, ABONE. The shortcut that starts the most onboarding confusion: the alias table is tenant-owned and additive — prune it in the compliance editor if it fires on a brand keyword, add a Turkish synonym your CRM predicts, or clone the shipped seed. The per-keyword storage, propagation across channels, and propagation-into-suppression behavior are on the opt-out keyword alias table.
Data residency for TR voice + SMS records
A Turkish destination touches two storage surfaces on the platform, each pinned separately. SMS records (messages, contacts, suppression) live in the workspace's messaging shard — the tenant's residency posture is the same one as other destinations, and the data residency overview enumerates the classes. Voice records (recordings, voicemail, live media metadata) pin to a region on the voice side, a control you set on the tenant: Orbit does not carry an EU workspace's call through US infrastructure, and a TR region pins recordings and media to that address space. The pin lives on voice data residency — inbound-country gating and auto-blocks are still tenant-configured per market, but the residency address is the one that decides where the record lands.
Neither surface is a substitute for the cross-border-transfer reading above. The residency pin keeps storage in the named region; the KVKK Article 8/1a-b socket — consent, adequacy, or a KVKK-Board-signed undertaking — is still the clause the program needs to transfer data out of Turkey at all.
Frequently asked questions
Does the EU's GDPR Article 27 representative requirement cover Turkey?
No. Article 27 of GDPR names an EU representative for controllers outside the EEA processing EU data. KVKK's VERBİS regime requires its own Turkish registration where the entity is not established in Turkey and processes data of Turkish residents. The clauses rhyme; they do not stack.
Is BANKNOW rejected even when the bank's license is real?
Yes — the reserved prefix is operator-side, not KYC-side. BANK* is pre-filtered at the Turkish carrier level independent of the claim the tenant makes on the sender, so a licensed bank still resolves the sender name differently (for example a keyword that does not lead with the reserved prefix). The strict-mode gate is a tenant-owned control that fires pre-send so the reject is deterministic.
Is the Turkey opt-out vocabulary one thing I flip on?
No. The shipped TR seed is the edit-starting point; the alias table is a tenant-owned list you extend. DUR resolves on the first open; ÇIKIŞ resolves alongside it.
Does an approved TR sender-ID registration gate the sender-identity rules?
The two layers are independent. A restricted_prefix reject happens on the destination format check; an SENDER_ID_NOT_REGISTERED or a pending-status block is the registration gate. A sender must clear both before the send proceeds — the registration path is sender-ID registration, the format gate is strict sender-ID mode.
Is this legal advice?
No. This is a tenant-owned onboarding playbook pointing at per-market reference data; the legal interpretation of KVKK and BTK stays with you and your counsel. Final approval sits with the controller's registration and the BTK registry, not with the platform.
The levels are hard gates where they are hard; the vocabulary is what a Turkish program re-reads before the launch calendar moves.
Published 27 September 2026.