> ## Documentation Index
> Fetch the complete documentation index at: https://docs.orbit.devotel.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Turkey: KVVK and BTK Sender-ID Rules
> Turkey's Personal Data Protection Law (KVVK No. 6698) and the BTK sender-registration regime mapped to Orbit surfaces — live TR country rules, business_doc + address_proof KYC roles, seeded Turkish opt-in/opt-out aliases, the DST-safe quiet window, the 30-day DSAR clock, and Art. 9 cross-border residency controls.
# Turkey: KVVK and BTK Sender-ID Rules
Turkey regulates commercial messaging along two axes that meet on every
TR-bound send. The **Personal Data Protection Law No. 6698 (KVVK)**,
enforced by the Personal Data Protection Board (KVKK), defines what you
owe each `+90` recipient on consent, data-subject rights, and
cross-border processing. The **BTK sender-registration regime** (the
Information and Communication Technologies Authority and the mobile
operators it supervises) decides whether your SMS traffic delivers at
all: an alphanumeric sender ID reaches a Turkish handset only once that
ID is registered. This page is the canonical Turkey reference on Orbit
— the same role the [South Korea PIPA page](/compliance/south-korea-pipa)
and the [France rules page](/compliance/fr-marketing-sms-rules) play
for their markets.
Everything below is a **tenant-owned control**. Orbit ships the
surfaces — the consent ledger, suppression and the opt-out keyword
libraries, tenant-configurable quiet hours, sender-registration
status, recording-consent enforcement, the DSAR pipeline —
defaults-open; your organization configures them for Turkey.
Compliance with KVVK, BTK rules, and carrier policy remains your
responsibility, and the regulators and carriers enforce them
regardless of what any toggle says. This page is documentation, not
legal advice.
***
## 1. The TR route: BTK sender registration
Read the live TR row of `GET /compliance/country-rules?channel=sms` on
[Country Compliance Requirements](/compliance/country-requirements)
before you provision. Turkey's SMS edge accepts alphanumeric sender IDs
only once registered — an unregistered sender is filtered at the
carrier edge rather than delivered.
```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms&country=TR" \
-H "Authorization: Bearer $ORBIT_API_KEY"
```
The returned row carries the same fields the France example on the
country-requirements page shows — `sender_types`, `registration`
(`none` / `recommended` / `required`), `sender_rules`,
`content_restrictions`, `stop_requirement`, `two_way`, `dlr_support`,
`default_tps` — plus `last_synced_at` and `last_reviewed_at` for the
freshness check to run before flipping TR live.
BTK naming rules reserve sender-ID prefixes for the institutions that
own them — `GOV`, `BANK`, `SGK`, `MEB` and similar government,
financial-institution, and education prefixes are not available to
ordinary tenants. When you pick an alphanumeric sender for TR traffic,
pick your own registrable name and expect a prefix collision with a
reserved series to be rejected outright.
File the registration through your operator or aggregator, then track
it with two KYC document roles on the
[KYC identity model](/compliance/kyc-identity-model):
* a `business_doc` (trade registry or company extract), and
* an `address_proof` (utility bill or equivalent).
Submit and follow approval on
[Sender-ID Registration](/compliance/sender-id-registration). Until the
row reports `approved`, keep TR marketing traffic in rehearsal — the
send-gate holds Turkey until a registered sender is attached. Voice
origination carries no sender-ID registration, but Turkish
communications-law obligations apply at the operator level; confirm
your carrier's posture for voice separately.
***
## 2. Opt-in and opt-out vocabulary
Turkish keyword aliases ship seeded on the
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table):
| Direction | Seeded aliases |
| - | - |
| Opt-out | `DUR`, `RED`, `IPTAL`, `İPTAL`, `DURDUR`, `ÇIKIŞ` |
| Opt-in | `BAŞLA`, `EVET`, `KATIL`, `ABONE` |
Both the dotted-`İ` and dotless-`i` idioms resolve, so a reply
`İPTAL` and a reply `IPTAL` both write the suppression entry. Choose
which variants you accept per sender when you extend the list.
Where Turkish tenants get burned is scope. Apply the same checklist you
apply for any seed bundle:
1. **Channel scope.** The seeded aliases apply to SMS. Extend the list
yourself for WhatsApp or RCS scope when you run TR traffic on those
channels — add them as custom rules on the alias table page.
2. **Suppression scope.** Route a TR revocation at scope `all` the way
the Canada and Australia pages recommend: a contact that replies
`DUR` to your SMS should not then be voice-dialed or emailed by the
same program. See
[Opt-Out & Suppression Lists](/compliance/opt-out-suppression).
Every inbound `DUR`/`İPTAL` reply, like every `STOP` in France or
`080` call in Korea, lands as a timestamped suppression row. The row —
not the message — is what an audit asks for.
***
## 3. KVVK consent posture
KVVK is consent-first for promotional messaging, and the KVVK consent
record rides on the [consent ledger](/compliance/consent-management)
with `lawful_basis: "consent"` and a consent-text version pinned at
capture:
```bash theme={null}
curl -X POST https://api.orbit.devotel.io/api/v1/compliance/consent \
-H "Authorization: Bearer $ORBIT_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"identifier": "+905321234567",
"channels": ["sms"],
"opt_in": true,
"lawful_basis": "consent",
"purpose": "TR marketing — promotional SMS per KVVK consent text",
"consent_text_version": "tr-kvkk-marketing-v2",
"consent_proof_url": "https://signup.example.com/consent/evt_tr_9c"
}'
```
A KVVK consent record is yours to store — KVVK's legal-basis
vocabulary is narrower than GDPR's, so treat consent (or explicit
opt-in for marketing) as the working basis rather than stretching
`legitimate_interests`. For recipients with no recorded consent, the
tenant-owned
[unknown-marketing policy](/compliance/consent-default-policy) decides
what happens — it defaults to `refuse` for marketing sends, which is
the correct default for Turkey-bound promotional traffic. See
[Consent Management](/compliance/consent-management) for the record
contract, and verify before the first send with
`GET /compliance/consent/lookup`.
***
## 4. Quiet-hours default — Turkey is DST-safe
Turkey runs a fixed **UTC+3** zone with **no daylight saving**, so a
recipient-timezone-resolved window applies the same offset all year.
The deliberate default operators honor is **21:00–08:00 TR time** —
Turkey has no federal marketing window the way France's 20:00–08:00
law does, so the window you set is your own decision.
Configure the window on
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) — the
recipient-resolution path handles `+90` numbers without DST drift —
and validate the recipient timezone resolution with
[Quiet-Hours Preview](/compliance/quiet-hours-preview) before you flip
TR live. Because UTC+3 is fixed, a TR window never mis-fires the way an
DST-shifting zone can when the clock moves.
***
## 5. DSAR clock — 30 days under the GDPR jurisdiction family
KVVK subjects answer through the DSAR pipeline on a **30-day** clock —
by law the Data Controller answers within the period the KVKK Board
specifies, and 30 days is the working practice. File the request with
`applicable_jurisdiction: "gdpr"` on the
[DSAR page](/compliance/dsar) — the jurisdiction family that carries a
30-day SLA — and note in the request purpose that KVVK applies. The
erasure lifecycle runs the same cooling-off-then-hard-delete flow the
page documents, and a completed erasure flows into suppression so a
deleted contact does not re-enter TR marketing sends via a later
import.
***
## 6. Data residency — KVVK Art. 9
KVVK's cross-border transfer rule (Art. 9) triggers on overseas
processing, and regulators ask *where* Turkish-resident data lives. Two
controls are relevant on Orbit:
* **Pin the voice region.** Voice is the one channel where you pin a
resident region directly — set it deliberately on
[Voice Data Residency](/compliance/voice-data-residency) rather than
accepting the default. SMS, email, and the audit trail are covered by
the platform geography Devotel publishes plus your encryption layer.
* **Hold tenant-side encryption keys.** The
[BYOK customer-managed keys](/compliance/byok-customer-managed-keys)
surface lets you hold the encryption key for the tenant — the
strongest localization claim available without an in-Turkey region.
If counsel determines your TR traffic falls under a strict localization
rule, treat that as the constraint that decides whether you use Orbit
for TR at all — this page describes the general KVVK + BTK posture,
not supervision-sector carve-outs.
***
## Frequently asked questions
**Does Orbit register my Turkish sender ID with BTK?**
No — carrier-facing registration is yours to file (or to file through
your aggregator), the same as every market. Orbit exposes the TR
country-rules row and the registration-status tracking so you can
confirm the sender is attached, and it delivers your traffic once it
is.
**Which opt-out replies does the seeded alias set catch?**
The SMS seed covers `DUR`, `RED`, `IPTAL`, `İPTAL`, `DURDUR`, and
`ÇIKIŞ`, with both dotted-İ and dotless-i idioms resolving. WhatsApp
and RCS are not on the SMS seed — extend custom rules for those
channels on the
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table).
**What clock does a KVVK data-subject request carry?**
30 days — file it with `applicable_jurisdiction: "gdpr"` and the SLA
tracker applies the 30-day clock. Turkish opt-out keywords in-market
apply regardless of the DSAR clock: a recipient's `DUR` reply must
write a suppression entry on every sender you run in Turkey.
**Does Turkey have a legal quiet-hours window?**
No — Turkey imposes no federal no-send window the way France does.
Set tenant **quiet hours** deliberately (recipient-timezone-resolved,
fixed UTC+3, e.g. 21:00–08:00 TR) the same way you would elsewhere —
see
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) and the
[Quiet-Hours Preview](/compliance/quiet-hours-preview) surface.
***
This page is documentation, not legal advice — an engineering map of
the Orbit surfaces, not a legal opinion. KVVK, the BTK
sender-registration regime, and carrier policy carry real enforcement
(KVVK fines, carrier-edge filtering of unregistered traffic). Have
counsel review your consent text and proof capture, your template
footers, and your Art. 9 cross-border posture before you send to
Turkish recipients.
***
## Related references
* [Country Compliance Requirements](/compliance/country-requirements) —
the per-country matrix this page expands the TR row of.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
submit-and-track flow for the TR registration.
* [KYC Identity Model](/compliance/kyc-identity-model) — the
`business_doc` + `address_proof` roles the operator asks for.
* [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) —
the seeded TR aliases and the custom-rule extension path.
* [Consent Management](/compliance/consent-management) — the KVVK
consent record contract (`lawful_basis`, proof URL, text version).
* [Data Subject Access Requests (DSAR)](/compliance/dsar) — the
jurisdiction families and the 30-day SLA clock.
* [Voice Data Residency](/compliance/voice-data-residency) — the
region pin KVVK Art. 9 asks for.
* [BYOK Customer-Managed Keys](/compliance/byok-customer-managed-keys) —
tenant-side keys for a localization claim.
* [Long-Tail Market FAQ](/compliance/long-tail-market-faq) — the
consolidated FAQ this page lifts Turkey out of.
* [Turkey KVKK/BTK blog deep-dive](https://orbit.devotel.io/blog/turkey-kvkk-btk-sender-id-rules-2026) —
the marketing-side preview this docs page supersedes: KVVK scope vs
GDPR, BTK reserved prefixes, and the TR opt-out vocabulary.