La transaction frauduleuse est généralement le dernier signal, pas le premier

La plupart des systèmes de lutte contre la fraude s’organisent autour d’un moment : la transaction. L’argent est sur le point de bouger, c’est donc à ce moment que les questions difficiles sont posées. C’est un réflexe compréhensible, et c’est précisément pourquoi tant de fraudes passent au travers.

Lorsqu’une transaction frauduleuse apparaît, l’attaque est presque terminée. La transaction n’est pas le début de la fraude ; elle en est la fin. Tout ce qui aurait pu révéler l’attaque — et l’arrêter à moindre coût — s’est produit plus tôt, dans des signaux que la plupart des systèmes n’observaient pas.

Remonter le fil de l’attaque

Prenons une fraude par détournement de compte typique, racontée à rebours à partir de la transaction :

1. La transaction. Un virement important vers un nouveau bénéficiaire. C’est l’événement que le moniteur de transactions évalue. Mais à ce stade, le fraudeur contrôle le compte, le bénéficiaire est déjà configuré et les alertes sont déjà supprimées. On demande au système de prendre sa décision la plus critique avec la plus faible marge de manœuvre.
2. Création du bénéficiaire. Quelques instants plus tôt, un nouveau destinataire a été ajouté. En soi, ajouter un destinataire est une opération banale, mais dans ce contexte, c’est une étape préparatoire.
3. Modifications du compte. Avant cela, l’adresse e-mail, le numéro de téléphone ou les paramètres de notification ont changé, désactivant discrètement la capacité du véritable client à remarquer que quelque chose ne va pas.
4. Dérive comportementale. Le rythme de frappe de la session, la navigation et la dynamique tactile ont cessé de correspondre au titulaire du compte. Quelqu’un d’autre est aux commandes.
5. Reconnaissance / connexion. La session a commencé par des consultations de solde et un accès direct aux paramètres — un comportement qui correspond à un fraudeur repérant le compte, pas à un client gérant ses opérations bancaires.
6. Compromission de l’appareil. Et tout au début, l’appareil était compromis, un outil d’accès à distance était actif ou une session avait été détournée.

Lu à l’endroit, il s’agit d’une chaîne d’au moins six maillons. Un système centré sur la transaction n’évalue que le dernier — et l’évalue au pire moment possible, lorsque les preuves ont été enfouies et que le temps joue contre lui.

Pourquoi l’évaluation ponctuelle échoue

Traiter la transaction comme le point de décision crée trois faiblesses structurelles :

• Vous décidez tard. Les occasions les plus riches et les moins coûteuses d’intervenir se situent plus tôt dans la chaîne, avant que les étapes préparatoires ne soient achevées.
• Vous décidez à l’aveugle. Isolé, un simple virement vers un nouveau destinataire est ambigu. Le signal qui lève l’ambiguïté — le comportement de détournement qui l’a précédé — se situe en dehors de la transaction.
• Vous décidez sous pression. En particulier sur les rails de paiement instantané, le moment de la transaction ne laisse aucun temps pour l’examen. Ce que vous savez, vous devez déjà le savoir.

Le fraudeur, quant à lui, a tout fait pour que la transaction finale paraisse normale : le bon appareil, des identifiants valides, un bénéficiaire établi (bien que récent) et des alertes réduites au silence. Si la transaction est la seule chose que vous examinez, elle passera généralement.

Un risque continu, pas un point de contrôle final

L’alternative consiste à cesser de considérer la prévention de la fraude comme une barrière au niveau de la transaction et à commencer à la penser comme une image de risque continue qui se construit tout au long du parcours. Chaque étape — appareil, session, connexion, navigation, modification du compte, création de bénéficiaire, transaction — apporte des preuves. Chaque événement met à jour un score de risque vivant.

Selon ce modèle, la fraude de l’exemple ci-dessus n’est pas détectée au niveau de la transaction ; elle est détectée au moment où le comportement a dérivé, ou lorsqu’un détail de contact a changé sur une session qui semblait déjà suspecte, ou lorsqu’un nouveau bénéficiaire a été ajouté au sein d’une session déjà à risque élevé. Lorsque la transaction arrive, le score reflète déjà tout ce qui l’a précédée — et la décision est facile, précoce et sûre.

Cela transforme aussi la manière dont la friction est appliquée. Lorsque le risque s’accumule en continu, les défis de vérification renforcée peuvent être réservés aux sessions qui ont réellement suscité la méfiance, au lieu d’être appliqués à chaque transaction. Les bons clients circulent librement ; les sessions à risque sont arrêtées avant, et non après, que l’argent ne bouge.

Comment Paygilant est conçu autour de cette idée

C’est le principe au cœur de Paygilant. Plutôt que de noter les transactions comme des événements isolés, Paygilant assemble en continu une image de risque en temps réel à partir de ses six Ensembles de Renseignement propriétaires — couvrant le contexte d’appareil, de comportement, d’identité, de compte et de transaction — à chaque point de contrôle du parcours de l’utilisateur, aussi bien dans les applications que sur USSD.

Parce que l’analyse s’exécute silencieusement et continuellement en arrière-plan, la compromission de l’appareil, la reconnaissance, la dérive comportementale, la modification du compte et la configuration du bénéficiaire sont tous perçus au moment où ils se produisent et intégrés à un jugement unique en évolution. Lorsque la transaction arrive enfin, Paygilant ne rencontre pas la fraude pour la première fois — il observe toute l’histoire depuis le début.

La transaction frauduleuse est le dernier signal, pas le premier. Les plateformes qui l’emportent sont celles qui ont cessé de l’attendre.