> ## 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.

# Long-Tail Market FAQ: KVVK, PIPA, APPI, POPIA, PDPA

> One consolidated FAQ for the five long-tail market regimes operators ask about most — Turkey (KVVK), South Korea (PIPA), Japan (APPI), South Africa (POPIA), and Singapore/Thailand (PDPA): what to register, which documents to file, which opt-out vocabulary applies, the DST-safe quiet-hours default, the DSAR clock, and a link to each market's deep page.

# Long-Tail Market FAQ: KVVK, PIPA, APPI, POPIA, PDPA

The deep country pages cover each regime end to end; this page is the
consolidated FAQ for the five long-tail markets operators ask about
most: **Turkey (KVVK)**, **South Korea (PIPA)**, **Japan (APPI)**,
**South Africa (POPIA)**, and **Singapore/Thailand (PDPA)**. Each
answer reconciles five things per market: the data-residency posture,
the sender-registration level the
[Country Compliance Requirements](/compliance/country-requirements)
rows carry, the opt-in/opt-out keyword vocabulary from the
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table),
the KYC document roles you file through the
[KYC Identity Model](/compliance/kyc-identity-model) (`id_proof`,
`business_doc`, `address_proof`), and the DSAR SLA clock you pick on
the [DSAR page](/compliance/dsar).

<Note>
  Every control named below is **tenant-owned**. Orbit ships the
  surfaces defaults-open — consent ledger, suppression, sender
  registration status, quiet hours, recording-consent enforcement, the
  DSAR pipeline; you configure them per market. Regulators and carriers
  enforce their rules regardless of what any toggle says. This page is
  documentation, not legal advice.
</Note>

<Warning>
  Korea, Japan, and South Africa have deep pages; **Turkey and the
  SG/TH pair have no dedicated page yet — Turkey's deep content is
  planned, and PDPA is covered below together.** Where a deep page is
  missing, read the market's live row returned by
  `GET /compliance/country-rules?channel=<channel>` and the generic
  [Sender-ID Registration](/compliance/sender-id-registration) page.
</Warning>

***

## Turkey — KVVK (Personal Data Protection Law No. 6698)

**What must register?**
Turkey's SMS edge accepts alphanumeric sender IDs only once registered
— read the live `TR` row for the channel before you provision. File
the registration through your operator or aggregator as a
`business_doc` (trade registry / company extract) plus an
`address_proof` on the
[KYC identity model](/compliance/kyc-identity-model); until the row
reports `approved`, TR marketing traffic should stay in rehearsal.
Voice origination carries no sender-ID registration, but Turkish
communications-law obligations apply to the operator level — see your
carrier.

**Which opt-in/opt-out vocabulary ships?**
Turkish aliases are seeded: opt-out `DUR`, `RED`, `IPTAL`, `İPTAL`,
`DURDUR`, `ÇIKIŞ`; opt-in `BAŞLA`, `EVET`, `KATIL`, `ABONE` (the
dotted-İ and dotless-i variants both resolve). Extend the list on
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
for WhatsApp/RCS scope. KVVK consent records you store yourself with a
`lawful_basis: "consent"` and your consent-text version.

**Which quiet-hours default is DST-safe?**
Turkey has a fixed UTC+3 zone (no DST). A recipient-timezone-resolved
default of **21:00–08:00 TR time** is the operator honor-default —
Turishi no federal window is statutory the way France's is. Configure
it on [Quiet-Hours Configuration](/guides/quiet-hours-configuration)
and validate with
[Quiet-Hours Preview](/compliance/quiet-hours-preview).

**Which DSAR SLA applies?**
KVVK gives the data subject **30 days** for a response (by law, the
Data Controller must respond within the period the KVVK board
specifies; the practice is 30 days). File with
`applicable_jurisdiction: "gdpr"` — the documented jurisdiction family
that carries a 30-day clock on the [DSAR page](/compliance/dsar) —
and note in the request purpose that KVVK applies.

**Data residency?**
KVVK's cross-border transfer rule (Art. 9) triggers on overseas
processing. Pin your voice region deliberately ([Voice Data
Residency](/compliance/voice-data-residency)) and hold tenant-side
encryption keys ([BYOK](/compliance/byok-customer-managed-keys)) for a
strong localization claim without an in-Turkey region.

***

## South Korea — PIPA (+ KISA opt-out rules)

