Anti-Gaming und Three Strikes: wie die Auction zurückschlägt

Der erste Reflex bei „Anti-Gaming“ ist die Vorstellung eines ausgefeilten Machine-Learning-Modells, das Bieter in „ehrlich“ und „betrügerisch“ sortiert. Das läuft hier nicht. Was läuft, sind zwei einfachere Dinge, die beide besser funktionieren, als sie auf dem Papier aussehen.

Laufende Erkennung im Moment des Gebots

Jedes eingehende Gebot durchläuft eine Prüfung, bevor es angenommen wird. Die Prüfung sieht sich die jüngste Aktivität der bietenden Company an und berechnet vier Signale: Schnellfeuer-Bursts innerhalb eines 60-Sekunden-Fensters, die Gesamtzahl zurückgezogener Gebote, Rückzüge, die sich in einem 30-Minuten-Musterfenster ballen, und das rohe Gebotsvolumen der letzten 24 Stunden. Jedes Signal trägt ein plattformseitig einstellbares Gewicht; die gewichtete Summe landet auf einem Level low / medium / high. Mit den ausgelieferten Defaults ist ein Score von 2 medium und ein Score von 4 high.

Ist das Level high, wird das Gebot mit dem Grund bidder_high_suspicion abgelehnt. Ist es medium, wird das Gebot angenommen, aber der Bieter erscheint zur Prüfung auf /auction/anti-gaming. Die Signale bleiben auf der Company Row des Bieters gecacht, damit das nächste Gebot derselben Company nicht die ganze Fensterabfrage erneut fahren muss — schnell genug, um den Bid Feed nicht auszubremsen, genau genug, um die schlimmsten Muster zu fangen.

Die Review-Seite ist eine Work Queue, kein Monitor. Sie sagt, welche Policy aktiv ist, wer die Nachverfolgung besitzt, wann die jüngste Gebotsstichprobe analysiert wurde und was die nächsten Schritte sind. Tenant User bekommen Teilnehmer prüfen und Gebote prüfen; Platform Staff bekommt die Risk Settings, das Bieterregister und eine Blocklist-Aktion mit Pflichtbegründung. Eine leere Seite heißt, dass in der jüngsten Stichprobe niemand die Schwellen überschritten hat — sie ist kein Audit jedes je platzierten Gebots.

Schwellen und Gewichte stellen ReVend Platform Admins auf /admin/auction/risk-settings ein. Sie sind plattformweit kalibriert; ein Seller kann sie beim Veröffentlichen eines Lots nicht lockern.

Vor dem Bann: die Strike-Schwelle

Strikes beißen, bevor der Bann es tut. Die Bidder-Deposit-Policy trägt eine Schwelle für aktive Strikes (Default 2). Eine Company mit so vielen aktiven Strikes wird beim Eligibility Check mit dem Grund strike_threshold abgewiesen — kein Gebot, kein Buy-now — lange bevor der dritte Strike überhaupt landet. Zwei Strikes sind eine Warnung, die man nicht ignorieren kann. Drei sind die Tür, die zugeht.

Three-Strikes-Auto-Bann

Die laufende Erkennung fängt Fehlverhalten im Moment. Three Strikes fängt das Muster, das erst über mehrere Auctions hinweg sichtbar wird. Es gibt zwei Strike-Typen. escrow_deposit_timeout: Ein Bieter hat ein Lot gewonnen, die Plattform hat ein Escrow angelegt, das auf das Deposit wartet, und der Käufer hat innerhalb des 7-Tage-Fensters nie überwiesen. Ein täglicher Job (02:00 UTC) storniert diese Escrows, höchstens 25 pro Lauf, und verbucht den Strike gegen die Company des Käufers. buyer_cancel_after_win: Der Käufer ist von einem gewonnenen Lot weggelaufen.

Die Strikes-Tabelle ist eigens dafür gebaut. Sie erfasst den Strike-Typ, den Quellkontext (Escrow, Deal oder Lot, je nach Strike), das Erfassungsdatum, eine Details-Spalte für alles, was der Quellflow anhängen will, und ein Clearance-Trio (cleared at, cleared by, cleared reason) für Compliance-Begnadigungen. Bereinigte Strikes bleiben zur Nachvollziehbarkeit in der Tabelle; sie zählen nur nicht mehr.

Die Schwelle ist hart auf drei aktive Strikes in 180 Tagen verdrahtet. Landet der dritte, setzt ein Database Trigger die Company mit einer systemgenerierten Begründung auf blocklisted, und der Bid Guard lehnt jeden weiteren Versuch ab, bevor er die Bieterlogik erreicht. Der Bieter ist damit faktisch aus der Auction entfernt, ohne dass sich jemand daran erinnern musste, ihn zu entfernen.

Begnadigungen und Nachweis

Platform Staff kann einzelne Strikes auf /admin/auction/strikes/[companyId] begnadigen. Die Begnadigung verlangt eine Begründung von mindestens 5 Zeichen, die in die Cleared-Reason-Spalte geschrieben wird. Staff kann außerdem die Blocklist selbst aufheben und auf /admin/auction/bidders Verification Tiers und Blocklist-Status verwalten. So oder so bleibt die Audit-Zeile stehen — die Begnadigung wird dokumentiert, nicht wegradiert. Denn wenn beim nächsten Mal jemand fragt „warum ist dieser Bieter wieder da?“, steht die Antwort in einer Spalte und nicht in jemandes Gedächtnis.