Who Can Request a Traceback? FCC, ITG, and Law Enforcement Explained
In our last article, we covered what a traceback actually is and where the system came from. If you haven't read what a traceback is and where the TRACED Act came from, that's worth reading first, since this article builds directly on it.
Now we need to answer a more practical question. Who actually has the authority to send you one of these requests, and what happens if you decide to ignore it because you don't recognize the sender?
This article walks through the three sources a traceback request can come from, why each one carries the same weight, and why "we didn't originate the call" isn't a defense against having to respond.
Let's get into it.
Who Can Actually Request a Traceback?
There are three parties who can initiate a traceback request, and it's worth knowing all three by name. Carriers sometimes assume a request has to come from the FCC directly to be valid. It doesn't.
The FCC can request a traceback. Law enforcement agencies, at the federal or state level, can also request one. And the Industry Traceback Group, acting as the FCC's registered consortium, can request one on behalf of both.
This isn't a hierarchy where one requester outranks another. It's three separate entry points into the same legal obligation, all of them backed by the same underlying rule.
The Three Doors a Traceback Can Come Through
Think of it as three separate doors that all lead to the same obligation.
The first door is the FCC itself. Usually through its Enforcement Bureau, when a complaint or an investigation points to a specific illegal call.
The second door is law enforcement. These may include the FTC, a state attorney general's office, or another agency running its own investigation into a scam operation.
The third door, and by far the busiest one, is the ITG. Most carriers will never receive a traceback request directly from the FCC or from law enforcement. They'll receive one from the ITG, acting on the FCC's behalf.
All three doors carry identical weight under the law. There's no tier system where an ITG request matters less than an FCC request. The obligation to respond under 47 CFR § 64.1200(n)(1), which we covered in the last article, applies no matter which door the request walked through.
It also doesn't matter how the request is delivered. Whether it lands in a shared compliance inbox, comes through a portal, or arrives as a phone call from an investigator. The identity of the sender is what determines your obligation, not the format of the message.
Three Doors. One Legal Obligation.
The route by which a traceback reaches you does not create a different class of response.
The FCC and Law Enforcement Route
When the FCC or a law enforcement agency initiates a traceback directly, it's usually because the call in question is already part of an active investigation.
That doesn't mean every FCC traceback is high stakes and every ITG one is routine. It just means the request arrived through a different channel, and that channel tells you something about what's happening on the other end.
A federal or state investigation into a specific scam campaign, such as a fake vehicle warranty operation running across dozens of states, might generate its own traceback requests. These requests would remain entirely separate from anything the ITG is working on.
Law enforcement agencies have the authority to request this information directly as the calls in question are potential evidence in a case, not just a compliance concern.
State attorneys general have been particularly active on this front in recent years. They often coordinate with each other across state lines when a scam campaign targets consumers nationally rather than in a single jurisdiction.
A traceback request from a state AG's office is legally no different from one issued by the FCC. It often signals a broader multistate enforcement effort is already underway.
Why Do These Requests Often Come with Extra Weight?
The practical difference for you as a carrier is mostly about who's watching the response. A traceback that originates from an active law enforcement investigation is more likely to be followed up on, cross referenced with other evidence, and used in a subsequent enforcement action or prosecution.
That doesn't change your obligation. It changes the stakes of getting the response wrong. Whether that's responding late, responding with incomplete information, or not responding at all.
A slow response to a routine ITG traceback might result in a compliance flag. A slow response to a traceback tied to an active federal investigation carries a real chance of drawing direct scrutiny to your business.
It's also worth knowing that these direct requests don't happen in isolation from the ITG process. In practice, the FCC and law enforcement often work alongside the ITG rather than around it. They share findings and coordinate on cases that involve the same underlying call traffic.
A request that technically originates from a state AG's office may still reference an ITG case number. Usually, the two efforts are frequently pulling from the same investigation.
The Obligation Stays Constant. The Exposure Changes.
The source of a traceback does not create different duties, but the surrounding investigation can change the consequences of a weak response.
The ITG Route: Where Most Requests Actually Originate
For the vast majority of carriers, every traceback request they ever see will come from the ITG. It's worth understanding how a request actually reaches that point, because it demystifies what can otherwise feel like an opaque process arriving out of nowhere.
Consumer complaints feed into this system constantly. The FTC's Do Not Call complaint database, state attorney general offices, and the FCC's own consumer complaint portal all collect reports of illegal and unwanted calls.
The ITG monitors and pulls from these sources, along with tips from carriers and its own internal fraud detection, to identify calls worth tracing.
This means the ITG isn't waiting around for individual carriers to self report problems. It's actively watching multiple public and industry data sources at once, which is part of why response times matter so much. By the time a traceback request reaches you, the ITG has usually already done meaningful work identifying the call as worth pursuing.
How does a Consumer Complaint Turn Into an ITG Traceback?
Here's the practical version of that pipeline. A consumer reports a specific call, usually because it was a scam, a spoofed number, or an illegal robocall campaign they'd never consented to. That complaint includes the basic identifying details: the number that called them, roughly when it happened, and what the call was about.
The ITG reviews these reports and selects calls that fit a pattern worth investigating, whether that's volume, a known scam type, or a request from a partner agency. Once selected, the ITG opens a formal traceback and contacts the terminating carrier to start the chain we walked through in the last article.
This is also why you might occasionally see a traceback request for a call that seems, on its face, fairly minor. The ITG isn't only tracing headline grabbing fraud campaigns. It's also tracing the smaller patterns that, left unaddressed, tend to grow into bigger ones. A single call rarely triggers a traceback on its own. It's usually one data point in a pattern the ITG has already been watching.
That pattern based approach also explains why some carriers see a cluster of traceback requests arrive close together. If a bad actor is running a campaign through a particular route, the ITG may trace several calls from that same campaign in quick succession.
Such calls sometimes pass through different carriers in the same chain, sometimes through the same carrier more than once. Seeing multiple requests in a short window isn't a sign you're being singled out. It's usually a sign the ITG has identified an active campaign and is working to close it down as quickly as possible.
One Complaint Can Become a Network-Wide Traceback
The ITG does not simply investigate isolated calls. It uses individual complaints as signals that may reveal a broader campaign.
Why "We Didn't Originate the Call" Isn't a Defense
This is the single most common objection carriers raise when a traceback request lands in their inbox. It's worth addressing head on because it's based on a misunderstanding of what the request is actually asking.
A traceback request isn't accusing you of originating an illegal call. It's asking you to confirm one specific fact: who handed you this call.
If you're an intermediate carrier who simply routed traffic from one upstream provider to a downstream one, you're still expected to answer that question. Your answer is what keeps the chain moving toward whoever did originate it.
Some carriers treat a traceback request the way they'd treat a legal accusation, and respond defensively, slowly, or with legal counsel involved before a simple factual answer has even been given.
That reaction is understandable, but it usually makes things worse. The request is asking for a fact you already have on file. Treating it as an adversarial process tends to slow down a response that should take minutes, not weeks.
Traceback Is About the Handoff, Not the Blame
The operational question changes depending on where you sit in the call path.
The Difference Between Originating a Call and Being Asked About One
These are two entirely separate things, and conflating them is what leads carriers to either panic unnecessarily or, worse, ignore a request they assume doesn't apply to them.
Originating a call means you're the provider that first injected the call onto the public telephone network. Being asked about a call means someone downstream from you needs to know who handed it to you.
You can be the second party in a chain of fifteen carriers and still be legally obligated to respond. You may have had nothing to do with where the call started or who ultimately profited from it.
Refusing to respond because "it wasn't us" doesn't make the obligation disappear. It just makes you a non responsive link in a chain that the FCC and the ITG are actively watching, and non responsiveness is tracked and reported on, a topic we'll cover in detail later in this series.
Originating a Call Is Not the Same as Being in the Traceback
Your position in the call path determines what you know, not whether the traceback question applies to you.
What "Any Provider in the Call Path" Actually Means
The rule is written broadly on purpose. Any provider in the call path means exactly what it says: originating, intermediate, gateway, or terminating, it doesn't matter. If a call passed through your network at any point, you can be asked about it.
This matters because carriers sometimes assume their specific role exempts them. A gateway provider bringing foreign traffic into the US network might assume traceback obligations apply only to domestic originators.
An intermediate carrier running wholesale transit might assume the obligation only applies to retail facing providers. Neither assumption holds up, and both are worth correcting before a traceback request forces the point.
The breadth of the rule is also what makes the whole system function at all. Illegal call traffic frequently passes through several carriers on purpose. Specifically because bad actors know that a longer, more fragmented chain is harder to trace.
If the obligation only applied to originating and terminating carriers, every intermediate hop in between would become a safe zone where a trace could quietly stall out.
No Safe Zone in the Call Path
The obligation follows the call through the network, regardless of the provider's commercial or technical role.
A Quick Gut Check: Could This Be You?
If your network has ever carried a call, whether you originated it, routed it, or delivered it to its final destination, you're in scope. There's no size threshold, no minimum call volume, and no exemption for wholesale versus retail traffic.
We go deeper into what your specific obligations look like depending on where you sit in the call path, originating, intermediate, gateway, or terminating, in a later article in this series, covering each role in detail.
What's Next in This Series
Now you know who can send you a traceback request and why your role in the call path doesn't exempt you from responding. The next practical question is what actually shows up when a traceback request arrives.
What information does the ITG send you, and what are you actually expected to hand back?
We'll also start looking at the 24 hour response clock in an upcoming article. Knowing who can request a traceback matters a lot less if you don't know how quickly you're expected to answer.
For now, the next article in the series covers exactly what a traceback request contains, line by line, so nothing about the document itself catches you off guard.












