Putting the FCC’s Robocall Mitigation Database to Work

BACKGROUND

FCC’s 17-97 Second Report and Order (adopted 29-Sep 2020) instantiated the Robocall Mitigation Database. This new Database is expected to establish a chain of trust as calls flow from point of origination to termination through, potentially, a series of providers. Most importantly, if a provider abuses that trust, it gives the FCC a tool to shut down that provider by de-listing them from the RMD.

OPERATION

A reader of the Order would likely conclude that the expected flow for any call, with respect to the RMD, is as follows:

• The end-user caller presents the call to an Originating Voice Service Provider.
• The Originating VSP treats the call per applicable STIR/SHAKEN and/or Robocall Mitigation Program requirements and if met, sends the call onward.
• The next Provider in the call path sends it onward only if the source from which it received the call is in the Robocall Mitigation Database. This step iterates as required.
• The Terminating VSP delivers the call to the end-user recipient.

From this, we would expect each provider in the path (Originating Voice Service and any Intermediate Providers) will be listed in the RMD. The Order promises this; it says at Footnote 340: we give intermediate and terminating voice service providers confidence that any provider not listed in the Robocall Mitigation Database is out of compliance with our rules…

CONFUSION

Astute readers of the Order have raised concerns that the Order may be interpreted differently. Part of the concern stems from the underlying definitions:

• Voice Service Provider is not explicitly defined, but Voice Service per 47 CFR § 64.6300(l)(1): Means any service that is interconnected with the public switched telephone network and that furnishes voice communications to an end user using resources from the North American Numbering Plan or any successor to the North American Numbering Plan adopted by the Commission under section 251(e)(1) of the Communications Act of 1934….
• Thus, Voice Service Provider would presumably be a provider directly serving an end-user, and thus includes (only) Originating and Terminating Voice Service Providers.
• Intermediate Provider, as defined by reference in the Order, is any entity that carries or processes traffic that traverses or will traverse the [PSTN] at any point insofar as that entity neither originates nor terminates that traffic.

The Final Rules in the Order, at § 64.6305(c), state:

• intermediate providers and voice service providers shall only accept calls directly from a voice service provider … if that voice service provider’s filing appears in the Robocall Mitigation Database….

This mandate could be read to indicate that the restriction applies if the call source is an (Originating) Voice Service Provider but would NOT apply if the source is an Intermediate Provider. In other words, it appears that an Intermediate Provider is free to take traffic from another Intermediate Provider, even if that Intermediate Provider is NOT listed in the RMD.

However, were a downstream provider to implement that exclusion, and accept traffic from an unlisted provider, they would face at least two critical risks:

• Conflict with Footnote 340 quoted above, wherein the FCC guides intermediate and terminating voice service providers to expect their upstream sources to be listed in the RMD and noting that “any provider not listed in the RMD is out of compliance with our rules.” This says ANY PROVIDER (not just voice service provider) and so would include intermediate providers.
• Even more problematic is this from ¶151: We further determine that as with our interpretation of “providers of voice service,” we assess the definition of “intermediate provider” on a call-by-call basis for the purpose of our call authentication rules. A single entity therefore may act as a voice service provider for some calls on its network and an intermediate provider for others.

A downstream provider has no way of knowing whether its upstream source is acting as an intermediate provider or an originating voice service provider for a PARTICULAR call.

To ensure compliance with the Order, a downstream provider must either:

• Obtain a contractual commitment from a source that the source will send to that downstream exclusively calls that it obtained only from another intermediate provider or from an Originating Voice Service Provider listed in the database, ostensibly obviating the need for that source itself to be listed in the RMD. However, this is extremely risky, since there is no technical way to verify that the source did not, in fact, originate a given call or accept the call from an unlisted OVSP.
• Alternatively, require that EVERY source from which it accepts traffic is listed in the RMD. This is the only practical approach, since illegal robocalling by definition attracts parties that behave unlawfully and are least likely to adhere to contractual stipulations.

A FIX

At ¶83, the FCC directs the Bureau to establish this portal and database, provide appropriate filing instructions and training materials, and release a Public Notice when voice service providers may begin filing certifications. The below can be included in that release or be a response to CTIA’s pending PFR.

To reduce confusion while still meeting the objectives of the Order (shared by all stakeholders), the Bureau should clarify that a provider that operates EXCLUSIVELY as an INTERMEDIATE provider, NEVER originating calls on behalf of an end-user, and takes calls ONLY from other providers registered in the RMD, can itself register in the RMD and so indicate, should that registration not be imported from the Intermediate Provider Registry per Footnote 340.

