An SSAI Misrepresentation Reason Code Labels the Bid Request, Not the VAST the Stitch Will Serve

Pre-bid filters finally have a named bucket for server-side ad insertion that does not check out. On 13 October 2026, Pixalate launched Ad Fraud API 3.0, which pairs the existing zero-to-one probability score with Invalid Traffic reason codes drawn from a 46-type taxonomy. Among them is SSAI Misrepresentation: claims SSAI but fails validation. Buyers can block that code, a whole sophisticated category, or every sophisticated type with one rule. That is real progress on the request object.

The same week, Integral Ad Science told trade press that CTV still sees domain spoofing and device spoofing even on premium publishers, because high CPMs attract fraudsters who want to look like television inventory. Those stories land in board slides as rates and reason codes. They do not automatically reach the VAST document the stitcher hands the player after the auction clears.

The gap is structural. A reason code on the bid request describes what the verification vendor inferred from IP, bundle, user agent, and declared insertion path. The SSP still serves the tag or the stitch output into the publisher player and owns the error that never reaches the buyer. When the inner hop drops Error URIs or strips AdVerifications, seller logs can show fill and quartiles while the buyer's post-bid file shows SSAI Misrepresentation on a different slice of the same campaign. Both sides can be reading accurate instruments aimed at different layers.

What SSAI Misrepresentation actually measures

Pixalate defines SSAI Misrepresentation as claims SSAI but fails validation. That is not the same sentence as the MRC's SSAI spoofing example, which is a falsified measurement event in the sophisticated category. The new API label is operational: it returns in a riskTypes array beside the score, alongside codes such as Invalid Bundle IDs, OS Misrepresentation, and User Agent Bundle ID Device Mismatch. Pixalate states that US CTV invalid traffic rose 32 percent in the first half of 2026, citing free-form bundle identifiers, device proliferation, and spoofed SSAI as drivers. The API rollout applies to Ad Fraud API customers now; Analytics, Pre-Bid Blocklist datafeeds, and the Media Ratings Terminal adopt the same taxonomy over the following weeks.

None of that requires the vendor to parse VAST. The check runs where the bid is formed: declared SSAI flags, bundle and device coherence, proxy and data-center paths. A legitimate operator running a real stitcher can still trigger adjacent codes when the request metadata is messy. A fraudulent path can still return XML-shaped responses that fail later in the player. Reason codes compress a complex judgment into a filterable integer. They do not replace a document inspection on the ad response the SSP forwards.

Four-digit codes encode class and category. Pixalate's announcement uses 2202 as Data Center Proxy Traffic and 2207 as App Misrepresentation in an example riskTypes payload. SSAI Misrepresentation sits in the same sophisticated family as those examples. Blocking 22xx is a category decision. Blocking one code is a surgical decision. Neither tells you whether MediaFiles on the stitched inline include delivery and type, or whether a wrapper still exposes VASTAdTagURI targets the player can reach within timeout budgets.

Why the stitch hop hides the failure from the label

Server-side insertion exists because players want a smooth manifest, not because buyers stopped caring about creative structure. The stitcher fetches VAST or wraps a client tag, may transcode mezzanine files, and often fires impressions from infrastructure that looks like a data center. Pixalate's own SSAI Misrepresentation code exists because that pattern is easy to mimic with invalid traffic. It is also how honest SSAI works.

Normalization is where seller-side pain arrives. Stitchers merge wrapper chains, cache regional variants under one campaign key, or drop extensions that slow parsing. An outer wrapper with Impression trackers but no Error element still validates as XML. When the player hits a dead VASTAdTagURI or a MediaFile the device cannot decode, VAST error codes 301, 302, and 303 exist so upstream hops learn the chain broke. If the stitcher never forwarded those Error URIs, the buyer's reason code file and the publisher's player log disagree even though both describe the same user session.

