Stripe Radar är utmärkt på det den gör: att poängsätta en transaktion i samma ögonblick som pengar rör sig. Men just när pengar inte rör sig uppstår vårt problem.
Vi erbjuder en gratisperiod på 7 dagar. För att starta den sparar användaren ett kort men debiteras aldrig – i bakgrunden är det en Stripe SetupIntent, inte en betalning. Ingen debitering innebär ingen händelse vid debitering, vilket gör att Radars mest kraftfulla regler inte har något att utvärdera när det är som viktigast: när ett bedrägligt konto skapas och börjar förbruka gratisperiodens krediter.
Det här är berättelsen om hur vi gick från att släcka bränder i enskilda chattar till att köra ett automatiserat, minut-för-minut-bedrägerilager – byggt ovanpå vår egen produkt, Zero.
Radar är bra. "Bra" är inte "perfekt."
Stripe Radar är verkligen bra på sitt jobb. Tränad på över $1 biljoner i årlig betalningsvolym känner dess modeller igen ett kort de sett tidigare 92% av gångerna, och Stripe rapporterar att Radar minskar bedrägerier med 32% i genomsnitt för företag som använder det.
Läs det där talet igen: minskar, inte eliminerar. Ett genomsnittligt avtryck på 32% är stort – men det betyder att en betydande andel bedrägeriförsök fortfarande når dig, och Stripe är uppfriskande ärliga om varför. Med deras egna ord: "att minska antalet falska positiva ökar ofta sannolikheten för att verkliga bedrägerier slinker igenom." Läckage är inte ett fel i modellen; det är den avsiktliga kostnaden för att inte blockera riktiga kunder. Varje bedrägeriteam väljer medvetet hur mycket som ska släppas igenom.
För en produkt med gratisperiod är den läckan större än rubriksiffran antyder – eftersom den mest kraftfulla delen av Radar aldrig ens körs.
Varför en grind bara kan minska
Det finns en djupare anledning till att en motor som agerar vid debitering kan minska bedrägerier men aldrig stoppa dem, och det handlar inte om Stripes modeller – det handlar om timing och information. I det ögonblick ett kort läggs till har kunden ännu inte gjort något. Ingen inloggningshistorik, inget produktbeteende, inget användningsmönster att lära av – bara ett kort och några nätverkssignaler. Radar gör sin bästa bedömning på den tunnaste möjliga informationsbasen, just när den har minst att gå på.
Det är den verkliga gränsen. Du kan justera en grind, men du kan inte ge den data som ännu inte finns. Informationen som faktiskt skiljer en missbrukare från en kund skapas till största delen efter att grinden redan har behövt fatta sitt beslut.
Steg 1: Släcka bränder i chattfönstret
Vårt första svar var helt manuellt. När en våg av missbruk slog till öppnade någon en konversation med vår agent och hanterade incidenten live: tog fram de senaste registreringarna, granskade korten, hittade mönstret och stängde kontona manuellt.
Det fungerade, men det gick inte att skala. Varje incident började från noll. Kunskapen – hur ser denna ring ut, vilka signaler är tillförlitliga – fanns i en persons huvud och en chattråd, och försvann när fönstret stängdes.
Vi lärde oss också en dyrbar läxa på den goda sidan av tratten: när vi ville vinna tillbaka genuina användare som avbrutit utcheckningen, kan ett slarvigt utskick till en bedräglig adress göra verklig skada – det bekräftar att adressen är aktiv. All automation vi byggde måste kunna skilja på en riktig prospekt och en planterad sådan.
Steg 2: Förstärka ytterdörren med Radar
Vårt nästa steg var att flytta allt vi kunde uppströms till Radar – blocklistor och hastighetsregler vid kortläggningen, anpassade efter det tryck vi såg. Det är rätt första steg och stoppade de grövsta attackerna.
Men två begränsningar blev snabbt tydliga. Den första är den Stripe själv nämner: en motor som agerar vid debitering är en avvägningsratt, inte en mur – skruva upp och du blockerar riktiga kunder, skruva ner och mer bedrägeri slinker igenom. Den andra är strukturell och specifik för gratisperioder: den 32% tjänas in vid debitering, och en SetupIntent-gratisperiod har ingen debitering att poängsätta. Om du inte uttryckligen aktiverar Radar på sparade betalningsmetoder körs motorn inte alls – och även när den gör det gäller endast Block, Allow och 3DS-regler på en SetupIntent. Åtgärden "Review", den som ger en människa en andra chans att granska, utlöses aldrig.
Så det enskilt mest effektiva lagret i stacken står, som standard, över just det ögonblick vi behövde det som mest. Radar är en grind vid ytterdörren. Vi behövde en patrull bakom den.
Steg 3: Ett andra lager, byggt på Zero
Efter registrering vänds informationsbilden. Kontot börjar lämna spår – och den mest värdefulla delen av det spåret finns i ett system som betalningsleverantören aldrig ser: vår identitetsleverantör, Clerk.
Så vi gav Zero tillgång till det. Clerk vet saker Stripe inte kan: hur kontot skapades, registreringsmetod och e-post, sessionen och enheten bakom, och exakt timing i förhållande till alla andra registreringar den dagen. Stripe känner till kortet. Inget av systemen berättar hela historien på egen hand – men agenten kan läsa båda och korrelera mellan dem. Missbruk som är osynligt vid grinden blir uppenbart sida vid sida: ett helt nytt konto vars inloggningsidentitet inte stämmer överens med dess faktureringsidentitet, skapat bara minuter från en klunga av liknande konton. Den korssystemjämförelsen är precis vad en grind vid debitering inte kan göra – och exakt vad en agent ovanpå båda systemen kan.
På den rikare informationsbasen kör vi ett antal schemalagda Zero-uppgifter var några minut mot live-registrerings- och faktureringsdata. Tre principer styr dem:
1. Patrullera, inte bara granska. Istället för att utvärdera ett ögonblick sveper agenten igenom alla nya registreringar i en kort slinga, korrelerar kontodata och betalningsmetadata för att hitta konton som slank förbi ytterdörren.
2. Skikta åtgärder efter säkerhet. Inte varje signal förtjänar samma åtgärd. Mönster med hög säkerhet hanteras automatiskt – kontot stängs av och gratisperioden avslutas direkt, eftersom åtgärden är reversibel och kostnaden för att vänta är verklig. Signaler med lägre säkerhet hanteras aldrig automatiskt; de samlas i en rapport för manuell granskning. Beslutsam där det är säkert, försiktig där det inte är det.
3. Behåll ett mänskligt revisionsspår. Varje automatiserad åtgärd loggar exakt vilken signal som utlöste den, så den kan granskas – och återställas – på sekunder. Automation du inte kan granska är automation du inte kan lita på.
Vi tillämpade samma noggrannhet på den vänliga sidan av tratten. En separat uppgift hittar genuina användare som avbrutit utcheckningen och skriver ett utkast till ett återvinningsmail för manuell godkännande – bakom ett medvetet strikt bedrägerifilter, så vi aldrig validerar en dålig adress. Samma motor, motsatt mål.
Vad det gjorde för ekonomin
När patrullen var igång förändrades siffrorna direkt. Titta på den 90:e percentilens registrering – de tunga konton som gjorde verklig skada. Den gratisperiodskalkyl som ett sådant konto förbrukade under sina första timmar föll från ungefär $4 till cirka $0.25 – en minskning på 94%. Utslaget över alla nya registreringar under samma period föll förlusten per konto med ungefär 85%.
Förändringens form säger allt. De flesta registreringar kostade oss aldrig något; förlusten var alltid koncentrerad till en lång, tung svans av konton som bara fanns för att tömma gratisperiodens krediter. Patrullen minskade inte tratten – den kapade svansen. Inte färre registreringar. Renare sådana.
Varför en agent och inte ett skript
Vi hade kunnat skriva ett cron-jobb. Vi gjorde det inte, av en anledning: hotet förändras snabbare än en releasecykel. När en angripare byter taktik uppdaterar vi en uppgifts instruktioner i klartext och den nya logiken är live vid nästa körning – ingen deploy, ingen schemamigrering, ingen ticket. "Reglerna" är en prompt, och prompten är lika snabb att ändra som angriparen själv.
Det är den verkliga lärdomen. Radar är rätt verktyg för risk vid debitering, och vi lutar oss tungt mot det. Men en produkt med gratisperiod har en strukturell blind fläck som inget verktyg vid debitering kan täcka – och lösningen är inte en större regelmotor. Det är ett snabbt, granskningsbart, ständigt aktivt andra lager som du kan omprogrammera i takt med hotet.
Slutsatser för team med gratisperiod
- Kartlägg dina ögonblick utan debitering. Varhelst en användare får värde innan en betalning poängsätts är en lucka som ett verktyg vid debitering inte ser.
- Lägg till lager, ersätt inte. Behåll Radar vid ytterdörren. Lägg till en kontinuerlig patrull efter registrering bakom den.
- Koppla ihop systemen. Din betalningsleverantör och din identitetsleverantör har varsin halva av bilden. Bedrägeriet syns i överlappet.
- Skikta åtgärder efter säkerhet och logga alla. Automatisera bara där åtgärden är reversibel och signalen stark; skicka resten till en människa.
- Optimera för anpassningshastighet. Vid bedrägeri vinner det team som kan ändra sina regler snabbast.
Nyfiken på vad en ständigt aktiv agent kan automatisera i din egen stack? Utforska Zero.
Noter: Radar-siffror är Stripes egna publicerade data (stripe.com/radar; "A primer on machine learning for fraud detection"). Förlustsiffror avser beräkningskostnad per ny registrering under de första timmarna efter registrering, mätt över matchade perioder före och efter lansering, med interna konton exkluderade; urvalet efter lansering är fortfarande tidigt och kommer att stabiliseras över tid.
