Cosa mi ha insegnato un corso di iGaming sui sistemi antifrode

Ho fatto il corso Anti-Fraud and Payments Handling della iGaming Academy aspettandomi una lista di regole per bloccare transazioni cattive. Quello che mi ha davvero insegnato è che l'antifrode è soprattutto una serie di giudizi, e quasi nessuno di essi ha una risposta giusta e netta.

La prevenzione delle frodi è un compromesso, non un filtro

L'istinto è pensare al fraud detection come un filtro: transazioni cattive da una parte, buone dall'altra. I sistemi reali non funzionano così, perché le regole che catturano più frode catturano anche clienti veri, e ogni cliente legittimo che blocchi è ricavo perso più una persona che probabilmente non tornerà.

Quindi la domanda non è mai "questa regola cattura la frode." È "quanto costa questa regola quando sbaglia, e quanto spesso sbaglierà." Una regola che cattura il 90% della frode ma rifiuta il 5% dei clienti genuini può facilmente essere peggiore per un business di una regola che ne cattura il 60% e non ne rifiuta quasi nessuno.

Non ogni decline significa la stessa cosa

Questa è stata di gran lunga la distinzione più utile del corso. Una transazione declined può significare fondi insufficienti, un timeout di rete, una carta segnalata rubata, o una banca che blocca una transazione che ha trovato sospetta. Sono segnali completamente diversi che capitano di arrivare tramite lo stesso canale.

Fondi insufficienti è una condizione temporanea, quindi riprovare più tardi o tramite un'altra rotta è ragionevole. Una carta segnalata rubata è una risposta permanente e definitiva, e riprovarla altrove significa cercare di far passare una transazione fraudolenta attraverso un acquirer che non l'ha ancora individuata. Trattare queste due risposte in modo identico è come un sistema di pagamento finisce per perdere vendite legittime oppure riciclare frode.

I pattern contano più delle singole transazioni

Una singola transazione di solito non dice molto da sola. Un pagamento di 50 € non è degno di nota. La stessa carta che produce tentativi rifiutati ripetuti in una finestra breve è una storia completamente diversa, perché è così che appare il card testing: qualcuno con una lista di carte rubate che controlla quali sono ancora attive prima di spenderle.

Questo ha cambiato come penso ai dati che un sistema di pagamento deve salvare. Le regole che vedono solo la transazione attuale non possono rilevare un pattern, quindi la cronologia deve esserci e deve essere interrogabile al momento della decisione, non solo archiviata per il reporting successivo.

L'evidenza fa parte del prodotto

La parte a cui non avevo affatto pensato prima del corso: quando un acquirer o un regolatore chiede perché una transazione è stata approvata o rifiutata, "ha deciso il sistema" non è una risposta. Serve il record di cosa è stato controllato, quale è stato il risultato, e quale regola è scattata.

Questo ha ridefinito la persistence per me. Nella maggior parte dei progetti il database è dove vive lo stato. Nei pagamenti è anche l'audit trail, e cancellare un record di pagamento non è pulizia, è distruggere prove.

I dati di carta hanno regole proprie

Salvare i numeri di carta completi non è una decisione da prendere alla leggera, è un obbligo di compliance con requisiti reali legati ad essa. La versione pratica per un progetto come il mio è semplice: tieni il BIN e le ultime quattro cifre, che bastano a identificare una carta tra le transazioni e mostrare a un cliente quale carta ha usato, e non salvare mai il resto.

Cosa ne ho tratto davvero

Il corso ha cambiato cosa penso sia un sistema antifrode. Non è un muro che metti davanti ai pagamenti. È un insieme di decisioni sul rischio accettabile, prese con informazioni incomplete, dove essere troppo aggressivi costa soldi veri ed essere troppo permissivi costa di più. Costruire PayMaestro dopo è stato soprattutto un esercizio nel trasformare quei giudizi in codice che potesse davvero essere ispezionato e spiegato più avanti.