Stripe Radar è eccellente in ciò che fa: assegnare un punteggio a una transazione nel momento esatto in cui il denaro si muove. Ma il momento in cui il denaro non si muove è proprio il punto in cui si nascondeva il nostro problema.
Offriamo una prova gratuita di 7 giorni. Per avviarla, l'utente salva una carta ma non viene mai addebitato: dietro le quinte si tratta di un SetupIntent di Stripe, non di un pagamento. Nessun addebito significa nessun evento legato all'addebito, il che significa che le regole più potenti di Radar non hanno nulla da valutare nel momento che conta di più: quando un account fraudolento viene creato e inizia a bruciare crediti di prova.
Questa è la storia di come siamo passati dallo spegnere incendi in conversazioni una tantum a gestire un livello antifrode automatizzato, minuto per minuto, costruito sopra il nostro stesso prodotto, Zero.
Radar è ottimo. Ma "ottimo" non è "perfetto".
Stripe Radar è davvero bravo in ciò che fa. Addestrato su oltre 1.000 miliardi di dollari di volume di pagamenti annuo, i suoi modelli riconoscono una carta già vista il 92% delle volte, e Stripe riporta che Radar riduce le frodi del 32% in media per le aziende che lo utilizzano.
Rileggete però quel numero: riduce, non elimina. Un calo medio del 32% è notevole, ma significa che una larga fetta della pressione fraudolenta continua ad arrivare alla vostra porta, e Stripe è straordinariamente onesta sul perché. Con le loro stesse parole: "ridurre il numero di falsi positivi spesso aumenta la probabilità che più frodi reali sfuggano tra le maglie della rete." La perdita non è un difetto del modello; è il costo deliberato di non bloccare i vostri clienti reali. Ogni team antifrode sceglie, di proposito, quanto lasciar passare.
Per un prodotto basato sulla prova gratuita, quella falla è più ampia di quanto suggerisca il numero in evidenza, perché la parte più potente di Radar non entra nemmeno in funzione.
Perché una barriera può solo ridurre
C'è una ragione più profonda per cui un motore che agisce al momento dell'addebito può ridurre le frodi ma non eliminarle del tutto, e non riguarda i modelli di Stripe: riguarda tempistica e informazioni. Nell'istante in cui viene aggiunta una carta, il cliente non ha ancora fatto nulla. Nessuno storico di accessi, nessun comportamento sul prodotto, nessun pattern di utilizzo da cui imparare: solo una carta e una manciata di segnali di rete. Radar prende la sua decisione migliore sulla fetta di prove più sottile possibile, nell'unico momento in cui ha meno elementi su cui basarsi.
Questo è il vero limite. Puoi mettere a punto una barriera, ma non puoi darle dati che non esistono ancora. Le informazioni che davvero distinguono un abusatore da un cliente vengono per lo più create dopo che la barriera ha già dovuto decidere.
Fase 1: Spegnere incendi nella finestra di chat
La nostra prima risposta era interamente manuale. Quando arrivava un'ondata di abusi, qualcuno apriva una conversazione con il nostro agente e gestiva l'incidente in tempo reale: estrarre le registrazioni recenti, esaminare le carte, individuare il pattern, chiudere gli account a mano.
Funzionava, ma non era scalabile. Ogni incidente ripartiva da zero. La conoscenza — che aspetto ha questa rete, quali segnali sono affidabili — viveva nella testa di una sola persona e in un solo thread di chat, e svaniva nel momento in cui la finestra si chiudeva.
Abbiamo anche imparato una lezione costosa sul lato buono del funnel: quando volevamo riconquistare utenti autentici che avevano abbandonato il checkout, un'email di contatto incauta verso un indirizzo fraudolento fa danni reali: conferma che l'indirizzo è attivo. Qualsiasi automazione avessimo costruito avrebbe dovuto distinguere tra un potenziale cliente reale e uno piazzato ad arte.
Fase 2: Rinforzare la porta d'ingresso con Radar
La nostra mossa successiva è stata spostare a monte, dentro Radar, tutto ciò che potevamo: liste di blocco e regole di velocità al passaggio di aggiunta della carta, calibrate sulla pressione che stavamo osservando. È la prima mossa giusta, e ha fermato gli attacchi più grossolani.
Ma sono emersi rapidamente due limiti. Il primo è quello che Stripe stessa nomina: un motore che agisce al momento dell'addebito è una leva di compromesso, non un muro — alzala e blocchi clienti reali, abbassala e più frodi passano. Il secondo è strutturale e specifico delle prove: quel 32% si guadagna al momento dell'addebito, e una prova con SetupIntent non ha alcun addebito da valutare. A meno di abilitare esplicitamente Radar sui metodi di pagamento salvati, il motore non entra affatto in funzione, e anche quando lo fa, su un SetupIntent si applicano solo le regole Block, Allow e 3DS. L'azione "Review", quella che concede a un essere umano un secondo sguardo, non scatta mai.
Così il livello con le migliori prestazioni dell'intero stack se ne sta, per impostazione predefinita, in panchina proprio nel momento in cui ne avevamo più bisogno. Radar è una barriera alla porta d'ingresso. A noi serviva una pattuglia dietro di essa.
Fase 3: Un secondo livello, costruito su Zero
Dopo la registrazione, il quadro informativo si capovolge. L'account inizia a lasciare una traccia, e la parte più ricca di quella traccia vive in un sistema che il processore di pagamenti non vede mai: il nostro provider di identità, Clerk.
Così abbiamo dato a Zero l'accesso ad esso. Clerk conosce cose che Stripe non può sapere: come è stato creato l'account, il metodo di registrazione e l'email, la sessione e il dispositivo dietro di esso, e la tempistica precisa rispetto a ogni altra registrazione di quel giorno. Stripe conosce la carta. Nessuno dei due sistemi, da solo, racconta tutta la storia, ma l'agente può leggere entrambi e correlarli tra loro. L'abuso invisibile alla barriera diventa evidente messo a confronto: un account nuovo di zecca la cui identità di accesso non coincide con la sua identità di fatturazione, creato a pochi istanti di distanza da un grappolo di account simili. Quella correlazione tra sistemi è esattamente ciò che una barriera al momento dell'addebito non può fare, ed esattamente ciò che può fare un agente che si appoggia su entrambi i sistemi.
Su questa base di prove più ricca, eseguiamo ogni pochi minuti una serie di attività programmate di Zero sui dati live di registrazione e fatturazione. A guidarle ci sono tre principi:
1. Pattuglia, non limitarti a filtrare. Invece di valutare un singolo momento, l'agente passa al setaccio ogni registrazione recente in un ciclo breve, correlando i dati dell'account e i metadati di pagamento per far emergere gli account che sono sgusciati oltre la porta d'ingresso.
2. Modula la risposta in base alla confidenza. Non ogni segnale merita la stessa azione. I pattern ad alta confidenza vengono gestiti automaticamente: l'account viene sospeso e la sua prova annullata all'istante, perché l'azione è reversibile e il costo dell'attesa è reale. I segnali a bassa confidenza non vengono mai gestiti in automatico; vengono raccolti in un report perché un essere umano li esamini. Decisi dove è sicuro, prudenti dove non lo è.
3. Mantieni una traccia di controllo umana. Ogni azione automatizzata registra il segnale esatto che l'ha innescata, così da poter essere esaminata, e annullata, in pochi secondi. Un'automazione che non puoi verificare è un'automazione di cui non puoi fidarti.
Abbiamo applicato lo stesso rigore al lato amichevole del funnel. Un'attività separata individua gli utenti autentici che hanno abbandonato il checkout e prepara la bozza di un'email di riconquista perché un essere umano la approvi, dietro un filtro antifrode deliberatamente severo, così da non convalidare mai un indirizzo malevolo. Stesso motore, obiettivo opposto.
Cosa ha fatto all'economia del prodotto
Una volta che la pattuglia è entrata in funzione, i numeri si sono mossi immediatamente. Guardate la registrazione al 90° percentile, gli account pesanti che facevano i danni veri. La capacità di calcolo di prova che uno di essi bruciava nelle prime ore è scesa da circa 4 dollari a circa 0,25 dollari, un calo del 94%. Mediata su ogni nuova registrazione nello stesso intervallo, la perdita per account è scesa di circa l'85%.
La forma del cambiamento è ciò che lo rivela. La maggior parte delle registrazioni non ci costava mai nulla; la perdita era sempre concentrata in una lunga e pesante coda di account che esistevano solo per prosciugare i crediti di prova. La pattuglia non ha ridotto il funnel: ha tagliato quella coda. Non meno registrazioni. Registrazioni più pulite.
Perché un agente, e non uno script
Avremmo potuto scrivere un cron job. Non l'abbiamo fatto, per una ragione: la minaccia cambia più velocemente di un ciclo di rilascio. Quando un attaccante cambia tattica, aggiorniamo le istruzioni di un'attività in linguaggio naturale e la nuova logica è attiva all'esecuzione successiva: nessun deploy, nessuna migrazione di schema, nessun ticket. Le "regole" sono un prompt, e il prompt è veloce da cambiare quanto lo è l'attaccante.
Questa è la vera lezione. Radar è lo strumento giusto per il rischio al momento dell'addebito, e ci appoggiamo molto su di esso. Ma un'attività basata sulla prova gratuita ha un punto cieco strutturale che nessuno strumento legato all'addebito può coprire, e la soluzione non è un motore di regole più grande. È un secondo livello rapido, verificabile e sempre attivo, che puoi riprogrammare alla velocità della minaccia.
Spunti per i team basati sulla prova gratuita
- Mappa i tuoi momenti senza addebito. Ovunque un utente ottenga valore prima che un pagamento venga valutato c'è una falla che uno strumento legato all'addebito non può vedere.
- Stratifica, non sostituire. Tieni Radar alla porta d'ingresso. Aggiungi dietro di esso una pattuglia continua post-registrazione.
- Correla tra i sistemi. Il tuo processore di pagamenti e il tuo provider di identità detengono ciascuno metà del quadro. La frode è visibile nella sovrapposizione.
- Modula le tue azioni in base alla confidenza, e registrale tutte. Agisci in automatico solo dove l'azione è reversibile e il segnale è forte; instrada il resto a un essere umano.
- Ottimizza per la velocità di adattamento. Nella lotta alle frodi, vince il team che sa cambiare le proprie regole più in fretta.
Curioso di sapere cosa potrebbe automatizzare un agente sempre attivo nel tuo stack? Esplora Zero.
Note: i dati di Radar sono i numeri pubblicati da Stripe stessa (stripe.com/radar; "A primer on machine learning for fraud detection"). Le cifre di perdita riflettono il costo di calcolo per nuova registrazione nelle prime ore dopo l'iscrizione, misurato su intervalli comparabili prima e dopo il lancio, con gli account interni esclusi; il campione post-lancio è ancora in fase iniziale e si consoliderà nel tempo.