KYC and sender-ID registration on a CPaaS — country rules, documents, and the send gate

KYC on a CPaaS

KYC — know your customer — is the identity proof a carrier or regulator requires before it lets your sender identity carry traffic, and on a CPaaS it is an object you build once and reuse: structured compliance profiles backed by a document library, referenced per country, per sender, and per number. It is not a badge the platform grants; it is evidence the regulator reviews.

Regulated markets do not accept "trust me." Before an alphabetic sender ID delivers in the UK or a long code activates in Germany, someone — Ofcom, the BNetzA, a US carrier — wants to know who the sending entity actually is. On Devotel Orbit, that proof is modeled as two things you own: a document library (the files themselves) and compliance profiles (the structured identity the documents back up). The KYC glossary entry defines the term; this guide covers how the verification lifecycle runs from upload through approval to renewal, and what happens at the send gate when it is missing.

Compliance profiles and the document library

A compliance profile (cprof_…) is one regulatory identity bundle: who the end user is, for which use case, in which country. Carriers review the profile as a unit — approve it once and every number or sender that profile covers can use it. A profile captures a label, a use_case (phone-number purchase, alphanumeric sender ID, US 10DLC brand or campaign, WhatsApp business verification, and more), the country_code it answers to where the use case is country-bound, whether the end user is a business or an individual, and the structured fields the country asks for (registered name, address, tax ID).

Documents live in a separate, tenant-wide library. Upload a business registration once with POST /compliance/documents and it returns a doc_… ID you attach to a German number profile today and reuse for a Brazilian sender-ID registration tomorrow — no second upload. A document does regulatory work only when it is attached to a profile with a role (id_proof, address_proof, business_doc, authorization, other) that tells the carrier which requirement it satisfies; the same file may play a different role in a different profile. The full field list and upload contract are in the KYC documents reference.

A profile's status moves draft → pending_review → approved (or rejected), and to expired when its validity window closes. Only an approved profile satisfies a country's checks.

Read the country rules at choose-time, not send-time

The most expensive onboarding surprise is not a rejection — it is discovering after choosing a launch market that the destination blocks unregistered senders outright. Every country registration question has one answer source: GET /api/v1/compliance/country-rules, a read-only reference any authenticated user can call. Per country and per channel it returns the accepted sender types and a registration level with three values:

A brand integrating a CPaaS typically has a "pick your launch countries" step; that step should call the country-rules endpoint and surface the registration value per country, so a market that requires pre-registration shows its lead time before the brand commits to it. Filter by region to narrow the scan, and call it once per channel (sms, rcs, whatsapp, voice, email, viber) — the same country can answer to a different regulator per channel. The choosing-matrix treatment is the sender-ID country matrix guide.

The five hardest markets, plus the India nuance

Read the live value from the endpoint — below is the current planning snapshot for the markets that surprise operators most, not a frozen copy to code against:

• United Kingdom — required (Ofcom / Phone-paid Services Authority). Register the alphabetic sender ID before the first send; the gate holds unregistered UK-bound traffic.
• Saudi Arabia — required (CST, formerly CITC). The sender name — not just a number — must be pre-registered and approved with the regulator.
• United Arab Emirates — required (TDRA). The regulator and carriers (e&, du) expect a KYC-backed brand identity attached to the sender name: upload documents first, register second.
• Brazil — required (Anatel). Dynamic alphabetic senders are not accepted at all; the sender ID must hold a country-level approved registration before sends originate.
• United States — required, but the object is different: no alphabetic senders exist for standard long codes. Under 10DLC you register a brand and a campaign per US long number through The Campaign Registry.

India is required under a different regime entirely — TRAI's Distributed Ledger Technology (DLT) framework. Instead of a sender-ID approval, the ledger records your entity, your headers, and your content templates, and every send must carry a template ID that matches a registered template. Registering the sender without registering the templates is the common failure.

At the other end, much of the EU is none or recommended: an alphabetic sender ID delivers with no pre-registration. Register it anyway where you can — unregistered dynamic alpha is the traffic carriers relabel first when filtering tightens.

How the send gate rejects unregistered required markets

When a destination is required and the sender has no approved registration for that country, the send-time gate rejects the send with a 422 and a market-specific code — for example MESSAGING_SA_SENDER_NOT_REGISTERED or MESSAGING_BR_SENDER_NOT_REGISTERED. The gate checks alphabetic senders only; numeric long codes route through carrier provisioning instead, so the check never blocks a number the carrier itself provisioned.

