Anti-Gaming y Three Strikes: cómo se defiende el Auction

El instinto, cuando leemos "antijuegos", es imaginar un modelo sofisticado de aprendizaje automático que clasifique a los postores en "honestos" y "fraudulentos". Eso no es lo que se está ejecutando. Lo que se está ejecutando son dos cosas más simples, las cuales funcionan mejor de lo que parecen en papel.

Detección continua en el lugarBid

Eda oferta que llega pasa por una verificación antes de ser aceptada. La verificación analiza la actividad reciente del postor en cuatro ventanas de tiempo: los últimos 60 segundos, los últimos 5 minutos, la última hora y las últimas 24 horas. A partir de esa actividad, calcula dos señales: recuento de ofertas rápidas (cuántas ofertas en la ventana más corta) y recuento de retracciones (cuántas de esas ofertas fueron retiradas). Las señales se ponderan según umbrales ajustables por la plataforma y producen una puntuación de sospecha baja/media/alta.

Si la puntuación es alta, la oferta se rechaza automáticamente. Si la puntuación es media, la oferta se acepta pero se marca para revisión en la página antijuegos del operador. Las señales permanecen almacenadas en caché en la fila de la empresa del postor, por lo que la siguiente oferta de la misma empresa no vuelve a ejecutar la consulta de ventana completa: lo suficientemente rápido como para no ralentizar el flujo de ofertas y lo suficientemente preciso como para detectar los peores patrones.

Los umbrales los ajustan los administradores de la plataforma ReVend OS de /admin/auction/risk-settings.. Los valores predeterminados están calibrados en toda la plataforma; los inquilinos no pueden relajarlos en el momento de la publicación.

Auto-ban de tres strikes

La detección continua detecta el mal comportamiento en el momento. Los tres strikes detectan el patrón que solo es visible en múltiples subastas. El tipo de ataque relevante, en la versión 1, es escrow_deposit_timeout: un postor ganó mucho, el sistema creó un depósito en garantía pendiente y el comprador nunca transfirió los fondos dentro del plazo de 7 días. El depósito en garantía se cancela automáticamente y se registra una huelga contra la empresa del comprador.

La tabla de strikes (auction_strikes) está diseñada específicamente. Registra el tipo de ataque, el contexto de origen (escrow_id, deal_id, lot_id, según el ataque), la fecha registrada, una columna de detalles JSONB para cualquier contexto adicional que el flujo de origen desee adjuntar y un trío de autorización (cleared_at, cleared_by_user_id, cleared_reason) para indultos de cumplimiento. Las huelgas aprobadas permanecen en la tabla para auditoría; simplemente ya no cuentan para el umbral.

El umbral está codificado en tres ataques en 180 días. Cuando llega el tercer strike activo, un activador DESPUÉS DE INSERTAR cambia Companies.bidder_blocklisted a verdadero con un motivo del sistema. El activador G3 BEFORE INSERT existente en subasta_bids rechaza cada intento de oferta posterior antes de que alcance la lógica placeBid. El postor es, efectivamente, eliminado de la subasta sin que nadie tenga que acordarse de eliminarlo.

Indultos y auditoría

Compliance puede perdonar ataques individuales desde la página de ataques del administrador (/admin/auction/strikes/[companyId], solo personal de plataforma). El perdón requiere un motivo de al menos 5 caracteres, escrito en la columna cleared_reason. El cumplimiento también puede eliminar la lista de bloqueo completa mediante la acción clearBidderBlocklist existente. De cualquier manera, la fila de auditoría permanece: el indulto se documenta, no se borra. Porque la próxima vez que alguien pregunte "¿por qué ha vuelto este postor?" la respuesta está en una columna, no en la memoria de alguien.