Ce qu'un cours d'iGaming m'a appris sur les systèmes anti-fraude

J'ai suivi le cours Anti-Fraud and Payments Handling de l'iGaming Academy en m'attendant à une liste de règles pour bloquer les mauvaises transactions. Ce qu'il m'a vraiment appris, c'est que l'anti-fraude est surtout une série de jugements, et presque aucun d'eux n'a de bonne réponse nette.

La prévention de la fraude est un compromis, pas un filtre

Le réflexe, c'est de penser au fraud detection comme un filtre : mauvaises transactions d'un côté, bonnes de l'autre. Les vrais systèmes ne fonctionnent pas comme ça, parce que les règles qui attrapent le plus de fraude attrapent aussi de vrais clients, et chaque client légitime que vous bloquez, c'est du revenu perdu plus une personne qui ne reviendra probablement pas.

Donc la question n'est jamais « est-ce que cette règle attrape la fraude ». C'est « combien coûte cette règle quand elle se trompe, et à quelle fréquence va-t-elle se tromper ». Une règle qui attrape 90 % de la fraude mais rejette 5 % des clients authentiques peut facilement être pire pour une entreprise qu'une règle qui en attrape 60 % et n'en rejette presque aucun.

Tous les declines ne veulent pas dire la même chose

C'était de loin la distinction la plus utile du cours. Une transaction declined peut vouloir dire des fonds insuffisants, un timeout réseau, une carte signalée volée, ou une banque qui bloque une transaction qu'elle a trouvée suspecte. Ce sont des signaux complètement différents qui arrivent par le même canal.

Des fonds insuffisants, c'est une condition temporaire, donc réessayer plus tard ou par une autre route est raisonnable. Une carte signalée volée, c'est une réponse permanente et définitive, et la réessayer ailleurs revient à essayer de faire passer une transaction frauduleuse par un acquirer qui ne l'a pas encore repérée. Traiter ces deux réponses de façon identique, c'est comme ça qu'un système de paiement finit soit par perdre des ventes légitimes, soit par blanchir de la fraude.

Les patterns comptent plus que les transactions individuelles

Une seule transaction ne dit généralement pas grand-chose à elle seule. Un paiement de 50 € n'a rien de remarquable. La même carte produisant des tentatives refusées répétées dans une fenêtre courte, c'est une tout autre histoire, parce que c'est à ça que ressemble le card testing : quelqu'un avec une liste de cartes volées qui vérifie lesquelles sont encore actives avant de les dépenser.

Ça a changé ma façon de penser aux données qu'un système de paiement doit stocker. Les règles qui ne voient que la transaction actuelle ne peuvent pas détecter un pattern, donc l'historique doit être là et doit être interrogeable au moment de la décision, pas juste archivé pour du reporting plus tard.

La preuve fait partie du produit

La partie à laquelle je n'avais pas du tout pensé avant le cours : quand un acquirer ou un régulateur demande pourquoi une transaction a été approuvée ou refusée, « le système a décidé » n'est pas une réponse. Il faut la trace de ce qui a été vérifié, quel a été le résultat, et quelle règle s'est déclenchée.

Ça a reformulé la persistence pour moi. Dans la plupart des projets, le database est là où vit l'état. Dans les paiements, c'est aussi la piste d'audit, et supprimer un record de paiement n'est pas du nettoyage, c'est détruire une preuve.

Les données de carte ont leurs propres règles

Stocker des numéros de carte complets n'est pas une décision à prendre à la légère, c'est une obligation de compliance avec de vraies exigences attachées. La version pratique pour un projet comme le mien est simple : gardez le BIN et les quatre derniers chiffres, ce qui suffit pour identifier une carte à travers les transactions et montrer à un client quelle carte il a utilisée, et ne stockez jamais le reste.

Ce que j'en ai vraiment retenu

Le cours a changé ce que je pense qu'est un système antifraude. Ce n'est pas un mur qu'on met devant les paiements. C'est un ensemble de décisions sur le risque acceptable, prises avec une information incomplète, où être trop agressif coûte de l'argent réel et être trop permissif coûte encore plus. Construire PayMaestro ensuite a surtout été un exercice consistant à transformer ces jugements en code qui puisse vraiment être inspecté et expliqué plus tard.