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

# Saudi Arabia CST Sender & Marketing Rules

> Saudi Arabia sender and marketing rules on Orbit — the CST (formerly CITC) regime that pre-registers every alphanumeric sender ID, the opt-in posture for marketing SMS and voice, dual Arabic/English STOP handling with the two-language auto-reply, KYC documents the carriers accept, quiet-hours posture, and the send-time gates each obligation feeds.

# Saudi Arabia CST Sender & Marketing Rules

Saudi Arabia regulates commercial messaging through the **Communications,
Space and Technology Commission (CST)** — formerly the Communications and
Information Technology Commission (CITC) — and the licensed operators it
supervises. Saudi Arabia runs one of the strictest sender-ID regimes in the
world: an **alphanumeric sender ID reaches a `+966` handset only once that
sender name is registered**, and unregistered sender traffic is blocked at
the carrier edge, not held for review. Marketing SMS into `SA` follows an
opt-in posture — the posture every strict pre-registration market converges
on — and CST's regime touches SMS (pre-registration of the sender name),
voice (no sender ID, but calling-window and content rules apply), and email
only through the consent and content layer.

Everything below is a **tenant-owned control**. Orbit ships the surfaces —
the consent ledger, suppression and the Arabic opt-out keyword aliases,
tenant-configurable quiet hours, sender-registration tracking, and the
send-gate — defaults-open; your organization configures them for Saudi
Arabia. Compliance with CST's requirements and the carriers' vetting
remains yours, and the regulator enforces it regardless of what any toggle
says. This page is documentation, not legal advice.

<Note>
  This page is documentation, not legal advice — an engineering map of the
  Orbit surfaces, not a legal opinion. Enforcement exposure is wholesale:
  the CST regime blocks unregistered sender IDs at the carrier level, not
  message by message, and name registration without the backing KYC
  documents is rejected outright. Have counsel review your sender-name
  choice, your consent text and proof capture, and your marketing-window
  posture before you send to Saudi recipients.
</Note>

***

## 1. The SA route: sender-name pre-registration

Read the live SA row of `GET /compliance/country-rules?channel=sms` on
[Country Compliance Requirements](/compliance/country-requirements) before
you provision. The Saudi SMS edge accepts alphanumeric sender IDs only once
registered — an unregistered sender is filtered at the carrier edge rather
than delivered, and the send-gate holds traffic until an `approved` entry
exists for SA.

```bash theme={null}
curl "https://api.orbit.devotel.io/api/v1/compliance/country-rules?channel=sms&country=SA" \
  -H "Authorization: Bearer $ORBIT_API_KEY"
```

Saudi Arabia is a pre-registration market on the longer end of the approval
window; the live SA row reports `registration: required` and names the
documents the carriers ask for — a commercial registration and an
authorization letter. Plan the same lead time the UAE page budgets on
[Sender-ID Registration](/compliance/sender-id-registration).

Three naming rules catch SA submissions early:

* **Sender ID must match the brand.** CST rejects generic names — a `INFO`,
  `SMS`, or `ALERT` class sender ID that does not tie back to your
  registered brand identity. Pick a registrable brand name that the KYC
  documents you upload can support.
* **A KYC-backed brand identity, not just a string.** The carriers expect
  the sender name attached to a KYC-verified entity; thin submissions
  bounce. Emphasize the legal `company_name`, the `company_website`, and a
  complete `use_case` on
  [Organization KYC Onboarding](/guides/organization-kyc-onboarding).
* **Register before traffic.** Unlike a post-paid registration market,
  Saudi Arabia rejects the traffic itself when the name is unregistered —
  the send-gate returns the SA sender-not-registered error on any A2P
  attempt until the entry is `approved`, per
  [Troubleshooting Compliance Error Codes](/compliance/troubleshooting-compliance-error-codes).

File the registration through
[Sender-ID Registration](/compliance/sender-id-registration) with KYC
document refs the carriers accept:

