Anti-gaming und Three Strikes: wie Auction zurueckschlaegt

Wenn du "anti-gaming" liest, denkst du instinktiv an ein sophisticated Machine-learning Model, das Bidders in "honest" und "fraudulent" einteilt. Das läuft hier nicht. Was läuft, sind zwei einfachere Dinge, und beide funktionieren besser, als sie auf Papier aussehen.

Continuous detection at placeBid

Jeder Bid, der eingeht, läuft durch einen Check, bevor er accepted wird. Der Check schaut auf die recent activity des Bidders über vier Time Windows: die letzten 60 seconds, die letzten 5 minutes, die letzte hour und die letzten 24 hours. Daraus berechnet er zwei Signals — rapid-bid count (wie viele Bids im kürzesten Window) und retraction count (wie viele dieser Bids withdrawn wurden). Die Signals werden mit platform-tunable Thresholds gewichtet und ergeben einen low / medium / high Suspicion Score.

Wenn der Score high ist, wird der Bid auto-rejected. Wenn der Score medium ist, wird der Bid accepted, aber auf der Anti-gaming Page des Operators for Review geflaggt. Die Signals bleiben auf der Company Row des Bidders cached, sodass der nächste Bid derselben Company nicht die vollständige Window Query neu ausführt — schnell genug, um den Bidding Feed nicht zu verlangsamen, präzise genug, um die schlimmsten Patterns zu fangen.

Die Thresholds werden von ReVend OS Platform Admins über /admin/auction/risk-settings gesteuert. Die Defaults sind platform-wide kalibriert; Tenants können sie beim Publish nicht lockern.

Three-strikes auto-ban

Continuous detection fängt in-the-moment misbehaviour. Three-strikes fängt das Pattern, das erst über mehrere Auctions sichtbar wird. Der relevante Strike Type in v1 ist escrow_deposit_timeout — ein Bidder hat ein Lot gewonnen, das System hat ein pending-deposit Escrow erstellt, und der Buyer hat die Funds nicht innerhalb des 7-day Window überwiesen. Das Escrow auto-cancels, und ein Strike wird gegen die Company des Buyers recorded.

Die Strikes Table (auction_strikes) ist purpose-built. Sie records den Strike Type, den Source Context (escrow_id, deal_id, lot_id, je nach Strike), das Recorded Date, eine JSONB Details Column für zusätzlichen Kontext, den der Source Flow anhängen will, und ein Clearance Trio (cleared_at, cleared_by_user_id, cleared_reason) für Compliance Pardons. Cleared Strikes bleiben für Audit in der Table; sie zählen nur nicht mehr zum Threshold.

Der Threshold ist hard-coded auf three strikes in 180 days. Wenn der dritte active strike landet, setzt ein AFTER INSERT Trigger companies.bidder_blocklisted mit einem System Reason auf true. Der bestehende G3 BEFORE INSERT Trigger auf auction_bids rejected danach jeden weiteren Bid Attempt, bevor er die placeBid Logic erreicht. Der Bidder ist effektiv aus der Auction entfernt, ohne dass jemand daran denken muss.

Pardons and audit

Compliance kann einzelne Strikes von der Admin Strikes Page pardonnen (/admin/auction/strikes/[companyId], nur platform-staff). Der Pardon verlangt einen Reason mit mindestens 5 characters, geschrieben in die cleared_reason Column. Compliance kann auch die komplette Blocklist über die bestehende clearBidderBlocklist Action aufheben. In beiden Fällen bleibt die Audit Row — der Pardon ist dokumentiert, nicht gelöscht. Denn wenn das nächste Mal jemand fragt "warum ist dieser Bidder zurück?", steht die Antwort in einer Column, nicht im Gedächtnis von jemandem.