Échéance AMLR 2027 : le problème des infrastructures de données auquel les institutions ne sont pas préparées

Je pense que la plupart des établissements qui considèrent l’échéance de juillet 2027 comme un simple projet de mise en conformité découvriront, trop tard, qu’il s’agit en réalité d’une crise d’infrastructure de données. Le règlement anti-blanchiment (« AMLR ») ne se contente pas de relever la barre en matière d’actions à mener. Il modifie la norme sous-jacente concernant ce que vous devez savoir – et le savoir de manière cohérente, traçable et en temps réel. Les établissements qui ont passé des années à masquer les lacunes dans les données clients par des vérifications manuelles et le jugement d’analystes constateront que l’AMLR ne laisse aucune place à ces solutions de contournement. L’objectif est de mettre en place de meilleurs processus, mais pour y parvenir, il faut enfin s’attaquer au problème des données héritées qui a été reporté depuis une décennie.

Principaux enseignements

• Seul un tiers des entités concernées de l'UE prévoient d'être prêtes d'ici le 10 juillet 2027. Selon l'enquête 2026 de PwC sur la lutte contre le blanchiment d'argent dans la région EMEA, entre 14 % et 29 % des personnes interrogées avaient même réalisé une analyse d'impact détaillée (PwC, 2026).
• La qualité des données constitue le principal obstacle à la conformité aux normes AMLR, et non la conception des processus. PwC a constaté que la qualité des données était citée comme le principal obstacle à la généralisation de l’adoption des technologies et de l’IA par 52 % à 89 % des personnes interrogées, selon le secteur (PwC, 2026).
• L'AMLR est un règlement ne prévoyant aucune période de transition pour la transposition nationale – et ses exigences en matière de bénéficiaires effectifs finaux (UBO) constituent le test le plus rigoureux en matière de qualité des données. Ce même texte s'imposera à l'ensemble des 27 États membres à compter du 10 juillet 2027. Les bénéficiaires effectifs finaux (UBOs) devront être identifiés et vérifiés à partir d'un seuil de participation de 25 % ou moins, les registres centraux devront être consultés et les divergences signalées de manière proactive. Cette chaîne de vérification se rompt instantanément lorsque les données relatives aux entités sous-jacentes sont fragmentées ou obsolètes.
• La mise en conformité avec les exigences « Know Your Customer » (KYC) est déjà coûteuse. Avec l'entrée en vigueur de l'AMLR, elle le deviendra encore davantage. Les grandes banques de l'UE consacrent déjà en moyenne 5,7 millions d'euros par an au KYC, dont 74 % en frais de personnel (Ondato, 2025). Les exigences plus strictes de l'AMLR en matière de données alourdiront ce coût pour tous les établissements qui n'ont pas encore renforcé structurellement leurs bases de données.
• La qualité des données est une condition préalable aux gains de productivité, et non une conséquence de ceux-ci. Tout investissement dans l’automatisation – qu’il s’agisse d’outils de filtrage, de révision assistée par l’IA ou de modèles d’évaluation des risques – repose sur des données structurées et fiables. Les institutions qui déploient ces outils sur des données fragmentées ne gagnent pas en productivité. Elles automatisent à grande échelle leurs erreurs existantes, et les analystes continuent de passer la majeure partie de leur temps à rechercher des informations plutôt qu’à prendre des décisions.
• Les mesures coercitives de l'ACPR préfigurent l'approche de la loi AMLA. 48 % des sanctions prononcées par l'ACPR en 2023 concernaient des manquements liés à une connaissance insuffisante ou obsolète de la clientèle – avant même l'entrée en vigueur du nouveau régime (Welance Conseil, 2023).

Quels changements auront lieu le 10 juillet 2027 ?

Le paquet de mesures de l'UE de 2024 en matière de lutte contre le blanchiment de capitaux a introduit trois instruments étroitement liés. Ceux-ci ne sont pas interchangeables, et les confondre constitue l'une des erreurs les plus courantes commises par les institutions dans la planification de leur réponse.

Le changement structurel réside dans la nature même du règlement AMLR en tant que texte réglementaire. Pendant deux décennies, les obligations en matière de lutte contre le blanchiment d’argent ont été définies par des directives, que les États membres transposaient dans leur législation nationale, ce qui donnait lieu à des divergences d’interprétation que les établissements pouvaient contourner et, le cas échéant, exploiter. Le règlement AMLR supprime cette marge de manœuvre. À compter du 10 juillet 2027, un établissement de paiement à Dublin et une banque à Varsovie liront le même texte et seront soumis à la même norme.

Cette normalisation a une conséquence directe : elle élimine toute possibilité de compenser la faiblesse des données par une interprétation procédurale locale.

