vIBAN : pourquoi près de la moitié de votre portefeuille pourrait être requalifié en compte de paiement

Le 30 mars 2026, l'ACPR et Tracfin ont publié un rapport conjoint que peu d'éditeurs LCB-FT ont lu attentivement, mais qui change discrètement le périmètre réglementaire d'une partie significative de l'activité des établissements de monnaie électronique. Le document s'intitule Panorama et analyse des services d'IBAN virtuels offerts en France, sous l'angle de la lutte contre le blanchiment des capitaux et le financement du terrorisme. Sous un titre clinique, il pose une affirmation sans précédent : une part importante de ce que les EMI commercialisent aujourd'hui sous l'étiquette « vIBAN » sont en réalité des comptes de paiement à part entière, et doivent être traités comme tels.

À 14 mois de l'entrée en application du règlement (UE) 2024/1624 (AMLR), cette requalification déclenche un empilement d'obligations nouvelles que la plupart des dispositifs internes des EMI ne sont pas calibrés pour absorber. Cet article décrypte la grille de critères publiée, mesure les conséquences, et propose un cadre opérationnel pour diagnostiquer un portefeuille existant.

L'ordre de grandeur

Le rapport documente l'état du marché à fin 2022 : 1,7 million de vIBAN actifs en France, dont 731 004 chez les établissements financiers, 610 669 dans les sociétés non financières, le reste chez les particuliers. Pour un mois de référence — janvier 2023 — ces vIBAN ont véhiculé 4 milliards d'euros de transactions. Trois ans plus tard, les volumes ont sensiblement augmenté et la concentration s'est faite sur quelques acteurs : un seul EMI peut compter plusieurs centaines de milliers de vIBAN actifs, avec une moyenne de 40 000 vIBAN par client institutionnel.

Sur ce volume, le rapport identifie deux usages clairement à risque élevé — la réattribution en cascade (cas 4) et la fourniture de vIBAN avec un code pays différent de celui du compte maître (cas 5) — et signale un troisième angle moins discuté : la pratique consistant à délivrer aux utilisateurs finaux des fonctionnalités qui s'apparentent à celles d'un compte autonome, sans que l'EMI applique le régime correspondant.

C'est ce troisième angle que la grille de qualification adresse.

Ce qui change entre un vIBAN et un compte de paiement

L'ACPR ne crée pas une obligation neuve. Elle rappelle que l'article L. 314-1 I du Code monétaire et financier, transposant l'article 4 (12) de la DSP2, définit un compte de paiement comme « un compte détenu au nom d'une ou de plusieurs personnes, utilisé pour l'exécution d'opérations de paiement ». Dès lors qu'un identifiant bancaire est utilisé pour exécuter des opérations au nom d'un tiers autre que le titulaire du compte maître, ce n'est plus un sous-compte mais un compte autonome — quelle que soit l'appellation commerciale.

Les conséquences sont disproportionnées. Un vIBAN au sens strict — au sens du compte fusionné homogène que l'ACPR accepte de longue date — n'exige qu'une vigilance allégée fondée sur la connaissance du titulaire du compte maître. Une requalification en compte de paiement déclenche, pour chaque identifiant, l'ensemble des obligations applicables à la tenue de compte.

La dernière ligne est la plus exposante. Un EMI qui distribue ce qu'il croit être des vIBAN à des marchands d'une marketplace peut se trouver, à son insu, en situation d'exercice illégal de fourniture de services de paiement au sens de l'article L. 314-1 du Code monétaire et financier — sanctionné par l'article L. 572-5. L'illustration n° 8 du rapport (page 13) est explicite sur ce point : « une entreprise A disposant d'un compte offrant la possibilité de créer un nombre infini d'IBAN virtuels associés peut proposer à ses clients des services de paiement avec une apparence de légitimité, sans agrément ». Le rapport mentionne par ailleurs qu'au moins un EMI a déclaré un soupçon en 2023 sur un agent ayant détourné cette fonctionnalité.

La grille des cinq critères

L'ACPR retient cinq tests cumulatifs au sens propre du terme : la présence d'un seul d'entre eux suffit à requalifier un vIBAN en compte de paiement (rapport, page 31).

