Community post

Dans l’industrie luxembourgeoise des fonds, le prochain enjeu de conformité ne sera probablement pas d’écrire davantage de politiques. Il sera de démontrer que ce qui est écrit correspond effectivement à ce qui est fait.

Les Management Companies et AIFM luxembourgeois ne manquent généralement pas de documentation.

AML Policy.

Risk Management Policy.

Delegation Oversight Framework.

Valuation Policy.

Conflict of Interest Policy.

Compliance Monitoring Plan.

Procedure de screening.

Periodic Review Procedure.

Best Execution Policy.

DORA framework.

SFDR documentation.

À cela s’ajoutent les comités, dashboards, KPI, contrôles de deuxième ligne, rapports des délégataires, questionnaires et minutes de gouvernance.

Sur le papier, l’architecture réglementaire peut être impressionnante.

Mais une question devient progressivement plus importante que toutes les autres :

l’organisation fonctionne-t-elle réellement comme ses procédures disent qu’elle fonctionne ?

Car c’est précisément dans l’écart entre Policy et Practice que se situe aujourd’hui une part croissante du risque réglementaire.

Et cet écart peut être beaucoup plus dangereux qu’une procédure manquante.

Lorsqu’une procédure manque, le problème est identifiable.

Il peut être enregistré dans un gap analysis.

Un owner peut être désigné.

Une remediation action peut être ouverte.

Une deadline peut être fixée.

Le défaut est visible.

La situation est plus délicate lorsqu’une procédure existe, a été approuvée par le Board, est accessible sur SharePoint et semble parfaitement adaptée au cadre réglementaire...

...mais n’est pas appliquée comme prévu.

Prenons quelques exemples.

La politique prévoit une Enhanced Due Diligence pour les High Risk relationships.

Mais certains dossiers High Risk ne comportent aucune mesure réellement différente des dossiers Medium Risk.

La procédure prévoit un maker-checker.

Mais le second contrôle est parfois réalisé par simple email, sans lien clair avec le dossier.

La politique prévoit une annual review des dossiers High Risk.

Mais la date de revue réellement utilisée dans les systèmes diffère de celle du reporting.

Le framework de délégation prévoit un oversight régulier des service providers.

Mais le contrôle consiste essentiellement à recevoir leurs reportings.

La procédure de sanctions prévoit le screening de la population entière.

Mais personne n’a récemment réconcilié la population source avec celle effectivement injectée dans l’outil.

La politique ESG décrit des engagements précis.

Mais le portefeuille réel n’a pas été testé suffisamment régulièrement contre ces engagements.

Dans chacun de ces cas, le problème n’est pas l’absence de règle.

Le problème est plus subtil :

l’organisation croit disposer d’un contrôle parce qu’elle dispose d’un document qui décrit ce contrôle.

Les priorités de supervision publiées par la CSSF pour le secteur des fonds en 2026 sont révélatrices.

La CSSF indique poursuivre ses travaux off-site et on-site selon une approche fondée sur les risques, avec une attention particulière à la gouvernance, aux fonctions de contrôle interne, aux risques opérationnels, à la délégation, à la valorisation, à la liquidité, aux risques ICT, à la finance durable et à l’AML/CFT.

Le point important n’est pas simplement la liste de ces domaines.

C’est la manière dont ils sont contrôlés.

La supervision ne consiste plus uniquement à demander :

« Disposez-vous d’une politique ? »

Elle cherche de plus en plus à comprendre :

« Comment fonctionne-t-elle ? »

« Qui exécute le contrôle ? »

« Comment l’avez-vous testé ? »

« Quelle population avez-vous utilisée ? »

« Quelles anomalies avez-vous identifiées ? »

« Comment les avez-vous corrigées ? »

« Comment le Board en a-t-il été informé ? »

La Common Supervisory Action lancée en juillet 2026 par l’ESMA et la CSSF sur la fonction de risk management des UCITS Management Companies et AIFM illustre parfaitement cette évolution : elle porte notamment sur la gouvernance et l’organisation de la fonction, l’identification, la mesure et le monitoring des risques, ainsi que le reporting vers le senior management et les organes de gouvernance.

Autrement dit :

la conformité ne se juge plus seulement à travers le design du dispositif, mais à travers son fonctionnement réel.

Les professionnels de l’audit connaissent depuis longtemps cette distinction.

Un contrôle peut être parfaitement conçu.

Cela ne signifie pas qu’il fonctionne.

Il existe donc deux questions différentes.

Design effectiveness

Le contrôle est-il correctement conçu pour couvrir le risque ?

Operating effectiveness

Le contrôle fonctionne-t-il réellement comme prévu ?

Dans beaucoup de dispositifs de compliance, l’essentiel des efforts historiques a porté sur la première dimension.

Les politiques ont été rédigées.

Les contrôles ont été définis.

Les responsabilités ont été attribuées.

Les matrices ont été construites.

Mais la seconde dimension devient désormais décisive.

