L'allarme che
nessuno legge

Facciamolo con i numeri veri, perché è un conto che si fa in trenta secondi e che cambia le riunioni. Cinquantamila transazioni al giorno, frodi allo 0,1%: cinquanta frodi. Il tuo modello è buono: prende il 90% delle frodi e ha solo il 1% di falsi allarmi sui casi puliti.

• Frodi prese: il 90% di 50 = 45.
• Falsi allarmi: l'1% di 49.950 = 499.
• Allarmi totali: 544. Di questi, sono frodi 45.

Quando quel sistema suona, la probabilità che sia davvero una frode è l'8%. Undici volte su dodici stai disturbando un cliente onesto. E il modello ha fatto un lavoro eccellente: il 90% di sensibilità e l'1% di falsi allarmi sono numeri che in pochi ottengono.

Il motivo per cui l'intuizione si ribella: pensi «1% di errore, quindi mi sbaglio una volta su cento». Ma quell'1% si applica a quarantanovemilanovecentocinquanta transazioni pulite, mentre il 90% si applica a cinquanta. Sono due numeri moltiplicati per basi diverse di tre ordini di grandezza. La rarità della frode ti sta lavorando contro, e non c'è modello che la annulli.

Le tre conseguenze pratiche, che poi sono il resto di questa risorsa:

1. Migliorare la sensibilità serve a poco. Passare dal 90% al 95% ti dà due frodi in più e non tocca i 499 falsi allarmi. Dimezzare i falsi allarmi, dall'1% allo 0,5%, te ne toglie 250. Il numero da attaccare è quasi sempre quello, ed è quasi sempre quello che nessuno guarda perché il cruscotto mostra la sensibilità.
2. Il resto lo fa il contesto. Un allarme all'8% di probabilità non giustifica di bloccare una carta. Ne giustifica un altro: un SMS di conferma, che costa due centesimi e non fa arrabbiare nessuno. Le azioni si scelgono in base a quanto sei sicuro, e sono più di due.
3. Il conto va fatto in euro, non in percentuali. Quanto costa un cliente disturbato a torto? Quanto costa una frode che passa? Se la seconda vale duecento volte la prima, allora l'8% di probabilità è più che sufficiente per agire, e la tua soglia è troppo alta. È la soglia della risorsa sui punteggi, applicata a un caso dove i due errori differiscono di ordini di grandezza.

Prima di scrivere una riga di codice su un progetto antifrode faccio sempre queste due domande, e nel 90% dei casi non c'è una risposta. Quando non c'è, quello è il progetto.

1. Quanto ci costa un falso allarme? Non «è fastidioso»: quanto, in euro. Ci sono dentro i minuti dell'analista, la telefonata al cliente, la probabilità che quel cliente se ne vada, e il danno reputazionale se blocchi una carta a un pagamento importante. Tipicamente sono fra i 3 e i 40 euro, e la forbice è enorme perché dipende da cosa fai quando l'allarme suona.
2. Quanto ci costa una frode che passa? Non solo l'importo: la pratica di rimborso, il tempo dell'assistenza, la segnalazione, e in certi settori la sanzione. Tipicamente è dieci o cento volte il falso allarme.

Con questi due numeri la soglia si calcola invece di deciderla in riunione, e viene fuori un fatto che sorprende sempre: se una frode passata costa cento volte un falso allarme, ti conviene agire anche su segnalazioni all'1% di probabilità. Cioè accettare novantanove disturbi per fermarne una. È giusto, in aritmetica pura, ed è insopportabile nella pratica, e la contraddizione fra queste due frasi è dove sta tutto il mestiere.

Si scioglie smettendo di pensare che l'azione sia una sola. Il sistema non deve scegliere fra «blocco» e «lascio passare»: deve scegliere fra una scala di azioni con costi diversi, e per ciascuna c'è una soglia diversa.

• Sotto lo 0,5%: niente. Registri e basta, servirà per riaddestrare.
• Fra lo 0,5% e il 5%: attrito invisibile. Un controllo in più che il cliente non vede.
• Fra il 5% e il 30%: conferma leggera. Un SMS, una notifica sull'app. Costa due centesimi, il cliente onesto ci mette tre secondi.
• Sopra il 30%: la pratica va sul tavolo di un analista, e ci va con il punteggio in cima.
• Sopra il 90%, e solo lì: si blocca.

