Les patterns SQL utilisés pour détecter la fraude aux transactions

• La détection de fraude commence souvent, avant le machine learning, par une bonne modélisation des tables et jointures et par la recherche en SQL de patterns anormaux liés à la vitesse, au lieu, au montant, au commerçant et à l’horaire
• La velocity consiste à repérer les périodes où les transactions d’un même porteur de carte se concentrent sur une courte durée, avec un besoin d’ajuster la fenêtre temporelle, les seuils et des listes blanches pour les faux positifs
• L’impossible travel s’appuie sur LAG() et le calcul de distance pour détecter, comme un paiement à Chicago puis 7 minutes plus tard à Los Angeles, des déplacements physiquement impossibles qui signalent fortement une carte clonée
• Les anomalies de montant recherchent des valeurs comme $1.00, $99.99, $499.99, révélatrices de tests de carte ou d’évitement de règles, mais elles sont peu adaptées aux transactions de prestations
• En combinant hausse soudaine chez un commerçant, transactions hors horaires habituels et colonnes dérivées via fonctions de fenêtre, on peut attribuer un score à partir de plusieurs signaux et réduire le cycle d’itération de plusieurs semaines à quelques heures

---

Les patterns SQL pour repérer les signes de fraude dans les données de transaction

• La détection de fraude commence souvent, avant le machine learning ou les bases de données en graphe, par les bonnes tables et jointures et par du SQL pour repérer des formes de transactions inhabituelles
• Cela s’applique aux données où de l’argent circule et où des logs subsistent, comme les cartes de crédit, les remboursements de santé, l’e-commerce, les POS ou les programmes publics d’aides
• Sur un nouveau dataset, on empile généralement les patterns dans cet ordre : velocity, déplacement impossible, anomalies de montant, concentration par commerçant, horaires anormaux, signaux basés sur les fonctions de fenêtre

1. Velocity : trop de transactions sur un temps très court

• Lorsqu’on cherche à vider rapidement une carte ou un compte volé, on observe souvent un regroupement de transactions sur une courte période pour un même porteur de carte
• La requête de base regroupe les transactions des 30 derniers jours par heure et repère les segments où le nombre de transactions par cardholder_id dépasse un seuil
• Les principaux paramètres à ajuster sont la taille de la fenêtre temporelle et le seuil de nombre de transactions
  • On peut exécuter en parallèle des versions sur 1 minute, 5 minutes et 1 heure pour les comparer
  • Les réseaux de test de cartes concentrent les transactions en quelques secondes, alors que les fraudes aux prestations peuvent s’étaler sur une demi-journée
• Les utilisateurs légitimes peuvent aussi dépasser le seuil
  • un opérateur qui gère des distributeurs automatiques
  • une personne qui recharge en masse des cartes prépayées
  • après une première exploration, il faut donc une liste blanche des cas de faux positifs
• L’approche par fenêtre glissante calcule le nombre de transactions des 5 dernières minutes avec COUNT(*) OVER (...) RANGE BETWEEN INTERVAL '5 minutes' PRECEDING AND CURRENT ROW
• QUALIFY fonctionne dans Snowflake, BigQuery, Databricks et Teradata
  • dans Postgres, il faut encapsuler la requête complète dans un CTE puis filtrer à l’extérieur

2. Impossible travel : un déplacement physiquement impossible

• Si une carte est utilisée à Chicago puis 7 minutes plus tard à Los Angeles, il y a de fortes chances qu’au moins une des deux transactions soit frauduleuse
• Ce pattern est un signal fort de carte clonée, car il existe très peu d’explications normales à la présence d’une même carte dans deux lieux éloignés à quelques minutes d’intervalle
• La requête utilise LAG() pour récupérer l’heure et la position de la transaction précédente, puis calcule la distance et le temps entre les deux
• haversine est une fonction qui calcule la distance orthodromique (great-circle distance)
  • la plupart des data warehouses la fournissent
  • sinon, c’est une fonction assez simple à écrire soi-même
• L’exemple de seuil est de 600mph
  • la vitesse de croisière d’un avion de ligne est d’environ 575mph, donc cela signifie un déplacement impossible même en avion
  • si on descend à 100mph, on capte aussi des déplacements terrestres rapides, mais on commence à attraper des cas légitimes comme des voyageurs en avion ou des parents qui transportent leurs enfants