Premier critère : la délivrance d'un relevé d'identité bancaire associant le vIBAN au nom d'une autre personne que le titulaire du compte dont l'identité a été vérifiée par l'établissement. Concrètement, si l'EMI génère un RIB où l'intitulé est celui d'un marchand, d'un loueur, d'un freelance, ou de tout utilisateur final autre que le titulaire du compte maître chez l'EMI, le critère est rempli.

Deuxième critère : la délivrance d'un relevé de compte ou équivalent présentant un solde, sans qu'il s'agisse d'un simple sous-compte du même client. Un utilisateur final qui consulte « son » solde sur « son » vIBAN dans un back-office, une application mobile ou via une API, bascule mécaniquement dans la catégorie compte de paiement.

Troisième critère : l'initiation d'opérations de paiement depuis l'identifiant fourni vers des tiers librement choisis, le cas échéant à l'aide d'interfaces programmables, peu important quel numéro de compte apparaît comme émetteur dans les messages de paiement. La nuance technique est importante : même si la travel rule (règlement 2023/1113) impose que le message de paiement reflète le compte réel, le simple fait d'offrir au client la capacité d'initier des sorties libres suffit à requalifier.

Quatrième critère : l'exécution d'opérations de paiement à destination de contreparties autres que le titulaire du compte de la redirection. Autrement dit, des flux sortants qui ne reviennent pas exclusivement vers le compte personnel de l'utilisateur final. Si l'utilisateur peut envoyer de l'argent à un tiers, ce n'est plus un compte de réception, c'est un compte d'opérations.

Cinquième critère : l'exécution d'opérations de paiement entre plusieurs identifiants fournis par un établissement à un même client. Plusieurs vIBAN détenus par le même utilisateur final, entre lesquels des virements peuvent circuler, sont structurellement traités comme une famille de comptes autonomes utilisés à des fins analytiques par leur détenteur.

Deux cas réels pour fixer les idées

Marketplace e-commerce avec EMI agent de PSP. L'EMI tient un compte maître au nom de la marketplace. Pour chaque marchand vendant sur la plateforme, un vIBAN est généré. L'acheteur paie sur le vIBAN du marchand ; les fonds atterrissent sur le compte maître ; la marketplace voit dans son back-office le crédit imputé au marchand ; périodiquement, un payout sortant est exécuté vers le compte bancaire externe du marchand. C'est le pattern dominant du Banking-as-a-Service en France et en Europe.

Application de la grille : le RIB est au nom du marchand (critère 1) ; les flux sortants vont vers une banque tierce du marchand (critère 4). Conclusion : compte de paiement à part entière. L'EMI doit appliquer le KYC complet à chaque marchand, l'inscrire au registre national des comptes bancaires, exercer une vigilance directe sur chaque relation et traiter chaque marchand comme un client direct au sens de la LCB-FT.

Foncière qui veut tracer ses loyers. La même structure technique, mais inversée. La foncière a un compte chez l'EMI. Pour chaque locataire, un vIBAN est généré. Le locataire vire son loyer sur ce vIBAN ; la foncière voit dans son ERP qui a payé. Aucune fonctionnalité n'est exposée au locataire — pas de RIB à son nom, pas de solde affiché, pas de virement sortant possible.

Application de la grille : aucun critère rempli. Le RIB reste au nom de la foncière. Le locataire est un simple débiteur. Conclusion : vIBAN homogène, vigilance allégée fondée sur la connaissance KYC de la foncière, conformément à la doctrine ACPR de longue date.

La frontière entre ces deux configurations n'est pas une question d'intention commerciale mais de paramétrage produit : à quel nom le RIB est-il généré, qui peut consulter le solde, qui peut initier des virements, vers qui ces virements peuvent-ils aller. Aujourd'hui, chez la plupart des EMI, ces paramètres sont éparpillés entre des fichiers de configuration, des conditions générales d'utilisation, des flags dans la base produit. Personne ne tient un inventaire centralisé qui dirait, pour chaque vIBAN actif, dans quelle catégorie il tombe.

Le diagnostic que l'AMLR rend obligatoire

L'article 22 du règlement (UE) 2024/1624 entre en application le 10 juillet 2027. Il dispose que « les établissements de crédit et les établissements financiers obtiennent des informations pour identifier et vérifier l'identité des personnes physiques ou morales utilisant tout IBAN virtuel qu'ils émettent, ainsi que le compte bancaire ou de paiement associé », et que l'établissement émetteur doit pouvoir fournir cette information sous cinq jours ouvrés à compter d'une demande d'une autorité compétente.

