Concevoir l’architecture des déclarations réglementaires AML à grande échelle

Pourquoi les déclarations AML constituent le problème de données le plus difficile d’une banque

À première vue, la déclaration réglementaire AML ressemble à un problème de données. Un régulateur — FINTRAC au Canada, FinCEN aux États-Unis — vous demande de déclarer certains profils de transactions : télévirements dépassant un seuil (EFTR), opérations en espèces dépassant un seuil (CTR), comportements suspects (STR) et transactions inhabituelles (UTR). Il suffit de prendre les données, de les formater et de les envoyer.

En pratique, la difficulté tient au fait que le régulateur veut un récit reliant les faits : qui est à l’origine des fonds, qui les a reçus, qui contrôle le compte, quel est le niveau KYC des parties, quelle composante de change est passée par quel intermédiaire, quels signaux de cybersécurité ont été déclenchés autour de la session. Ce contexte est dispersé dans des centaines de systèmes sources — systèmes bancaires centraux de détail, marchés de capitaux, prêts commerciaux, virements, change, trésorerie, référentiels clients, systèmes d’identité — chacun avec son propre schéma, son rythme d’actualisation et ses responsables.

Le 2e ensemble réglementaire de FINTRAC l’a rendu explicite : environ 30 cas d’usage distincts, chacun reliant la transaction financière aux données de change, de clients/comptes et de cybersécurité, dans les activités de banque privée, de détail, de marchés de capitaux et commerciales. Sur le plan architectural, ce n’est pas un projet de reporting. C’est une plateforme d’intégration d’entreprise.

L’architecture de référence, de bout en bout

Les plateformes que nous avons conçues pour de grandes banques partagent une structure commune — cinq couches logiques, chacune évolutive et auditable indépendamment :

• Ingestion des sources. Capture des modifications de données issues des systèmes bancaires centraux, des RH Workday, des référentiels clients, des moteurs de change et des signaux de cybersécurité. Certains systèmes publient des événements ; les systèmes historiques exposent des extractions par lots que nous encapsulons dans un chargeur validant le schéma.
• Colonne vertébrale de diffusion. Des flux d’événements de type Kafka transportant les transactions financières, les mises à jour KYC, les correspondances avec les listes de sanctions et les événements du cycle de vie des comptes. Les topics sont partitionnés par client ou par compte afin de préserver l’ordre par entité.
• Liaison et enrichissement. Des traitements de flux relient l’événement de transaction aux données de référence clients, aux hiérarchies de comptes, aux composantes de change, aux profils KYC et à l’historique comportemental. Le résultat est un enregistrement déclarable entièrement relié, structuré selon les exigences du régulateur.
• Détection et règles. Actimize héberge les scénarios de détection AML pour les STR/UTR ; des règles de seuil déterministes et des données de référence pilotent les EFTR/CTR. Le résultat est un flux de déclarations candidates accompagné de leurs justificatifs.
• Transmission et traçabilité. Un service de transmission formate les données EFTR/STR/CTR/UTR selon les schémas de FINTRAC, les signe et les envoie par le canal sécurisé. Chaque enregistrement porte un identifiant de traçabilité remontant à ses événements sources.

La plateforme repose sur Azure — AKS pour les services conteneurisés, PostgreSQL pour le stockage des déclarations réglementaires, Azure Storage pour les événements bruts, et Azure Monitor / Sentinel pour la sécurité et l’observabilité. Lors de déploiements dans les cinq grandes banques canadiennes, nous avons enrichi Actimize sur AKS avec PostgreSQL spécifiquement pour les capacités CTR à grande échelle.

Pourquoi diffuser les événements plutôt que traiter des lots chaque nuit

Historiquement, les déclarations AML reposaient sur un traitement par lots nocturne. Cela fonctionnait lorsque les délais de déclaration se comptaient en jours. Aujourd’hui, les attentes de FINTRAC — et, franchement, l’appétence au risque de la banque elle-même — se rapprochent bien davantage du temps quasi réel. Les EFTR doivent être déclenchées de manière fiable, quel que soit le moment du règlement du virement sous-jacent. Les STR gagnent à associer des signaux comportementaux en direct à la transaction.

