Skip to main content

​
Regulated number-purchase compliance packets

In most countries a phone number activates the moment you buy it. In ten markets the carrier reviews a compliance packet first: business documents, identity proof, and a set of structured fields on your compliance profile. This guide lists exactly what to prepare for each regulated market, so the purchase preview passes on the first attempt instead of after a carrier round trip.

​
One registry, ten regulated markets

Buying a local, mobile, or toll-free number in DE, GB, FR, BR, MX, IN, JP, FI, NL, or SE runs the regulated preflight: the buy flow (and GET /numbers/regulatory-preview, documented on Regulatory Preview) evaluates the country and number type against your organization’s compliance profiles and returns compliance_profile_satisfies.
  • compliance_profile_satisfies: true — an approved profile already covers every required field and document for that market; the purchase proceeds like an unregulated one.
  • compliance_profile_satisfies: false — complete the packet below for that country first. Buying anyway debits the number into pending_compliance, where it routes nothing until a satisfying profile is attached (see Satisfy the preview before you buy).
Every other country is unregulated for purchase: the preview returns unregulated: true, no documents are requested, and the number activates instantly. The ten regulated markets share one base packet and differ only in the additions each market’s section below names, so a profile you built for one country is most of the way to any other.

​
The shared base packet

Every regulated market collects the same base: two required documents plus the business identity fields, and two prompted disclosure fields. The last two are optional in the strict sense but prompted on every regulated purchase, and they are the two fields most often left blank. Carriers that review regulated bundles return a “requirements partially completed (3/6)” style rejection when the identity half of the packet is fine but the website and use-case disclosures are missing, and that rejection loops until the disclosures exist on the profile. Fill both on every packet, even where the market’s section below never mentions them. Required versus prompted matters at the preview: compliance_profile_satisfies enforces the required slots, so a profile missing a required document or field fails the preview and blocks a clean purchase. Prompted (optional) slots never block the preview; the wizard prompts for them so the carrier’s review does not stall on a partially completed bundle.

​
Germany (DE)

  • Document roles: business_doc (required), address_proof (required), id_proof (required).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration or vat_certificate for business_doc (a Handelsregister extract); utility_bill, bank_statement, lease_agreement, or proof_of_address for address_proof (a Garanturkunde / rent registration counts as lease_agreement); passport, id_card, or drivers_license for id_proof.
The upload-to-attachment walk for the German address proof (Garanturkunde as lease_agreement) is in The KYC Identity Model.

​
France (FR)

  • Document roles: business_doc (required), address_proof (required), id_proof (required).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration for the Kbis (the registry extract issued by the Greffe du Tribunal de Commerce); proof_of_address or utility_bill for the justificatif de domicile; passport, id_card, or drivers_license for id_proof.
The Kbis and justificatif uploads are worked end-to-end in The KYC Identity Model.

​
United Kingdom (GB)

  • Document roles: business_doc (required), address_proof (required), id_proof (prompted).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration or vat_certificate (Companies House certificate); utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.
The UK carrier requirement is one compound ask: a local government-issued ID/passport copy or a company registration certificate. Orbit therefore prompts both inputs. Attach the company registration as business_doc, or satisfy the identity branch with a passport or national ID as id_proof; either proof completes the compound requirement, while address_proof stays required alongside.

​
Japan (JP)

  • Document roles: business_doc (required), address_proof (required), id_proof (prompted).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration (a certified registry extract, e.g. a tokibo now); utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.
Japan runs the same compound rule as the UK: the carrier accepts either the company registration or a government-issued ID/passport, so business_doc is required and id_proof is prompted as the substitutable branch.

​
Finland (FI)

  • Document roles: business_doc (required), address_proof (required), id_proof (prompted).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration or vat_certificate (YTJ trade register extract); utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.
Finland runs the same compound rule as the UK and JP: company registration or government-issued ID, with business_doc required and id_proof prompted as the alternative branch.

​
Netherlands (NL)

  • Document roles: business_doc (required), address_proof (required), id_proof (prompted).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration or vat_certificate (KvK extract); utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.