• On peut aussi observer des signaux proches dans la même famille
  • des transactions dans deux villes éloignées d’un même État en moins de 5 minutes peuvent suggérer un réseau local de clonage
  • des transactions dans plusieurs ZIP codes en moins d’une heure peuvent suggérer un réseau de skimmers opérant dans une même zone
  • des transactions franchissant une frontière en moins de 10 minutes peuvent signaler un réseau international

3. Amount anomalies : des transactions anormales pour certains montants

• Certaines structures de montant apparaissent souvent dans la fraude, mais rarement dans les usages normaux
• Les conditions d’exemple recherchent notamment les montants suivants
  • $1.00, $5.00, $10.00
  • entre $99.50 et moins de $100.00
  • entre $499.50 et moins de $500.00
• Les petits montants entiers en dollars sont généralement un signal de test de carte
  • il s’agit de vérifier qu’un numéro récupéré dans un dump de cartes fonctionne réellement avant de le revendre
  • il est rare qu’un véritable porteur de carte achète un article coûtant exactement $1.00
  • un café aura plus souvent un prix comme $4.73, et un plein d’essence quelque chose comme $52.81
• Les montants juste en dessous d’un seuil ont une autre signification
  • $99.99 peut refléter une tentative d’éviter un seuil où une vérification d’identité devient obligatoire à partir de $100
  • $499.99 peut refléter une tentative d’éviter une limite quotidienne de retrait ATM à $500
  • c’est un signe que l’acteur connaît les règles et reste juste en dessous
• Dans les transactions de prestations, les patterns de montants ronds sont nettement moins utiles
  • les prestations ne sont pas testées de la même manière que les cartes
  • les versements en double sont souvent un signal plus important

4. Suspicious merchants : une concentration anormale au niveau du commerçant

• Lorsqu’un lecteur de carte, par exemple sur une pompe à essence, est infecté par un skimmer, cela peut produire non pas une seule fraude, mais des dizaines de fraudes
• Toutes les cartes utilisées sur ce lecteur pendant plusieurs semaines peuvent finir dans la base de données de quelqu’un
• Vu du côté commerçant, cela se manifeste souvent par une hausse inhabituelle du nombre de cartes sans lien entre elles sur une courte période, accompagnée de montants plus élevés
• Un exemple simple de critère consiste à regrouper les 7 derniers jours par commerçant et par heure afin de calculer
  • le nombre de cartes uniques
  • le nombre total de transactions
  • le montant total des transactions
  • puis à rechercher les créneaux où le nombre de cartes uniques dépasse 20 et le montant total dépasse $5000
• Les seuils statiques posent un problème d’échelle
  • Costco peut dépasser ce seuil en 90 secondes
  • une librairie d’occasion ne le dépassera presque jamais
• Une meilleure approche consiste à comparer chaque commerçant à sa propre baseline historique
  • regrouper les transactions des 60 derniers jours par heure
  • calculer, pour chaque commerçant, le nombre moyen historique de cartes uniques sur les 168 buckets horaires précédents
  • repérer les périodes où le nombre actuel de cartes uniques dépasse 3 fois la moyenne historique
• Les 168 buckets horaires correspondent aux intervalles horaires des 7 derniers jours
  • parce que la saisonnalité quotidienne et hebdomadaire compte
  • même pour un même café, la baseline d’un mardi à 14h n’est pas celle d’un samedi à 9h
• Comme point de départ, on peut utiliser 3 fois la normale
  • c’est assez souple pour éviter un flot excessif d’alertes
  • mais assez strict pour repérer de vrais créneaux anormaux

5. Off-hours : des transactions en dehors des horaires habituels d’un individu

• La plupart des gens ont des habitudes de dépense
• Si une personne qui travaille de 9h à 17h commence soudainement à acheter de l’essence à 3h du matin, il est possible que sa carte soit utilisée par quelqu’un d’autre, ou qu’elle soit en voyage
• Le fait qu’elle soit en voyage peut être vérifié par d’autres signaux
• La requête calcule, sur les 90 derniers jours, le nombre de transactions par porteur de carte et par heure, puis ne reconnaît comme horaires habituels que les heures où il y a eu au moins 2 transactions
• Ensuite, toute nouvelle transaction dont l’heure se situe hors de la plage earliest_hour à latest_hour de ce porteur est détectée
• La condition interne “au moins 2 transactions sur cette plage horaire” est importante
  • elle évite qu’un plein nocturne isolé, survenu par hasard il y a 3 mois, soit intégré aux horaires habituels
  • elle aligne le critère non sur un événement unique, mais sur une véritable habitude