* a `business_doc` — the Saudi commercial registration issued to the entity
  (the SA row's `commercial_registration` requirement), and
* an `authorization` — an authorization letter appointing the sender (the
  SA row's `authorization_letter` requirement).

For an individual registrant, attach an `id_proof` — a Saudi national ID —
in place of the commercial registration; the role on the
[KYC identity model](/compliance/kyc-identity-model) is the same
`id_proof` slot the documents page uploads to. Upload each document once on
[KYC Documents](/compliance/documents-kyc) and reuse the returned `doc_…`
ID across registrations. Until the SA entry reports `approved`, keep
marketing traffic in rehearsal — the send-gate holds SA and returns a
sender-not-registered error (422) on any A2P attempt.

Voice origination carries no sender-ID registration, but CST-level carrier
obligations apply at the operator level; confirm your carrier's posture for
voice separately.

***

## 2. Dual Arabic/English opt-out vocabulary

Arabic keyword aliases ship seeded on the
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) —
the Arabic rows name both `SA` and `AE` as the markets each alias is
common in:

| Direction | Seeded aliases |
| - | - |
| Opt-out | `إلغاء`, `أوقف`, `توقف`, `STOP` |
| Opt-in | `ابدأ`, `نعم`, `START` |

The matcher is locale-insensitive case-folding with Unicode normalisation,
so a reply `توقف`, a reply `STOP`, and a reply `stop` all write the
suppression entry. The matching rule runs against the exact keyword (or
the keyword plus trailing punctuation) — publish the opt-out keyword you
reference in your consent text and footer.

CST's expectation in a pre-registration market is that opt-out handling
works in **both Arabic and English**: the auto-reply your keyword rule
writes should acknowledge the opt-out in both languages (`You are now
unsubscribed. تم إلغاء اشتراكك.` is the shape), and your consent text and
sender-name footer should reference the Arabic keyword alongside or instead
of `STOP`. Set the two-language auto-reply text on the alias table's
editor and let the seeded Arabic rows carry the vocabulary; a contact
replying `إلغاء` receives the same acknowledgement as a contact replying
`STOP`.

Apply the same two scope rules every seed bundle carries:

1. **Channel scope.** The seeded Arabic aliases apply to SMS. Extend the
   list yourself for WhatsApp or RCS scope when you run SA traffic on
   those channels.
2. **Suppression scope.** Route a SA revocation at scope `all`: a contact
   that replies `توقف` 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 Arabic opt-out lands as a timestamped suppression row. The
row — not the message — is what an audit asks for.

***

## 3. Opt-in consent posture

Saudi Arabia has no opt-out-style commercial-messaging statute, so treat
promotional SMS and voice as **opt-in-strict** — the same posture opt-in
jurisdictions converge on. The 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": "+966512345678",
    "channels": ["sms"],
    "opt_in": true,
    "lawful_basis": "consent",
    "purpose": "SA marketing — promotional SMS per opt-in consent text",
    "consent_text_version": "sa-cst-marketing-v1",
    "consent_proof_url": "https://signup.example.com/consent/evt_sa_4d"
  }'
