Surveillance des transactions de jeu responsable pour l'iGaming (FR)

Les opérateurs d'iGaming ont deux obligations de surveillance qui vont dans des directions différentes. Les règles LCB vous demandent de surveiller le blanchiment — structuration, schémas de mule, contreparties sanctionnées. Les règles de jeu responsable vous demandent de surveiller les méfaits — un joueur déposant plus rapidement qu'il ne le devrait, augmentant ses propres limites pour courir après les pertes, ou étant exploité pour des bonus. La plupart des opérateurs gèrent ces deux aspects comme des programmes distincts avec des outils distincts, même si les deux lisent le même flux de transactions de joueurs.

L'API de surveillance des transactions de Didit exécute les deux dans un seul moteur. Le pack Jeu responsable détecte les pics de vitesse de dépôt, les changements de limites suspects et l'abus de bonus, en utilisant des catégories de transactions gambling_* dédiées — et il se trouve aux côtés des packs LCB/FT, détection d'anomalies et fraude dans le même produit, la même file d'attente d'alertes et le même flux de travail de cas. Chaque transaction est notée en temps réel à 0,02 $ par transaction.

Ce guide explique le pack Jeu responsable, les catégories de jeu qui l'alimentent et comment le configurer.

Points clés à retenir

• Le pack Jeu responsable détecte les pics de vitesse de dépôt, les changements de limites suspects et l'abus de bonus — des signaux de protection des joueurs, pas seulement de blanchiment.
• Des catégories gambling_* dédiées — gambling_bet, gambling_limit_change, gambling_bonus_change — permettent aux règles de s'appliquer dans le bon contexte.
• Le jeu responsable et la LCB fonctionnent dans un seul moteur, de sorte que les signaux de préjudice pour le joueur et de blanchiment partagent une file d'attente d'alertes et un flux de travail de cas.
• Les fenêtres de vélocité (nombre, somme, distinct) expriment les schémas de vitesse de dépôt et de changement de limite sans processeur de flux séparé.
• AWAITING_USER peut mettre en pause une transaction signalée pour une étape supplémentaire qui sert également de point de contact de protection du joueur.
• 0,02 $ par transaction, sans minimum. Le contrôle LCB sur une partie signalée est facturé séparément à 0,20 $.

Ce que fait le pack Jeu responsable

Le pack est un ensemble de règles sélectionnées et ajustées aux typologies de protection des joueurs plutôt qu'à celles de blanchiment. Il lit le flux de transactions du joueur — dépôts, paris, changements de limites, événements de bonus — et signale les schémas qui intéressent les régulateurs et les cadres de prévention des méfaits : un joueur déposant de manière répétée dans une courte période, un joueur augmentant sa limite de dépôt ou de perte immédiatement après une série de pertes, ou des comptes cyclant des bonus de manière à signaler un abus ou une exploitation organisée.

Chaque règle a les mêmes types d'action que le reste du moteur : ajouter au score de risque, changer le statut, étiqueter la transaction ou ajouter la partie à une liste. Ainsi, un pic de vitesse de dépôt peut faire passer un joueur en révision, joindre une note pour l'équipe de jeu responsable et — si votre politique le permet — mettre en pause le prochain dépôt avec AWAITING_USER afin que le joueur doive confirmer avant de continuer.

Pourquoi c'est important

Les régulateurs des jeux de hasard exigent de plus en plus des opérateurs qu'ils démontrent une surveillance active des méfaits, et pas seulement une conformité à la LCB. Les conditions de licence dans de nombreuses juridictions attendent des opérateurs qu'ils identifient les marqueurs de préjudice — courir après les pertes, l'escalade des dépôts, les changements de limites qui suppriment les protections — et qu'ils interviennent. Ne pas le faire représente un risque pour la licence, et pas seulement une amende.

Exécuter le jeu responsable comme un ajout à la surveillance LCB est inefficace, car les deux lisent les mêmes transactions. Un moteur unifié permet à une seule intégration de servir les deux obligations : le même dépôt qu'une règle LCB évalue pour la structuration, une règle de jeu responsable l'évalue pour la vélocité. Les signaux partagent une file d'attente, les analystes partagent un flux de travail, et la piste d'audit couvre les deux programmes à la fois — à un prix par transaction au lieu de deux contrats de fournisseur.

Détails techniques

Les transactions de jeu sont créées via l'API unifiée /v3/ avec une catégorie gambling_* afin que les bonnes règles s'appliquent :

curl -X POST https://verification.didit.me/v3/transactions/ \
  -H "x-api-key: $DIDIT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "transaction_id": "txn_g7a118",
    "category": "gambling_bet",
    "amount": 500,
    "currency": "EUR",
    "currency_kind": "fiat",
    "txn_date": "2026-05-21T20:05:00Z",
    "subject": { "vendor_data": "player_4471", "role": "SENDER", "entity_type": "INDIVIDUAL" },
    "payment_method": "CARD"
  }'

Un pic de vitesse de dépôt déclenche le pack Jeu responsable et renvoie un statut sur lequel l'opérateur peut agir :

{
  "transaction_id": "txn_g7a118",
  "status": "AWAITING_USER",
  "risk_score": 68,
  "triggered_rules": [
    {
      "name": "Vitesse de dépôt — nombre sur 24h",
      "bundle": "Jeu responsable",
      "aggregation": "count",
      "window": "24h",
      "action": "CHANGE_STATUS"
    }
  ],
  "alert_id": "alrt_e9c440"
}

