Main site

Advertising AI agent · Ad verification

Ad-Verification & Fraud-Triage AI Agent

Triage invalid-traffic and misrepresentation alerts, assemble the evidence a claim needs and track the window it has to be filed in — a person confirms fraud, blocks supply and files.

Typical delivery
4–6 weeks
Deployment
Your stack
Block sign-off
Named person
After launch
Agent Care

What this agent does

Triages the alerts, a person calls fraud

In

  1. 01

    Take in verification-vendor alerts, exchange and DSP log anomalies, and platform invalid-traffic reports.

  2. 02

    Attach the supply path, the ads.txt and sellers.json position, and the format each impression ran in.

Reason

  1. 03

    Separate general from sophisticated invalid traffic, and separate both from a measurement artefact.

  2. 04

    Test the declared domain, app and seller against the chain the bid record actually shows.

  3. 05

    Size the exposure in impressions and spend, and count the days the notice period has left.

Decide

  1. 06

    Rank findings by evidence strength and exposure, and drop the ones no claim can be built on.

  2. 07

    Route every fraud call, supply block and claim to the person who owns that decision.

Out

  1. 08

    Prepare the claim pack in the format the exchange, vendor or platform accepts, for a person to file.

  2. 09

    Retain the alert, the evidence, the reviewer's call and what the counterparty paid or refused.

Product statement

The agent triages, evidences and prepares. It does not confirm fraud, block supply or file a claim — a named person does each of those.

Example workflow

One alert, end to end

  1. 1Alert arrivesA verification-vendor flag, a log anomaly in the exchange or DSP, or a platform invalid-traffic report
  2. 2Path reconstructedThe declared domain, app bundle and seller set against ads.txt, sellers.json and the chain on the bid record
  3. 3Finding classifiedGeneral invalid traffic, sophisticated invalid traffic, misrepresented inventory, or a measurement artefact
  4. 4Evidence and window assembledImpression-level records, the sources that agree, the exposure sized, and the days the notice period has left

No human action required

Stages 1 to 4 run without a person in the loop — the path reconstruction, the classification and the evidence pack are finished before anyone is asked to read anything.

5DecisionSplits on evidence strength and the claim window
Evidenced, window still open

Reaches the reviewer ready to file.

Thin evidence or artefact suspected

Held for triage, with no block proposed.

Verification lead and account owner

The verification lead confirms the finding and decides what is blocked; the account owner files the claim and carries the conversation with the counterparty.

Confirm · Reclassify · Reject

Approved — handed back

  1. 6Blocked and claimedOnly after a person confirms the finding, names what is blocked and files the claim
  2. 7Outcome evaluatedAlert precision against confirmed cases, claim acceptance, recovery, and what each block cost the publisher

Reclassified findings

Every finding a reviewer overturns is counted, in both directions.

What should not run autonomously

Human approval stays in control

Outside the boundary — human approval required

8 items

  • Confirming that an impression was fraudulent.
    • Blocking a publisher, app, seller or supply path.
    • Filing a claim or refund request with a counterparty.
    • Accepting a make-good in place of a credit.

  • Automation boundary

    Agent acts unaided

    • ✓Reconstruct the declared path against ads.txt, sellers.json and the bid record.
    • ✓Classify traffic as general, sophisticated, misrepresented or a measurement artefact.
    • ✓Assemble impression-level evidence in the format the counterparty accepts.
    • ✓Track the notice period and rank findings by exposure and evidence strength.

    Write actions run only inside the approval boundaries agreed during implementation. Blocking supply and filing a claim are not among them.

    • Naming a publisher as fraudulent to a third party.
    • Changing an inclusion list or supply-path allowlist.
    • Setting the thresholds that trigger a block.
  • Withdrawing, settling or escalating a disputed claim.

Example output

One flagged impression, annotated

Everything the agent proposes is attached to the alert it came from.

Triage output · single finding

Illustrative example
Alert source
Verification vendor, post-bid
Inventory
CTV app, resold path
Window
Closes this week
Classification
Misrepresented inventory
Confidence
91%
Claim
Prepared, not filed