This is consistent with ¶89, stating We see no clear need to impose a burdensome belt-and-suspenders paperwork requirement on providers that are already subject to this obligation by rule. The rules indeed state that if a provider DOES originate ANY calls, it will need to register AND CERTIFY in the RMD.

Should providers (including foreigners) attempt frivolous registrations, the FCC can tighten the requirements as necessary to retain the integrity of the system.

The FCC should further clarify that if a provider accepts calls from an UNREGISTERED source, then that accepting provider will be deemed the ORIGINATING PROVIDER for that call and must have in place the applicable programs, registrations, and certifications.

These clarifications would be consistent with the rest of the Order, including Footnote 340. It would give all providers what they need in terms of safely complying with the Order (only accepting calls from registered providers for calls that they do not themselves originate). And it would give foreign providers the OPTION of registering (and, as applicable, certifying) in the RMD, as an alternative to allowing their downstreams to originate their calls.

Perhaps most importantly, it ensures the enforcement effectiveness contemplated in Footnote 322.

USF/499-A ANALOGY

With the refinements outlined here, the framework of the Order will behave similarly to the time-tested approach used for collecting Universal Service Fund fees.

Service providers are responsible for assessing, collecting, and remitting USF. Any provider so obligated must annually file a Form 499-A.

Since the fee is only assessed once per call, it is not appropriate for an originating provider X to collect and remit the fee from its customer, to then have the downstream provider Y assess the fee and collect if from X, and so on down the line.

Thus, the industry has a process whereby provider X can certify to provider Y that it is collecting and remitting USF where applicable, and that X should be exempted from USF assessments by Y. This is exclusively an opt-in process. If X fails to make that certification, Y is obligated to remit USF for X’s calls.

Similarly, if X has a current, valid listing in the RMD, Y can serve as an intermediate provider for X’s calls. Otherwise, Y will be the originating provider for those calls.

IMPLEMENTATION SUGGESTIONS

In this context, we offer four technical implementation suggestions for the RMD:

• Include the provider’s 499-A Filer ID as a field in the RMD. This will serve as a unique, searchable identifier. As noted above, 499-A filer information is already routinely captured by providers accepting traffic from other providers. It need not be a required field but given the nature of the traffic at issue here, we would expect nearly all providers in the RMD to also be 499-A filers. There are numerous foreign providers with 499-A Filer IDs.
• Allow query access to the RMD via a web-based computer-to-computer interface. This will allow providers to determine, in real time, whether an upstream traffic source is (or still is) listed in the RMD. For reference, there is already such an interface to the 499-A database.
• As an option, allow a provider registering in the RMD to include an address for push notifications of provider de-listings. This would allow providers to immediately learn if an FCC enforcement action has caused a provider to be removed from the RMD. Notified providers would then be able to take timely action to reject traffic from that de-listed provider.
• Include in the RMD, for each listed provider, a registration category field, that would distinguish those providers imported from the IPR, vs. those that are exclusively intermediate providers, vs. those that are both originating and intermediate providers, etc.

REFERENCES FROM THE ORDER (excerpted from the FCC’s document)

¶ 81. Deficient Robocall Mitigation Programs. If we find that our non-prescriptive approach to robocall mitigation is not satisfactorily stemming the origination of illegal robocalls, we agree with NTCA and Verizon that we should be ready to impose more prescriptive obligations on any voice service provider whose robocall mitigation program has failed to prevent high volumes of illegal robocalls.321 We thus direct the Enforcement Bureau to prescribe more specific robocall mitigation obligations for any voice service provider it finds has implemented a deficient robocall mitigation program. Such robocall mitigation obligations would be chosen as appropriate to resolve the specific voice service provider’s prior shortcomings. In such instances, the Enforcement Bureau will release an order explaining why a particular mitigation program is deficient and, among other things, prescribe the new obligations needed to rectify those deficiencies, including any milestones or deadlines. We find that action by the Enforcement Bureau is appropriate in responding to issues on a case-by-case basis. If we find that our non-prescriptive approach to robocall mitigation programs is falling short on a widespread basis, we will not hesitate to revisit the obligations we impose through rulemaking at the Commission level.

FN322 As part of the penalties it may impose, the Enforcement Bureau may de-list a voice service provider from the robocall mitigation database we establish. See ZipDX Ex Parte at 4.

