A shared deal record does not detect connected TV fraud. It does something narrower: it fixes, in one version that buyer and seller both hold, which apps and devices were promised, how ads would be inserted, whose measurement counts and what happens if traffic proves invalid. That turns a fraud finding from an argument about what the deal said into a check against terms both sides accepted. Detection and independent verification remain separate jobs.

TL;DR. The best-established CTV fraud mechanisms are server-side ad insertion (SSAI) spoofing, app spoofing and device spoofing, and each works by misrepresenting where an impression came from. Supply chain standards such as ads.txt (2017), app-ads.txt and sellers.json (2019) tell a buyer who may sell, not what a specific deal promised. A shared deal record settles what was agreed: app bundles, device types, insertion method, verification vendor and remedy. It cannot stop anyone fabricating traffic, and it is only as strong as the terms written into it.

How does CTV fraud work?

CTV fraud works by misrepresenting the origin of an impression so that cheap or fabricated traffic is sold at television prices. Connected TV attracts fraud because its prices are high and it is hard to measure: there is no browser, client-side scripts are limited on many devices, and a server often sits between screen and ad.

Server-side ad insertion spoofing. In SSAI, the publisher's server stitches ads into the stream and requests them on behalf of many viewers, so large volumes of requests legitimately come from a few server addresses. Fraudsters copy that pattern. A data centre server sends fabricated requests claiming to be SSAI traffic from many households, and checks based on IP address and request volume struggle to tell the difference.

App spoofing. An app spoofing scheme declares a false app identifier, usually the bundle ID of a well-known streaming app. The buyer believes it is paying for a premium channel when the impression ran somewhere else, or nowhere.

Device spoofing. Device spoofing presents emulated devices, phones or desktop traffic as a living-room television. The buyer pays a CTV price for an impression that never reached a TV screen.

In all three, the fraud lives in the gap between what the bid request claims and what actually happened.

What do ads.txt, app-ads.txt and sellers.json already cover?

IAB Tech Lab's supply chain transparency standards answer the question of who is authorised to sell. ads.txt, introduced in 2017, lets a publisher list the companies authorised to sell its inventory, and app-ads.txt applies the same idea to apps, including CTV apps. sellers.json, introduced in 2019, lets a supply-side platform disclose the sellers it represents.

These standards make app spoofing harder, because a buyer can check whether the seller claiming a bundle ID may sell it. They do less against SSAI spoofing, where the declared seller may be legitimate while the traffic is fabricated. And they say nothing about a particular deal. Authorisation answers "may this party sell this app?", not "is this the inventory the buyer agreed to pay for?"

What does a shared deal record fix?

A shared deal record fixes the terms. In a direct or programmatic guaranteed CTV deal, the record can state which app bundles and publishers are in scope, which device types count, whether ads are inserted server-side or client-side, which verification vendor measures delivery, how much invalid traffic is tolerated and what remedy applies above that level. When buyer and seller hold the same record, written at agreement and timestamped, neither side can later claim the deal said something different.

A shared deal record changes how a fraud finding gets resolved. Without one, a verification report flagging spoofed devices opens a negotiation about scope and whose numbers count. With one, the report is checked against accepted terms. In the Agree. Transact. Verify. research, separate buyer and seller records disagreed on at least one of eight deal dimensions, such as CPM, impressions or flight dates, in 95.3% of 90,202 simulated deals; a shared record brought that to 0.19%. Those figures come from a simulation with a published method, not live CTV campaigns, and they measure record disagreement, not fraud.

A shared deal record also fixes who the counterparty is. When agents negotiate for buyers and sellers, a marketplace can check that each connecting agent is authorised by the advertiser or publisher it claims to represent before terms are agreed. That closes a gap the auction never had: an agent claiming to sell a premium app's inventory without the right to do so.

What does a shared deal record not fix?

A shared deal record does not detect fraud. It records what was promised, not what was delivered. Fabricated SSAI requests and spoofed devices pass straight through it. Detection stays with invalid traffic filtering and independent verification, and the CTV schemes above mostly fall into what the MRC calls sophisticated invalid traffic, which routine filtering misses.

A shared deal record also cannot be stronger than its terms. If a deal omits the app bundle list, leaves the insertion method unstated or names no verification vendor, the record faithfully preserves a weak agreement. That risk grows when software writes the terms. In Concourse Bench v1, AI buyers negotiated with sellers run by fixed software policies; of 96 attempts, 55 ended in a completed buy, and of the 110 contracts signed, 95 promised a viewability floor below 70%. A completed deal is not the same as a protective one.

What should a CTV deal record contain to help against fraud?

A CTV deal record that does real work against fraud is specific about origin. It lists the app bundles and publishers in scope rather than a channel category, and names the device types that count as CTV. It states whether the publisher uses server-side insertion and whether the inserting server passes the original device's signals in its requests. It names the verification vendor whose numbers govern, the invalid traffic level that triggers a remedy, and the remedy itself: makegood, credit or the right to end the deal. And it requires every bundle in scope to list the seller in app-ads.txt. None of these clauses is new; what is new is agents agreeing them faster than a trading desk can review.

Where do agent standards fit?

Agentic buying does not change the fraud mechanisms, but it changes where the terms get written. IAB Tech Lab's AAMP framework includes OpenProposal, which standardises how publishers define products and packages in RFP responses, so a buyer agent can compare CTV offers in one format and carry specific terms into the deal. According to IAB Tech Lab, AAMP's support for the Deals API covers programmatic guaranteed, preferred deals and private marketplaces. AdCP, a separate protocol from AgenticAdvertising.org, lets publishers declare which agents may sell their inventory in an adagents.json file on their own domain, a check in the same spirit as app-ads.txt. Neither framework is a fraud detection system.

Alkimi, an agentic advertising marketplace that works within the AAMP framework and published both studies cited above, focuses on the record: buy-side and sell-side agents agree terms on a DealSheet held by both parties, connecting agents are checked as authorised by the buyer or publisher they represent, and humans keep approval rights at the deal level.

Frequently asked questions

What is SSAI spoofing?

SSAI spoofing is fraud in which a server sends fabricated ad requests that imitate server-side ad insertion traffic, so fake impressions look like ads stitched into real household streams.

What is the difference between app spoofing and device spoofing?

App spoofing falsely declares which app an impression ran in. Device spoofing falsely declares what device it ran on, usually presenting non-TV traffic as a television.

Does app-ads.txt stop CTV fraud?

No. app-ads.txt lets a buyer check whether a seller is authorised to sell an app, which makes app spoofing harder, but it does not detect fabricated traffic from an authorised source.

Can a shared deal record detect invalid traffic?

No. A shared deal record fixes what was agreed. Detecting invalid traffic stays with filtering and independent verification, judged against the terms in the record.

What Does a Shared Deal Record Fix in CTV Fraud and Device Spoofing?