La diffusion d’événements nous apporte trois choses impossibles avec les lots. Premièrement, une ingestion tenant compte de la contre-pression : une source amont lente ne fait pas tomber la chaîne de déclaration réglementaire. Deuxièmement, la relecture : lorsqu’une règle change, nous pouvons retraiter la fenêtre concernée sans toucher aux systèmes sources. Troisièmement, l’ordre par entité : en partitionnant par client ou par compte, nous garantissons qu’une modification de transaction est traitée après l’original, même lorsque dix mille événements par seconde transitent.

Côté coûts, AKS nous fournit une puissance de calcul élastique qui s’adapte au volume — les pics de fin de mois, de fin d’année et de volatilité des changes n’exigent pas une capacité provisionnée en permanence.

La modélisation des menaces comme livrable architectural à part entière

La déclaration AML évolue dans un environnement hostile. Des acteurs malveillants cherchent activement à rester sous les seuils, à fractionner les transactions ou à corrompre les données KYC. Une bonne plateforme AML ne se contente pas d’être conforme — elle tient compte des adversaires.

Chaque architecture que nous livrons dans ce domaine s’accompagne d’un modèle de menaces explicite : STRIDE à chaque frontière de composant, classification des données pour chaque stockage et identité à privilèges minimaux pour les appels entre services. Les secrets résident dans Azure Key Vault ; les identités de service utilisent des identités managées, pas des identifiants statiques. Les données sensibles — documents KYC, renseignements personnels des clients — sont chiffrées par enveloppe avec des clés propres au secteur d’activité.

Du côté de la transmission réglementaire, chaque charge utile est signée et la clé de signature est protégée par du matériel. Ainsi, une déclaration altérée ou rejouée est détectable aussi bien par FINTRAC que par notre propre chaîne d’audit.

KYC et intégration des entreprises de services monétaires

Les déclarations AML se situent en aval du KYC. Si le KYC est erroné, les déclarations le sont aussi. L’un des volets tactiques les plus intéressants sur lesquels nous avons travaillé est le parcours d’intégration des entreprises de services monétaires (MSB) — une catégorie de clients présentant un risque élevé avéré et pour laquelle les exigences de diligence raisonnable KYC sont importantes.

Le modèle architectural : une chaîne de filtrage qui intègre les inscriptions des MSB, les listes de sanctions et les données de propriété effective dans un graphe d’enrichissement client ; une interface tactique de gestion des dossiers pour l’équipe d’enquête AML ; et une piste d’audit reliant chaque décision d’intégration aux éléments qui la justifient. La solution tactique fait gagner du temps pendant que le référentiel client stratégique se met à niveau — mais ses résultats ont la même structure, de sorte que la plateforme stratégique récupère les données sans reprise.

Enseignements tirés de la mise en œuvre dans deux grandes banques

• Traitez le schéma du régulateur comme un contrat. Concevez en fonction de celui-ci dès le premier jour. Ne laissez pas les structures de données internes se propager dans la couche de transmission.
• Le travail réside dans les liens. Les règles EFTR/STR sont la partie facile. Relier correctement 30 cas d’usage de données clients, comptes, change et cybersécurité absorbe 80% de l’ingénierie.
• La traçabilité est indispensable. Lorsqu’un régulateur remet une déclaration en question, vous devez pouvoir montrer chaque événement qui y a contribué en quelques minutes — pas en quelques jours.
• L’approbation du comité de revue d’architecture n’est pas une simple formalité. Utilisez-la comme levier de rigueur. Les revues auxquelles nous avons participé ont révélé des problèmes de résidence des données et de gestion des clés qui auraient été très coûteux à corriger par la suite.
• Natif du cloud ≠ exclusivement dans le cloud. Certains systèmes amont resteront sur site pendant des années. L’architecture doit tenir compte avec réalisme de l’intégration hybride.

Votre banque ou fintech en a besoin ?

SEYSO a conçu des plateformes AML et de déclaration réglementaire pour plusieurs grandes banques canadiennes et américaines — couvrant les obligations LCTR, EFTR, STR, UTR, CTR, KYC et CFT. Si vous modernisez vos technologies de lutte contre la criminalité financière, migrez Actimize ou définissez un nouveau programme réglementaire, parlons-en. Apportez vos obligations réglementaires et la complexité de vos systèmes sources ; nous apporterons l’architecture.