Ad Fraud Prevention: A Practical Guide for Exchange Operators

Most writing about ad fraud is addressed to buyers: turn on a verification tag, read the report, exclude the bad placements. If you run the exchange, that advice is the wrong shape. A buyer only ever gets to act after the impression served. You get to act before it exists.

That is the whole argument, and it has a simple mechanical form. A fraudulent request passes through four gates on its way through your platform, and the cost of catching it rises sharply at each one:

• Gate 1 — before the auction opens. Authorized-seller and supply-chain checks. A request refused here costs you a few microseconds of CPU. Nothing has cleared, nothing is owed, nothing needs reconciling.
• Gate 2 — before the bid clears. Pre-bid filtering and invalid-traffic scoring. A request refused here costs a buyer nothing and costs you an auction you did not want.
• Gate 3 — before the creative renders. Creative verification on the clearing path. Now money has moved and you are protecting your demand partner’s brand rather than their budget.
• Gate 4 — after the fact. Log-level correlation and reconciliation. This is not prevention. It is accounting, remediation and evidence.

Every control described below belongs to one of those gates. If you are deciding where to spend engineering effort, spend it as far left as you can.

Table of Contents

• Where a fraudulent request costs you, gate by gate
• The fraud types that reach an exchange, and the signals that expose them
• Gate 1: authorized-seller checks before the auction opens
• Gate 2: pre-bid filtering and invalid-traffic scoring
• Does pre-bid filtering slow down the auction?
• Gate 3: creative verification on the clearing path
• Is ad fraud prevention the same thing as brand safety?
• Gate 4: log-level correlation, and what only it can catch
• Where to spend your filtering effort, by channel
• How to evaluate an invalid-traffic or verification vendor
• A runbook for when fraud reaches your partners
• Key takeaways
• Fraud controls built into Floxis
• Sources and standards worth bookmarking

Where a fraudulent request costs you, gate by gate

The reason to think in gates rather than in tools is that it tells you what a miss actually costs. The same fraudulent impression is a rounding error at Gate 1 and a partner conversation at Gate 4.

Two things follow from the table. First, the gates are cumulative rather than alternative — Gate 2 cannot see a spoofed domain that Gate 1 should have rejected, because by then the lie is already in the bid request. Second, nothing at Gate 4 is prevention, however sophisticated the reporting is. A vendor that only tells you about fraud after it happened is a measurement tool, not a prevention tool. Both are worth owning; do not confuse one for the other when you buy.

The fraud types that reach an exchange, and the signals that expose them

Classification is a triage tool, not an academic exercise. When an anomaly shows up in your reporting you want to map it to a likely mechanism in minutes, because the mechanism tells you which gate failed.

Domain spoofing sits at the top deliberately. It is the one type on this list that is fully preventable at Gate 1 with published, free, standardised data, and it is the one your buyers are most likely to catch and hold you responsible for.

Gate 1: authorized-seller checks before the auction opens

This gate is cheap, well-specified and unglamorous, which is why it is so often half-implemented. The standards do the hard part for you; the work is enforcement.

• ads.txt and app-ads.txt declare who is allowed to sell a publisher’s inventory. Crawl them on a schedule rather than trusting a file you read at onboarding — entries change, and a lapsed entry is indistinguishable from a spoof at bid time.
• sellers.json and the supply-chain object make the path itself auditable. Publish your own sellers.json accurately, and validate the schain on inbound requests. An incomplete or self-serving schain is a signal in its own right.
• Declared-identity consistency. A bundle ID that has never appeared with that publisher, a CTV device ID showing up in mobile web traffic, a country in the request that contradicts the resolved geo of the IP — each of these is cheap to evaluate and hard for a spoofer to keep coherent at volume.

The discipline that matters here is refusing to treat these as reporting fields. If your platform records that a request failed ads.txt validation and then runs the auction anyway, you do not have a gate; you have a log line.

Floxis validates ads.txt, sellers.json and schain on the request path, and ships an ads.txt crawler so the authorized-seller list you enforce against is the one that is live today rather than the one you imported last quarter.

Gate 2: pre-bid filtering and invalid-traffic scoring

Gate 1 answers “is this seller allowed to offer this inventory”. Gate 2 answers “is this request worth an auction at all”.

The controls that carry the most weight, roughly in order of effort:

1. Allow and block lists, applied at the dimensions fraud actually moves along. Domain, bundle, publisher, creative ID, IP, device and ad markup. Most operators start with domain and stop there, which leaves the other six open.
2. Invalid-traffic scoring on the request. IP reputation, data-centre ranges, device fingerprint stability and geo consistency, evaluated before the auction runs rather than sampled afterwards.
3. Floor and spend caps that treat suspicion as a price. Not every signal justifies a hard block. Raising the floor on a suspect segment lets genuinely valuable traffic clear and quietly starves the rest.
4. Outcome-linked reporting. Replace raw impression and click volume as your headline health metric with something downstream — post-click retention, conversion rate by source, revenue per thousand. Bots are good at manufacturing the top of the funnel and bad at faking the bottom of it.

