CTV Ad Fraud Is a Protocol Problem: Where OpenRTB Lies, VAST Breaks, and Revenue Disappears

The most expensive fraud in streaming often looks like a clean auction until the player tries to render the ad.

Most people talk about CTV ad fraud as if it starts with a bot, a fake app, or a suspicious traffic spike on a dashboard. That is too late in the story.

In connected TV, the money moves earlier. One system describes an opportunity in OpenRTB, another returns a winning creative, and a player or SSAI stack tries to execute that decision through VAST. If any of those layers are false, broken, or strategically incomplete, the auction can still clear, the logs can still look normal, and the revenue can still disappear.

I think about CTV fraud less as a pure invalid-traffic problem and more as a protocol-integrity problem.

The public signal is consistent. IAB/PwC says U.S. internet advertising reached a record $259 billion in 2024. Pixalate’s Q2 2025 benchmark put global CTV invalid traffic at 18%, based on more than 120 billion programmatic impressions. Penthera cites its own research saying 40% of VOD ads fail. Google Ad Manager says that if the gap between total code served and total impressions exceeds 25%, creative render rate is a likely cause.

Those are different kinds of signals: an industry revenue report, a vendor IVT benchmark, a vendor failure-rate claim, and platform troubleshooting guidance. They are not directly comparable. Taken together, they still describe the same market reality: CTV is large, fragmented, operationally brittle, and full of places where bad actors can hide inside normal-looking protocol traffic.

The simplest way to think about it is this:

OpenRTB is the claim. VAST is the instruction. Playback telemetry is the proof. Fraud lives where those three disagree.

Fraud enters at three layers: the claim layer, the execution layer, and the measurement layer.

This Is Not Just a Bot Problem

One reason CTV fraud stays hard to explain is that several different failure classes get mixed together.

Some impressions are simply fake. That is classic invalid traffic. Some impressions are real opportunities described with misleading metadata. Some are real wins attached to VAST tags that never had a serious chance of rendering. Some render but cannot be measured cleanly. Some are measurable on the server side but not auditable at the device layer. And some are not fraud at all; they are operational failures that create the same economic symptoms.

That last category matters. Not every broken VAST tag is fraud. Not every discrepancy is malicious. But fraud thrives in the same seams as ordinary breakage: places where metadata is trusted too early, validation happens too late, and reconciliation becomes the first line of defense.

Protocol fragility is not separate from fraud exposure. In CTV, it is often the substrate fraud uses.

OpenRTB: The Claim Layer

OpenRTB is where the market decides what the impression is supposed to be.

The protocol tells buyers whether this is an app or a site, what content is being watched, what device is requesting the ad, what supply path the request traveled through, whether the opportunity is SSAI-backed, what the pod position looks like, what privacy flags apply, and what kind of creative the buyer is expected to return.

That is an extraordinary amount of trust packed into one request.

OpenRTB 2.6 explicitly added features to support CTV buying and selling, including ad pods, channel and network objects, and a structured user-agent object. More recent IAB Tech Lab guidance pushed further into CTV-specific friction: genre taxonomy updates, Extended Content Identifiers, and sidecar APIs for live-event scale. The roadmap is clear about where the pressure is: CTV metadata, content context, and live-event scale.

The key point is that OpenRTB does not prove truth. It communicates assertions.

A request can be syntactically perfect and still be commercially false.

Examples are familiar to anyone who has spent time in the pipes:

• low-quality inventory packaged to look premium
• incomplete or misleading schain data
• content metadata shaped to attract higher-value demand
• pod or placement signals that imply a better context than the one actually delivered
• deal metadata that suggests curated or direct supply when the path is much murkier

This is also why ads.txt and app-ads.txt are necessary but insufficient. They reduce one class of supply-chain abuse. They do not tell you whether the OpenRTB request truthfully represents the stream context, or whether the VAST returned for that impression is actually runnable on the device receiving it.

VAST: The Execution Layer

If OpenRTB describes the opportunity, VAST decides whether the promised ad can actually happen.

VAST has been the standard mechanism for serving video ads since 2008. It carries the instruction set to the player: media files, duration, tracking, wrappers, companion assets, verification, interactive resources, and pricing metadata.

A huge amount of CTV loss gets quietly reclassified as “ops” when it is really failure in the execution layer.

IAB Tech Lab’s VAST CTV Addendum 2024 is especially revealing. It exists because TV-viewing environments still behave differently enough that the industry needs a cross-version compatibility layer for the features CTV actually depends on: ACIF ad registration, Open Measurement, interactive video, high-resolution creative, and icons for DSA compliance.

This is not paperwork. It is a stability document for a fragmented runtime.

The operational failures are well known:

• bad or missing MediaFile declarations
• wrapper chains that break or hide origin
• unsupported MIME types
• insecure HTTP assets on secure inventory
• malformed or missing IDs
• deprecated interactive declarations such as VPAID, which the spec has replaced with SIMID
• tracking definitions that are technically present but functionally useless

What matters in practice is that these failures are often semantically wrong, not structurally broken. The XML parses. The transaction proceeds. The auction can still be won. The ad still fails on the device that matters.

VAST is where fraud and fragility often overlap.

A deceptive actor does not always need to fake the whole impression. Sometimes it is enough to exploit the fact that the market clears on trust before the creative is deeply checked. A misleading wrapper chain, an unverifiable creative, a non-runnable asset declaration, or a measurement gap in the final instruction set can still turn a nominally successful auction into a bad impression.

An auction can be syntactically valid, operationally broken, and economically compromised at the same time.

SSAI Makes Truth Harder to Observe

CTV is especially unforgiving because the most valuable delivery architectures also reduce direct visibility.

