Des règles de surveillance des transactions qui détectent les risques plutôt que le bruit.

Une règle de surveillance des transactions est pertinente lorsqu'elle remplit trois conditions : elle correspond à un risque réel, elle s'active sur les données réellement envoyées et elle génère des alertes que l'analyste peut clôturer en s'appuyant sur une justification claire. Une règle qui échoue à l'un de ces tests engendre une charge de travail supplémentaire sans améliorer la détection.

Le réglage découle du même test. Il faut évaluer une règle en fonction du traitement de ses alertes (confirmées, résolues, non concluantes), et non en fonction de leur nombre. Une règle qui génère 40 alertes par semaine et en confirme 6 peut être plus efficace qu'une règle qui en génère 5 et n'en confirme aucune.

Pourquoi la plupart des programmes de surveillance sont-ils submergés d'alertes ?

Le volume d'alertes augmente généralement pour des raisons prévisibles, et la plupart d'entre elles sont liées à des choix de configuration plutôt qu'à des activités criminelles.

• Des règles copiées d'un modèle, et non d'une évaluation des risques. Une règle concernant les activités impliquant de nombreuses transactions en espèces n'a guère de sens pour un portefeuille qui ne manipule jamais d'argent liquide.

• Un seuil de montant unique par client. Une limite fixée pour les utilisateurs salariés du secteur du commerce de détail sera appliquée en permanence aux commerçants, mais jamais à un compte étudiant utilisé comme intermédiaire.

• Des règles qui lisent des champs que personne n'envoie. Soit elles ne se déclenchent jamais, ce qui crée un faux sentiment de sécurité, soit elles se déclenchent avec des valeurs par défaut qui n'ont aucune signification.

• Des alertes en double pour un même comportement. Dix paiements enfreignant la même règle au cours d'une même journée génèrent dix tickets, sauf si les doublons sont regroupés.

Chacun de ces problèmes peut être résolu avant même de toucher un seul poids.

Quelles règles sont pertinentes pour votre entreprise ?

Partez du produit, et non du catalogue de règles. Le tableau ci-dessous illustre quatre modèles commerciaux courants. Il ne s'agit pas d'une liste exhaustive des exigences réglementaires ; la liste finale doit être établie en fonction de votre propre évaluation des risques.

Deux règles méritent une attention particulière car, bien qu'elles paraissent sophistiquées, elles dépendent de l'histoire.

La règle de référence pour l'anomalie compare un montant à la valeur normale pour ce client. Un nouveau client n'ayant pas d'historique, la comparaison se fait à partir d'une cohorte existante jusqu'à ce qu'un nombre suffisant d'événements soit disponible. Il faut donc s'attendre à des fluctuations plus importantes durant les premières semaines de la relation client.

La règle de la période d'inactivité puis de la réactivation n'est pertinente que si l'inactivité est inhabituelle. Pour un produit d'épargne où plusieurs mois d'inactivité sont la norme, il est préférable d'allonger la période d'inactivité ou de minimiser l'importance de cette règle.

De quelles données chaque règle a-t-elle besoin avant de pouvoir être déclenchée ?

Il s'agit d'une défaillance silencieuse courante. Les règles comportementales lisent des champs spécifiques, et une règle avec un poids mais sans ses champs ne se déclenche jamais. La file d'alertes semble calme, mais ce calme apparent est trompeur.

Avant tout réglage, vérifiez la couverture. Toden Le système de surveillance des transactions (évaluation en temps réel des transactions et des événements clients) affiche un panneau de configuration des règles signalant les règles pondérées mais non configurées. La documentation relative aux règles de surveillance (s’ouvre dans un nouvel onglet) répertorie les champs lus par chaque règle intégrée.

Un exemple concret : un PSP Le système envoie le montant du paiement, la devise et l'identifiant du client, mais pas la contrepartie, car il stocke les bénéficiaires dans une table distincte. Ses règles de contournement et d'ajout de nouveaux bénéficiaires, pondérées à 0,6, n'ont jamais été déclenchées. La solution consiste à modifier l'intégration, et non les règles : ajouter la référence de la contrepartie à chaque événement.

Comment les limites de montant doivent-elles fonctionner selon les devises et les types de clients ?

Un seuil global unique tend à produire simultanément des faux positifs et des faux négatifs. Deux mécanismes permettent d'y remédier.

Limites par devise. Un plafond fixé en dollars américains n'apporte aucune information pertinente concernant un transfert en nairas ou en shillings une fois la conversion effectuée au taux de change en vigueur. Toden Le système fixe des plafonds dans une devise de base, avec des dérogations possibles par devise. Ainsi, une limite de 5 000 000 ₦ par transaction et une limite de 5 000 $US peuvent coexister, chacune s'appliquant aux opérations effectuées dans sa propre devise. Ces chiffres sont donnés à titre indicatif ; définissez les vôtres en fonction de vos données de transaction.

