ShieldLabs
Start Free
Back to blog
DetectionFraud prevention

Traffic Laundering Detection: 4 Checks Before Billing Decisions

Yahor PapouYahor PapouChief Marketing Officer
Traffic Laundering Detection: 4 Checks Before Billing Decisions

Last updated on October 10, 2026 · 10 min read

Visit tokens sorted before a billing decision

The most reliable way to detect traffic laundering combines five checks working together: supply-path reconciliation, device and network anonymity signals, graph-style cluster analysis, passive DNS correlation, and forensic sampling. No single signal catches sophisticated schemes on its own. The MRC's 2024 interim IVT guidance recommends back-end reconciliation over pre-bid blocking for these cases, paired with transparent decision-rate reporting.

TL;DR:

  • Reconcile ads.txt, sellers.json, and observed SupplyChain records daily, flagging missing sellers, repeated reseller hops, and domain or app ID mismatches.
  • Connect persistent visitor IDs, IP addresses, accounts, app bundles, and redirect paths; rank dense clusters by recurrence and revenue exposure before forensic review.
  • Affected clusters carried roughly 2.4 to 33.3 times normal traffic in one study, so investigate volume alongside cluster relationships rather than alone.
  • Report decision rates, separate unknown traffic from confirmed valid or invalid traffic, and favor reconciliation after delivery over bid time blocking for sophisticated cases.
  • Before billing or partner action, reproduce suspected flows using bid requests, server logs, rendered pages, and raw HTTP traces, escalating only after signals corroborate.

Table of Contents

Quick checklist: prioritized detection actions to run now

Fraud teams investigating a suspected laundering case benefit from a fixed order of operations rather than an ad hoc search. The sequence below moves from fast, automatable checks to slower manual confirmation.

  1. Reconcile ads.txt, sellers.json, and SupplyChain records for the campaign in question, then verify the seller_id and any passthrough nodes.
  2. Run IP and datacenter reputation checks, flag datacenter or hosting ASNs, and compare the results against declared campaign referrers.
  3. Inspect device-level anonymity signals and user-agent or process indicators, sampling specifically for anti-detect browser behavior and Apple Private Relay traffic.
  4. Log the decision rate, separate "unknown" traffic from confirmed valid or invalid traffic, and pull a sample for forensic review before any billing or partner action.

Pro Tip: Run the automated checks in batch overnight and reserve analyst time exclusively for the clusters that survive two or more independent signals.

Signals and telemetry to collect and correlate

Laundering schemes are built to pass any single check, so detection depends on collecting several telemetry layers and reading them together.

  • Device-level signals: fingerprint persistence, anonymity indicators (VPN or proxy use, Private Relay, anti-detect browser detection), and returning-visitor identifiers.
  • Network-level signals: IP address, ASN, datacenter lists, TLS or HTTP header anomalies, and passive DNS mappings.
  • Behavioral signals: session length, page depth, viewability, conversion timing, and bounce or engagement patterns that diverge from the campaign's baseline.
  • Attribution metadata: referrer, publisher or app ID, SupplyChain nodes, and campaign or creative IDs.

AlfScan's cross-app cluster analysis reached 92% precision and 92% recall on a 200-app ground-truth dataset, and flagged 4,515 fraudulent apps out of 91,006 scanned. That gap between single-property inspection and cross-entity correlation is the core reason laundering schemes survive basic filters: each property looks clean in isolation, and only the relationships between them expose the pattern.

Supply-path and attribution checks (ads.txt, sellers.json, SupplyChain)

Placement laundering typically hides inside the gap between what a publisher declares and what actually gets served. The IAB Tech Lab's ads.txt framework exists precisely to close that gap, and reconciling it daily against observed bid and impression logs is one of the highest-yield checks available.

  • Automate a daily comparison between declared supply (ads.txt and sellers.json) and the SupplyChain nodes actually observed in bid and impression logs.
  • Flag missing or confidential sellers, repeated reseller hops, and any mismatch between the declared domain and the rendered domain or app ID.
  • Sample bid requests against served impressions to catch falsified property IDs, and route confirmed mismatches into sophisticated invalid traffic (SIVT) reporting.

Supply-path transparency proves that a declared relationship exists, not that the resulting impression was viewed by a person, so this check works best paired with device and network signals rather than alone.

Graph and cluster analysis to detect collusion and attribution laundering

Collusion-based laundering schemes route traffic through chains of apps, domains, or accounts specifically so no single node looks abnormal. Building a graph that links persistent visitor IDs, IPs, account IDs, app bundle IDs, and redirect chains surfaces the pattern that per-property review misses.

  1. Construct a graph connecting persistent visitor identifiers, IP addresses, account IDs, bundle IDs, and redirect paths across the properties in question.
  2. Search the graph for dense clusters, repeated device-to-account mappings, and groups of low-value properties that all resolve back to the same infrastructure.
  3. Rank clusters by size, revenue exposure, and how often the pattern repeats, then send the highest-priority clusters to forensic review.

The ACM CCS 2024 study on collusion-based ad attribution laundering found laundered invalid traffic ranging from roughly 2.4 to 33.3 times normal traffic volume within affected clusters, a spread wide enough that volume alone is a weak signal without the cluster context.

Passive DNS and network intelligence as a detection layer

