Préparation réglementaire
Préparation réglementaire dans l’UE
MiCA, DORA, le Travel Rule européen, les obligations AML et les exigences relatives aux services de paiement sont mis en œuvre sous forme de modules de plateforme, d’enregistrements et de workflows opérationnels, plutôt que laissés dans des documents de politique interne.
Perspective de la direction générale
Un cadre commun. Plusieurs États d’origine.
MiCA, DORA et le cadre européen LCB-FT (lutte contre le blanchiment de capitaux et le financement du terrorisme) créent un ensemble de règles commun ; l’UE ne constitue pas pour autant un marché d’agrément uniforme. L’État membre d’origine choisi, son autorité nationale compétente, l’accès local aux services bancaires et les attentes des autorités de supervision déterminent la manière dont un programme d’agrément se déroule réellement.
La période transitoire MiCA est terminée. Les nouveaux projets de crypto-actifs dans l’UE doivent être conçus dès l’origine pour le modèle opérationnel d’un CASP (prestataire de services sur crypto-actifs) agréé – les enregistrements, les contrôles et la résilience passent ainsi d’une tâche postérieure au lancement à une exigence de conception.
Grumpio fournit une base produit technique commune et un programme de mise en œuvre réglementaire propre à chaque pays. La mise en œuvre européenne associe un logiciel fintech éprouvé en production à un programme de préparation MiCA, paiements, DORA et LCB-FT adapté à l’État membre d’origine ; la direction coordonne ainsi un seul plan de livraison plutôt qu’une chaîne de fournisseurs.
Préparation MiCA et CASP
Une préparation couvrant le modèle opérationnel
Grumpio met en œuvre les couches techniques et opérationnelles dont dépendent une demande d’agrément CASP et la supervision continue ; les chantiers de gouvernance, prudentiels et juridiques demeurent auprès des conseils du client. Les nouveaux projets de crypto-actifs dans l’UE devant opérer dès l’origine comme des CASP agréés, ces couches sont intégrées à la plateforme avant le lancement plutôt qu’ajoutées après coup. Le périmètre est confirmé au regard de l’État d’origine choisi et des services demandés.
Négociation, wallet et ledger
L’exécution des ordres, les workflows de conservation et les enregistrements financiers sont conçus comme une seule plateforme auditable, structurée autour des attentes des autorités de supervision.
Administration et habilitations
Les accès fondés sur les rôles, la séparation des tâches et la journalisation d’audit maintiennent les actions opérationnelles, financières et administratives distinctes et traçables.
Enregistrements clients et actifs
Les données relatives aux clients, aux ordres, aux transactions et aux actifs sont produites par le système sous forme d’enregistrements prêts pour le reporting, plutôt que compilées manuellement.
AML, KYC et contrôles de transfert
Le contrôle AML, la vérification KYC, l’analyse de risque des wallets et les contrôles de transfert sont intégrés à l’onboarding et à l’exploitation via Legichain ou les fournisseurs du client.
Reporting et éléments probants d’audit
Les données de reporting, les journaux et les enregistrements d’exploitation sont conçus pour que les éléments probants d’audit soient un sous-produit de l’exploitation quotidienne, et non un exercice de collecte distinct.
Déploiement et passation
Le déploiement dans des régions de l’UE, la documentation et une passation structurée permettent à l’équipe d’ingénierie du client d’exploiter et de faire évoluer la plateforme.
Pour la direction technique
DORA comme socle opérationnel
DORA s’applique depuis janvier 2025 et constitue un cadre d’exploitation en vigueur pour les CASP, les établissements de paiement et les établissements de monnaie électronique. La plateforme et les éléments probants d’exploitation sont conçus pour intégrer DORA au cycle de vie technologique, plutôt que d’en faire un exercice documentaire distinct.
Examiner l’approche d’ingénierie- Cartographies des actifs et services TIC : les services, les dépendances et les responsabilités sont consignés et tenus à jour.
- Workflows de gestion des incidents : les flux de détection, de classification et de déclaration produisent les enregistrements que les obligations en matière d’incidents exigent.
- Journalisation et observabilité : les événements clients, administrateurs, financiers et système sont surveillés de manière centralisée et restituables pour l’audit.
- Continuité et reprise : la sauvegarde est conçue conjointement avec les tests de restauration, les objectifs de reprise et les environnements d’exploitation alternatifs.
- Tiers et contrôle des changements : les inventaires de prestataires, les registres d’informations, l’architecture de sortie et des pipelines de mise en production tracés sont maintenus sous forme de données structurées.
Architecture de supervision
Supervision distribuée, rôles définis
La supervision dans l’UE est répartie entre des organes européens et nationaux plutôt que détenue par un régulateur central. Les demandes d’agrément sont en règle générale reçues et instruites par l’autorité nationale compétente de l’État membre d’origine choisi, qui supervise ensuite l’entreprise agréée, tandis que les autorités européennes coordonnent les normes, les registres et la convergence en matière de supervision. Le tableau résume des rôles publics de haut niveau ; la structure exacte est confirmée pour l’État d’origine choisi et le modèle d’activité.
| Autorité | Rôle en synthèse |
|---|---|
| Autorité nationale compétente de l’État d’origine | Reçoit et instruit les demandes d’agrément et supervise l’entreprise agréée |
| ESMA | Coordonne la supervision MiCA et tient le registre de l’UE ; elle n’agrée pas directement chaque CASP |
| EBA | Élabore les normes techniques et les orientations relatives aux services de paiement, à la monnaie électronique et aux domaines connexes |
| AMLA | Coordonne les travaux LCB-FT au niveau de l’UE depuis début 2026 ; la supervision directe d’entités sélectionnées est attendue à partir de 2028 |
| Autorités de protection des données | Font appliquer le RGPD au niveau des États membres, le Comité européen de la protection des données (EDPB) favorisant une interprétation cohérente |
La plupart des entreprises restent supervisées par leurs autorités nationales. Dernière revue du cadre réglementaire : 16 juillet 2026.
Pour la direction conformité
Transferts, filtrage, éléments probants
Les exigences réglementaires sont transformées en workflows opérationnels, habilitations, enregistrements, alertes et contrôles, plutôt que laissées dans des documents de politique interne. Pour une entreprise de l’UE, cela couvre le Travel Rule applicable aux crypto-actifs, les obligations de filtrage et les enregistrements attendus par la supervision.
La technologie de filtrage vient en appui du MLRO du client, de sa politique LCB-FT nationale et de ses décisions réglementées finales ; elle ne s’y substitue jamais. Le futur corpus LCB-FT de l’UE, applicable par étapes à partir de la mi-2027, fait l’objet d’un suivi afin de pouvoir ajuster les workflows.
- Workflows Travel Rule : les informations sur le donneur d’ordre et le bénéficiaire, les données du CASP de contrepartie et les déclarations de wallets auto-hébergés sont collectées, filtrées et enregistrées selon le modèle opérationnel.
- Filtrage : le filtrage des personnes physiques et morales, les contrôles PEP (personnes politiquement exposées) et sanctions, l’adverse media (couverture médiatique défavorable) et le risque des wallets multi-chaînes s’exécutent via le contrôle AML Legichain ou les fournisseurs choisis par le client.
- Vérification d’identité : la vérification KYC fondée sur les documents, la lecture NFC et les contrôles de liveness produit des décisions d’onboarding automatisées, sur lesquelles la politique de risque du client s’appuie ensuite.
- Surveillance et éléments probants : un refiltrage périodique maintient à jour le risque clients et wallets, et les résultats sont exportables sous forme d’enregistrements structurés pour la revue interne et les demandes des autorités de supervision.
Paiements et monnaie électronique
PSD2 aujourd’hui. PSD3 à venir.
PSD2 et EMD2, avec leur transposition nationale, l’authentification forte du client et DORA, demeurent le cadre en vigueur pour les établissements de paiement et de monnaie électronique de l’UE, aux côtés du règlement sur les paiements instantanés lorsqu’il s’applique. PSD3 et le règlement sur les services de paiement (PSR) arrivent, mais n’ont pas encore remplacé ce cadre : les projets actuels sont donc construits sur les règles en vigueur et la transition est suivie via le modèle de support convenu.
-
Adaptation à l’État d’origine
La plateforme de monnaie électronique est adaptée à l’agrément de l’État d’origine du client, à son modèle de protection des fonds (safeguarding), à ses rails de paiement et à la structure de son programme de cartes – le périmètre est décrit sur la page logiciel de monnaie électronique.
-
Protection des fonds et rapprochement
La cartographie du ledger, les enregistrements des comptes de protection des fonds, le rapprochement et les workflows d’exception produisent les enregistrements que le modèle de protection des fonds de l’établissement exige. Grumpio ne détient pas les fonds des clients, n’en assure pas la protection et ne les transmet pas.
-
Cartes crypto et wallets
Une offre de carte crypto ou de wallet peut relever à la fois du périmètre d’agrément MiCA, d’un agrément de paiement ou de monnaie électronique et des règles des réseaux de cartes ; l’architecture est cartographiée sur l’ensemble de ces couches plutôt que réduite à un seul agrément.
Architecture des données
RGPD et résidence des données
Les environnements clients de l’UE peuvent être déployés on-premises ou sur une infrastructure dédiée dans des régions de l’UE, avec des flux de données et une conservation adaptés au modèle opérationnel de l’État d’origine. L’architecture de stockage des données et de déploiement peut être configurée autour de la juridiction d’exploitation du client et de ses exigences institutionnelles.
Le lieu de déploiement n’est qu’un élément d’une architecture de données plus large : base légale, conservation, minimisation, contrôle d’accès et registres de violations sont traités dans la conception de la plateforme, et les transferts hors EEE sont évalués avec des garanties appropriées. L’hébergement dans un pays donné ne règle pas à lui seul toutes les obligations de protection des données.
Solutions associées
La préparation avance avec le produit
La préparation à l’UE ne prend pas la forme d’un rapport. Elle est mise en œuvre sur la plateforme que l’entreprise exploitera, dans le même plan de projet que le déploiement et les intégrations. Le programme complet est décrit sur la page préparation réglementaire.
-
Logiciel de plateforme d’échange crypto
Négociation, wallets, ledger, prise en charge du Travel Rule et back-office conçus pour le modèle opérationnel d’un CASP agréé.
-
Logiciel de monnaie électronique
Comptes, ledger en partie double (comptabilité en partie double), enregistrements de protection des fonds, paiements et back-office adaptés à l’agrément de l’État d’origine.
-
Logiciel de contrôle AML
Filtrage des personnes physiques et morales, PEP et sanctions, adverse media et risque des wallets, avec éléments probants exportables.
-
Logiciel de vérification KYC
Vérification automatisée des documents, NFC et liveness, intégrée aux parcours d’onboarding de l’UE.
Processus de mise en œuvre
De l’État d’origine aux éléments probants
La préparation est conduite comme un processus d’ingénierie produisant des livrables vérifiables, mené en parallèle du déploiement de la plateforme plutôt que comme un exercice documentaire distinct. Une plateforme éprouvée en production est adaptée à l’État d’origine choisi, au périmètre de services, aux fournisseurs, au modèle de données et aux attentes des autorités de supervision ; la séquence ci-dessous est donc planifiée en fonction de la juridiction et du modèle d’activité.
-
Périmètre et État d’origine
Le modèle d’activité, les services envisagés, l’État membre d’origine cible et les systèmes existants sont évalués conjointement.
-
Cartographie des exigences
Les exigences MiCA, DORA, Travel Rule, LCB-FT, paiements et données sont rattachées aux modules de la plateforme, aux enregistrements, aux workflows et aux fournisseurs pour la juridiction retenue.
-
Mise en œuvre
Modules, habilitations, intégrations et enregistrements sont configurés sur la plateforme ; les travaux de préparation avancent en parallèle du déploiement et de la personnalisation.
-
Éléments probants et validation
Enregistrements, journaux, rapports et livrables de continuité sont testés afin de confirmer que le système produit ce que la supervision et l’audit attendent.
-
Exploitation et mises à jour
Les textes à venir, tels que PSD3, le PSR et le paquet LCB-FT de l’UE, font l’objet d’un suivi après la mise en production, et les évolutions sont appliquées via le modèle de support convenu.
FAQ
Questions fréquentes
L’agrément est en règle générale traité par l’autorité nationale compétente de l’État membre d’origine choisi, qui reçoit la demande et supervise l’entreprise agréée. L’ESMA soutient la convergence en matière de supervision et tient le registre de l’UE, mais elle n’est pas automatiquement l’autorité d’agrément directe de chaque CASP.
La période transitoire MiCA est terminée. Les nouveaux projets de crypto-actifs dans l’UE doivent être conçus dès l’origine pour le modèle opérationnel d’un CASP agréé. En pratique, la négociation, la conservation, les enregistrements, l’AML/KYC et les contrôles de résilience sont intégrés à la plateforme avant le lancement plutôt qu’ajoutés après coup, et la mise en œuvre est adaptée à l’État d’origine choisi.
DORA s’applique depuis janvier 2025 et est traité comme le cadre d’exploitation en vigueur, non comme une législation à venir. Les cartographies des actifs et services TIC, les workflows de gestion des incidents, la journalisation centralisée, les tests de sauvegarde et de restauration, les inventaires de tiers et les contrôles des changements sont configurés comme partie intégrante de la plateforme : les éléments probants d’exploitation attendus par DORA sont ainsi produits par le système lui-même.
Les environnements clients de l’UE peuvent être déployés on-premises ou sur une infrastructure dédiée dans des régions de l’UE, avec des flux de données et une conservation adaptés au modèle opérationnel de l’État d’origine. Le lieu d’hébergement ne règle pas à lui seul toutes les questions de protection des données : les transferts, la conservation et les accès sont donc évalués dans le cadre de la conception du déploiement.
PSD2 et EMD2, avec leur transposition nationale, demeurent le cadre en vigueur pour les paiements et la monnaie électronique dans l’UE. PSD3 et le PSR constituent un cadre à venir, qui n’avait pas été formellement adopté à la date de la dernière revue. Les plateformes sont structurées de sorte que la transition puisse être suivie et appliquée via le modèle de support convenu.
Non. Grumpio fournit le logiciel, les enregistrements, les workflows et les contrôles d’exploitation dont dépend un programme d’agrément, et se coordonne avec les conseils juridiques et conformité du client. Les avis juridiques et la décision d’agrément demeurent du ressort des conseils du client et de l’autorité nationale compétente.
Le programme équivalent pour les entreprises du Royaume-Uni est décrit sur la page préparation réglementaire au Royaume-Uni.
Prochaine étape
Planifier le programme de préparation pour l’UE
La première réunion examine le modèle d’activité, les États d’origine envisagés et les systèmes existants, puis esquisse la manière dont la livraison de la plateforme et les travaux de préparation s’articuleraient dans un seul et même plan.