The Netherlands runs the same compound rule as the UK, JP, and FI: company registration or government-issued ID, with business_doc required and id_proof prompted as the alternative branch.

​
Brazil (BR)

  • Document roles: business_doc (required), address_proof (required), id_proof (required), plus the authorization role (prompted): a signed letter from a company director authorizing the contact person, uploaded as power_of_attorney (or other).
  • Structured fields: the shared base packet plus cnpj (required), the business registry number issued to every Brazilian legal entity.
  • Accepted types: business_registration or vat_certificate; utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license; power_of_attorney or other for the authorization letter.
Attach the authorization letter whenever the carrier review asks for one; the wizard prompts the role alongside the required cnpj field.

​
Mexico (MX)

  • Document roles: business_doc (required), address_proof (required), id_proof (required).
  • Structured fields: the shared base packet plus rfc (required), the tax identifier SAT issues to every registered entity. The RFC travels as profile data, not as a document.
  • Accepted types: business_registration (the acta constitutiva or registry extract), vat_certificate; utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.

​
India (IN)

  • Document roles: business_doc (required), address_proof (required), id_proof (required).
  • Structured fields: the shared base packet plus gstin (required) and pan (required). Both travel as profile data; the preview flips compliance_profile_satisfies only once both are present.
  • Accepted types: business_registration (certificate of incorporation), vat_certificate; utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.

​
Sweden (SE)

  • Document roles: business_doc (required), address_proof (required), id_proof (required).
  • Structured fields: the shared base packet; no market additions.
  • Accepted types: business_registration or vat_certificate (Bolagsverket extract); utility_bill, bank_statement, lease_agreement, or proof_of_address; passport, id_card, or drivers_license.
Two Sweden-specific conditions: the address proof must be dated within 90 days of submission, and the end user must be physically present in Sweden at purchase time. Presence is recorded as an attestation during the purchase flow; no separate document is needed for it.

​
Satisfy the preview before you buy

Work the packet until the preview passes, then buy:
1

Upload the documents to your KYC library

POST /compliance/documents with the library type, the country_code, and the file. You get a doc_… ID per upload; the accepted type values and the role-to-type mapping are on KYC Documents.
2

Attach each document by ID and role

POST /compliance/compliance-profiles/:id/documents attaches a doc_… ID to the profile under its role (business_doc, address_proof, id_proof, authorization). Create the profile with use_case: phone_number_purchase and the market’s country code if you don’t have one yet.
3

Set the structured fields

PUT /compliance/compliance-profiles/:id/data with the base fields plus your market’s additions (cnpj, rfc, gstin + pan), and the two prompted disclosures, website and business_description.
4

Re-run the preview until it flips

Call GET /numbers/regulatory-preview with the country and number type after each update. When every required slot is filled and the attached documents are unexpired, compliance_profile_satisfies returns true and the purchase activates normally.
If you buy with compliance_profile_satisfies: false anyway, the number is debited but held at pending_compliance: it routes nothing until an approved profile is attached, and the carrier sets a verify-by window on the order. If the window expires while the number still waits, the carrier can auto-release it and return the inventory, so the number is lost as well as inert. The window and the recovery path are covered on Regulatory Preview and Number Lifecycle.

​
Rejected packet?

A carrier rejection names the requirement it could not satisfy. Read the reason against this page’s per-market section, fix the one slot it names (an expired address proof and a missing sub-allocation disclosure are the two common ones), and re-submit; the fix loop, including how to swap documents without breaking other consumers of the same doc_… ID, is on Carrier Rejection Feedback and the KYC Profile Submission Runbook.

​
Your packet, your accuracy

Orbit prompts for the packet, carries it to the carrier, and enforces the purchase gate; the documents and data are yours. Carriers and regulators in each country grant final approval, and the accuracy of what you submit, and renewing documents before they lapse, stays with your organization. This page documents what the platforms collect and how the gates behave; it is not legal advice and is not a compliance guarantee for any market.