Ad fraud and connected TV ad fraud: how invalid traffic works and how to detect it

Advertisers pay for impressions and clicks that no person ever saw, because programmatic advertising trusts signals that fraudsters can fake at scale. Connected TV (CTV) makes this worse: ads are expensive, most are stitched into the stream on a server, and the device that supposedly played the ad is often only a set of claims in a bid request. This guide explains the invalid traffic (IVT) categories defined by the Media Rating Council (MRC), how bot traffic, device spoofing and server-side ad insertion (SSAI) spoofing work, and how the IAB Tech Lab supply chain standards ads.txt, app-ads.txt and sellers.json help buyers check who is selling. It is for ad operations, fraud, security and analytics teams at advertisers, agencies, publishers and ad tech platforms. It is defensive: it describes how schemes behave so they can be detected, not how to run one.

Key takeaways

• IVT has two tiers. The MRC splits invalid traffic into General IVT, caught by lists and parameter checks that every accredited measurer must apply, and Sophisticated IVT, which needs advanced analytics, corroboration or human review.
• CTV fraud is mostly impersonation. Schemes such as PARETO made Android phones pose as Roku, Apple TV, Fire TV and other streaming devices, and reported ads as played when nothing was shown.
• SSAI weakens the evidence. When a server stitches ads into the stream, tracking can come from one server IP, so device and IP signals passed by the SSAI vendor become claims that must be verified.
• Supply chain files are necessary but not sufficient. ads.txt, app-ads.txt and sellers.json let a buyer check that a seller is authorised, but they do not prove that a real person on a real device saw the ad.
• Measure, segregate and claw back. Report GIVT and SIVT separately, track decision rates and unknown traffic, and build refund terms into contracts.

What ad fraud is and the MRC IVT categories

The MRC Invalid Traffic Detection and Filtration Guidelines Addendum (issued October 2015, updated June 2020, with an interim update memo finalised in April 2024) defines invalid traffic as traffic or media activity that does not represent legitimate traffic that should be included in measurement counts. It covers non-human traffic and activity designed to produce IVT. OWASP lists the same problem as OAT-003, now named Cost-Inflation Fraud (formerly Ad Fraud), in its Automated Threats to Web Applications project: false clicks and fraudulent display of advertisements.

The addendum sets list-based filtration as the floor, using industry lists such as the IAB/ABC International Spiders and Bots List, and names data centre IP ranges from Amazon AWS, Google and Microsoft as the minimum starting point. For SIVT it points to traps and honeypots, properly evaluated CAPTCHAs, device fingerprinting where privacy rules permit, machine learning, forensic review and "follow the money" analysis.

Common schemes, from web to CTV

• Data centre bots with fake residential cover: in the Methbot case announced by the US Department of Justice in November 2018, operators rented more than 1,900 data centre servers, leased more than 650,000 IP addresses registered to look like home connections, and loaded ads on fabricated sites impersonating more than 5,000 domains. DOJ said businesses paid more than 7 million US dollars for ads no person saw.
• Botnets of infected computers: the same DOJ case described 3ve, which used more than 1.7 million infected computers running hidden browsers, with the Kovter malware behind the botnet, and caused losses of more than 29 million US dollars. The FBI sinkholed 23 Kovter domains. See the Botnets Guide.
• Domain and app spoofing: the bid request claims premium inventory (a known news site or CTV app) while the ad actually runs somewhere cheap or nowhere. This is what ads.txt and app-ads.txt were built to counter.
• CTV device spoofing: HUMAN's Satori team disclosed PARETO in April 2021: nearly one million infected Android phones posed as Roku players, Apple TVs, Fire TV sticks, LG smart TVs and Chromecast devices. A command server set each phone's device profile, phones checked in about every 30 seconds for jobs, and they reported ad playbacks as shown without displaying anything. HUMAN reported 29 Android apps spoofing more than 6,000 CTV apps and an average of 650 million bid requests a day before the takedown. A linked operation used 36 Roku apps.
• SSAI spoofing: a fraudster sets up servers that behave like an SSAI provider and send fabricated server-side tracking calls with invented device IPs and user agents. The MRC's OTT and SSAI guidance notes that SSAI artifacts can be spoofed and that IP based identification is risky because IPs can be spoofed and SSAI providers use shared or dynamic addresses.
• Compromised consumer devices: the FBI warned in June 2025 (alert I-060525-PSA) that the BADBOX 2.0 botnet spans millions of devices, including TV streaming devices and other IoT products, infected before purchase or through backdoored apps, with home networks sold on as residential proxies. Traffic from such devices looks residential, which defeats simple data centre filtering. See the Residential Proxy Networks and Abuse Guide.
• Click fraud and click injection: automated or incentivised clicks inflate pay per click charges; the MRC lists click farms and clickjacking under SIVT. See the Clickjacking Guide.