Pourquoi les données constituent-elles le véritable écart en matière de conformité ?

Les équipes chargées de la conformité mènent des analyses des écarts depuis deux ans. La plupart connaissent les exigences de l’AMLR. Elles sont toutefois bien moins nombreuses à avoir répondu en toute honnêteté aux questions les plus épineuses : où sont réellement conservées les données requises sur les clients et les bénéficiaires effectifs ? Qui en est responsable en interne ? Ces données peuvent-elles être retracées, vérifiées et mises à jour de manière cohérente d’une entité à l’autre et d’une juridiction à l’autre ?

Lorsque ces questions sont posées, la réponse est généralement gênante. Les informations clients sont généralement dispersées dans plusieurs systèmes : outils de gestion de la relation client (CRM), systèmes bancaires centraux, formulaires de l'onboarding , et tableurs opérationnels.

Le CRM est souvent au cœur de cet échec. La plupart des établissements stockent leurs données clients pertinentes en matière de conformité dans un système – Salesforce ou un équivalent propriétaire – qui a été conçu pour les interactions commerciales, et non pour la gestion des risques. Un CRM organise les données autour des transactions, des contacts et des étapes du cycle de vente. Nous avons développé cet argument en détail dans cet article : « Votre CRM est un outil de génération de chiffre d’affaires. Ce n’est pas un système KYC adapté. »

La conformité exige que les données soient organisées en fonction des profils de risque : chaînes de propriété, historique des vérifications, provenance des documents, déclencheurs de mise à jour liés aux événements. Le fait de présenter un enregistrement du CRM à un organisme de contrôle lors d’une inspection ne constitue pas une preuve de diligence raisonnable. Cela témoigne au contraire d’un système qui n’a jamais été adapté à cet usage. Pourtant, pour la plupart des établissements, le CRM reste de facto le système de référence pour les données clients, y compris les données de conformité.

Ce choix de conception a un effet cumulatif. Au cours de la dernière décennie, les institutions ont répondu à chaque nouvelle exigence réglementaire en acquérant une solution ponctuelle spécialisée : un outil pour l’identification des personnes politiquement exposées (PPE), un autre pour la vérification des pièces d’identité, un autre encore pour le filtrage des sanctions, et un dernier pour la surveillance des transactions. Chaque outil fonctionne de manière isolée. Aucun d’entre eux ne contribue à former une vue d’ensemble centrale et cohérente du client. Les régulateurs sanctionnent de plus en plus non seulement l’absence de contrôles, mais aussi l’absence d’un système capable de relier ces contrôles pour former une vue cohérente du client. Cette fragmentation est structurelle, et l’acquisition d’une nouvelle solution ponctuelle ne permet pas d’y remédier.

Plus précisément, l'AMLR impose :

• Identification et vérification des bénéficiaires effectifs au seuil de 25 % (ou inférieur dans les secteurs à haut risque), étayées par des pièces justificatives
• Consultation obligatoire des registres centraux des bénéficiaires effectifs tenus en vertu de la 6e directive anti-blanchiment (AMLD6), avec signalement documenté des divergences lorsque les informations contenues dans ces registres sont en contradiction avec les données internes
• Suivi continu, mise à jour périodique et examens déclenchés par des événements – et non pas une collecte ponctuelle
• Documents permettant de retracer la provenance des données, la date à laquelle elles ont été vérifiées et la manière dont elles ont influencé une décision en matière de conformité
• Une cohérence suffisante pour permettre aux groupes transfrontaliers de mettre en œuvre des contrôles et de fournir des éléments probants aux autorités de contrôle dans plusieurs juridictions

Rien de tout cela n'est possible lorsque les données clients sont stockées dans des silos isolés les uns des autres.

Pourquoi ne peut-on pas améliorer le processus KYC sans commencer par corriger les données ?

Le KYC est une fonction en aval. Il dépend entièrement de la qualité, de l'exhaustivité et de la cohérence des données clients qui l'alimentent. Lorsque ces données sont défaillantes – c'est-à-dire contradictoires ou fragmentées entre différents systèmes, collectées une seule fois et jamais mises à jour, stockées dans des formats qu'aucun outil de filtrage ne peut analyser –, aucun processus KYC, aussi bien conçu soit-il, ne peut produire un résultat fiable. Il s'agit d'un problème structurel que les institutions contournent depuis des années grâce à des efforts manuels et à des campagnes de correction récurrentes.

En tout état de cause, l’AMLR est le prétexte réglementaire que les équipes de conformité attendaient. La réglementation est l’un des rares leviers capables d’obtenir l’aval du comité exécutif pour des investissements dans les infrastructures qui ont été relégués au second plan depuis des années. Et la conformité est l’une des seules fonctions de l’entreprise à disposer d’un mandat réglementaire lui permettant d’imposer une vision unique et faisant autorité quant à l’identité d’un client — un problème que toutes les autres fonctions se sont révélées incapables de résoudre seules.

