Surveillance des transactions en temps réel ou par lots : choisir la bonne architecture

La question fondamentale de l’architecture

Lors de la conception d’un système de surveillance des transactions anti-blanchiment d’argent, l’une des décisions architecturales les plus critiques est de savoir si les transactions doivent être traitées en temps réel ou par lots. Ce choix se répercute sur tous les aspects de votre système : coûts d’infrastructure, capacités de détection, flux de travail opérationnels et conformité réglementaire.

L'approche traditionnelle repose sur le traitement par lots : collecter les transactions tout au long de la journée, exécuter des algorithmes de détection pendant la nuit et présenter des alertes aux analystes le lendemain matin. Mais à mesure que la technologie a évolué et que les systèmes de blanchiment d’argent sont devenus plus sophistiqués, la surveillance en temps réel est devenue de plus en plus attrayante. La question n'est plus de savoir si une surveillance en temps réel est possible, mais si elle constitue le bon choix pour vos besoins spécifiques.

Comprendre le traitement par lots

Le traitement par lots analyse les transactions en groupes à intervalles planifiés, généralement quotidiennement, mais parfois toutes les heures ou toutes les semaines selon le scénario. Cette approche domine les systèmes AML depuis des décennies, et pour de bonnes raisons :

Avantages du traitement par lots

• Accès complet aux données :Les systèmes par lots peuvent analyser ensemble les transactions d'une journée entière, détectant les modèles qui émergent dans l'ensemble des données. Les schémas structurants qui impliquent plusieurs transactions tout au long de la journée deviennent évidents lorsque vous voyez l'image complète.
• Efficacité informatique :Le traitement en masse permet des techniques d'optimisation telles que la vectorisation et le traitement parallèle sur des ensembles de données entiers. Vous pouvez exécuter des modèles d'apprentissage automatique coûteux qui seraient trop lents pour le traitement par transaction
• Prévisibilité des ressources :Les coûts d'infrastructure sont prévisibles car vous savez exactement quand le traitement aura lieu. Vous pouvez augmenter les ressources de calcul en dehors des heures d'ouverture, lorsque les coûts du cloud sont inférieurs
• Architecture plus simple :Les systèmes par lots sont conceptuellement plus simples à créer et à maintenir. Il n'est pas nécessaire d'avoir une infrastructure de streaming complexe, une gestion d'état ou des garanties de traitement unique.
• Tests plus faciles :Les travaux par lots sont déterministes et reproductibles. Vous pouvez réexécuter le lot d'hier avec des règles modifiées pour tester les modifications avant de les déployer en production.

Inconvénients du traitement par lots

• Latence de détection :Par définition, le traitement par lots introduit du retard. Une transaction suspecte à 9 heures du matin ne générera une alerte que le lendemain, donnant ainsi aux criminels une longueur d'avance de plus de 24 heures.
• Capacité d’intervention limitée :Vous ne pouvez pas arrêter une transaction suspecte si vous n’en êtes informé qu’une fois qu’elle est terminée. Pour les scénarios à haut risque, ce délai peut être inacceptable
• Contraintes de la fenêtre de lot :Tous les traitements doivent être terminés dans la fenêtre de lot. À mesure que les volumes de transactions augmentent, vous pourriez avoir du mal à terminer le traitement avant l'arrivée du prochain lot.
• Pics de ressources :Les tâches par lots créent une charge d'infrastructure importante pendant les fenêtres de traitement, nécessitant un surprovisionnement pour gérer la capacité maximale qui reste inactive la plupart du temps.

Comprendre le traitement en temps réel

Le traitement en temps réel (ou quasi-réel) analyse chaque transaction au fur et à mesure qu'elle se produit, générant des alertes en quelques secondes ou minutes. Cette approche nécessite une architecture fondamentalement différente mais offre des fonctionnalités uniques :

Avantages du traitement en temps réel

