Stripe Radar is uitstekend in wat het doet: een transactie beoordelen op het moment dat er geld beweegt. Maar precies op het moment dat er geen geld beweegt, zat ons probleem.
Wij bieden een gratis proefperiode van 7 dagen aan. Om deze te starten, slaat een gebruiker een kaart op zonder ooit te worden belast — onder de motorkap is dat een Stripe SetupIntent, geen betaling. Geen afschrijving betekent geen afschrijvingsmoment, waardoor de krachtigste regels van Radar niets te beoordelen hebben op het moment dat het er het meest toe doet: wanneer een frauduleus account wordt aangemaakt en begint met het verbruiken van proefcredits.
Dit is het verhaal van hoe we van handmatig fraudebestrijding in losse chats zijn gegaan naar een geautomatiseerde, minutie-tot-minutie fraudelaag — gebouwd bovenop ons eigen product, Zero.
Radar is geweldig. "Geweldig" is niet "perfect."
Stripe Radar is echt goed in wat het doet. Getraind op meer dan $1 biljoen aan jaarlijkse betalingsvolume, herkennen de modellen een kaart die ze eerder hebben gezien 92% van de tijd, en Stripe meldt dat Radar fraude gemiddeld met 32% vermindert voor bedrijven die het gebruiken.
Lees dat getal nog eens: vermindert, niet elimineert. Een gemiddelde daling van 32% is aanzienlijk — maar het betekent dat een groot deel van de fraudedruk nog steeds bij jou terechtkomt, en Stripe is daar verfrissend eerlijk over. In hun eigen woorden: "het verminderen van het aantal false positives vergroot vaak de kans dat echte fraude erdoorheen glipt." Lek is geen fout in het model; het is de bewuste prijs om je echte klanten niet te blokkeren. Elk fraudeteam kiest bewust hoeveel ze doorlaten.
Voor een product dat draait op proefperiodes is dat lek groter dan het hoofdgetal suggereert — omdat het krachtigste deel van Radar nooit wordt uitgevoerd.
Waarom een poort alleen kan verminderen
Er is een diepere reden waarom een engine op afschrijvingsmoment fraude kan verminderen maar nooit beëindigen, en dat ligt niet aan Stripe's modellen — het gaat om timing en informatie. Op het moment dat een kaart wordt toegevoegd, heeft de klant nog niets gedaan. Geen inloggeschiedenis, geen productgedrag, geen gebruikspatroon om van te leren — alleen een kaart en een paar netwerksignalen. Radar maakt zijn beste inschatting op basis van het dunste stukje bewijs, precies op het moment dat er het minst te beoordelen valt.
Dat is het echte plafond. Je kunt een poort afstellen, maar je kunt hem geen data geven die nog niet bestaat. De informatie die een misbruiker van een klant onderscheidt, ontstaat grotendeels nadat de poort al een beslissing heeft moeten nemen.
Fase 1: Brandjes blussen in het chatvenster
Onze eerste reactie was volledig handmatig. Wanneer er een golf van misbruik kwam, opende iemand een gesprek met onze agent en werd het incident live afgehandeld: recente aanmeldingen ophalen, kaarten bekijken, het patroon vinden, accounts handmatig sluiten.
Het werkte, maar was niet schaalbaar. Elk incident begon vanaf nul. De kennis — hoe ziet deze ring eruit, welke signalen zijn betrouwbaar — zat in het hoofd van één persoon en één chatdraad, en verdween zodra het venster werd gesloten.
We leerden ook een dure les aan de goede kant van de funnel: als we echte gebruikers die de checkout verlieten wilden terugwinnen, doet een ondoordachte e-mail naar een frauduleus adres echt kwaad — het bevestigt dat het adres actief is. Elke automatisering die we bouwden moest dus het verschil kunnen zien tussen een echte prospect en een geplante.
Fase 2: De voordeur versterken met Radar
Onze volgende stap was om alles wat we konden naar voren te schuiven in Radar — blokkeerlijsten en snelheidsregels bij het toevoegen van een kaart, afgestemd op de druk die we zagen. Het is de juiste eerste stap en stopte de grofste aanvallen.
Maar twee plafonds werden snel duidelijk. De eerste noemt Stripe zelf: een engine op afschrijvingsmoment is een afwegingsknop, geen muur — draai hem omhoog en je blokkeert echte klanten, draai hem omlaag en meer fraude glipt erdoor. De tweede is structureel en specifiek voor proefperiodes: die 32% wordt verdiend bij afschrijving, en een SetupIntent-proef heeft geen afschrijving om te beoordelen. Tenzij je Radar expliciet inschakelt op opgeslagen betaalmethoden, draait de engine helemaal niet — en zelfs als dat wel zo is, gelden alleen Block, Allow en 3DS-regels op een SetupIntent. De "Review"-actie, die een mens een tweede blik geeft, wordt nooit geactiveerd.
Dus de best presterende laag in de stack doet standaard niet mee op het exacte moment dat we hem het hardst nodig hadden. Radar is een poort bij de voordeur. Wij hadden een patrouille erachter nodig.
Fase 3: Een tweede laag, gebouwd op Zero
Na aanmelding verandert het informatielandschap. Het account begint een spoor achter te laten — en het rijkste deel daarvan leeft in een systeem dat de betalingsverwerker nooit ziet: onze identity provider, Clerk.
Dus gaven we Zero toegang. Clerk weet dingen die Stripe niet kan weten: hoe het account is aangemaakt, de aanmeldmethode en het e-mailadres, de sessie en het apparaat erachter, en de precieze timing ten opzichte van andere aanmeldingen die dag. Stripe kent de kaart. Geen van beide systemen vertelt het hele verhaal — maar de agent kan beide lezen en de gegevens koppelen. Het misbruik dat onzichtbaar is bij de poort, wordt duidelijk naast elkaar: een gloednieuw account waarvan de inlogidentiteit niet overeenkomt met de betaalidentiteit, aangemaakt vlak na een cluster lookalikes. Die koppeling tussen systemen is precies wat een poort op afschrijvingsmoment niet kan — en precies wat een agent bovenop beide systemen wel kan.
Op basis van dat rijkere bewijs draaien we elke paar minuten een set geplande Zero-taken op live aanmeld- en betaaldata. Drie principes sturen deze taken:
1. Patrouilleer, niet alleen poortwachter. In plaats van één moment te beoordelen, scant de agent elke recente aanmelding in een korte cyclus, koppelt accountdata en betaalmetadata om accounts te vinden die langs de voordeur zijn geglipt.
2. Rangschik de reactie naar vertrouwen. Niet elk signaal verdient dezelfde actie. Patronen met hoog vertrouwen worden automatisch afgehandeld — het account wordt direct geschorst en de proefperiode geannuleerd, omdat de actie omkeerbaar is en wachten echt kostbaar is. Signalen met lager vertrouwen worden nooit automatisch uitgevoerd; ze worden verzameld in een rapport voor menselijke beoordeling. Doortastend waar het veilig is, voorzichtig waar dat niet zo is.
3. Houd een menselijke audittrail bij. Elke geautomatiseerde actie registreert het exacte signaal dat het triggerde, zodat het binnen seconden kan worden beoordeeld — en teruggedraaid. Automatisering die je niet kunt auditen, kun je niet vertrouwen.
We pasten dezelfde zorgvuldigheid toe aan de vriendelijke kant van de funnel. Een aparte taak vindt echte gebruikers die de checkout hebben verlaten en stelt een terugwin-e-mail op voor menselijke goedkeuring — achter een bewust strenge fraudefilter, zodat we nooit een fout adres bevestigen. Zelfde engine, tegenovergesteld doel.
Wat het deed met de economie
Zodra de patrouille actief was, veranderden de cijfers direct. Kijk naar de 90e percentiel aanmelding — de zware accounts die de echte schade aanrichtten. De proefcompute die één zo'n account in de eerste uren verbruikte, daalde van ongeveer $4 naar ongeveer $0.25 — een daling van 94%. Gemiddeld over alle nieuwe aanmeldingen in hetzelfde venster daalde het verlies per account met ongeveer 85%.
De vorm van de verandering zegt alles. De meeste aanmeldingen kostten ons nooit iets; het verlies zat altijd geconcentreerd in een lange, zware staart van accounts die alleen bestonden om proefcredits leeg te trekken. De patrouille verkleinde de funnel niet — hij sneed die staart af. Niet minder aanmeldingen. Wel schonere.
Waarom een agent, en geen script
We hadden een cronjob kunnen schrijven. Dat deden we niet, om één reden: de dreiging verandert sneller dan een releasecyclus. Als een aanvaller van tactiek verandert, passen we de instructies van een taak aan in gewone taal en de nieuwe logica is live bij de volgende run — geen deploy, geen schemawijziging, geen ticket. De "regels" zijn een prompt, en de prompt is net zo snel aan te passen als de aanvaller zelf.
Dat is de echte les. Radar is het juiste gereedschap voor risico op afschrijvingsmoment, en we vertrouwen er sterk op. Maar een product dat draait op proefperiodes heeft een structurele blinde vlek die geen enkele afschrijvingsengine kan dekken — en de oplossing is niet een grotere regelengine. Het is een snelle, controleerbare, altijd-actieve tweede laag die je kunt herprogrammeren op de snelheid van de dreiging.
Adviezen voor teams met proefperiodes
- Breng je momenten zonder afschrijving in kaart. Overal waar een gebruiker waarde krijgt voordat een betaling wordt beoordeeld, is een gat dat een afschrijvingsengine niet ziet.
- Laagstapelen, niet vervangen. Houd Radar bij de voordeur. Voeg een continue patrouille na aanmelding toe.
- Koppel systemen. Je betalingsverwerker en je identity provider hebben elk de helft van het verhaal. De fraude is zichtbaar in de overlap.
- Rangschik je acties naar vertrouwen, en log ze allemaal. Automatiseer alleen waar de actie omkeerbaar is en het signaal sterk; stuur de rest naar een mens.
- Optimaliseer voor aanpassingssnelheid. Bij fraude wint het team dat zijn regels het snelst kan aanpassen.
Benieuwd wat een altijd-actieve agent in jouw stack kan automatiseren? Ontdek Zero.
Opmerkingen: Radar-cijfers zijn afkomstig uit Stripe's eigen gepubliceerde data (stripe.com/radar; "A primer on machine learning for fraud detection"). Verliescijfers tonen compute-kosten per nieuwe aanmelding in de eerste uren na registratie, gemeten over overeenkomende periodes voor en na lancering, met interne accounts uitgesloten; de post-lancering steekproef is nog vroeg en zal na verloop van tijd verder stabiliseren.
