Auteur original : Maître Shao Jiadian
Ces deux dernières années, de plus en plus de clients posent des questions sur les paiements cryptographiques.
Il y a ceux qui font de la collecte de paiements pour le commerce électronique transfrontalier, ceux qui font des règlements en stablecoins, ceux qui font des cartes "U", ceux qui font de l'acquisition de marchands, ceux qui intègrent des paiements dans des portefeuilles Web3, et aussi des sociétés de paiement traditionnelles qui veulent progressivement connecter leurs activités de paiement et de collecte de devises fiduciaires existantes à des stablecoins, des comptes d'échange ou des réseaux de règlement sur chaîne.
La plupart des gens commencent par poser la même question :
"Maître Shao, quelle licence devrions-nous obtenir en premier ?"
Cette question est bien sûr importante. Faire des activités de paiement, qu'elles soient traditionnelles ou cryptographiques, ne peut contourner les licences. Le MSB américain (Money Services Business, enregistrement d'activité de services monétaires, techniquement un enregistrement au niveau fédéral plutôt qu'une licence traditionnelle), la licence MTL d'État (Money Transmitter License), le MSO de Hong Kong (Money Service Operator, opérateur de services monétaires), la licence MPI de Singapour (Major Payment Institution, institution de paiement principale), l'autorisation de service DPT (Digital Payment Token, jeton de paiement numérique), le CASP sous MiCA en Europe (Crypto-Asset Service Provider, fournisseur de services d'actifs cryptographiques) : tous peuvent devenir l'entrée réglementaire que les projets doivent affronter.
Mais dans la pratique, je ressens de plus en plus fortement une chose :
La licence n'est que la première chose, la deuxième chose détermine vraiment si un projet peut décoller.
Cette deuxième chose, ce n'est pas trouver une banque, ni trouver un canal, ni se précipiter pour lancer l'application.
C'est concevoir un circuit d'activités fermé, qui puisse être compris et exécuté conjointement par les banques, les institutions de paiement, les bourses, les fournisseurs de services de gestion des risques sur chaîne, les autorités de régulation, ainsi que les équipes internes du projet.
La licence est le ticket d'entrée, le circuit fermé est la capacité opérationnelle.
L'erreur la plus courante des projets de paiement cryptographique est de croire que la licence peut tout résoudre
De nombreux porteurs de projet ont une foi presque naïve dans les licences. Ils terminent l'enregistrement MSB aux États-Unis et pensent pouvoir faire des paiements et des collectes en stablecoins pour des clients du monde entier ; ils obtiennent le MSO de Hong Kong et pensent pouvoir intégrer au passage USDT, USDC ; ils voient que le coût d'une licence VASP dans un certain pays est faible et pensent pouvoir l'utiliser pour toutes les activités de paiement cryptographique ; ils entendent qu'une EMI ou PI d'un certain endroit peut traiter de la monnaie électronique et des paiements et pensent qu'elle couvre naturellement aussi les règlements sur chaîne en stablecoins.
Cette compréhension est dangereuse.
La licence résout le problème de "avez-vous le droit de vous asseoir à la table de jeu", pas le problème de "pouvez-vous concrètement faire ce métier".
Même si on appelle ça du paiement, les différences d'activités peuvent être énormes.
Aidez-vous les clients à effectuer des transferts en devises fiduciaires, ou à convertir des stablecoins ? Fournissez-vous des outils de collecte pour les marchands, ou un réseau de règlement transfrontalier ? Ne fournissez-vous que des interfaces techniques, ou gérez-vous réellement les fonds des clients ? Affichez-vous seulement des pages tierces, ou participez-vous à la tarification, à l'appariement, à la compensation, au règlement ? Laissez-vous les clients transférer eux-mêmes les cryptos aux marchands, ou la plateforme collecte-t-elle, paie-t-elle, convertit-elle pour le compte des clients ?
Chaque changement de détail entraîne des évolutions dans les exigences de licence, de conformité AML (lutte contre le blanchiment), de sanctions, de protection des fonds des clients, de responsabilité contractuelle et de risques fiscaux.
Par exemple, le MSO de Hong Kong correspond principalement aux services de change et de transfert d'argent, et ne couvre pas automatiquement les activités liées aux actifs virtuels comme la négociation, l'échange, la garde ou les stablecoins ; l'enregistrement MSB américain n'équivaut pas non plus à remplir toutes les exigences de licence de transmission monétaire au niveau des États américains ; la régulation CASP sous MiCA en Europe ne peut pas simplement remplacer les arrangements réglementaires liés aux paiements traditionnels, à la monnaie électronique ou à la coopération avec les comptes bancaires.
Donc, l'état le plus dangereux pour un projet de paiement cryptographique, ce n'est pas l'absence de licence, mais d'obtenir une licence et de penser ensuite pouvoir tout faire.
Certaines licences permettent effectivement au projet d'obtenir un statut réglementaire, d'autres sont effectivement bénéfiques pour ouvrir des comptes, lever des fonds, nouer des partenariats commerciaux et communiquer. Mais la licence en elle-même ne vous aide pas automatiquement à répondre aux questions qui préoccupent le plus les banques et les partenaires : qui sont les clients ? D'où vient l'argent ? D'où viennent les cryptos ? Quel est l'objet de la transaction ? À qui sont-ils finalement réglés ? Quel rôle joue exactement la plateforme au milieu ?
Si ces questions ne sont pas claires, plus on a de licences, plus on risque d'exposer la confusion dans la conception de l'activité.
La deuxième chose n'est pas de trouver une banque, mais de clarifier le circuit d'activités
De nombreux porteurs de projet diront que la deuxième chose après la licence, c'est bien sûr de trouver une banque.
Ce n'est vrai qu'à moitié.
La banque est bien sûr importante. Sans compte bancaire, sans entrée de devises fiduciaires, sans compte de règlement marchand, de nombreuses activités de paiement ne peuvent tout simplement pas démarrer. Mais le problème est que les banques n'acceptent pas les projets sur un coup de tête, elles veulent voir si cette activité peut être clairement expliquée, si la gestion des risques peut être continue, et si on peut établir des responsabilités en cas de problème.
Si le circuit d'activités n'est pas bien conçu, avoir contacté plus de banques ne fera que répéter les échecs.
Ce qu'il faut vraiment faire d'abord, c'est décomposer le circuit d'activités.
Première couche : le circuit client.
À qui le projet s'adresse-t-il exactement ? Aux utilisateurs individuels ou aux clients professionnels ? Aux e-commerçants transfrontaliers, aux marchands de jeux, aux réseaux publicitaires, aux travailleurs indépendants, ou aux porteurs de projet Web3 ? Les clients viennent de quels pays et régions ? Y a-t-il des Américains, des résidents de l'UE, des utilisateurs de Chine continentale ? Y a-t-il des utilisateurs de zones à haut risque ? Y a-t-il des secteurs à haut risque comme les sanctions, les jeux d'argent, les escroqueries, le contenu pour adultes, les agences de change informelles, le commerce fictif ?
L'identité du client détermine la profondeur du KYC (Know Your Customer, connaissance du client) et la couleur de risque fondamentale de l'activité.
Deuxième couche : le circuit des fonds.
D'où viennent les devises fiduciaires ? Sur quel compte entrent-elles ? Sont-ce des fonds clients, des paiements de règlement marchands ou des fonds propres de la plateforme ? La plateforme détient-elle des fonds clients ? Forme-t-elle une réserve de fonds ? Effectue-t-elle des collectes et des paiements pour le compte de tiers ? Implique-t-elle des transferts de change transfrontaliers ? Doit-elle passer par des banques, des EMI, des institutions de paiement, des acquéreurs, des organismes de transfert d'argent ou d'autres entités titulaires d'une licence pour effectuer le transfert de fonds ?
Si les flux de fonds ne sont pas clairs, les banques ne seront pas rassurées.
Troisième couche : le circuit des cryptos.
D'où viennent les stablecoins ? Les clients les transfèrent-ils eux-mêmes depuis la chaîne, ou la plateforme les aide-t-elle à les acheter ? La plateforme fixe-t-elle les prix ? Fait-elle de l'appariement ? Assure-t-elle la garde ? Gère-t-elle les clés privées ? Contrôle-t-elle les adresses sur la chaîne ? Utilise-t-elle des bourses tierces, du OTC, des fournisseurs de liquidités ou des services de garde ?
Dans les paiements cryptographiques, le flux de cryptos est plus facilement négligé que le flux de fonds. Mais la régulation et les partenaires posent maintenant la même question : pourquoi peut-on accepter cette crypto ? Cette transaction sur chaîne est-elle contaminée ? L'adresse a-t-elle été en contact avec des mélangeurs, des adresses d'escroquerie, des marchés darknet, des plateformes de jeux d'argent ou des listes de sanctions ?
Quatrième couche : le circuit de règlement.
Que reçoit exactement le marchand ? Des devises fiduciaires ou des stablecoins ? Si le marchand reçoit des devises fiduciaires, qui a effectué la conversion des actifs cryptographiques en devises fiduciaires au milieu ? Si le marchand reçoit des stablecoins, a-t-il lui-même la capacité de recevoir et de traiter les stablecoins ? Si la devise de paiement du client et la devise de collecte du marchand ne correspondent pas, qui supporte les taux de change, le slippage, les frais, les remboursements et les refus au milieu ?
Sans clarté à ce niveau, les litiges seront très nombreux.
Cinquième couche : le circuit de responsabilité.
Que faire si les fonds ou le compte d'un client sont gelés ? Que faire si un marchand est contesté ? Que faire si une adresse sur chaîne est marquée comme à haut risque par le KYT (Know Your Transaction, surveillance des transactions sur chaîne) ? Que faire si, après l'exécution d'une transaction, on découvre que la source des fonds est suspecte ? Qui traite les demandes de gel, de divulgation, d'assistance des autorités de régulation ou des services répressifs ? Si un canal tiers est interrompu, qui assume la responsabilité envers le client et le marchand ?
Les activités de paiement ne craignent pas la complexité, elles craignent la complexité sans limites de responsabilité.
Pourquoi de nombreux projets ne meurent pas sur la licence, mais sur le circuit fermé
Ces dernières années, j'ai vu pas mal de projets de paiement cryptographique, et l'obstacle final n'est souvent pas "avoir ou non une licence".
Le plus souvent, c'est que le porteur de projet a une identité réglementaire qui semble correcte, un produit qui semble fonctionnel, un canal technique qui semble déjà connecté, mais dès qu'on arrive aux étapes d'ouverture de compte bancaire, de due diligence des canaux, d'audit des partenaires, de due diligence des investisseurs ou de communication avec les régulateurs, toute l'histoire devient intenable.
Ces audits ne s'arrêtent pas au niveau "avez-vous une licence", ils continuent à décomposer.
Si le projet dit n'être qu'un fournisseur de services techniques, les partenaires regarderont généralement plus loin : les fonds et stablecoins des clients transitent-ils par des comptes ou portefeuilles contrôlés par la plateforme, la plateforme participe-t-elle au choix du chemin de transaction, décide-t-elle de l'exécution, assume-t-elle la promesse de réception, fait-elle des promesses de règlement aux marchands ?
Si le projet dit ne pas faire de change, les partenaires continueront généralement à regarder : les actifs payés par le client et ceux collectés par le marchand sont-ils identiques, y a-t-il conversion crypto/crypto, crypto/fiduciaire ou conversion de devises au milieu, qui fournit les prix, qui obtient l'écart, qui supporte le slippage et les remboursements ?
Si le projet dit simplement se connecter à des institutions tierces titulaires d'une licence, l'audit ne s'arrêtera pas là non plus. Les partenaires continueront à regarder : la relation client est-elle établie au nom de qui, qui effectue le KYC et le KYT, qui conserve les documents de transaction, qui traite les transactions anormales, qui est responsable envers le client et le marchand en cas d'échec du service tiers ?
Si le projet utilise des bourses, du OTC, des fournisseurs de liquidités ou des services de garde pour certaines étapes, cela impliquera encore une série de questions : l'usage des comptes professionnels, les documents justificatifs des transactions, la conservation des commandes et factures, le filtrage des adresses sur chaîne, la vérification de l'authenticité des marchands, le filtrage des listes de sanctions, etc.
C'est le dilemme réel de nombreux projets.
Sur le PowerPoint, c'est écrit PayFi (Payment Finance), Crypto Payment, Stablecoin Settlement, Global Merchant Acquiring, ça a l'air très avancé. Mais dès qu'on entre dans l'audit, les questions deviennent très concrètes : chaque somme d'argent, chaque crypto, chaque client, chaque marchand, peut-on l'expliquer ?
Les activités de paiement ne se résument jamais à "transférer de la valeur de A à B" si simplement. La véritable activité de paiement, c'est de répondre clairement avant chaque transfert de valeur : pourquoi peut-on transférer, qui a le droit de transférer, qui assume le risque, à qui s'adresser en cas de problème.
C'est l'importance du circuit fermé.
Le circuit de conformité des paiements cryptographiques doit au moins répondre à sept questions
Un circuit fermé de paiement cryptographique qui peut fonctionner doit au moins répondre à sept questions. Qui est le client ? Qui est le marchand ? Qui collecte l'argent ? Qui collecte les cryptos ? Qui effectue le change ? Qui assure la garde ? Qui assume la responsabilité de la lutte contre le blanchiment d'argent (AML), du filtrage des sanctions, des remboursements, des gels, des refus, des transferts erronés, de la contamination des actifs sur chaîne et des demandes de renseignements des régulateurs ?
Ces sept questions semblent simples, mais elles suffisent à révéler la véritable nature de la plupart des projets de paiement cryptographique.
Par exemple, un projet dit ne faire que de "l'agrégation de paiements en stablecoins". Il faut alors continuer à regarder : qu'est-ce qui est agrégé ? Des canaux de paiement ou de la liquidité de change ? Le client passe commande chez vous ou est-il directement redirigé vers un tiers ? Participez-vous à la tarification ? Contrôlez-vous le chemin de transaction ? Recevez-vous des actifs clients ? Promettez-vous aux marchands des délais et montants de réception ?
Autre exemple, un projet dit ne pas toucher aux fonds des clients. Il faut alors regarder le circuit réel : le client envoie-t-il l'argent sur un compte contrôlé par la plateforme ? Le client transfère-t-il les stablecoins sur un portefeuille contrôlé par la plateforme ? La plateforme a-t-elle le droit de décider de libérer, geler, retourner ou transférer ? Si oui, cela ne peut pas s'expliquer par un simple "ne pas toucher aux fonds".
Encore un exemple, un projet dit utiliser des institutions tierces titulaires d'une licence pour effectuer le change et le règlement. Il faut aussi regarder : qui est le tiers ? Quelles régions et activités couvre la licence du tiers ? Au nom de qui est établie la relation client ? Qui fait le KYC ? Qui conserve les documents de transaction ? Qui signale les transactions anormales ? Qui traite les réclamations des clients ? Y a-t-il une séparation claire des responsabilités et des avertissements sur les risques entre la page du tiers et celle de la plateforme ?
Le paiement cryptographique n'est pas une conformité ponctuelle, mais une conformité de circuit.
Individuellement, le projet peut avoir une licence, une banque, la technologie, des accords, des outils KYT. Mais si ces éléments ne sont pas intégrés dans le même circuit d'activités fermé, on aboutit à une situation très gênante : chaque pièce semble présente, mais la voiture ne roule pas bien.
Ce que l'avocat doit vraiment faire, ce n'est pas seulement aider le client à trouver une licence bon marché
Beaucoup de projets, à leurs débuts, demandent aux avocats : "Où la licence est-elle la moins chère ? Où est-ce le plus rapide ? Où la régulation est-elle la plus souple ?"
On peut poser cette question, mais pas seulement celle-là.
Une licence bon marché ne soutient pas forcément une activité réelle, le chemin le plus rapide ne passe pas forcément l'audit bancaire, un endroit où la régulation semble souple ne garantit pas la reconnaissance des partenaires principaux. Plus réalistement, un projet de paiement cryptographique ne se résout souvent pas avec une seule licence, mais résulte d'une combinaison de différentes entités, licences, partenaires et périmètres d'activité.
La valeur de l'avocat ici n'est pas seulement de dire au porteur de projet où demander une licence, mais de l'aider à décomposer l'activité en une structure que la régulation peut comprendre, que les partenaires peuvent accepter et que l'équipe peut exécuter.
Concrètement, les tâches incluent au moins :
Concevoir l'architecture des entités, préciser quelle entité est responsable de la signature des clients, quelle entité est responsable des services techniques, quelle entité est responsable des services de paiement, quelle entité s'interface avec les bourses, banques ou fournisseurs de liquidités.
Concevoir le chemin des licences, déterminer quelles activités nécessitent une licence propre, quelles activités peuvent être réalisées via des partenaires titulaires d'une licence, quelles activités ne sont pas possibles à l'étape actuelle, quelles activités peuvent être réservées pour une évolution future.
Concevoir les flux de fonds et de cryptos, tracer clairement chaque entrée et sortie de devises fiduciaires et de stablecoins, éviter que l'activité ne constitue en réalité des collectes/paiements pour le compte de tiers, des transferts d'argent sans licence, du change sans licence, de la garde sans licence ou des services d'actifs virtuels sans licence, alors que le porteur de projet pense n'être qu'un "fournisseur de services techniques".
Concevoir les règles de KYC, KYT, AML et de filtrage des sanctions, pour que les équipes opérationnelles de première ligne sachent quels clients peuvent être acceptés, lesquels nécessitent un audit renforcé, quelles transactions doivent être bloquées, quelles situations nécessitent un gel, un refus, un signalement ou l'arrêt du service.
Concevoir le système contractuel, intégrer les accords utilisateurs, accords marchands, accords de canaux, accords de liquidité, divulgation des risques, déclarations de services tiers, règles de traitement des transactions anormales et limites d'exonération en un ensemble cohérent, plutôt que de simplement assembler quelques modèles trouvés sur Internet.
Concevoir la communication externe, aligner le site web, le livre blanc, les pages de l'application, le discours commercial, les présentations commerciales et l'activité réelle. De nombreux projets ne meurent pas sur l'activité elle-même, mais sur le fait de "promettre trop à l'extérieur, de ne pas pouvoir le faire en interne, et que la régulation voit immédiatement le problème".
Un bon plan de conformité pour les paiements cryptographiques, ce n'est pas étouffer le projet, mais lui faire savoir où il peut agir, où il ne peut pas, et où il ne peut pas encore mais pourra plus tard.
Après la licence, le projet doit passer de "est-ce faisable ?" à "comment faire sans déraper ?"
Les paiements cryptographiques continueront certainement à se développer à l'avenir.
Les stablecoins pénètrent des scénarios de paiement et de règlement plus traditionnels, les banques, institutions de paiement, émetteurs de cartes, bourses, portefeuilles, prestataires de services marchands réévaluent tous leur position. Pour les porteurs de projet, c'est bien sûr une opportunité. Mais plus l'opportunité est grande, plus les exigences des régulateurs et des partenaires deviendront concrètes.
Autrefois, beaucoup de gens dans le secteur crypto aimaient parler de concepts, de flux, de technologie, de mondialisation. Maintenant, c'est différent. Maintenant, les banques regardent vos flux de fonds, les régulateurs regardent les limites de votre licence, les partenaires regardent la répartition des responsabilités, les investisseurs regardent vos coûts de conformité durable, les clients demandent qui est responsable en cas de problème.
Donc, pour faire du paiement cryptographique, la première chose est bien sûr la licence.
Mais la deuxième chose, ce n'est certainement pas se précipiter pour trouver une banque, ni se précipiter pour connecter un canal, encore moins se précipiter pour lancer.
La deuxième chose, c'est de structurer toute l'activité en un circuit fermé.
Ce circuit fermé doit au moins permettre : de pouvoir expliquer clairement l'activité, de pouvoir tracer le circuit, d'identifier les risques, de répartir clairement les responsabilités, d'avoir des contrats qui s'articulent, d'être exécutable par l'équipe, compréhensible par les partenaires, et de pouvoir répondre aux questions des régulateurs.
Si on n'y arrive pas, la licence n'est qu'un certificat accroché au mur. Si on y arrive, la licence deviendra vraiment le point de départ de l'activité.
La véritable compétitivité d'un projet de paiement cryptographique, ce n'est pas qui obtient d'abord une licence bon marché, mais qui assemble d'abord la licence, la banque, les canaux, la gestion des risques sur chaîne, l'admission des clients, la responsabilité contractuelle et la discipline opérationnelle en un système capable de fonctionner à long terme.
