Anti-gaming en three strikes: hoe de auction terugvecht

Wanneer je "anti-gaming" leest, denk je instinctief aan een sophisticated machine-learning model dat bidders classificeert als "honest" of "fraudulent." Dat draait hier niet. Wat wel draait zijn twee eenvoudigere dingen, en allebei werken beter dan ze op papier lijken.

Continuous detection at placeBid

Elke bid die binnenkomt gaat door een check voordat hij wordt accepted. De check kijkt naar recente activity van de bidder over vier time windows: de laatste 60 seconds, de laatste 5 minutes, het laatste hour en de laatste 24 hours. Uit die activity berekent hij twee signals — rapid-bid count (hoeveel bids in het kortste window) en retraction count (hoeveel van die bids werden withdrawn). De signals worden gewogen met platform-tunable thresholds en produceren een low / medium / high suspicion score.

Als de score high is, wordt de bid auto-rejected. Als de score medium is, wordt de bid accepted maar geflagd voor review op de anti-gaming page van de operator. De signals blijven cached op de company row van de bidder, zodat de volgende bid van hetzelfde company niet opnieuw de volledige window query draait — snel genoeg om de bidding feed niet te vertragen, precies genoeg om de slechtste patterns te vangen.

De thresholds worden door ReVend OS platform admins beheerd via /admin/auction/risk-settings. De defaults zijn platform-wide gekalibreerd; tenants kunnen ze niet versoepelen bij publish.

Three-strikes auto-ban

Continuous detection vangt misbehavior op het moment zelf. Three-strikes vangt het patroon dat pas zichtbaar wordt over meerdere auctions. Het relevante strike type in v1 is escrow_deposit_timeout — een bidder won een lot, het systeem maakte een pending-deposit escrow aan, en de buyer wired de funds nooit binnen het 7-day window. De escrow auto-cancelt, en er wordt een strike geregistreerd op de company van de buyer.

De strikes table (auction_strikes) is purpose-built. Ze registreert strike type, source context (escrow_id, deal_id, lot_id, afhankelijk van de strike), recorded date, een JSONB details column voor extra context die de source flow wil meegeven, en een clearance trio (cleared_at, cleared_by_user_id, cleared_reason) voor compliance pardons. Cleared strikes blijven in de table voor audit; ze tellen alleen niet meer mee voor de threshold.

De threshold is hard-coded op three strikes in 180 days. Wanneer de derde active strike landt, flipt een AFTER INSERT trigger companies.bidder_blocklisted naar true met een system reason. De bestaande G3 BEFORE INSERT trigger op auction_bids reject daarna elke volgende bid attempt voordat die de placeBid logic bereikt. De bidder is effectief uit de auction verwijderd zonder dat iemand eraan moet denken hem te verwijderen.

Pardons and audit

Compliance kan individual strikes pardonnen vanaf de admin strikes page (/admin/auction/strikes/[companyId], alleen platform-staff). De pardon vereist een reason van minstens 5 characters, geschreven in de cleared_reason column. Compliance kan ook de volledige blocklist opheffen via de bestaande clearBidderBlocklist action. In beide gevallen blijft de audit row staan — de pardon wordt gedocumenteerd, niet gewist. Want de volgende keer dat iemand vraagt "waarom is deze bidder terug?" staat het antwoord in een column, niet in iemands geheugen.