VASP « Modèle de paiement : » DAXCHAIN + ChainValley en tant que bénéficiaires fiat derrière les dépôts de casino offshore !

Les revues Rail Atlas de FinTelegram sur les casinos offshore liés à Stellar montrent un schéma de paiements répétitif : les joueurs sont acheminés via des rails « open banking » et de portefeuilles qui ne paient pas directement le casino, mais paient plutôt des intermédiaires enregistrés VASP—notamment DAXCHAIN (Estonie) et ChainValley (Pologne)—qui semblent fonctionner comme des points de collecte fiat. Il ne s'agit pas d'un cas isolé. Cela ressemble à un modèle opérationnel évolutif conçu pour maintenir le casino hors de la ligne de mire des paiements.

Points clés

• Plusieurs marques de casinos attribuées à Stellar montrent une répétition « de type modèle » dans l'UX et l'architecture de paiement, cohérente avec les résultats Stellar/Legiano antérieurs de FinTelegram.
• Le régulateur italien bloque au moins certains domaines associés (y compris les variantes AllySpin et Supabet), tandis que les opérateurs alternent entre des « mutations » de domaines, diluant l'application au niveau DNS.
• Les flux open-banking acheminent les utilisateurs à travers des cascades de passerelles (selon votre revue) aboutissant à des bénéficiaires tels que DAXCHAIN OÜ (www.daxchain.eu), dont la posture publique est une activité VASP/monnaie virtuelle—et non une activité d'établissement de paiement licenciée.
• Les données du registre de DAXCHAIN présentent Olegs Bogdanovics comme bénéficiaire effectif. Sa licence de monnaie virtuelle soulève la question évidente : pourquoi un VASP est-il le bénéficiaire de « dépôts bancaires » vers des casinos offshore ?
• ChainValley reste un nœud récurrent : FinTelegram a documenté des dépôts « fake-fiat » où les financements Skrill/Neteller sont convertis en USDC/USDC.e et transmis aux portefeuilles de casino—présentés au joueur comme s'il s'agissait d'un « dépôt » normal.

Lisez nos rapports ChainValley ici.

Récit bref

Nos dernières revues de casinos (WinBay, AllySpin, LuckyMax, Spinbara, Supabet) renforcent ce que les enquêtes Legiano/Stellar suggéraient déjà : les groupes de casinos offshore industrialisent les « rails de dépôt » de la même manière qu'ils industrialisent la rotation de domaines.

La partie frappante n'est pas seulement que l'open-banking soit proposé—c'est qui reçoit l'argent. Au lieu de payer un opérateur de jeux clairement identifié et licencié, les flux se terminent chez des intermédiaires comme DAXCHAIN (Estonie) et ChainValley (Pologne). D'un point de vue conformité, c'est un signal d'alarme clignotant : la couche « marchand de référence » est conçue de manière à ce que le casino soit à un pas de l'événement de paiement.

Analyse étendue : Le problème réglementaire n'est pas « Open Banking » — c'est la conception du bénéficiaire

1) PSD2 ne disparaît pas parce que l'interface dit « crypto » ou « open banking »

En vertu de PSD2 (Directive (UE) 2015/2366), les services de paiement dans l'UE sont une activité réglementée, et l'autorisation/enregistrement est suivi par les autorités nationales compétentes et consolidé dans des registres au niveau de l'UE.

Si une entité agit fonctionnellement comme un agent de collecte fiat (recevant des virements bancaires de consommateurs qui financent une relation de casino offshore), les questions naturelles sont :

• Est-elle autorisée/enregistrée comme établissement de paiement ou établissement de monnaie électronique pour cette activité ?
• Si non, quelle est la qualification juridique du « paiement » que le consommateur pense effectuer ?

C'est exactement là que l'architecture « fake-fiat » devient utile aux opérateurs : si le paiement peut être cadré en interne comme un achat de crypto (même si l'expérience utilisateur suggère un dépôt de casino), l'intermédiaire tente de sortir de la catégorie agent de paiement PSD2 et d'entrer dans la catégorie VASP.

2) DAXCHAIN : Licencié pour l'activité de monnaie virtuelle, mais positionné comme bénéficiaire Fiat

Les sources publiques indiquent que DAXCHAIN détient une autorisation de service de monnaie virtuelle FIU estonienne (listée avec le numéro de licence FVT000045 dans les communications FIU).
Séparément, le registre des entreprises estonier divulgue les informations de propriété/contrôle de la société (y compris le nom du bénéficiaire effectif dans la vue du registre).