• Son inconvénient est qu’elle nécessite des données historiques
  • un nouveau compte n’a pas encore de baseline
  • pour ces comptes, on peut utiliser le pattern horaire global de l’ensemble des utilisateurs, ou ignorer ce pattern jusqu’à ce que quelques mois d’historique s’accumulent

6. Combiner les signaux avec les fonctions de fenêtre

• Les patterns basés sur les fonctions de fenêtre ne constituent pas un type de fraude séparé ; ils servent plutôt à transformer les cinq patterns précédents en signaux combinables
• On peut créer les colonnes dérivées suivantes pour chaque transaction
  • temps écoulé depuis la transaction précédente : timestamp - LAG(timestamp)
  • changement de commerçant ou non : comparaison entre le merchant_id précédent et le merchant_id courant
  • montant cumulé des 24 dernières heures : SUM(amount) OVER (...)
  • rang de la transaction dans la journée : ROW_NUMBER()
• Une fois matérialisées, ces colonnes ramènent les règles de fraude à de simples expressions de filtre
• Un réseau de test de cartes peut être repéré avec les conditions suivantes
  • au moins la 5e transaction de la journée
  • moins de 60 secondes après la transaction précédente
  • un commerçant différent de celui de la transaction précédente
• Si une nouvelle hypothèse de fraude peut s’exprimer comme un filtre SQL plutôt que comme un ticket d’ingénierie, le cycle d’itération passe de plusieurs semaines à quelques heures
• Au final, cela permet de détecter davantage de fraudes, plus rapidement

Comment utiliser ces patterns ensemble

• Aucun pattern, à lui seul, n’est suffisant
• Chacun a des limites claires
  • la velocity génère des faux positifs comme les opérateurs de distributeurs automatiques
  • le déplacement géographiquement impossible manque les fraudes qui restent dans une même grande agglomération
  • les anomalies de montant fonctionnent mal hors du contexte des tests de cartes
  • la règle sur les horaires anormaux a besoin d’historique
• En pratique, on exécute tous les patterns puis on attribue un score à chaque transaction à partir de plusieurs signaux
• Une transaction qui déclenche trois ou quatre signaux est presque toujours frauduleuse
• Une transaction qui ne déclenche qu’un seul signal peut simplement correspondre à un usage inhabituel mais légitime d’un porteur de carte en voyage
• Si vous débutez en détection de fraude, il est judicieux de commencer par Velocity
  • cela révèle un volume utile de fraude
  • cela attrape relativement peu d’activité légitime
  • et le coût d’exécution reste faible
• Si vous avez déjà les points 1 à 5, le prochain investissement utile concerne les colonnes brutes basées sur les fonctions de fenêtre
  • une fois créées, tous les analystes de l’équipe peuvent les réutiliser
  • l’ajout du pattern de fraude suivant ne devient plus un projet à part entière

Points d’attention

• Gestion des NULL

  • les tables de transactions réelles n’utilisent pas toujours NULL comme dans les manuels SQL d’introduction
  • de nombreux systèmes legacy utilisent des valeurs sentinelles comme 9999-12-31 pour “pas de date de fin” ou 0001-01-01 pour “pas de date de début”
  • un filtre avec IS NULL peut rater silencieusement ce type de lignes
  • il faut vérifier les conventions de la table concernée avant d’écrire la clause WHERE

• Faux positifs

  • toute règle peut attraper de vrais porteurs de carte ayant un comportement inhabituel mais légitime
  • les cas signalés nécessitent une revue humaine
  • il faut une boucle de feedback pour ajuster les seuils à partir des vrais cas de fraude et des faux signaux
  • automatiser un blocage sur une seule règle peut faire perdre des clients

• Données personnelles

  • si les données contiennent des PII, il faut respecter les politiques d’usage des données applicables
  • il vaut mieux commencer avec des données désidentifiées ou un échantillon, puis n’utiliser les données de production qu’après validation

• Coût

  • les fonctions de fenêtre sur de grandes partitions ne sont pas bon marché
  • il faut d’abord filtrer la plage de dates avant d’appliquer les fonctions de fenêtre
  • exécuter LAG() sur 2 ans de transactions d’un dataset complet avant d’ajouter le WHERE peut fortement consommer le budget de crédits du data warehouse