As received

The alert and the bid record exactly as the vendor and the exchange logged them, with the path each one declared.

Evidence used

  • Bid-record supply path
  • Seller line in ads.txt
  • App bundle mismatch

Why it is held

The ads.txt check passes — the seller is authorised. The app in the bid record is not.

What the score decides

It decides how hard a reviewer looks before blocking a seller, not whether fraud occurred.

Action

ConfirmReclassifyReject

Value

Where AI adds value

The same four claims, placed at the point in the workflow where each one applies.

Where the value lands

Value 01 – 04

Every alert and log line

From vendors, exchanges and platforms

03Path & evidence

Reconstruct the path that carried the impression

Set the declared domain, app and seller against ads.txt, sellers.json and the supply chain on the bid record, rather than against the label on the report.

01Approved path

Take the triage queue off the analyst

The deduplication, the path reconstruction and the evidence pack are done before a person opens the alert, so the hour goes on judgement rather than assembly.

02Human review

Reach the claim before the window shuts

Findings worth a claim are ranked and dated now, instead of surfacing after the counterparty's notice period has already run out.

04

Build an evidence trail

Retain the alert, the bid record, the reconstructed path, the classification, the reviewer's call, the claim as filed and what the counterparty paid or refused — on both paths.

Integrations

Typical integrations

Five system groups connect to the same agent. Which of them are in scope is decided in discovery.

  • Verification vendors

    • DoubleVerify
    • IAS
    • HUMAN
    • Pixalate
    • vendor alert APIs

  • DSPs & exchanges

    • DV360
    • The Trade Desk
    • Amazon Ads
    • exchange and log-level feeds

  • Supply-chain sources

    • Inventory lists
    • ads.txt and app-ads.txt
    • SupplyChain object
    • sellers.json

Agent

Ad verification & fraud triage

  • Reconstructs paths
  • Classifies traffic
  • Prepares claims

  • Billing & warehouse

    • Invoices
    • credit notes
    • make-goods
    • BigQuery
    • Snowflake
    • warehouse tables

  • Observability & evaluation

    • OpenTelemetry
    • Langfuse
    • Supported monitoring/evaluation sources

Integration availability depends on the client's existing systems and API access.

Agent controls

Six layers between the model and the block list

Each control wraps the one inside it. A finding clears every layer before a block, judged under the vendor's definition — and the fraud call sits outside all six.

L6 · Outermost — last line of defence

Inward → L1 · closest to the model

L6Rollback / safe modeReturn triage to the team and lift blocks if evaluations or signals degrade.Roll back
L5TraceabilityRecord the alert, evidence, reviewer call, claim and counterparty response.Record
L4Definition stampingEvery finding carries the vendor, definition and version it was judged under.Stamp
L3Block and claim gateNo supply is blocked and no claim is filed without a named person.Gate
L2Artefact testMeasurement gaps and server-side patterns are ruled out first.Rule out
L1Corroboration ruleNo finding stands on one source; the log has to agree with the alert.Corroborate
Model coreTriage — classification, reconstructed path, evidence pack, exposure and days remaining
L1 – L2
Decide whether a finding may stand
L3
Decides who blocks supply and files
L4 – L5
Keep every finding traceable to its source
L6
Pulls automation back when signals degrade

How Nestack evaluates it

Evaluate the triage — not only the alerts that were caught.

Coverage runs the whole depth of the workflow, and every layer is cut by slice.

Surface — the queue a reviewer works through

  1. E1Final-output evaluationDid the finding hold when a person checked it against the evidence?
  2. E2Step-level evaluationDid it reconstruct the path from the bid record, not the report label?
  3. E3Tool evaluationDid it read the correct account, seller, app and date range?
  4. E4Missed-fraud recallWhat did it miss where fraud was later confirmed by someone else?
  5. E5Slice evaluationHow does performance change across formats, supply paths and vendors?
  6. E6Business outcomeClaims filed inside the window, claims accepted, and supply blocked in error.

Floor — the spend recovered and the waste that stops

Failure modes