Voici à quoi cela ressemble concrètement :

• En l'absence d'une source unique de données fiables, le processus KYC reste toujours approximatif. Lorsque les données clients sont dispersées entre un CRM, un système bancaire central, un formulaire « onboarding » et une série de feuilles de calcul d'analystes, personne ne dispose d'une vue d'ensemble complète d'un client. Le rapprochement des données est manuel et lent.
• Les campagnes de mise en conformité constituent un aveu, et non une solution. Tout projet de mise en conformité KYC à grande échelle revient pour une institution à reconnaître que son architecture de données a produit des enregistrements qui n'ont jamais été adaptés aux exigences de conformité. Le nettoyage de ces enregistrements ne fait que corriger un instantané. Il ne corrige pas le système qui les a générés.
• L'automatisation appliquée à des données erronées rend le problème invisible, sans pour autant l'atténuer. Les files d'attente d'alertes s'allongent, les analystes sont débordés, les tableaux de bord affichent une activité intense. Mais la vision globale de la situation client reste incohérente. Les gains de productivité ne se concrétisent jamais, car les conditions préalables en matière de données n'ont jamais été remplies.

Pourquoi des données de mauvaise qualité rendent-elles l'automatisation inutile ?

C'est l'argument qui importe le plus pour les responsables des opérations et des technologies.

Tout investissement dans l'automatisation – qu'il s'agisse de l'examen de documents assisté par l'IA, de l'identification automatisée des bénéficiaires effectifs, de la surveillance continue des transactions ou de la notation des risques – repose sur l'hypothèse que les données clients sous-jacentes sont propres, structurées et cohérentes. Si l'on retire cette hypothèse, les calculs de productivité s'effondrent complètement.

Il ne s'agit pas d'une hypothèse. L'enquête « EMEA AML Survey 2026 » menée par PwC a révélé que la qualité des données était citée comme le principal obstacle à la généralisation de l'adoption des technologies et de l'IA par 52 % à 89 % des personnes interrogées, selon le secteur (PwC, 2026). Ces institutions ne manquent pas d'adopter les technologies. Elles les adoptent, mais se rendent compte qu'elles ne peuvent pas fonctionner sans la base de données nécessaire pour les soutenir.

Les arguments en faveur de la modernisation de l'infrastructure de données, en termes de productivité, sont, à bien des égards, plus convaincants que ceux liés à la conformité. Une lacune en matière de conformité engendre un risque réglementaire. Une lacune au niveau des données engendre un risque réglementaire et limite de manière permanente le gain d'efficacité que peut apporter tout investissement technologique. Les institutions qui considèrent la qualité des données comme une simple question de conformité et non comme un choix stratégique en matière d'infrastructure continueront à acheter des outils et à être déçues par les résultats.

Des données de qualité ne découlent pas d'outils plus performants. Ce sont les données de qualité qui permettent d'obtenir des outils plus performants. L'ordre des choses est important, et trop d'institutions inversent cette logique.

Que signifie réellement « prêt d'ici 2027 » ?

Une analyse des lacunes menée à bien ne signifie pas pour autant que vous êtes prêt. Pas plus qu’un contrat signé avec un nouveau prestataire. Être prêt signifie que votre établissement est en mesure de présenter à un contrôleur une vue d’ensemble cohérente et traçable du profil de risque de chaque client – issue d’un système unique faisant autorité, mise à jour en permanence et étayée par une piste d’audit complète détaillant la manière dont chaque donnée a été collectée et vérifiée.

La plupart des établissements n'en sont pas encore là. Seul un tiers environ des répondants de l'UE à l'enquête « 2026 EMEA AML Survey » menée par PwC s'attendaient à être en conformité d'ici le 10 juillet 2027 – et entre 14 % et 29 % d'entre eux avaient même réalisé une analyse d'impact détaillée (PwC, 2026).

Le problème est particulièrement aigu pour les groupes transfrontaliers, où un même client peut être représenté différemment selon les différents systèmes nationaux, où les structures des bénéficiaires effectifs sont documentées selon des normes locales variables, et où il n’existe aucune couche de données partagée reliant les entités entre elles. La volonté d’harmonisation exprimée par l’AMLR suppose un niveau de cohérence interne des données que la plupart des grandes institutions n’ont pas encore atteint. Pour ces groupes, juillet 2027 n’est pas une date butoir de mise en conformité, mais une date butoir pour la mise en place d’une infrastructure de données.

Que faut-il faire concrètement pour remettre de l'ordre dans la base de données ?

