Anti-gaming en three strikes: hoe de auction terugvecht

Wanneer je “anti-gaming” leest, denk je instinctief aan een geraffineerd machine-learningmodel dat bieders indeelt in “eerlijk” en “frauduleus”. Dat draait hier niet. Wat wel draait, zijn twee eenvoudiger dingen, en allebei werken ze beter dan ze op papier lijken.

Continue detectie op het moment van bieden

Elke bid die binnenkomt, gaat door een check voordat hij geaccepteerd wordt. De check kijkt naar de recente activiteit van het biedende bedrijf en berekent vier signalen: snelle bursts binnen een venster van 60 seconden, het totale aantal ingetrokken bids, retracties die samenklonteren binnen een patroonvenster van 30 minuten, en het ruwe biedvolume over de laatste 24 uur. Elk signaal draagt een gewicht dat het platform kan bijstellen; de gewogen som landt op een niveau laag / medium / hoog. Met de meegeleverde defaults is een score van 2 medium en een score van 4 hoog.

Is het niveau hoog, dan wordt de bid geweigerd met de reden bidder_high_suspicion. Is het medium, dan wordt de bid geaccepteerd maar verschijnt de bieder ter review op /auction/anti-gaming. De signalen blijven gecacht op de bedrijfsrij van de bieder, zodat de volgende bid van hetzelfde bedrijf niet opnieuw de volledige vensterquery draait — snel genoeg om de biedfeed niet te vertragen, precies genoeg om de ergste patronen te vangen.

De reviewpagina is een werklijst, geen monitor. Ze zegt welk beleid actief is, wie de opvolging bezit, wanneer het recente biedstaal geanalyseerd werd en wat de volgende stappen zijn. Tenantgebruikers krijgen Deelnemers bekijken en Biedingen bekijken; platformmedewerkers krijgen de risk settings, het biederregister en een blocklist-actie met verplichte reden. Een lege pagina betekent dat niemand in het recente staal de drempels overschreed — het is geen audit van elke bid die ooit geplaatst is.

De drempels en gewichten worden afgesteld door ReVend platform admins op /admin/auction/risk-settings. Ze zijn platformbreed gekalibreerd; een verkoper kan ze niet versoepelen wanneer hij een lot publiceert.

Voor de ban: de strikedrempel

Strikes bijten al voor de ban dat doet. Het bidder-depositbeleid draagt een drempel voor actieve strikes (default 2). Een bedrijf met zoveel actieve strikes wordt bij de toelatingscheck geweigerd met de reden strike_threshold — geen bid, geen buy-now — lang voordat de derde strike ooit landt. Twee strikes is een waarschuwing die je niet kunt negeren. Drie is de deur die dichtgaat.

Three-strikes auto-ban

Continue detectie vangt wangedrag op het moment zelf. Three strikes vangt het patroon dat pas zichtbaar wordt over meerdere veilingen. Er zijn twee striketypes. escrow_deposit_timeout: een bieder won een lot, het platform maakte een escrow aan die op het deposit wachtte, en de koper stortte de fondsen nooit binnen het venster van 7 dagen. Een dagelijkse job (02:00 UTC) annuleert die escrows, maximaal 25 per run, en registreert de strike tegen het bedrijf van de koper. buyer_cancel_after_win: de koper liep weg van een gewonnen lot.

De strikes-tabel is speciaal daarvoor gebouwd. Ze registreert het striketype, de broncontext (escrow, deal of lot, afhankelijk van de strike), de datum van registratie, een detailkolom voor wat de bronflow er ook aan wil hangen, en een clearance-trio (gewist op, gewist door, reden van wissen) voor pardons vanuit compliance. Gewiste strikes blijven in de tabel staan voor audit; ze tellen alleen niet meer mee.

De drempel staat hardgecodeerd op drie actieve strikes in 180 dagen. Wanneer de derde landt, zet een database-trigger het bedrijf op blocklisted met een systeemreden, en weigert de biedbewaking elke volgende poging voordat die de biedlogica bereikt. De bieder is effectief uit de veiling verwijderd zonder dat iemand eraan moet denken hem te verwijderen.

Pardons en audit

Platformmedewerkers kunnen individuele strikes pardonneren vanaf /admin/auction/strikes/[companyId]. Het pardon vereist een reden van minstens 5 tekens, geschreven in de kolom met de reden van wissen. Ze kunnen ook de blocklist zelf opheffen, en verificatieniveaus en blocklist-status beheren op /admin/auction/bidders. In beide gevallen blijft de auditrij staan — het pardon wordt gedocumenteerd, niet gewist. Want de volgende keer dat iemand vraagt “waarom is deze bieder terug?”, staat het antwoord in een kolom en niet in iemands geheugen.