¶ 82. Voice Service Provider Certification and Database. To promote transparency and effective robocall mitigation, we require all voice service providers—not only those granted an extension—to file certifications with the Commission regarding their efforts to stem the origination of illegal robocalls on their networks.

¶ 86. Obligations on Intermediate Providers and Terminating Voice Service Providers. As suggested by multiple commenters, we prohibit intermediate providers and terminating voice service providers from accepting voice traffic directly from any voice service provider that does not appear in the database, including a foreign voice service provider that uses NANP resources that pertain to the United States to send voice traffic to residential or business subscribers in the United States. Effective 90 days after the deadline for robocall mitigation program certifications set forth in the Bureau Public Notice establishing the robocall mitigation database and portal, intermediate providers and terminating voice service providers are subject to this prohibition. The record reflects support for this requirement.

¶ 87. We agree with Verizon that, “by prohibiting downstream service providers from accepting traffic from providers that are not in [the database], the Commission can deny a service provider access to the regulated U.S. voice network if it determines that the service provider’s STIR/SHAKEN or robocall mitigation practices are inadequate.” In this way, we can police the voice traffic that voice service providers originate by removing or restoring a voice service provider’s listing on the database, after providing notice of any certification defects and providing an opportunity to cure.

¶ 89. We decline to adopt to USTelecom’s proposal that we require intermediate providers to file a certification to their compliance with this rule. We see no clear need to impose a burdensome belt-and-suspenders paperwork requirement on providers that are already subject to this obligation by rule. We similarly decline ZipDX’s proposal that intermediate providers must “[i]mplement[] a Robocall Mitigation Program applicable to calls [they do] not authenticate.” Pursuant to the TRACED Act, robocall mitigation is meant to stem the origination of illegal robocalls, and ZipDX does not explain specifically how an intermediate provider could itself prevent the origination of illegal robocalls. We find the rule we establish—whereby intermediate providers are prohibited from accepting traffic from an originating voice service provider that has not certified to a robocall mitigation program—best leverages the role of intermediate providers to combat illegal robocalls within our greater robocall mitigation scheme.

FN340: To ease compliance with this obligation, we will import all listings from the Intermediate Provider Registry into the Robocall Mitigation Database on a rolling basis so that all registered intermediate providers are represented therein. See FCC, Intermediate Provider Registry, https://opendata.fcc.gov/dataset/Intermediate-ProviderRegistry/a6ec-cry4/data (last visited Sept. 3, 2020); Third Rural Call Completion Order, 33 FCC Rcd at 8402-03, paras. 6-8 (establishing the Intermediate Provider Registry). Because intermediate providers that do not originate any traffic are not subject to our certification requirements, they would not otherwise be listed in the database. By affirmatively adding such providers we give intermediate and terminating voice service providers confidence that any provider not listed in the Robocall Mitigation Database is out of compliance with our rules, rather than leaving the potential for uncertainty about whether a provider is noncompliant or simply was not required to be included in the database because it does not originate traffic. A provider that serves as both an intermediate provider and originating voice service provider must file a certification with respect to the traffic for which it serves as an originating voice service provider, even if its listing has been imported from the Intermediate Provider Registry.

¶151. We adopt our proposal from the First Caller ID Authentication Report and Order and Further Notice to use the definition of “intermediate provider” found in section 64.1600(i) of our rules. This section provides that an “intermediate provider” is “any entity that carries or processes traffic that traverses or will traverse the [PSTN] at any point insofar as that entity neither originates nor terminates that traffic.” We further determine that as with our interpretation of “providers of voice service,” we assess the definition of “intermediate provider” on a call-by-call basis for the purpose of our call authentication rules. A single entity therefore may act as a voice service provider for some calls on its network and an intermediate provider for others.

64.6305 Robocall mitigation and certification….

(b) Certification and database. (1) Not later than the date established in a document released by the Wireline Competition Bureau establishing the Robocall Mitigation Database and portal (amending this paragraph (b)), a voice service provider, regardless of whether it is subject to an extension granted under 47 CFR 64.6304, shall certify…

(c) Intermediate provider and voice service provider obligations. Beginning ninety days after the deadline for certifications filed pursuant to paragraph (b) of this section, intermediate providers and voice service providers shall only accept calls directly from a voice service provider, including a foreign voice service provider that uses North American Numbering Plan resources that pertain to the United States to send voice traffic to residential or business subscribers in the United States, if that voice service provider’s filing appears in the Robocall Mitigation Database in accordance with paragraph (b) of this section.