Catégories de jeu. gambling_bet, gambling_limit_change et gambling_bonus_change permettent d'appliquer les règles en contexte — une règle de vélocité sur les dépôts, une règle de modèle sur les changements de limites, une règle d'abus sur les événements de bonus.

Vélocité et agrégation. Exprimez les schémas de vitesse de dépôt et de changement de limite avec des fenêtres de comptage, de somme et distinctes — « plus de 6 dépôts en 24 heures », « dépôts cumulés de plus de 2 000 € en 7 jours » — sans construire votre propre processeur de flux.

Webhooks. Abonnez-vous à transaction.created et transaction.status.updated pour maintenir votre plateforme synchronisée à mesure que les alertes sont résolues et que les mesures correctives sont terminées.

Prix. 0,02 $ par transaction, facturé par appel, sans minimum. Le contrôle LCB sur une partie signalée est facturé séparément à 0,20 $.

Élaborer des règles de protection des joueurs

• Vitesse de dépôt. Une fenêtre de count ou de sum sur les événements de dépôt adjacents à gambling_bet détecte un joueur déposant plus rapidement ou plus que ce que vos seuils de préjudice autorisent. Mettez en pause le prochain dépôt avec AWAITING_USER afin que le joueur confirme avant de continuer.
• Changements de limites. Une règle sur gambling_limit_change détecte un joueur augmentant une limite de dépôt ou de perte, surtout juste après une série de pertes — un marqueur classique de la poursuite des pertes. Transmettez-le à l'examen et informez l'équipe de jeu responsable.
• Abus de bonus. Une règle sur gambling_bonus_change, combinée à des comptes distincts, détecte le cyclage des bonus et l'exploitation organisée.
• LCB en parallèle. Les dépôts du même joueur sont soumis simultanément à la LCB/FT et à la détection d'anomalies, de sorte que les signaux de structuration ou de mule apparaissent dans la même file d'attente.

Tous ces éléments sont configurés dans la Business Console, et vous pouvez les étendre dans le pack personnalisé pour les marqueurs de préjudice spécifiques à l'opérateur.

Cas d'utilisation

• Casinos en ligne — les règles de vitesse de dépôt et de changement de limite signalent les comportements de poursuite des pertes et déclenchent une étape supplémentaire de protection du joueur.
• Paris sportifs — les fenêtres de vitesse de pari et de dépôt détectent l'escalade des mises au cours d'une session.
• Acquisition basée sur les bonus — les règles gambling_bonus_change avec des comptes distincts détectent l'exploitation des bonus.
• Plateformes à accès limité par l'âge — les étapes AWAITING_USER servent de point de contact de re-vérification lorsque des signaux de préjudice ou de fraude apparaissent.
• Opérateurs multi-juridictionnels — ajustez les seuils de préjudice par marché dans la Console tout en conservant un seul programme de surveillance.

Comment s'intégrer à Didit

1. Activez le pack. Dans la Business Console, activez le Jeu responsable en parallèle de la LCB/FT et de la détection d'anomalies, et ajustez les seuils de vitesse de dépôt, de changement de limite et de bonus à vos juridictions.
2. Envoyez les événements de jeu. POST /v3/transactions/ avec la bonne catégorie gambling_* lorsque les joueurs déposent, parient, changent de limites ou reçoivent des bonus — avec un transaction_id et un vendor_data stables liant chacun au joueur.
3. Agissez sur le statut. Approuvez, révisez, refusez ou mettez en pause avec AWAITING_USER pour insérer une étape de protection du joueur ou de re-vérification.
4. Synchronisez avec les webhooks. Écoutez transaction.status.updated pour réagir lorsqu'une alerte est résolue ou qu'une étape supplémentaire est terminée.

Parce que tout est sur l'API unifiée /v3/, un joueur intégré avec les flux KYC passe directement dans le même moteur qui exécute à la fois sa surveillance du jeu responsable et de la LCB — une plateforme d'identité et de fraude de bout en bout.

Questions fréquemment posées

Que détecte le pack Jeu responsable ?

Les pics de vitesse de dépôt, les changements de limites suspects et l'abus de bonus — des marqueurs de protection du joueur — en utilisant les catégories gambling_bet, gambling_limit_change et gambling_bonus_change.

Puis-je exécuter le jeu responsable et la LCB dans le même moteur ?

Oui. Les deux fonctionnent dans un seul moteur contre le même flux de transactions, partageant une file d'attente d'alertes et un flux de travail de cas, de sorte que vous remplissez les deux obligations à partir d'une seule intégration.

Comment signaler le comportement de poursuite des pertes ?

Utilisez une règle sur gambling_limit_change pour détecter les augmentations de limites (surtout après des pertes) et les fenêtres de vitesse de dépôt pour détecter l'escalade des dépôts. Transmettez-les à l'examen ou mettez-les en pause avec AWAITING_USER.

Puis-je mettre un joueur en pause plutôt que de le bloquer ?

Oui. Le statut AWAITING_USER met en pause une transaction signalée pour une étape supplémentaire — une confirmation, une re-vérification — qui reprend automatiquement une fois que le joueur l'a validée, servant de point de contact de protection du joueur.

Quel est le coût ?

0,02 $ par transaction, facturé par appel sans minimum. Le contrôle LCB sur une partie signalée est facturé séparément à 0,20 $.

Prêt à commencer ?

Lisez l'aperçu de la surveillance des transactions dans la documentation, voyez comment cela s'intègre au reste de la plateforme sur la page produit de la surveillance des transactions, et consultez les prix transparents par appel sur la page des prix. Quand vous êtes prêt, commencez gratuitement — 500 contrôles KYC gratuits chaque mois, et la surveillance des transactions à 0,02 $ par appel.