There is a structural reason this gate is worth more than its client-side equivalent, and it is not latency. Fraudsters optimise against the controls they can observe. A verification tag in the browser is observable: it can be detected, fingerprinted and served around. A pre-bid rule running inside your exchange is not. Moving controls server-side is not only earlier in the chain, it is harder to evade.

Managing false positives. Auto-exclude only on high-confidence combinations of corroborating signals. Quarantine mid-confidence traffic for 48 to 72 hours of observation before making the decision permanent. Never auto-exclude on a single signal in isolation — one noisy rule that blocks good supply will cost you more partner trust than the fraud it caught.

Start conservative and tighten. An aggressive initial ruleset produces false positives at exactly the moment your team has no baseline to judge them against, and the usual outcome is that everybody stops believing the system.

Does pre-bid filtering slow down the auction?

Latency is the objection every engineering team raises first, and it is usually the wrong thing to worry about. Seller-authorization and list checks are lookups against data you already hold in memory; they resolve well inside the bid timeout you are already committed to, and they run in parallel with work the auction has to do anyway. The real cost of Gate 2 is operational complexity, not milliseconds — rules to maintain, thresholds to tune, and false positives to adjudicate. Budget for that instead, and start with a small ruleset you can reason about. Adding seller authorization and IP reputation first, then behavioural scoring once you have a clean baseline, gets you most of the protection without the noise.

Gate 3: creative verification on the clearing path

By this point money has moved. What is still preventable is what the creative does once it lands: auto-redirects, undeclared third-party calls, malware, and markup that does not match what the buyer described.

Two operating rules make this gate useful rather than decorative:

• Check on the clearing path, not on a sample. A creative scanner that reviews a nightly sample will find the bad creative after it has run for a day. Checks that run on every clearing path find it on the first impression.
• Scan by creative ID, and block by creative ID. Fraudulent creatives rotate through seats and campaigns. Blocking the buyer is a blunt and relationship-damaging response to a problem that is usually one asset wide.

Floxis runs creative checks on every clearing path, with blocking available at creative-ID granularity alongside the other filtering dimensions.

Is ad fraud prevention the same thing as brand safety?

They share machinery and answer different questions. Fraud prevention asks whether the impression was real — a human, on the inventory that was declared, through a seller allowed to offer it. Brand safety asks whether a real impression was appropriate — the right creative, next to acceptable content, in a context the buyer would accept. The overlap is Gate 3, where the same creative scan on the clearing path catches both a malicious redirect and an off-brand asset. The distinction matters when you are buying: an invalid-traffic vendor will not tell you your demand partner’s creative is running next to something they would object to, and a brand-safety vendor will happily verify that a bot saw a perfectly appropriate ad.

Gate 4: log-level correlation, and what only it can catch

Some fraud is invisible in any single event and obvious across the chain. Attribution fraud is the clearest case: nothing about the individual click looks wrong; what looks wrong is a conversion two seconds later, or one publisher holding an implausible share of last-click credit.

To get value here you need three things:

• A request ID that survives the whole chain, from bid request through impression, click and conversion. Without it, correlation is guesswork.
• One log schema rather than several. Cross-event analysis across siloed reporting systems is a data-engineering project every time you want to ask a question.
• Exportable, log-level data. Aggregate dashboards cannot show you a timing distribution, and a timing distribution is how attribution fraud confesses.

This is also the gate that produces evidence. When you go to a supply partner about a bad source, the conversation goes very differently with a request-level export than with a screenshot of a dashboard.

Floxis logs every request, bid and drop with the drop reason attached, and the data is exportable — so the partner conversation starts from a shared record rather than a claim.

Where to spend your filtering effort, by channel

Fraud risk is not evenly distributed, and controls do not transfer cleanly between environments. Prioritise by exposure.

Mobile and in-app

The highest-risk channel for install fraud, SDK tampering and click injection.

• Enforce app-ads.txt for every app in your supply, and re-crawl it on a schedule.
• Treat the declared bundle ID as a claim to be validated, not a label. Bundle IDs that have never appeared with a publisher are worth quarantining on sight.
• Watch post-install engagement by source. A source with volume and no day-one retention is the clearest single fraud signal available in mobile.
• Push back on long click-attribution windows. A thirty-day window is an open invitation to click injection; a week or less is defensible for most categories.

CTV and OTT

Premium prices and less mature measurement make this the most attractive target and the hardest to police. Domain and app spoofing dominate: a cheap device misrepresents itself as a premium streaming environment.

