Comment fonctionne le système de surveillance des transactions

Le Système de surveillance des transactions (SGT) surveille les dépôts, les conclusions, les transferts et les événements connexes afin de détecter à temps les risques de LMA, les anomalies financières et les anomalies opérationnelles. Dans iGaming, c'est le noyau de la protection de l'argent : à l'entrée, les données de paiement et de comportement, à la sortie, les alertes classées, les mallettes d'enquête et les rapports réglementaires.

1) Flux de données : exactement ce que nous collectons

Paiements et décaissements : 'autorisé/capturé/remboursé/chargeback', montants, monnaie, méthode, banque/PSP, commissions.

Portefeuille : 'wallet. debit/credit ', balances, annulations, idempotence (' txn _ id ',' Idempotency-Key ').

Signaux KYC/AML : âge/adresse, liveness, sanctions/RER, adverse media, SoF/SoW (sous EDD).

Comportement : fréquence des séances, « poursuite », vitesse des paris, activité nocturne.

Réseau et périphérique : device fingerprint, IP/ASN, proxy/VPN, géo-dérive.

Communications : cartes/portefeuilles/appareils partagés, graphes de référence.

Webhooks des fournisseurs : signés HMAC, avec anti-replay (« timestamp », nonce).

💡 Tous les événements passent par le bus (Kafka/PubSub) et reçoivent des clés de bout en bout : 'trace _ id', 'txn _ id', 'player _ ref'.

2) Architecture TMS (niveaux)

1. Ingest et normalisation : amener les statuts PSP au régime général, déduplication, validation des monnaies/montants.

2. Feature Store : signes en ligne/hors ligne (velocity, stabilité géographique, histoire chargeback, liens graphiques).

3. Règles et modèles : seuils déterministes + ML/anomalies + détecteurs graphiques.

4. Scoring et orchestration de solutions : un seul risque-score, une politique d'action (sauter/limiter/hold/EDD/bloc).

5. Alerting et gestion des cas : files d'attente, priorité, chèques, SLA.

6. Reporting et audit : dashboards, STR/SAR, archives WORM, exportation au régulateur.

3) Règles de premier niveau (détecteurs rapides)

Velocity : N dépôts/retraits en X minutes ; sursaut de remplacement/refund.

Géo/méthode : incohérence du pays de la carte et de la PI ; les PSP/portefeuilles rares.

Pass-through : dépôt important → activité minimale → retrait rapide.

Structuring : broyage des montants autour du seuil KYC/AML.

Déclencheurs comportementaux : multi-account par appareil/IP, pics nocturnes.

Chaque règle a une fenêtre, un seuil, une gravité et une action (soft-limit, hold, rummage manuel).

4) Modèles de deuxième niveau

Anomalies : Isolation Forest/auto-encodeur pour un modèle de transaction « non standard ».

Supervise : boosting/logreg en gradient sur une histoire marquée (chargeback/frod confirmé).

Graphe : link prediction/Node2Vec/GNN pour les syndicats, les détails généraux, les « mules ».

Calibrage coupe-off : équilibre TPR/FPR par objectifs commerciaux, stabilité sur la saisonnalité.

5) Scoring et prise de décision (decisioning)

Nous collectons le risque agrégé (0-1 ou Low/Med/High).

Politiques :

Low → sauter/limites douces ;
Med → step-up KYC/EDD, retard de sortie ;
Haut → hold/bloc et enquête immédiate.
Les combinaisons de signaux (haut score ML + drapeau graphique) donnent la priorité dans la file d'attente.

6) Gestion des cas et enquêtes

Montage automatique du contexte : paiements, KYC, IP/ASN, graphiques, historique de chargeback.

Checklists : ce que vous demandez au client (adresse/SoF), ce que vous vérifiez (koshelyok↔PSP) quand vous escaladez.

Résultat : cleared/limited/EDD/STR/SAR ; toutes les actions sont logées dans une archive WORM.

SLA : temps de réaction et de fermeture selon la gravité de la mallette, alerte « quand il brûle ».

7) STR/SAR et conformité

L'affaire avec des signes de blanchiment/financement du terrorisme est → formée par un rapport STR/SAR (faits, montants, liens entre les participants, temporisation).

Le calendrier et le format sont par juridiction ; tipping-off est interdit.

Les matériaux sont stockés dans un entrepôt immuable, l'accès est strictement par rôle.

8) Sécurité et vie privée dans le TMS

Cryptage : TLS 1. 2+/1. 3 « en route », AES-GCM « en stockage », clés dans KMS/HSM, rotation.

Pseudonyme : 'player _ ref' au lieu de PII ; communication avec PII - séparément, avec cryptage sur le terrain.

