Anti-Fraud
ADBNK identifies invalid traffic through a dual mechanism — multi-layer real-time risk control + retrospective batch detection — and auto-reverses it at settlement, ensuring advertisers only pay for real traffic and publishers' compliant revenue is unaffected.
Two lines of defense
Ad request / impression / click
│
▼
┌───────────────────────┐
│ ① Real-time risk (rule engine) │ score on the fly → block / flag / pass
└───────────┬───────────┘
│ suspicious or hit: mark billable=false
▼
┌───────────────────────┐
│ ② Retrospective batch detection │ re-check credited events → generate reversals
└───────────┬───────────┘
▼
Settlement counts only real, billable traffic① Real-time risk control (rule engine)
Each request is scored across multiple rules, and the action is decided by score:
| Score | Action |
|---|---|
| ≥ 80 | Block (mark invalid) |
| ≥ 50 | Flag as suspicious |
| < 50 | Pass |
Rules span multiple dimensions (a higher score means more suspicion):
| Rule | What it detects |
|---|---|
| IP blacklist | A blacklist hit is judged invalid directly |
| Bot detection | bot/spider/crawler, curl/wget, headless/selenium/puppeteer and similar traits |
| Rate limiting | Per-IP request/impression/click frequency over threshold |
| Fingerprint check | Many-to-many anomalies between device fingerprint and IP; during tracking, checks whether the fingerprint platform matches the UA (FP_UA_MISMATCH) |
| Geo anomaly | Data-center IPs, VPN/proxy, geo jumps |
| Click-time analysis | Click delay too short, clicks with no impression record, expired impressions, automated clicks |
| Session behavior analysis | Abnormal/regular CTR, traffic over-concentrated in a few zones |
| Referer check | Empty Referer, invalid Referer, frequently changing Referer |
Silent handling, no tipping off
On a risk hit the system still returns the ad, but marks that event billable=false (non-billable). A fraudster can't tell whether they've been detected by "whether ads still show", reducing their ability to counter and bypass; meanwhile the platform keeps collecting fraud-behavior data. When the score is extremely high, the IP is auto-added to the blacklist for a period.
② Retrospective batch detection and settlement reversal (Fraud Reversal)
Some fraud only surfaces after accumulating data over time (e.g. regular CTR, after-the-fact confirmed fake orders). The settlement flow therefore builds in retrospective checks:
- Settlement counts only billable traffic: aggregation includes only
billable=1events; traffic judged invalid in real time never enters billing from the start. - Re-check credited events: a batch task re-evaluates events already
calculated; those hitting batch-invalid (batch_valid=false) or manual fraud (manual_fraud=true) generate a fraud reversal that claws back the settled amount.
Advertisers don't pay for invalid traffic
Whether blocked in real time or caught retrospectively, invalid traffic is never counted toward the advertiser's final charge — real-time is excluded directly, after-the-fact is reversed via fraud reversal. Your spend corresponds to real traffic that passed the double check.
Common types of invalid traffic
| Type | Typical traits |
|---|---|
| Bots/crawlers | Automated UA, headless browser, no real interaction |
| High-frequency inflation | Massive requests/clicks from a single IP/device in a short time |
| Data-center/proxy traffic | From data-center IPs, VPN, proxy — not real end users |
| Abnormal clicks | Millisecond-level clicks after impression, clicks with no matching impression, regular click patterns |
| Fingerprint/UA mismatch | Device fingerprint platform conflicts with request UA (e.g. fingerprint Windows but UA Android) |
| Abnormal sessions | Abnormally high or too-regular CTR, traffic highly concentrated in a few zones |
Compliance advice for publishers
Invalid traffic is reversed — never inflate
Impressions/clicks judged invalid generate no settleable revenue, and retrospective checks even claw back credited amounts. Any inflation, induced clicks, or bot traffic brings no real income and may instead trigger IP bans and account risk.
- Only integrate real human traffic — don't buy or manufacture bot, proxy, or inflated traffic.
- Don't induce clicks — avoid misleading buttons, forced clicks, or disguising ads as content.
- Tag honestly — set tags by the zone's real content and audience; false tagging lowers match quality.
- Protect your zone code — prevent third parties from stealing it to inflate and dragging your account down.
- Watch for anomalies — when CTR or traffic spikes, proactively investigate the source and clean up abnormal channels in time.