As a solutions engineer at an SSP, you see the sample tag, the vendor documentation, and a demo player long before you see production stitch logs. You are gone before the live stitch hop that rewrites the document. Your handoff is the ad response the publisher integrates, which means your last defensible check is structural: version, required fields, wrapper depth, and one live URL that returns the same shape you approved. Pre-bid SSAI Misrepresentation on the exchange request is input to trafficking policy. It is not output certification for the VAST the seat actually serves.

Verification nodes follow the same split. A buyer may require OMID or a vendor AdVerification block on every CTV line. The pre-bid API can flag misrepresented environment while the stitched inline omits AdVerifications entirely. Post-bid vendors then classify invalid traffic on beacons that never had a verification client to begin with. The fight moves to spreadsheets about SSAI when the immediate fix was a missing node on the inline the stitcher cached.

This wrapper is familiar in SSAI handoffs. It records the seller impression and points at the buyer inline. It omits Error on the wrapper hop. If the inner fetch times out or returns empty VAST, many players emit error 301 or 302 only when an Error URI was present to receive the beacon. Without it, the chain fails quietly from the buyer's perspective while the SSP impression already fired from the stitcher.

A pre-bid block on SSAI Misrepresentation does not catch that XML gap. The misrepresentation label, if it fires at all, fired on request metadata before this document was normalized. The solutions engineer checklist has to include Error on wrappers that still participate in the chain, not only on the inline the buyer emailed as an attachment.

Compare the live URL after geo and cache keys apply. SSAI caches keyed by campaign id are notorious for serving a national wrapper while the player requests a regional inline. The reason code on the original bid does not update when the cache serves a different inner document.

This inline is what a healthy stitch should collapse toward: a playable MediaFile with delivery, type, width, and height, plus duration for pod logic. CTV players skip files missing those attributes even when the URL looks plausible. The SSP demo may have used exactly this shape. Production may strip MediaFile attributes during transcoding or swap the mezzanine URL without updating width and height.

When Ad Fraud API returns SSAI Misrepresentation on the bid, trafficking may pause the line. When the player skips the MediaFile, support tickets go to the publisher app team. Same campaign, two dashboards. Connecting them requires saving the stitched response body, not only the reason code export.

Invalid Bundle IDs and User Agent Bundle ID Device Mismatch codes belong primarily to the bidstream story; see the rtblint note on fraudulent bundle mimicry for OpenRTB fields. This post stays on the document the SSP still forwards after those codes fire or fail to fire.

Sample-tag review before SSP handoff

• Fetch the tag URL the publisher player will call, not only the XML attached in email.
• If the first body is a Wrapper, follow VASTAdTagURI until InLine or hit the hop limit the player uses.
• Confirm Error elements exist on wrapper hops that still record seller impressions.
• Check MediaFile delivery, type, width, and height on the inline the stitcher will cache.
• Match declared VAST version to the player map in the integration doc.
• Compare demo-player output to one production geo if the stitcher caches by region.
• Log whether AdVerifications survived normalization when the IO requires verification.
• Archive the response body when pre-bid shows SSAI Misrepresentation but the player reports fill.

Where document checks sit in the stack

Pixalate's launch explicitly ties reason codes to Pre-Bid Blocklist datafeeds and Analytics columns. That is the right layer for volume control. SSPs still monetize through delivery quality: completion rates, publisher renewals, and makegoods when the buyer's verification rejects the impression post hoc. A reason code reduces how often bad requests enter the auction. It does not guarantee the auction winner's VAST survives your stitcher.

The industry post on SSAI spoofing and falsified measurement remains the conceptual frame for why server beacons confuse defenders. This API change names one more request-side bucket. Operators need both: filter SSAI Misrepresentation where the bid is formed, and lint the VAST before the publisher player does.

vastlint checks structural consistency on pasted XML or fetched tags: wrapper depth, MediaFile attributes, missing Error URIs, and verification nodes relative to declared version. It does not call Pixalate and it does not reproduce IVT scores. It answers whether the tag you are about to hand a publisher would pass a player that strictly implements VAST before anyone debates reason code 22xx.