Le contrôle fonctionne-t-il sur l’intégralité de la population ?

À la fréquence prévue ?

Avec la bonne méthodologie ?

Avec la bonne indépendance ?

Avec une preuve exploitable ?

Et surtout :

les exceptions sont-elles identifiées et traitées ?

C’est là que se situe souvent le véritable risque.

Prenons un exemple simple.

Une procédure prévoit que toutes les relations High Risk soient revues annuellement.

Le dashboard présenté au comité indique :

High Risk periodic reviews completion rate: 95 %

Le chiffre paraît rassurant.

Mais imaginons que :

• la population source comprenne en réalité 21 dossiers et non 20 ;
• un dossier liquidé soit toujours présent ;
• deux dossiers aient changé de rating sans que le fichier de suivi ait été actualisé ;
• une revue enregistrée comme « completed » ne dispose pas encore de l’approbation requise ;
• et que le calcul du KPI soit effectué manuellement.

Le chiffre de 95 % peut alors être mathématiquement exact sur le fichier utilisé...

...tout en étant réglementairement trompeur.

Le problème n’est pas nécessairement une mauvaise intention.

Il s’agit souvent d’un problème plus banal :

l’absence de réconciliation entre procédure, donnée, système et reporting.

Et c’est précisément ce type de faiblesse que les organisations doivent apprendre à identifier.

Policy → Procedure → Process → System → Data → Control → Evidence → Reporting

La maturité réglementaire ne peut plus être appréciée sur la seule base d’une politique.

Chaque obligation importante devrait pouvoir être suivie tout au long de cette chaîne.

Prenons le screening AML.

Policy

La politique prévoit un screening sanctions, PEP et adverse media.

Procedure

La procédure détermine qui doit être screené, quand et selon quelles modalités.

Process

Les équipes opérationnelles injectent ou alimentent la population.

System

L’outil exécute le screening.

Data

La population réellement screenée doit correspondre à la population attendue.

Control

Les alertes sont analysées et soumises à un maker-checker lorsque nécessaire.

Evidence

L’organisation conserve l’historique du match, de l’analyse et de la décision.

Reporting

Les true hits, incidents, volumes et exceptions sont remontés au niveau approprié.

Si une seule de ces briques ne fonctionne pas, l’existence d’une excellente policy ne protège pas nécessairement l’organisation.

Toutes les organisations connaissent ce phénomène.

Une procédure est créée.

Elle répond parfaitement au besoin au moment où elle est rédigée.

Puis l’environnement change.

Un outil est remplacé.

Un prestataire change.

Une responsabilité est transférée.

Un nouveau type de véhicule est lancé.

Une équipe est réorganisée.

Une migration de données intervient.

Une règle interne est modifiée.

Mais la procédure demeure inchangée.

Progressivement apparaît alors ce que l’on pourrait appeler une procédure fantôme :

une procédure officiellement en vigueur, mais qui ne décrit plus exactement la réalité opérationnelle.

C’est un risque important.

Car une procédure obsolète peut être plus problématique que l’absence de procédure.

L’absence de procédure indique immédiatement qu’un travail doit être effectué.

La procédure fantôme donne au contraire l’impression que le risque est couvert.

L’écart Policy–Practice ne signifie pas toujours que l’organisation fait moins que ce qu’elle devrait.

Elle peut également faire davantage.

Par exemple :

la procédure prévoit une revue annuelle des High Risk, mais les équipes effectuent également des event-driven reviews ;

la procédure prévoit une validation par Compliance, mais une deuxième validation RC existe en pratique ;

la procédure prévoit un contrôle trimestriel, mais celui-ci est réalisé mensuellement.

Cela peut sembler positif.

Mais un processus qui dépend de pratiques non documentées présente lui aussi un risque.

Pourquoi ?

Parce que le dispositif devient dépendant :

• de certaines personnes ;
• d’usages informels ;
• de fichiers individuels ;
• d’emails ;
• de connaissances non documentées.

Lorsque la personne quitte l’organisation, le contrôle peut disparaître avec elle.

La documentation n’a donc pas uniquement pour fonction de satisfaire le régulateur.

Elle permet de rendre le dispositif reproductible.

Le secteur luxembourgeois des fonds repose largement sur des modèles délégués.

Portfolio management.

Fund administration.

Transfer agency.

Distribution.

IT.

Screening.

Valuation support.

Mais déléguer une activité ne signifie pas déléguer la responsabilité de supervision.

Les priorités CSSF 2026 prévoient d’ailleurs une étude auprès d’un échantillon d’IFM concernant le third-party risk management et les principes de délégation, avec un focus sur l’intégration d’un cadre opérationnel complet et effectif dans le dispositif global de gestion des risques.

Le risque Policy–Practice apparaît lorsque le Delegation Oversight Framework prévoit :

• KPI ;
• SLA ;
• due diligence ;
• periodic review ;
• escalation ;
• remediation tracking ;

mais que la réalité se limite à :

