Gestion des dossiers de fraude : quelles alertes examiner ?
Le lundi matin, la file des alertes fraude est déjà triée par score. Pendant la nuit, les alertes à faible score du week-end ont été classées automatiquement. La liste semble bien ordonnée : celles qui sont encore affichées attendent qu’on décide si elles justifient l’ouverture d’un dossier, tandis que celles qui ont disparu ne laissent aucune tâche à traiter. Pourtant, l’une des alertes écartées concernait une demande liée à un appareil. Vendredi, un autre analyste avait confirmé comme frauduleuse une demande associée à ce même appareil. La file apparaît donc après le tri et le traitement automatique, sans que l’on sache encore ce que cette alerte manquante implique pour les dossiers en cours.
La gestion des dossiers de fraude intègre les demandes liées à l’examen
La gestion des dossiers de fraude commence avec une alerte et se termine par une décision consignée. Le dossier rassemble les informations disponibles, attribue un examen à un analyste si nécessaire et conserve la décision pour la suite du traitement.
Un dossier regroupe l’alerte, le client et sa demande, les demandes liées enregistrées comme fiches, la tâche attribuée et son échéance, le résultat et la note de l’analyste, ainsi qu’un mémo et un journal d’activité. Un modèle de dossier définit les fiches, les tâches et les décisions d’un traitement qui reste ouvert le temps que de nouvelles informations arrivent. Il ne s’agit pas d’un simple appel de décision.
Dans une file, une alerte indique généralement les règles antifraude déclenchées pour une demande. Une règle peut aussi repérer une activité répétée sur une période donnée. Pourtant, un même appareil, numéro de téléphone, e-mail ou compte peut apparaître dans d’autres demandes qui semblent ordinaires lorsqu’on les examine isolément. Les équipes recherchent parfois ces éléments manuellement, voire pas du tout. La gestion de dossiers permet aussi de réunir les tâches de vérification répétitives et les éléments du dossier, comme le présente cet aperçu de la gestion de dossiers dans la lutte contre la fraude.
Les demandes liées peuvent modifier le traitement d’une alerte
La confirmation d’une fraude sur une demande liée oriente vers un examen une alerte au score faible. Dans l’exemple, la fraude sur A-1042 a été confirmée vendredi. Lundi, A-1101 arrive avec le même appareil et aucun signal qui lui soit propre. Une règle fondée uniquement sur le score de A-1101 écarterait l’alerte.
Les règles de fraude génèrent de nombreuses alertes qui sont finalement classées sans fraude. Les équipes établissent donc des priorités au lieu d’examiner chaque alerte individuellement. Mais si le traitement ne dépend que du score de l’alerte, les éléments réutilisés sur plusieurs demandes peuvent passer inaperçus.
Dans l’exemple, une tâche évalue les signaux propres à chaque alerte, puis transmet leur niveau et les demandes liées à une tâche d’analyse du réseau, qui détermine le traitement. Les règles sur les signaux et le réseau ont été testées sur ces alertes dans l’environnement de test de Decisimo.
Les résultats replacent la décision liée au faible score dans son contexte :
| Alerte | Signaux | Points, niveau | Liens, fraudes avérées | Orientation |
|---|---|---|---|---|
| Demande sans anomalie, ancien e-mail, même pays | aucun | 0, low | 0, 0 | clear |
| Nouvel e-mail, adresse IP à l’étranger | nouvel e-mail, pays de l’adresse IP différent | 2, review | 1, 0 | review |
| Peu de signaux, appareil lié à une fraude avérée | aucun | 0, low | 2, 1 | review |
La demande sans anomalie est levée. Celle qui présente un nouvel e-mail et un pays différent pour l’adresse IP est examinée en raison de ses propres signaux. A-1101 n’a aucun signal propre, mais l’une de ses deux demandes liées est confirmée comme frauduleuse.
Intégrer les demandes liées au dossier
Les demandes liées doivent arriver avec l’alerte. L’analyse des liens, une autre source de données ou le système à l’origine de l’alerte fournit ces relations. Le dossier conserve les demandes sous forme de fiches et permet de les prendre en compte dans le traitement.
La tâche Linked applications examine les demandes qui partagent un numéro de téléphone, un e-mail, un appareil ou un compte bancaire avec la demande à l’origine de l’alerte. Elle compte les demandes liées et celles qui sont confirmées comme frauduleuses, définit le traitement et crée une fiche pour chaque demande. Chaque fiche est identifiée par l’identifiant de la demande. Si la même demande arrive de nouveau dans le dossier, sa fiche est mise à jour au lieu d’être dupliquée.
Cette tâche reçoit les demandes liées et produit des fiches ainsi qu’un traitement pour le dossier.
La section Flow du modèle montre comment les tâches lisent des informations et produisent des résultats que d’autres tâches peuvent utiliser.
L’outil d’analyse des liens de fraude peut aider à repérer les demandes qui partagent des éléments. Sa démonstration présente 11 demandes sans étiquette situées à deux liens ou moins d’une fraude connue, dont 5 dans un groupe de 8 demandes. Ces résultats montrent quelles demandes sans étiquette sont proches d’une fraude connue. La démonstration indique cette proximité, pas les scores des alertes. Comparez ces résultats aux décisions prises à partir des seules alertes avant de déterminer le traitement qui aurait été appliqué.
Présenter les liens du réseau lors de l’examen par l’analyste
L’analyste doit examiner ensemble les signaux de l’alerte et les décomptes du réseau. La revue est confiée au rôle Fraud analyst, avec une échéance de 24 heures. La section Review info présente les signaux et les décomptes du réseau, et demande de renseigner une issue et une note d’analyste.
L’analyste peut examiner les éléments partagés avec l’alerte. Le Review info et le graphique de la tâche humaine présentent les informations du dossier et les relations dans la tâche où la décision est prise.
Pour A-1101, le graphique la relie à A-1042 par un appareil partagé et à A-1043 par un numéro de téléphone partagé. Une règle de nœud inclut les demandes, et deux règles de lien relient chacune d’elles à l’appareil ou au numéro de téléphone qu’elles ont en commun.
Quand l’analyste confirme une fraude, le dossier peut ajouter l’appareil, le numéro de téléphone, l’e-mail ou le compte partagé à une liste de blocage. Une demande ultérieure utilisant cette valeur peut alors être refusée, et les demandes liées déjà acceptées peuvent être réexaminées.
Définir le traitement avant de lever la prochaine alerte
Revenons à la file du lundi. Une alerte à faible score peut nécessiter un examen si l’appareil, le numéro de téléphone, l’e-mail ou le compte qu’elle partage la relie à une fraude confirmée. Le dossier doit prendre en compte les signaux propres à l’alerte et les demandes qui lui sont liées avant de la lever.
- Définir ce qui transforme une alerte en dossier, les issues possibles, le rôle chargé de l’examiner et le délai prévu. Nommer les issues : « cleared », « confirmed_fraud » ou « not_fraud ».
- Évaluer les signaux propres à l’alerte dans une tâche et les demandes liées dans une autre, afin que l’orientation tienne compte des deux résultats.
- Intégrer au dossier les demandes liées transmises avec l’alerte, depuis l’analyse des liens ou le système à l’origine de l’alerte, et conserver un seul enregistrement par identifiant de demande.
- Ne classer automatiquement l’alerte sans suite que si les signaux sont faibles et qu’aucune demande liée n’est confirmée comme frauduleuse.
- Présenter les signaux et les décomptes du réseau dans Review info, puis afficher les demandes liées et les valeurs partagées dans le graphique de la tâche.
- Quand l’analyste confirme une fraude, ajouter au blocage, depuis le dossier, l’appareil, le numéro de téléphone, l’adresse e-mail ou le compte partagé.
- Charger les demandes du mois dernier dans l’outil d’analyse des liens de fraude et examiner les demandes sans étiquette proches de fraudes avérées. Les comparer aux décisions fondées uniquement sur les alertes pour repérer celles qui auraient été classées sans suite d’après leur seul score.
Questions fréquentes sur la gestion des dossiers de fraude
Qu’est-ce que la gestion des dossiers de fraude ?
La gestion des dossiers de fraude transforme une alerte en dossier, rassemble les informations disponibles, attribue un examen et enregistre la décision pour les traitements ultérieurs. Définissez le contenu du dossier, le rôle chargé de l’examiner et les résultats qu’il peut consigner.
Que doit faire un système de gestion des dossiers de fraude ?
Il doit conserver les fiches, les tâches, les attributions, les échéances et les décisions du dossier, et permettre à l’équipe d’enregistrer les résultats et leurs conséquences. Le traitement, les informations d’examen et les actions après confirmation d’une fraude sont à configurer selon les décisions prises par les analystes.
Comment traiter les alertes de fraude liées ou en double ?
Intégrez les demandes liées au dossier sous forme de fiches identifiées par l’identifiant de la demande. Si la même demande arrive de nouveau dans ce dossier, sa fiche est mise à jour. Les éléments partagés peuvent servir au traitement et à l’examen par l’analyste.
Quelles alertes de fraude peut-on lever automatiquement ?
Une alerte ne doit être levée automatiquement que si ses propres signaux sont faibles et qu’aucune demande liée n’est confirmée comme frauduleuse. Dans le modèle testé, A-1101 est orientée vers un examen parce qu’une demande liée est confirmée comme frauduleuse. La règle de levée automatique doit vérifier ces deux conditions.
Quelles informations l’analyste doit-il voir pour décider du traitement d’une alerte de fraude ?
Pour examiner une alerte, l’analyste a besoin de ses signaux, des décomptes du réseau, des demandes liées et des valeurs qu’elles partagent. Présenter ces éléments dans Review info et le graphique, puis recueillir l’issue et une note.
Que se passe-t-il après la confirmation d’une fraude par l’analyste ?
L’appareil, le numéro de téléphone, l’e-mail ou le compte partagé peut être ajouté à une liste de blocage depuis le dossier. Les demandes liées déjà acceptées peuvent être réexaminées. Prévoyez la mise à jour de la liste dans le traitement du résultat de fraude confirmée.
Quel seuil de score faut-il fixer pour envoyer une alerte de fraude en examen ?
Définissez le seuil de score faible à partir des résultats des alertes et de la capacité d’examen, puis exigez une deuxième condition avant toute levée automatique : aucune demande liée ne doit être confirmée comme frauduleuse. Un seuil de score seul peut entraîner la levée d’une demande utilisant un appareil déjà associé à une fraude. Vérifiez de nouveau ce seuil au regard des résultats confirmés, en particulier après toute modification des signaux d’alerte ou des sources de liens.
Une seule demande liée confirmée comme frauduleuse suffit-elle à empêcher une levée automatique ?
Oui, si le lien repose sur un identifiant pertinent, comme un appareil ou un compte, et que la demande liée a été confirmée comme frauduleuse. L’alerte doit alors être examinée par un analyste, même si ses propres signaux sont faibles. Un numéro de téléphone ou un e-mail partagé peut aussi relier des demandeurs légitimes. Il faut donc présenter la valeur partagée et la raison du lien, plutôt que de considérer toute relation comme une preuve.
Comment tester une règle de levée automatique avant de l’activer ?
Rejouez les demandes récentes avec le traitement envisagé, notamment les alertes à faible score liées à des fraudes confirmées, celles sans lien, les identifiants de demande répétés et les données de liens manquantes ou tardives. Comparez les traitements aux résultats consignés par les analystes et estimez le nombre de dossiers qui seraient examinés. N’activez pas la levée automatique si des données de liens manquantes sont traitées comme une absence de lien au lieu d’orienter l’alerte vers un examen.
