Détection de fraudes en temps réél

La solution SAS de lutte contre la fraude et le blanchiment d'argent SAS AML est un puissant outil permettant la détection de fraudeurs et d'activités illégales perpétrées par des clients d'un organisme. Fonctionnant par batch, il faut donc attendre que le processus de détermination et de générations des alertes soient terminés pour que les alertes puissent être analysées.
Nous allons plutôt voir comment on peut utiliser la solution pour déterminer en temps réél qu'un client est victime d'une fraude.

Imaginons qu'un paiement ait été effectué aux Etats-Unies quelques heures après un retrait avec la même carte en France. On peut imaginer que le numéro de carte bancaire ait été piraté et donc que notre client est victime d'une fraude. On souhaite dans ce cas que le client soit avertie en temps réél et non qu'il ait à attendre que le processus de détermination et de générations des alertes lève l'alerte puis qu'un analyste constate la fraude.

Mise en place de la détection en temps réél

De quoi avons nous besoin ?
- de scénarios propice aux temps réél,
- d'une API d'envoie de SMS pour prévenir le client,
- d'un job qui va :
- monitorer les transactions directement depuis le système source;
- exécuter les scénarios à chaque nouvelle transactions;
- prévenir le client qu'il est peut-être victime d'une fraude.
- d'un service qui va exécuter en continue ce job.

Implémentation des scénarios

Nous allons implémenter les scénarios simples suivants:
- Retraits / paiements effectuées dans des pays différents dans un laps de temps court.
- Plusieurs retraits importants dans la même journée.

En prenant l'hypothèse qu'une carte n'est liée qu'à un compte, ces scénarios sont au niveau compte.

Dans SAS AML, les scénarios analysent les données contenues dans une table appelée prep. Ici nous cherchons de la performance, il faut donc que cette table contienne uniquement les colonnes nécessaires:
- le numéro de compte,
- le numéro de téléphone du client,
- le numéro de transaction et sa clé technique. Celle-ci sert à déterminer les transactions responsables de l'alerte.
- la date de la transaction,
- le montant de la transaction,
- le type de la transaction,
- le pays où a eu lieu la transaction.

La prochaine étape consiste à créer une entête de scénario (Header) dans SAS AML avec les caractéristiques suivantes:
- Niveau compte;
- Type étape data auto-générée;
- Aggrégration sur la colonne numéro de compte;

- fréquence quotidienne.

Ce qui nous donne:

Il ne reste plus qu'à écrire les scénarios.
Pour le premier scénario nous avons besoin des paramètres suivants:
- le type de transaction à monitorer. Nous allons nous limiter à PAIEMENT (sous entendu paiement par carte) et RETRAIT.
- le nombre de transactions minimum (par exemple deux);
- le nombre de pays différent minimum. Prenons deux pays comme minimum.

Ce qui nous donne:

L'algorithme est le suivant :
- Initialisation d'un hash qui va enregistrer la liste des différents pays (exécuter qu'un fois).
- Initialisation à chaque itération d'un compteur du nombre de pays différent à 0. Pour rappel, il y a une itération par niveau de granularité soit compte ici.
- Si le nombre de transactions est au moi même égal au nombre minimum de transactions requis alors on parcours ces transactions:
- Si le type de transaction est celui attendue et que la date de la transaction est celle du jour alors :
- On teste si le pays est déjà dans le hash. Si ce n'est pas le cas, le compteur de pays différent est incrémenté et le pays est ajouté dans le hash.
- Si le compteur du nombre de pays différent est égal ou supérieur au paramètre de pays différent alors une alerte est levée.

Pour le second scénario, nous avons besoin des paramètres suivants:
- le type de transaction à monitorer. Ici seulement RETRAIT.
- le nombre de transactions minimum (par exemple trois);
- le montant total minimum (par exemple 500€).
Ce qui nous donne:

L'algorithme est le suivant :
- Initialisation à chaque itération d'un compteur du nombre de transaction et de la somme des montants des transactions à 0.
- Parcours des transactions:
- Si le type de transaction est celui attendue et que la date de la transaction est celle du jour alors :
- Incrémentation du compteur de transactions et ajout du montant de la transaction.
- Si le compteur de transactions et la somme des montants sont égals ou supérieurs aux paramètres alors une alerte est levée.

Nous pouvons maintenant créer le job qui va alimenter la prep table de ces scénarios et les exécuter.

Création du job de monitoring

Le job ne va pas lire la totalité des données sources mais seulement les nouvelles transactions de type paiement par carte et retrait DAB. Prenons le cas où la table des données sources est en Oracle. Nous pouvons créer un trigger qui va alimenter une table de contrôle:

Les données de cette table vont servir à alimenter la prep du jour mais doivent être enrichie du numéro de téléphone du client. Pour cela deux manières:
- Récupérer le client titulaire du compte à partir de la table FSC_PARTY_ACCOUNT_BRIDGE puis le numéro de téléphone dans la table FSC_PARTY_DIM.
- Utiliser les rest API mis à disposition par la version 7 de la solution SAS AML.

Les besoins de performance trancheront pour déterminer laquelle de ces options utiliser. Pour illuster notre exemple, nous allons plutôt utiliser les rest API qui s'utilisent ainsi:
- Récupération du jeton et du cookie d'authentification (ces éléments seront à fournir dans les entêtes des prochaines requêtes):

- Récupération du client titulaire du compte dans lequel à eu lieu la transaction (la réponse est un fichier JSON):

- Récupération du numéro de téléphone (rest API rest/customers//);
- Récupération des transactions associées aux comptes (rest API rest/customers//transactions/").

La table prep quotidienne est alimentée en mode "ajout" et possède une clé primaire sur le numéro de transactions pour éviter les doublons. Une fois celle-ci prête, les scénarios peuvent être exécutées. Pour cela, nous pouvons utiliser un web service créer à partir du Stored Process standard fcf_sa_test_scenarios_sp. Concrêtement, nous en faisons d'abord une copie pour y ajouter une sortie XML de la table des alertes. Ce web service est appelé à l'aide d'une proc soap dont voici un exemple d'enveloppe:

Nous avons besoin également d'une table qui va capturer les numéros de compte qui ont déclenché une alerte afin de ne pas regénérer d'alertes pour un même compte.

A ce stade nous avons potentiellement des alertes. Il ne reste plus qu'à envoyer un SMS aux clients victimes de la fraude. Il existe de nombreux prestataires qui offre ce genre de service. Pour notre exemple, nous utilisons nexmo qui offre quelques sms gratuit pour tester l'API:

Enfin, les transactions monitorées doivent être supprimées de la table de contrôle pour éviter de les traiter une seconde fois.

Voici un exemple d'implémentation de ce processus avec SAS Data Integration Studio:

Il ne reste plus qu'à créer un service qui va exécuter en boucle le job SAS par exemple un démon Linux. Concrêtement, le démon fera une pause d'une minute à la fin de chaque itération permettant au job d'avoir le temps de s'exécuter. Il s'agit donc plutôt d'un direct en léger différé !

Vidéo en direct léger différé

Voici une petite vidéo illustrant ce que l'on vient de mettre en place.

Merci de votre lecture.