Skip to main content

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

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

Read the live SA row of GET /compliance/country-rules?channel=sms on Country Compliance 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.
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. 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.
  • 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.
File the registration through 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 is the same id_proof slot the documents page uploads to. Upload each document once on KYC Documents 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 — the Arabic rows name both SA and AE as the markets each alias is common in: 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.
Every inbound Arabic opt-out lands as a timestamped suppression row. The row — not the message — is what an audit asks for.
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 with lawful_basis: "consent" and a consent-text version pinned at capture:
For recipients with no recorded consent, the tenant-owned unknown-marketing policy decides what happens — it defaults to refuse for marketing sends, which is the correct default for SA-bound promotional traffic. See 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 — the recipient-resolution path handles +966 numbers without DST drift — and validate the recipient timezone resolution with 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

​
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:
  • 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

1

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

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

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

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

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

Set the marketing no-overnight window

Turn on tenant quiet hours covering the overnight hours recipient time; validate with Quiet-Hours Preview. Plan Ramadan and Eid campaigns against a tightened window.
7

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

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.

​
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. 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 and reuse the doc_… IDs across registrations.
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.