Written by: Matt Beucler, CEO, Plura AI
Key Takeaways for Contact Center and CX Leaders
- The Foreign Robocall Elimination Act (S.2666) remains pending as of June 2026 and does not create immediate mandates, penalties, or international agreements for U.S. carriers.2
- Its primary mechanism is an interagency task force that will study foreign robocall origins and issue recommendations, not binding rules for operators.
- Active compliance pressure comes from the FCC NPRM (CG Docket No. 26-52) and existing state onshoring laws, which operate independently of S.2666.
- STIR/SHAKEN authentication gaps for foreign-originated calls persist because the bill does not extend enforcement authority beyond U.S. borders.
- Operators can reduce exposure today by moving to 100% U.S. FCC-licensed infrastructure, and booking a live demo with Plura AI shows how domestic carrier ownership addresses compliance requirements now.
Current Status and Timing of S.2666
S.2666, the Foreign Robocall Elimination Act, was introduced in the 119th Congress. As of June 2026, the bill has not passed either chamber and has not been signed into law. S. 2666 has been reported out of the Senate Committee on Commerce, Science, and Transportation and placed on the Senate calendar (Calendar No. 422) as of June 1, 2026. Companion legislation, including the Keep Call Centers in America Act (S.2495), follows a similar trajectory through the legislative calendar. Operators should consult qualified counsel regarding the current status of any pending legislation before making compliance decisions based on anticipated passage.
What the Interagency Task Force Actually Does
The bill’s central mechanism is an interagency task force charged with identifying the origins of foreign robocalls reaching U.S. networks, assessing existing enforcement tools, and producing recommendations for Congress and the FCC. The task force structure draws participation from multiple federal agencies, including the FCC and the FTC (Federal Trade Commission).
The operative word is “recommendations.” The task force produces a report. It does not issue binding carrier rules, impose fines on foreign originators, or create a private right of action for U.S. operators harmed by foreign robocall traffic. The Federal Register record for CG Docket No. 26-52 reflects that the FCC is already pursuing separate rulemaking on offshore call-handling practices, which moves on its own timeline independent of S.2666’s task force output.
Limits of International Cooperation on Robocalls
S.2666 faces the same structural challenge that has constrained prior attempts to suppress foreign robocall traffic. Enforcement requires cooperation from foreign governments, and that cooperation does not follow automatically from a U.S. statute.
Foreign call originators operate under the jurisdiction of their own national regulators. A U.S. law directing the FCC to negotiate international agreements does not compel a foreign government to act. Bilateral and multilateral agreements on telecommunications enforcement often take years to negotiate, ratify, and implement. During that period, foreign-originated traffic continues to enter U.S. networks through gateway carriers, and the legal tools available to U.S. regulators stop at the border.
STIR/SHAKEN (Secure Telephone Identity Revisited / Signature-based Handling of Asserted information using toKENs), the caller-ID authentication framework mandated by the TRACED Act (Telephone Robocall Abuse Criminal Enforcement and Deterrence Act), authenticates calls that originate on U.S.-licensed carriers. Calls entering U.S. networks from foreign originators frequently arrive without a valid STIR/SHAKEN attestation, or with a gateway carrier’s attestation that does not reflect the true call origin. S.2666 does not resolve this authentication gap.
How S.2666 Differs from the TRACED Act and STIR/SHAKEN
The TRACED Act, enacted in December 2019, gave the FCC authority to mandate STIR/SHAKEN implementation across U.S. voice carriers and extended the statute of limitations for robocall enforcement actions. It produced measurable results on domestically originated spoofed calls because U.S. carriers were subject to FCC jurisdiction and could be compelled to implement the authentication standard.
S.2666 operates in a different enforcement environment. Its target, foreign-originated robocalls, sits outside the direct reach of FCC carrier mandates. Where the TRACED Act could order U.S. carriers to authenticate calls at origination, S.2666 can only recommend that foreign governments and international bodies adopt equivalent standards. The scope difference is significant for operators evaluating whether the bill will reduce the volume of foreign robocall traffic reaching their customers or damaging their caller-ID reputation.
Interaction with the FCC NPRM and State Onshoring Laws
S.2666 and the FCC NPRM (CG Docket No. 26-52) address different problems but create overlapping compliance pressure for operators with any foreign-infrastructure dependency. The NPRM proposes capping offshore customer-service calls at 30% of volume and prohibiting offshore handling of sensitive consumer data, including passwords, multi-factor authentication codes, Social Security numbers, and banking and card data. That rulemaking is active and moving on its own timeline regardless of S.2666’s legislative progress.
1State laws add a third layer of exposure that is already in effect. New York’s Call Center Jobs Act carries penalties up to $10,000 per day for covered violations. New Jersey has enacted a mirror statute. Connecticut restricts offshore handling under state contracts. Missouri issued an executive order on offshore disclosure. Florida restricts offshore handling of medical information. None of these state-level obligations are contingent on S.2666’s passage.
Operators evaluating their foreign-infrastructure exposure should consult qualified counsel on the cumulative effect of the FCC NPRM, active state laws, and pending federal legislation. The compliance picture does not hinge on a single bill. It reflects a converging set of obligations that are already creating liability for operators who have not audited their vendor stack.
Practical Near-Term Actions for U.S. Operators
While S.2666 remains pending, operators can take concrete steps to reduce foreign robocall exposure and address the compliance obligations that are already active.
First, audit every vendor in the contact center stack for infrastructure location. AI voice and SMS tools built as API (application programming interface) wrappers on top of third-party CPaaS (Communications Platform as a Service) providers may route voice traffic through infrastructure that sits outside U.S. jurisdiction. The vendor’s marketing materials are not a reliable guide. The key questions are where voice originates and where data is stored.
Second, verify STIR/SHAKEN attestation levels on outbound calls. Calls originating on a third-party CPaaS may carry a lower attestation level than calls originating on an FCC-licensed carrier. That difference affects how destination carriers treat the call and whether it reaches the recipient as labeled.
Third, review DNC (Do Not Call) scrubbing architecture. Real-time scrubbing against federal and state DNC registries before dial is a compliance requirement that belongs at the carrier level, not bolted on after the fact. Operators relying on a third-party compliance layer that sits outside their primary voice platform carry integration risk on every outbound campaign.
Fourth, document the data-handling path for sensitive consumer data. Under the FCC NPRM’s proposed sensitive-data prohibition, the relevant questions cover where calls are answered and where data is processed and stored. Operators should be able to demonstrate that sensitive data does not leave domestic infrastructure.
Why Domestic Infrastructure Reduces Exposure
The legislative gap in S.2666 points to the same conclusion that the FCC NPRM and state onshoring laws have already reached. The only architecture-level defense against foreign robocall exposure and offshore compliance liability is owning the infrastructure stack domestically.
Plura AI is an FCC-licensed platform that runs voice, SMS (Short Message Service), RCS (Rich Communication Services), and webchat on 100% U.S. infrastructure. Voice originates on Plura’s own FCC-licensed audio bridging carrier, not a third-party CPaaS. STIR/SHAKEN authentication runs on every outbound call at the carrier level. Branded caller-ID is issued directly by Plura’s carrier, which means calls present with the company’s name rather than “Spam Likely” or an unfamiliar number. Real-time DNC scrubbing, TCPA (Telephone Consumer Protection Act) consent logging, and TCPA-litigator list filtering are first-class layers of the platform, not third-party add-ons.
Because Plura owns the full carrier stack, operators can report 100% U.S.-handled in their broadband consumer label disclosures and address the FCC NPRM’s domestic-infrastructure requirements by architecture rather than by contractual promise. Voice origination, model hosting, data storage, and call recording all sit on domestic infrastructure. There is no foreign-infrastructure dependency to audit out of the stack.
Plura’s Stateful Conversation Database holds context across every channel, so an AI agent that sent an SMS at 9 a.m. picks up the voice call at noon already knowing what was said. The AI Predictive Dialer, AI SMS, AI RCS, and AI Webchat all share that same memory layer. Plura supports compliance with TCPA, DNC, HIPAA, SOC 2, and 50+ state rule sets on every outbound contact, with immutable consent records and one-click audit-ready exports (per plura.ai/products/compliance).1
Frequently Asked Questions
Has the Foreign Robocall Elimination Act been signed into law?
No. As of June 2026, S.2666 remains on the Senate calendar and has not been enacted. Operators should consult qualified counsel for current legislative status rather than treating anticipated passage as a present-day compliance milestone.
What does the Foreign Robocall Elimination Act actually require carriers to do?
S.2666 creates a study mechanism, not a carrier mandate. The task force described earlier will produce recommendations for Congress and the FCC, but those recommendations do not carry enforcement authority. Carrier-level obligations in the robocall space continue to flow from the TRACED Act and existing FCC orders implementing STIR/SHAKEN.
How does S.2666 interact with the FCC NPRM on offshore call centers?
The two regulatory instruments address different problems. S.2666 targets foreign-originated robocall traffic. The FCC NPRM, CG Docket No. 26-52, addresses offshore handling of U.S. customer-service calls and sensitive consumer data. They are on separate timelines and create separate compliance obligations. An operator with foreign-infrastructure dependencies may face exposure under both the NPRM’s proposed rules and the state onshoring laws already in effect, regardless of whether S.2666 is ever enacted.
Why does STIR/SHAKEN fail to block many foreign robocalls?
STIR/SHAKEN authenticates calls that originate on U.S.-licensed carriers by attaching a cryptographic signature to the caller-ID information. Calls entering U.S. networks from foreign originators frequently arrive without a valid STIR/SHAKEN attestation, or with a gateway carrier’s attestation that does not reflect the true call origin. The authentication framework was designed for domestic origination and does not extend enforcement authority to foreign carriers operating outside FCC jurisdiction. S.2666’s task force is intended to study this gap, but the bill does not resolve it directly.
What is the immediate infrastructure-level defense against foreign robocall exposure?
The architecture-level defense is owning or operating on a 100% U.S. FCC-licensed carrier stack. When voice originates on a domestic FCC-licensed carrier, STIR/SHAKEN authentication runs at origination, branded caller-ID is issued at the carrier level, and there is no foreign-infrastructure dependency to create compliance exposure under the FCC NPRM or state onshoring laws. Operators relying on third-party CPaaS providers that route traffic through foreign infrastructure inherit that infrastructure’s compliance posture. Auditing the full vendor stack for infrastructure location is the first step. Replacing foreign-infrastructure dependencies with domestic alternatives provides a more durable solution. Plura runs on 100% U.S. infrastructure by architecture, with voice origination, model hosting, data storage, and call recording all on domestic infrastructure.
1 Plura AI maintains SOC 2, HIPAA, ISO, and GDPR posture as part of its platform infrastructure. References to compliance frameworks in this article describe Plura’s platform capabilities and do not constitute a guarantee that any customer using Plura will themselves be compliant with applicable laws or standards. Customers remain solely responsible for their own regulatory obligations, certifications, consent management, recordkeeping, and the claims they make to their own end users. Consult qualified legal counsel for guidance specific to your use case.
2 This article describes regulatory frameworks at a general level and does not constitute legal advice. Laws and regulations vary by jurisdiction, change over time, and apply differently depending on facts and circumstances. Readers should consult qualified legal counsel before making compliance decisions.
This article is provided for informational purposes only and reflects Plura AI’s understanding at the time of publication. Product capabilities, integrations, and specifications are subject to change. For the most current information, visit plura.ai.
This article was produced with the assistance of AI tools and reviewed by Plura AI prior to publication.