FCC Robocall Mitigation Database (RMD) certification
If your organization originates US outbound calls, the FCC’s Robocall Mitigation Database (RMD) requires you to file a robocall-mitigation certification and keep it current. Terminating carriers must refuse traffic from providers whose certification is missing or deficient — so an absent filing can stop downstream carriers from accepting your calls at all. The console at Settings → Compliance → RMD (/settings/compliance/rmd)
is where you prepare the filing, track its lifecycle, and watch the
recertification clock. Every control here is tenant-owned: you draft the
certification, you file it with the FCC, and you keep it current. Orbit
records the state for your audit trail — this page does not transmit to the
FCC or wire a carrier on your behalf. Restricted to owner and admin
roles.
1. Who needs a filing — and where it shows up downstream
47 CFR § 64.6305 requires every voice service provider to hold a current RMD certification before traffic terminates in the US. Scope is US outbound voice only — messaging, email, and non-US voice are out of RMD scope. If you do not place US calls at all, this obligation does not apply to you. Two places your RMD record surfaces downstream:- Intercarrier reviews. When you onboard a carrier or vendor, they verify your RMD record as part of STIR/SHAKEN attestation (see STIR/SHAKEN attestation). A missing or stale record rejects the review before it starts.
- Traceback response. When a flagged call routes back to you, an absent or deficient filing sharpens the ITG’s position — see ITG traceback workflow for the full response workflow.
2. Open the console
Go to Settings → Compliance → RMD. The page has two cards: your registration (or an invitation to start one), and below it the Call-time origination enforcement setting. That second setting is opt-in and off by default — do not switch it to Enforce while you are still drafting, or Orbit blocks every outbound call on this organization.3. Prepare the certification
The FCC filing needs five pieces of company information. Assemble them before you open the form so you are not drafting by guess:
Match the entity details to your
Organization KYC profile before you
submit. The most common validation loop with carriers is a name or address
mismatch between the filed entity and the KYC record — identical spelling,
not just “close enough”.
4. File it — the lifecycle
The certification moves through a five-state lifecycle. Orbit renders the live status as a badge on the registration card, and only the actions legal from the current state show as buttons.
Before you submit, the form enforces completeness: the mitigation plan is
mandatory unless STIR/SHAKEN is complete, contact fields are required, and
the entity identity is present. A rejection after filing is typically a
deficiency the FCC or a carrier flagged — record it with Flag
remediation, correct the draft body (withdrawn and draft registrations
stay editable), and resolve.
The console also carries the recertification verdict on every read:
The default interval is 365 days; the form accepts a custom interval up to
3,650 days. A material change to your business details must be reflected in
the RMD within the 10-business-day window the console displays on the
registration card.
5. Keep it current
Three classes of change trigger a refiling — always within the 10-business- day update window:- Business details. Entity name, address, or OCN changed.
- Mitigation program. The robocall-mitigation plan you filed is revised (new vetting step, new monitoring tool, changed traceback SLA).
- STIR/SHAKEN status. Your implementation level changed — partial upgrading to complete drops the mandatory plan, for example.
Review due soon and then Recertification overdue, and the
update window readout on the card reminds you how long you have to reflect
a material change. Treat Review due soon the way you treat an expiring
cert — book the review before it flips overdue.
6. The certification id and how it interacts with traceback
After you file with the FCC, store the confirmation or filing id in the Filing reference field (you get the prompt on Submit, and again on Mark active). That reference is what carriers ask for when they verify your record, and what you cite back when a traceback reviewer asks which filing covers the implicated traffic. For the traceback workflow itself, see ITG traceback workflow.7. One posture surface in a broader profile
RMD is one surface of your full compliance posture — the assembly that also carries your KYC record, your DPA/BAA papers, your sender registrations, and your policy scanners. Assemble that profile as one unit in Compliance profiles instead of managing each surface alone.Worked example: a healthcare org opening US calling
A clinic already handling EU voice signs a US customer and needs to originate US calls. Sequence:- Counsel confirms the organization files as the voice originator.
- The admin opens Settings → Compliance → RMD and starts a registration — fills the legal entity exactly as it appears in Organization KYC, declares STIR/SHAKEN partial (deployment in progress), and writes the mitigation plan describing patient-vetting and traceback-response SLAs.
- Because declaration is partial, the plan is mandatory — the form keeps it required.
- They file with the FCC, come back, click Submit filing, and paste the FCC confirmation id as the filing reference.
- Once the FCC publishes the record, they click Mark active. The
recertification clock starts; the badge shows
Current. - Six months later the mitigation program changes — new vetting step. They edit the draft plan inside the 10-business-day window, re-file at the FCC, and the record stays current.
Troubleshooting
Deep dives
- ITG traceback workflow — the downstream surface your RMD record is cited back on.
- STIR/SHAKEN attestation — the signing your mitigation program complements.
- Organization KYC — the entity identity your filing must match.
- Compliance profiles — the assembly RMD sits inside.
- RMD registration API reference — the endpoint surface behind this console.