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.
"__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.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 à unaction_type, à une event_category ou à un filtre match arbitraire, et peut exiger des occurrences min_count avant que la séquence n’avance.
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_statusversAWAITING_USERest 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 formeIN_REVIEW.open_caserattache 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
Blanchiment par jeu minimal
Blanchiment par jeu minimal
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.Fraude amicale
Fraude amicale
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.Siphonnage de compte par prise de contrôle
Siphonnage de compte par prise de contrôle
La séquence
ato_drain décrite ci-dessus, avec add_score 90 et change_status DECLINED.Dumping de jetons
Dumping de jetons
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.Jeu par bot et assistance en temps réel
Jeu par bot et assistance en temps réel
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.Contournement de l'auto-exclusion
Contournement de l'auto-exclusion
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.