Saltar al contenido principal
Los eventos los evalúa el mismo motor que las transacciones. Hay un único modelo de reglas, un único vocabulario de condiciones y un único conjunto de acciones: una regla simplemente declara a qué tipos de registro se aplica.

Se aplica a

scope.record_types determina para qué se activa una regla.
Si lo omites, la regla se aplica solo a transacciones. Toda regla escrita antes de que existieran los eventos se comporta exactamente igual que antes, y una regla nunca empieza a coincidir con inicios de sesión porque su alcance estuviera vacío.
En la consola, esto es el selector Se aplica a del paso de disparador de una regla. Al elegir Eventos aparece una lista de casillas Categorías de eventos que acota aún más la regla; deja todas sin marcar para evaluar todas las categorías.
"__current__" significa “el mismo valor que el del evento que se está evaluando”: así es como una regla expresa por sujeto, por dispositivo o por ronda sin nombrar ninguno.

Campos de evento

Las condiciones leen rutas con espacio de nombres. El vocabulario de transacciones que ya conoces (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>) también se resuelve en un evento. Las señales del sujeto se almacenan en caché en el usuario monitorizado y no se recalculan en cada evento, de modo que una regla puede leerlas a velocidad de ingesta.

Agregaciones

Velocidad

Los reductores que ya usas en las transacciones (count, sum, avg, min, max, distinct_count) sobre una ventana móvil window (30m, 24h, 7d, 30d).

Ratio

Dos reductores sobre la misma ventana. Así se expresan las ratios de apuesta frente a depósito, retirada frente a depósito, bono frente a depósito y las tasas de contracargos.
Deposita 1,000, apuesta 20, solicita una retirada, y la ratio es 0.02: el clásico blanqueo mediante juego mínimo.
Una ratio sin denominador nunca coincide. No tener depósitos no es una ratio de cero, es ausencia de evidencia, y que la regla se active en ese caso marcaría a todos los usuarios recién creados.

Secuencia

Predicados ordenados dentro de una ventana. Cada paso se ajusta a action_type, event_category o a un filtro match arbitrario, y puede exigir min_count ocurrencias antes de que la secuencia avance.
Relleno de credenciales (credential stuffing), luego la toma de control del MFA, luego la redirección del pago y luego el vaciado de la cuenta. La regla se dispara con el evento que completa la cadena, y la evidencia coincidente enumera los ids de evento de cada paso. El estado de la secuencia se guarda por regla y sujeto, de modo que avanza a medida que llegan los eventos en lugar de volver a recorrer la línea de tiempo. El progreso anterior a la ventana se descarta en lugar de contabilizarse.

Correlación

Una unión entre sujetos: aplica un reductor a todos los eventos que comparten el grupo de este evento.
"pair": true trata los dos extremos como un conjunto no ordenado, de modo que A→B y B→A caen en el mismo grupo, y eso es lo que permite que una sola regla vea las dos mitades de una colusión. El chip dumping, las apuestas opuestas y la autorreferencia de afiliados tienen todos esta forma. Añade siempre filters que delimiten una regla de correlación. Sin ellos, considera todos los eventos de la ventana.

Reglas en tiempo real y asíncronas

Algunas reglas pueden responder dentro de la solicitud de ingesta y otras no. Un evento cuyas reglas siguen pendientes se devuelve con "correlation_pending": true. Su estado y su puntuación se actualizan en el propio evento cuando termina la pasada asíncrona; volver a ejecutarla es idempotente, así que una regla nunca aplica su puntuación dos veces. Esta separación es intencionada: una consulta de red entre sujetos no debe hacer esperar a un inicio de sesión.

Acciones

El mismo vocabulario de acciones que las reglas de transacciones: add_score, change_status, add_tags, add_note, add_to_list, open_case. Dos diferencias en los eventos:
  • change_status a AWAITING_USER es un resultado exclusivo de las transacciones (no existe un flujo de subsanación para eventos) y se aplica como IN_REVIEW.
  • open_case vincula el caso al sujeto en lugar de a una transacción, y registra en el caso el ID del evento coincidente.

Evidencia

Cada coincidencia almacena lo que observó: la ventana de agregación, el valor calculado, el valor esperado, ID de eventos muestreados y el origen de cada campo coincidente. Así, un analista puede distinguir una IP registrada por el servidor de un indicio proporcionado por el cliente antes de tomar medidas respecto de una coincidencia. La consola muestra el origen junto a cada campo coincidente en el panel lateral del evento.

Ejemplos prácticos

Depósito, juego simbólico, retiro rápido. Condición event.action_type eq withdrawal_requested, más la proporción entre apuestas y depósitos indicada anteriormente, con lte 0.1 durante 24h.
Proporción de count(chargeback_opened) respecto a count(deposit_completed) por sujeto durante 30d, gte 0.5. Agrupa por event.payment.payment_fingerprint en lugar de por sujeto para detectar un mismo instrumento en varias cuentas.
La secuencia ato_drain indicada arriba, con add_score 90 y change_status DECLINED.
La correlación de pares indicada arriba. Eleva value al importe que sea relevante para tus mesas y añade event.gameplay.game_id a group_by para mantener las partidas separadas.
Condiciones: event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 y event.device.bot_score gte 90, con add_tags. Combínalas con un distinct_count de event.device.fingerprint por IP para encontrar una granja en lugar de un único script.
Condición: event.action_type eq self_exclusion_match y event.payload.re_registration_attempt eq true, con escalado mediante open_case.

Siguientes pasos

Ingesta de eventos

La envoltura, las diez categorías y el contrato de lotes.

API de reglas

Crea, actualiza y prueba reglas con datos históricos de forma programática.
Última modificación el 1 de noviembre de 2026