Effectuez un backtest avant la mise en service : testez les modifications des règles de surveillance en toute sécurité

Vous pouvez anticiper l'impact d'une modification de règle avant sa mise en application en rejouant l'historique récent avec la configuration proposée et en analysant les décisions qui seraient modifiées. C'est ce qu'on appelle un backtest. Cette méthode répond précisément à une question : sur des événements déjà observés, quelles décisions cette configuration aurait-elle prises différemment ?

Cela ne vous indique pas si la modification est appropriée. Ce jugement repose sur une attente écrite formulée avant le test, et sur les événements individuels qui basculent, et non sur le décompte global. Les équipes qui négligent l'une ou l'autre de ces étapes finissent par approuver des modifications simplement parce que le nombre semble faible.

Que vous apprend réellement un backtest ?

Un backtest consiste à récupérer des événements stockés, à réévaluer chacun d'eux à l'aide des règles candidates, puis à comparer la nouvelle décision avec celle enregistrée initialement. Les résultats utiles sont :

• combien d'événements se déplaceraient entre ALLOW , REVIEW et BLOCK ;

• quels événements se déplacent, et dans quelle direction ;

• quelles règles s'activent plus ou moins souvent avec la nouvelle configuration ?

Dans Toden La surveillance des transactions , et plus précisément l' étape « Tester les modifications » , effectue cette opération avant l'enregistrement. Elle rejoue les événements récemment évalués sous forme de test historique en lecture seule et indique le nombre de décisions qui seraient modifiées. Ce test ne génère aucune alerte, investigation, mise à jour client ni facturation ; il peut donc être exécuté aussi souvent que nécessaire en toute sécurité. Les tests rétrospectifs portent sur un maximum de 1 000 événements enregistrés. La documentation relative aux règles de surveillance (s’ouvre dans un nouvel onglet) décrit la configuration testée.

Pourquoi commencer par écrire le résultat attendu ?

En l'absence d'attente clairement définie, tout résultat de backtest peut être justifié. Une baisse de 3 % REVIEW Ces décisions peuvent sembler avantageuses si vous souhaitiez moins d'alertes et désavantageuses si vous souhaitiez une meilleure couverture.

Rédigez deux ou trois phrases avant d'exécuter le test :

• Le changement : « Augmenter le NGN limite par transaction unique de 2 000 000 ₦ à 3 500 000 ₦.

• La raison : « La plupart des alertes de seuil concernant les clients à compte salaire au cours du dernier trimestre ont été résolues comme étant de faux positifs. »

• Effet attendu : « Seuil moins élevé » REVIEW décisions relatives aux comptes de salaires. Aucun changement à BLOCK décisions. Aucun cas de fraude confirmé du dernier trimestre ne devrait être transféré à ALLOW ."

Ces chiffres sont illustratifs. La dernière phrase est la plus importante : elle énonce le résultat qui vous amènerait à rejeter le changement.

Comment interpréter les décisions qui changent de camp ?

La variation nette masque le mouvement brut. Une configuration qui envoie 30 événements depuis REVIEW à ALLOW et 28 de ALLOW à REVIEW affiche un changement net de 2, mais a modifié 58 décisions.

Triez les feuilles en quatre groupes et lisez un extrait de chaque groupe :

Faites correspondre le premier groupe avec les étiquettes d'alerte. Si un événement se déplace vers ALLOW Si une alerte avait été confirmée comme un vrai positif, la modification aurait supprimé une détection légitime. Une seule de ces alertes suffit à nous faire réfléchir.

Pour les règles personnalisées, vérifiez également qu'elles s'appliquent. Une condition définie sur un champ non transmis par l'intégration affichera zéro déclenchement, ce qui pourrait être interprété à tort comme un « aucun impact ».

Que ne peut pas vous dire un backtest ?

En pratique, quatre limites importent.

L'historique reflète vos décisions passées. Si une configuration antérieure a bloqué une transaction, le client a peut-être abandonné, tenté un autre montant ou changé de fournisseur. Les événements qui auraient dû suivre ne se sont jamais produits. Un test rétrospectif d'une règle moins restrictive observe donc moins de transactions qu'elle autoriserait désormais et peut sous-estimer l'effet.

