Bots and syndicates: what actually stops them
Operators are banning high-volume players and talking about bots. The data says the problem is mostly arithmetic, not software, and the fixes are design changes you can make this month.
Who is actually buying late
Between October and November 2026 we followed 1,288 competition closes across 22 UK sites, and read the public entry lists of 154 finished competitions on sites that publish them. Three things stood out.
- Late buying is a human with an alert, not a bot at the checkout. On the entry lists, the bulk late buys (20 or more tickets, 5% or more of the competition, inside the last hour) were made by 30 accounts in total; 7 repeat buyers made half of them. They buy a median 20 minutes before the close, by hand.
- They buy exactly when the maths says to. A competition becomes a target the moment the unclaimed instant prizes plus the main-draw share are worth more than the remaining tickets cost. Small buyouts (under £500 of tickets) were typically gone within the hour; mid-sized ones (£5,000 to £50,000) sat for hours or days because few people will risk that on prize counts they can't verify.
- Everyone else loses interest once they see it. Where a competition went past the buyout point, the same handful of accounts took it every time. Regular customers were, as one operator put it, taking the risk so that someone else could take the value.
None of that is touched by CAPTCHAs, rate limits or device fingerprinting. The buyer is a person with a card who passed your checks.
1. Score the maths, not the behaviour
Stamp every ticket purchase with the competition's state at that moment: tickets sold, unclaimed prize value, minutes to close. From those you get the expected value of that ticket at the time it was bought. A regular customer's purchases are scattered with respect to expected value; a syndicate account's cluster where it is highest, across competitions and across weeks. Rank accounts by their average expected value at purchase against the population.
It is hard to evade without giving up the edge, because the only way to look ordinary is to buy when it isn't profitable. It needs no fingerprinting, and it links syndicate accounts to each other, since they all appear at the same moments on the same competitions. It runs on data you already hold: your order table and your prize ledger.
2. Remove the buyout point
Scoring tells you who. These stop the giveaway.
- Release prizes with sales. Don't put every instant prize into play at launch. Release them in tranches as the competition fills, so the unclaimed value per unsold ticket never exceeds roughly 80% of the ticket price. The buyout point cannot form. On a hosted platform this is the platform's change to make, and worth asking for.
- Cap the share of what's left, not the ticket count. "Maximum 500 per person" is beaten with accounts. "No account may buy more than 5% of the remaining tickets in the last hour" bites a sniper and nobody else.
- Stop feeding trackers in real time. Publish remaining-prize counts and the sold figure with a delay, or in bands. Transparency is a trust feature and the trade-off is real, but exact live counts are what every tracker depends on. Labels like "best odds now" are an invitation.
- Short basket holds. A ten-minute reservation near a close is a blocking tool. Two or three minutes is enough for a real customer.
3. Check your own draws
If you are going to tell customers your draw is random, be able to show it. The draw-position test takes your completed-competitions page and tells you in an afternoon whether winning tickets land where a fair draw would put them. Run it before someone else does. Commit-and-reveal seeds, or a draw under independent supervision, let you publish the proof rather than the claim.
What not to do
- Bans by name are the weakest tool: accounts are cheap, and a ban with a pending prize invites a dispute.
- Pulling a competition's draw forward or extending it because a buyout approaches is a terms problem waiting to happen; change the design instead.
- Hiding data entirely trades a tracker problem for a trust problem. Lag and bands do most of the work.
Disclosure: the author built and runs a read-only alert tool that reads the same public pages described here. That is how these numbers were measured. See about and disclosure.