Passive DNS records give investigators a durable view of infrastructure that IP rotation alone can't hide. A single server or hosting block that resolves an unusual number of unrelated, high-value domains is a strong laundering indicator, even when each individual domain looks legitimate.

  • Monitor many-to-one domain-to-IP mappings and ISP tuples that serve an outsized number of high-value domains relative to their known traffic.
  • Combine passive DNS data with SSL certificate metadata, reverse DNS records, and WHOIS registration patterns to build a durable fingerprint of the infrastructure.
  • Use these fingerprints to group suspected laundering servers together and to support escalation decisions, whether that means a partner conversation or an account-level review.

The placement laundering detection research demonstrates this approach at scale, correlating server-side IP and ISP tuples with client-side process indicators across hundreds of billions of events to surface schemes that property-level checks alone missed.

Forensic validation: sampling, HTTP traces, and manual confirmation

Automated signals narrow the list of suspects. Forensic validation is what turns a suspicion into evidence a partner or billing team can act on.

  1. Pull reproducible samples: bid requests, server logs, rendered HTML, and full HTTP traces, documenting the exact test environment used.
  2. Reproduce the traffic flow in a controlled environment and inspect headers, user-agent or process names, and any client-side obfuscation such as history.replaceState calls or chained redirects.
  3. Record every finding in a format suited to reconciliation and partner conversations, and escalate only when multiple corroborating signals point the same direction.

Pro Tip: Keep raw HTTP traces attached to every escalation. A partner dispute almost always comes down to whose log is more complete.

Operationalizing detection: workflows, decision-rate metrics, and MRC-aligned reporting

Detection only has value once it's folded into a repeatable process with metrics that stand up to partner and auditor scrutiny.

  • Measure and publish the decision rate, keeping unknown traffic reported separately from confirmed valid or invalid traffic.
  • Apply post-serve filtration for the sophisticated cases and use pre-bid signals selectively, since over-relying on pre-bid blocking can telegraph the detection logic itself.
  • Feed detection outputs directly into campaign reconciliation, billing adjustments, partner queries, and audit trail records.

The MRC's 2024 interim IVT updates require measurement organizations to report decision rate and favor back-end reconciliation for most SIVT categories. That requirement exists because front-end suppression is visible to the schemes it's meant to catch, while back-end detection stays harder to probe but depends entirely on disciplined reconciliation afterward.

Practitioner perspective: common mistakes and pragmatic fixes

The most common mistake we see is treating a single signal list as a verdict instead of an input. Flagging a datacenter IP or a mismatched referrer in isolation produces noise; correlating it against a graph of accounts, devices, and supply paths produces evidence. Teams that add supply-path reconciliation and cluster analysis early in an investigation tend to surface laundering faster than teams that keep adding more bot-detection rules to the same single-signal pile. Quantify what's unknown rather than forcing every session into "valid" or "invalid."

— Jeff

Where a persistent visitor identification and anonymity-signal platform fits

Every checklist above depends on telemetry that survives cookie clearing, IP rotation, and months between visits, which is exactly the gap a dedicated identification layer is built to close. Our visitor identification platform recognizes a returning visitor with up to 99% accuracy regardless of cleared cookies or incognito sessions, which means the persistent IDs feeding your graph clustering stay stable instead of resetting on every session.

  • Anonymity-signal detection covers anti-detect browser detection, VPN and proxy use, and Apple Private Relay, feeding directly into the device-level checks in your triage checklist.
  • Network intelligence surfaces datacenter and hosting ASN patterns for the IP reputation step without a separate lookup tool.
  • Explainable risk scores arrive with the underlying signals attached, so every flagged session has an audit trail ready for partner reconciliation.
  • Traffic quality analytics break down risk by source and channel, enriching your decision-rate calculations with per-campaign context.

Setup runs through a single JavaScript snippet with SDKs for Node.js, Python, Go, and PHP, and the pricing page lists the free tier alongside paid plans so your team can evaluate integration effort before committing budget.

FAQ

What is traffic laundering in digital advertising?

Traffic laundering is a scheme where invalid or low-quality traffic gets routed through legitimate-looking apps, domains, or accounts so it passes basic validation checks. It typically exploits attribution and supply-chain declarations rather than relying purely on bot volume, which is why single-property or single-signal checks often miss it.

How is traffic laundering different from general invalid traffic?

General invalid traffic (GIVT) is usually detectable through static lists and basic filters, while traffic laundering falls into the sophisticated invalid traffic (SIVT) category that requires deeper reconciliation. The MRC's IVT guidance treats these as distinct classifications with different recommended detection approaches.

What role does ads.txt play in detecting laundering?

The ads.txt and sellers.json framework lets publishers declare authorized sellers, so comparing declared supply paths against what's actually observed in bid logs reveals unauthorized reseller hops. It doesn't confirm that an impression was genuinely viewed, so it works best combined with device and network signals.

Can device fingerprinting alone detect traffic laundering?

Device fingerprinting alone is not enough, since laundering schemes are designed to look legitimate at the individual device or session level. Persistent identification becomes useful mainly when it feeds into graph-based cluster analysis that connects devices, accounts, and infrastructure across many sessions.

How often should detection rules be updated?

Detection rules need continuous review rather than a one-time setup, since laundering infrastructure shifts as schemes adapt to known checks. A practical cadence pairs automated daily reconciliation (supply-path and IP checks) with periodic forensic sampling to catch patterns the automated layer misses.

Sources

Related articles