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.

The route by which a traceback reaches you does not create a different class of response.

01
FCC
Regulatory investigation
A complaint or investigation identifies a specific illegal call or suspected activity.
Direct regulatory request
02
Law Enforcement
Criminal or consumer investigation
Agencies such as the FTC or a state attorney general may investigate scam operations independently.
Investigative request
03
ITG
Industry traceback
The Industry Traceback Group commonly acts on the FCC's behalf to trace suspicious calls across carriers.
Operational traceback request
Same obligation
47 CFR § 64.1200(n)(1)
The obligation does not become weaker because the request came through the ITG instead of directly from the FCC.
What changes
Who sends the request
FCC, law enforcement, or the ITG may be the visible point of contact.
What does not change
Your response obligation
The delivery format does not create a lower tier of compliance responsibility.
Do not classify a traceback by its delivery channel.
Inbox, portal, or investigator call. Verify the sender's authority and treat the request accordingly.

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.

Routine ITG case
Compliance attention
A weak response may trigger additional follow-up or a compliance flag.
LOWER
External scrutiny
Active investigation
Evidence scrutiny
The response may be cross referenced with evidence already collected elsewhere in the investigation.
HIGHER
External scrutiny
Poor response
Direct scrutiny
Late, incomplete, or absent responses can turn the carrier itself into a focus of attention.
HIGHEST
Potential exposure
How the investigations connect
FCC
Regulatory findings
Law Enforcement
Investigative evidence
ITG
Traceback evidence
One investigation can appear through multiple channels.
A direct agency request may reference an ITG case because both efforts can concern the same underlying call traffic.
Late
Timeline risk
Incomplete
Evidence gap
No response
Escalation risk
The practical rule
Do not assess a traceback by how serious it appears. Treat every request as binding, while recognising that some requests sit inside a much larger investigative record.

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.

Consumer complaint
Number, time and call details
Pattern detection
Volume, scam type or agency signal
Traceback opened
Specific call enters the investigation
Carrier chain
Each hop identifies its upstream provider
Why multiple requests can arrive together
Call 01
+
Call 02
+
Call 03
+
Call 04
Campaign signal
Same route
Several calls may expose the same upstream path.
Different paths
The same campaign can also appear across different carrier chains.
Misread
“We received four requests, so we're being targeted.”
Multiple requests can instead indicate that investigators are mapping the same active campaign from several call records.
Better interpretation
“Our traffic may intersect with an active pattern.”
A cluster is often evidence that the investigation has expanded from one call to a broader traffic pattern.
The important signal is not the number of requests. It is their relationship.
Several tracebacks arriving close together may represent multiple views of the same campaign rather than unrelated investigations.

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.

Originator
Who sent it?
The source of the traffic
Your network
Who handed it to you?
The fact you are expected to provide
Next hop
Where did you send it?
The downstream handoff
Common response
“We didn't originate the call.”
True, perhaps. But it does not answer the operational question being asked of an intermediate carrier.
Useful response
“We received it from Carrier B.”
This supplies the fact needed to move the investigation one hop closer to the origin.
What happens when the question is treated as an accusation?
Traceback received
Defensive review
Delay
Chain stalls
The efficient mindset
Treat the traceback first as a factual routing lookup. Your CDRs and call records should tell you which upstream provider handed you the call.
Don't defend your position. Identify the handoff.

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.

Role A
Originating Provider
1
Injects the call onto the public telephone network
This provider is closest to the point where the call entered the public network and may ultimately be the subject of the investigation.
Question: Where did the call enter?
Role B
Intermediate Provider
2
Receives and forwards the call
This provider may have had no role in creating the call, but its records identify the upstream carrier that handed the traffic over.
Question: Who handed it to you?
A fifteen-carrier path can look like this
Originator
Carrier 01
Carrier 02
Intermediate
Carrier 03
Intermediate
Carriers 04–14
Carrier 15
Termination
If Carrier 02 receives a traceback:
Its answer still matters
What you may not know
Where the call began
What you should know
Who handed it to you
What happens if you refuse
The chain loses a link
The traceback does not ask, “Were you the culprit?”
It asks, “Which provider handed you this call?”
A factual handoff keeps the investigation moving upstream.

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.

01
Originating
Injects traffic
02
Gateway
Bridges networks
03
Intermediate
Transits traffic
04
Terminating
Delivers the call
The rule follows the call
Originator
In scope
Gateway
In scope
Intermediate
In scope
Terminating
In scope
The misconception
“Our role is different, so the rule does not apply.”
A gateway may carry international traffic. A wholesale carrier may provide transit. Neither role creates an automatic exemption from the traceback chain.
The network reality
Every additional hop must remain traceable.
If intermediate providers became exempt, fragmented routing would create gaps precisely where investigators need the chain to continue.
What happens if intermediate hops are excluded?
Originator
Intermediate
TRACE GAP
Terminating
The chain would stop at the very point where fragmented routing makes attribution hardest.
The call path is the scope.
Originating, gateway, intermediate, or terminating. If your network handled the call, your position in that path does not make it a traceback-free zone.

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.