Skip to main content

​
Compliance Approval Timelines & Trigger Runbooks

Three FAQ pages share the compliance surface. This one keeps only the two things no other page carries: the timeline table that separates platform-paced setup minutes from external-paced approval queues, and the trigger-event runbook routes for the three incidents a compliance officer actually gets paged about. Everything else routes:
  • Which gate fired (a rejected send, a blocked call, a pending registration) — the routing FAQ.
  • Which gates fail open, which fail closed, and who owns each control — the posture FAQ.
  • Per-topic questions — the topic’s canonical deep page, linked per section below.
This page describes Orbit’s platform controls. It is not legal advice. Which laws apply to your traffic, and what posture is adequate, depends on your jurisdiction, your recipients, and what you send. Confirm with qualified counsel.

​
Timeline realism: what is platform-paced vs external-paced

The single most common compliance-planning error is modeling an externally-gated step as an instant, platform-paced step. Split every topic’s path into the two halves below, and budget the external half first.

​
Per-market sender-ID timeline reference

External-paced windows are estimates, not guarantees — regulator and carrier backlogs shift. Budget the conservative column and start early. Markets not listed follow the general sender-ID flow on the Sender-ID country matrix; the per-destination registration level (none / recommended / required) reads live from GET /api/v1/compliance/country-requirements. Only two topics (TCPA quiet hours, STIR/SHAKEN delegate certs) have no externally-gated step at all. The per-topic sections below deep-link into the canonical page for each topic instead of re-answering it.

​
10DLC — canonical deep pages

​
TCPA quiet hours — canonical deep pages

  • The TCPA federal voice guard — the one platform-owned gate: which controls are the platform’s (federal 8 AM–9 PM recipient-local window, state overlays) and which are yours to flip (per-channel org gate, campaign fallback, consent_overrides_quiet_hours).
  • Quiet-Hours Preview — GET /compliance/quiet-hours/preview returns the resolved window and the DST-safe next_allowed_at UTC instant before a send is attempted.
  • Troubleshooting: state mini-TCPA blocked calls — the TCPA_STATE_DIALING_WINDOW_BLOCKED / TCPA_TIMEZONE_UNKNOWN codes decoded.
    • #error-codes — which code fires when and the recourse for each.

​
GDPR / DSAR — canonical deep pages

  • DSAR — the intake/verify/fulfil workflow and the per-regulation deadline table: GDPR 30 days, CCPA/CPRA 45, PDPA 30, PIPEDA 30, DPDP 30. No external approval queue — the clock that matters is statutory, and identity-verification plus fulfilment stay with your compliance function.

​
STIR/SHAKEN — canonical deep pages

​
HIPAA / BAA — canonical deep pages

  • BAA — the execute → expire → re-execute state machine, the e-sign pipeline, and the days_until_expiry countdown.
  • HIPAA posture guide — the execute-order: BAA countersigned (yours, days-to-weeks of counsel) → HIPAA mode flips on (PUT /api/v1/settings/hipaa once GET /api/v1/compliance/baa reads executed) → follow-on controls. Until then PHI-bearing sends reject with 422 HIPAA_BAA_REQUIRED fail-closed.
    • #execute-order — the dependency chain and why BAA must be executed first.

​
Sender-ID country rules — canonical deep pages

  • Sender-ID Registration — the filing workflow; approval is granted by the regulator or carrier in that country, not the platform.
  • Sender-ID country matrix — the market list; per-country approval queues don’t batch, so treat sender-ID as a per-destination planning item.
    • #market-table — the per-market registration levels and sender-ID types.
  • Country requirements — GET /api/v1/compliance/country-requirements reads the per-country registration level (none / recommended / required).
    • #api-endpoint — the live per-country read and the registration field.

​
KYC documents — canonical deep pages

  • KYC documents — the packet lifecycle: upload, compliance-profile assembly, expiry alerts, rotation. The numeral fact: a regulated-country number idles at pending_compliance until an approved profile satisfies it, and an incomplete packet resets the review clock — attach the country’s KYC documents up front.
    • #packet-lifecycle — upload → assemble → validate → expire → rotate.
    • #expiry-alerts — the numbers.document_expiry_alert_days dashboard banner and renewal window.
  • KYC profile submission runbook — the step-by-step re-submission flow, failure-mode pointer table, and combo coverage matrix for the four destination types a compliance profile services.
  • Opt-Out & Suppression Lists — scope semantics: a phone row defaults to scope all, an email row to email; the scope mismatch (importing the CSV with the wrong channel) is the one case where an imported opt-out doesn’t gate what you expected.
  • Send Gates → preference center — the preference-center, Consent API, and STOP-keyword entry points; all write the suppression ledger in one transaction and a suppressed address is dropped pre-dispatch.

​
Trigger events — three real incidents, runbook-routed

​
My campaign got flagged — which runbook covers the recourse?

Route by the error code family, then to the runbook. A 422 POLICY_VIOLATION names the matched rule in its details payload — that is the pre-send policy scanner refusing on a keyword hit, not a registration gate. A 422 COMPLIANCE_PROFILE_REQUIRED or …_NOT_APPROVED is the profile/KYC gate firing before dispatch. The full per-code routing table is on troubleshooting: compliance send-gate error codes, and the scanner’s rule taxonomy is on Spam keywords and content screening. For a carrier-side (not gate-side) flag such as a throughput drop, read Compliance Health Scores first — the ranked warnings array points to the sender about to be throttled before the traffic degrades.

​
A destination country changed its registration rule — do I re-file my profile?

Yes — a country-rules feed refresh never rewrites a filed profile; it lands in the structural columns of the country table only, so when a destination raises its registration level (say, recommended → required) the new rule applies to existing traffic immediately and you file against the new rule, not a protected profile you were carrying. The current per-country level reads on GET /api/v1/compliance/country-requirements; what a refresh can and cannot change is on Country rules auto-refresh feeds, and the re-filing flow on Sender-ID Registration. A rejected row is recourse by re-submission, not re-verification: read the reviewer notes, fix the cited gap, and re-file.

​
My BAA expires in 60 days — what do I do before the PHI gate closes?

Execute the re-sign flow now — once days_until_expiry reaches 60 the dashboard shows the re-execute banner and the owner-only execute flow reopens, so an executed BAA doesn’t have to lapse before you re-file it. Past expires_at the status reads expired and the PHI send gate closes fail-closed again until re-execution; the re-derive is from the stored baa_executed_at timestamp on every read, so a missed daily cron doesn’t quietly extend coverage. The re-execute runbook is on the BAA page and the state machine’s days_until_expiry field carries the countdown.
None of the above is legal advice. Orbit is the conduit and the ledger: it carries your sends, enforces the gates you set, and keeps the auditable record (consent decisions, suppression entries, scrub results, certifications). It does not decide that a send is compliant, does not file with a regulator for you, and does not send customer notices for you. Confirm your obligations with qualified counsel.