Tradizionalmente, la lotta contro le frodi nei prodotti digitali si basava su rigide regole basate su regole o moderazione manuale, il che portava a un alta carico operativo e alla staticità del sistema. Con lo sviluppo del machine learning, le aziende hanno iniziato a implementare Real-Time Fraud Detection SDK, che valutano ogni transazione per la probabilità di frode. La chiave difficoltà è che qualsiasi classificatore commette errori di due tipi: False Positive (blocco di un utente legittimo) riduce direttamente il ricavo, mentre False Negative (omissione della frode) aumenta i chargeback. È fondamentale per il business misurare il trade-off tra questi errori per ottimizzare le soglie di scoring.
Il classico A/B testing è impossibile, poiché l'omissione intenzionale delle transazioni fraudolente nel gruppo di controllo è inaccettabile dal punto di vista reputazionale e dei requisiti FinCEN/PCI-DSS. Un semplice confronto delle metriche prima e dopo l'implementazione è distorto dalla stagionalità degli attacchi fraudolenti e dall'auto-selezione degli utenti (aggiornano l'applicazione più i clienti fedeli). Gli utenti con alto rischio di frode hanno inizialmente una conversione diversa rispetto a quelli a basso rischio, pertanto un confronto ingenuo tra approvati e rifiutati fornisce una stima distorta a causa del confounding by indication.
Il metodo ottimale è il Sharp Regression Discontinuity Design (RDD) attorno al valore soglia del fraud score (ad esempio, 0.7), dove si verifica un improvviso cambiamento nella probabilità di approvazione da 1 a 0. Confrontiamo le transazioni con score 0.69 (trattamento, approvato) e 0.71 (controllo, rifiutato), presumendo una casualità locale nella finestra di bandwidth (±0.05). Utilizziamo la Local Linear Regression con un nucleo triangolare per stimare il LATE (Local Average Treatment Effect). Per aumentare la precisione, applichiamo Covariate-Adjusted RDD, aggiungendo predittori (storico del dispositivo, geo) come variabili di controllo. Per stimare il ricavo netto calcoliamo il Incremental Revenue: la differenza tra la frode evitata (chargeback previsto) e i ricavi persi dai false positives, identificati tramite RDD.
In un'app mobile di marketplace, dopo l'integrazione del Fraud Detection SDK da un fornitore esterno, la conversione totale in acquisto è diminuita dal 4.2% al 3.5%, mentre il tasso di frode è sceso dal 2.8% allo 0.4%. Il team di prodotto sospettava che il sistema fosse troppo aggressivo e bloccasse utenti legittimi e solvibili, ma non poteva quantificare il problema a causa dell'assenza di un gruppo di controllo.
Opzione A: Confronto semplice della conversione prima e dopo l'implementazione (pre-post analysis). Vantaggi: minimo sforzo lavorativo, non richiede infrastrutture speciali. Svantaggi: ignora completamente la stagionalità (periodo dopo l'implementazione coincide con l'inizio della bassa stagione), auto-selezione durante l'aggiornamento dell'app e cambiamento del mix di marketing (è stato lanciato un nuovo canale con bassa conversione).
Opzione B: Divisione geografica (città Gruppo A con sistema attivo, Gruppo B senza). Vantaggi: crea un vero gruppo di controllo pulito. Svantaggi: tecnicamente impossibile a causa dell'unica base di codice e della cache CDN; gli utenti migrano tra città; il profilo di frode varia notevolmente tra le regioni (eterogeneità orizzontale).
Opzione C: Regression Discontinuity Design basato sul fraud score continuo attorno alla soglia di cut-off 0.65. Vantaggi: utilizza un esperimento naturale, garantisce casualità locale, consente di isolare l'effetto causale per le transazioni "al confine". Svantaggi: richiede un elevato volume di dati nella finestra di soglia; stima il LATE, che potrebbe differire dall'ATE per l'intera popolazione; sensibile alle manipolazioni dello score (i frodatori possono imparare a eludere la soglia).
Opzione D: Synthetic Control Method, creazione di una combinazione pesata di coorti storiche per simulare un gruppo di controllo. Vantaggi: funziona senza un gruppo di controllo fisico, tiene conto delle tendenze temporali. Svantaggi: presuppone che i fattori influenti siano stabili nel tempo; sensibile agli outlier nella pre-elaborazione; difficile da convalidare se non attraverso test placebo.
È stata scelta l'Opzione C (RDD) con bandwidth 0.08 e un polinomio di primo grado. L'analisi ha mostrato che per le transazioni superiori a 15.000 ₽ la percentuale di false positive è doppia rispetto agli acquisti più piccoli. Sulla base di ciò, sono stati impostati soglie dinamiche per le categorie di prodotti.
Risultato: È stato possibile quantificare che 0.6 punti percentuali delle 0.7 perdite di conversione sono attribuibili ai false positives. Dopo la calibrazione delle soglie, è stato recuperato il 45% del ricavo perso (circa 18 milioni di ₽ al mese) mantenendo il 90% di efficacia nel contrastare le frodi.
Come distinguere l'effetto causale dal selection bias, quando gli utenti con alto fraud score hanno inizialmente una minore propensione all'acquisto, anche se i sistemi di frode non esistessero?
Risposta: Questa è una classica problematica di confounding by indication, quando l'indicazione per il trattamento (alto rischio) è correlata all'outcome. In RDD è fondamentale controllare il bilanciamento delle covariate nella finestra di bandwidth: confrontare la distribuzione dell'età del dispositivo, la storia degli acquisti, il geo tra i gruppi appena sotto e appena sopra la soglia. Se si osserva uno squilibrio, è necessario applicare bias-corrected RDD includendo le covariate nella regressione oppure utilizzare l'approccio di Local Randomization, testando formalmente l'ipotesi di casualità della distribuzione. Senza questa verifica, la stima dell'effetto sarà mescolata con le differenze preesistenti tra gli utenti ad alto e basso rischio.
Perché il semplice confronto tra il tasso di approvazione tra utenti che hanno attraversato diverse versioni del modello (v1 e v2) non consente di valutare correttamente l'effetto del miglioramento dell'algoritmo?
Risposta: Questo confronto soffre di selection bias rispetto agli osservabili e compositional drift. Il nuovo modello v2 può essere applicato in modo selettivo (ad esempio, solo a nuovi utenti o in regioni piloto), creando gruppi non comparabili. Inoltre, il miglioramento della qualità dello scoring modifica la composizione degli utenti approvati: v2 può approvare "zone grigie" che v1 rifiutava, ma questi utenti hanno una diversa conversione. Per una valutazione corretta, è necessario utilizzare Offline Policy Evaluation con Inverse Propensity Weighting (IPW) o Doubly Robust Estimation sui log storici, valutando counterfactual, quale ricavo avrebbe generato v1 sulle stesse transazioni di v2.
Come considerare il problema del feedback ritardato, quando la frode viene confermata dopo 30 giorni (chargeback), mentre gli analisti necessitano di una valutazione dell'effetto dopo 7 giorni per decisioni tempestive?
Risposta: Questo crea un problema di dati censurati (censored data) e asimmetria nella valutazione. Per le transazioni degli ultimi 30 giorni, non conosciamo l'etichetta vera (frode/non frode). La soluzione consiste nell'utilizzare l'Analisi di Sopravvivenza (modello dei rischi proporzionali di Cox) per valutare il tempo fino alla frode, in grado di gestire dati incompleti. In alternativa, si possono impiegare Surrogate Metrics (ad esempio, caratteristiche di velocità, cambiamento del fingerprint del dispositivo durante la sessione), che si correlano con future frodi, come proxy. È importante comprendere che i false positives sono visibili immediatamente (rifiuto istantaneo), mentre i false negatives si manifestano con ritardo, distorcendo la precisione verso l'alto nel breve periodo. Per RDD, è consigliabile utilizzare dati "congelati" con lag di 30+ giorni, accettando la perdita di freschezza a favore della correttezza dell'inferenza causale.