> ## 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. # KYC console: business verification, document upload, and brand registration > Walk through Settings → KYC (/settings/kyc): what the console owns, how to submit and track business identity verification, how review and rejection handling work, and how KYC relates to onboarding status, carrier-side sender-ID registration, and Verify. # Settings → KYC The **KYC** console at `/settings/kyc` is where your organization completes business identity verification: you submit your business details, Devotel reviews them, and approval raises your sending limits and unlocks voice origination. This guide covers what the console owns, how to submit and track a verification, how rejections work, and where KYC ends and carrier-side brand registration or the Verify product begin. ## What the KYC console owns Three responsibilities live on this page: 1. **Business identity verification.** You declare who your organization is (company name, country, industry, use case, expected message volume) and Devotel reviews the submission. Approval is the gate to higher sending limits and voice origination. 2. **Document upload.** Where your deployment requires it, identity and business documents (for example a government ID, business registration, or utility bill) are collected here and passed through encrypted, carrier-specific formatting and submission. You can also confirm identity self-serve with a hosted government-ID and selfie liveness check when your deployment offers it. 3. **Brand registration.** Your submitted company name and website feed the brand vetting carriers perform before your traffic carrying your brand goes live. The KYC console is where you register that information; the carrier-side registration itself happens outside Orbit (see [KYC vs sender-ID registration](#kyc-vs-sender-id-registration-and-verify)). Verification is also an audit artifact: the approved state renders a printable summary (company name and approval badge) designed for SOC 2 binders and carrier onboarding paperwork, so the page you present to an auditor is the page you see at `/settings/kyc`. Only **Owner** and **Admin** roles can open the console. Developer, Supervisor, Agent, and Viewer seats do not see the tile, and the page re-checks the role server-side, so visibility is never the authorization boundary. ## Walkthrough of /settings/kyc ### Submitting a verification Open **Settings → KYC** and complete the form: | Field | Required | Notes | | - | - | - | | Company Name | Yes | The legal name reviewers and carriers see | | Company Website | No | Must start with `http://` or `https://` when provided; carriers use it for brand vetting, so leave it blank rather than entering a bare domain or plain text | | Country | Yes | Full ISO country list plus an "Other" escape hatch | | Industry | Yes | Fifteen options, from E-Commerce to Non-Profit plus Other | | How will you use the platform? | Yes | At least 10 characters describing your messaging use case | | Estimated Monthly Message Volume | Yes | One of five bands, from "Under 1,000" to "1,000,000+" | Click **Verify Account**. The submission moves to review and the page switches to the **In Review** state. You receive an email as soon as the verification is approved; no action is needed from you while it is under review. While a submission is in review you may also see a **Verify with government ID** card (when your deployment provisions the hosted identity check). Completing the government-ID and selfie capture adds a verified-identity signal to your file; it never grants approval by itself, the reviewer weighs it alongside your business details. If the card does not appear, your deployment does not offer it and nothing is missing from your submission. ### Verification timeline The page shows exactly one of four states: | State | What you see | What happens next | | - | - | - | | Not started | The submission form | Submit to start review | | In Review | A pending card plus the optional government-ID check | Devotel reviews; you are emailed on approval | | Rejected | The reviewer's reason, plus **Edit and resubmit** and **Contact support** | Fix the flagged details and resubmit | | Approved | A verified card with your company name and a **Print summary** action | Higher sending limits and voice origination are enabled | Review is a human-gated step; there is no fixed turnaround to plan against. The email-on-approval notice is the contract the console promises. ### Document types accepted What reviewers and carriers ask for depends on your country, industry, and the channels you activate. The common set: * **Government ID** of an authorized representative (passport or national ID), used by the hosted liveness check and by manual review. * **Business registration** or incorporation document matching the company name you submitted. * **Proof of address**, such as a recent utility bill, when a reviewer needs to confirm the registered address. Uploads are encrypted and formatted per carrier requirement before submission. If your file needs an additional document, the reviewer names it in the rejection or follow-up note, so you always know what to provide rather than guessing. ### Rejection handling A rejected submission shows the reviewer's reason on the page. Click **Edit and resubmit** to reopen the form; your previously submitted company name, country, and industry are prefilled so you only re-enter what changed. Resubmitting starts a new review and returns the page to **In Review**. If the reason is unclear, **Contact support** opens a mail to the support team with the rejection as the subject; include anything about your use case that the form could not carry. Common rejection causes and the fix for each: | Reason pattern | Fix | | - | - | | Website missing or not a URL | Add the site with the `https://` prefix, or leave the field blank | | Use case too thin | Describe who you message, over which channels, and how contacts opted in | | Company name mismatch | Use the exact legal name from your registration document | | Volume band inconsistent with the use case | Pick the band that matches the use case you described | ## Connection to Onboarding Status **Settings → Onboarding Status** is the org-wide provisioning timeline; KYC is one step on it. The two surfaces read the same verification record and answer different questions: * **Onboarding Status** shows where the whole organization stands against go-live: provisioning steps, verification progress, and the checklist of what remains before you can launch. See the [onboarding status timeline guide](/guides/onboarding-status-timeline). * **KYC** is where you act on the verification step: submit, resubmit, add the government-ID check, and print the approved summary. Nothing needs re-entering in two places. On a rejection, the KYC console carries the reason and the resubmit path, while Onboarding Status keeps showing the step as open until the new review approves. Tracking overall readiness happens on Onboarding Status; fixing or completing the verification happens on KYC. The [verifications timeline guide](/guides/verifications-timeline) covers reading verification progress across the org. ## KYC vs sender-ID registration and Verify Three different surfaces share vocabulary and are easy to conflate: | Surface | Where | Who runs it | What approval changes | | - | - | - | - | | KYC (this console) | `/settings/kyc` | Devotel reviews your business | Sending limits and voice origination on Orbit | | Sender-ID / brand registration | Carrier and aggregator side, often started from **Numbers** or **Compliance** surfaces | Carriers and national registries | Whether traffic carrying your brand or sender IDs is accepted on networks | | Verify | API product, [Verify overview](/verify/overview) | You, for your end users | Nothing about your account; it authenticates *your application's* users via OTP, TOTP, passkeys, and push | KYC approves your business to Devotel. Sender-ID and brand registration approve your brand to carriers: a carrier registry decides whether your name or shortcode may appear as the sender on a network, and some verticals require brand registration before campaign traffic is accepted. KYC feeds that process with your business details but does not replace it, and a carrier registration requirement does not imply a KYC problem, or vice versa. Channel-specific brand flows, such as RCS brand verification, keep their own guides (see [RCS brand verification](/guides/rcs-brand-verification-kyc) and the [organization KYC onboarding guide](/guides/organization-kyc-onboarding)). Verify is unrelated to both: it is the end-user authentication product your application calls over the API. The government-ID check inside KYC confirms *your* organization's identity; Verify confirms *your customers'* identity in your product. ## Tenant-owned posture KYC verifies who you are; it does not prescribe how you operate. Your compliance posture (quiet hours, consent practice, country rules) is configured by your organization under **Settings → Compliance**, and the KYC outcome adds no mandated claims to that posture. What verification does change is platform access: approved organizations get the sending limits and voice origination that unverified organizations do not, because carriers and regulators expect the sending business to be identifiable. If your vertical is subject to additional requirements (healthcare, finance, government messaging), those obligations remain yours to configure and document; the [compliance posture overview](/compliance/posture-overview) maps the controls you own. The KYC summary exists partly so you can evidence the identity step in your own audits, not because Orbit mandates a compliance program. ## See also * [Settings hub](/settings/overview) — the console map with routes and role gating for every Settings tile * [Onboarding status timeline](/guides/onboarding-status-timeline) — reading the provisioning and verification timeline * [Verifications timeline](/guides/verifications-timeline) — verification progress across the org * [Organization KYC onboarding](/guides/organization-kyc-onboarding) — the onboarding-side view of business verification * [RCS brand verification](/guides/rcs-brand-verification-kyc) — a carrier-side brand flow contrasted with KYC * [10DLC registration](/guides/10dlc-registration) — US campaign brand registration, a carrier-side process * [Verify overview](/verify/overview) — end-user authentication factors (separate product) * [Compliance posture overview](/compliance/posture-overview) — the tenant-owned compliance controls This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.