The Robocall Mitigation Database and FCC Filing Requirements

The MSP's Guide to VoIP: Part 19 of 20

Disclaimer: This post is educational content about the FCC's Robocall Mitigation Database and associated filing requirements. It is not legal advice. Regulations change, interpretations vary, and your specific situation may differ from the general scenarios described here. Consult with a telecom attorney to determine how these regulations apply to your business.

If the previous post on STIR/SHAKEN was about how calls get authenticated, this post is about the regulatory infrastructure that sits behind that authentication, specifically the FCC's Robocall Mitigation Database (RMD) and the filing requirements that determine whether your voice traffic gets carried by downstream carriers or gets blocked at the interconnection point.

This is one of those topics that sounds like it only matters to large carriers, and then you discover that the obligations extend much further down the food chain than you expected. If you are providing interconnected VoIP (any VoIP service that connects to the PSTN) and originating voice calls in any capacity, you need to understand how the RMD works and whether you have a filing obligation.

What the Robocall Mitigation Database is

The Robocall Mitigation Database is a publicly accessible database maintained by the FCC that lists voice service providers and their certifications regarding STIR/SHAKEN implementation and robocall mitigation. It was established as part of the FCC's implementation of the TRACED Act, and its purpose is both regulatory and operational.

The regulatory purpose is to create accountability. By requiring voice service providers to publicly certify their compliance with STIR/SHAKEN mandates or describe their robocall mitigation programs, the FCC creates a record that can be used for enforcement. If a provider is identified as a source of illegal robocall traffic, the FCC can check whether they filed, what they claimed in their filing, and whether their actual practices match their claims.

The operational purpose is more immediately consequential for your day-to-day business. Under FCC rules, intermediate and terminating carriers are generally required to block voice traffic from voice service providers that do not have an active filing in the RMD. This is not a theoretical enforcement mechanism. It is an automated one. If your filing lapses or you never filed at all, carriers downstream in the call path may be required to block your traffic. The result is that your clients' calls simply do not complete.

The database is publicly searchable at the FCC's website. Anyone can look up a provider and see whether they have an active filing, what type of filing they made, and when it was last updated. This transparency is intentional, allowing carriers to verify filing status before accepting traffic, and it allows end users and other stakeholders to check their provider's compliance.

Who needs to file

The filing requirement applies broadly to voice service providers, and the definition of voice service provider for RMD purposes has been discussed in Post 17. The general rule is that if you provide interconnected VoIP and originate voice traffic that enters the PSTN, you should evaluate whether you have a filing obligation.

The FCC has identified several categories of entities that are generally expected to file:

Facilities-based carriers that operate their own switching and transmission infrastructure. These are the traditional phone companies and VoIP carriers that most people think of when they hear "voice service provider."

Non-facilities-based providers that originate voice traffic through other carriers' infrastructure. This includes resellers, over-the-top VoIP providers, and entities that use SIP trunking to originate calls but do not operate their own network infrastructure.

Intermediate providers that receive and forward voice traffic between other providers. These are the transit carriers and tandem switches in the middle of the call path.

Gateway providers that receive calls from outside the United States and introduce them into the domestic telephone network.

The category that catches MSPs off guard is the second one. If you are originating calls through a SIP trunk, even if you do not own the trunk infrastructure and even if you think of yourself as a small IT company, you may fall into the category of a non-facilities-based provider that has a filing obligation. The determination depends on the specific facts of your operation and the contractual structure with your trunk provider.

Some MSPs are clearly covered by their upstream provider's filing. If you are reselling a white-label hosted platform and the wholesale provider is the entity that originates calls onto the PSTN, the wholesale provider's filing generally covers the traffic. You are not independently originating calls; you are using the provider's platform, which originates calls on the provider's trunks under the provider's authority.

Other MSPs have a less clear picture. If you operate your own PBX, contract directly with a trunk provider, and originate calls from your infrastructure through that trunk, you may be the originating provider for RMD purposes, even though the trunk provider handles the actual PSTN interconnection. The trunk provider's filing covers the trunk provider. It does not necessarily cover you.

This is the kind of determination that benefits from the telecom attorney consultation we recommended in the previous post. The cost of getting a definitive answer is small. The cost of getting it wrong is not.

What a filing contains

An RMD filing is not a complex legal document. It is a structured certification that contains several key elements:

Provider identity. The name of the voice service provider, contact information, FCC Registration Number (if applicable), and your Operating Company Number (OCN) if you have one. The OCN ties your filing to your identity in the broader telephone network's billing and routing systems. This is the basic "who are you" information.

STIR/SHAKEN implementation status. The provider certifies one of the following:

• They have fully implemented STIR/SHAKEN and are signing outbound calls with the appropriate attestation levels. This is the preferred certification for providers that are subject to the STIR/SHAKEN mandate.

• They have partially implemented STIR/SHAKEN (for example, they sign some but not all calls, or they sign calls on some but not all parts of their network). In this case, they describe what they have implemented and what remains.

• They have not implemented STIR/SHAKEN but have implemented a robocall mitigation program. This option is available for smaller providers and others that qualify for an exemption from the STIR/SHAKEN mandate. In this case, they must describe their robocall mitigation program.

