FraudShield — Système Avancé de Détection de Fraude

Projet de Stage de fin d'étude - Bank of Africa Essaouira (BMCE)

Une plateforme bicouche combinant l'analyse de transactions par Deep Learning et le monitoring comportemental de session.

Vue d'ensemble

FraudShield est une solution de pointe conçue pour sécuriser les transactions bancaires en temps réel. Elle repose sur deux piliers technologiques complémentaires :

Module A (MLP) : Détection de fraude au niveau transactionnel basée sur un réseau de neurones (Multi-Layer Perceptron).

Module B (BSM) : Scoring de risque comportemental (Behavioral Session Monitoring) utilisant XGBoost pour sécuriser les transactions sans OTP.

FraudBot IA : Un assistant conversationnel intelligent intégré (via Groq/Llama) pour aider les analystes à interpréter les scores de risque.

Problématique et Objectifs

La fraude bancaire représente un fléau croissant pour les institutions financières. Selon les estimations de l'industrie, les pertes liées à la fraude sur les paiements en ligne atteignent plusieurs milliards de dollars annuellement à l'échelle mondiale. Au Maroc, la digitalisation accélérée des services bancaires expose davantage les clients à des risques de fraude transactionnelle et comportementale.

Deux problématiques distinctes mais complémentaires ont été identifiées :

1. La fraude transactionnelle classique : Détection de transactions frauduleuses basée sur les caractéristiques financières et contextuelles (montant, heure, localisation, catégorie marchande).
2. La fraude comportementale lors de sessions sans OTP : Certaines transactions en ligne ne nécessitent pas de code OTP, créant une faille exploitée par des bots et des fraudeurs qui usurpent l'identité des clients. La problématique est alors : comment distinguer un utilisateur légitime d'un fraudeur, uniquement à partir de son comportement de navigation ?

L'objectif principal est de concevoir, entraîner et déployer une plateforme MLOps complète capable de :

• Analyser des transactions bancaires en temps réel et signaler les fraudes potentielles.
• Évaluer le risque comportemental d'une session de paiement en l'absence d'OTP.
• Fournir aux analystes de la fraude un outil de supervision avec historique, statistiques et assistance IA.
• Maintenir un pipeline de réentraînement automatique avec versionnement des modèles.

Architecture Technique

Backend (FastAPI)

Modèles ML :

TensorFlow/Keras (MLP) pour les transactions.

XGBoost (BSM) pour le comportement utilisateur.

Base de données : Supabase (PostgreSQL) pour l'historique et la persistance.

LLM : Intégration Groq API (Llama 3) pour l'assistant IA.

Frontend (React + Vite)

Interface moderne, réactive et "Premium" avec Dark Mode natif.

Visualisations de données dynamiques (Donuts, Heatmaps, SHAP plots).

Système de gestion d'état fluide pour l'analyse batch et unitaire.

Données et Exploration

Jeu de Données — Module MLP (Transactions)

Source : Dataset Sparkov (Kaggle) — Simulation de transactions bancaires générées synthétiquement par l'outil Sparkov Data Generation.

Caractéristiques :

• Fichier d'entraînement : fraudTrain.csv — 351 MB
• Fichier de test : fraudTest.csv — 150 MB
• Volume total : ~1,3 million de transactions
• Variable cible : is_fraud (binaire : 0 = Légitime, 1 = Fraude)
• Déséquilibre de classes : ~99,5% légitime vs ~0,5% fraude (déséquilibre sévère)

Features brutes disponibles :

• Informations temporelles : date, heure
• Informations géographiques : localisation du marchand, du client, distance calculée
• Informations financières : montant (amt), catégorie de marchand
• Informations démographiques : âge, genre
• Identifiants : numéro de carte, marchand (encodés)

4.2 Analyse Exploratoire (EDA)

L'analyse exploratoire a permis de dégager les observations suivantes :

Patterns temporels :

• Les fraudes sont surreprésentées la nuit (entre 22h et 5h du matin).
• Un pic de fraudes est observé les week-ends.
• Les mois de mai et décembre présentent des taux légèrement supérieurs.

Patterns catégoriels :

• Les catégories grocery_net (épicerie en ligne), shopping_net et misc_net présentent les taux de fraude les plus élevés.
• Les transactions physiques (POS) sont moins sujettes à la fraude que les transactions en ligne (NET).

Patterns financiers :

• Les montants frauduleux suivent une distribution différente : plus de fraudes sur des montants moyens (entre 200 et 800 MAD) que sur des montants très faibles ou très élevés.
• La déviation par rapport au montant moyen habituel du porteur (amt_deviation) est un indicateur fort.

Matrice de corrélation : Les features les plus corrélées avec is_fraud sont : is_night, amt_deviation, distance_km, category_shopping_net, category_misc_net.

Jeu de Données — Module BSM (Comportemental)

Le module BSM repose sur un dataset synthétique généré spécifiquement pour ce projet, simulant des sessions de paiement en ligne avec des profils comportementaux distincts (utilisateur légitime, bot scripté, fraudeur humain).

Variable cible triclasse :

• 0 — Approuver : Session à faible risque, transaction validée automatiquement
• 1 — Challenger : Risque modéré, validation supplémentaire requise (OTP ou autre)
• 2 — Bloquer : Risque élevé, transaction bloquée, alerte levée

Installation & Démarrage

1. Prérequis

Python 3.10+

Node.js 18+

Un compte Supabase et une clé API Groq.

2. Configuration du Backend

cd api
pip install -r requirements.txt

# Créer un fichier .env avec :

# SUPABASE_URL, SUPABASE_KEY, GROQ_API_KEY

python app.py

3. Configuration du Frontend

cd frontend
npm install
npm run dev

Fonctionnalités Clés

Analyse Unitaire & Batch : Testez des transactions isolées ou importez des fichiers CSV (jusqu'à 100 000 lignes).

Dashboard Admin : Statistiques globales, taux de fraude par catégorie et répartition horaire.

Historique BSM : Suivi des sessions suspectes avec analyse des signaux (vitesse de frappe, entropie souris, VPN, etc.).

Interprétabilité (SHAP) : Comprenez pourquoi une session est jugée risquée grâce aux valeurs SHAP intégrées.

Structure du Projet

├── api/                # Serveur FastAPI et logique métier
├── frontend/           # Interface React (Vite)
├── models/             # Artefacts des modèles entraînés (.keras, .pkl)
├── notebooks/          # Pipelines d'entraînement et recherche SHAP
├── data/               # Jeux de données d'entraînement (Sparkov)
└── schema.sql          # Définition de la base de données Supabase