Anti-gaming et three strikes : comment Auction riposte

Le réflexe, quand on lit « anti-gaming », est d’imaginer un modèle de machine learning sophistiqué qui range les bidders en « honnêtes » et « frauduleux ». Ce n’est pas ce qui tourne. Ce qui tourne, ce sont deux choses plus simples, et toutes deux marchent mieux qu’elles n’en ont l’air sur le papier.

Détection continue au moment du bid

Chaque bid qui arrive passe par un contrôle avant d’être accepté. Le contrôle regarde l’activité récente de la company qui bid et calcule quatre signaux : les rafales dans une fenêtre de 60 secondes, le nombre total de bids rétractés, les rétractations qui se groupent dans une fenêtre de pattern de 30 minutes, et le volume brut de bids sur les 24 dernières heures. Chaque signal porte un poids réglable au niveau plateforme ; la somme pondérée atterrit sur un niveau low / medium / high. Avec les valeurs par défaut livrées, un score de 2 est medium et un score de 4 est high.

Si le niveau est high, le bid est rejeté avec la raison bidder_high_suspicion. S’il est medium, le bid est accepté mais le bidder remonte pour revue sur /auction/anti-gaming. Les signaux restent en cache sur la ligne company du bidder, donc le bid suivant de la même company ne relance pas toute la requête de fenêtre — assez rapide pour ne pas ralentir le flux de bidding, assez précis pour attraper les pires patterns.

La page de revue est une file de travail, pas un moniteur. Elle indique quelle politique est active, qui porte le suivi, quand l’échantillon récent de bids a été analysé et quelles sont les étapes suivantes. Les utilisateurs tenant obtiennent Revoir les participants et Revoir les offres ; le platform staff obtient les réglages de risque, le registre des bidders et une action de blocklist avec raison obligatoire. Une page vide signifie que personne dans l’échantillon récent n’a franchi les seuils — ce n’est pas un audit de tous les bids jamais posés.

Les seuils et les poids sont réglés par les admins plateforme ReVend sur /admin/auction/risk-settings. Ils sont calibrés pour toute la plateforme ; un seller ne peut pas les assouplir en publiant un lot.

Avant le bannissement : le seuil de strikes

Les strikes mordent avant le bannissement. La politique de deposit bidder porte un seuil de strikes actifs (2 par défaut). Une company qui atteint ce nombre est refusée au contrôle d’éligibilité avec la raison strike_threshold — pas de bid, pas d’achat immédiat — bien avant que le troisième strike ne tombe. Deux strikes, c’est un avertissement qu’on ne peut pas ignorer. Trois, c’est la porte qui se ferme.

Le bannissement automatique au troisième strike

La détection continue attrape le mauvais comportement de l’instant. Les three strikes attrapent le pattern qui n’est visible que sur plusieurs auctions. Il y a deux types de strike. escrow_deposit_timeout : un bidder a gagné un lot, la plateforme a créé un escrow en attente du deposit, et le buyer n’a jamais viré les fonds dans la fenêtre de 7 jours. Un job quotidien (02:00 UTC) annule ces escrows, au maximum 25 par passage, et enregistre le strike contre la company du buyer. buyer_cancel_after_win : le buyer a laissé tomber un lot gagné.

La table des strikes est faite pour ça. Elle enregistre le type de strike, le contexte source (escrow, deal ou lot selon le strike), la date d’enregistrement, une colonne de détails pour ce que le flow source veut y attacher, et un trio de clearance (cleared at, cleared by, cleared reason) pour les grâces compliance. Les strikes effacés restent dans la table pour l’audit ; ils ne comptent simplement plus.

Le seuil est codé en dur à trois strikes actifs sur 180 jours. Quand le troisième tombe, un trigger de base de données bascule la company en blocklisted avec une raison générée par le système, et le garde-fou de bid rejette chaque tentative suivante avant qu’elle n’atteigne la logique de bidding. Le bidder est, dans les faits, retiré de l’auction sans que personne n’ait à penser à le retirer.

Grâces et audit

Le platform staff peut gracier des strikes individuels depuis /admin/auction/strikes/[companyId]. La grâce exige une raison d’au moins 5 caractères, écrite dans la colonne cleared reason. Le staff peut aussi lever la blocklist elle-même, et gérer les niveaux de vérification et l’état de blocklist sur /admin/auction/bidders. Dans tous les cas, la ligne d’audit reste — la grâce est documentée, pas effacée. Parce que la prochaine fois que quelqu’un demandera « pourquoi ce bidder est-il de retour ? », la réponse sera dans une colonne, pas dans la mémoire de quelqu’un.