**What must register?**
SMS sender pre-registration is **required** — unregistered alphanumeric
traffic is filtered at the carrier edge, not delivered. Read the KR
row of
[Country Compliance Requirements](/compliance/country-requirements);
KR's `registration: required` blocks the send-gate until a registered
sender is attached. Two controls live on the deep page:

* the **pre-registration** (file through your operator/aggregator as
  `business_doc` + `address_proof` roles), and
* the **`080` free-to-reply withdrawal number** — KR's analog of
  France's `STOP au 36111`, printed in every KR marketing template's
  footer.

Voice carrier origination carries no sender registration; KakaoTalk is
the dominant adjacent channel and inherits the same PIPA consent
rules.

**Which opt-in/opt-out vocabulary ships?**
Korean reply vocabulary is yours to add as custom rules on the
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
— the canonical `080` withdrawal and replies like `수신거부` / `중지`
/ `STOP` must write a suppression entry on every sender you run. The
policy-scanner's `ko` bundle already knows the `중지` compose-time
lint.

**Which quiet-hours default is DST-safe?**
Korea is UTC+9 with no DST. No federal statutory SMS window like
France's exists; the restraint is PIPA's purpose limitation plus
carrier filtering. Set tenant **quiet hours deliberately**
(21:00–08:00 KR recipient time) — see
[Quiet-Hours Configuration](/guides/quiet-hours-configuration).

**Which DSAR SLA applies?**
PIPA requests file under `applicable_jurisdiction: "pdpa"` — the
**30-day APAC clock** applies, same as SG/TH PDPA. Erasure outcomes
flow into suppression so a deleted contact cannot silently re-enter
marketing sends.

**Data residency?**
PIPA's overseas-processing rule requires a written record plus
consent-specific handling in regulated verticals. Pin voice regions and
apply BYOK where you need the strongest localization posture without an
in-Korea region; document the transfer map from the
[Data Residency Overview](/compliance/data-residency-overview).

Deep page: [South Korea PIPA + KISA Opt-Out Posture](/compliance/south-korea-pipa).

***

## Japan — APPI (Act on Protection of Personal Information)

**What must register?**
Japan's sender rules sit where telecom regulation and APPI meet:
carriers (NTT Docomo, KDDI, Softbank, Rakuten) dictate address-form,
APPI governs whether you may address the person at all. The `JP` row
of the country-rules endpoint records sender type and registration
level per channel; most AKKs (A2P alphanumeric) require pre-registration
filed as `business_doc` + `address_proof` roles on your
[KYC identity model](/compliance/kyc-identity-model). WhatsApp and
RCS carry their own content-policy gates — see
[Whatsapp Content Policy](/compliance/whatsapp-content-policy).

**Which opt-in/opt-out vocabulary ships?**
APPI is a purpose-and-disclosure regime: record the consent ledger
with `purpose` and `consent_text_version` per `(contact, channel)`
pair. Opt-out vocabulary is your custom-rule set — add Japanese
aliases on
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table)
(suggesting `パスワード`/`キャンセル` variants wherever the carrier text
expects them) — and treat each inbox reply as a suppression record.

**Which quiet-hours default is DST-safe?**
Japan is UTC+9 with no DST. APPI does not impose a statutory window;
the expectation comes from carrier practice. Set a tenant quiet-hours
default (21:00–08:00 JP recipient time) through
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) and
preview with
[Quiet-Hours Preview](/compliance/quiet-hours-preview).

**Which DSAR SLA applies?**
APPI requests file under `applicable_jurisdiction: "pdpa"` if you
want the APAC family SLA; Japan's APPI carries a "without delay"
residual provision with a practice-typical 30-day clock. The
30-day-family `pdpa` code is the closest available SLA on the
[DSAR page](/compliance/dsar) — treat it as your APPI tracker and
note the APPI basis in the request purpose.

**Data residency?**
APPI's cross-border rule (Joint Order class) requires the subject's
consent, an adequate-level country/framework, or system raises, and a
written record of what transfers. Pin your voice region and BYOK as
the residency answer for Japan-bound recordings; document the mapping
per [Data Residency Overview](/compliance/data-residency-overview).

Deep page: [Japan APPI](/compliance/japan-appi).

***

## South Africa — POPIA (+ ECTA direct-marketing opt-out)