Accès : RBAC/ABAC, droits JIT sur les cas sensibles, audit en lecture/exportation.

Webhooks/externes : Signature HMAC, anti-replay, retraits idempotent.

9) Schéma de l'événement (exemple 'payment. captured`)

json
{
"event_id": "evt_9ab…",  "occurred_at": "2025-10-17T10:15:22. 512Z",  "trace_id": "trc_41c…",  "txn_id": "txn_dep_784…",  "player_ref": "plr_0f2…",  "method": "card",  "amount": 150. 00,  "currency": "EUR",  "psp": "acq_X",  "geo": {"ip":"203. 0. 113. 5","country":"DE","asn":"AS12345"},  "device": {"fp":"dfp_a18…","platform":"ios"},  "risk": {"velocity_5m":3,"asn_reputation":"medium"},  "integrity": {"signature":"base64:…"}
}

Des schémas similaires sont pour 'wallet. credit`, `payout. settled`, `kyc. verified`, `graph. linked`.

10) Métriques de qualité TMS

Precision/Recall, TPR/FPR par alertes et mallettes.

Alert-to-Case Ratio et TTR/MTR enquêtes.

Taux de SAR et cas confirmés par le régulateur.

Chargeback/Fraud-loss % et les filtres ROI.

Friction client : temps de sortie moyen, % des clients « nets » soumis à la vérification.

Stabilité : scoring latin, temporisation, disponibilité flow.

11) Tuning et contrôle de la dérive

Backtesting : essais de règles/modèles sur l'histoire, comparaison avec la référence.

Champion/Challenger : modèles parallèles en vente.

Dérive des données : tests PSI/KS, alertes lors du changement de mélange méthodes/géo.

Retrening : fenêtres régulières + marquage manuel « or » par la commande Complaens.

12) Fonctionnement : Observabilité et SLO

Dashboards : alertes/mallettes par heure, p95 latence de scoring, proportion de timeouts, queue d'enquête, taux de passe-through.

SLO : « scoring ≤150 ms p95 », « TTR High-Case ≤ 24 h », « budget erroné » sur le FPR.

Trace end-to-end ('trace _ id') - rapide drill-down du paiement à la cause première.

13) Erreurs typiques

Parier uniquement sur les règles ou, au contraire, uniquement sur ML. J'ai besoin d'une composition.

Pas d'idempotence d'argent. Des répétitions de webhook → des prises d'opérations et de fausses alertes.

Mauvaise normalisation des statuts PSP. Les états gris brisent le soudage.

L'absence d'analyse graphique. Les syndicats et les « fermes » restent invisibles.

Aucune rétroaction dans le modèle. Les erreurs ne se transforment pas en apprentissage - la qualité stagne.

Mélange de PII dans les événements. Violation de la minimisation et risques superflus du RGPD.

14) Checlist d'implémentation (enregistrer)

Bus d'événements unique, normalisation des statuts PSP
Clés de bout en bout : 'trace _ id', 'txn _ id', 'player _ ref'
Feature Store (en ligne/hors ligne) et catalogue de caractéristiques
Composition : Règles + anomalies + supervisées + graphe
Real-time scoring ≤150 ms + fallback-solutions
Gestion des cas : files d'attente, chèques, SLA, archives WORM
STR/SAR processus et modèles de rapport
Confidentialité/cryptage (TLS/KMS/HSM), RBAC/ABAC, accès JIT
Observabilité : Dashboards, traçage, alertes
Backtesting, Champion/Challenger, surveillance de la dérive
Chantier automobile koshelyok↔PSP, enquête sur les divergences
Documentation : Politiques, Pleybooks Sapport, Formation des analystes

15) Mini-FAQ

TMS = antifrode ? Les objectifs se chevauchent, mais les objectifs sont plus larges : AML/réglementation, STR/SAR, comptabilité.

Est-il possible de réduire le FPR sans perdre le TPR ? Oui : signaux graphiques et cascade de règles + ML, plus calibrage fin des seuils.

Pourquoi le temps réel est-il important ? Retards = « mauvaises » conclusions et pertes non remboursables.

Ai-je besoin de fournisseurs externes ? Souvent oui (sanctions/REER, KYC, réputation comportementale ASN/dispositifs).

Comment ne pas « étrangler » les joueurs honnêtes ? Mesures par étapes : limites douces → step-up KYC → hold seulement à haut risque.

Le système de surveillance des transactions est un convoyeur cohérent : événements normalisés, signes uniques, cascade de règles et de modèles, analyse graphique, scoring rapide et discipline d'enquête. Un tel TMS réduit simultanément les pertes, répond aux exigences du régulateur et maintient un bon UX « propre » aux joueurs.