Étendre la conformité KYB à l'échelle européenne : comment éviter les complexités liées à chaque pays

Une solution « Know Your Business » (KYB) peut sembler relativement simple à mettre en œuvre lorsqu'elle est déployée dans un seul pays. Le cadre réglementaire y est bien défini et le nombre de variations locales est limité.

La situation est différente lorsque votre entreprise est présente sur plusieurs marchés européens.

Chaque pays a ses propres exigences réglementaires, attentes en matière de surveillance et obligations de déclaration. Si l'on ajoute à cela la multiplicité des canaux, des produits et des entités opérationnelles, la mise en œuvre peut rapidement se traduire par un enchevêtrement ingérable de règles et d'exceptions spécifiques à chaque pays.

Chaque pays a ses propres exigences réglementaires, attentes en matière de surveillance et obligations de déclaration. Mais la difficulté opérationnelle la plus profonde ne réside pas dans la diversité des règles, mais dans le manque de cohérence des données sous-jacentes. Les registres du commerce varient considérablement quant aux informations qu’ils publient, à la fréquence de leurs mises à jour et à la question de savoir si les informations qu’ils contiennent peuvent être considérées comme faisant autorité aux fins de la connaissance du client (KYB).

Cette transition est toujours en cours. À travers l'Europe, l'écart de fiabilité entre ce que publie un registre et ce sur quoi on peut se fier en toute sécurité dans un processus KYB n'est ni uniforme ni statique. Si l'on ajoute à cela la multiplicité des canaux, des produits et des entités opérationnelles, le défi ne se résume pas à un enchevêtrement de règles propres à chaque pays. Il s'agit d'un enchevêtrement d'hypothèses relatives à la qualité des données propres à chaque pays, qui doivent être explicitement modélisées, documentées et mises à jour.

Cette préoccupation est compréhensible. Mais elle confond deux choses qui ne sont pas identiques : la diversité réglementaire, qui est bien réelle, et la complexité architecturale, qui relève d'un choix. C'est cette dernière qui, en réalité, entrave les déploiements dans plusieurs pays.

Le véritable défi ne réside pas dans l'échelle européenne, mais dans une complexité incontrôlée.

Conséquence typique d'un développement pays par pays : une règle mise à jour en France n'est pas prise en compte en Belgique. Un changement réglementaire en Allemagne entraîne trois mois de nouveaux tests. L'équipe chargée de la conformité au sein du groupe ne peut pas établir une vue consolidée sans procéder à un rapprochement manuel. Rien de tout cela n'est dû aux réglementations. Cela est dû à des logiques redondantes, en l'absence de gouvernance partagée.

Cette question porte généralement sur quatre domaines :

• La mise en œuvre initiale de la solution
• La mise à jour régulière des règles spécifiques à chaque pays
• La gestion de plusieurs pays sur une seule plateforme
• La production de rapports réglementaires adaptés à chaque autorité de régulation locale

Il ne s'agit pas là de défis distincts. Ils sont étroitement liés. Si les adaptations locales sont mises en œuvre au moyen de configurations en double, de solutions de contournement manuelles ou d'une logique conditionnelle de plus en plus complexe, la plateforme devient difficile à comprendre, à maintenir et à auditer.

Une approche évolutive repose sur un principe différent : standardiser le modèle opérationnel, tout en ne localisant que ce qui doit véritablement l'être.

S'appuyer sur un cadre commun

Un déploiement dans plusieurs pays ne doit pas commencer par la mise en place d'une solution distincte pour chaque marché.

Les organisations devraient commencer par définir les éléments pouvant faire l'objet d'un partage entre les différents pays :

• Une méthodologie commune en matière de risques
• Un modèle de données partagé
• Flux de travail et processus de validation cohérents
• Gouvernance et contrôles d'accès normalisés
• Une piste d'audit commune
• Principes de présentation des comptes au niveau du groupe

Les exigences spécifiques à chaque pays sont ensuite ajoutées sous forme d'extensions contrôlées : réglementations locales, obligations relatives aux produits, exigences en matière de distribution, formats de rapports.

L'objectif n'est pas d'éliminer les différences locales, mais d'éviter que chaque différence ne donne lieu à un processus ou à un système distinct. La plupart des obligations de l'UE en matière de lutte contre le blanchiment d'argent (AML) reposent sur la même architecture de base : vérification de l'identité des clients fondée sur les risques, identification des bénéficiaires effectifs, surveillance continue. Ce qui diffère réellement d'un marché à l'autre, ce sont les seuils, les types de documents et les formats de déclaration. Aucun de ces éléments ne nécessite un système distinct par pays.

Veillez à ce que les règles locales restent modulaires

Les exigences spécifiques à chaque pays deviennent difficiles à gérer lorsqu'elles sont directement intégrées dans la logique centrale d'une plateforme. Une simple mise à jour réglementaire nécessite alors des modifications parallèles dans toutes les versions nationales. Une seule mise à jour manquée entraîne un manquement à la conformité et fait l'objet d'une constatation lors d'un audit.

Un modèle plus durable distingue :

• Méthodologie de base
• Exigences réglementaires locales
• Paramètres commerciaux (seuils, produits, canaux)
• Processus opérationnels
• Obligations en matière de déclaration

Cette séparation permet aux organisations de mettre à jour un composant local sans avoir à repenser l'ensemble du modèle. Elle renforce également la traçabilité en indiquant quelles règles sont actives, pourquoi elles existent, qui les a approuvées et où elles s'appliquent.

