Quick answer: KYC (know-your-customer) on a CPaaS is the proof regulators and carriers ask for before they let a phone number activate or a Sender ID carry traffic in a regulated market. On Devotel Orbit, you upload each document once into a tenant document library, reference it by a doc_… ID across every sender registration and compliance profile that accepts it, and renew it before its recorded expiry date. The classes most markets ask for: proof of business registration, a use-case description, brand or agent authorization, and tax or regulator IDs. The reference with the full endpoint surface is the KYC documents docs page; this post is the orientation reading before you open it.
If your onboarding plan has a German number, a US 10DLC brand, and an alphanumeric Sender ID in the target list, the document question arrives in week one — so it pays to know the shape of the answer before a regulator's clock starts.
Why KYC exists in CPaaS at all
Public telecommunications is a regulated market almost everywhere, and regulators delegate part of the identity-verification burden to the carriers and platforms that route traffic. Three touchpoints routinely need verified identity:
Number provisioning. In most European and APAC markets, a geographic or toll-free number does not activate for an end user whose identity no one has proven. UK's Ofcom, Germany's BNetzA, and France's ARCEP each define which proof a local number requires; a CPaaS provider that hands out numbers without collecting that proof is running a liability, not a product.
Regulated Sender IDs. An alphanumeric SMS Sender ID, a US 10DLC brand and campaign, a toll-free verification, an RCS agent, a WhatsApp Business registration — each of these is a filing with a carrier or registry, and each filing leans on documented identity for the brand behind it. The US 10DLC ecosystem (The Campaign Registry) exists precisely to bind a sender identity to a vetted business.
Enterprise onboarding itself. Even before any filing, platforms gate their own abuse surface. A provider that skips KYC becomes the path of least resistance for SMS pumping, gray routes, and smishing — and the carriers respond by distrusting every sender on the platform. KYC protects your deliverability as much as it protects the carrier.
The takeaway for a buyer: gathering documents is not bureaucratic friction; it is the price of sitting on the trusted side of the routing table.
The document classes regulators actually ask for
Across markets, the asks converge on four classes. Gather these up front and most country filings are a naming exercise rather than a new paperwork hunt.
1. Proof of business registration
The foundational class: a business registration extract, certificate of incorporation, or commercial-register entry showing the legal entity's current name, registered address, and registration number. Regulators verify the entity exists and matches the brand about to send; carriers cross-check the registration number against their own records. For individual end users, this becomes an identity document — a passport or national ID card.
2. Use-case description
Structured text, not a file: what the number or sender will actually do. "Appointment reminders for our clinic's registered patients" passes where "marketing" does not. This maps to a use-case category such as phone_number_purchase, sms_sender_id_alphanumeric, sms_10dlc_brand_us, sms_10dlc_campaign_us, sms_tfv_us, or whatsapp_business_verification — and for US 10DLC campaigns it extends to sample message content. Write it specifically once and reuse it; vague use-case text is the single most common rejection reason.
3. Brand or agent authorization
When the filing entity differs from the brand's owner — an agency filing for a client, a subsidiary sending under the parent brand — the carrier wants written authorization linking the two. A letter of authorization, power of attorney, or brand-consent document covers it. If your legal entity name differs from the sender name you want to display, expect this class to be mandatory.
4. Tax and regulator IDs
The machine-checkable identifiers: VAT certificate or tax ID in the EU, EIN in the US, ABN in Australia, and country-specific registrations where the market requires them (for example, a DLT entity ID where India's DLT framework applies). These are verified against public registries, so a typo here fails the same as a missing document.
One class people forget: proof of address and supporting documents — a utility bill, bank statement, or lease agreement — which some markets use to corroborate the registered address, and most regulators treat as aged once the document is a few months old.
Gathered in advance, these four classes cover the overwhelming majority of country filings. Something country-specific does come up — which is why you check a regulatory preview before purchasing, not after.
Orbit's lifecycle: upload once, reference everywhere
The model behind the paperwork matters to a buyer, because it determines whether KYC is a recurring tax or a one-time taxonomy.
Devotel Orbit splits your proof into two objects you own: a document library holding the files themselves, and compliance profiles — structured identity bundles (cprof_…) covering one end user, one use case, one country. The lifecycle:
- Upload once. Each file goes into your tenant-scoped library and gets a
doc_…ID. The upload is already referenced in the introduction: one multipart request, document type, JPEG/PNG/WebP/PDF up to 10 MB, encrypted before storage. - Reference by ID. Attach the
doc_…ID to any profile with a role (id_proof,address_proof,business_doc,authorization,other). The German phone-number profile and the French Sender-ID filing can both point at the samedoc_…ID — no second upload. Sender-ID registrations carrydocument_refs, a list of those IDs. - Track expiry. Each attached document records an
expires_at; an expired document stops counting toward a country's requirements even though the file still sits in your library, and the number regulatory-preview check flips to unsatisfied the moment the document lapses. - Renew by replacement. Renewal is a fresh upload attached in the same role, then the old document detached. An already-approved profile stays approved while you swap — the submission is re-reviewed on next use.
Two operational notes buyers should hear day one. A profile in pending_compliance state blocks the number activation it gates, and a number stuck there past the carrier's verify-by deadline can be auto-released — so a lapsed document is not a cosmetic state. And nothing in the lifecycle is automatic-approval: supplying documents starts a review; the regulator's verdict comes back on its own timetable. Plan onboarding around that review window, not around the upload itself.
What "renew before expiry" means in practice
Regulators commonly treat identity and address documents as stale after a fixed age — typically 3 to 12 months depending on the class and market. "Renew before expiry" is the discipline of replacing the document while the old one still counts. Four habits make it cheap:
- Set review calendars from the alerts, not from memory. Orbit derives per-number expiry alerts from the
expires_attimestamps already stored — sorted most-urgent first, each row naming the binding expiry and a suggested action (renewvs.renew_or_release). The default 30-day look-ahead window is tunable per organization. - Renew using the same document type and role. Renewal is a swap, not an edit: fresh upload, same role attach, old one detached. Doing it inside the valid window never leaves the profile uncovered.
- Batch by expiry month. Because one
doc_…ID can back many profiles, a single passport renewal fixes the German number profile, the French Sender ID, and the RCS agent in one upload. Group your expiries by document, not by filing. - Never delete before detaching. Deleting a document is refused while any profile still references it — detach first. The refusal is the platform stopping you from silently breaking every filing the document backed.
Get these four right and KYC becomes a scheduled admin task measured in minutes per quarter, not a surprise audit.
The platform carries the documents; the decision stays with the regulator
One boundary should be explicit in any KYC conversation, and it is deliberately designed this way:
| Devotel Orbit (the platform) | You (the tenant) |
|---|---|
| Encrypts and stores each document once, scoped to your organization. | Supply truthful, current documents in the first place. |
| Carries the profile and its documents to each carrier and reports the review status. | Choose which profiles a document backs, and in which role. |
| Flags documents approaching or past expiry per number. | Upload replacements and re-attach before a document lapses. |
| Enforces the gates — unsatisfied profiles don't activate numbers. | Keep structured profile fields accurate as your business details change. |
Orbit never invents a document, never auto-renews one, and never promises a regulator's answer. The regulator is verifying your identity; the platform's guarantee is narrower and more useful: a document you supply once is reusable everywhere it's accepted, and you'll see its expiry coming with enough lead time to act.
Where to go next
The full reference — endpoint surface, document types, roles, expiry-alert tuning, and the country-requirement matrix — is the KYC Documents & the Compliance-Profile Lifecycle docs page. Start there, run a regulatory preview for the countries on your roadmap, and upload the four document classes before your first number purchase. The only onboarding surprise left will be the one the regulator creates — and that one at least arrives with a checklist in hand.