Server-side ad insertion improves user experience. It smooths playback, reduces client-side complexity, and makes ad breaks more broadcast-like. It also collapses a lot of client-side observability unless you are extremely disciplined about end-to-end correlation.

That creates three recurring blind spots.

First, server-side systems can report a successful decision even when the downstream player experience is degraded. What the ad server thinks happened is not always what the device actually experienced.

Second, measurement can become split-brain. Server beacons, player events, verification callbacks, and billing logic can all tell slightly different versions of the same story.

Third, reconciliation is delayed. By the time the numbers disagree, the slot is gone. The viewer moment is gone. The buyer has moved on. The publisher cannot resell the impression.

That delay is exactly what makes protocol-level abuse expensive. If you only discover the mismatch during reporting, you are not preventing loss. You are documenting it.

The auction can clear long before anyone learns whether the creative was actually runnable and measurable on the device that mattered.

What the Public Data Shows

The best public numbers do not merely point to fraud. They point to a market that still struggles to establish a shared truth about what happened.

• IAB/PwC reports $259 billion in U.S. internet advertising revenue in 2024. The economic base is enormous, which means protocol failure in video is not a niche problem.
• Pixalate’s Q2 2025 benchmark puts global CTV IVT at 18%. Invalid traffic remains material even in environments that market themselves as premium.
• Penthera cites its own research saying 40% of VOD ads fail. Whatever portion of that is fraud, the execution layer is still fragile at scale.
• Google Ad Manager says that a gap above 25% between total code served and total impressions likely points to creative render rate problems. Major platforms explicitly expect systemic breakdowns between serving and counted outcomes.

Again, these are not interchangeable metrics. That is the point. Different sources, different methodologies, different layers of the stack, same basic finding: CTV is a high-value environment where truth still degrades between declaration, execution, and proof.

What a Defensible CTV Control Plane Looks Like

If you accept that fraud in CTV is a protocol-integrity problem, the response cannot be limited to post-campaign fraud scoring.

You need controls at each trust boundary.

1. Validate OpenRTB semantically, not just syntactically

Do not stop at JSON shape validation. Check that the request makes sense economically and operationally.

Review supply path completeness, app and content consistency, device plausibility, secure-transport expectations, SSAI markers, pod signals, and partner-specific anomalies. A request that is technically valid but commercially implausible should not be treated as premium inventory by default.

2. Treat VAST validation as revenue protection, not QA

This is the part the industry still handles too casually.

VAST should be linted before it reaches expensive decision points: creative onboarding, bid response assembly, cache insertion, stitch-time execution, and partner certification workflows. If the final instruction set is broken, every upstream decision was made on false assumptions.

I built vastlint because protocol correctness should not be left to late-stage debugging. In CTV, VAST validation is not polish. It is loss prevention.

3. Treat SSAI as a trust boundary

If server-side insertion hides client truth, you need compensating telemetry. Correlate what was requested, what was stitched, what the player attempted, what error codes fired, and what billing later assumed.

If those records cannot be joined at impression or transaction level, you do not have a forensic surface. You have isolated logs.

4. Correlate claim, instruction, and proof

For each impression, you want a chain that connects:

• the OpenRTB request that described the opportunity
• the winning response and any creative identifiers
• the final VAST or cached VAST actually used
• the player or SSAI execution outcome
• the measurement and billing consequences

If you cannot walk that chain quickly, bad actors will keep making money inside the gap.

5. Score partners on discrepancy and rejection behavior, not just spend

The market still overweights CPM, fill, and bid density. Those matter. But in CTV, you should also be tracking who sends malformed instructions, who causes render-rate loss, who relies on opaque wrappers, who produces recurring measurement gaps, and who improves when confronted with evidence.

A partner that clears auctions aggressively but degrades execution quality is not a strong revenue partner. It is a leakage source.

The control plane has to connect request truth, creative truth, execution truth, and billing truth.

The Actual Lesson

The streaming ad industry has spent years talking about fraud as if it were mostly a traffic-classification problem. Sometimes it is. But in CTV, some of the most expensive losses happen earlier and more quietly.

They happen when premium inventory is described loosely, when supply-path truth is hard to verify, when a winning creative is not deeply validated, when SSAI reduces observability, and when reconciliation is asked to solve problems that should have been blocked at the protocol boundary.

I keep coming back to the same conclusion: in CTV, fraud prevention is not just about finding bots. It is about verifying claims before they become instructions, and verifying instructions before they become invoices.

If OpenRTB is allowed to overstate the opportunity, VAST is allowed to understate the execution risk, and the player is the first place anyone learns the truth, the market will keep paying a fraud tax even when every system in the chain can produce a clean-looking log.

Trustworthy CTV will not come from more dashboards at the end of the process. It will come from stricter protocol integrity at the beginning.

Sources

• IAB Tech Lab: VAST standard overview and version history
• IAB Tech Lab: OpenRTB standard overview and version history
• IAB Tech Lab: VAST CTV Addendum 2024 implementation note
• IAB Tech Lab: Essential OpenRTB updates for 2026 roadmap
• IAB/PwC Internet Advertising Revenue Report: Full Year 2024
• Pixalate: Q2 2025 Global Invalid Traffic and Ad Fraud Benchmarks for Web, Mobile Apps, and CTV
• Penthera: The Biggest Advertising Challenges in VOD
• Google Ad Manager: Understand VAST error codes

Source note: the IAB/PwC figure is an industry revenue total; the Pixalate and Penthera numbers are vendor-reported benchmarks or research; the Google Ad Manager reference is platform troubleshooting guidance rather than a market estimate.