• Détection immédiate :Les activités suspectes sont identifiées en quelques secondes, permettant une réponse rapide. Pour des scénarios tels que le piratage de compte ou la détection de compte mule, cette vitesse est cruciale
• Intervention transactionnelle :Les systèmes en temps réel peuvent bloquer ou retarder les transactions avant qu'elles ne soient terminées, empêchant ainsi la fraude et le blanchiment d'argent plutôt que de simplement les détecter après coup.
• Utilisation continue des ressources :Les ressources de calcul sont utilisées de manière fluide tout au long de la journée plutôt que de croître pendant les fenêtres de traitement par lots. Cela peut être plus rentable à grande échelle
• Meilleure expérience client :Pour les transactions légitimes incorrectement signalées (faux positifs), les systèmes en temps réel peuvent fournir un retour d'information immédiat, permettant une résolution rapide plutôt que de surprendre les clients quelques jours plus tard.
• Détection de modèle incrémentielle :Certains modèles sont plus faciles à détecter en temps réel. Par exemple, les contrôles de vélocité (« trop de transactions au cours de la dernière heure ») sont naturels dans les architectures de streaming.

Inconvénients du traitement en temps réel

• Complexité architecturale :Les systèmes en temps réel nécessitent une infrastructure de streaming sophistiquée (Kafka, Flink, Kinesis), une gestion de l'état et une gestion minutieuse des événements dans le désordre.
• Fenêtre contextuelle limitée :Lors du traitement de la transaction N, vous ne pouvez pas voir la transaction N+1 qui se produit cinq minutes plus tard. Certains modèles évidents dans les lots deviennent plus difficiles à détecter dans les flux
• Contraintes informatiques :Chaque modèle doit être exécuté dans les limites de votre SLA de latence (généralement < 100 ms pour le traitement en ligne). Les modèles complexes d'apprentissage automatique peuvent être trop lents pour une exécution par transaction
• Coûts d’infrastructure plus élevés :Les systèmes en temps réel doivent répondre aux pics de transactions 24 heures sur 24 et 7 jours sur 7, ce qui pourrait augmenter considérablement les coûts d'infrastructure.
• Complexité avec état :Maintenir l’état sur les systèmes de streaming distribués est un défi. Des fonctionnalités telles que « nombre de transactions cette semaine » nécessitent une gestion minutieuse de l'état et un fenêtrage

// Exemple : vérification de la vitesse en temps réel dans une architecture de streaming
// Utilisation du traitement de style Apache Flink

flux
  .keyBy(txn => txn.accountId)
  .window(TumblingEventTimeWindows.of(Time.hours(1)))
  .aggregate (nouveau VelocityAggregator())
  .filter(velocity => Velocity.count > seuil)
  .map (créer une alerte)
  .addSink(alerteSink);

// La même logique en batch :
SÉLECTIONNER 
  identifiant_compte,
  COUNT(*) comme txn_count,
  SOMME (montant) comme total_amount
DE transactions
OÙ horodatage >= MAINTENANT() - INTERVALLE '1 heure'
GROUPE PAR id_compte
HAVING COUNT(*) > seuil ;

Architectures hybrides : le meilleur des deux mondes

En pratique, les systèmes AML les plus sophistiqués utilisent une approche hybride, combinant un traitement en temps réel et par lots en fonction des exigences du scénario. Cette architecture à plusieurs niveaux traite les transactions à travers plusieurs couches :

Cette approche à plusieurs niveaux vous permet d'appliquer le bon modèle de traitement à chaque scénario. Les scénarios à haut risque qui bénéficient d’une intervention immédiate bénéficient d’un traitement en temps réel, tandis que la détection de modèles complexes nécessitant un contexte complet s’exécute par lots. La plupart des transactions transitent par les trois niveaux, chaque couche ajoutant progressivement une analyse plus sophistiquée.

Cadre décisionnel : quand utiliser chaque approche

Choisir entre le traitement en temps réel et le traitement par lots nécessite d'analyser vos besoins spécifiques sur plusieurs dimensions :

Utilisez le traitement en temps réel lorsque :