• Cross-reference declared app bundles against verified app-ads.txt entries before the auction, not in a monthly review.
• Flag impossible device-to-content combinations — a CTV device ID appearing in mobile web requests, a living-room app reporting handset-shaped session behaviour.
• Insist on independently audited invalid-traffic measurement for CTV specifically. Accreditation is granted per channel, and desktop accreditation tells you nothing about a connected TV.

Open web and programmatic

Supply-path complexity is itself the attack surface. Every additional hop is another place for a declared domain to change.

• Reject bid requests from sellers not present in the publisher’s ads.txt. This is the single highest-yield rule on this page.
• Validate sellers.json entries against the seller IDs actually appearing in your bid stream.
• Run supply-path analysis and cut redundant hops. Fewer intermediaries means fewer opportunities for spoofing, and it usually improves your economics at the same time.

How to evaluate an invalid-traffic or verification vendor

Most teams evaluate on self-reported detection rates, which are unauditable and therefore meaningless. Evaluate on methodology, accreditation and integration depth instead.

Questions worth asking every vendor:

• Is your invalid-traffic methodology accredited by the Media Rating Council, and for which channels specifically — desktop, mobile, CTV?
• What is your false-positive rate, how do you measure it, and will you provide log-level data so we can validate it independently?
• Do you offer real-time blocking at the ad call, or post-campaign reporting only?
• Which behavioural and network signals does detection use, and how often is the model retrained?
• How do you handle SDK-level fraud in mobile environments?
• What is your turnaround for flagging a newly observed fraud pattern?
• What does the reclaim process look like for verified losses?

Scope any pilot to one channel and a defined window of at least four weeks, and require log-level access so you can correlate their flags against your own anomaly rules. A vendor that resists log-level sharing during a pilot has told you something important about what an audit would find.

This is worth getting right rather than outsourcing to a default, which is why Floxis treats invalid-traffic and creative verification as bring-your-own: the platform works with the provider you choose, or Floxis runs it for you if you would rather not own the vendor relationship.

A runbook for when fraud reaches your partners

Discovery is the easy part. What separates a contained incident from a lost partner is executing a fast, documented remediation that preserves the evidence.

First 24 hours

1. Contain the source. Block at the narrowest dimension that stops the bleeding — creative ID or placement before publisher, publisher before seller.
2. Freeze the evidence. Export the raw request, bid and impression logs for the affected window before any retention policy ages them out.
3. Quantify the exposure. Fraudulent volume multiplied by the effective CPM or CPC for the period gives you the number you will be discussing with everyone else.
4. Tell your demand partners before they tell you. Buyers discover this through their own verification; being the one who raised it is worth more than the credit you will end up issuing.

First week

1. Trace it back to a gate. Every incident maps to a control that was missing, misconfigured or advisory rather than enforcing. Name it explicitly.
2. Close that gate, then check whether the same weakness exists on adjacent paths.
3. Re-check the exclusions you applied in hour one. Emergency blocks are deliberately blunt and quietly cost you good supply if they are never revisited.
4. Reconcile and settle. Issue credits against the quantified exposure rather than an estimate.

Beyond a week

1. Keep an incident log — date, source, signals observed, spend impact, remediation applied. It supports future reclaim and it is the only thing that turns a series of incidents into a pattern you can act on.
2. Monitor the affected metrics for one to two weeks. Invalid-traffic rate, post-click retention and conversion timing should all move in the right direction; if only one does, the remediation was incomplete.
3. Feed the signature back into Gate 1 or Gate 2 so the same pattern is refused next time rather than re-investigated.

Key takeaways

Fraud controls built into Floxis

Fraud prevention bolted on after the fact is expensive and always a step behind. Floxis puts the controls in the auction path itself.

For publishers, ad networks and SSPs running their own exchange, the white-label RTB platform provides authorized-seller checks against ads.txt and sellers.json, full schain validation, allow and block lists across domain, bundle, publisher, creative ID, IP, device and ad markup, and creative verification on every clearing path — under your own brand. Invalid-traffic and creative verification are bring-your-own-key, so you can keep the provider you already trust, or have Floxis run it.

The Prebid.js and Prebid Server infrastructure runs the same control stack, so header-bidding and server-side demand are governed by one set of rules rather than two. Every request, bid and drop is logged with its drop reason and exportable at log level, which means both your fraud investigation and your partner reporting read from the same data.

To see how the control architecture maps onto your supply, request a technical walkthrough.

Sources and standards worth bookmarking

• IAB Europe Guide to Ad Fraud
• IAB Tech Lab — ads.txt
• IAB Tech Lab — app-ads.txt
• IAB Tech Lab — sellers.json and the supply-chain object
• Media Rating Council
• Cloudflare — what is ad fraud