**What must register?**
South African SMS traffic accepts alphanumeric sender IDs, usually
after pre-registration filed through your operator/aggregator; wire
the registration status through the KYC document role
(`business_doc` + `address_proof`) before production traffic. Voice
carries no sender registration. Where an ECTA opt-out is handled at
the carrier edge, a suppression entry flowing from your sender
registration status is the same thing a South African recipient
expects.

**Which opt-in/opt-out vocabulary ships?**
The ECTA opt-out is the first law most operators meet. English
vocabulary (`STOP` family) is the carrier expectation; add the
South-African preference-center hook
([Custom Opt-Out Keyword Lists](/guides/opt-out-lists)) and record the
suppression per channel as `all` scope. Consent records you store
yourself with a `lawful_basis` value and the versioned consent text.

**Which quiet-hours default is DST-safe?**
South Africa sits UTC+2 with no DST. No statutory federal no-send
window exists; the ECTA provision only names reasonable-hours
restraint for direct marketing. Set a tenant quiet-hours fallback
(21:00–08:00 recipient time) through
[Quiet-Hours Configuration](/guides/quiet-hours-configuration).

**Which DSAR SLA applies?**
POPIA's access-and-correction requests file under
`applicable_jurisdiction: "gdpr"` -> the **30-day clock** applies as
a documented state on the [DSAR page](/compliance/dsar). POPIA's
practical response-window is up to your Information Regulator-guided
use; treat the 30-day family code as the closest SLA tracker and
note POPIA as the basis.

**Data residency?**
POPIA gives the Information Regulator's s72 cross-border rule — no
bright-line ban on overseas processing, but a record plus a basis.
Pin voice regions and BYOK as the residency claim; map the transfer
posture per [Data Residency Overview](/compliance/data-residency-overview).

Deep page: [South Africa POPIA Posture](/compliance/south-africa-popia).

***

## Singapore & Thailand — PDPA

**What must register?**
Singapore's DNC register affects outbound marketing calls/SMS/faxes
to +65 recipients; sender registration itself is lightest here —
alphanumeric IDs accepted, usually `recommended` on the
country-rules rows. Thailand's PDPC regime is consent-led. File any
KYC attachments through your operator/aggregator with the
`business_doc` + `address_proof` roles; the
[KYC identity model](/compliance/kyc-identity-model) is where the
attachment lands.

**Which opt-in/opt-out vocabulary ships?**
English `STOP` aliases are the canonical expectation across APAC;
both markets treat a `STOP` reply as a suppression entry the ledger
owns. Confirmed-consent records storing `purpose` and
`consent_text_version` per `(contact, channel)` close the deemed-
consent nuance Singapore's 2020 amendment codifies.

**Which quiet-hours default is DST-safe?**
Both SG (UTC+8) and TH (UTC+7) are DST-free timezones. No statutory
quiet window exists; the PDPA expectation inherits from carrier
practice. Set tenant quiet hours per recipient timezone — see
[Quiet-Hours Configuration](/guides/quiet-hours-configuration).

**Which DSAR SLA applies?**
PDPA requests file under `applicable_jurisdiction: "pdpa"` — the
**30-day clock** family applies; both markets treat a `pdpa` request
type as the documented SLA tracker. Erasure outcomes flow into
suppression the same way as KR/APPI subjects.

**Data residency?**
SG and TH transfers are assessments you run on your transfer basis;
the residency pin ([Voice Data Residency](/compliance/voice-data-residency))
records where recordings physically live, and BYOK
([BYOK Customer Managed Keys](/compliance/byok-customer-managed-keys))
carries the localization claim where you need it.

Deep page: [Singapore and Thailand PDPA Posture](/compliance/pdpa-singapore-thailand).

***

## Comparative matrix

