Inside a Traceback Request: What the ITG Actually Sends You

In the last two articles, we covered what a traceback actually is and who has the authority to request one. Now it's time to look at the document itself. What actually lands in your inbox, and what is it really asking for?

A lot of the anxiety carriers feel about traceback requests comes from not knowing what the request contains before it arrives. Once you've seen one, most of that anxiety goes away, because the request is far more narrow and specific than people expect.

This article walks through the exact information included in a traceback request. It also details what the document deliberately leaves out. Finally, it shows you how to read one quickly so you can start answering without wasting time.

We'll also cover the practical difference between a traceback request and other kinds of formal legal demands your business might receive. Confusing the two is one of the most common reasons carriers escalate a simple task into a slow one.

Let's get into it.

What Does a Traceback Request Actually Look Like When It Arrives?

Most carriers picture a traceback request as something formal and intimidating, closer to a subpoena than an email. In practice, it's closer to a short, structured data request. The ITG standardized this format years ago specifically so carriers could respond quickly without needing legal review for every single case.

The request typically arrives through the ITG's Secure Traceback Portal, sometimes referred to internally as the STP. Smaller or newer carriers may still see one arrive by email in the early stages of onboarding with the ITG. Either way, the structure of the request itself doesn't change.

Carriers who've been through this a few times often set up a dedicated inbox or portal login specifically for compliance requests. This sounds like a small thing, but it's one of the most common reasons a traceback request gets missed entirely.

A single shared inbox for sales, support, or general enquiries often creates operational bottlenecks and severe delays. If a time-sensitive traceback request lands in this cluttered environment, it can easily go unnoticed. Even worse, the compliance clock keeps running whether anyone has actually seen the notification or not.

The Format You Should Expect

Expect a short cover section first. This section identifies the requesting organization and provides a case or traceback number for all tied correspondence. It also sets a due date calculated from a 24-hour clock.

Below the cover section lies the actual data. Carriers must focus their attention here. This section determines whether you can answer the request in minutes or if you need to dig through records first.

If your team has never seen one, request a sample directly from the ITG. Alternatively, ask your account contact to walk through the format once. Most carriers only need to see the layout a single time. After that, processing it becomes second nature for compliance or NOC staff.

The Data Points Every Traceback Request Contains

Every traceback request is built around a small, consistent set of data points. The ITG doesn't vary this structure much from request to request, which is deliberate. Standardization means your team can build a repeatable process instead of reading each request from scratch.

At minimum, you'll see the called number, the calling number as it appeared on the call (which may be spoofed, and the ITG knows this), and the date and time of the call expressed in UTC rather than local time.

Called Number, Calling Number, and the UTC Timestamp

These three fields are the core of an ITG traceback request. Each field helps identify the reported call. Together, they give your team the information needed to search your call records and trace the call to the next provider.

Called Number

The called number is the number that received the reported call. It identifies the destination of the call.

This is one of the first fields you should use when searching your call detail records (CDRs). It helps narrow the search to calls sent toward a specific destination. This is especially useful when your network handles a large volume of traffic.

The number may appear in different formats in your systems. For example, one system may include the country code while another may use a local or normalized format. Your search process should account for these differences.

Why is it requested?

The called number tells you where the reported call was going. It helps your team find the relevant call in your records. When combined with the calling number and timestamp, it provides a strong set of search criteria.

Calling Number

The calling number is the number that appeared on the recipient's phone as the caller ID.

This number is important, but it should not be treated as proof of the caller's identity. The calling number may have been spoofed. The ITG is aware of this and uses the number as part of the traceback process.

You should still use the calling number when searching your CDRs. It can help you identify the reported call and distinguish it from other calls to the same destination.

The calling number can also provide useful context about the complaint. For example, repeated reports involving the same number may indicate a wider spoofing or abuse issue.

Why is it requested?

The calling number shows what caller ID was presented to the recipient. It helps match the reported call with records held by each provider in the traceback chain.

UTC Timestamp

The UTC timestamp shows when the reported call occurred. ITG traceback requests use UTC rather than local time. This removes confusion when multiple carriers operate across different time zones. Every provider can search using the same time reference.

The timestamp may represent when the call was received by the complaining party. It does not always represent the exact time the call entered your network. Routing and signalling can create small differences between network records.

For this reason, do not search for an exact second-to-second match. Use a small time window around the reported timestamp.

Why is it requested?

The UTC timestamp tells you when to look. It gives every provider a common reference point and helps narrow the CDR search quickly. Make UTC conversion and timestamp normalization a standard part of your traceback intake process.

Campaign Name and the Optional Call Recording

Beyond the three core fields, most ITG requests also include a campaign name or description. This is more than a label. It tells you what type of call activity the ITG is investigating.

A traceback request is rarely about one call. It is usually linked to a wider campaign. The ITG may already be tracking many calls linked to the same activity. Some campaigns may involve dozens or even hundreds of calls.

Recent changes to the ITG process may also include the reason the campaign is suspected to be illegal or fraudulent. This gives carriers more context. The reason will usually point to a specific type of violation. Examples include spoofing, lack of consent, or a known scam pattern.

It is useful to keep a simple internal log of campaign names. Record the campaign name when a request arrives. Also record how your team handled it. The same campaign may appear again in a later request. Having the earlier record gives your team useful context. It can also reduce the time needed to respond.

