Fraude à l’affiliation : faux joueurs et dépôts de 21-23 €

Ce cas de fraude à l’affiliation provient de deux lancements test en Espagne qui, selon les programmes concernés, ont attiré les mêmes joueurs simulés. Les dépôts se concentraient sur 21-23 €, tous par carte de crédit, généralement une à deux heures après l’inscription. Les données de paiement ont ensuite pointé vers des émulateurs, pas vers de vrais appareils. Les deux affiliés ont été exclus ; l’un d’eux a été averti qu’il ne serait pas payé.

En bref : les joueurs simulés ont laissé un faisceau de signaux, pas une preuve irréfutable unique, et la couche de paiement les a confirmés.

Les résultats en bref

Il n’y a pas de ligne ROI : c’est un cas de détection, pas un cas de profit.

Contexte

Des représentants de deux programmes d’affiliation et le CEO du produit de casino qu’ils promouvaient ont décrit le cas de façon anonyme dans un rapport sectoriel de février 2026. Les programmes, le produit et les affiliés ne sont pas nommés, et aucun des chiffres ne peut être vérifié de façon indépendante.

Tout commence avec les conditions du test. L’essai du programme X avec le produit était conçu pour aller vite : savoir rapidement si une nouvelle source ou un GEO Tier-1 mérite un deal. Sa faiblesse, c’était l’absence d’étalon. Au-delà de quelques règles de base (joueurs en Espagne, machines à sous, compte approvisionné et jeu réel), personne n’avait fixé d’objectif de rétention ni de valeur de dépôt, si bien que le programme n’avait rien d’écrit sur quoi s’appuyer pour refuser le trafic. C’est la même lacune que l’on retrouve dans les litiges de KPI entre affiliés et programmes.

Dans les deals CPA, le déclencheur du paiement est généralement un premier dépôt qualifiant (FTD), ce qui fait des faux FTD une cible naturelle de la fraude à l’affiliation dans l’iGaming. L’hypothèse de travail des programmes était que le trafic avait été conçu pour passer inaperçu lors des premiers contrôles de l’opérateur et pendant la période de rétention du paiement. La mesure publicitaire appelle ce même problème le trafic invalide : le Media Rating Council indique que le trafic peut être jugé invalide lorsqu’il provient de bots ou d’une activité conçue pour le produire.

Ce qu’ils ont fait

Le dispositif faisait tourner des joueurs simulés sur des appareils émulés et menait chaque faux compte jusqu’à l’inscription et un petit dépôt. Les programmes n’en ont vu que les traces laissées dans leurs données. Elles sont regroupées ci-dessous comme un analyste fraude les passerait en revue : ce qu’il faut vérifier, ce que cela a montré ici et pourquoi c’était anormal.

Signaux temporels

• Vitesse d’un lancement à froid. Le premier contrôle sur toute nouvelle source porte sur la vitesse à laquelle elle produit. Celle-ci, activée tard dans la soirée, a enregistré une vague d’inscriptions et ses premiers dépôts en une heure environ. Venant d’une source sans historique, ce rythme a été lu par les programmes comme un avertissement, pas comme une victoire.

• Rythme des inscriptions. Tracez les inscriptions minute par minute. Au lieu d’une courbe dispersée, le graphique montrait de hauts pics, chacun regroupant des dizaines de comptes créés presque au même instant. Les gens arrivent indépendamment les uns des autres ; des comptes qui arrivent ensemble suggèrent un déclencheur unique derrière eux, et c’est ainsi que les programmes l’ont interprété.

• Délai de dépôt. Mesurez l’écart entre l’inscription et le premier dépôt pour chaque compte. Sur l’ensemble de cette source, il restait d’une à deux heures en moyenne. D’après l’expérience des programmes, quelqu’un qui compte jouer alimente son compte tout de suite ou en quelques minutes ; une attente uniforme de plusieurs heures sur toute une source sortait donc du lot.

Signaux de paiement

• Moyens de dépôt. Ventilez les dépôts de la source par moyen de paiement. La ventilation n’avait qu’une ligne : cartes de crédit, 100 %. Une audience réelle remplit plusieurs lignes ; une source à un seul moyen de paiement était donc un signal d’alerte pour les programmes.