[GN⁺]

Commentaires Hacker News

• Le critère selon lequel le véritable titulaire de la carte n’achète presque jamais quelque chose à 1,00 $ dépend surtout de la manière dont le vendeur fixe ses prix, non ?
  Quand quelqu’un achète quelque chose sur un site web pour tester une carte bancaire volée, il ne peut pas choisir librement le prix.
  En plus, cela semble trop pensé pour des situations comme aux États-Unis, où les taxes ne sont pas incluses dans le prix ; dans d’autres régions, les prix ronds sont très courants.
  Je doute aussi que les autres critères fonctionnent bien. Par exemple, si l’on signale les personnes qui ont effectué une transaction au cours des 90 derniers jours en dehors d’une tranche horaire où elles avaient d’habitude au moins deux transactions, j’ai l’impression qu’on attraperait facilement la moitié des gens.
  On ne sait pas bien si c’est un article qui réduit à l’excès une expertise complexe à de simples requêtes SQL, ou si tout est inventé et spéculatif. Les phrases « six motifs SQL utilisés pour repérer la fraude transactionnelle » et « il n’y a rien ici sur lequel j’ai réellement travaillé ou que j’ai réellement vu » se contredisent.

  • Les « transactions en dehors des horaires habituels » semblent être un critère assez basique.
    En général, on n’achète pas de l’essence, du café ou des snacks à 2 heures du matin, mais les rares fois où cela arrive, il y a de fortes chances qu’il s’agisse d’une urgence personnelle, et dans ce cas on n’a pas forcément envie d’appeler sa banque.
    Je sais bien qu’un voleur opportuniste peut aussi agir à cette heure-là, mais le coût des faux positifs existe bel et bien.
  • C’est même pire que ça. D’après mon expérience, le café a souvent un montant rond, et certaines personnes mettent volontairement un montant exact quand elles font le plein.
    Il existe aussi des stations-service qui demandent des montants prédéfinis, comme 10, 20 ou 50 euros.
  • Un soir, dans un pub, j’avais faim et j’ai voulu acheter un paquet de chips, mais le montant minimum par carte était de 5 £ ; j’ai donc demandé qu’on me fasse payer 5 £ tout rond.
    Ma carte a alors été bloquée pour suspicion de fraude, ce qui m’a bien agacé. Ce n’est pas le genre de chose qu’on veut gérer à 2 heures du matin en étant ivre.
    Ça m’a peut-être protégé de moi-même, mais c’était quand même pénible.
  • Je ne sais pas si cela se fait encore, mais autrefois, des hôtels ou des loueurs de voitures faisaient parfois une transaction à 1,00 $ pour vérifier la validité d’une carte bancaire avant une réservation ou une location.
  • Cette méthode se contourne facilement en ajoutant un peu de jitter aux transactions de test, et on pourrait aussi l’améliorer facilement avec une vraie analyse statistique.
    Et puis la reconnaissance heuristique de motifs, quand on n’attend pas une précision proche de 100 %, n’est-ce pas justement le genre de domaine où l’IA est censée être bonne ?

• Le critère « franchissement de frontière en moins de 10 minutes = organisation internationale » pourrait aussi s’appliquer à des gens tout à fait ordinaires qui vivent près des frontières en Europe.
  Même si on exclut les transactions sans présence physique de la carte, cela semble supposer à tort que tous les emplacements des commerçants sont correctement configurés, que toutes les ventes ont lieu dans des magasins physiques, qu’il n’existe pas de commerce mobile, et que toutes les transactions sont correctement traitées en ligne.

  • Il y a quelques semaines, quand je suis passé des États-Unis au Canada, cela a probablement pris 10 minutes environ.

• Si on lit jusqu’au bout, on découvre un contenu creux et des conseils contradictoires. Cela ressemble presque certainement à un texte généré par LLM.
  L’auteur dit que « votre équipe » ne devrait dépendre d’aucun motif en particulier, tout en affirmant que le seul motif 1 peut déjà révéler « une quantité utile de fraude ».
  Il y a aussi des phrases bizarres comme « tous les analystes de votre équipe les utiliseront, c’est-à-dire les window functions, et ajouter le prochain motif de fraude cessera d’être un projet ».
  Presque tous les exemples n’utilisent pas IS NULL, et pourtant il y a une digression peu pertinente sur le fait que le filtrage IS NULL pourrait ne pas être appliqué ; le seul exemple qui l’utilise est dans un autre contexte.
  Globalement, c’est un article de mauvaise qualité et beaucoup trop long.

