Introduction
Dans un monde de plus en plus numérique, la détection de la fraude transactionnelle est devenue cruciale. Bien que l'apprentissage automatique et les bases de données graphiques soient souvent vantés, l'outil le plus fiable reste souvent le bon vieux SQL. Voyons ensemble six patterns SQL qui te permettront de repérer efficacement les anomalies dans les transactions.
1. Vélocité des transactions
La vélocité est l'un des signaux les plus simples et les plus puissants. Lorsqu'une carte est volée, le fraudeur essaie généralement de l'épuiser avant que le titulaire ne le remarque. Pour capturer cela, tu peux utiliser une requête SQL qui regroupe les transactions par détenteur de carte et par tranches horaires :
``sql SELECT cardholder_id, date_trunc('hour', timestamp) AS hour_bucket, count() AS tx_count FROM transactions WHERE timestamp >= current_date - INTERVAL '30 days' GROUP BY 1, 2 HAVING count() > 10; ``
Cette requête te permet d'identifier les détenteurs de carte qui effectuent un nombre anormalement élevé de transactions en une heure. Tu peux ajuster le seuil et la fenêtre temporelle selon tes besoins.
2. Voyage impossible
L'idée est simple : si une carte est utilisée à deux endroits éloignés en un court laps de temps, il y a de fortes chances qu'elle soit clonée. Voici une requête qui détecte ces anomalies :
``sql WITH ordered_tx AS ( SELECT cardholder_id, timestamp, location, LAG(timestamp) OVER (PARTITION BY cardholder_id ORDER BY timestamp) AS prev_ts, LAG(location) OVER (PARTITION BY cardholder_id ORDER BY timestamp) AS prev_loc FROM transactions ) SELECT cardholder_id, prev_ts AS first_tx, timestamp AS second_tx, prev_loc AS first_location, location AS second_location, EXTRACT(EPOCH FROM (timestamp - prev_ts)) AS time_diff FROM ordered_tx WHERE time_diff < 420 AND prev_loc != location; ``
Ici, nous vérifions les transactions qui se produisent en moins de sept minutes entre deux lieux différents.
3. Transactions par paire suspecte
Il s'agit de repérer des transactions répétées entre les mêmes paires d'entités, ce qui peut indiquer un schéma de fraude. Utilise cette requête pour détecter ces patterns :
``sql SELECT sender_id, receiver_id, count(*) AS tx_count FROM transactions WHERE date >= current_date - INTERVAL '30 days' GROUP BY sender_id, receiver_id HAVING tx_count > 5; ``
Cette approche te permet de surveiller les relations suspectes entre deux comptes ou entités.
4. Montant de transaction inhabituel
Les montants atypiques peuvent également signaler une fraude potentielle. Par exemple, une transaction très élevée ou très basse par rapport à la moyenne habituelle d'un utilisateur. Voici comment détecter cela :
``sql SELECT cardholder_id, amount, avg(amount) OVER (PARTITION BY cardholder_id) AS avg_amount FROM transactions WHERE amount > 2 * avg_amount; ``
Cette requête identifie les transactions qui sont deux fois supérieures à la moyenne de l'utilisateur.
5. Utilisation suspecte des cartes de crédit
Certaines cartes de crédit peuvent être utilisées de manière anormale, par exemple, être actives dans des zones géographiques où le titulaire ne se rend jamais. Utilise cette requête :
``sql SELECT cardholder_id, location, count(*) AS location_count FROM transactions WHERE date >= current_date - INTERVAL '30 days' GROUP BY cardholder_id, location HAVING location_count > 10; ``
Cela t'aidera à repérer les cartes utilisées de manière excessive dans des lieux inhabituels.
Conclusion
La détection de la fraude transactionnelle ne nécessite pas toujours des outils sophistiqués, mais plutôt des requêtes SQL bien pensées. En appliquant ces patterns à tes données, tu peux identifier rapidement et efficacement les comportements suspects. Discutons de ton projet en 15 minutes.