Ticket Scalping and Inventory Hoarding Bots Guide: Fair Drops, Queues, Limits and the Law

When a concert on-sale or a limited product drop sells out in seconds to automated buyers, the business loses its customers' trust, its pricing control and often its relationship with the artist or brand, even though every sale technically succeeded. Scalping bots buy scarce stock faster and in larger volume than any person can, and inventory hoarding bots hold stock in baskets or reservations without paying, so genuine customers see "sold out" while nothing has sold. This guide is for fraud, product, platform and security teams running ticketing, limited releases, restaurant or appointment booking, and travel inventory. It covers how these attacks show up in your data, the legal backdrop in the US and UK, and the design controls that work: queues, purchase limits, hold rules, identity and payment linkage, and fairness mechanisms such as raffles. It goes deeper than the Bot Management Guide, which explains bot detection in general, and stays defensive: it describes attacker behaviour only as far as defenders need to recognise it.

Key takeaways

• Scarcity is the attack surface. OWASP names the two core threats: OAT-005 Scalping (obtaining limited goods by unfair methods) and OAT-021 Denial of Inventory (depleting stock without completing the purchase), and both target the business rules around scarce stock rather than a software flaw.
• Detection alone loses the race. A drop is over in minutes, so the controls that matter are designed in before it starts: a virtual queue, per-person limits, short holds and pre-registration.
• Limit the person, not the session. Purchase limits enforced per browser session or IP address are trivially spread across accounts; enforce them across linked accounts, payment instruments, delivery addresses and verified phone numbers.
• The law helps, but only afterwards. The US BOTS Act (15 U.S.C. 45c) and the UK Breaching of Limits on Ticket Sales Regulations 2018 make bot circumvention of ticket controls unlawful, and regulators act on evidence your logs provide.
• Fairness is a design choice. For the highest-demand releases, raffles, verified fan registration and identity-bound tickets remove the speed advantage that bots exist to exploit.

Scalping, sniping and denial of inventory

The OWASP Automated Threats to Web Applications project gives a shared vocabulary. Using it in requirements and incident reports avoids arguments about what "bot traffic" means.

Scalping and denial of inventory often work together. Seat spinning holds the best seats repeatedly so they never reach the public, then releases them into a controlled window for the operator's own accounts. In retail, hoarding baskets during a drop forces stock out of circulation while the operator's checkout bots complete purchases. Both depend on a supply of accounts, so Fake Account Creation and Sign-up Fraud controls are part of the defence.

Why this is a security problem, not just a commercial one

• Account and payment abuse travels with it: fake and stolen accounts, card testing to prepare payment instruments, and account takeover of genuine fans with purchase history or presale access. See the Account Takeover Prevention Guide and the Card Testing and Carding Attacks Defence Guide.
• Load looks like an attack: drop traffic can resemble a denial of service, and NIST SP 800-53 SC-5 Denial-of-service Protection applies to the queue and checkout tiers.
• Resale fuels consumer scams: inventory bought by bots feeds secondary listings where buyers meet fakes and duplicates. See the Ticket Scams Guide.

How scalping shows up in your data

Defenders rarely see a single bot. They see distributions that do not look like people. These are the signals worth building before a drop, each paired with what normal looks like.

No single signal is proof. Residential proxies make network signals weak on their own, and real fans also buy at speed. Combine signals into a risk score per order and per linked cluster of accounts, and review the cluster rather than the single order. The Transaction Monitoring and Behavioural Biometrics Guide covers scoring approaches.

Design controls before the drop

The strongest controls change the rules of the sale so that speed and volume stop paying. Use them in layers.

Virtual queues and waiting rooms

• Randomise the starting line: admit everyone who arrives before the on-sale time into a waiting room, then assign queue positions randomly at the start. Arriving with a thousand sessions at 09:59:59 then gives no advantage over arriving at 09:45.
• Bind the queue token: issue a signed, single-use, short-lived token on exit from the queue, bound to the account and session, and require it on every inventory and checkout call. Reject direct calls to checkout APIs without a valid token, which stops bots that skip the queue.
• Control admission rate: release users at a rate the inventory and payment tiers can serve, and protect the origin so it cannot be reached around the queue.
• Limit queue entries: one queue position per account, and challenge or deduplicate entries that share strong linkage signals.