| Market                        | Registration level (typical)                            | Document roles to file           | Opt-out vocabulary                                                        | DST-safe quiet-hours default                                | DSAR SLA                                          |
| ----------------------------- | ------------------------------------------------------- | -------------------------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------- | ------------------------------------------------- |
| **Turkey (KVVK)**             | `required` on alphanumeric SMS                          | `business_doc` + `address_proof` | Turkish aliases ship (`DUR`, `IPTAL`, `İPTAL`); extend on the alias table | Fixed UTC+3 default of 21:00–08:00                          | `gdpr` code — 30-day tracker, basis noted as KVVK |
| **South Korea (PIPA)**        | `required` pre-registration; `080` withdrawal in footer | `business_doc` + `address_proof` | Korean rules you add (`수신거부`, `중지`); `ko` bundle already lints `중지`       | UTC+9 fixed; deliberate tenant hours (21:00–08:00)          | `pdpa` code — 30-day APAC clock                   |
| **Japan (APPI)**              | `required` on most A2P alphanumeric                     | `business_doc` + `address_proof` | Custom Japanese aliases you file                                          | UTC+9 fixed; carrier-practice hours (21:00–08:00)           | `pdpa` code — 30-day tracker; APPI basis noted    |
| **South Africa (POPIA/ECTA)** | `recommended`/`required` depending on operator          | `business_doc` + `address_proof` | English `STOP` family; ECTA opt-out at carrier edge                       | UTC+2 fixed; ECTA "reasonable hours" practice (21:00–08:00) | `gdpr` code — 30-day tracker; POPIA basis noted   |
| **SG/TH (PDPA)**              | `recommended` alphanumeric                              | `business_doc` + `address_proof` | English `STOP` aliases                                                    | UTC+8 / UTC+7 fixed                                         | `pdpa` code — 30-day APAC clock                   |

Registration levels above are averages of the live rows returned by
`GET /compliance/country-rules?channel=sms` — always re-read the live
row before you provision; the row, not this table, is authoritative.
The document role (`id_proof`, `address_proof`, `business_doc`,
`authorization`, `other`) is how the
[KYC identity model](/compliance/kyc-identity-model) attaches roles to
a compliance profile.

***

## Frequently asked questions

**Which registrations are mandatory?**
Check the live row per channel on
[Country Compliance Requirements](/compliance/country-requirements):
TR and KR SMS rows carry `required` alphanumeric registration; JP's
carrier-edge gate is variant-specific per carrier. SG and TH rows
typically read `recommended`. Whatever the row says, the send-gate
blocks what the registration level demands.

**Which document role do I file?**
Corporate identity lands as `business_doc`; address evidence lands as
`address_proof`; individual signers land as `id_proof`. The KYC
[identity model](/compliance/kyc-identity-model) enumerates the five
roles (`id_proof`, `address_proof`, `business_doc`, `authorization`,
`other`).

**What qualifies as a DST-safe quiet-hours default?**
A fixed-zone recipient-time default (UTC+3 TR, UTC+9 KR/JP, UTC+2 ZA,
UTC+8 SG, UTC+7 TH) that you set on
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) and
validate with the
[Quiet-Hours Preview](/compliance/quiet-hours-preview). None of these
markets move DST — the safety property is timezone fixity, not the
window itself.

**Which DSAR SLA applies?**
The [DSAR page](/compliance/dsar) enumerates the `applicable_jurisdiction`
codes and the clocks they carry. Pick the closest-geographic family
(`pdpa` for KR/JP/SG/TH; `gdpr` for TR/ZA) and record the market's
official basis in the request `purpose` so the SLA tracker reports
the window your counsel expects.

**Does Orbit register my sender in these markets?**
No — carrier-facing or regulator-facing registration is yours to file
(or file through your operator/aggregator); Orbit exposes the row and
the gate, delivers once the row reports `approved`, and never files
a registration on your behalf.

***

## Related references

* [Country Compliance Requirements](/compliance/country-requirements) —
  the per-country, per-channel sender rules this FAQ reconciles.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
  submit-and-track flow.
* [KYC Identity Model](/compliance/kyc-identity-model) — the document
  role vocabulary (`id_proof`, `business_doc`, `address_proof`).
* [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) —
  the seeded vocabulary per market.
* [DSAR](/compliance/dsar) — the SLA-clock tracker and jurisdiction
  codes.
* [Voice Data Residency](/compliance/voice-data-residency) — region
  pinning and the in-region guarantee.
* [Data Residency Overview](/compliance/data-residency-overview) —
  the per-channel residency map.
* [BYOK Customer Managed Keys](/compliance/byok-customer-managed-keys) —
  the strongest localization posture without an in-market region.
* [Quiet-Hours Configuration](/guides/quiet-hours-configuration) and
  [Quiet-Hours Preview](/compliance/quiet-hours-preview) — the
  org-wide channel gates and the validation surface.
* [Compliance Posture Overview](/compliance/posture-overview) — the
  tenant-owned controls map.