Passer au contenu principal
Les événements sont évalués par le même moteur que les transactions. Il n’existe qu’un seul modèle de règle, un seul vocabulaire de conditions et un seul jeu d’actions : une règle indique simplement les types d’enregistrements auxquels elle s’applique.

S’applique à

scope.record_types détermine sur quoi une règle se déclenche.
Laisser ce champ absent maintient une règle limitée aux transactions. Toutes les règles écrites avant l’existence des événements se comportent exactement comme auparavant, et une règle ne commence jamais à correspondre aux connexions parce que son périmètre était vide.
Dans la console, ceci correspond au sélecteur S’applique à de l’étape Déclencheur d’une règle. Choisir Événements affiche une liste de contrôle Catégories d’événements qui restreint davantage la règle ; laissez-la entièrement décochée pour évaluer toutes les catégories.
"__current__" signifie « la même valeur que l’événement évalué ». C’est ainsi qu’une règle exprime par sujet, par appareil ou par manche sans en nommer un. Les enregistrements sans la valeur de regroupement ne sont jamais regroupés ensemble. Un événement sans empreinte d’appareil n’est pas « le même appareil » que d’autres événements qui n’en ont pas, et un événement qui n’indique aucun sujet n’est pas « le même sujet » que d’autres événements anonymes : lorsque l’événement évalué n’a pas de valeur pour un champ "__current__", cette agrégation ne correspond pas, quel que soit son opérateur.

Champs d’événement

Les conditions lisent des chemins avec espaces de noms. Le vocabulaire des transactions que vous connaissez déjà (action_type, subject_vendor_data, subject_ip_country, custom_values.<key>) se résout aussi sur un événement. Les signaux du sujet sont mis en cache sur l’utilisateur surveillé, et non recalculés à chaque événement, si bien qu’une règle peut les lire à la vitesse de l’ingestion.

Agrégations

Vélocité

Les réducteurs que vous utilisez déjà sur les transactions (count, sum, avg, min, max, distinct_count) s’appliquent sur une window glissante (30m, 24h, 7d, 30d).

Ratio

Deux réducteurs sur la même fenêtre. C’est ainsi qu’on exprime les taux de mise sur dépôt, de retrait sur dépôt, de bonus sur dépôt et de rétrofacturation.
Dépôt de 1 000, mise de 20, demande de retrait : le ratio vaut 0,02. C’est un blanchiment classique par jeu minimal.
Un ratio sans dénominateur ne correspond jamais. L’absence de dépôt n’est pas un ratio de zéro : c’est une absence de preuve, et déclencher la règle dans ce cas signalerait chaque nouvel utilisateur.

Séquence

Prédicats ordonnés à l’intérieur d’une fenêtre. Chaque étape correspond à un action_type, à une event_category ou à un filtre match arbitraire, et peut exiger des occurrences min_count avant que la séquence n’avance.
Bourrage d’identifiants, puis prise de contrôle MFA, puis redirection du versement, puis vidage du compte. La règle se déclenche sur l’événement qui complète la chaîne, et les preuves correspondantes listent les identifiants d’événement de chaque étape. L’état de séquence est conservé par règle et par sujet : il progresse à mesure que les événements arrivent, au lieu de réanalyser la chronologie. La progression antérieure à la fenêtre est écartée plutôt que comptée.

Corrélation

Une jointure inter-sujets : effectuer une réduction sur tous les événements qui partagent le groupe de cet événement.
"pair": true fait correspondre les deux extrémités comme un ensemble non ordonné, de sorte que A→B et B→A tombent dans le même groupe. Cela permet à une seule règle de voir les deux moitiés d’une collusion. Le dumping de jetons, les paris opposés et l’auto-parrainage d’affilié ont tous cette forme. Donnez toujours à une règle de corrélation des filters qui la restreignent. Sans eux, elle considère chaque événement de la fenêtre.

Temps réel et règles asynchrones

Certaines règles peuvent répondre dans la requête d’ingestion, d’autres non. Un événement dont les règles sont encore en attente est renvoyé avec "correlation_pending": true. Son statut et son score sont mis à jour sur place dès que la passe asynchrone se termine. La relance est idempotente : une règle n’applique jamais son score deux fois. Cette séparation est volontaire : une requête visant un réseau de fraude portant sur plusieurs sujets ne doit pas faire attendre une connexion.

Actions

Le même vocabulaire d’actions que pour les règles de transaction : add_score, change_status, add_tags, add_note, add_to_list, open_case. Deux différences s’appliquent aux événements :
  • change_status vers AWAITING_USER est un résultat propre aux transactions (il n’existe pas de flux de remédiation pour les événements) et il est appliqué sous la forme IN_REVIEW.
  • open_case rattache le dossier au sujet plutôt qu’à une transaction, et enregistre l’identifiant de l’événement correspondant sur le dossier.

Preuves

Chaque correspondance conserve ce qu’elle a observé : la fenêtre d’agrégation, la valeur calculée, la valeur attendue, les identifiants d’événements échantillonnés et la source de chaque champ concerné. Un analyste peut ainsi distinguer une IP fournie par le serveur d’une indication fournie par le client avant d’agir sur une correspondance. La console affiche la source à côté de chaque champ concerné, dans le panneau de détail de l’événement.

Exemples détaillés

Dépôt, jeu avec des jetons, retrait rapide. Condition event.action_type eq withdrawal_requested, plus un ratio mise/dépôt avec lte 0.1 sur 24h.
Ratio de count(chargeback_opened) sur count(deposit_completed) par sujet sur 30d, gte 0.5. Regroupez par event.payment.payment_fingerprint au lieu du sujet pour repérer un même moyen de paiement utilisé sur plusieurs comptes.
La séquence ato_drain décrite ci-dessus, avec add_score 90 et change_status DECLINED.
La corrélation de paires décrite ci-dessus. Augmentez value jusqu’au montant significatif pour vos tables, et ajoutez event.gameplay.game_id à group_by pour séparer les parties.
Conditions sur event.action_type eq bot_signal_observed, event.bot.timing_variance_ms lte 10 et event.device.bot_score gte 90, avec add_tags. Combinez avec un distinct_count de event.device.fingerprint par IP pour repérer une ferme plutôt qu’un seul script.
Condition sur event.action_type eq self_exclusion_match et event.payload.re_registration_attempt eq true, avec escalade via open_case.

Suite

Ingestion d'événements

L’enveloppe, les dix catégories et le contrat de lot.

API des règles

Créez, mettez à jour et effectuez des tests rétrospectifs sur les règles par programmation.
Dernière modification le 7 novembre 2026