Purchase limits that hold

• Define the limit in policy: OWASP ASVS 5.0 V2.1.3 asks for business logic limits to be documented per user and globally, and V2.3.2 asks for them to be implemented as documented. Write down the per-event or per-product limit and the identifiers it applies to.
• Enforce across identifiers: apply the limit per account, per payment instrument (card fingerprint, not full number), per normalised delivery address, per verified phone number and per device cluster.
• Enforce at commit, not at basket: check limits again when the order is confirmed and when tickets are transferred, because bots split purchases across accounts and consolidate afterwards.
• Cap orders per time window: ASVS V2.4.2 asks that business flows require realistic human timing; reject orders completed faster than a person could.

Hold and reservation rules against hoarding

• Short holds for scarce stock: reduce basket and seat hold times during a drop, and release held stock automatically on expiry.
• Cap concurrent holds: limit active holds per account and per linked cluster, and block re-holding the same items immediately after release.
• Require commitment earlier: take a payment authorisation or deposit before a hold for high-demand inventory, or reserve only after the queue token is presented.
• Watch hold-to-purchase ratios: a cluster holding many seats and buying few is a denial of inventory signal even when no single account looks unusual.

Fairness mechanisms for the highest demand

Detection and response during the sale

Detection still matters during the sale and afterwards. The aim is to stop orders before fulfilment and to cancel what got through.

1. Edge and bot management: client signals, challenges and reputation at the edge, tuned for the drop window. Use challenges sparingly at peak; see the CAPTCHA and bot challenges guide on their limits.
2. Account and identity checks: step-up verification for new accounts, accounts with recent credential changes, or clusters that share devices or addresses.
3. Order scoring: score each order on the signals above and hold high-risk orders for review rather than declining them instantly, which tells the operator less.
4. Post-sale review: before tickets issue or goods ship, cluster orders by linkage and cancel those that breach limits, as the terms of sale allow.
5. Resale monitoring: match seat and barcode data from marketplace listings to orders, and use it to confirm clusters and refine rules.

Logging matters for both tuning and legal action. ASVS V16.3.3 asks for logging of attempts to bypass business logic and anti-automation controls; keep queue token issuance, limit rejections and cancellations with timestamps and linkage data. This maps to NIST SP 800-53 AU-6 and SI-4 and CSF 2.0 DE.AE-02.

Metrics that show it is working

• Share of inventory bought by flagged clusters: after post-sale review, by event or drop.
• Resale share: proportion of sold seats or items appearing on secondary listings within seven days.
• Hold-to-purchase ratio: per account and cluster during the drop window.
• Limit breach cancellations: orders cancelled for breaching limits, and the share later disputed by genuine customers.
• Queue bypass attempts: checkout calls without a valid queue token.
• Customer complaints: "sold out instantly" complaints and contact rate per drop.

The legal backdrop: BOTS Act and UK ticket limits

Laws in this area target the scalper, not the platform, but they shape what evidence and controls the platform should keep. This section summarises primary sources checked on 8 November 2026.

In the US, Executive Order 14254 of 31 March 2025, Combating Unfair Practices in the Live Entertainment Market, directed the FTC to rigorously enforce the BOTS Act and to work with state attorneys general, including by sharing information or evidence. Both laws apply to tickets; sneaker and other retail drops rely on terms of sale, contract and general fraud law instead, so write clear purchase limits and cancellation rights into retail terms.

The UK offence turns on a "sales limit", so publish the limit clearly in the sale terms. The US Act turns on circumvention of a technological control, so a queue, a purchase limit enforced in code and a CAPTCHA are all controls that the Act protects. In both cases, logs showing the control and the circumvention are the evidence a regulator needs. This guide summarises these laws and is not legal advice.

Lessons from enforcement cases

The FTC's first BOTS Act cases, announced in January 2021 against three New York ticket brokers, show the pattern defenders should design against. The FTC alleged the brokers used automated software to search for and reserve tickets, bought more than 150,000 tickets for popular events, and used software to hide their IP addresses along with hundreds of fictitious accounts and payment cards to get around per-event ticket limits. The judgments totalled more than USD 31 million, partially suspended, with over USD 3.7 million to be paid, and the orders barred evading ticket limits, using false identities and using bots.

