Stripe Radar er utmerket til det den gjør: å vurdere en transaksjon i det øyeblikket penger beveger seg. Men akkurat når penger ikke beveger seg, oppstår vårt problem.
Vi tilbyr en gratis prøveperiode på 7 dager. For å starte den, lagrer brukeren et kort, men blir aldri belastet — i bakgrunnen er dette en Stripe SetupIntent, ikke en betaling. Ingen belastning betyr ingen hendelse ved betalingstidspunktet, noe som gjør at Radars kraftigste regler ikke har noe å vurdere akkurat når det gjelder mest: når en svindel-konto opprettes og begynner å bruke prøve-kreditter.
Dette er historien om hvordan vi gikk fra å slukke svindelbranner i enkeltchatter til å kjøre et automatisert, minutt-for-minutt svindellag — bygget på vårt eget produkt, Zero.
Radar er bra. "Bra" er ikke "perfekt."
Stripe Radar er virkelig god på det den gjør. Trenet på mer enn $1 billioner i årlig betalingsvolum, gjenkjenner modellene et kort de har sett før 92% av gangene, og Stripe rapporterer at Radar reduserer svindel med 32% i snitt for virksomheter som bruker det.
Les det tallet igjen: reduserer, ikke eliminerer. Et gjennomsnittlig kutt på 32% er betydelig — men det betyr at en stor andel svindel fortsatt når frem til deg, og Stripe er forfriskende ærlige om hvorfor. Med deres egne ord: "å redusere antall falske positiver øker ofte sannsynligheten for at mer reell svindel slipper gjennom." Lekkasjen er ikke en feil i modellen; det er den bevisste kostnaden for å ikke blokkere ekte kunder. Hvert svindelteam velger, med vilje, hvor mye de lar slippe gjennom.
For et produkt med gratis prøveperiode er denne lekkasjen større enn overskriften antyder — fordi den kraftigste delen av Radar aldri engang kjøres.
Hvorfor en port bare kan redusere
Det finnes en dypere grunn til at en motor som jobber ved betalingstidspunktet bare kan redusere svindel, men aldri stoppe den, og det handler ikke om Stripes modeller — det handler om tidspunkt og informasjon. I det øyeblikket et kort legges til, har kunden ikke gjort noe ennå. Ingen innloggingshistorikk, ingen produktatferd, ingen bruksmønster å lære av — bare et kort og noen få nettverkssignaler. Radar gjør sin beste vurdering på det tynneste mulige grunnlaget, akkurat når den har minst å gå på.
Det er det reelle taket. Du kan finjustere en port, men du kan ikke gi den data som ikke eksisterer ennå. Informasjonen som faktisk skiller en misbruker fra en kunde, skapes for det meste etter at porten allerede har måttet ta en avgjørelse.
Fase 1: Brannslukking i chatvinduet
Vår første respons var helt manuell. Når en bølge av misbruk traff, åpnet noen en samtale med vår agent og håndterte hendelsen direkte: hentet de siste registreringene, så på kortene, fant mønsteret, og stengte kontoene manuelt.
Det fungerte, men det var ikke skalerbart. Hver hendelse startet fra null. Kunnskapen — hvordan ser denne ringen ut, hvilke signaler er pålitelige — fantes i én persons hode og én chat-tråd, og forsvant i det øyeblikket vinduet ble lukket.
Vi lærte også en dyr lekse på den gode siden av trakten: når vi ønsket å vinne tilbake ekte brukere som hadde forlatt utsjekken, kunne en uforsiktig e-post til en svindeladresse gjøre reell skade — det bekrefter at adressen er aktiv. All automatisering vi bygde måtte kunne skille mellom en ekte potensiell kunde og en plantet en.
Fase 2: Forsterke inngangsdøren med Radar
Neste steg var å flytte alt vi kunne oppstrøms til Radar — blokkeringslister og hastighetsregler ved kortregistrering, tilpasset presset vi opplevde. Det er det riktige første steget, og det stoppet de groveste angrepene.
Men to begrensninger dukket raskt opp. Den første er den Stripe selv peker på: en motor ved betalingstidspunktet er en avveiningsbryter, ikke en mur — skrur du den opp, blokkerer du ekte kunder, skrur du den ned, slipper mer svindel gjennom. Den andre er strukturell og spesifikk for prøveperioder: den 32% opptjenes ved betaling, og en SetupIntent-prøve har ingen betaling å vurdere. Med mindre du eksplisitt aktiverer Radar på lagrede betalingsmetoder, kjøres ikke motoren i det hele tatt — og selv når den gjør det, gjelder kun Block, Allow og 3DS-regler på en SetupIntent. Handlingen "Review", den som gir et menneske en ekstra sjanse til å se på saken, utløses aldri.
Dermed sitter det beste laget i stakken, som standard, på sidelinjen akkurat når vi trengte det mest. Radar er en port ved inngangsdøren. Vi trengte en patrulje bak den.
Fase 3: Et andre lag, bygget på Zero
Etter registrering snus informasjonsbildet. Kontoen begynner å legge igjen spor — og den rikeste delen av dette sporet finnes i et system betalingsleverandøren aldri ser: vår identitetsleverandør, Clerk.
Så vi ga Zero tilgang til den. Clerk vet ting Stripe ikke kan: hvordan kontoen ble opprettet, registreringsmetode og e-post, økt og enhet bak, og nøyaktig tidspunkt i forhold til alle andre registreringer den dagen. Stripe kjenner kortet. Ingen av systemene forteller hele historien alene — men agenten kan lese begge og koble dem sammen. Misbruk som er usynlig ved porten blir åpenbart side om side: en splitter ny konto hvis innloggingsidentitet ikke samsvarer med faktureringsidentiteten, opprettet minutter etter en klynge med lookalikes. Den tverrsystemkoblingen er akkurat det en port ved betalingstidspunktet ikke kan gjøre — og akkurat det en agent som sitter på toppen av begge systemene kan.
På dette rikere datagrunnlaget kjører vi et sett planlagte Zero-oppgaver hvert par minutter mot levende registrerings- og faktureringsdata. Tre prinsipper styrer dem:
1. Patruljer, ikke bare port. I stedet for å vurdere ett øyeblikk, sveiper agenten gjennom alle nylige registreringer i en kort sløyfe, korrelerer kontodata og betalingsmetadata for å avdekke kontoer som slapp forbi inngangsdøren.
2. Del opp responsen etter sikkerhet. Ikke alle signaler fortjener samme handling. Mønstre med høy sikkerhet håndteres automatisk — kontoen suspenderes og prøveperioden kanselleres umiddelbart, fordi handlingen kan reverseres og kostnaden ved å vente er reell. Signaler med lavere sikkerhet blir aldri automatisk håndtert; de samles i en rapport for manuell gjennomgang. Besluttsom der det er trygt, konservativ der det ikke er det.
3. Hold et menneskelig revisjonsspor. Hver automatisert handling logger nøyaktig hvilket signal som utløste den, slik at det kan gjennomgås — og reverseres — på sekunder. Automatisering du ikke kan revidere, kan du ikke stole på.
Vi brukte samme grundighet på den vennlige siden av trakten. En egen oppgave finner ekte brukere som har forlatt utsjekken og utarbeider en vinn-tilbake-e-post for manuell godkjenning — bak et bevisst strengt svindelfilter, slik at vi aldri validerer en dårlig adresse. Samme motor, motsatt mål.
Hva det gjorde med økonomien
Da patruljen var i gang, endret tallene seg umiddelbart. Se på den 90. persentilen av registreringer — de tunge kontoene som gjorde størst skade. Prøveberegningen én av dem brukte opp de første timene, falt fra omtrent $4 til omtrent $0.25 — et fall på 94%. Gjennomsnittlig tap per ny registrering i samme periode falt med omtrent 85%.
Endringenes form sier alt. De fleste registreringer kostet oss aldri noe; tapet var alltid konsentrert i en lang, tung hale av kontoer som kun eksisterte for å tømme prøve-kreditter. Patruljen reduserte ikke trakten — den kuttet halen. Ikke færre registreringer. Renere registreringer.
Hvorfor en agent, og ikke et script
Vi kunne skrevet en cron-jobb. Det gjorde vi ikke, av én grunn: trusselen endrer seg raskere enn en release-syklus. Når en angriper endrer taktikk, oppdaterer vi instruksjonene til en oppgave i klartekst, og den nye logikken er aktiv ved neste kjøring — ingen deploy, ingen skjemaendring, ingen sak. "Reglene" er en prompt, og prompten kan endres like raskt som angriperen.
Det er den virkelige lærdommen. Radar er riktig verktøy for risiko ved betalingstidspunktet, og vi bruker det mye. Men et produkt med gratis prøveperiode har et strukturelt blindsone som ingen betalingstidsverktøy kan dekke — og løsningen er ikke en større regelmotor. Det er et raskt, reviderbart, alltid aktivt andre lag som du kan omprogrammere i takt med trusselen.
Læringspunkter for team med gratis prøveperiode
- Kartlegg øyeblikk uten betaling. Overalt hvor en bruker får verdi før en betaling vurderes, finnes det et hull et betalingstidsverktøy ikke ser.
- Legg til lag, ikke erstatt. Behold Radar ved inngangsdøren. Legg til en kontinuerlig patrulje etter registrering bak den.
- Koble sammen systemer. Betalingsleverandøren og identitetsleverandøren din har hver sin halvdel av bildet. Svindelen er synlig i overlappet.
- Del opp handlingene etter sikkerhet, og logg alle. Automatiser kun der handlingen kan reverseres og signalet er sterkt; send resten til manuell vurdering.
- Optimaliser for tilpasningshastighet. I svindelarbeid vinner teamet som raskest kan endre reglene sine.
Nysgjerrig på hva en alltid aktiv agent kan automatisere i din egen stack? Utforsk Zero.
Notater: Radar-tallene er Stripes egne publiserte tall (stripe.com/radar; "A primer on machine learning for fraud detection"). Tapstallene reflekterer beregningskostnad per ny registrering de første timene etter registrering, målt over sammenlignbare perioder før og etter lansering, med interne kontoer ekskludert; utvalget etter lansering er fortsatt tidlig og vil stabilisere seg over tid.