• Fourchette de montants. Représentez la taille des dépôts. Ils se concentraient entre 21 € et 23 €. Les vrais joueurs, d’après l’expérience des programmes, choisissent des montants irréguliers ; une fourchette aussi étroite ressemblait à une valeur prédéfinie plutôt qu’à un choix.

• La vie après le premier dépôt. Suivez chaque déposant dans les sessions suivantes. La piste s’arrêtait au paiement : un dépôt proche du minimum, quasiment aucun spin et aucune visite de retour. Dans un test réservé aux machines à sous qui exigeait de jouer, des comptes qui déposent puis se taisent semblent exister pour déclencher un FTD plutôt que pour jouer.

Signaux comportementaux

• Remplissage du formulaire. Comparez jusqu’où les comptes vont dans le formulaire d’inscription, champs facultatifs compris. Ici, chaque compte a rempli chacune des quatre à six étapes, sans aucune hésitation entre elles. Les vraies inscriptions laissent souvent des champs facultatifs vides ; un taux de remplissage de 100 % évoque donc davantage un script qu’une foule (observation des programmes).

• Bonus. Vérifiez si les nouveaux déposants ouvrent ou réclament l’offre de bonus. Aucun ne l’a fait. Pour une audience casino, cela ressemble davantage à un signal absent qu’à un signal discret.

• Click-to-reg. Comparez le click-to-reg avec le trafic réel passé. Il dépassait de loin tout ce que les équipes avaient vu ; le chiffre n’a pas été communiqué.

Le même schéma dans deux programmes

Le programme Y a lui aussi mené un test rapide en Espagne et constaté le même comportement. Sa cohorte correspondait à celle du programme X sur le parcours d’inscription, le timing des dépôts, les montants et le silence après le dépôt. Deux sources sans lien ne produisent normalement pas la même cohorte ; c’est cette correspondance qui a fait passer les programmes d’une plainte sur la qualité à une enquête pour fraude.

Les données des appareils ont tranché. Les systèmes de paiement enregistrent l’appareil et l’environnement d’où provient chaque dépôt ; l’équipe a donc vérifié de ce côté. Les dépôts remontaient à des environnements émulés, pas à des téléphones physiques ni à des navigateurs ordinaires. Ce constat a donné aux signaux de fraude publicitaire relevés plus tôt une seule cause technique.

Résultats

La réaction des programmes, telle qu’ils l’ont décrite :

• Trafic stoppé. Chez le programme X, le product manager a arrêté le flux et averti l’affilié qu’il ne serait pas payé. Dans un chat de travail, la consigne était de stopper tout le trafic et de ne pas lancer de nouveaux flux ; le manager du programme Y a ensuite confirmé la décision.

• Émulateurs bloqués. L’équipe technique du produit a ensuite limité l’accès depuis des émulateurs et, selon ce récit, les dépôts issus de ce trafic ont cessé de passer à partir de ce moment.

• Partenaires exclus. Les deux affiliés ont été exclus de leurs programmes. D’après ce qui a été rapporté, les programmes ont conclu qu’un même dispositif avait été acheminé par les deux, et non qu’un seul éditeur avait commis une erreur.

Comment la fraude a été détectée

L’ordre des preuves est la partie utile. Le tracker montrait le volume et un click-to-reg invraisemblable. Les données comportementales montraient les clusters : des rafales, un délai fixe, un seul moyen de paiement, une fourchette de montants plate. La couche de paiement a fourni la preuve technique. La détection a fonctionné parce que chaque couche a été recoupée avec la suivante, pas parce qu’un indicateur a franchi un seuil.

Les programmes n’ont publié ni tableaux de bord, ni comptages, ni montants : considérez donc ces seuils comme des illustrations, pas comme des benchmarks.

Le coût le plus lourd d’un échec de détection aurait été des données faussées, pas un seul paiement. Un produit qui aurait conservé ce trafic aurait compté des FTD provenant de comptes qui n’allaient jamais jouer, et ses chiffres d’activation, de bonus et de second dépôt auraient semblé cassés pour des raisons étrangères au produit.

Ce qui n’a pas marché

• La première hypothèse était fausse. Le programme X a d’abord soupçonné l’affilié d’envoyer du trafic crash games en violation des conditions réservées aux machines à sous. Cela aurait été une infraction aux conditions et non des joueurs simulés ; l’hypothèse sous-estimait donc ce qui se passait.