Why CTV and SSAI are different

On the open web a measurement script runs in the viewer's browser and can observe rendering, viewability and interaction. In CTV much of that is missing. The MRC's OTT/CTV and SSAI Digital Video Measurement Guidelines (August 2021) explain that with SSAI an intermediary server combines content and ads into one stream, the player may not process ad tracking, and the stitching service cannot access the ad tags used in client-side tracking.

The April 2024 MRC interim update adds two CTV points: SIVT vendors should compare property IDs declared before bidding with where ads were actually delivered, and CTV bundle IDs fall under the app misrepresentation rules, so non-CTV apps misrepresented as CTV are SIVT. It also encourages use of ads.txt and app-ads.txt, requires annual assessment of how much detection depends on IP address, user agent and user-level signals, and requires impressions of unknown IVT status caused by privacy limits to be reported separately.

Supply chain transparency: ads.txt, app-ads.txt and sellers.json

The IAB Tech Lab Supply Chain Validation specifications let a buyer check who is allowed to sell inventory. The current ads.txt and app-ads.txt version is 1.1 (August 2022, which added OWNERDOMAIN and MANAGERDOMAIN).

Key fields

• ads.txt record: four comma separated fields: advertising system domain, publisher account ID (which must match the ID sent in bid requests, usually publisher.id), account type DIRECT or RESELLER, and an optional certification authority ID (for example a TAG ID). Variables include CONTACT, SUBDOMAIN, INVENTORYPARTNERDOMAIN (for CTV and app partners, followed one hop only), OWNERDOMAIN and MANAGERDOMAIN.
• Retrieval rules: HTTPS preferred, text/plain, redirects followed within the root domain plus one hop to a third party, a 404 means no authorised sellers, and without cache headers a seven day expiry applies. A placeholder record marks an intentionally empty file.
• app-ads.txt discovery: stores expose appstore:developer_url, appstore:bundle_id and appstore:store_id meta tags; the verifier maps the developer URL to its registrable domain and fetches /app-ads.txt. The specification explicitly extends to CTV app stores, using a Roku Channel Store example.
• sellers.json fields: seller_id, seller_type, name and domain, plus is_confidential and is_passthrough. All sellers must be listed even if confidential, but confidential entries can omit name and domain. The only valid version value is 1.0.

Limits

These files show authorisation, not delivery. A spoofed CTV device can still send a bid request that names a real app and a real authorised seller. Confidential sellers.json entries hide identities, and RESELLER chains can be long. HUMAN's PARETO write-up recommended full adoption of app-ads.txt for CTV, sellers.json and consistent app ID and bundle ID declarations, which helps, but delivery still needs verification.

Detection signals

Implementation: building an ad fraud programme

1. Set the standard in contracts. Require MRC accredited IVT measurement (GIVT at minimum, SIVT for CTV and video), separate reporting of GIVT, SIVT and unknown traffic, and refunds or make goods for invalid impressions.
2. Turn on pre-bid supply checks. Buy only from sellers authorised in ads.txt or app-ads.txt, require a complete schain, check every node against sellers.json, and consider requiring matching OWNERDOMAIN values as the specification suggests.
3. Prefer direct paths in CTV. Limit long reseller chains, and keep a verified list of SSAI vendors and their server ranges.
4. Pilot post-bid verification on a slice of spend, compare vendor IVT rates with your own log analysis, and tune before applying across all campaigns.
5. Investigate anomalies with "follow the money" analysis: which seller IDs, apps and SSAI servers concentrate the invalid traffic.
6. Close the loop. Add confirmed bad bundle IDs, seller IDs and IP ranges to block lists, request refunds, and share findings with partners.
7. Review annually, including how much your detection relies on IP and user agent, which privacy changes keep reducing.

