FCC Robocall Mitigation Database Checker & Change Monitor

Check and monitor FCC Robocall Mitigation Database status across a provider portfolio.

Give it a watchlist of U.S. voice, gateway and intermediate providers. Each run downloads one validated snapshot of the official FCC RMD current list, matches every provider by RMD number, FRN or exact business name, and returns one explicit row per input: listed or not, provider roles, STIR/SHAKEN implementation, recertification date, and in monitor mode exactly what changed since the last successful check.

Also searched as: RMD lookup, FCC RMD API, robocall mitigation database check, STIR/SHAKEN provider status, FRN lookup, KYUP counterparty check.

Use from AI agents with MCP

Connect the public Actor directly at https://mcp.apify.com?tools=automa-flow/fcc-rmd-provider-monitor. Ask your agent to verify a provider portfolio and preserve the Actor's explicit SUCCESS, NOT_FOUND, AMBIGUOUS, FAILED and INVALID_INPUT states in downstream decisions.

Why providers run this

Downstream providers use the RMD to decide whether traffic from an upstream partner may be carried at all, and FCC rules require RMD filings to stay accurate and to be recertified each year. Filings do get removed: during a single afternoon of source research, five providers disappeared from the current list in four minutes, all of them without a recertification date.

Checking one provider by hand is easy. Checking 300 interconnect partners every morning, and noticing the one that vanished overnight, is not.

Primary use cases

1. Bulk FCC RMD provider lookup - resolve hundreds of providers in one run.
2. Verify upstream and interconnect providers before accepting or continuing traffic.
3. Monitor provider listing changes - catch a partner that disappears from the current list.
4. Detect STIR/SHAKEN implementation changes - complete, partial, none or not applicable.
5. Track RMD recertification updates as filings are recertified through the annual cycle.
6. Feed changes into telecom compliance workflows by webhook, schedule or the Apify API.

Input

{
  "providers": [
    { "rmdNumber": "RMD0001410", "reference": "upstream-001" },
    { "frn": "0018570812", "reference": "interconnect-002" },
    { "businessName": "Infobip Voice, Inc.", "reference": "name-review" }
  ],
  "mode": "snapshot"
}

Each provider needs at least one of rmdNumber, frn or businessName. reference is your own key and is echoed back unchanged. Up to 5,000 providers per run.

Field	Default	Meaning
providers	required	1-5,000 watchlist entries
mode	snapshot	monitor also returns changes since the last successful check
monitorId	none	Required in monitor mode; names the stored baseline
onlyChanges	false	Blanks details of unchanged providers, still one row per input
includeAliases	true	Other FRNs, other and previous d/b/a names
includeBusinessAddress	false	The filed company address

Matching

rmdNumber is tried first, then frn, then an exact normalized businessName. Nothing is fuzzy-matched. In the live registry 18 FRNs and 96 business names belong to more than one current filing; those return AMBIGUOUS with candidate_rmd_numbers, so you can re-run against the exact filing rather than trusting a guess.

Output

One row per input provider, always, including invalid, ambiguous and failed checks.

{
  "source": "fcc_rmd",
  "source_id": "RMD0001410",
  "source_url": "https://fccprod.servicenowservices.com/rmd?id=rmd_form&table=x_g_fmc_rmd_robocall_mitigation_database&sys_id=...&view=sp",
  "scraped_at": "2026-09-03T19:22:00Z",
  "schema_version": 1,
  "fingerprint": "5c1f...",
  "reference": "upstream-001",
  "status": "SUCCESS",
  "matched_by": "RMD_NUMBER",
  "listed": true,
  "rmd_number": "RMD0001410",
  "frn": "0021441233",
  "business_name": "Piratel llc",
  "country": "United States of America",
  "foreign_provider": false,
  "provider_roles": ["VOICE_SERVICE_PROVIDER", "GATEWAY_PROVIDER", "INTERMEDIATE_PROVIDER"],
  "stir_shaken_implementation": "COMPLETE",
  "last_updated": "2026-02-17",
  "last_recertified": "2026-02-17",
  "changed": false,
  "changes": [],
  "alerts": []
}

status is one of SUCCESS, NOT_FOUND, AMBIGUOUS, FAILED or INVALID_INPUT. These mean different things and never collapse into each other:

• NOT_FOUND with listed: false is a verified absence: the snapshot downloaded, validated and did not contain that identifier.
• FAILED means the source could not be verified. It says nothing at all about whether the provider is listed, and it never overwrites a stored baseline.

Every row carries scraped_at, schema_version and a fingerprint over the regulatory fields only, so rows are append-only observations you can diff, deduplicate and keep as history.

Monitor mode

{
  "providers": [{ "rmdNumber": "RMD0001410" }, { "frn": "0018570812" }],
  "mode": "monitor",
  "monitorId": "carrier-portfolio",
  "onlyChanges": true
}

The first run stores a baseline and reports change_type: "BASELINE" with changed: false. Later runs compare against the last successful observation and emit deterministic events:

Event	Meaning
PROVIDER_NO_LONGER_LISTED	Was in the current list, now absent
PROVIDER_LISTED / PROVIDER_RELISTED	First appearance, or a return after an absence
ROLE_ADDED / ROLE_REMOVED	Voice, gateway or intermediate role change
IMPLEMENTATION_CHANGED	STIR/SHAKEN implementation moved
NEW_RECERTIFICATION_OBSERVED	A recertification date appeared for the first time
RECERTIFICATION_DATE_CHANGED	The recertification date moved
FILING_UPDATED	The filing's last-updated date moved
BUSINESS_NAME_CHANGED, FRN_CHANGED, COUNTRY_CHANGED, FOREIGN_PROVIDER_CHANGED	Identity and jurisdiction
ALIAS_ADDED / ALIAS_REMOVED, PREVIOUS_NAME_ADDED / PREVIOUS_NAME_REMOVED, OTHER_FRN_ADDED / OTHER_FRN_REMOVED	d/b/a and related-FRN changes
ADDRESS_CHANGED	The filed company address changed

A failed or ambiguous check never becomes a change event and never replaces the baseline, so a bad source day cannot invent a wave of removals.

Schedule it

Create the run once, then schedule it in the Apify console:

• Daily at 07:00 UTC - 0 7 * * *, mode: "monitor", onlyChanges: true.
• Weekly on Monday - 0 7 * * 1 for a slower-moving portfolio.

The FCC publishes changes continuously, so daily is the useful cadence for interconnect partners and weekly is usually enough for a vendor list.

Webhook on changes

Add an Actor webhook for ACTOR.RUN.SUCCEEDED pointing at your endpoint, then read the change-only view:

https://api.apify.com/v2/datasets/{{resource.defaultDatasetId}}/items?view=changes&clean=true

Each unwound row is one change event with its provider, ready to post into a ticket, a Slack channel or a compliance queue.

Call it from the API

curl -X POST "https://api.apify.com/v2/acts/<username>~fcc-rmd-provider-monitor/run-sync-get-dataset-items?token=$APIFY_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{
        "providers": [{"rmdNumber": "RMD0001410"}, {"frn": "0018570812"}],
        "mode": "monitor",
        "monitorId": "carrier-portfolio"
      }'

Other useful views: ?view=alerts&clean=true for PROVIDER_NOT_LISTED and IDENTIFIER_MISMATCH, and ?view=diagnostics&clean=true for status and error triage. The run summary, including snapshot row count and validation warnings, is written to RUN_SUMMARY in the run's key-value store.

Pricing

Pay per event: provider_checked, $0.02 per resolved provider, about $20 per 1,000 providers.

A provider is charged at most once per run, and only when the run produced a verified answer from a fully validated snapshot: a matched filing, or a confirmed absence from the current list. A confirmed absence is charged because it is the answer carriers act on, and it takes the same validated snapshot to establish.

Never charged: ambiguous identifiers, invalid input, retries, source failures, the snapshot download itself, Dataset writes and Key-Value Store operations.

Platform usage is included in the event price. There is no run-start charge and no charge for an Actor run that cannot produce a verified provider answer. A $2 maximum total charge funds up to 100 resolved checks; the actual bill can be lower when an identifier is invalid or ambiguous, or when the source fails.

Because one snapshot serves the whole watchlist, a run costs the same to the platform whether it checks 1 provider or 5,000. Larger batches are dramatically better value per provider.

Source and freshness

The Actor reads the FCC's public current-list CSV, the same file the RMD portal offers for download. No login, no API key, no CAPTCHA, no browser and no proxy. One request per run, requested compressed, roughly 1.2 MB on the wire for about 11,400 current filings.

Before a single provider is classified, the snapshot must pass validation: a complete compressed stream verified against its CRC and length, the expected columns and known field vocabulary, zero structurally unreadable rows, a minimum row count, and a comparison against the previous run's row count. Invalid FRNs and unknown role, implementation, foreign-provider or date values fail the run instead of being converted into a false regulatory change. A row-count collapse also fails rather than reporting that half the database was removed; additive schema drift and smaller unusual row-count drops are reported as warnings in the run summary.

Limits worth knowing

• This is an independent service and is not affiliated with the FCC. Data comes from the public FCC Robocall Mitigation Database.
• Being listed is not a compliance opinion, and absence from the current list is not proof of enforcement removal, voluntary withdrawal or wrongdoing. The Actor reports source facts and nothing beyond them. Output is informational and is not legal advice.
• Two thirds of current filings publish no recertification date, so the Actor exposes last_recertified and reports when it changes, but never infers an "overdue" verdict.
• Filing contact names, titles, departments, phone numbers, extensions, contact addresses and contact countries are published by the source but are never collected, returned or stored. The company address is available only if you switch includeBusinessAddress on.
• Robocall mitigation plan documents are not downloaded or analyzed.
• The RMD covers current filings only. This Actor does not submit or amend filings, and does not enrich from Form 499, enforcement dockets or the covered list.