• Hacker News, il faut qu’on parle de ça.
  « Fixel Smith » est un personnage créé par IA, et l’article n’a presque rien à voir avec l’analyse de fraude. Ce nom est utilisé pour presque toutes les identités imaginables : musicien (1), romancier (2), analyste fraude (3), influenceur (4), etc.
  Le post a obtenu plus de 220 points et plus de 70 commentaires, et presque personne n’a remarqué qu’il était assez faux ; personne non plus n’a relevé qu’il s’agissait d’un personnage généré par IA.

  1. https://www.amazon.it/Forged-Soundtrack-Explicit-Fixel-Smith...

  2. https://fixelsmith.com

  3. https://analytics.fixelsmith.com/

  4. https://www.instagram.com/fixeltales/

  • Hacker News semble avoir récemment pris l’habitude agaçante de mettre en avant ce genre de soumissions IA de faible qualité.
    Je me demande si ce déferlement d’IA révèle une vérité dérangeante sur le discernement de la communauté, ou s’il s’agit simplement d’un échec des défenses existantes qu’il suffirait de corriger.
  • J’ai consulté l’article sur mon téléphone et je n’ai parcouru que rapidement les commentaires. Il n’est pas toujours facile de juger si un texte est généré par IA ou simplement édité, mais ici c’était évident au premier coup d’œil rien qu’en lisant les citations.
    Si l’on suppose que tous les commentaires ont été rédigés de bonne foi, le faible niveau de littératie IA même ici est assez inquiétant.
  • Même à vue de nez, cela ressemble soit à une personne incroyablement prolifique, soit à un bot.
    Les romans n’ont presque aucun rapport avec les articles d’analyse, et les articles d’analyse semblent avoir un style de LLM, donc l’ensemble paraît suspect. C’est ironique quand on pense que le sujet initial est justement la fraude.
  • Je serais encore plus surpris si la plupart des gens enquêtaient par habitude sur les auteurs de ce qu’ils lisent.
    Honnêtement, je ne regarde généralement même pas la signature, et encore moins les autres parties du site.
  • C’est bien un texte qui existe réellement. Bien sûr, il a l’air d’avoir été écrit par un LLM, mais si la pire critique qu’on puisse lui adresser est de ressembler à un LLM, alors on n’a peut-être pas vraiment de critique substantielle.
    On ne sait pas si le contenu est inventé ou non, mais on peut critiquer l’article pour ce qu’il dit sans spéculer sur le fait qu’il ait été écrit par un LLM ou que ce soit de la fiction. Il présente beaucoup de défauts bien plus concrets.

• Nous développons le framework open source de sécurité tirreno.
  L’approche décrite ici nous paraît discutable. Par exemple, le déplacement impossible est une technique légitime et largement utilisée, mais elle concerne le comportement d’utilisateurs en ligne basé sur les adresses IP.
  Dans tirreno, il existe des règles distinctes pour les cas où l’IP provient manifestement d’Apple Relay ou de VPN/Tor, et ce sont des indicateurs séparés.
  Je pense qu’une partie, voire la totalité, des exemples est générée par LLM. Le contexte est mélangé, et personne ne collecte réellement à grande échelle des positions GPS pour les paiements par carte.

  1. https://github.com/tirrenotechnologies/tirreno

• Cela ressemble davantage à une logique fondée sur des règles encodée dans des requêtes SQL, sans données probantes derrière.
  Il y a des seuils partout, mais aucune donnée ne montre que ces seuils ont du sens.