Rien de tout cela, en apparence, ne répond à la question PSD2 : pourquoi un VASP est-il le destinataire nommé dans un flux de « dépôt » par virement bancaire qui finance finalement une activité de jeux offshore ? Si le véritable objectif commercial est le jeu, acheminer du fiat vers un bénéficiaire VASP ressemble moins à de l'innovation et plus à un contournement de périmètre.

3) ChainValley : Le hub de conversion « Fake-Fiat » répétable

Le registre d'activité de monnaie virtuelle polonais liste ChainValley, mais les autorités polonaises ont été explicites que l'entrée dans le registre d'activité VASP n'équivaut pas à une licence de services financiers/approbation de supervision au sens de PSD2.

Le reportage Legiano/Stellar de FinTelegram a déjà documenté comment ces flux peuvent être structurés : « dépôt » → achat crypto intégré (USDC/USDC.e) → transfert automatique vers le portefeuille du casino, financé via les rails Skrill/Neteller—laissant les consommateurs avec un levier de litige/rétrofacturation plus faible parce qu'ils ont techniquement « reçu la crypto qu'ils ont commandée ».

Dans notre nouvel ensemble Stellar, ChainValley apparaît à nouveau—associé à des marques de paiement grand public classiques (Skrill/Neteller/PaysafeCard) qui n'ont jamais été conçues pour être des alimentateurs silencieux vers des transferts de stablecoin de casinos offshore.

Lisez nos rapports Stellar ici.

4) La question Visa/Tink : quand l'open banking devient un rail de jeu

Nous avons trouvé une cascade qui inclut Tink dans le parcours de confirmation open-banking. Visa a confirmé publiquement son acquisition de Tink et la positionne comme une plateforme de paiements/données pour initier des paiements et déplacer de l'argent via des API.

Cela crée une question de conformité inconfortable mais nécessaire pour l'écosystème :

• Si une pile open-banking réglementée initie des paiements vers des bénéficiaires VASP qui sont ensuite utilisés pour financer des casinos offshore non licenciés, quel filtrage marchand/catégorie est réellement appliqué ?
• Ces paiements sont-ils traités comme des « achats crypto » (et donc autorisés), même lorsque l'objectif commercial en aval est le jeu ?
• Si oui, s'agit-il d'une défaillance de contrôle—ou d'un modèle commercial ?

Informations exploitables : questions de conformité nécessitant des réponses

1. Pour DAXCHAIN / ChainValley : Quel est le produit contractuel exact ici—dépôt de casino, facilitation de paiement, ou achat crypto/rampe d'accès ? S'il s'agit d'« achat crypto », pourquoi l'UX est-elle présentée comme une méthode de financement de casino ?
2. Pour les intermédiaires open-banking (y compris les participants à la pile Tink) : Quelle diligence renforcée est effectuée lorsque le bénéficiaire est un VASP observé de manière répétée dans les flux de dépôt de jeux offshore ?
3. Pour les rails de portefeuille électronique (modèle MiFinity) : Pourquoi des bénéficiaires comme CANAMONEY EXCHANGE LTD / CenturaPay continuent-ils d'apparaître dans les flux de caisse de casinos offshore—quels contrôles de surveillance des marchands empêchent réellement l'exposition répétée ?
4. Pour les régulateurs & FIU : Les enregistrements VASP sont-ils utilisés comme porte dérobée pour gérer des services d'agent de paiement de facto pour des marchands à haut risque (jeux illégaux, trading parallèle) ? Si oui, où se situe la ligne d'application ?

Appel à l'information

Si vous disposez de documentation interne, d'enregistrements d'intégration de marchands, de données bénéficiaire/descripteur, de détails de compte de règlement, de clusters de portefeuilles, ou de preuves montrant comment DAXCHAIN et ChainValley catégorisent ces « dépôts » (financement de casino vs. achat crypto), partagez-les en toute sécurité via Whistle42. Nous sommes particulièrement intéressés par : (i) les identités de marchand de référence ; (ii) les récits de transactions utilisés pour la conformité bancaire ; (iii) les résultats de rétrofacturation/réclamations ; (iv) la logique de commutation de passerelle entre les points de terminaison de passerelle de paiement ; et (v) toute correspondance avec les régulateurs.