All articles
Platform
Fraud review decision tree
A practical escalation framework for classifying suspicious traffic before it impacts campaign quality and payouts.
KiwiWall
ยท
Jul 03, 2026
ยท
11 min read
Fraud review decision tree in brief
Fraud prevention is a workflow problem, not a single blocklist. This decision tree gives operators a consistent path from alert to action.
Who this is for
- Fraud reviewers and traffic operators.
- Publisher and advertiser support teams.
- Analytics teams owning source quality and incident response.
Definition
A review tree has three stages:
- Signal strength: is evidence weak, moderate, or high?
- Evidence source: one signal, or corroborated signals?
- Business impact: immediate harm, delayed quality damage, or cosmetic anomaly?
Decision table
| Signal level | Initial action | Promotion path |
|---|---|---|
| Weak / uncertain | Quarantine and monitor | Promote if signal clears after 2 windows |
| Moderate | Pause source segment, request payload review | Unpause only after payload integrity passes |
| Strong | Block/deny under incident protocol | Reopen only after root-cause closure |
How it works
- Route every alert into one of three lanes: IP, behavior, volume.
- Map the lane to an SLA (hours to review, owner, evidence requirement).
- Escalate only when cross-lane corroboration exists.
- Close cases with explicit rationale and publish retention time.
Checklist
- Define owner for each severity lane.
- Set evidence requirements before manual blocking.
- Track recurring offenders by source and campaign.
- Add lessons learned into cap rules and offer routing.
Conversion link
Apply this before raising volume in Performance tracking and fraud control and move recovered traffic through Affiliate offerwall only after closure.
Next up
Week one launch timeline