Automated abuse arrives quietly. A script scans one promotional code a few thousand times an hour. A scraper walks a range of identifiers hunting for live ones. Neither looks dramatic in the moment; the damage surfaces later, in a drained campaign budget and a dashboard that no longer describes reality.
The fraud is the visible half. The quieter cost is analytical: teams set channel strategy and judge campaign reach from scan data, and decisions made from bot traffic are decisions made from fiction. Suppose a region reports sixty thousand scans and forty thousand were scripted; the budget that follows those numbers is being steered by the script's author.
What a script looks like in the data
Picture a coupon campaign going live at nine in the morning. By ten, one code has been scanned from six hundred network addresses across four continents. At the level of a single scan, every request looks well formed. At the level of the timeline, the pattern is unmistakable. Detection therefore has to look across events, at the shape of activity over time, rather than inside any single request.
Four behavioural signals do most of the detection work.
- Rate. Scans arriving at machine cadence, with uniform gaps no human thumb produces.
- Device consistency. Real users show messy variation in hardware, app versions and screen sizes; scripts repeat one profile or cycle through implausibly tidy ones.
- Geo velocity. The same unit scanned in two cities minutes apart implies travel no vehicle delivers.
- One-time-use violations. An identity meant to be redeemed once that keeps turning up is the loudest signal of all, and it is caught at the record, where the duplicate is flagged on its first scan.
- Sequential probing. Consecutive identifiers queried in order suggest enumeration of a code space rather than possession of printed labels.
Rules before models
The temptation is to reach for machine learning first. We start with rules, because a rule can be read aloud to a fraud team and defended in front of an auditor. Each rule states its threshold in plain terms: more scans of one identity than the window allows, a geographic jump above a set speed, a redemption attempt on an identity already consumed. Thresholds come from observed baselines, and baselines differ by product, market and season, so we keep them in policy rather than burying them in code. A festival ticket and a fertiliser bag deserve different limits.
When a rule fires, the response is graded. Log and mark the event. Flag the identity for review. Refuse the scan outright where the value at risk justifies it. We make that refusal at scan time as a deliberate design decision; post-event analysis is useful for reporting and useless for prevention, because by the time a batch job notices the pattern, the discounts are spent.
The false-positive bill
Every threshold arrives with a bill attached, and honest vendors itemise it. A warehouse handheld legitimately scans hundreds of units an hour and looks like a bot on rate alone. A retail counter runs one device all day and fails a naive device-variation check. A wholesaler scanning received stock in bulk has entirely lawful reasons to trip a velocity rule.
Policy thresholds absorb the difference. The same rule carries different limits per campaign, per role and per channel: a registered warehouse device earns a high rate ceiling, a consumer coupon gets a strict one. Where a wrong block would cost a genuine customer, the graded response matters more than the threshold. A soft flag keeps the person moving while the event still lands in the log for review.
Treat the scan endpoint as the asset it is
One framing clarifies the whole subject. Nobody exposes a payments endpoint without rate limits and an audit trail, yet scan endpoints that gate the same money routinely ship with neither.
A scan endpoint that releases value is a payments endpoint with a camera in front of it.
The practical move is an inventory. List which of your codes release value on scan, then decide the threshold and the graded response for each class before launch rather than after the first drained campaign. Bots industrialise whatever they touch. The defence is to make every scan answer to a record and a policy, so that scale starts working for the defender.