• L’intervention est précieuse :Si le blocage ou le retardement des transactions suspectes apporte une valeur significative, le temps réel est essentiel. Cela inclut la prévention de la fraude, le respect des sanctions et la surveillance des clients à haut risque.
• La vitesse compte sur le plan opérationnel :Lorsque les analystes doivent enquêter et résoudre des alertes alors que les clients sont toujours en contact (par exemple, dans une succursale ou au téléphone), le traitement en temps réel permet d'améliorer le service client.
• Exigences réglementaires :Certaines juridictions ou scénarios imposent des contrôles en temps réel, notamment pour le contrôle des sanctions et la prévention du financement du terrorisme.
• La logique de détection est simple :Si vos règles et modèles peuvent s'exécuter en moins de 100 ms, le traitement en temps réel est réalisable sans optimisation poussée.
• Modèles par transaction :Lorsque des anomalies sont détectables dans des transactions individuelles ou dans un historique très récent (vitesse, géolocalisation, empreinte digitale de l'appareil)

Utilisez le traitement par lots lorsque :

• Le contexte nécessite un ensemble de données complet :La détection de structurations, de superpositions ou d'autres schémas complexes nécessite souvent d'examiner les transactions d'une journée ou d'une semaine entière pour identifier le modèle.
• Intensif en calcul :Les modèles d'apprentissage profond, les réseaux neuronaux graphiques ou l'analyse complète du réseau peuvent nécessiter des secondes ou des minutes par transaction, ce qui est acceptable par lots mais impossible en temps réel.
• Analyse rétroactive :Les rapports réglementaires, l'analyse des tendances et la formation de modèles s'adaptent naturellement au traitement par lots puisqu'ils analysent les données historiques.
• Contraintes de coûts :Lorsque le budget d'infrastructure est limité, le traitement par lots offre une plus grande capacité de détection par dollar dépensé
• Aucune intervention n’est nécessaire :Pour de nombreux scénarios AML, un délai de détection de 24 heures est acceptable, car vous documentez les modèles de dépôt SAR, sans empêcher les transactions.

Considérations techniques de mise en œuvre

La mise en œuvre réussie de l’une ou l’autre architecture nécessite une attention particulière aux détails techniques qui ont un impact significatif sur les performances et la fiabilité :

Défis de mise en œuvre en temps réel

La mise en place d'une surveillance AML en temps réel de niveau production implique de résoudre plusieurs défis techniques qui n'existent pas dans les systèmes par lots :

• Gestion de l'État :Les systèmes de streaming doivent maintenir l’état (soldes des comptes, nombre de transactions, modèles historiques) sur tous les travailleurs distribués. Cela nécessite une utilisation prudente des magasins d'état, des fenêtrages et des filigranes.
• Traitement exactement une fois :Éviter les alertes en double lorsque les systèmes tombent en panne et redémarrent nécessite un traitement idempotent et une gestion minutieuse des transactions.
• Données arrivant tardivement :Les transactions peuvent arriver dans le désordre ou en retard. Votre stratégie de fenêtrage doit gérer cela avec élégance sans créer de lacunes dans la détection
• Gestion de la contre-pression :Lorsque les systèmes en aval ralentissent, le pipeline de streaming doit gérer la contre-pression sans abandonner les transactions ni créer une croissance illimitée de la mémoire.
• Déploiement du modèle :La mise à jour des modèles ML dans un système de streaming en cours d'exécution sans temps d'arrêt ni traitement dupliqué nécessite des stratégies de déploiement sophistiquées

Défis de mise en œuvre par lots

Bien que conceptuellement plus simples, les systèmes batch ont leurs propres complexités techniques :

• Gestion des fenêtres de lots :À mesure que les volumes de données augmentent, il devient difficile d'effectuer le traitement dans les fenêtres disponibles. Les stratégies incluent le traitement incrémentiel, le partitionnement des données et l'optimisation progressive
• Gestion des dépendances :Les tâches par lots dépendent souvent de plusieurs sources de données en amont. L'orchestration de ces dépendances et la gestion des échecs nécessitent des outils comme Airflow ou Dagster
• Retraitement:Lorsque vous découvrez des problèmes dans le traitement de l'historique, le retraitement efficace de grandes plages de dates nécessite une architecture minutieuse pour les mises à jour incrémentielles.
• Fraîcheur des données :S'assurer que toutes les données requises sont arrivées avant de commencer le traitement par lots nécessite une coordination minutieuse, en particulier entre les fuseaux horaires.

Analyse des performances et des coûts

Les caractéristiques de performances et de coûts du traitement en temps réel par rapport au traitement par lots diffèrent considérablement, et le choix optimal dépend fortement du volume et des modèles de transactions :

Répartition des coûts : traitement par lots

Pour une institution financière traitant 10 millions de transactions par jour avec une surveillance AML par lots :

• Calcul : 3 000 $/mois (faites tourner un grand cluster pendant 4 heures par nuit)
• Stockage : 800 $/mois (historique des transactions de 90 jours, historique des alertes d'un an)
• Orchestration : 200 $/mois (service géré Airflow)
• Total : ~ 4 000 $/mois ou 0,012 $ pour 1 000 transactions

Répartition des coûts : traitement en temps réel

Pour le même établissement avec suivi en temps réel :

• Infrastructure de streaming : 8 000 $/mois (Kafka ou Kinesis à grande échelle)
• Traitement de flux : 5 000 $/mois (cluster Flink, toujours actif)
• State Store : 2 500 $/mois (Redis ou DynamoDB pour l'état en temps réel)
• Service de modèles : 3 500 $/mois (infrastructure d'inférence à faible latence)
• Total : ~19 000 $/mois ou 0,057 $ pour 1 000 transactions

La différence de coût de 4 à 5 fois est typique, mais la proposition de valeur dépend entièrement de ce que permet cette capacité en temps réel. Si l’on bloque 10 millions de dollars de transactions frauduleuses par mois, le retour sur investissement est évident. Si vous déplacez simplement la génération d'alertes de 24 heures à 5 minutes sans impact opérationnel, cela n'est peut-être pas justifié.

Considérations réglementaires et de conformité

Différents régimes réglementaires ont des attentes différentes en matière de latence de surveillance AML, ce qui peut influencer vos choix architecturaux :

Contrôle des sanctions

La plupart des juridictions exigent un contrôle des sanctions en temps réel avant la fin des transactions. Ceci n'est généralement pas négociable et doit faire partie de votre traitement en ligne. Cependant, l’examen complet des sanctions peut souvent être divisé :

• En ligne : correspondances de noms exactes et correspondances floues de haute confiance (< 100 ms)
• Temps quasi réel : correspondance floue complète, algorithmes phonétiques (1 à 5 minutes)
• Lot : Détection des sanctions basées sur le réseau, analyse des bénéficiaires effectifs (quotidiennement)

Détection d'activités suspectes

Pour la surveillance générale de la LBC, les régulateurs s'attendent généralement à une détection « opportune » plutôt qu'en temps réel. Ce qui constitue « en temps opportun » varie selon la juridiction et le profil de risque :

• Clients à haut risque : surveillance en temps quasi réel ou quotidienne attendue
• Clients à risque moyen : surveillance quotidienne à hebdomadaire acceptable
• Clients à faible risque : un suivi hebdomadaire à mensuel est souvent suffisant

Cette approche basée sur les risques permet une architecture à plusieurs niveaux dans laquelle les scénarios à haut risque sont traités en temps réel tandis que les scénarios à faible risque utilisent un traitement par lots, optimisant à la fois la conformité et les coûts.

Stratégies migratoires

De nombreuses institutions envisagent de migrer du traitement par lots vers le traitement en temps réel, ou de mettre en œuvre des architectures hybrides. Basé sur notre expérience en aidant des dizaines d'institutions financières dans cette transition, voici une voie de migration éprouvée :

Phase 1 : Établir une infrastructure de streaming (3 à 6 mois)

• Déployer une plateforme de streaming (Kafka, Kinesis, Pulsar)
• Implémenter l’ingestion de transactions dans l’infrastructure de streaming
• Créer des runbooks de surveillance, d'alerte et opérationnels
• Former l’équipe des opérations aux opérations de streaming
• Exécuté en parallèle avec le système batch existant (ne changez pas encore)

Phase 2 : implémentation du mode Shadow (2 à 4 mois)

• Implémenter les scénarios sélectionnés dans le traitement en temps réel
• Générer des alertes mais ne pas les envoyer aux analystes (mode shadow)
• Comparez les alertes en temps réel avec les alertes par lots pour les mêmes scénarios
• Ajustez pour atteindre la parité ou mieux avec les performances par lots
• Valider la latence, la précision et les caractéristiques opérationnelles

Phase 3 : basculement progressif (3 à 6 mois)

• Déplacer le premier scénario vers le traitement en temps réel de la production
• Surveillez attentivement les problèmes, en conservant le lot comme sauvegarde
• Migrer progressivement des scénarios supplémentaires
• Continuez le traitement par lots pour une couverture complète
• Documenter les apprentissages et affiner l’approche de manière itérative

Phase 4 : Optimisation et amélioration (en cours)

• Optimiser les performances et réduire les coûts
• Ajoutez des scénarios de détection sophistiqués en temps réel
• Mettre en œuvre des capacités d’intervention
• Améliorez-vous grâce aux mises à jour du modèle ML en temps réel
• Poursuivre le traitement par lots pour les analyses complexes

Étude de cas : Migration des grandes banques européennes

Une grande banque européenne avec 15 millions de clients et 50 millions de transactions mensuelles a migré avec succès d'une architecture pure batch vers une architecture hybride en 18 mois :

• Point de départ:Traitement par lots quotidien avec une latence d'alerte de 24 à 36 heures, un taux d'alerte de 3,2 %, un taux de vrais positifs de 8 %
• Phase 1 :Mise en œuvre d'un filtrage des sanctions et de contrôles de vélocité en temps réel (6 mois)
• Phase 2 :Ajout de modèles ML en temps quasi réel pour la prise de contrôle de compte et la détection de mules (6 mois)
• Phase 3 :Traitement par lots maintenu pour la détection de modèles complexes, amélioré avec des réseaux de neurones graphiques (6 mois)
• Résultats:Latence moyenne des alertes réduite à 4 heures, taux d'alerte réduit à 1,8 %, taux de vrais positifs amélioré à 15 %, blocage de 45 millions d'euros de fraude au cours de la première année

L'approche hybride s'est avérée optimale : traitement en temps réel pour les scénarios dans lesquels l'intervention a de la valeur, traitement par lots pour une détection complète des modèles qui nécessite un contexte complet.

Tendances futures : convergence et évolution

L’avenir des architectures de surveillance AML est de plus en plus sophistiqué, avec plusieurs tendances émergentes :

• Micro-loting :Le traitement de petits lots toutes les quelques minutes combine les avantages des deux approches : une latence en temps quasi réel avec un contexte complet de type batch.
• Traitement adaptatif :Systèmes qui choisissent dynamiquement une stratégie de traitement en fonction du score de risque de transaction, en utilisant le temps réel pour les risques élevés et le traitement par lots pour les risques faibles.
• Apprentissage continu :Modèles ML qui se mettent à jour progressivement à partir des données en streaming plutôt que de nécessiter un recyclage par lots, permettant une adaptation plus rapide aux nouveaux modèles
• Streaming/lot unifié :Des frameworks comme Apache Beam qui permettent d'écrire une seule fois la logique de traitement et de la déployer sur des moteurs de streaming ou par lots
• Traitement des bords :Déplacement d'une certaine logique de détection au point d'origine de la transaction pour une intervention à très faible latence

Conclusion : ce n'est pas l'un ou l'autre

La question du temps réel ou du traitement par lots n’est pas binaire. Les systèmes AML les plus efficaces utilisent les deux approches de manière stratégique, en appliquant un traitement en temps réel lorsque ses capacités fournissent une valeur claire et un traitement par lots où une analyse complète nécessite un contexte complet.

Votre décision doit être motivée par une évaluation lucide de vos besoins : où la vitesse de détection est-elle importante ? Où l’intervention est-elle utile ? Quelles sont vos contraintes de calcul et de coûts ? Quelles sont les exigences de votre environnement réglementaire ? La réponse sera différente pour chaque institution et chaque scénario au sein de cette institution.

Chez nerous.ai, notre plateforme prend en charge nativement le traitement en temps réel et par lots, permettant aux institutions de choisir la bonne approche pour chaque scénario sans être enfermées dans un seul modèle architectural. Cette flexibilité est cruciale à mesure que les dispositifs de blanchiment d’argent évoluent et que les exigences institutionnelles évoluent au fil du temps.

La meilleure architecture n'est pas la plus avancée ou la plus coûteuse : c'est celle qui s'aligne le mieux avec vos exigences opérationnelles, réglementaires et commerciales spécifiques tout en restant durable et évolutive à mesure que votre institution se développe.