To clear the gate: submit the registration from Settings → Sender IDs or through the sender-ID API, attach the KYC documents the market expects (referenced by their doc_… IDs — the registration route never accepts files), and wait for approved. The sender-ID registration reference covers the submission and status endpoints.

Document types, expiry, and renewal

The library accepts eleven document types — id_card, passport, drivers_license, utility_bill, bank_statement, business_registration, vat_certificate, lease_agreement, proof_of_address, power_of_attorney, other — as JPEG, PNG, WebP, or PDF up to 10 MB. Files are encrypted before they leave the API and held in private storage.

Many regulators treat documents as stale after a fixed age: UK Ofcom, Germany's BNetzA, and France's ARCEP generally require ID or address proof to be no older than 3–12 months. Each attached document carries an expires_at; once it lapses it stops counting toward the country's requirements even while the file still sits in your library, and an expired attachment flips a profile from satisfying to unsatisfying. Renewal is a fresh upload, not an edit — upload the replacement, attach it in the same role, then detach and optionally delete the old one. Profiles already approved stay approved while you swap the document; the submission is re-reviewed on next use. Per-number expiry alerts (GET /numbers/document-expiry-alerts) surface upcoming document expirations and carrier deadlines with a suggested action, so a lapsed utility bill never costs you a number silently.

Tenant-owned by design

The split of responsibility is deliberate. Orbit encrypts and stores each document once, scoped to your organization; carries the profile and its documents to each carrier and reports per-provider review status; flags documents approaching expiry; and enforces the gates — unregistered senders do not pass send checks and unsatisfied profiles do not activate numbers. You supply truthful, current documents; choose which profiles a document backs and in which role; keep the structured fields accurate as your business details change; and upload replacements before a document lapses.

Final approval is always granted by the carrier or regulator in each country — never by the platform. Orbit never invents, auto-approves, or auto-renews identity documents on your behalf, and the registration values the country-rules endpoint returns tell you what to plan for, not a delivery guarantee. Coverage is also enabled per tenant: a market listed by the endpoint is not necessarily enabled on your account. That posture — operator owns the obligations, the platform supplies the controls and the evidence trail — is the same one the CPaaS compliance topics guide applies to TCPA, 10DLC, STIR/SHAKEN, and opt-out handling.

Frequently asked questions

What does KYC verify, and who reviews it?

KYC verifies the identity of the sending entity — the business or individual behind the sender ID, long code, or number. You build the evidence in a compliance profile backed by library documents; the carrier or regulator in each country reviews it and grants (or refuses) approval. Orbit submits, tracks, and enforces the result, but never approves on a regulator's behalf.

Which markets absolutely require pre-registration before the first send?

The five that surprise operators most are the United Kingdom, Saudi Arabia, the United Arab Emirates, Brazil, and the United States (as 10DLC brand + campaign registration). India also requires registration under TRAI's DLT regime, with registered content templates as the extra step. For every other market, read the registration field from the country-rules endpoint at choose-time — values change, so treat any static table as a snapshot.

What happens if I send to a required market without an approved registration?

The send-time gate rejects the send with a 422 and a market-specific error code (for example MESSAGING_SA_SENDER_NOT_REGISTERED). Nothing reaches the carrier. The check applies to alphabetic sender IDs; a numeric long code routes through carrier provisioning instead. To clear the block, submit the registration with the market's expected documents and wait for the carrier's approved decision.

Do I re-upload documents for every country?

No. Documents live in a tenant-wide library: upload once, then reference the same doc_… ID across as many profiles and country registrations as accept it. Each registration references the ID with a role that says which requirement it satisfies, so one business registration can back the UK sender-ID filing and a German number profile simultaneously. The only recurring work is renewal — regulators reject stale documents, so re-upload before the recorded expiry.

How do documents expire, and how do I renew them?

Each attached document carries an expires_at; once it lapses, it stops counting toward the country's requirements and the profile it backs can become unsatisfying until renewed. Renewal is a fresh upload in the same role, after which the old attachment is detached. Approved profiles stay approved during the swap, and the per-number expiry-alerts endpoint lists upcoming expirations with a suggested action before they bite.

Sources and further reading

• KYC documents and the compliance-profile lifecycle: upload once, reference by doc_… ID across profiles and registrations, renew before expiry.
• Sender-ID registration: submit and track per-country registrations and their status.
• Sender-ID country matrix: read registration: none / recommended / required at choose-time, with the five hardest markets and India DLT.
• CPaaS compliance topics: the companion telecom-regulation explainer — TCPA, 10DLC, STIR/SHAKEN, and opt-out handling.
• 10DLC registration: the US brand + campaign flow.
• DLT-India onboarding: India's entity + header + content-template regime.