```

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 SA-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. Marketing quiet-hours posture

The Saudi convention for marketing SMS follows the same conservative
no-send window the GCC pre-registration markets converge on: avoid the
overnight hours (21:00–07:00 recipient-local is the window carriers honor
on marketing traffic). Saudi Arabia runs a fixed **UTC+3** zone with **no
daylight saving**, so a recipient-timezone-resolved window applies the same
offset all year.

This is *not* Orbit's tenant quiet-hours: the send-gate does not flip it
on for you; you set your tenant quiet hours to cover it deliberately.
Configure the window on
[Quiet-Hours Configuration](/guides/quiet-hours-configuration) — the
recipient-resolution path handles `+966` numbers without DST drift — and
validate the recipient timezone resolution with
[Quiet-Hours Preview](/compliance/quiet-hours-preview) before you flip SA
live.

**Ramadan and Eid seasonal sending.** Saudi marketing traffic reads season:
Ramadan and the two Eids shift the hours recipients find acceptable, and
the convention tightens the acceptable window toward the evenings during
fasting hours. Orbit makes no platform-level seasonal change (the
quiet-hours window is tenant-configured); tighten the window yourself
during Ramadan and revert after Eid.

***

## 5. Obligations → Orbit surface table

| CST / carrier obligation | Orbit surface that carries it |
| - | - |
| Alphanumeric sender-ID pre-registration | [Sender-ID Registration](/compliance/sender-id-registration) submit-and-track flow; the [send-time gate](/compliance/send-gates) returns a sender-not-registered error until the SA entry is `approved` |
| Sender name matches the brand (no generic names) | [Organization KYC Onboarding](/guides/organization-kyc-onboarding) — the sender name ties to the KYC-verified entity; generic-class names (`INFO`, `SMS`) are rejected in the CST review |
| KYC documents the carriers accept | [KYC Documents](/compliance/documents-kyc) — `business_doc` (commercial registration) + `authorization` (authorization letter); `id_proof` (Saudi national ID) for an individual |
| Marketing opt-in before first send | [Consent Management](/compliance/consent-management) — a consent record with `sms` scope before dispatch; posture in the [GDPR Posture Guide](/compliance/gdpr-posture-guide) |
| No-overnight marketing window | [Quiet-Hours Configuration](/guides/quiet-hours-configuration) opt-in tenant control (deliberate, not default), validated with [Quiet-Hours Preview](/compliance/quiet-hours-preview) |
| Arabic + English STOP handling | [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) — Arabic rows target `SA, AE`; two-language auto-reply set on the editor; suppression at scope `all` via [Opt-Out & Suppression Lists](/compliance/opt-out-suppression) |
| Ramadan / Eid seasonal posture | Tenant quiet-hours window you tighten seasonally — no platform override; campaign-level decision |
| Restricted industries | [Restricted & Prohibited Industries](/compliance/restricted-industries) — content restrictions layer on top of every SA posture |

***

## 6. Send-time posture — org-level knobs

Two tenant-owned policies decide what happens for a contact with no
recorded consent on a marketing send, both deliberate knobs on
[Consent Posture: The Unknown-Consent Policies](/compliance/consent-default-policy):

```bash theme={null}
curl -X PATCH https://api.orbit.devotel.io/api/v1/settings/compliance/unknown-marketing-policy \
  -H "Authorization: Bearer $ORBIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "unknown_marketing_policy": "refuse"
  }'