Why a Recording Isn't Always Included, and What to Do When It Is

A call recording or transcript can provide useful context. However, it is not included with every request. It is also not required for the ITG to proceed. When a recording is included, it helps confirm the call's connection to the reported campaign. This can be useful when similar scam scripts are being used by different sources.

If a recording is provided, listen to it once during intake. Use it to understand the nature of the reported call. Do not treat the recording as a separate investigation.

Your role is still the same. You need to identify which provider handed you the call. The recording is supporting context for the ITG's investigation. It does not create an additional task for your team.

What a Traceback Request Is NOT Asking You to Do

A traceback request has a narrow purpose. This is important to understand. It prevents confusion and avoids unnecessary delays.

A traceback request does not ask you to decide whether the call was illegal. That decision is outside your role. The ITG handles the traceback investigation. The FCC and law enforcement may also become involved when required.

Your role is much simpler. You need to identify who handed you the specific call. You then provide that information to the ITG.

A traceback request is also not a request for your full call records. You do not need to provide the customer's complete account history. You also do not need to explain your network architecture.

Some carriers provide more information than requested. They may do this to be cautious. However, this does not make the process faster. It can have the opposite effect. The ITG then has to review extra information to find the specific detail it needs.

The traceback process is designed to move one hop at a time. A call may pass through many carriers before reaching its source. Each carrier only needs to identify the provider that handed it the call.

If every carrier sent large amounts of data, the process would slow down. The ITG would have to review unnecessary information at every hop. A focused response keeps the process moving.

The Difference Between a Traceback and a Records Subpoena

A subpoena is a formal legal instrument. It can require you to provide specific records. It is usually connected to an investigation or legal proceeding. It may also require involvement from your legal team.

A traceback request is different. It is an operational compliance request under 47 CFR § 64.1200(n)(1). It is designed to be handled quickly. Your compliance or NOC team can usually manage the request.

You do not need to treat every traceback as a legal matter. Doing so can create unnecessary delays. It can also cause your team to miss the required response window.

The two processes can still be connected. A traceback may reveal that a carrier is repeatedly unresponsive or uncooperative.

This information can later support formal action. That could include FCC enforcement or a law enforcement request for records. The traceback itself remains an operational process. However, repeatedly ignoring traceback requests can lead to more serious consequences.

How to Read a Traceback Request So You Don't Waste Time

Once you know what to look for, a traceback request is usually straightforward. You do not need to interpret every detail. Focus on the information needed to find the call and identify the provider that handed it to you.

Step 1: Check the Case Number and Due Date

Start with the case number. This is the main reference for the request. Use it when tracking the request internally and when submitting your response.

Next, check the due date. This tells you how much time you have to complete the traceback. Record the deadline in your ticketing or compliance system so it is not missed.

Step 2: Pull the Three Core Fields

Find the three key fields in the request:

• Called number
• Calling number
• UTC timestamp

These are the fields you need to match the call in your CDRs. You can convert the UTC timestamp to your local time for internal searching. However, keep the original UTC value in your records and response.

Step 3: Search Your CDRs

Use the called number and calling number to search your call records. Use the UTC timestamp to narrow the time range. Do not rely on an exact timestamp match. Allow for small differences caused by routing and network processing. Your goal is to find the specific call described in the request.

Step 4: Identify the Upstream Provider

Once you find the matching call, check where it came from. Identify the upstream provider that handed the call to your network. This is the key information the ITG needs from your hop in the traceback. You do not need to trace the call beyond your own network. The next provider will handle the next hop.

Step 5: Submit Your Response

Send the requested provider information back through the same channel used for the traceback request. Keep the response focused. In most cases, you only need to provide the upstream provider's details.

A Simple First-Response Checklist

Your first-response process can be reduced to five steps:

1. Confirm the case number and due date.
2. Review the called number, calling number, and UTC timestamp.
3. Search your CDRs for the matching call.
4. Identify the upstream provider.
5. Respond through the same channel.

That is usually all that is required. A traceback does not normally require legal review or executive approval. It also does not require a lengthy investigation. An exception may arise if the traceback points directly to one of your own customers. That situation requires a different process and should be handled separately.

Make the Process Repeatable

Add this checklist to your existing ticketing or compliance workflow. Do not rely only on individual knowledge or a shared document. Traceback requests can arrive at any time. Your process should allow any trained team member to handle them.

Automation can make this even faster. CDR matching tools can reduce a manual search to a near-instant lookup. This becomes especially useful for carriers that handle a high volume of traceback requests.

Keep an Internal Record

The response to the ITG may be short. Your internal record should still be complete. Record:

• What you searched
• What call you found
• Which provider handed you the call
• What information you sent
• When you submitted the response

This record is not part of the traceback response itself. It is for your internal documentation. Good records also help if your traceback activity is reviewed later. You can show that requests were handled consistently and within the required timeframe.

What's Next in This Series

Now that you know exactly what a traceback request contains and what it's actually asking of you, the next question is timing. How fast do you actually need to move, and what happens if you don't?

The next article in this series covers the 24 hour response clock in full detail, including how it ties directly to your Robocall Mitigation Database certification, and why the FCC has made clear that missing that commitment is treated as its own separate violation.