Valeurs de référence par client. Lorsqu'un produit s'adresse à des clients très différents, une règle de référence permet de détecter une augmentation anormale pour une personne donnée, même si elle reste inférieure à une limite globale.

La règle de structuration dépend de la limite par transaction. Toden Le système recherche une série d'au moins trois transactions dans la même devise, atteignant entre 70 et 100 % de la limite, sur une période donnée. Si la limite est fixée bien au-dessus de l'activité normale, la plage surveillée est vide et la règle ne se déclenche jamais. Si elle est fixée trop bas, des clients ordinaires seront inclus dans cette plage. Il est donc conseillé de définir d'abord la limite, puis d'évaluer la validité de la règle.

Comment les pondérations et les seuils transforment-ils les règles en une décision ?

Chaque règle produit un signal compris entre 0 et 1. Toden Ces signaux sont pondérés en un score composite unique à l'aide d'un OU souple : un signal fort peut à lui seul faire grimper le score, et les signaux suivants l'augmentent avec un effet décroissant. Le score est ensuite comparé à deux seuils.

Cette forme a une conséquence pratique. Les pondérations indiquent le degré de fiabilité d'une règle prise individuellement. Une règle sur laquelle on n'agirait jamais seule (arrondir les montants, par exemple) a une faible pondération et n'est donc pertinente qu'en parallèle avec d'autres. Une règle quasi-déterminée (une contrepartie figurant sur votre liste noire) a une pondération proche de la valeur maximale.

Lorsque les règles intégrées ne décrivent pas un scénario, une règle personnalisée peut le faire. Une règle personnalisée est un arbre de conditions construit à partir deall,anyetnot, avec son propre score et son propre poids, et il tire en cas d'alerte commecustom:<name>Choisissez un nom significatif, car les enquêteurs le liront sur chaque alerte et il apparaîtra sur SAR rapports.

Comment ajuster une règle sans deviner ?

Le réglage nécessite des résultats. Une alerte fermée sans étiquette ne vous apprend rien ; rendez donc l’étiquette obligatoire avant la fermeture. Toden permet aux analystes de déterminer si une alerte est un vrai positif, un faux positif ou non concluante, et les déclenchements répétés des mêmes règles sur le même client sont regroupés en une seule alerte, de sorte que chaque étiquette reflète un seul comportement plutôt que dix tickets.

Un cycle de réglage qui fonctionne en pratique :

1. Choisissez une règle à la fois. Modifier trois pondérations simultanément rend le résultat impossible à attribuer.

2. Consultez ses étiquettes récentes. Comptez les alertes confirmées, résolues et non concluantes sur une période suffisamment longue pour inclure votre cycle d'activité normal.

3. Examinez attentivement les alertes résolues. Dix faux positifs provenant d'une même catégorie de commerçants indiquent un problème de segmentation, et non de seuil.

4. Proposez la modification minimale permettant de corriger la tendance. Il s'agit souvent d'une limite par devise ou d'une exclusion de contrepartie, et non d'une pondération moindre.

5. Testez-le par rapport à l'historique avant de l'enregistrer.Le test de Toden rejoue en lecture seule des événements récemment évalués et indique combien de décisions changeraient, sans créer d’alerte ni de frais supplémentaires.

6. Consignez la raison. Notez ce qui a changé, pourquoi et ce que vous attendez. La prochaine évaluation devra vérifier ces attentes.

Deux erreurs à éviter méritent d'être soulignées. Augmenter le seuil de revue pour réduire le volume d'alertes supprime simultanément toutes les alertes de toutes les règles, y compris celles qui fonctionnaient correctement. Supprimer une règle parce qu'elle génère trop d'alertes revient à supprimer la couverture d'un risque que vous aviez pourtant identifié ; si ce risque est toujours présent dans votre évaluation, il est préférable de corriger la règle.

Une règle de décision pour chaque règle de votre bibliothèque

Avant qu'une règle ne reste en vigueur, elle doit passer les vérifications suivantes :

• Il identifie le risque couvert par votre évaluation des risques.

• Les champs qu'il lit sont présents dans les événements en direct, et vous avez confirmé qu'il s'est déclenché au moins une fois lors des tests.

• Son poids reflète le degré de confiance que vous lui accorderiez en lui-même.

• Ses limites sont fixées par devise lorsque votre livre est multidevises.

• Ses alertes sont clôturées par une étiquette, et ces étiquettes sont vérifiées régulièrement.

• Chaque modification apportée à ce document a été confrontée à des événements historiques et consignée par écrit avec une justification.

Une règle qui ne résiste pas à ces vérifications ne vous protège pas. Elle est soit silencieuse, soit bruyante, et dans les deux cas, elle vous coûte cher.