```

* `refuse` (the default) is the fail-closed posture a Saudi opt-in-strict
  regime argues for — an unknown-consent marketing send is refused.
* Loosening to `allow_with_logging` is a deliberate, documented call with
  a required written justification; it is not the SA posture.

The sibling consent-default policy (`permit_on_missing` /
`deny_on_missing`) governs the CDP side, not the marketing-send gate; leave
it at the default unless your CDP posture calls for the stricter variant.

***

## 7. Worked configuration before first SA send

<Steps>
  <Step title="Read the SA country-rules row">
    `GET /compliance/country-rules?channel=sms&country=SA` and read
    `sender_types`, `registration`, `content_restrictions`, and
    `stop_requirement`. If `registration` is `required`, the send-gate
    holds SA traffic until an `approved` sender is attached — this is the
    intended behavior, not a fault.
  </Step>

  <Step title="Pick the sender name">
    Alphanumeric, matching the brand identity your KYC documents support —
    no generic class names. Pre-flight it with `GET /compliance/check`
    before you file.
  </Step>

  <Step title="Upload KYC documents">
    Upload the Saudi commercial registration (`business_doc`) and an
    authorization letter (`authorization`); for an individual, a Saudi
    national ID as `id_proof`. Note the returned `doc_…` IDs.
  </Step>

  <Step title="File the SA sender-name registration">
    `POST /compliance/sender-id-registrations` with the SA entry
    referencing your `doc_…` IDs. Wait for the SA country entry to reach
    `approved`; budget the pre-registration lead time the UAE page
    documents.
  </Step>

  <Step title="Capture marketing opt-in first">
    Record a consent entry with `sms` scope before any SA marketing
    send; the unknown-marketing policy defaults to `refuse`, which is the
    right call for the Saudi regime.
  </Step>

  <Step title="Set the marketing no-overnight window">
    Turn on tenant quiet hours covering the overnight hours recipient
    time; validate with
    [Quiet-Hours Preview](/compliance/quiet-hours-preview). Plan Ramadan
    and Eid campaigns against a tightened window.
  </Step>

  <Step title="Publish the dual Arabic/English opt-out">
    Confirm the seeded Arabic aliases (`إلغاء`, `أوقف`, `توقف`, `STOP`)
    cover the keyword your consent text and footer reference, and set the
    auto-reply to acknowledge in both languages.
  </Step>

  <Step title="Verify before first send">
    `GET /compliance/sender-id-registrations` shows SA `approved`;
    `GET /compliance/consent/lookup` returns the recipient's consent
    row; the quiet-hours preview resolves the recipient timezone
    correctly. Then send.
  </Step>
</Steps>

***

## Frequently asked questions

**Does Orbit register my Saudi sender name with CST?**
No — carrier-facing registration is yours to file (or to file through your
aggregator), the same as every market. Orbit exposes the SA country-rules
row and the registration-status tracking so you can confirm the sender is
attached, and it delivers your traffic once the entry is `approved`.

**Is the overnight window a platform gate?**
No — the overnight no-send window is the market convention, not a gate
Orbit flips on. Setting tenant quiet hours to cover it is a deliberate,
tenant-owned opt-in — the same pattern the France page documents for the
French window.

**Why does the Saudi page ask for both Arabic and English STOP?**
Because Saudi recipients can reply in either language, CST's regime expects
opt-out handling to work for both, and your auto-reply should acknowledge
both. The Arabic aliases (`إلغاء`, `أوقف`, `توقف`) ship seeded targeting
`SA, AE` — see
[Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table).

**Which KYC documents does a Saudi registration accept?**
A Saudi commercial registration as `business_doc` plus an authorization
letter as `authorization`; for an individual, a Saudi national ID as
`id_proof`. Upload each on
[KYC Documents](/compliance/documents-kyc) and reuse the `doc_…` IDs
across registrations.

***

<Warning>
  This page is documentation, not legal advice — an engineering map of the
  Orbit surfaces, not a legal opinion. CST's sender-registration regime and
  the carriers' vetting carry real enforcement (carrier-edge filtering of
  unregistered traffic, name rejection). Have counsel review your
  sender-name choice, your consent text and proof capture, and your
  Ramadan/Eid marketing-window posture before you send to Saudi recipients.
</Warning>

***

## Related references

* [Country Compliance Requirements](/compliance/country-requirements) —
  the per-country matrix this page expands the SA row of.
* [Sender-ID Registration](/compliance/sender-id-registration) — the
  submit-and-track flow for the SA registration; lead-time table.
* [KYC Identity Model](/compliance/kyc-identity-model) — the
  `business_doc`, `id_proof`, and `authorization` roles the carriers ask
  for.
* [Organization KYC Onboarding](/guides/organization-kyc-onboarding) —
  the KYC-backed brand identity the SA sender name attaches to.
* [Opt-Out Keyword Alias Table](/compliance/opt-out-keyword-alias-table) —
  the seeded Arabic aliases and the custom-rule extension path.
* [Consent Management](/compliance/consent-management) — the consent
  record contract (`lawful_basis`, proof URL, text version).
* [Consent Posture: The Unknown-Consent Policies](/compliance/consent-default-policy) —
  the `refuse` / `allow_with_logging` decision point.
* [Quiet-Hours Configuration](/guides/quiet-hours-configuration) — set
  the recipient-timezone-resolved window.
* [Quiet-Hours Preview](/compliance/quiet-hours-preview) — validate the
  recipient timezone resolution before you go live.
* [Troubleshooting Compliance Error Codes](/compliance/troubleshooting-compliance-error-codes) —
  the regional-gate error surface the SA row lands in.
* [UAE TDRA Sender & Marketing Rules](/compliance/uae-tdra-sender-rules) —
  the sibling GCC pre-registration market page; Saudi and UAE senders
  usually launch together.