Antifrod moteurs : signaux, scoring, règles

1) Le défi de l'antifrod et les clés KPI

L'objectif est de minimiser les pertes de frod avec un maximum de joueurs de bonne foi et un faible retard de décision. Métriques de niveau supérieur :

Taux de fraud (par dépôts/gains/chargbacks), taux de chargeback, taux de bonus.
Approval rate/FPR (faux taux positif), Precision/Recall, AUC/PR-AUC pour les modèles.
Solutions de latitude (p95/p99, budget réel cible : 50-150 ms), Cost savings vs baseline.
Manual review rate et SLA sur l'analyse de cas.

2) Architecture en temps réel

Convoyeur type :

1. Collecte d'événements : dépôt, retrait, enregistrement, login, mise, modification des détails, création de ticket, utilisation de codes promotionnels.

2. Enrichissement : statuts KYC/AML, fiches comportementales, géo/device, communication graphique, risque de profil du fournisseur de paiement.

3. Temps réel : bus d'événements (Kafka/PubSub), boutique de fonctionnalités avec fenêtres 5 min/1 heure/24 heures, service de scoring (modèle en ligne + règles).

4. Actions : allow/deny/challenge (3DS/SCA, dop. KYC), limitation, bloc promo, inspection manuelle.

5. Fidbek-loup : chargbacks, mallettes confirmées, appels → marquage → rééducation.

6. Surveillance : dashboards et alertes par métriques, dérive de données, fenêtres « silencieuses » et éclats.

3) Signaux (caractéristiques) de premier ordre

Identification et environnement :

Device fingerprint (WebGL/Canvas, User-Agent stabilité, polices), réputation IP (VPN/hébergement), ASN, proxy.
Comportement geo : rusynchron ip-geo vs payment BIN/adresse, changement de pays/fuseau horaire.
Biométrie comportementale : rythme des clics/scroll, vitesse et « tremblements » de la souris, rythme d'impression, mobile-gyro.
Modèles de bot : navigateurs headless, temporisations anormalement stables, répétitions de scénarios.

Finances et paiements :

BIN-fiches, émetteur, pays à risque, statut 3DS, retours par carte.
Velocity-fichi : n dépôts en 10 min/1 heure, montant par fenêtre, tentatives de paiement avec différentes cartes/portefeuilles.
Drapeaux crypto-rouges : dépôts de mixers/échanges à haut risque, communication graphique « cassée » UTXO.

Compte et sot-graphe :

Courrier fournisseur/âge du domaine, uniphamiles/mêmes adresses, correspondances téléphone/carte/appareils.
Multi-account/Cluster detection : devis/IP partagés, modèles d'enregistrement et d'entrée répétés.
Promo-abyuz : sursaut des inscriptions à une adresse/sous-réseau, bonus cash-out rapides, cycles « dépôt-minimum-pari-retrait ».

Comportement de jeu :

Velocity Session (temps avant le premier pari, intervalle moyen entre les paris), paris sans variabilité, jouer uniquement avec des bonus, arrêter l'activité immédiatement après le wagering.

4) Modèles de scoring : de la régression logistique au graphe ML

Les approches sont combinées :

Gradient boosting/régression logistique pour les modèles interprétés et rapides dans la vente.
Modèle de séquence (GBDT sur les unités à fenêtres temporelles, LightGBM/CatBoost ; moins souvent - LSTM/Transformer sur les événements).
Modèle graphique (Node2Vec/GraphSAGE) pour identifier les grappes de multiaccount.
Ensembles et risk-score : on range la score 0.. 100. Le seuil A est auto-allow, B est challenge/KYC, C est deny.

Exemple de scoring simple (pseudo-code) :


risk = 0 if ip_is_hosting: risk += 25 if device_reused_over_5_accounts_24h: risk += 30 if deposit_velocity_1h > 3: risk += 20 if email_domain_new or temp: risk += 10 if chargeback_history: risk += 40 score = min(100, risk)
decision = "ALLOW" if score < 30 else "CHALLENGE" if score < 60 else "DENY"

5) Règles : Pourquoi ils s'il y a ML

Les règles sont nécessaires pour :

Réactions rapides aux nouveaux schémas (modèle zero-day).
Cas juridiquement transparents (audit/justification).
Des politiques subtiles (exceptions régionales, niveaux VIP, spécificité du fournisseur).

Règlement type :

Velocity: `count(deposits, 10m) ≥ 3` и `distinct_cards_24h ≥ 2` → CHALLENGE.
Geo-mismatch: BIN_country ≠ IP_country и нет 3DS → DENY.
Device rouse : 'device _ hash' rencontré sur ≥ N comptes pour 72 h → BAN/REVIEW.
Promo : nouveau compte + bonus + pari au minimum + tentative de retrait instantané → HOLD + vérification.
Crypto : Entrez UTXO à partir de clusters à risque élevé → HOLD à KUS/source de fonds.

Gestion des règles : arbre de décision/tables de décision (Decision Table), priorités, conflits, « mode shadow » avant d'être activé. Logi : quelle branche a fonctionné, quelles fiches décisives.

6) Équilibre entre risque et conversion

Risk-based authentication: SCA/3DS/доп. KYC - seulement sur les bandes de rochers limites.

Whitelist/graylist/blacklist au niveau BIN, fournisseurs, partenaires, VIP.

A/B politiques tests : comparaison des seuils, coût de l'erreur vs revenus, rétention.

Explainability : SHAP/feature importance sur la vente pour les appels et la formation de Sapport.

7) Analyse graphique et multi-account