Progettato così, l'8% di probabilità del capitolo 00 smette di essere un problema: non blocca niente, manda un SMS. E il vincolo delle quaranta pratiche al giorno riguarda solo l'ultima fascia, che è piccola. La domanda «qual è la soglia» è mal posta: le soglie sono quattro, e ciascuna corrisponde a una cosa che costa.

La simulazione in cima alla pagina è il capitolo più utile di tutta questa risorsa, e il meno tecnico. Riassumo cosa dimostra, perché è controintuitivo: stesso modello, stessa soglia, stessi allarmi, stessi analisti. Cambia solo l'ordine in cui si aprono le pratiche, e le frodi fermate passano da zero a una dozzina.

Il motivo per cui succede davvero, in azienda, è banale e universale: le code si costruiscono in ordine cronologico perché è il modo naturale di fare una lista. Nessuno decide «lavoriamo dalla più vecchia», è semplicemente come esce dal database se non scrivi un ORDER BY diverso. E in quel momento, senza che nessuno lo scelga, il punteggio del modello, che è l'unica cosa che il progetto ha prodotto, viene buttato via.

Le regole che uso per progettare un sistema del genere, e che valgono anche fuori dalle frodi, ovunque ci sia una coda e delle persone:

1. Parti dalla capacità, non dal modello. Quante pratiche riuscite ad aprire in un giorno? Quaranta. Bene: allora il sistema produce quaranta pratiche al giorno, ordinate per punteggio, e finisce lì. Tutto quello che sta sotto va in un registro che nessuno guarda ma che serve per riaddestrare.
2. La coda si ordina per valore atteso, non per punteggio. Punteggio per importo. Una frode da 12 euro all'80% di probabilità vale meno di una da 8.000 euro al 20%, e l'analista che apre la prima ha buttato via il suo tempo anche se ha ragione.
3. Misura il tasso di conferma, e mostralo. «Di quello che apri, quanto è frode.» Se scende sotto il 20%, il sistema sta bruciando la fiducia degli analisti, ed è un guasto grave anche se nessuna metrica lo segnala. Quel numero va sul cruscotto del capo, non nascosto in un rapporto.
4. Chiudi il giro. Ogni pratica aperta produce un esito: era frode o no. Quello è l'unico dato di addestramento che avrai mai. Se l'analista lo scrive in un campo note in italiano libero, l'hai perso. Deve essere un pulsante con tre opzioni.

Un progetto antifrode si giudica da un numero solo, e l'accuratezza non c'entra: quante frodi fermi con le ore di persone che hai. Tutto il resto sono metriche intermedie che possono migliorare mentre quel numero peggiora, e nella mia esperienza è quello che succede quasi sempre.

Nessuno vuole sentirselo dire, e lo dico lo stesso perché mi ha fatto risparmiare mesi: su un progetto antifrode nuovo, le prime venti regole scritte da chi conosce il mestiere prendono la maggior parte delle frodi che prenderesti con un modello, e le prendono la settimana prossima invece che fra sei mesi.

«Stessa carta, quattro paesi diversi in un'ora.» «Ordine di dieci volte la media, spedizione a un indirizzo mai visto, cliente registrato ieri.» «Reso senza scontrino sopra i 500 euro, terzo in un mese.» Queste sono regole, si scrivono in SQL, si spiegano a chiunque in dieci secondi e non hanno bisogno di nessuno storico etichettato.

La divisione del lavoro che funziona, e che consiglio sempre:

• Le regole prendono il noto. Gli schemi di frode che conosci, quelli che il tuo responsabile ti descrive a memoria. Sono spiegabili, contestabili in tribunale, e quando sbagliano si capisce perché in trenta secondi.
• Il modello prende l'ignoto. Le combinazioni strane che nessuno avrebbe pensato di scrivere. È qui che vale i suoi soldi, ed è un valore reale ma incrementale: arriva dopo le regole, non al posto loro.
• Le regole sono anche la rete di sicurezza del modello. Il giorno che il modello va in deriva e comincia a dire cose strane, le regole continuano a funzionare, perché non hanno imparato niente da nessuna parte.

Due cose sulle regole che si scoprono solo dopo averle messe in produzione. La prima: vanno contate. Ogni regola deve avere il suo tasso di conferma, e quelle che non confermano mai vanno spente. Nei sistemi vecchi trovo sempre una trentina di regole che nessuno osa toccare perché «le ha messe Tizio nel 2019», e che producono metà dei falsi allarmi del capitolo 02.