• Propre ligne par ligne. De petits dépôts similaires passent un contrôle ligne par ligne. L’uniformité n’apparaît que lorsqu’on regarde toute la source d’un coup.

• Un signal isolé induit en erreur. Des dépôts uniquement par carte ou un premier dépôt tardif peuvent chacun avoir une cause anodine. Le dossier a tenu parce que les signaux se regroupaient et se répétaient dans deux programmes.

• Le tracker ne pouvait pas trancher. La preuve est venue de données de paiement et d’appareil qu’un tracker d’affiliation ne voit pas.

Enseignements pour les affiliés : repérer la fraude à l’affiliation

Si vous gérez un programme ou un produit :

• Intégrez un étalon minimal à chaque test. Même un test sans KPI peut définir des déclencheurs de pause : une répartition des moyens de paiement, un ratio dépôt/jeu et une plage de délai avant le premier dépôt.

• Regardez les distributions, pas les moyennes. Tracez par source les montants des dépôts, les horodatages d’inscription et le délai avant dépôt. Les clusters serrés et les pics synchrones méritent un arrêt et une vérification, pas une célébration.

• Exploitez la couche paiement et appareil. Demandez à votre prestataire de paiement quelles données d’appareil il peut renvoyer. Si vous publiez une application Android native, la Play Integrity API de Google peut indiquer si une requête provient d’un appareil Android authentique et certifié, et un émulateur qui échoue à ses contrôles ne renvoie aucun verdict d’appareil.

Si vous achetez ou revendez du trafic :

• Auditez les sous-sources avant qu’elles n’atteignent un programme. La prévention de la fraude à l’affiliation commence en amont : une seule sous-source qui envoie des joueurs émulés peut vous coûter toute la relation, pas seulement un paiement.

• Écartez les autres types de fraude. Une qualité de conversion anormale peut aussi venir d’un vol d’attribution comme le cookie stuffing ; vérifiez donc les parcours de clic autant que les joueurs.

• Reliez les dépôts aux clics. Un suivi par postback propre permet aux deux parties de remonter rapidement d’un FTD signalé à sa source.

Questions fréquentes

Qu’est-ce que la fraude à l’affiliation dans l’iGaming ?

La fraude à l’affiliation désigne toute tentative de se faire payer pour des joueurs, des dépôts ou des clics qui ne sont pas authentiques. Dans les programmes de casino et de paris sportifs, elle prend notamment la forme de faux FTD, d’abus de bonus, de comptes en double et de trafic simulé comme dans le cas ci-dessus. Notre guide sur la fraude à l’affiliation dans l’iGaming couvre chaque type.

Comment détecter de faux joueurs ou des dépôts simulés ?

Pour repérer des dépôts simulés, cherchez des clusters : une fourchette de montants étroite, un délai fixe entre inscription et dépôt, un seul moyen de paiement sur toute une source, des inscriptions en rafales synchrones et des formulaires sans abandon. Confirmez ensuite avec les données d’appareil et de paiement, qui, dans ce cas, ont révélé des émulateurs. Ici, la détection de la fraude à l’affiliation reposait sur la concordance de plusieurs signaux.

Pourquoi les dépôts étaient-ils petits et uniformes ?

Les programmes ont vu dans ces montants étroits, proches du minimum, une limite prédéfinie censée paraître naturelle tout en gardant chaque dépôt bon marché. L’effet a été inverse : les vrais joueurs déposent des montants irréguliers, si bien qu’une fourchette constante de 21-23 € est devenue le signal le plus clair du dossier.

Qu’arrive-t-il à un affilié dont le trafic est signalé comme faux ?

Ici, le trafic a été stoppé et les deux affiliés ont été exclus de leurs programmes ; le premier a été averti qu’il ne serait pas payé. La possibilité pour un opérateur de retenir un paiement ou de mettre fin à un deal dépend de la clause anti-fraude des conditions que vous avez signées : lisez-la donc avant le début d’un test.

Sources

• Media Rating Council, update to the Invalid Traffic Detection and Filtration Standards, June 25, 2020

• Android Developers, Play Integrity API: integrity verdicts

• Case figures: anonymous account by two affiliate programs and the product's CEO, published in a February 2026 trade report. Single anonymous source, not independently verified; this article regroups and summarises it and adds no independent data.