« Le prestataire nous envoie son quarterly report. »

Recevoir un reporting n’est pas exercer un oversight.

Le véritable contrôle commence lorsqu’on demande :

Qui a challengé le reporting ?

Les chiffres ont-ils été vérifiés ?

Les incidents récurrents ont-ils été identifiés ?

Les breaches ont-elles déclenché une action ?

Le plan de remédiation a-t-il été suivi ?

Les risques matériels ont-ils été remontés ?

Le contrôle réglementaire n’est pas le document reçu.

C’est ce que l’organisation fait du document reçu.

La finance durable fournit un autre exemple particulièrement instructif.

La CSSF indique en 2026 vouloir vérifier non seulement la conformité des informations précontractuelles et périodiques, mais également leur cohérence avec les portefeuilles, notamment au moyen d’analyses des titres détenus afin de vérifier leur correspondance avec le nom, les objectifs, la stratégie et les caractéristiques présentées aux investisseurs.

Voilà précisément le sujet.

Une disclosure peut être juridiquement parfaite.

Mais si le portefeuille réel ne correspond plus à ce qu’elle décrit, le risque naît de l’écart entre :

Disclosure

et

Reality.

Le greenwashing n’est donc plus seulement un problème rédactionnel.

Il peut devenir un problème de cohérence opérationnelle.

Pourquoi cette question devient-elle plus importante aujourd’hui ?

Parce que la supervision devient de plus en plus data-driven.

Plus les régulateurs disposent de données structurées, plus ils peuvent comparer :

• périodes ;
• fonds ;
• gestionnaires ;
• ratios ;
• incidents ;
• performances ;
• risques ;
• anomalies ;
• distributions statistiques.

Cela rend progressivement visibles des incohérences qui auparavant pouvaient rester enfouies dans des dossiers individuels.

Une politique peut affirmer qu’un risque est maîtrisé.

Les données peuvent démontrer le contraire.

Et lorsque la donnée et la procédure se contredisent, la procédure perd rapidement sa valeur probante.

Dans ce nouvel environnement, la fonction Compliance ne peut plus uniquement poser la question :

« La procédure est-elle conforme à la réglementation ? »

Elle doit ajouter :

« La réalité est-elle conforme à la procédure ? »

Et encore :

« Puis-je le démontrer ? »

Cette évolution implique une fonction Compliance davantage tournée vers :

• le testing ;
• le sampling ;
• la réconciliation ;
• la data analysis ;
• le walkthrough ;
• la challenge function ;
• le root-cause analysis ;
• le follow-up des remediation actions.

Autrement dit, moins de conformité exclusivement documentaire.

Et davantage de compliance assurance.

Il existe un moyen très simple de tester la robustesse d’une procédure.

Ne pas commencer par la procédure.

Commencer par un dossier.

Prenons une relation High Risk au hasard.

Et reconstruisons tout le chemin.

Pourquoi est-elle High Risk ?

Quel critère de la méthodologie a déclenché ce niveau ?

Quelle EDD a été réalisée ?

Qui l’a approuvée ?

Quelle periodicité de monitoring en découle ?

La dernière revue a-t-elle été réalisée dans les délais ?

Le screening est-il actif ?

Quels contrôles de deuxième ligne ont porté sur ce dossier ?

La situation est-elle reflétée correctement dans le reporting management ?

Puis seulement après, comparons cette réalité à la procédure.

Cet exercice peut être extrêmement révélateur.

Les AIFM et Management Companies pourraient intégrer à leur Compliance Monitoring Programme un test très simple.

Pour chaque processus matériel :

1. What do we say we do?

Que prévoient nos policies et procedures ?

2. What do we actually do?

Que font réellement les équipes ?

3. What does the system do?

Le système reflète-t-il le processus décrit ?

4. What does the data show?

Les données confirment-elles son exécution ?

5. What happens when the process fails?

Les exceptions sont-elles détectées, escaladées et corrigées ?

6. Can we prove it?

La piste d’audit est-elle suffisante ?

Si ces six réponses sont cohérentes, le dispositif est probablement robuste.

Si elles divergent, le véritable compliance gap est identifié.

Ce sujet ne concerne pas uniquement Compliance.

Il concerne directement la gouvernance.

Un Board ou un Conducting Officer ne devrait plus uniquement recevoir :

« 98 % des contrôles ont été réalisés. »

Il devrait pouvoir demander :

98 % de quelle population ?

Comment la complétude de cette population a-t-elle été vérifiée ?

Que contiennent les 2 % restants ?

Existe-t-il un risque matériel ?

Depuis combien de temps l’exception existe-t-elle ?

Qui est responsable de sa résolution ?

La même anomalie s’est-elle déjà produite ?

Ces questions transforment un reporting descriptif en véritable outil d’oversight.

Le modèle traditionnel pourrait être résumé ainsi :

Regulation → Policy → Procedure → Control

Le prochain niveau devrait probablement devenir :

Regulation → Policy