La seconda, ed è quella che conta: una regola è pubblica. Se il tuo controllo scatta sopra i 500 euro, chi ti frega fa ordini da 499. Il modello ha il vantaggio di essere opaco, e su un problema con un avversario che ti studia quel vantaggio vale parecchio. È il capitolo 05.

Nella maggior parte dei progetti veri non hai un elenco di frodi passate. Hai un sacco di dati e nessuno che ti dica quali righe erano cattive. A quel punto si passa alla rilevazione di anomalie non supervisionata, cioè «trovami le righe strane», e qui c'è un fraintendimento che vale la pena chiarire una volta per tutte:

Un rilevatore di anomalie non trova le frodi. Trova le cose rare. Sono due insiemi diversi che si sovrappongono poco, e la differenza fra i due è il motivo per cui questi progetti deludono quasi sempre.

Il cliente che compra una volta l'anno per centomila euro è rarissimo, ed è il tuo miglior cliente. La transazione a Capodanno alle 3 di notte è rara perché è Capodanno. Il pezzo di produzione con la misura fuori scala è raro, ed è semplicemente il primo pezzo del lotto nuovo. Un sistema che segnala le cose rare ti segnalerà tutto questo, ogni giorno, e sarà tecnicamente corretto.

Quando funziona davvero, e sono tre casi precisi:

1. Quando il normale è veramente omogeneo. Una macchina che gira sempre uguale: lì un'anomalia è un'anomalia. In un flusso di clienti umani il normale ha una coda lunghissima di casi legittimi bizzarri, e il rilevatore ci sbatte contro ogni giorno.
2. Come esploratore, non come allarme. Fantastico per far vedere a un esperto le cinquanta righe più strane del mese e sentirsi dire «questa, questa e questa non mi piacciono». Quelle tre diventano le prime etichette che hai, e da lì parte il capitolo 03.
3. Sui cambi di regime. Non «questa riga è strana», ma «da martedì l'intera distribuzione si è spostata». È molto più robusto, molto più utile, ed è il capitolo 06.

Il percorso che consiglio, e che è l'inverso di quello che viene proposto in genere: parti dalle regole del capitolo 03 per prendere il noto; usa il rilevatore di anomalie solo per generare le tue prime etichette facendo lavorare un esperto un'ora al mese; dopo sei mesi hai qualche centinaio di casi etichettati e a quel punto, e solo a quel punto, il modello supervisionato ha senso ed è quello bravo.

È la differenza che separa le frodi da ogni altro progetto di questo sistema di risorse, e va capita bene perché rovescia parecchie intuizioni. Quando prevedi le vendite, le vendite non stanno cercando di ingannarti. Quando prevedi un guasto, il macchinario non cambia comportamento perché lo stai guardando. Nelle frodi sì. C'è una persona, dall'altra parte, che prova, osserva cosa passa, e si adatta.

Le conseguenze pratiche, tutte spiacevoli:

• Il modello scade da solo. Non perché il mondo cambia, come nel capitolo 06: perché qualcuno lo sta attivamente aggirando. Un modello antifrode fermo da un anno lo hanno aggirato, altro che «stabile». La sua accuratezza sui dati storici resta bellissima, e sul mondo di oggi non vale niente.
• Ogni regola che riveli è una regola che perdi. Se dici a un cliente perché è stato bloccato, e a volte devi dirglielo, gli stai dando la specifica di come non essere bloccato. La spiegabilità qui ha un costo che negli altri progetti non ha, e la tensione fra «spiegare» e «proteggere» non si risolve: si gestisce.
• Il tuo blocco è informazione per loro. Chi prova la carta rubata con un micro-pagamento sta facendo un esperimento, e tu gli stai rispondendo. Passa? Allora la carta è buona. Bloccata? Prova la prossima. Il tuo sistema, rispondendo, insegna.

Cosa faccio, in concreto, che è meno di quanto vorrei ma è quello che funziona:

1. Non rispondere subito con la verità. Un blocco immediato dice «beccato». Un ritardo, una richiesta di verifica, un'approvazione che poi viene ritirata: costano poco e non insegnano niente all'avversario. Questo va progettato con chi si occupa dell'esperienza del cliente, perché ha un costo su chi è onesto.
2. Riaddestra spesso, e con dati recenti. Non per capriccio: i dati di due anni fa descrivono avversari che nel frattempo hanno cambiato mestiere. Un antifrode va riaddestrato ogni mese, ed è la sola famiglia di modelli dove lo dico senza esitare.
3. Monitora il tasso di conferma, non l'accuratezza. Se le pratiche che apri confermano sempre meno, o l'avversario è cambiato o il modello sta scadendo. È l'unica sveglia che suona in tempo, e funziona solo se hai chiuso il giro del capitolo 02.
4. Tieni un pezzo di casualità. Una piccola quota di controlli su transazioni scelte a caso, non segnalate da niente. Costa poco, ed è l'unico modo di scoprire le frodi che il tuo sistema non vede per costruzione: se guardi solo dove il modello ti manda, non scoprirai mai cosa succede dove non ti manda. È l'esplorazione del capitolo sui bandit, con in più che qui c'è qualcuno che ha interesse a starci lontano.

C'è un secondo modo di perdere, e non richiede nessun avversario: il mondo si muove e il modello resta fermo. Cambia il mix dei clienti, esce un prodotto nuovo, si aggiorna l'app e i tempi di sessione si dimezzano, arriva Natale. Il modello continua a girare, la sua accuratezza sui dati di collaudo di due anni fa è sempre quella, e nessuno si accorge di niente.

Il fatto scomodo: la deriva non la vedi guardando il modello. Il modello sta benissimo, fa quello che ha imparato. La vedi guardando due cose, che vanno messe su un cruscotto il primo giorno e non l'ultimo:

1. Le colonne in ingresso. La distribuzione di ogni colonna, questa settimana contro il periodo di addestramento. Se l'importo medio è raddoppiato, o se una colonna è improvvisamente vuota nel 30% dei casi perché qualcuno ha cambiato un form, il modello sta ricevendo un mondo che non ha mai visto. Questo lo puoi misurare subito, senza aspettare gli esiti, ed è il motivo per cui è il primo controllo da mettere.
2. Il tasso di conferma. Di quello che segnali, quanto risulta vero. È il segnale più affidabile che esista e arriva in ritardo, perché aspetta il verdetto degli analisti. Per questo serve l'altro.

Il guasto tipico che trovo: qualcuno ha cambiato un campo a monte, il modello riceve zeri al posto di un valore, e continua a produrre punteggi ragionevolissimi. Nessun errore, nessuna eccezione, nessun allarme. Il sistema è rotto da tre mesi e il rapporto mensile dice che va tutto bene.

Le tre cose che metto sempre, e che costano un giorno di lavoro in tutto:

• Un controllo sulla distribuzione delle colonne, settimanale, con una soglia che manda una mail. Non serve niente di sofisticato: media, mediana e percentuale di valori mancanti, confrontate con l'addestramento.
• Il tasso di conferma su un grafico, con la data dell'ultimo riaddestramento segnata sopra. Quando la linea scende, si vede a occhio.
• Una data di scadenza sul modello. Letterale: dopo sei mesi il sistema scrive nei log che il modello è scaduto. Sembra teatro, e serve, perché senza quella riga non lo riaddestra nessuno mai.

Prendiamo il caso della simulazione: cinquantamila transazioni al giorno, tre analisti, una cinquantina di frodi.

• Il modello: un gradient boosting su una tabella di transazioni. Gira su un portatile, si riaddestra in due minuti, costa zero di licenza e zero di token. Come nella risorsa sulle decisioni, l'infrastruttura qui è arrotondabile a zero.
• Le regole: venti righe di SQL scritte con il responsabile antifrode. Una settimana, ed è la settimana che rende di più di tutto il progetto.
• La coda ordinata per valore atteso: mezza giornata. È l'ORDER BY del capitolo 02, ed è quello che nella simulazione porta le frodi fermate da zero a una dozzina.
• Il giro chiuso: tre pulsanti nell'interfaccia dell'analista al posto del campo note. Due giorni di lavoro, e senza quelli fra un anno non hai ancora un dato di addestramento.

E adesso la voce che non compare mai a preventivo, e che è la più grossa:

Il riaddestramento mensile, per sempre. Chiamarla manutenzione ordinaria è fuorviante: è la condizione perché il sistema continui a esistere. Un antifrode che non si riaddestra da un anno lo hanno già aggirato, e nessuno ha ancora guardato. Se il preventivo che ti fanno non ha dentro una riga ricorrente, quel preventivo è incompleto e il progetto morirà al mese quattordici.

Il ritorno, sui numeri della simulazione: da mezza frode fermata al giorno a una dozzina. Se la frode media vale 400 euro, sono quattromila euro al giorno che prima passavano. Il costo di ottenerli, la prima volta, è un mese di lavoro. Poi c'è la riga ricorrente, che è quella che rende il resto possibile.

Una nota sull'ordine, perché è la domanda che mi fanno sempre. Se stai partendo da zero, l'ordine è: regole (settimana 1), coda ordinata e giro chiuso (settimana 2), modello (mese 3, quando hai le prime etichette vere prodotte dalle settimane 1 e 2). Chi comincia dal modello arriva allo stesso punto sei mesi dopo, e con meno soldi in cassa.

1. Il modello prende il 90% delle frodi e sbaglia solo l'1%. Quando suona, è frode?
   Nell'8% dei casi. Su 50.000 transazioni con 50 frodi, l'1% di errore sulle 49.950 pulite fa 500 falsi allarmi contro 45 frodi prese. Il modello è ottimo: è la rarità che lavora contro.
2. Conviene di più portare la sensibilità dal 90 al 95%, o i falsi allarmi dall'1 allo 0,5%?
   Il secondo, di gran lunga: due frodi in più contro 250 falsi allarmi in meno. E il primo è il numero che sta sul cruscotto.
3. Qual è il vincolo vero di un sistema antifrode?
   Le ore degli analisti. Ne hai quaranta al giorno e non ne avrai di più. Tutto il resto si progetta attorno a quel numero.
4. In che ordine si lavora la coda delle segnalazioni?
   Per valore atteso: punteggio per importo. Se si lavora in ordine di arrivo, che è come esce dal database se non scrivi un ORDER BY, il punteggio del modello viene buttato via nel momento in cui serviva.
5. Il tasso di conferma è al 5%. Cos'è successo?
   Che gli analisti stanno per smettere di guardare la coda, e hanno ragione. È un guasto grave anche se nessuna metrica tecnica lo segnala.
6. Quante azioni deve avere il sistema?
   Più di due. Fra «niente» e «blocco» ci sono l'attrito invisibile e l'SMS di conferma, che costa due centesimi. La domanda «qual è la soglia» è mal posta: le soglie sono una per azione.
7. Regole o modello?
   Prima le regole, che prendono il noto e si scrivono in una settimana. Il modello dopo, per l'ignoto. Chi comincia dal modello arriva allo stesso punto sei mesi dopo.
8. Qual è il difetto di una regola, che il modello non ha?
   È pubblica. Se il controllo scatta sopra i 500 euro, chi ti frega fa ordini da 499.
9. Un rilevatore di anomalie non supervisionato trova le frodi?
   No, trova le cose rare. Il tuo miglior cliente è rarissimo. Serve per generare le prime etichette facendo lavorare un esperto un'ora al mese, non come allarme.
10. Cosa distingue le frodi da ogni altro progetto di previsione?
    C'è qualcuno che ti studia e si adatta. Il modello scade da solo, ogni blocco insegna all'avversario, e il riaddestramento mensile non rientra nella manutenzione, è la condizione di esistenza.
11. Perché controllare a caso qualche transazione non segnalata?
    Perché guardando solo dove il modello ti manda, non scoprirai mai cosa succede dove non ti manda. È l'unico modo di vedere le frodi che il sistema non vede per costruzione.
12. Il modello di credito rifiuta i cattivi pagatori. Cosa non impara mai?
    Come sarebbe andata con quelli che ha rifiutato. Impara solo da chi il credito l'ha avuto, e si auto-conferma. Serve approvare a caso una piccola quota di rifiutati per sapere quanto business stai buttando.

Se hai un sistema di allarmi che gira, c'è una domanda che si risponde in dieci minuti e dice quasi tutto: di quello che aprite, quanto risulta vero? Se nessuno sa rispondere, o se la risposta è sotto il 20%, il progetto è quello, e non passa da un modello nuovo.

Se vuoi guardarla insieme, scrivimi su WhatsApp.