Where each failure originates in the agent

Seven failure modes plotted against the five stages of the agent lifecycle.

Agent lifecycle

Direction of processing →

  1. 01 · Signal intake

    1 mode

    • AV-01

      Artefact called fraud

      A server-side or proxy pattern is read as invalid traffic.

    Stage gathers

    Vendor alerts, exchange logs and platform reports

  2. 02 · Classification

    2 modes

    • AV-02

      Legitimate publisher blocked

      A false positive cuts a real publisher's revenue.

    • AV-03

      Authorised but misrepresented

      The ads.txt chain checks out; the inventory does not.

    Stage judges

    Declared domain, app and seller against the chain

  3. 03 · Evidence & claim

    2 modes

    • AV-04

      Confirmed after the window

      Fraud is called once the notice period has closed.

    • AV-05

      Evidence the counterparty rejects

      The pack lacks the impression records a claim needs.

    Stage assembles

    Impression-level proof in the format a claim needs

  4. 04 · Block / output

    1 mode

    • AV-06

      Pennies chased, waste untouched

      Small credits are worked while the bad path keeps running.

    Stage returns

    The finding a person blocks, claims or rejects

  5. 05 · Change / Version

    1 mode

    • AV-07

      Vendor definition moved

      A threshold changes and the rates stop reconciling.

    Stage tracks

    Model, prompt, threshold and definition changes

  • Sev-1 · legitimate supply is cut on a false call
  • Sev-2 · recoverable spend is written off
  • Sev-3 · the queue misleads and waste persists
See the complete Advertising failure-mode catalogue

Affected slices

A low rate for the account hides the path that is wrong

Invalid-traffic rates can sit inside benchmark overall while a few formats and supply paths carry nearly all of the findings a reviewer overturns and nearly all of the claims a counterparty refuses. Nestack reports performance by slice, not only in total.

Slice performance — reported separately, not only in aggregate

Illustrative example
SliceFailure rateLiftLift vs. thresholdStatus
CTV and SSAI inventory6.3%3.6×Review
Resold and rebroadcast paths4.9%2.8×Review
MFA-adjacent long-tail display2.8%1.6×Watch
Direct premium web display1.2%0.7×Normal

Bar: overturned-finding lift vs. direct-display baseline · scale 0–4.0× · tick marks the 2.0× review threshold

2 of 4 slices over threshold

Evidence-linked improvement

The window closes whether or not the evidence is ready

Notice periods run from the invoice, not from the day a pattern becomes obvious. A cycle that sharpens detection but not speed still claims too late.

Improvement cycle · five stages

Switchback — the path turns at Improve and returns at Learn

  1. 01

    Detect

    Alert precision, a missed case or claim acceptance moves on one path or format.

  2. 02

    Diagnose

    Traced to the signal, the path reconstruction, the evidence pack or a threshold.

  3. 03

    Improve

    The rule, threshold or pack format is changed, re-approved by the verification lead and version-linked.

  4. 04

    Verify

    Re-run against confirmed cases and against the blocks a reviewer overturned.

  5. 05

    Learn

    The refused claim becomes a regression case and the counterparty's evidence requirement is written down.

  6. Learn → Detect

    The return edge. Each cycle is re-timed against the shortest notice period in the stack, not the average one.

Typical build scope

Twelve workstreams across six weeks

The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, alert and log access, classification and path reconstruction, evidence and evaluation, then the block workflow and handover.

Workstream

Week 1Week 2Week 3Week 4Week 5Week 6

  1. 01Triage discovery and automation-boundary definition.Week 1
  2. 02Verification-vendor and platform alert feeds.Week 1, Week 2
  3. 03DSP, exchange and log-level data access.Week 1, Week 2
  4. 04Supply-path sources: ads.txt and sellers.json.Week 2
  5. 05Invalid-traffic taxonomy and classification.Week 2, Week 3
  6. 06Declared-path and misrepresentation checks.Week 3
  7. 07Measurement-artefact and unmeasured-impression handling.Week 3, Week 4
  8. 08Evidence packs in each counterparty's format.Week 4
  9. 09Claim-window tracking and escalation rules.Week 4, Week 5
  10. 10Evaluation suite, slices and regression cases.Week 4, Week 5
  11. 11Block workflow and reviewer routing.Week 5, Week 6
  12. 12Observability, deployment and Agent Care handover.Week 6