Robocall mitigation program description. If the provider has not fully implemented STIR/SHAKEN, they must describe the specific practices they use to prevent illegal robocall traffic from originating on their network. This includes call analytics, traffic monitoring, customer vetting procedures, and other measures.

Commitment to cooperate with traceback. The provider certifies that they will cooperate with traceback requests from the Industry Traceback Group (ITG) or other authorized entities. Traceback is the process of tracing the origin of illegal robocalls back through the network to the originating provider. When the ITG identifies suspicious traffic, they send traceback requests to providers in the call chain, and each provider is expected to respond with information about where the traffic came from.

This commitment to cooperate is not optional or symbolic. The ITG conducts thousands of tracebacks, and providers that do not respond or respond slowly are flagged. Repeated failure to cooperate with tracebacks can lead to FCC enforcement action and can be cited by downstream carriers as a reason to block traffic.

Certifying official. A named individual at the provider who certifies under penalty of perjury that the information in the filing is accurate. This is not a rubber-stamp exercise. The certifying official is personally attesting to the accuracy of the filing, and making a false certification has legal consequences.

Filing cadence and what happens when a filing lapses

RMD filings are not one-time events. The FCC requires that filings be updated annually at minimum, and providers must update their filing whenever there is a material change to their STIR/SHAKEN implementation or robocall mitigation program.

The annual update requirement means that even if nothing has changed about your operations, you need to actively renew your filing. A filing that was accurate and complete on the day it was submitted becomes a lapsed filing if it is not renewed on schedule. And a lapsed filing, from the perspective of downstream carriers checking the database, looks the same as no filing at all.

When a filing lapses, the consequences can be swift. Carriers that check the RMD before accepting traffic (and they are required to under FCC rules) may begin blocking traffic from a provider with a lapsed filing. The blocking is not punitive in intent; the carrier is complying with its own obligation to not accept traffic from non-compliant providers. But the effect on the provider whose filing lapsed is the same as if they were deliberately blocked: calls stop completing.

The timeline from filing lapse to traffic disruption varies. Some carriers check filing status in real time or near real time. Others check on a periodic basis. But the trend has been toward more automated and more frequent checking, which means the window between a filing lapse and traffic disruption is shrinking.

Re-filing after a lapse is possible and the database will update relatively quickly once a new filing is submitted. But the disruption during the lapse period can be significant, particularly if your client base depends on outbound calling. Getting ahead of the renewal deadline is dramatically better than scrambling to re-file after your traffic has already been blocked.

Downstream consequences: what blocked traffic looks like

When carriers block your traffic due to a missing or lapsed RMD filing, the experience for your clients and their call recipients depends on how the blocking is implemented.

Hard blocking means the call is rejected at the network level. The originating provider (your trunk provider or your SBC) receives a SIP response indicating that the call cannot be completed. Depending on the specific response code used, your PBX may present this to the caller as a busy signal, a "call cannot be completed" message, or a generic failure. The caller knows the call did not go through.

Soft blocking means the call is accepted by the intermediate or terminating carrier but not delivered to the recipient. The call might be sent to a generic voicemail, dropped silently, or answered by an announcement. The caller may believe the call was delivered normally when it was not. This is harder to detect and harder to troubleshoot.

Selective blocking means that some carriers block your traffic while others still carry it. This results in a pattern where calls to some destinations work and calls to others do not. Your clients report that they can call some people but not others, and the pattern correlates with the terminating carrier rather than the geographic destination.

From a troubleshooting perspective, RMD-related blocking can look like a trunk issue, a routing issue, or a seemingly random failure pattern. If you are seeing widespread call completion failures that do not correlate with your network conditions or your trunk provider's status, checking the RMD filing status should be on your diagnostic list. This is especially true if the failures appeared suddenly without any changes to your infrastructure.

How to check whether your upstream carrier's filing covers you

If you are in a resale arrangement and you believe your upstream provider's filing covers your traffic, verify that assumption rather than relying on it.

Check the RMD directly. Go to the FCC's Robocall Mitigation Database and search for your upstream provider. Verify that they have an active filing and that it is current. Note the date of their last filing update and set yourself a reminder to check again before their renewal is due.

Read the filing. RMD filings are publicly accessible. Read your provider's filing and check whether it describes an arrangement that covers traffic originated by their resellers and downstream customers. Some providers explicitly address this in their filing. Others do not, which creates ambiguity.

Ask the provider directly. Contact your wholesale provider or trunk provider and ask explicitly: "Does your RMD filing cover traffic that I originate through your platform/trunks?" Get the answer in writing. If the answer is yes, ask them to point you to the specific language in their filing or their reseller agreement that supports this. If the answer is no, or if they are not sure, you have work to do.

Review your agreement. Your wholesale or trunk provider agreement should address regulatory compliance responsibilities. Look for provisions that allocate RMD filing obligations. If the agreement is silent on this topic, that is a gap that needs to be addressed, either through an amendment to the agreement or through your own independent filing.