Nœuds : comptes, appareils, cartes, téléphones, IP. Röbra : « utilisé », « lié ».

Métriques : triads/clics, composants de connectivité, centralité.

Règles sur la colonne : Si dans le composant> k nouveaux comptes en 24 heures avec le même périphérique fingerprint → bloc promo, limites de sortie, vérification manuelle des nœuds clés.

8) Pro promo-frod/bonus-abyse

Signaux :

Enregistrements en série avec le même type d'adresse, courrier unique.
Exécute rapidement le minimum de wagering et essaie de le mettre à zéro.
Coordination via les mêmes devis/IP/renvois.
Mitiger : limites sur les bonus par device et les détails de paiement, KYC au premier retrait, conditions personnalisées de wagering, velocity-cap par promo.

9) Processus et gestion de cas

Queu....& Priorisation : Hiérarchisation des cas selon la somme des risques/pertes.

Playbooks pour les analystes : checklists, quelles preuves collecter (captures d'écran des transactions, relevés, explications).

SLA : solution auto ≤ 150 ms, cas manuels p95 ≤ 24 h ; escalade à haute valeur ≤ 2 h.

Recours : trace de la décision, hiérarchie de la révision, rétrospective des flags erronés.

10) Données et qualité

Feature store : fenêtres en ligne (5 min, 1 h, 24 h) + unités hors ligne.

Data quality: completeness, freshness, drift. Alert, quand la part de null/fallback augmente.

Versioning : diagrammes d'événements, versions de modèles et ensemble de règles, « replay » sur l'historique.

11) Suivi des modèles et dérive

Data drift/concept drift : tests PSI/KS, contrôle de la saisonnalité (soirées/week-end/sorties promotionnelles).

Surveillance en ligne : étalonnage du scoring (Brier score), stabilité des seuils.

Shadow/Champion-Challenger : mettre de nouveaux modèles à l'ombre, comparer par raccourcis hors ligne/chargbacks tardifs.

12) Conformité et exigences réglementaires

KYC/AML : listes de sanctions, PEP, sources de fonds ; seuils de vérification manuelle.

GDPR/données : minimisation, limitation de la purpose, exploitabilité des solutions.

PCI DSS (cartes), SCA/PSD2 (UE), exigences MGA/UKGC/Curacao, etc.

Audit : logiques de décision immuables, qui/quand a changé la règle ou le modèle.

13) Profils de risque et actions

Exemple de stratégie d'action :

Score <30 → ALLOW, sans frottement.
30-59 → CHALLENGE : SCA/3DS, KYC sélectif (selfie + doc), limite de montant/vitesse.
60-79 → HOLD : gel du retrait, demande de source de fonds, examen manuel.
≥ 80 → DENY/BAN : bloc promo/retrait, fermeture du compte lors de la confirmation.

14) Performance et fiabilité

Budget de latitude : les fiches légères en ligne, les fiches lourdes dans les caches/fenêtres lues.

Fail-safe : dégradation vers les règles de base en cas d'échec du modèle/fich store ; Timaoutes et circuit breaker.

HA : plusieurs instances du service de scoring, steless, blue-green deploy, sorties canaries.

Taux-limites sur les actions critiques (enregistrement, changement de détails, conclusions).

15) Exemple de l'événement et de la réponse du moteur

Entrée (abrégée) :

json
{
"event": "withdraw_request",  "user_id": "u_92871",  "amount": 1200. 00,  "currency": "EUR",  "ip": "185. 12. 34. 56",  "device_hash": "d:1a2b3c",  "bin_country": "GB",  "ip_country": "DE",  "kyc_status": "BASIC",  "velocity_withdraw_24h": 3,  "bonus_active": true,  "wagering_progress": 22
}

Réponse de l'antifrode :

json
{
"decision": "HOLD",  "score": 68,  "reasons": ["Geo_mismatch", "Withdraw_velocity_high", "Active_bonus_low_wagering"],  "actions": ["Request_KYC_Level2", "Freeze_withdrawal_48h", "Notify_analyst_queue_high"]
}

16) Mise en œuvre : un plan progressif

1. Découverte : inventaire des événements, sources, SLA.

2. MVP : règles de base + modèle simple, latitude ≤ 150 ms.

3. Couche graphique : clustering multi-account, sanctions sur les promos.

4. Biométrie comportementale : réduction des bots/scripts.

5. Optimisation de la conversion : authentification fondée sur le risque, seuils.

6. Opération : gestion de cas, alertes, rapports pour le régulateur.

7. Amélioration continue : shadow-start, retrain toutes les N semaines, post-mortem.

17) Chèque-liste des mesures pratiques

Une seule fonctionnalité avec des fenêtres et des mises à jour SLA.
Protocole d'explication des décisions (journal des causes, cartes SHAP).
Table de décision avec priorités, tests de conflit.
Taux limites et politiques de retrait/promo.
Les vérifications des graphes multi-account avant l'attribution des bonus.
Cadre A/B pour les seuils et les politiques.
Mode fail-safe sans modèle et sans intégrations externes.
Rétrospectives régulières de cas faux positifs/faux négatifs.

Résumé

Un puissant moteur antifrod n'est pas une « paire de règles », mais une boucle vivante de signaux, de scores et de politiques contrôlées qui fonctionne rapidement, de manière compréhensible et adaptative. Combinez le scoring ML avec des règles claires, l'analyse graphique et l'authentification fondée sur le risque - et vous réduirez les pertes de frondes sans frottement excessif pour les joueurs honnêtes.