Pour un EMI qui distribue 500 000 vIBAN dont l'utilisateur final est connu seulement de son PSP client, cette exigence est inopérable sans automatisation. Il faut, pour chaque vIBAN, savoir : (i) si l'utilisateur final est un tiers vis-à-vis du compte maître, (ii) si une obligation directe de KYC s'applique, (iii) si le PSP client a ce KYC et selon quels accords contractuels il s'engage à le transmettre, (iv) sous quel délai et dans quel format l'information peut être consolidée. Aucune équipe humaine ne maintient cet inventaire à la main.

Le préalable opérationnel est donc un diagnostic systématique du portefeuille existant : passer chaque vIBAN actif dans la grille des cinq critères, classifier en vIBAN homogène ou compte de paiement, lister les obligations déclenchées, identifier les angles morts KYC. C'est cet inventaire qui détermine ensuite ce qu'il faut industrialiser entre 2026 et juillet 2027.

Ce qu'un agent IA LCB-FT peut faire qu'un projet interne ne fait pas

L'argument pour automatiser n'est pas un argument de coût analyste. C'est un argument de cohérence et d'auditabilité. La grille ACPR doit s'appliquer de la même façon à 500 000 vIBAN, et la justification de chaque classification doit être reconstituable trois ans plus tard devant un contrôleur. C'est un travail qui appelle un agent avec un tool use structuré, une trace d'exécution journalisée, et une RAG sur la doctrine elle-même.

Le module que nous développons pour les EMI prend un identifiant de vIBAN en entrée et produit en sortie une classification, la liste des critères remplis avec leurs preuves, la liste des obligations déclenchées, et la citation exacte du passage du rapport ACPR/TRACFIN justifiant la décision. L'agent récupère la configuration produit (template de RIB, droits d'API, droits de sortie), analyse les 90 derniers jours de transactions sur le vIBAN, recherche dans le registre interne combien d'identifiants sont attribués au même utilisateur final, applique la grille, journalise la décision, et propose une recommandation d'action — soit revoir le design produit pour rester en vIBAN homogène, soit basculer en compte de paiement avec un workflow KYC complet, soit suspendre le service en attendant arbitrage CCO.

Sur un portefeuille EMI de taille moyenne, ce diagnostic produit en quelques heures ce qu'une équipe conformité mettrait plusieurs mois à reconstituer à la main, et il le produit avec une trace d'audit homogène. La valeur principale n'est pas le gain de temps. Elle est dans l'élimination de l'incertitude réglementaire : un CCO qui dispose de ce diagnostic peut faire arbitrer la roadmap produit en sachant exactement combien de relations basculent dans quel régime, et chiffrer l'exposition contentieuse résiduelle.

L'enjeu calendaire

Le 10 juillet 2027 n'est pas une deadline lointaine. Il s'écoulera 14 mois entre la rédaction de cet article et l'entrée en application de l'AMLR. Sur cette période, un EMI confronté à un portefeuille mixte de vIBAN homogènes et de comptes de paiement déguisés a quatre chantiers à mener en parallèle : le diagnostic du portefeuille existant, la revue du design produit pour les nouvelles relations, la collecte rétroactive du KYC sur les utilisateurs finaux requalifiés, et la mise en place du dispositif d'inscription au registre national des comptes bancaires.

Aucun de ces chantiers ne peut commencer avant que le diagnostic ne soit fait. C'est le préalable méthodologique. C'est aussi le sujet sur lequel les acteurs qui démarrent maintenant prendront durablement l'avance — non pas parce que les autres ne pourront pas le faire, mais parce que la collecte rétroactive de KYC sur 100 000 utilisateurs finaux ne se compresse pas à un mois.

Nous travaillons actuellement avec quelques établissements de monnaie électronique français sur l'industrialisation de ce diagnostic. Les premiers retours portent sur des portefeuilles où la proportion de vIBAN à requalifier dépasse 40 % — un chiffre que peu de CCO anticipaient avant le rapport.

---

Le rapport conjoint ACPR/TRACFIN d'avril 2026 est disponible sur le site de l'ACPR. Pour discuter d'un diagnostic sur votre portefeuille ou d'une intégration de l'agent au sein de votre dispositif LCB-FT, contactez-nous ou testez le moteur d'analyse en libre accès sur /chat.