Stripe Radar er fremragende til det, den gør: at score en transaktion i det øjeblik, penge bevæger sig. Men det øjeblik, hvor penge ikke bevæger sig, er præcis dér, vores problem opstod.
Vi tilbyder en gratis prøveperiode på 7 dage. For at starte den gemmer brugeren et kort, men bliver aldrig opkrævet — i baggrunden er det en Stripe SetupIntent, ikke en betaling. Ingen opkrævning betyder ingen hændelse ved opkrævningstidspunktet, hvilket betyder, at Radars mest effektive regler ikke har noget at evaluere i det øjeblik, der betyder mest: når en svigagtig konto bliver oprettet og begynder at bruge prøvecredits.
Dette er historien om, hvordan vi gik fra brandslukning af svindel i enkeltstående chats til at køre et automatiseret, minut-for-minut svindellag — bygget oven på vores eget produkt, Zero.
Radar er god. "God" er ikke "perfekt."
Stripe Radar er virkelig god til det, den gør. Trænet på mere end $1 billion i årlig betalingsvolumen, genkender dens modeller et kort, de har set før, 92% af gangene, og Stripe rapporterer, at Radar reducerer svindel med 32% i gennemsnit for de virksomheder, der bruger det.
Læs det tal igen: reducerer, ikke eliminerer. Et gennemsnitligt fald på 32% er betydeligt — men det betyder, at en stor del af svindelpresset stadig når frem til din dør, og Stripe er forfriskende ærlig om hvorfor. Med deres egne ord: "reducering af antallet af falske positiver øger ofte sandsynligheden for, at mere reel svindel slipper igennem." Lækage er ikke en fejl i modellen; det er den bevidste pris for ikke at blokere dine rigtige kunder. Hvert svindelteam vælger bevidst, hvor meget de vil lade slippe igennem.
For et produkt med gratis prøveperiode er det læk større end overskriften antyder — fordi den mest effektive del af Radar aldrig engang kører.
Hvorfor en port kun kan reducere
Der er en dybere grund til, at en motor ved opkrævningstidspunktet kan reducere svindel, men aldrig stoppe den, og det handler ikke om Stripes modeller — det handler om timing og information. I det øjeblik et kort tilføjes, har kunden endnu ikke gjort noget. Ingen login-historik, ingen produktadfærd, intet brugsmønster at lære af — kun et kort og et par netværkssignaler. Radar træffer sit bedste valg på det tyndest mulige grundlag, netop når den har mindst at gå ud fra.
Det er den reelle begrænsning. Du kan finjustere en port, men du kan ikke give den data, der endnu ikke eksisterer. Den information, der faktisk adskiller en misbruger fra en kunde, skabes for det meste efter, at porten allerede har måttet træffe sin beslutning.
Fase 1: Brandslukning i chatvinduet
Vores første reaktion var helt manuel. Når en bølge af misbrug ramte, åbnede en medarbejder en samtale med vores agent og håndterede hændelsen live: trak de seneste tilmeldinger, kiggede på kortene, fandt mønsteret, lukkede kontiene manuelt.
Det virkede, men det kunne ikke skaleres. Hver hændelse startede fra nul. Viden — hvordan ser denne ring ud, hvilke signaler er pålidelige — levede i én persons hoved og én chattråd, og forsvandt i det øjeblik vinduet blev lukket.
Vi lærte også en dyr lektie på den gode side af tragten: når vi ville vinde ægte brugere tilbage, der havde forladt betalingsflowet, gjorde en uforsigtig opfølgende e-mail til en svigagtig adresse reel skade — den bekræftede, at adressen var aktiv. Enhver automatisering, vi byggede, skulle kunne skelne mellem en reel kunde og en plantet adresse.
Fase 2: Forstærkning af hoveddøren med Radar
Vores næste skridt var at flytte alt, vi kunne, opstrøms til Radar — bloklister og hastighedsregler ved korttilføjelsen, tilpasset det pres, vi oplevede. Det er det rigtige første skridt, og det stoppede de groveste angreb.
Men to begrænsninger viste sig hurtigt. Den første er den, Stripe selv nævner: en motor ved opkrævningstidspunktet er en afvejning, ikke en mur — skruer du op, blokerer du rigtige kunder, skruer du ned, slipper mere svindel igennem. Den anden er strukturel og specifik for prøveperioder: den 32% opnås ved opkrævning, og en SetupIntent-prøveperiode har ingen opkrævning at score. Medmindre du eksplicit aktiverer Radar på gemte betalingsmetoder, kører motoren slet ikke — og selv når den gør, gælder kun Block, Allow og 3DS-regler på en SetupIntent. Handlingen "Review", den der giver et menneske et ekstra kig, udløses aldrig.
Så det bedst præsterende lag i stakken sidder som standard overhovedet ikke med i det øjeblik, vi havde mest brug for det. Radar er en port ved hoveddøren. Vi havde brug for en patrulje bagved.
Fase 3: Et andet lag, bygget på Zero
Efter tilmelding vender informationsbilledet. Kontoen begynder at efterlade spor — og den rigeste del af det spor findes i et system, betalingsudbyderen aldrig ser: vores identitetsudbyder, Clerk.
Så vi gav Zero adgang til det. Clerk ved ting, Stripe ikke kan: hvordan kontoen blev oprettet, tilmeldingsmetode og e-mail, sessionen og enheden bag, og den præcise timing i forhold til alle andre tilmeldinger den dag. Stripe kender kortet. Ingen af systemerne fortæller hele historien alene — men agenten kan læse begge og krydskorrelere dem. Det misbrug, der er usynligt ved porten, bliver tydeligt side om side: en helt ny konto, hvis login-identitet ikke stemmer overens med faktureringsidentiteten, oprettet få øjeblikke efter en klynge af lookalikes. Den krydssystemsammenkædning kan en port ved opkrævningstidspunktet ikke lave — men det kan en agent, der sidder oven på begge systemer.
På det rigere datagrundlag kører vi et sæt planlagte Zero-opgaver hvert par minutter mod live tilmeldings- og faktureringsdata. Tre principper former dem:
1. Patruljer, ikke kun port. I stedet for at evaluere ét øjeblik, gennemgår agenten alle nylige tilmeldinger i en kort sløjfe, korrelerer kontodata og betalingsmetadata for at finde konti, der slap forbi hoveddøren.
2. Differentier responsen efter sikkerhed. Ikke alle signaler fortjener samme handling. Mønstre med høj sikkerhed håndteres automatisk — kontoen suspenderes og prøveperioden annulleres straks, fordi handlingen kan fortrydes og omkostningen ved at vente er reel. Signaler med lavere sikkerhed udløser aldrig automatisk handling; de samles i en rapport til manuel gennemgang. Beslutsom, hvor det er sikkert, forsigtig, hvor det ikke er.
3. Bevar et menneskeligt revisionsspor. Hver automatiseret handling registrerer det præcise signal, der udløste den, så det kan gennemgås — og fortrydes — på få sekunder. Automatisering, du ikke kan revidere, kan du ikke stole på.
Vi brugte samme grundighed på den venlige side af tragten. En separat opgave finder ægte brugere, der har forladt betalingsflowet, og udkast til en win-back e-mail til godkendelse af et menneske — bag et bevidst stramt svindelfilter, så vi aldrig validerer en dårlig adresse. Samme motor, modsat mål.
Hvad det gjorde ved økonomien
Da patruljen var live, ændrede tallene sig straks. Se på den 90. percentil tilmelding — de tunge konti, der gjorde størst skade. Den prøveberegning, én af dem brugte i de første timer, faldt fra omkring $4 til omkring $0.25 — et fald på 94%. Gennemsnitligt på tværs af alle nye tilmeldinger i samme periode faldt tabet pr. konto med omtrent 85%.
Forandringens form afslører det hele. De fleste tilmeldinger kostede os aldrig noget; tabet var altid koncentreret i en lang, tung hale af konti, der kun eksisterede for at tømme prøvecredits. Patruljen indsnævrede ikke tragten — den skar halen af. Ikke færre tilmeldinger. Renere tilmeldinger.
Hvorfor en agent og ikke et script
Vi kunne have skrevet et cron-job. Det gjorde vi ikke, af én grund: truslen ændrer sig hurtigere end en release-cyklus. Når en angriber skifter taktik, opdaterer vi en opgaves instruktioner i almindeligt sprog, og den nye logik er live ved næste kørsel — ingen deploy, ingen skemamigrering, ingen ticket. "Reglerne" er en prompt, og prompten kan ændres lige så hurtigt som angriberen.
Det er den virkelige lektie. Radar er det rette værktøj til risikovurdering ved opkrævning, og vi bruger det intensivt. Men et produkt med gratis prøveperiode har et strukturelt blinde punkt, som intet værktøj ved opkrævning kan dække — og løsningen er ikke en større regelmotor. Det er et hurtigt, reviderbart, altid aktivt andet lag, som du kan omprogrammere i takt med truslen.
Anbefalinger til prøvebaserede teams
- Kortlæg dine øjeblikke uden opkrævning. Overalt hvor en bruger får værdi, før en betaling scores, er der et hul, et værktøj ved opkrævning ikke kan se.
- Lag, ikke erstat. Behold Radar ved hoveddøren. Tilføj en kontinuerlig patrulje efter tilmelding bagved.
- Kombinér på tværs af systemer. Din betalingsudbyder og din identitetsudbyder har hver halvdelen af billedet. Svindlen er synlig i overlapningen.
- Differentier dine handlinger efter sikkerhed, og log dem alle. Auto-handl kun, hvor handlingen kan fortrydes og signalet er stærkt; send resten til manuel behandling.
- Optimer for tilpasningshastighed. I svindelbekæmpelse vinder det team, der kan ændre sine regler hurtigst.
Nysgerrig på, hvad en altid-aktiv agent kunne automatisere i din egen stack? Udforsk Zero.
Bemærk: Radar-tal er Stripes egne offentliggjorte tal (stripe.com/radar; "A primer on machine learning for fraud detection"). Tabstal afspejler beregningsomkostning pr. ny tilmelding i de første timer efter registrering, målt over sammenlignelige perioder før og efter lancering, med interne konti udeladt; udvalget efter lancering er stadig tidligt og vil blive mere præcist over tid.
