Quand 40 % du lot de CTR d'une banque est rejeté : histoire d'un redressement goAML

Scénario composite tiré de déploiements types en Afrique de l'Est. Les informations relatives à l'institution sont anonymisées et les chiffres sont représentatifs, sans pouvoir être attribués à un client en particulier.

Le mois où les déclarations ont cessé de passer

La responsable de la conformité d'une banque commerciale kényane de second rang avait une routine qu'elle n'aimait pas. Le 3 de chaque mois, son équipe exportait dans un tableur les transactions en espèces du mois précédent depuis le système bancaire central (core banking), les nettoyait à la main, lançait une macro qui produisait le XML goAML, puis téléversait le fichier sur le portail du Financial Reporting Centre (FRC).

Puis l'équipe attendait.

Les bons mois, le portail acceptait le lot et l'équipe passait à autre chose. Les mauvais mois — et les mauvais mois devenaient la norme —, le portail renvoyait une erreur de validation citant un élément XSD que personne en interne ne savait interpréter. Un mois, environ 40 % du lot a été rejeté. L'équipe disposait de quatre jours ouvrables pour soumettre à nouveau avant l'échéance déclarative, sans moyen fiable de savoir lesquels, parmi plusieurs milliers d'enregistrements, étaient en cause.

C'est la part de la conformité en matière de lutte contre le blanchiment de capitaux et le financement du terrorisme (LBC/FT) qui figure rarement dans les documents de politique interne. L'obligation est claire. Les contrôles existent. Et pourtant, les déclarations n'arrivent toujours pas à temps.

Ce qui ne fonctionnait pas, en réalité

Lorsque nous avons passé le processus en revue avec l'équipe, les défaillances se sont regroupées autour de quatre causes, dont aucune ne relevait du jugement en matière de conformité :

• Une dérive silencieuse du schéma. La macro avait été écrite pour une version antérieure du XSD goAML. Lorsque le schéma est passé à la v5.0.2, plusieurs éléments facultatifs sont devenus obligatoires et une énumération a changé. Personne n'avait reconstruit la macro.
• Des champs d'identifiant en texte libre. Les types de pièce d'identité des clients étaient saisis de manière incohérente dans le système bancaire central — « National ID », « NATIONAL_ID », « ID Card » — et la couche de mappage les transmettait tels quels.
• Une logique de seuil logée dans un tableur. La détection des transactions en espèces dépendait d'un filtre tenu à jour par un seul analyste. L'agrégation des transactions d'un même client sur une même journée se faisait à l'œil.
• Aucun contrôle préalable. La première fois que quiconque apprenait qu'un fichier n'était pas valide, c'était lorsque le régulateur le signalait.

C'est ce dernier point qui compte. Chacun des autres problèmes était surmontable s'il était détecté avant la transmission. Aucun ne l'était lorsque la boucle de retour passait par le portail du FRC, avec un délai de quatre jours à la clé.

Ce qui a changé

La banque a déployé la solution Déclarations goAML de Creodata sous la forme d'une instance Azure mono-locataire, aux côtés de sa plateforme bancaire centrale existante. Trois choses ont bougé :

Le mappage est sorti des tableurs. Les données de transactions et de clients arrivent par une intégration sécurisée et sont automatiquement mises en correspondance avec le modèle de données goAML. Les types d'identifiant sont normalisés dès l'ingestion au regard des énumérations du schéma : « ID Card » n'atteint donc jamais le générateur XML.

La détection est passée dans la plateforme. Les seuils applicables aux transactions en espècesEN — y compris les règles d'agrégation sur une même journée — sont configurés une fois pour toutes et appliqués de manière cohérente. Les transactions qui atteignent le seuil ressortent automatiquement, au lieu de dépendre du filtre d'un analyste.

La validation est passée avant la transmission. Chaque fichier généré est validé dans la plateforme par rapport au XSD goAML v5.0.2 en vigueur. Les enregistrements en échec sont signalés avec l'élément précis et l'enregistrement précis en cause, dans des termes sur lesquels un analyste conformité peut agir, plusieurs jours avant que le fichier ne s'approche du régulateur.

Le volet STR a été traité séparément. Les déclarations de soupçon sont désormais rédigées dans un espace de travail dédié plutôt que dans Word : l'exposé des faits, les transactions liées et les entités à l'appui restent ainsi ensemble et peuvent être reconstitués ultérieurement.

Le résultat

La première transmission en production est partie six semaines après le lancement. Elle a été acceptée du premier coup, tout comme les suivantes. Le 3 du mois a cessé d'être un événement.

Deux effets secondaires ont compté davantage que l'équipe ne l'avait prévu :

La préparation des contrôles est passée de plusieurs semaines à quelques heures. La plateforme conserve une piste d'audit immuable de ce qui a été déclaré, quand, par qui et sur la base de quels enregistrements sources. Lorsque l'autorité de contrôle a demandé comment une décision de seuil précise avait été prise huit mois plus tôt, la réponse a tenu en une requête plutôt qu'en un chantier d'archéologie.

L'équipe conformité a cessé de faire de la saisie. Les heures auparavant consacrées au rapprochement des exports sont allées à ce pour quoi l'équipe est réellement payée : examiner les alertes et rédiger des exposés de soupçon défendables. Sur un mois type, ce sont plus de 80 heures réorientées de la bataille avec les formats vers l'analyse.

Ce que nous dirions à la prochaine banque

Trois enseignements de cette mission valent au-delà de ce cas.

Les rejets sont un symptôme, pas la maladie. Face à un lot rejeté, les institutions ont tendance à ajouter un relecteur. Cela augmente les coûts et permet de détecter peut-être la moitié des erreurs, car les humains repèrent mal les violations du XSD dans un XML. La solution durable est une machine qui contrôle le fichier au regard du schéma que le régulateur utilise réellement.

Les versions du schéma changent, et personne ne vous envoie de note. Si votre génération XML repose sur une macro, un script ou un module d'éditeur qui n'est pas suivi par rapport au XSD publié, partez du principe qu'elle cessera silencieusement d'être conforme. La validation par rapport au schéma en vigueur est la seule défense fiable.

Le pays compte. Le FRC au KenyaEN, la FIU en TanzanieEN, la FIA en OugandaEN, le FIC au Rwanda et le FIC en ZambieEN ajoutent chacun des exigences locales au socle goAML. Une plateforme qui traite « goAML » comme une cible unique échouera à la frontière. Les institutions présentes dans plusieurs juridictions devraient tester explicitement les règles propres à chaque pays, au lieu de présumer leur portabilité.

La banque de cette histoire déclare désormais dans deux juridictions à partir d'un seul déploiement. La responsable de la conformité n'aime toujours pas le 3 du mois, mais pour des raisons ordinaires.

Pour aller plus loin : Le guide complet des déclarations goAML · Transmission goAML rejetée ? Diagnostiquer et corriger les erreurs courantes

Vos lots goAML sont rejetés, ou vous préparez une première transmission ? Réservez une consultation ou découvrez la solution Déclarations goAML pour voir comment fonctionne la validation par rapport au schéma avant que votre fichier n'atteigne le régulateur.