Les établissements qui seront prêts en juillet 2027 partagent une caractéristique commune : ils ont considéré les données clients comme une infrastructure, et non comme un simple sous-produit des processus de mise en conformité.

Concrètement, cela implique quatre choses :

1. Un modèle de données client unifié – un système de référence, et non un simple référentiel. L'identité du client, les structures de propriété et les documents associés doivent être centralisés dans un système unique faisant autorité, auquel tous les processus en aval – vérification, surveillance, reporting – puisent leurs informations. Pas de copies, pas d'exportations, pas de « data lake » : une source unique qui organise les données en fonction du risque, et non des interactions commerciales.

2. Des données structurées et lisibles par machine dès leur collecte. Les données relatives aux bénéficiaires effectifs (UBO) collectées sous forme de pièce jointe au format PDF et enregistrées dans SharePoint ne sont pas exploitables en l'état. Les données doivent être structurées dès leur ingestion, et non nettoyées a posteriori dans le cadre de campagnes de correction.

3. Une mise à jour continue, et non un examen périodique. Les exigences de l’AMLR en matière d’examen déclenché par des événements impliquent que tout changement concernant la propriété effective, le statut de personnalité politique exposée (PEP) ou le profil de risque doit déclencher des mises à jour automatiques. Cela nécessite de synchroniser les mécanismes d’alerte, les examens périodiques et les connexions en temps réel aux registres externes afin d’automatiser les flux de travail.

4. Une traçabilité complète intégrée dès la conception. Chaque donnée doit comporter des informations de provenance : d'où elle provient, quand elle a été vérifiée, par quels moyens, et comment elle a influencé une décision en matière de conformité. Il ne s'agit pas d'une fonctionnalité de reporting à ajouter ultérieurement. Elle doit être intégrée dès le départ dans le mode de stockage des données.

Comment Ondorse aborde-t-elle cette question ?

Les institutions avec lesquelles Ondorse collabore sont souvent confrontées à un problème récurrent : elles ont mis en place un programme de remédiation, acquis un outil de filtrage et amélioré leurs processus de « Know Your Customer » (« KYC ») – et pourtant, elles croulent toujours sous la charge de travail manuel.

L’approche d’Ondorse part de la couche de données, et non du flux de travail. Plutôt que de devenir une énième solution ponctuelle s’ajoutant à une architecture fragmentée, Ondorse fait office de système de référence pour la conformité KYC : la plaque tournante centrale qui remplace le CRM en tant que source faisant autorité en matière de données de conformité. La distinction n’est pas purement sémantique. Un système de référence organise les données autour du risque : chaque client fait l’objet d’évaluations (onboarding, évaluations périodiques, évaluations déclenchées par des événements) et dispose d’un profil de risque dynamique établi à partir d’une combinaison cohérente de signaux. Il se connecte également aux solutions ponctuelles déjà déployées par une institution et les consolide, de sorte que les informations relatives aux PEP, aux sanctions, aux vérifications négatives et à l’identification alimentent un dossier client unique et unifié, au lieu de rester cloisonnées dans des silos distincts.

Une fois ce système de référence en place, une deuxième étape devient possible : une automatisation par l’IA qui tient réellement ses promesses. Les institutions qui déploient actuellement des processus d’examen de documents assistés par l’IA, de notation automatisée des risques ou d’ onboarding s par agents – et qui sont déçues par les résultats – ne souffrent pas d’une IA de mauvaise qualité. Elles souffrent de données de mauvaise qualité et d’une infrastructure sous-jacente insuffisante. Les modèles d’IA ont besoin de contexte pour fonctionner de manière fiable : un profil client cohérent, structuré et à jour qui relie les documents, les données de propriété, les résultats de filtrage et l’historique des transactions au sein d’une vue unique. Ce contexte est exactement ce qu’offre un système de référence de conformité. Une fois la base de données corrigée, les investissements déjà réalisés dans l’automatisation commencent à porter leurs fruits. Les gains de productivité promis – un traitement plus rapide de l’ onboarding, moins de tâches manuelles, un coût par dossier réduit pour les analystes – deviennent réalisables, car la condition préalable à leur mise en œuvre est enfin remplie.

Pour les établissements qui commencent à évaluer leurs lacunes en matière d'AMLR, la première question à se poser n'est pas de savoir quel outil de gestion des processus acquérir, mais si leur architecture de données clients est capable de prendre en charge la norme imposée par l'AMLR. La réponse à cette question détermine tout le reste, y compris la valeur que vous pourrez tirer des outils que vous avez déjà achetés.

Découvrez comment Ondorse aide les entités assujetties à mettre en place la base de données nécessaire au respect des exigences de l'AMLR : ondorse.co/contact.