Un exemple concret : lorsque le seuil d'identification des UBO en Allemagne change, seul le paramètre local concerné est mis à jour. Chaque dossier allemand en cours est automatiquement réévalué à la lumière de la nouvelle règle : pas de file d'attente de retraitement, pas de réacheminement manuel, pas de risque de dossiers oubliés. Cette même mise à jour n'aurait aucune incidence sur les configurations françaises ou belges.

Le même principe s'applique à la logique conditionnelle. Lorsque des pays appliquent ce même principe avec des seuils ou des paramètres différents, ceux-ci doivent être considérés comme des variantes d'une règle commune plutôt que comme des règles totalement distinctes.

Le tableau ci-dessous montre dans quels cas une standardisation est possible et dans quels cas une véritable localisation est nécessaire :

Gérer conjointement les pays et les chaînes

La complexité tient également à l'interaction entre les pays, les produits, les entités juridiques et les circuits de distribution.

Un modèle de gouvernance clair devrait définir les responsabilités à trois niveaux :

La gestion centralisée couvre la méthodologie globale de gestion des risques, la politique de lutte contre le blanchiment d'argent, le modèle de données et le cadre d'audit. Tout changement à ce niveau nécessite une approbation officielle et est répercuté simultanément sur l'ensemble des marchés.

La gestion locale couvre les paramètres spécifiques à chaque pays : types de documents, connexions aux registres, modèles de rapports et dérogations aux seuils lorsque la réglementation locale l'exige. Les équipes locales peuvent proposer des modifications ; une validation par le siège est requise avant leur mise en œuvre.

La responsabilité opérationnelle porte sur les décisions au niveau de chaque dossier : qui examine quoi, les procédures d'escalade, l'attribution des missions de diligence renforcée (EDD) et la planification des examens périodiques. Ce niveau peut être entièrement délégué aux équipes locales sans compromettre l'intégrité de la méthodologie centrale.

Cette structure permet d’éviter deux types de défaillances : d’une part, que les équipes centrales deviennent un goulot d’étranglement parce qu’elles détiennent l’entière responsabilité de tout, et d’autre part, que les équipes locales s’écartent discrètement de la ligne directrice parce qu’elles ont trop de responsabilités. Le contrôle des versions et les registres d’approbation à chaque niveau ne sont pas facultatifs. Ce sont eux qui permettent de rendre le modèle de gouvernance vérifiable lorsqu’un régulateur demande à consulter la chaîne de décisions qui sous-tend une classification des risques. (Lignes directrices du GAFI sur la supervision et l’application efficaces, 2021)

Prise en charge des rapports au niveau local et au niveau du groupe

Les autorités de régulation peuvent exiger des données, des formats, des fréquences ou des niveaux de détail différents. Parallèlement, les parties prenantes du groupe ont besoin d'une vue d'ensemble consolidée sur l'ensemble des marchés.

Un modèle de reporting évolutif devrait donc prendre en charge :

• Déclarations réglementaires locales (ACPR, BaFin, NBB, CSSF et autres)
• Rapports au niveau de l'entité
• Analyse des produits et des canaux de distribution
• Rapports au niveau du groupe
• Traçabilité des audits

Ces rapports doivent s'appuyer sur une base de données commune et correctement gérée. Lorsque l'ACPR exige un champ que la BaFin n'exige pas, ce champ est ajouté au modèle partagé et activé uniquement pour les entités françaises. Les exigences locales sont alors gérées à l'aide de mappages, de filtres, de vues et de modèles, plutôt que par le biais de systèmes parallèles.

Cela permet de réduire les opérations de rapprochement manuelles, d'améliorer la cohérence et de s'adapter plus facilement aux changements des exigences en matière de reporting.

Il faut envisager l'échelle européenne, et non la craindre

Un déploiement dans plusieurs pays comporte toujours une certaine complexité. La question essentielle est de savoir comment cette complexité est gérée.

Une plateforme reposant sur des configurations dupliquées, un reporting manuel et des exceptions opaques devient difficile à gérer. Une plateforme s’appuyant sur un cadre commun, des règles locales modulaires, des paramètres régulés et un reporting traçable peut accompagner l’expansion européenne sans que chaque pays ne devienne un projet à part entière.

La bonne question n'est pas de savoir si une solution impliquant plusieurs pays nécessitera une configuration. Ce sera le cas.

La bonne question est de savoir si cette configuration reste structurée, transparente et facile à maintenir à mesure que l'organisation se développe.

Ondorse prend directement en charge ce modèle opérationnel. La plateforme est conçue comme un système de référence en matière de conformité : chaque dossier, quel que soit le marché concerné, est représenté à travers un modèle de données unique axé sur les risques. C’est ce qui permet d’obtenir une véritable vue d’ensemble au niveau du groupe : non pas un rapport rapproché manuellement, mais une vue consolidée en temps réel, rendue possible par le fait que les données sous-jacentes n’ont jamais été cloisonnées.

L'ajout d'un pays implique d'étendre ce noyau commun avec des paramètres locaux, et non de tout reconstruire à partir de zéro. Les équipes chargées de la conformité peuvent effectuer ces modifications directement, en langage naturel, sans faire appel à des ingénieurs, et la mise à jour est effective pour tous les dossiers concernés en quelques jours, et non en plusieurs mois. Lorsqu'une réglementation locale change, les dossiers concernés sont réévalués automatiquement. Rien d'autre n'est modifié.