Consider filing anyway. In ambiguous situations, some providers and their attorneys recommend filing in the RMD independently, even if you believe your upstream provider's filing may cover you. Having your own active filing eliminates the ambiguity and ensures that if there is a dispute about coverage, your traffic is not caught in the middle. Filing is not difficult or expensive, and the protection it provides against traffic disruption may justify it even if it turns out to be technically redundant.

The traceback process in practice

Traceback is the mechanism by which illegal robocall traffic is traced from the terminating carrier back through the network to the originating provider. The Industry Traceback Group, operating under authority delegated by the FCC, conducts these traces.

A traceback starts when a carrier, government agency, or analytics company identifies a robocall campaign. They provide call detail records (CDRs) to the ITG, which then sends requests to the carriers in the call path, working backward from the terminating carrier toward the originating provider. Each carrier in the chain is asked to identify where the traffic came from, specifically which upstream provider delivered it.

If the traceback reaches you, meaning you are identified as the originating provider or an intermediate provider for the traffic in question, you will receive a traceback request. The request will contain call detail information and will ask you to identify the source of the traffic. You are expected to respond promptly (typically within 24 hours for urgent requests) with the information requested.

For an MSP operating a voice business with legitimate business clients, a traceback request might seem alarming, but it is not necessarily a sign of trouble. Tracebacks can occur because a number assigned to one of your clients was previously used by a robocaller (number recycling), because a client's system was compromised and used to originate fraudulent calls, or because a downstream analytics engine incorrectly flagged legitimate traffic as suspicious.

The important thing is to respond. Cooperating with tracebacks is part of your RMD filing commitment, and failure to cooperate is taken seriously. If you receive a traceback request and you can demonstrate that the traffic was legitimate, or that you have taken action to address the source of illegitimate traffic, that is generally the end of it. If you ignore the request or refuse to cooperate, that creates a much more serious problem.

Having good records matters here. If you can quickly look up a phone number, identify which client it is assigned to, and pull call records for the time period in question, you can respond to a traceback efficiently. A Carrier Lookup can help you verify the current carrier assignment and number status when investigating a flagged number. If your records are disorganized or incomplete, a traceback response becomes a fire drill.

Practical enforcement reality

The FCC has been increasingly active in enforcement around robocall mitigation. They have issued cease and desist orders to providers identified as sources of robocall traffic, ordered downstream carriers to block traffic from specific providers, and imposed fines in egregious cases.

The enforcement landscape has also involved the FCC ordering intermediate carriers to stop carrying traffic from providers that have been identified as bad actors, even when those intermediate carriers were not themselves engaged in any wrongdoing. This cascading enforcement puts pressure on the entire chain, because carriers know that accepting traffic from non-compliant providers creates risk for their own operations.

For MSPs, the practical enforcement risk depends on scale and behavior. A small MSP with a few hundred seats of legitimate business VoIP is not in the same risk category as a wholesale carrier processing millions of calls per day. But the blocking mechanism does not discriminate based on the size of the provider. If your filing lapses, your traffic can be blocked regardless of whether you are originating ten calls per day or ten million. The automated nature of the compliance checking means that small providers face the same filing obligations as large ones.

The most likely enforcement scenario for an MSP is not an FCC investigation or a fine. It is the quiet, operational consequence of a missing or lapsed filing: traffic that stops completing, clients who cannot reach their customers, and a scramble to figure out why. By the time you trace the problem to an RMD filing issue, your clients have already experienced the disruption.

What this means for your operations

If you have determined (based on the analysis in Post 17) that you have an independent RMD filing obligation, here is what that means operationally:

Initial filing. Prepare and submit your RMD filing through the FCC's online system. This includes registering for FCC credentials if you do not already have them, completing the filing form, and having a certifying official submit it. The process is not complex, but it requires accurate information about your STIR/SHAKEN implementation or robocall mitigation program.

Annual renewal. Set a calendar reminder well in advance of your filing's anniversary date. Renew the filing before it lapses. Do not wait for the FCC to remind you. They may not, and a reminder that arrives after the filing has lapsed is too late to prevent traffic disruption.

Material changes. If you change your STIR/SHAKEN implementation, your trunk providers, or your robocall mitigation practices, update your filing to reflect the changes. The filing is supposed to accurately represent your current practices, not your practices as of the date you originally filed.

Traceback readiness. Maintain call records in a format that allows you to respond to traceback requests quickly. Know who your clients are, what numbers are assigned to them, and how to pull call records for a specific number and time period. Designate someone on your team as the point of contact for traceback requests so that they do not get lost in a general support queue.

Monitoring. Periodically check the RMD to confirm your filing is active. Check your upstream providers' filings as well. If you rely on multiple trunk providers, check each one. Set alerts for renewal dates across all providers in your chain.

The administrative overhead of maintaining an RMD filing is not large. The initial filing takes a few hours, the annual renewal takes less, and the ongoing maintenance is primarily about keeping records and staying aware of deadlines. Compared to the operational disruption that a filing lapse can cause, it is a small investment.

Next up: Keeping Your Clients' Calling Reputation Clean, covering the ongoing work of monitoring, maintaining, and defending your clients' phone number reputation in a world where analytics engines decide who gets flagged as spam.