Apprentissage fédéré en finance

Dans un dispositif courant, chaque établissement part du même modèle et l'entraîne sur ses enregistrements locaux. Un agrégateur combine les mises à jour obtenues pour produire une nouvelle version du modèle commun. Federated Averaging combine les mises à jour sur plusieurs cycles d'entraînement, les paramètres du modèle évoluant pendant l'entraînement.

Pour une banque, le jeu local peut contenir des attributs transactionnels et des résultats de fraude examinés. Un modèle commun pourrait apprendre des établissements participants sans nécessiter une copie centrale unique de ces données brutes. La collaboration nécessite toujours une finalité définie et des règles cohérentes pour préparer les données d'entraînement.

L'apprentissage fédéré horizontal utilise des informations de structure similaire sur des enregistrements différents détenus par les participants. Les banques peuvent détenir les mêmes champs transactionnels pour des populations distinctes de clients. Des définitions communes permettent aux établissements d'entraîner des modèles locaux comparables avant de combiner les mises à jour.

L'apprentissage fédéré vertical utilise des informations différentes sur des personnes ou entités communes aux participants. Une collaboration financière doit alors établir quels enregistrements correspondent sans exposer des informations identifiantes inutiles. Les dispositifs mixtes combinent ces schémas et nécessitent une évaluation adaptée du processus d'alignement.

Le BIS Innovation Hub a testé des méthodes collaboratives de détection du blanchiment dans Project Aurora. Project Aurora a utilisé des données de paiement synthétiques pour comparer les approches de surveillance entre établissements et au-delà des frontières. Project Aurora était une preuve de concept combinant apprentissage automatique, analyse de réseaux et technologies de protection de la confidentialité.

Project Aurora a testé un entraînement fédéré avec des données locales pour examiner la souveraineté des données au sein de la collaboration. Ces résultats expérimentaux n'établissent pas les performances en production pour une banque donnée. L'analyse de réseaux LCB-FT examine les relations financières, tandis que l'apprentissage fédéré décrit l'entraînement entre participants sur des données distribuées.

Les gradients du modèle peuvent révéler des informations sur les enregistrements d'entraînement, même lorsque les données brutes des clients restent locales. Un gradient mesure comment l'erreur du modèle varie lorsque ses paramètres changent. Les participants doivent évaluer les informations visibles par l'agrégateur et les autres parties dans leur dispositif réel.

Les questions pertinentes concernent les destinataires des mises à jour individuelles et les utilisateurs pouvant interroger le modèle obtenu. L'accès aux versions successives du modèle peut aussi entrer dans l'évaluation de confidentialité. Un consortium devrait documenter les adversaires supposés avant de choisir les protections de ses données financières.

L'agrégation sécurisée peut masquer les mises à jour individuelles à l'agrégateur tout en permettant de calculer un résultat agrégé. La protection dépend du protocole choisi et de ses hypothèses sur les parties participantes. Les équipes devraient examiner la collusion et les déconnexions de participants pour évaluer ces hypothèses dans leur collaboration.

La confidentialité différentielle ajoute un aléa contrôlé pendant l'entraînement pour limiter les déductions sur les contributions individuelles. Le paramétrage de confidentialité peut modifier l'utilité du modèle financier obtenu. Les entraînements répétés et les publications de modèles nécessitent une comptabilité documentée de confidentialité et une évaluation de la qualité de détection.

Les banques participantes peuvent différer par leurs populations de clients, leurs historiques disponibles et l'étiquetage des cas confirmés. Un modèle améliorant un score global peut néanmoins être peu performant pour un établissement. L'évaluation devrait comparer les références locales au modèle commun sur des cas et périodes exclus de l'entraînement.

Le processus de validation des modèles bancaires peut examiner la qualité de détection avec la charge de travail créée pour les analystes. Les équipes devraient examiner les cas manqués et les conséquences de transactions signalées à tort. Les définitions des données, versions des modèles et résultats d'évaluation nécessitent des responsables identifiés pendant toute la collaboration.

Un pilote proposé peut commencer par une question de criminalité financière et un groupe limité d'établissements. Les participants peuvent définir les données d'entraînement autorisées et des critères d'acceptation mesurables avant d'échanger des mises à jour. Les tests devraient inclure un participant déconnecté et une mise à jour échouant aux contrôles de qualité convenus.

Le pilote nécessite aussi une décision sur l'accès au modèle après l'entraînement et le traitement des corrections ultérieures. Chaque banque devrait établir comment un résultat du modèle entre dans son processus d'investigation existant. Une décision d'utilisation en production nécessite des preuves issues de ce contexte opérationnel.