• L’affirmation du type « la détection de fraude dans les données transactionnelles, c’est surtout du SQL, pas du machine learning, pas des bases de données graphe, ni quoi que ce soit que Gartner pousse cette année » ne peut se défendre que si l’on parle de l’ensemble du travail d’intégrité programmatique.
  Si une approche plus simple et plus grossière résout le problème, elle peut être préférable.
  Les clients fintech veulent généralement savoir si une transaction en cours est frauduleuse, et ils veulent une réponse en quelques millisecondes sur des données de grande dimension. C’est un type de charge où une base de données relationnelle a du mal à tenir ces contraintes de temps réel à l’échelle ; elle sert plutôt à d’autres usages, comme le chargement de données historiques.
  C’est pour cela qu’on voit apparaître des bases de données en mémoire, des moteurs de stream processing, et aussi du machine learning.
  Cela dit, certains points de l’auteur sont valables, en particulier la gestion des alertes bruyantes, qui est un problème général dépassant la seule ingénierie de performance ; j’attends donc la suite avec intérêt.

  • D’après mon expérience, ce qui est décrit ici relèverait plus précisément de la prévention de la fraude que de la détection de fraude. Dans une architecture mature, les deux coexistent et se complètent.
    En prévention, on est toujours limité par les exigences de latence, les données disponibles et une vision incomplète du comportement utilisateur. On prend des décisions rapides avec du machine learning et des règles pour traiter la plupart des cas, mais à cause de ces contraintes, on ne peut pas bloquer toute la fraude avec précision.
    La détection, elle, s’occupe de ce qui se passe ensuite. Il est courant qu’une équipe d’analystes examine des transactions approuvées pour y repérer des signes de fraude. C’est particulièrement important pour les types de fraude qui ne s’accompagnent pas de signaux externes comme des chargebacks ou des plaintes clients. L’intégrité de plateforme en est un exemple, et les systèmes anti-blanchiment en fintech doivent eux aussi aller chercher la fraude.
    Les deux sont complémentaires, car les transactions détectées deviennent des labels qui servent à entraîner et évaluer les futurs modèles de prévention.

• Il est dit que si une carte est utilisée à Chicago puis à Los Angeles 7 minutes plus tard, l’une des deux transactions est forcément frauduleuse ; je me demande comment cela fonctionne pour le shopping en ligne.
  Si je suis assis sur mon canapé et que j’achète quelque chose sur Amazon, quelle adresse est enregistrée ?
  Et il y a aussi des cas limites, par exemple un couple qui partage un compte en ligne, pendant que l’un des deux voyage et effectue un achat avec une carte enregistrée.

  • Passer, insérer ou poser sa carte, ce sont des transactions avec présence de la carte. Saisir le numéro de carte, comme pour un achat en ligne, ce sont des transactions sans présence de la carte.
    Les commerçants et les banques savent faire cette distinction.
  • On peut le distinguer via les métadonnées de transaction. J’ai travaillé pour une société de cartes de crédit.
  • Je crois savoir que le système distingue les transactions avec présence de la carte et sans présence de la carte.

• Le fait que « cette méthode ne fonctionne pas tant qu’un historique n’a pas été constitué, et qu’il n’y a pas de référence pour les nouveaux comptes » est un aspect expérience client sous-estimé.
  Quand ma carte est refusée parce que je suis un nouveau client ou parce que j’ai un nouveau comportement, j’ai l’impression que le logiciel fait bien son travail.
  Mais si j’ai déjà un historique vérifié et qu’une transaction est quand même refusée, je suis agacé par ce qui ressemble à un algorithme naïf et paranoïaque.

  • L’incitation d’une banque est de réduire la fraude.
    Au bout du compte, les transactions frauduleuses finissent souvent annulées ou remboursées, et c’est la banque qui absorbe la perte. Une transaction refusée ne crée qu’un client mécontent, qui se plaindra puis oubliera vite. Le coût externalisé retombe donc sur le client.
    Les banques ont donc intérêt à se tromper du côté de la prudence, et à refuser des transactions même s’il y a des faux positifs.

• J’ai l’impression que l’idée même du machine learning est justement d’apprendre ce genre de règles à partir des données.
  La bonne approche serait, à mon avis, d’utiliser un modèle de machine learning pour trouver les motifs corrélés à la fraude, puis d’évaluer lesquels ont du sens. Cela pourrait même permettre de découvrir de nouvelles hypothèses.

  • Tout ce qui n’est ni explicable ni susceptible d’améliorations itératives déterministes est trop risqué pour le refus de transactions financières.
    Un analyste humain doit pouvoir expliquer à l’équipe conformité, dans un e-mail de 5 minutes, pourquoi une transaction donnée a été refusée et ce qu’il aurait fallu faire différemment pour éviter cette décision défavorable.
    Avec le machine learning, corriger un problème en fait souvent apparaître deux autres, encore mal visibles. Quand les choses évoluent dans le temps, le SQL réserve généralement moins de surprises en termes de régressions ou d’effets de bord inattendus.