La période d'analyse est limitée. Un récapitulatif des événements récents peut ne pas inclure un mois calme, un pic saisonnier ou un type d'événement récurrent. Si votre activité connaît des cycles de paie ou des pics d'activité pendant les fêtes, vérifiez si la période d'analyse les couvre.

L'étiquetage peut prendre du temps. Les alertes récentes n'ont peut-être pas encore été traitées. Un événement sans étiquette ne constitue pas une preuve ; par conséquent, toute modification apportée à un événement non étiqueté doit être considérée comme inconnue et non comme une modification sans risque.

Le comportement des consommateurs évolue. Les comportements criminels s'adaptent aux mesures de contrôle, et les comportements légitimes fluctuent en fonction des prix et des produits. Un backtest est une prévision, non une garantie.

Aucune de ces limites ne justifie de ne pas passer le test. Elles incitent plutôt à suivre les résultats en direct après la modification.

Comment passe-t-on d'une proposition de modification à la production ?

Une séquence simple permet de contrôler et de suivre les modifications.

1. Proposez une seule modification. Une seule règle, une seule limite ou une seule pondération. Les modifications groupées ne peuvent être attribuées.

2. Décrivez l'effet attendu, y compris le résultat qui vous amènerait à le rejeter.

3. Exécutez le test de validation dans l'environnement où la modification sera appliquée.

4. Lisez les informations dans les quatre groupes ci-dessus et vérifiez les alertes confirmées.

5. Faites examiner par un deuxième examinateur toute modification qui assouplit une règle. BLOCK ou supprime la couverture d'un risque nommé.

6. Publier comme une nouvelle version. Dans Toden La publication d'une règle relative à la fraude en crée une version immuable ; ainsi, une décision antérieure renvoie toujours à la règle précise qui l'a engendrée. C'est ce qui permet de répondre, un an plus tard, à la question : « Pourquoi cette transaction a-t-elle été autorisée en mars ? »

7. Comparez les résultats en direct avec les prévisions après une période déterminée et notez si les attentes se sont confirmées.

Les autorisations permettent la deuxième étape de révision. Toden Toute personne disposant d'un accès à Risk Intelligence peut consulter la configuration, tandis que la modification nécessite un administrateur.monitoring:manageL'autorisation, afin de pouvoir distinguer ceux qui proposent des changements de ceux qui les appliquent.

La même rigueur s'applique-t-elle aux politiques de suivi continu ?

Oui, à une différence près. Les modifications de règles influent sur la façon dont les événements individuels sont notés. Les politiques de surveillance continue déterminent quels clients sont revérifiés, à quelle fréquence et à partir de quel moment un changement est suffisamment important pour déclencher une alerte.

Toden Les politiques de surveillance sont stockées sous forme de versions immuables. Modifier la fréquence par défaut d'une politique met à jour les clients qui la suivent, mais ne remplace pas celle d'un client ayant spécifié une fréquence différente. Avant de modifier la fréquence par défaut d'une politique, vérifiez combien de clients la suivent et combien ont une fréquence différente, car la modification ne concernera que le premier groupe. La documentation sur la surveillance continue (s’ouvre dans un nouvel onglet) décrit les champs relatifs aux politiques et aux fréquences différentes.

Les questions sont les mêmes que pour les règles : qu’est-ce que vous prévoyez de changer, pour qui, et quel résultat vous inciterait à revenir sur votre décision ?

Une liste de contrôle pour chaque changement de règle

• Une modification par test.

• Effet attendu rédigé avant le test, incluant une condition de rejet.

• Le backtest a été exécuté dans le même environnement que la modification.

• Lecture des basculements par sens, avec vérification croisée des alertes confirmées.

• Deuxième examinateur pour tout ce qui desserre un bloc ou enlève la couverture.

• Publié en tant que nouvelle version avec la raison indiquée.

• Résultats en direct comparés aux prévisions à une date donnée.

Si une modification ne peut être expliquée en ces termes, elle n'est pas prête à être mise en service.