1. La fraude, il faut en convenir, a quelque chose à voir avec l’intelligence humaine1. Quand bien même emprunte-t-elle, par principe, un dessein négatif, avec une visée assurément délictuelle, elle repose sur un comportement astucieux, au moins de la part de celui qui la conçoit et au détriment du malheureux qui la subit. Et du reste, lorsque l’on s’intéresse au thème de la fraude aux opérations de paiement, l’on est très rapidement saisi par l’ampleur des procédés mis en œuvre et l’on se trouve confronté à une panoplie variée, parfois ésotérique, de situations. L’imagination débordante des fraudeurs est impressionnante : fraude aux investissements atypiques2, fraude au président, fraude opérée par substitution de RIB, fraude aux sentiments3, fraude au faux conseiller4. Tout cela est parfois très rudimentaire, parfois, au contraire, particulièrement élaboré. Quoi qu’il en soit, nombreuses sont les émotions, tout comme les comportements sollicités ; les techniques sont légion. Spoofing5 et phishing6 sont aussi bien connus. En bref, tout cela fait preuve d’une grande sophistication et ce panorama, qui ne trouve, semble-t-il, pas de limites, renforce cette impression que, là aussi, le droit court après le fait et qu’il doit sans cesse s’adapter à l’inventivité des fraudeurs.
2. Intelligence humaine : c’est de cette dimension dont il est habituellement question. Mais qu’en est-il lorsque l’on entend confronter ce domaine – la fraude aux opérations de paiement – à l’intelligence artificielle (IA) ? La banque n’échappe pas, bien évidemment, à la diffusion massive des systèmes d’IA, dont chacun sait que le principe est, pour l’essentiel, de répliquer informatiquement les principales facultés cognitives, dont celles de raisonner et de prendre des décisions. Et la confrontation des deux éléments – IA et fraude aux opérations de paiement – peut se concevoir selon deux approches. Dans une première perspective, l’IA est susceptible d’amplifier certains risques dans le domaine de la fraude aux opérations de paiement. L’incroyable sophistication des modèles d’IA, entraînés par de puissants algorithmes d’apprentissage automatique (machine learning), permet de maximaliser les effets de certaines fraudes, qu’il s’agisse d’IA plus classiques ou de grands modèles de langage. En vérité, avec des modèles d’IA générative élaborés, il est sans doute possible de frauder plus efficacement7. La reconstitution de la voix, notamment pour permettre à la fraude par téléphone de prospérer8, offre des ressources insoupçonnées. On sait désormais que la cybercriminalité s’accommode très bien des solutions technologiques et prend rapidement en compte les dernières avancées. Cela étant, cette approche ressort plutôt de la technique informatique et non de l’analyse juridique. Il est néanmoins essentiel, pour le régulateur, de comprendre quelles sont les évolutions des fraudeurs pour tenter d’offrir une réponse adéquate, en termes de répression. Aussi n’est-il guère étonnant que l’ACPR adapte ses méthodes9.
3. Dans une seconde perspective, qui se place tout à l’inverse de la première, il faut considérer que l’IA offre d’intéressantes potentialités dans la lutte contre la fraude aux opérations de paiement. L’IA est un élément central de cette lutte et devrait probablement, à l’avenir, se révéler l’instrument le plus important. Là aussi, il faut former le vœu que les évolutions technologiques permettront de déceler, de manière plus fine, les comportements frauduleux, et en amont, les opérations suspectes. Logiciel contre logiciel, algorithme contre algorithme, le premier traquant l’autre, sans doute s’agit-il là d’une partie du futur qui se dessine. Quoi qu’il en soit, les modèles d’IA permettant la surveillance, souvent en temps réel, des transactions sont, d’une part, prometteurs, mais il est surtout frappant de voir qu’ils sont devenus, d’autre part, indispensables pour les établissements bancaires (1.). Dans ces conditions, quand bien même une telle utilisation intervient au bénéfice du client, étant donné que la détection permettra dans le meilleur des cas d’empêcher la transaction, se pose la question de la conformité de ces dispositifs qui ont tendance à se généraliser (2.).
4. Aujourd’hui, compte tenu du développement exponentiel des différents types de fraudes, les prestataires de services de paiement sont dans l’obligation de développer, en interne, des solutions leur permettant de détecter, en temps réel, les opérations suspectes. Citons ici un extrait du rapport pour l’année 2023 de l’Observatoire de la sécurité des moyens de paiement qui met parfaitement en lumière cette exigence : « Sous l’impulsion des paiements SEPA, les PSP ont tous mis en œuvre des outils permettant de détecter les opérations de virement suspectes et de générer des alertes. Ces outils appliquent un score à chaque opération en se fondant sur des règles basées sur l’expérience métier, l’analyse des données de connexion et l’appareil utilisé. C’est également un domaine d’application important pour l’IA. Les établissements implémentent des moteurs de machine learning – dits “semi-supervisés” – dont le rôle est de déduire eux-mêmes les critères permettant de détecter une opération suspecte »10. Ces réflexions peuvent s’appliquer, plus généralement, aux opérations de paiement.
5. Ces modèles de détection sont nécessaires pour au moins deux séries de raisons. En premier lieu, le banquier voit régulièrement sa responsabilité engagée par les victimes d’escroquerie, avec plus ou moins de succès. L’on se souvient, par exemple, de l’arrêt rendu, par la Cour de cassation, le 23 octobre 202411, lequel doit toutefois être replacé dans son contexte12. Dans cette affaire, la Cour de cassation a confirmé la décision d’une cour d’appel, qui dans le cas d’un spoofing téléphonique, par le biais d’un faux conseiller, avait considéré que la négligence grave du client n’était pas caractérisée. Mais quoi qu’il en soit de la position de la jurisprudence qui, par principe, est évolutive, le prestataire de services de paiement est plutôt enclin à se prémunir en amont et à tenter d’empêcher la réalisation de l’opération de paiement possiblement frauduleuse. Dans ce cas, la question de sa responsabilité n’aura pas besoin de se poser. C’est d’ailleurs ce qu’a très bien compris le législateur européen, notamment dans la proposition de Règlement du Parlement européen et du Conseil concernant les services de paiement dans le marché intérieur et modifiant le Règlement (UE) n° 1093/2010. À la proposition de considérant n° 100, il est très clairement exprimé que « la détection en temps utile des opérations de paiement frauduleuses est essentielle et le contrôle des opérations joue un rôle important dans cette détection. Il convient donc d’exiger des PSP qu’ils disposent de mécanisme de contrôle des opérations à la hauteur de la contribution essentielle que ces mécanismes apportent à la prévention de la fraude ». Et le projet d’article 83 précise bien que « les prestataires de services de paiement mettent en place des mécanismes de contrôle des opérations qui (...) c) permettent aux prestataires de services de paiement de prévenir et de détecter les opérations de paiement potentiellement frauduleuses (...) ». Or, compte tenu des avancées récentes, ces mécanismes de contrôle reposent sur des systèmes d’IA. Ce type de mécanisme ex-ante est l’un des seuls moyens véritablement efficaces à la disposition des établissements de crédit prestataires de services de paiement pour atténuer l’ampleur de leur responsabilité en évitant que l’opération frauduleuse ne survienne. Cela étant, comme le souligne l’Observatoire, le compromis n’est pas simple à trouver. En effet, « la complexité de maintenance de ces outils réside dans le fait que l’évolution permanente des techniques de fraude est concomitante avec celle des usages légitimes des clients. Il s’agit donc d’un équilibre à trouver entre détecter le maximum de fraudes possibles et minimiser la gêne du client en limitant les rejets à tort »13.
6. En second lieu, un autre élément conforte l’idée d’un recours indispensable aux modèles de détection en temps réel des fraudes aux opérations de paiement : il s’agit de la dérogation au principe de l’authentification forte que permet l’article 18 du Règlement délégué du 27 novembre 201714. Tout d’abord, l’article 2 de ce texte impose au PSP de mettre en place des mécanismes de contrôle des opérations qui leur permettent de déceler les opérations de paiement non autorisées ou frauduleuses, lesdits mécanismes étant fondés sur l’analyse d’opérations de paiement tenant compte d’éléments qui sont propres à l’utilisateur de services de paiement dans des conditions d’utilisation normale des données de sécurité personnalisées. Ensuite, selon l’article 18 du règlement délégué, dont les prestataires de services de paiement font un large usage, ceux-ci ont la possibilité de ne pas appliquer l’authentification forte du client, en principe requise par la directive DSP 2, quand le payeur initie une opération de paiement électronique que le prestataire considère comme présentant un faible niveau de risque. Or, selon cette disposition, une opération de paiement électronique est considérée comme présentant un faible niveau de risque, conformément aux mécanismes de contrôle des opérations prévus à l’article 2, lorsque l’ensemble des conditions suivantes sont remplies. La première tient aux taux de fraude. Ensuite, le montant de l’opération ne doit pas dépasser la « valeur-seuil » de dérogation. Par ailleurs, il faut que les prestataires de services de paiement n’aient décelé aucun des éléments suivants à l’issue d’une analyse en temps réel des risques : dépenses anormales ou un type de comportement anormal du payeur, informations inhabituelles concernant l’utilisation du dispositif ou logiciel à des fins d’accès, des signes d’infection par un logiciel malveillant lors d’une session de la procédure d’authentification, un scénario connu de fraude dans le cadre de la prestation de services de paiement, une localisation anormale du payeur, une localisation du bénéficiaire présentant des risques élevés. Ainsi, l’analyse en temps réel des risques, qui repose sur un modèle d’IA, est directement impliquée par la volonté du prestataire de services de paiement de faire jouer la dérogation au principe de l’authentification forte.
7. Dans la lutte contre la fraude aux opérations de paiement, l’IA est devenue indispensable d’un point de vue pratique, mais semble également rendue obligatoire sur le plan juridique. Le déploiement de tels systèmes suppose cependant de répondre à quelques interrogations.
8. Si l’IA offre des opportunités techniques appréciables en matière de détection des fraudes, sa diffusion suscite cependant un certain nombre de questions relatives aux conséquences juridiques de son usage, notamment au regard des textes qui régissent cette avancée technologique majeure. Tout d’abord, une première constatation est indispensable pour esquisser le régime juridique d’une telle utilisation. Les logiciels de détection des fraudes, en temps réel, mis en œuvre par les PSP, ne doivent pas être considérés comme des systèmes d’IA à haut risque, au sens du règlement IA de 202415. Dans ces conditions, ils ne sont pas soumis aux exigences que pose ce texte. L’annexe III du règlement ne vise, dans les domaines qui se rapprochent – et de loin – du thème de la fraude aux opérations de paiement, que les systèmes d’IA destinés à être utilisés pour évaluer la solvabilité des personnes physiques ou pour leur établir une note de crédit. Or, ce n’est pas le cas des systèmes de détection en temps réel des opérations de paiement frauduleuses, lesquels concernent un tout autre secteur du droit bancaire. Pour tenter de s’extraire du champ d’application du Règlement, il n’est donc pas nécessaire de passer par l’exception que prévoit l’annexe III à propos des « systèmes d’IA utilisés à des fins de détection de la fraude financière ». Compte tenu de son emplacement dans le texte, elle ne pourrait d’ailleurs pas s’appliquer.
9. Ensuite, les algorithmes d’IA à l’œuvre dans les modèles de détection en temps réel des opérations frauduleuses se nourrissent de données, lesquelles doivent être analysées et traitées. Dans ces conditions, la question de la conformité de l’usage évoqué avec le texte majeur du domaine, c’est-à-dire avec le Règlement général sur la protection des données, se pose avec beaucoup d’acuité. Elle peut être à la source de nombreuses interrogations pour les PSP, dans la mise en place et l’utilisation de leurs modèles. En effet, le RGPD doit s’appliquer. Dans un modèle de détection en temps réel des opérations frauduleuses, il s’agit bien de traitement automatisé, en grande quantité, de données. En pratique, toute l’efficacité du modèle de détection en temps réel repose d’ailleurs sur ce processus susceptible de s’appliquer à un jeu plutôt conséquent. Ensuite, ces données seront traitées. Elles seront analysées, toujours en temps réel, pour permettre l’envoi d’un signal et le blocage de l’opération, avant qu’elle ne survienne. Cette fois-ci, c’est l’économie du modèle de détection qui en dépend.
10. Conformément à l’article 6 du RGPD, la collecte de données, puis leur traitement doivent reposer sur une base licite. S’agissant de détecter la fraude, l’existence d’une base licite ne suscite pas vraiment de difficultés. Tout d’abord, l’article 6, 1, f) du RGPD fournit une base licite de traitement. Celui-ci dispose que « le traitement est nécessaire aux fins des intérêts légitimes poursuivis par le responsable du traitement ». Et de ce point de vue, le considérant 47 du RGPD précise bien que la détection de la fraude est une base licite de traitement. D’ailleurs, dans les lignes directrices adoptées par le Comité européen de protection des données, en 2020, relatives à l’interaction entre le RGPD et la Directive sur les services de paiement, dite DSP 216, il est expressément indiqué que « le traitement de données à caractère personnel strictement nécessaire à des fins de prévention de la fraude peut constituer un intérêt légitime du prestataire de services de paiement concerné, pour autant que les intérêts ou les libertés et droits fondamentaux de la personne concernée ne prévalent pas sur ces intérêts ». Enfin, l’article L. 526-1 du Code monétaire et financier, qui opère une transposition légèrement amendée de la DSP 2, prévoit lui-même une autorisation de traitement. En effet, cette disposition précise que « les systèmes de paiement et les prestataires de services de paiement sont autorisés à traiter des données à caractère personnel lorsque cela est nécessaire pour garantir la prévention, la recherche et la détection des fraudes en matière de paiements ». En conséquence, à propos de la possibilité de collecter des données, puis de les traiter à des fins de prévention de la fraude, par un modèle d’IA, aucune difficulté de conformité au regard du RGPD ne semble se dessiner.
11. La notion de données sensibles, au sens de l’article 9 du RGPD, invite à la réflexion. Il paraît évident que les logiciels de détection, en temps réel, de la fraude traite des données sensibles au sens de ce texte17 : données de paiement au titre de cotisations syndicales, etc. Or, par application du règlement général sur la protection des données, le traitement de telles données suppose un certain nombre d’exigences supplémentaires : consentement explicite, prévision d’une étude d’impact, etc. Il semble que ces données peuvent cependant être traitées. En effet, il s’agit sans doute d’un traitement nécessaire pour des motifs d’intérêt public important, et qui est proportionné à l’objectif poursuivi. Pour autant, le projet de règlement sur les services de paiement devrait fournir un fondement encore plus solide. Dans son projet d’article 80, il dispose que « les systèmes de paiement et les prestataires de services de paiement sont autorisés à traiter les catégories particulières de données à caractère personnel de l’article 9 dans la mesure nécessaire à la prestation de services de paiement et au respect des obligations du règlement sur les services de paiement, dans l’intérêt public du bon fonctionnement du marché intérieur des services de paiement, sous réserve de garanties appropriées pour les libertés et droits fondamentaux des personnes physiques ». Il s’agit notamment de prévoir des mesures techniques visant à garantir le respect des principes de limitation de la finalité, de minimisation des données et de limitation de la conservation. Ensuite, Il faudra prendre, ce qui est probablement déjà le cas en pratique, des mesures organisationnelles, notamment la formation au traitement de catégories particulières de données, la limitation de l’accès à des catégories particulières de données et l’enregistrement de cet accès.
12. Deux dernières questions peuvent être posées face au déploiement de tels modèles d’IA. La première a trait à l’obligation de transparence. Dans le contexte d’un logiciel de détection de la fraude, ce point est important. L’article 13 du RGPD prévoit qu’au moment de la collecte des informations à caractère personnel auprès de la personne concernée, le responsable du traitement automatisé fournit des informations sur la logique sous-jacente de l’algorithme, ainsi que sur l’importance et sur les conséquences prévues du traitement pour la partie concernée. Cette disposition, à propos des logiciels d’IA de surveillance, en temps réel, de la fraude et des transactions frauduleuses, a pu nourrir quelques craintes parmi les professionnels. Faut-il divulguer l’algorithme dans ses moindres détails, c’est-à-dire dévoiler les modalités du modèle, ce dont pourraient se réjouir les éventuels fraudeurs ? La réponse est assurément négative. La protection issue du RGPD ne doit pas constituer un effet d’aubaine pour les personnes malintentionnées, pouvant ainsi découvrir la façon dont fonctionne l’algorithme de détection. Ainsi, seuls les grands principes doivent être expliqués, sans entrer dans le détail de la logique de l’algorithme.
13. La seconde interrogation concerne le principe de la conservation des données. Il est vrai que selon l’article 18 du RGPD, celui qui collecte la donnée ne peut conserver trop longtemps le résultat de ce qu’il collecte, du moins pas plus longtemps que nécessaire. De surcroît, l’article 17 consacre explicitement le droit à l’oubli. Or, pour l’efficacité du modèle, les données doivent être conservées. Elles doivent d’ailleurs l’être aussi quand les PSP font usage de la dérogation de l’article 18 pour l’authentification forte. Les prestataires de services de paiement qui font usage de la dérogation visée à l’article 18 font l’objet au moins une fois par an d’un audit portant sur la méthodologie, le modèle et les taux de fraude notifiés18. Dès lors, une question se pose : comment satisfaire à cet impératif si l’on ne doit pas conserver les données trop longtemps. Assurément, là aussi, la protection qu’offre l’article 17 doit tenir compte de l’objectif de prévention de la fraude. Le considérant 102 du règlement semble trouver un équilibre : « les prestataires de services de paiement devraient toutefois fixer des durées de conservation appropriées pour les différents types de données utilisés à des fins de prévention de la fraude. Ces durées de conservation devraient être strictement limitées à la durée nécessaire pour détecter les comportements atypiques et potentiellement frauduleux, et les prestataires de services de paiement devraient régulièrement supprimer les données qui ne sont plus nécessaires à la détection et à la prévention de la fraude. Les données traitées à des fins de contrôle des opérations ne devraient pas être utilisées après que l’utilisateur de services de paiement a cessé d’être un client du prestataire de services de paiement ». Cela étant, en pratique, une conservation trop longue n’a pas grand intérêt, dans la mesure où les modèles d’IA nécessitent des données d’une certaine fraîcheur.
14. Enfin, il faut préciser un dernier élément important à propos des modèles de surveillance en temps réel des transactions, afin de bloquer les transactions frauduleuses. Leur efficacité repose sur le partage d’informations entre les prestataires de services de paiement. Il faut en effet que les PSP, et les différents maillons de la chaîne, puissent faire remonter et partager des cas de fraude, qu’ils étiquettent. Ce partage d’informations peut susciter des difficultés de conformité, notamment au regard du secret bancaire. Pour cette raison, le projet d’article 83 du règlement sur les services de paiement est intéressant et semble donner une base licite au partage d’informations. Un tel dispositif de partage d’informations est prévu, auquel les prestataires de services de paiement pourront participer, ce qui permettra d’améliorer la qualité de la détection.
15. Comme d’autres, le secteur bancaire est traversé par la vague de l’IA. Parfois considérée comme un défi, elle peut également être perçue comme l’instrument d’une meilleure protection du client, dans le domaine de la fraude aux opérations de paiement. En pratique, elle est un levier incontournable de la lutte contre de tels comportements. En effet, les fraudeurs n’hésitent pas à exploiter les ressources de l’innovation technologique. Dans ces conditions, mieux vaut utiliser des instruments similaires. De ce point de vue, l’IA représente une formidable opportunité. Le cadre juridique existant offre des bases solides pour le déploiement et l’essor des modèles d’IA, ce qui suppose toutefois une certaine vigilance. Transparence, durée de conservation, partage d’informations doivent être maîtrisés. L’IA peut assurément contribuer à restaurer la confiance dans les systèmes de paiement.
