Anti-gaming y three strikes: cómo se defiende el Auction

Al leer “anti-gaming”, el instinto es imaginar un sofisticado modelo de machine learning clasificando postores en “honestos” y “fraudulentos”. No es lo que corre. Lo que corre son dos cosas más simples, y las dos funcionan mejor de lo que parecen sobre el papel.

Detección continua en el momento de pujar

Cada oferta que entra pasa una comprobación antes de aceptarse. La comprobación mira la actividad reciente de la empresa que puja y calcula cuatro señales: ráfagas rápidas dentro de una ventana de 60 segundos, el número total de ofertas retiradas, retiradas agrupadas dentro de una ventana de patrón de 30 minutos, y volumen bruto de ofertas en las últimas 24 horas. Cada señal lleva un peso ajustable por la plataforma; la suma ponderada cae en un nivel bajo / medio / alto. Con los valores por defecto que se entregan, una puntuación de 2 es media y una de 4 es alta.

Si el nivel es alto, la oferta se rechaza con el motivo bidder_high_suspicion. Si es medio, la oferta se acepta pero el postor aparece para revisión en /auction/anti-gaming. Las señales se quedan en caché en la fila de la empresa del postor, así que la siguiente oferta de la misma empresa no vuelve a lanzar la consulta completa de ventana: lo bastante rápido para no frenar el feed de pujas, lo bastante preciso para pillar los peores patrones.

La página de revisión es una cola de trabajo, no un monitor. Dice qué política está activa, quién se encarga del seguimiento, cuándo se analizó la muestra reciente de ofertas y cuáles son los siguientes pasos. Los usuarios de tenant tienen Revisar participantes y Revisar ofertas; el personal de plataforma tiene los ajustes de riesgo, el registro de postores y una acción de bloqueo con motivo obligatorio. Una página vacía significa que nadie de la muestra reciente cruzó los umbrales; no es una auditoría de todas las ofertas de la historia.

Los umbrales y los pesos los afinan los admins de plataforma de ReVend en /admin/auction/risk-settings. Están calibrados para toda la plataforma; un vendedor no puede relajarlos al publicar un lote.

Antes del veto: el umbral de strikes

Los strikes muerden antes que el veto. La política de depósitos de postor lleva un umbral de strikes activos (2 por defecto). Una empresa con esa cantidad de strikes activos se rechaza en la comprobación de elegibilidad con el motivo strike_threshold —ni oferta ni compra directa— mucho antes de que llegue a caer el tercer strike. Dos strikes son un aviso que no se puede ignorar. Tres son la puerta cerrándose.

Veto automático a los tres strikes

La detección continua pilla el mal comportamiento del momento. Los three strikes pillan el patrón que solo se ve a lo largo de varias subastas. Hay dos tipos de strike. escrow_deposit_timeout: un postor ganó un lote, la plataforma creó un escrow a la espera del depósito y el comprador nunca transfirió los fondos dentro de la ventana de 7 días. Un job diario (02:00 UTC) cancela esos escrows, como mucho 25 por ejecución, y registra el strike contra la empresa del comprador. buyer_cancel_after_win: el comprador se largó de un lote ganado.

La tabla de strikes está hecha a medida. Registra el tipo de strike, el contexto de origen (escrow, deal o lote, según el strike), la fecha de registro, una columna de detalles para lo que el flujo de origen quiera adjuntar, y un trío de anulación (anulado el, anulado por, motivo de anulación) para los indultos de cumplimiento. Los strikes anulados se quedan en la tabla para auditoría; simplemente dejan de contar.

El umbral está fijado en el código: tres strikes activos en 180 días. Cuando cae el tercero, un trigger de base de datos pone la empresa en la lista de bloqueo con un motivo generado por el sistema, y el guardia de pujas rechaza cualquier intento posterior antes de que llegue a la lógica de ofertas. El postor queda, en la práctica, fuera del Auction sin que nadie tenga que acordarse de sacarlo.

Indultos y auditoría

El personal de plataforma puede indultar strikes concretos desde /admin/auction/strikes/[companyId]. El indulto exige un motivo de al menos 5 caracteres, que se escribe en la columna de motivo de anulación. También pueden levantar el bloqueo en sí y gestionar niveles de verificación y estado de bloqueo en /admin/auction/bidders. En cualquier caso, la fila de auditoría se queda: el indulto queda documentado, no borrado. Porque la próxima vez que alguien pregunte “¿por qué ha vuelto este postor?”, la respuesta está en una columna y no en la memoria de nadie.