Rollback: block lists and pre-bid filters can cut legitimate reach. Run new filters in report-only mode first, and keep an exceptions list reviewed by ad operations.

Decision guidance

• Advertisers and agencies: focus on contracts, accredited verification and supply path optimisation. A small advertiser buying through one platform should at least require that platform's IVT reporting and ads.txt enforcement.
• Publishers and CTV app owners: keep ads.txt and app-ads.txt accurate and current, remove old resellers, and publish OWNERDOMAIN. Monitor for your app or domain being spoofed elsewhere.
• SSPs and exchanges: publish a complete sellers.json, minimise confidential entries, pass full schain, and filter GIVT before the auction.
• Pre-bid versus post-bid: pre-bid blocks waste early but sees only what the bid request claims; post-bid sees delivery evidence but money may already be spent. Mature programmes run both.

Measurement and KPIs

• GIVT and SIVT rates by channel (web, in-app, CTV), seller and app, reported separately as the MRC requires.
• Decision rate: recorded impressions divided by intended impressions, which the MRC requires by environment including OTT.
• Unknown traffic share, especially SSAI traffic that could not be validated.
• Share of spend on authorised paths (seller in ads.txt or app-ads.txt with a complete, valid schain).
• Refunds recovered as a share of measured invalid spend.
• Time to block a confirmed fraudulent bundle ID or seller ID.

Where identity fits

Ad fraud is an impersonation problem: devices, apps, domains and sellers all assert identities that buyers cannot easily prove. The supply chain files are a weak form of identity for sellers, and SSAI authentication with mutual TLS or ads.cert is an attempt to give server-side reporters a verifiable machine identity. The same bot detection ideas apply as in the Bot Management Guide.

Common failure patterns

• Treating ads.txt as fraud protection. It confirms authorisation only; PARETO traffic could carry the names of real apps.
• Counting unknown traffic as valid. SSAI traffic that cannot be validated should be reported separately, not blended into delivered impressions.
• Data centre lists as the only control. Residential proxies and infected home devices such as those in BADBOX 2.0 defeat them.
• Stale ads.txt files. Old reseller entries leave authorised paths open for years after a relationship ends.
• Trusting device claims in CTV. Device type, model and app bundle are self-reported in the bid request and were exactly what PARETO forged.
• No refund terms. Without contractual claw back, measured IVT becomes a report rather than recovered money.

Framework mapping

Practitioner checklist

• Require MRC accredited IVT measurement and separate GIVT, SIVT and unknown reporting in every media contract.
• Enforce ads.txt and app-ads.txt authorisation and complete schain validation against sellers.json before bidding.
• Keep your own ads.txt and app-ads.txt current, with OWNERDOMAIN set and old resellers removed.
• Maintain a verified list of SSAI vendors and treat unverified server-side traffic as unknown.
• Compare declared bundle IDs and domains with where ads were actually delivered.
• Look for impossible viewing patterns per device and per IP, not just data centre IPs.
• Run new filters in report-only mode before blocking.
• Track decision rate, IVT rates by seller and refunds recovered every month.

Standards and references

• Media Rating Council: Invalid Traffic Detection and Filtration Guidelines Addendum
• Media Rating Council: Invalid Traffic Detection and Filtration Interim Update Memo
• Media Rating Council: OTT/CTV and SSAI Digital Video Measurement Guidelines
• IAB Tech Lab: Supply Chain Validation specifications (ads.txt 1.1, app-ads.txt, sellers.json)
• IAB Tech Lab: ads.txt and app-ads.txt
• OWASP: OAT-003 Cost-Inflation Fraud
• US Department of Justice: Methbot and 3ve indictment
• FBI IC3: BADBOX 2.0 public service announcement

Related NHI Mgmt Group resources: Bot Management Guide · Botnets Guide · Residential Proxy Networks and Abuse Guide · Fraud Prevention Guide for Digital Businesses · Malvertising and SEO Poisoning Guide