12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallel

Final scope and sequence confirmed in discovery

Engagement tiers

What each tier includes

Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.

Capability✓ in scope · — not at this tierPilotOne channel, one vendorProductionProduction alert pipelineAdvancedMulti-vendor / multi-market
Introduced at Pilot
Alert intake and deduplication✓✓✓
Path reconstruction and classification✓✓✓
Evidence pack per finding✓✓✓
Named-reviewer sign-off✓✓✓
Baseline evaluation✓✓✓
Introduced at Production
Claim-window tracking and escalation—✓✓
Counterparty-specific claim formats—✓✓
Log-level and supply-path analysis—✓✓
Block workflow and allowlist controls—✓✓
Introduced at Advanced
Multi-vendor definition reconciliation——✓
CTV, retail media and enterprise controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build price
Confirmed after discovery based on the channels, vendors and exchanges in scope, log-level data access, the claim formats required, block controls and deployment requirements.
Separate from build
Build pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.

What we need from you

What you bring, and what we build with it

Each input maps to a piece of build scope and a week in the delivery timeline.

  1. 01The alerts and reports you get today, and who acts on them

    Triage discovery and automation-boundary definition

    Week 1

  2. 02Access to verification-vendor, DSP and exchange APIs

    Alert feeds and log-level data access

    Week 2

  3. 03The invalid-traffic definitions and thresholds you buy on

    Classification rules and measurement-artefact handling

    Week 2

  4. 04Your ads.txt, sellers.json and inventory-list sources

    Path reconstruction and misrepresentation checks

    Week 3

  5. 05Claims you have filed, including the ones that were refused

    Evidence packs, evaluation suite and regression cases

    Week 4

  6. 06Each counterparty's notice period and evidence requirement

    Claim-window tracking and escalation rules

    Week 4

  7. 07Named reviewers and who is allowed to block a seller

    Block workflow, allowlists and reviewer routing

    Weeks 5–6

Nothing else is required

Deployment, documentation and Agent Care handover are ours.

Delivery timeline

Four phases across six weeks

Phases are drawn over the weeks they actually occupy. Week 5 carries both the evaluation slices and the first blocks and claims made under signature.

Phase

W1

W2

W3

W4

W5

W6

  1. DiscoveryW1
  2. BuildW2 – W3
  3. EvaluateW4 – W5
  4. Pilot & LaunchW5 – W6

Week focus

W1Alerts in scope, the definitions you buy on, and who may block

W2Vendor, DSP and exchange feeds, and log-level access

W3Path reconstruction, classification and artefact handling

W4Evidence packs, claim-window rules and evaluation suite

W5Block workflow, first claims filed and targeted corrections

W6Production validation, overturn review and Agent Care handover

Reading the band
The claim-window rules and the evidence packs are built in week 4, before anything is blocked or filed in week 5. The bars show that dependency, not a smooth ramp.
At the end of W6
Claims have been filed under a named reviewer and every block overturned in review has been counted, then Agent Care takes over monitoring.
Duration
Six-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.

Next step · Advertising AI agent

Build a fraud-triage agent around the alerts you already pay for.

Show us a month of verification alerts, the log-level data behind them and the last claim you filed or gave up on. We'll triage that month end to end and show you which findings would have survived a counterparty's review, and which would have cost a publisher money for nothing.

Typical delivery
4–6 weeks
Deployment
Your verification and buying stack
Block sign-off
Named person, always
After launch
Agent Care available

Nestack Agents · Ad verification & fraud triage

AGT-AM-08 · Agent Care available after launch

Build a fraud-triage agent

Four questions so the call starts from your actual setup — then pick a time that suits you.

About you
Your setup

No obligation. We’ll map the workflow, name the automation boundary and tell you if an agent is the wrong answer.