Three lessons for platforms follow. Limits enforced per account were defeated with many accounts, so enforce them across payment instruments, addresses and devices. IP address controls were defeated by hiding the origin, so network signals must be one input among several. And the case relied on the platform's own records of accounts, cards and purchases, so retain them in a form that supports investigation.

Where identity fits

Scalping is ultimately an identity problem: one actor pretending to be many buyers. Controls that establish "one person, one entitlement" do most of the work. Verified phone numbers and payment instrument fingerprints raise the cost of each fake buyer; stronger sign-up checks reduce the supply of accounts; and passkeys or MFA on accounts with presale access stop account takeover of real fans. Identity proofing is rarely proportionate for retail drops, but for the very highest-demand events some organisers use it for verified registration. See the Identity Proofing and KYC Guide. Legitimate automation also exists: fans increasingly use AI assistants to buy on their behalf, so decide in policy whether agent purchases are allowed and how they are identified. See the Bot vs AI Agent Traffic Management Guide.

Implementation roadmap

1. Baseline: after the next drop, measure resale share, hold-to-purchase ratio and new-account share among buyers. This sets the case for change.
2. Write the rules: document purchase limits, hold times and cancellation rights in the terms of sale and as business logic requirements.
3. Build linkage: normalise addresses, fingerprint payment instruments and link accounts by device and phone so limits can apply to clusters.
4. Queue in monitor mode: run the waiting room and queue tokens on a smaller release first, logging bypass attempts without blocking, then enforce.
5. Pilot fairness mechanisms: try a raffle or pre-registration on one high-demand release and compare resale share.
6. Post-sale review loop: staff a review window between sale and fulfilment, with rollback: reinstate wrongly cancelled orders quickly and record why.
7. Refresh before every major drop: attackers adapt between events, so rehearse load, queue and limit enforcement each time.

Small merchants can get most of the value from a hosted waiting room, documented limits and payment instrument linkage. Large ticketing and retail platforms need cluster-level scoring, a review team and marketplace monitoring.

Common failure patterns

• Limits per session or per IP: spread across thousands of accounts and proxy addresses in minutes.
• A queue that guards the page but not the API: bots call checkout or seat endpoints directly without a queue token.
• Long holds on scarce stock: generous basket or seat hold times invite denial of inventory and seat spinning.
• First come, first served for everything: rewarding arrival time hands the advantage to the fastest automation.
• Blocking instantly and loudly: immediate declines teach the operator which signals you use; holding for review tells them less.
• No post-sale review: tickets issue and goods ship before anyone looks at clusters, leaving resale and chargebacks as the only signal.

Framework mapping

Practitioner checklist

• Classify each high-demand flow against OWASP OAT-005, OAT-013, OAT-019 and OAT-021.
• Document purchase limits, hold times and cancellation rights in terms of sale and requirements.
• Run a randomised waiting room with signed, single-use queue tokens checked on every inventory and checkout call.
• Enforce limits per account, payment instrument fingerprint, normalised address, phone and device cluster, at commit and on transfer.
• Shorten holds for scarce stock and cap concurrent holds per cluster.
• Score orders and hold high-risk ones for a post-sale review before fulfilment.
• Log queue token issuance, limit rejections and cancellations as evidence for BOTS Act or UK regulation complaints.
• Use raffles or verified registration for the highest-demand releases.
• Track resale share and hold-to-purchase ratio per drop.

Standards and references

• OWASP: Automated Threats to Web Applications
• OWASP: OAT-005 Scalping
• OWASP: OAT-021 Denial of Inventory
• OWASP: Application Security Verification Standard 5.0
• FTC: Better Online Ticket Sales Act
• FTC: FTC Brings First-Ever Cases Under the BOTS Act
• legislation.gov.uk: The Breaching of Limits on Ticket Sales Regulations 2018
• The White House: Combating Unfair Practices in the Live Entertainment Market

Related NHI Mgmt Group resources: Bot Management Guide, Top 10 Automated Bot Attacks, Fake Account Creation and Sign-up Fraud Guide, Rate Limiting and API Abuse Guide, Ticket Scams Guide.