De recente e-commerceboom heeft ook geleid tot een enorme toename van fraude met online betalingen. Naar schatting kost fraude bedrijven over de hele wereld meer dan US$ 20 miljard per jaar. Elke dollar die verloren gaat door fraude, leidt bovendien tot hogere bedrijfskosten, netwerkkosten en klantverloop, wat bedrijven uiteindelijk nog meer geld kost.

Fraude is niet alleen duur, maar geavanceerde fraudeurs vinden voortdurend nieuwe manieren om zwakke punten te exploiteren. Dat maakt fraudebestrijding een uitdaging. Daarom hebben we Stripe Radar gebouwd, een fraudepreventieoplossing op basis van machine-learning die volledig is geïntegreerd in het Stripe-platform. De machine-learning van Radar gebruikt de gegevens van honderden miljarden aan betalingen die elk jaar via het Stripe-netwerk worden verwerkt om fraude nauwkeurig te detecteren en voor snelle aanpassing aan de nieuwste trends. Zo kun jij blijven groeien, zonder dat de fraude toeneemt.

In deze whitepaper vertellen we je over Stripe Radar en hoe we het Stripe-netwerk gebruiken om fraude te detecteren, geven we je een overzicht van de machine-learningtechnieken die we gebruiken, leggen we uit hoe we denken over de effectiviteit en prestaties van fraudedetectiesystemen, en beschrijven we hoe andere tools in de Radar-suite bedrijven kunnen helpen hun fraudeprestaties te optimaliseren.

Online creditcardfraude: een introductie

Een betaling wordt als frauduleus beschouwd wanneer de kaarthouder de betaling niet autoriseert. Als een fraudeur bijvoorbeeld een aankoop doet met een gestolen kaartnummer waarover geen melding is gedaan, is het mogelijk dat de betaling gewoon wordt verwerkt. Als de kaarthouder vervolgens ontdekt dat de kaart door een fraudeur wordt gebruikt, zou hij of zij contact opnemen met de bank om de transactie te betwisten. Dit wordt ook wel een chargeback genoemd.

Bedrijven kunnen een chargeback betwisten door bewijsmateriaal in te dienen waaruit blijkt dat de betaling geldig was. Als bij transacties zonder kaart de betaling echter als frauduleus wordt beschouwd door de netwerken, krijgt de kaarthouder gelijk en is het bedrijf aansprakelijk voor het verlies van goederen en andere kosten.

In het verleden hebben bedrijven strenge maatregelen getroffen om vermoedelijke frauduleuze transacties te voorspellen en blokkeren. Rigide regels, zoals het blokkeren van alle creditcards die in het buitenland worden gebruikt, kunnen er echter voor zorgen dat ook veel correcte transacties worden tegengehouden. Machine-learning kan daarentegen genuanceerdere patronen herkennen, waardoor je je omzet kunt maximaliseren. Bij machine-learning betekent een vals negatief resultaat dat het systeem iets heeft gemist wat het wel had moeten herkennen, in dit geval een frauduleuze transactie. Een vals positief resultaat treedt op wanneer het systeem iets doet wat het niet had moeten doen, zoals het blokkeren van een legitieme klant. Voordat we dieper ingaan op machine-learning, is het belangrijk om te begrijpen wat de gevolgen zijn voor ieder resultaat.

Bij valse negatieven zijn bedrijven vaak aansprakelijk voor het oorspronkelijke transactiebedrag plus de chargebackkosten (de kosten voor het terugdraaien van de kaartbetaling door de bank), hogere netwerkkosten als gevolg van de chargeback en hogere operationele kosten vanwege het beoordelen van transacties of het bestrijden van chargebacks. Als er te veel transacties worden betwist, voegt het netwerk je bovendien mogelijk toe aan een monitoringsprogramma voor chargebacks. Dit kan leiden tot hogere kosten en in sommige gevallen kun je geen kaartbetalingen meer accepteren.

Valse positieven, of onterecht geweigerde transacties, treden op wanneer een legitieme klant een aankoop wil doen, maar de transactie wordt geweigerd. Onterecht geweigerde transacties kunnen de brutowinst negatief beïnvloeden en leiden tot reputatieschade. In een recente enquête gaf 33% van de consumenten aan dat ze na een onterecht geweigerde transactie niet meer bij een bedrijf zouden winkelen.

Er is een wisselwerking tussen het aantal chargebacks (valse negatieven) en het aantal legitieme klanten dat wordt geweigerd (valse positieven). Hoe minder chargebacks je hebt, hoe meer valse positieven je moet tolereren (en vice versa). Met andere woorden: hoe meer fraude je voorkomt, hoe hoger het aantal legitieme klanten dat wordt geblokkeerd. Maar het werkt ook de andere kant op: als je het aantal valse positieven terugbrengt, is de kans groter dat echte frauduleuze transacties niet worden gedetecteerd. Bedrijven moeten de balans zien te vinden tussen deze twee uitersten op basis van hun marges, groeiprofiel en andere factoren.

Voor bedrijven met kleine marges, bijvoorbeeld restaurants die online maaltijden verkopen, zijn er misschien wel honderden goede transacties nodig om één frauduleuze transactie te compenseren. Een vals negatief resultaat is in dat geval een dure grap. Bedrijven met dit profiel zijn misschien geneigd om een breed net uit te werpen om potentiële fraude te stoppen. Als de marges van een bedrijf hoog zijn, bijvoorbeeld voor een SaaS-bedrijf, is het tegenovergestelde waar. De misgelopen inkomsten van één legitieme klant die wordt geblokkeerd, wegen wellicht op tegen de kosten van eventuele extra fraude.

Stripe Radar en het Stripe-netwerk

Radar is de fraudepreventieoplossing van Stripe die bedrijven beschermt tegen online creditcardfraude. Het draait op adaptieve machine-learning, het resultaat van jaren van datawetenschap en infrastructuurwerk door de toegewijde machine-learningteams van Stripe. De algoritmen van Radar evalueren elke transactie op frauderisico's en nemen gepaste acties. Betalingen met een hoge score worden geblokkeerd en Radar for Fraud Teams biedt gebruikers tools waarmee ze kunnen aangeven wanneer andere acties moeten worden genomen.

Stripe verwerkt jaarlijks honderden miljarden betalingen van miljoenen bedrijven en werkt samen met duizenden partnerbanken over de hele wereld. Door deze hoge aantallen zien we signalen en patronen vaak veel eerder dan kleinere netwerken. Geaggregeerde gegevens van alle Stripe-transacties die relevant zijn voor fraude, worden gebruikt om onze fraudedetectie te verbeteren. Deze gegevens worden automatisch verzameld via de betaalflow. Signalen zoals het land waar de kaart is uitgegeven of het IP-adres waarvan de betaling is gedaan, bieden waardevolle inzichten bij het voorspellen van welke betalingen waarschijnlijk frauduleus zijn.

Eerder gebruik van een kaart in het Stripe-netwerk biedt ook waardevolle informatie die wordt meegenomen bij de risicobeoordeling. Negentig procent van de kaarten op het Stripe-netwerk is meer dan een keer gebruikt. Hierdoor hebben we veel gedetailleerde gegevens om te beoordelen of het gebruik van de kaart legitiem of frauduleus is.

Een ander belangrijk voordeel van onze machine-learning is dat Radar rechtstreeks is ingebouwd in Stripe en direct in gebruik kan worden genomen. Bij andere oplossingen voor fraudepreventie moet je over het algemeen flinke investeringen doen, zowel vooraf als na implementatie. Allereerst moeten bedrijven het fraudeproduct integreren. Dit omvat technische werkzaamheden waarbij gegevens over relevante gebeurtenissen en betalingen worden verzonden. Ten tweede moeten bedrijven een integratie voltooien om betalingslabels, die transacties categoriseren in legitieme en frauduleuze transacties, door te sturen van hun betalingsverwerker naar de leverancier van de fraudepreventieoplossing. De betalingen kunnen ook handmatig worden gelabeld, maar dit kost veel tijd en is foutgevoelig. Radar doet het anders. Het ontvangt geverifieerde informatie direct vanuit de gebruikelijke Stripe-betalingsflow en gebruikt actuele en nauwkeurige gegevens van kaartnetwerken en -uitgevers, waardoor er geen tijd aan engineering of het schrijven van code hoeft te worden besteed.

Laten we eens dieper ingaan op machine-learning en hoe we dit bij Stripe gebruiken.

De basis van machine-learning

Machine-learning verwijst naar een reeks technieken voor het verzamelen van grote hoeveelheden gegevens en het gebruiken van die gegevens om modellen te produceren die resultaten voorspellen, zoals de waarschijnlijkheid dat een transactie kan leiden tot een chargeback vanwege fraude.

Een van de belangrijkste toepassingen van machine-learning is voorspelling: we willen de waarde van een bepaalde uitvoer-variabele voorspellen op basis van een aantal invoerwaarden. In ons geval is de uitvoerwaarde waar (true) als de betaling frauduleus en anders is deze onwaar (false); dergelijke binaire waarden worden booleaans genoemd. Een voorbeeld van een invoerwaarde kan het land zijn waar de kaart is uitgegeven of het aantal verschillende landen waar de kaart de afgelopen dag in het Stripe-netwerk is gebruikt. We bepalen hoe we een voorspelling doen op basis van eerdere voorbeelden van invoer- en uitvoergegevens.

De gegevens die worden gebruikt om de modellen te trainen of te maken, bestaan uit records. Deze worden vaak verkregen uit historische gegevens en bevatten zowel de uitvoerwaarde als de verschillende invoerwaarden, zoals in het volgende (zeer vereenvoudigde) voorbeeld:

Dit voorbeeld gebruikt slechts drie invoerwaarden, maar in de praktijk maken machine-learningmodellen gebruik van honderdduizenden invoerwaarden. De uitvoer van het machine-learningalgoritme kan een model zijn zoals de volgende beslissingsboom:

Wanneer we een nieuwe transactie zien, kijken we naar de invoerwaarden en werken we naar beneden totdat we een van de 'bladeren' bereiken. Dit doen we door vragen te stellen, vergelijkbaar met het spel 'Twenty Questions'. Elk blad bestaat uit alle samples in de dataset (de tabel hierboven) die matchen met de vraag-antwoordparen langs het pad dat we in de boom hebben gevolgd. We berekenen hoe waarschijnlijk een nieuwe transactie frauduleus is door het aantal frauduleuze samples in het blad te delen door het totale aantal samples in het blad. Anders gezegd, de boom beantwoordt de vraag: Welke fractie van transacties in onze dataset met eigenschappen die vergelijkbaar zijn met de transactie die we nu onderzoeken, was er eigenlijk frauduleus? Machine-learning houdt zich bezig met de constructie van de boom: Welke vragen stellen we, en in welke volgorde, om de kansen te maximaliseren dat we de twee klassen nauwkeurig kunnen onderscheiden? Beslissingsbomen zijn bijzonder makkelijk te visualiseren en te duiden. Er zijn echter veel verschillende machine-learningalgoritmen, ieder met een andere manier om de relaties weer te geven die we proberen te modelleren.

De huidige modellen voor machine-learning zijn over het algemeen veel geavanceerder dan het speelgoedmodel hierboven en zijn de drijvende kracht achter veel van de producten die we tegenwoordig vaak gebruiken:

• Google geeft nauwkeurige spellingsuggesties voor zoekopdrachten met de functie 'Bedoelde u...?'. Het gebruikt hiervoor machine-learning om miljoenen taalgerelateerde parameters in minder dan drie seconden te modelleren.
  
• Amazon gebruikt machine-learning om aankopen te voorspellen met zijn aanbevelingssysteem op basis van de behoeften, voorkeuren en het veranderende gedrag van gebruikers op het hele platform, zelfs voor nieuwe gebruikers zonder historische gegevens.
  

Machine-learning is bovendien de basis voor Stripe Radar, waarmee we voorspellen welke van je betalingen frauduleus zijn.

Hoe werkt machine-learning?

Op universiteiten wordt vooral veel aandacht besteed aan het modelleerproces van machine-learning: de methoden voor het vertalen van gegevens (bijvoorbeeld de tabel hierboven) in modellen (bijvoorbeeld de beslissingsboom). Dit zijn de algoritmen die je vertellen hoe de invoerwaarden (het land waarin de kaart is uitgegeven, het aantal landen waarin de kaart is gebruikt, enzovoort) passen bij de uitvoerwaarden (was de transactie frauduleus of niet?). Het proces waarbij de invoergegevens uit de bovenstaande tabel worden gebruikt om de beslissingsboom te maken, is een voorbeeld van een specifieke machine-learningmethode. Bij het modelleren volg je een aantal stappen, afhankelijk van de aard van je gegevens en de modellen die je hebt gekozen. We schetsen in het vervolg een globaal beeld, zonder al te veel in detail te treden.

Allereerst moeten we onze trainingsgegevens ergens vandaan halen. Voordat we automatisch fraude kunnen opsporen, hebben een dataset met voorbeelden van fraude nodig. Voor elk voorbeeld moeten we een reeks invoereigenschappen hebben vastgelegd (of met terugwerkende kracht kunnen berekenen) die van pas kan komen bij toekomstige voorspellingen van de uitvoerwaarde. Deze invoereigenschappen worden kenmerken genoemd. De verzameling van invoerwaarden voor een bepaalde sample is een kenmerkvector. In ons bovenstaande voorbeeld had de kenmerkvector een lengte van drie: het land waar de kaart werd uitgegeven, het aantal landen waarin de kaart de afgelopen dag werd gebruikt en het betalingsbedrag in USD.

Kenmerkvectoren met honderden of zelfs duizenden kenmerken zijn echter niet ongebruikelijk. Zo gebruikt Radar bijvoorbeeld honderden kenmerken en de meeste daarvan zijn aggregaten die in het Stripe-netwerk worden berekend. Naarmate ons netwerk groeit, geeft elk kenmerk ons meer informatie. Dit komt doordat onze trainingsgegevens representatiever worden voor de volledige dataset van het kenmerk, waaronder alle gegevens die niet van Stripe afkomstig zijn. De uitvoerwaarde wordt vaak een doel of label genoemd. In ons voorbeeld was dit de booleaanse waarde die aangaf of de transactie wel of niet frauduleus was. De trainingsgegevens bestaan dus uit een groot aantal kenmerkvectoren en de bijbehorende uitvoerwaarden.

Ten tweede moeten we een model trainen. We hebben een methode nodig om ons voorspellende model te produceren die past bij onze trainingsgegevens. Classificaties van machine-learning genereren doorgaans niet alleen een klassenlabel als uitvoer, maar geven meestal aan hoe waarschijnlijk het is dat het gegeven sample tot een van de mogelijke klassen behoort. De uitvoer van een fraudeclassificatie kan bijvoorbeeld zijn dat er een kans van 65% is dat de betaling frauduleus is en een kans van 35% dat deze legitiem is.

Er zijn veel machine-learningtechnieken die kunnen worden gebruikt om modellen te trainen. Voor de meeste industriële toepassingen van machine-learning zijn traditionele benaderingen zoals lineaire regressie, beslissingsbomen of willekeurige beslissingsbossen een prima oplossing.

Het zijn echter geavanceerde technieken zoals neurale netwerken en deep-learning, geïnspireerd op de architectuur van neuronen in onze hersenen, die verantwoordelijk zijn voor een groot deel van de vooruitgang in dit veld, waaronder de AlphaFold-software die 98% van alle menselijke eiwitten kan voorspellen. Neurale netwerken kunnen alleen optimaal worden benut als ze zijn getraind met zeer grote datasets. In de praktijk kunnen veel bedrijven er dus niet volledig van profiteren. Vanwege de omvang van ons netwerk is Stripe in staat om deze meer geavanceerde aanpak te gebruiken en onze gebruikers echte resultaten te leveren. Onze nieuwe modellen hebben de prestaties van Radar op het gebied van machine-learning op jaarbasis met meer dan 20% verbeterd. Zo kunnen we meer fraude opsporen en tegelijkertijd het aantal valse positieven laag houden.

Kenmerk-engineering

Een van de belangrijkste onderdelen van industriële machine-learning is kenmerk-engineering. Dit bestaat uit twee delen:
Het formuleren van kenmerken die voorspellende waarde hebben op basis van uitgebreide kennis van het probleemdomein
Engineering om de waarden van die kenmerken beschikbaar te maken voor modeltraining en modelevaluatie in productieomgevingen

Bij het formuleren van een kenmerk kan een Stripe-datawetenschapper bijvoorbeeld bedenken dat het nuttig zou zijn om te weten of een kaartbetaling afkomstig is van een IP-adres dat gebruikelijk is voor die kaart. Bij een kaartbetaling afkomstig van IP-adressen die eerder zijn waargenomen (zoals de woning of werkplek van de kaarthouder), is het minder waarschijnlijk dat de betaling frauduleus is dan wanneer het IP-adres uit een ander land komt. Dit voorbeeld is verder niet onderbouwd, maar over het algemeen worden deze ideeën geformuleerd op basis van onderzoek van duizenden fraudegevallen. Wist je bijvoorbeeld dat het berekenen van het verschil tussen de tijd op het gebruikersapparaat en de huidige Coordinated Universal Time (UTC) of het aantal landen waarin de kaart is geautoriseerd, kan helpen om fraude te detecteren?

Als we een idee voor een kenmerk hebben, moeten we de historische waarden ervan berekenen zodat we een nieuw model met dit kenmerk kunnen trainen. Dit betekent dat we een nieuwe kolom toevoegen aan de 'tabel' met gegevens die we gebruiken om ons model te produceren. Om dit te doen voor het kenmerk uit ons voorbeeld, moeten we voor elke betaling die ooit met Stripe is uitgevoerd de twee meest veelvoorkomende IP-adressen berekenen waarvandaan eerdere betalingen met de kaart zijn gedaan. We zouden dit kunnen doen met gedistribueerde verwerking via een Hadoop-taak, maar zelfs dan is het mogelijk dat de taak te veel tijd of geheugen in beslag neemt. Vervolgens zouden we kunnen proberen de berekening te optimaliseren door een ruimtebesparende probabilistische gegevensstructuur te gebruiken. Zelfs voor kenmerken die eenvoudig lijken, zijn een specifieke infrastructuur en gevestigde workflows nodig om gegevens voor modeltraining te produceren.

Niet alle kenmerken worden door engineers zelf gemaakt. Sommige kenmerken kunnen door het model worden berekend en getest voordat ze worden geïmplementeerd. Categorische waarden, zoals het land van herkomst van een kaart of de handelaar die een transactie heeft verwerkt, lenen zich goed voor deze aanpak, in tegenstelling tot numerieke kenmerken. Deze hebben vaak een breed scala aan waarden en het kan lastig zijn om ze correct te definiëren.

Bij Stripe trainen we onze modellen met transactiepatronen om voor elke handelaar een inbedding te leren. Een inbedding vergelijkt de coördinaten van de individuele handelaar met andere handelaren. Vergelijkbare handelaren zullen vaak vergelijkbare inbeddingen hebben (dit wordt gemeten door de cosinusafstand). Het model gebruikt deze om de leerresultaten over te brengen van de ene handelaar naar de andere. In de onderstaande tabel zie je hoe deze inbeddingen eruit zouden kunnen zien, aangezien Uber en Lyft waarschijnlijk meer op elkaar lijken dan op Slack. Bij Stripe gebruiken we inbeddingen voor verschillende categorische kenmerken, zoals de uitgevende bank, het land van de handelaar en de gebruiker, de dag van de week en meer.

Het gebruik van inbeddingen komt steeds vaker voor in grootschalige industriële toepassingen van machine-learning. Woordinbeddingen zoals deze helpen bijvoorbeeld de complexe semantische relaties tussen woorden vast te leggen en werden ook gebruikt in Word2Vec, BERT en GPT-3, mijlpalen op het gebied van natuurlijke-taalverwerking. Stripe produceert inbeddingen om gelijkenissen tussen verschillende entiteiten op het Stripe-netwerk vast te leggen, op dezelfde manier zoals de bovenstaande methoden overeenkomsten tussen woorden vastleggen. Inbeddingen zijn een krachtige manier om concepten op hoger niveau te leren zonder expliciete training. Fraudepatronen zijn bijvoorbeeld vaak geografisch ongelijk verdeeld. Als ons systeem een nieuw fraudepatroon in Brazilië identificeert, kan het met inbeddingen automatisch hetzelfde patroon identificeren als het in de VS opduikt, zonder verdere training. Op deze manier helpen algoritmische ontwikkelingen de verschuivende fraudepatronen voor te blijven en blijven onze klanten beschermd.

De evaluatie van machine-learningmodellen

Een nieuwe machine-learningclassifcatie voor fraude gebruikt honderden kenmerken en wijst een waarschijnlijkheid (of score) toe aan inkomende transacties om de betaling te beoordelen. Voordat we het model in een productieomgeving kunnen gebruiken, moeten we bepalen hoe effectief het is bij het opsporen van fraude.

Belangrijke termen

Om beter te begrijpen hoe we onze machine-learningsystemen evalueren, definiëren we hieronder enkele belangrijke termen.

Stel dat we een beleid hebben opgesteld om een betaling te blokkeren als de transactie volgens het machine-learningmodel een fraudewaarschijnlijkheid van ten minste 0,7 heeft. We schrijven dit als P(fraude) > 0,7. Hier zijn enkele cijfers waarmee je de prestaties van ons model en beleid kunt duiden:

• Precisie: De precisie van ons beleid is de fractie van de transacties die we blokkeren en die werkelijk frauduleus zijn. Hoe hoger de precisie, hoe minder valse positieven. Stel dat van de tien transacties P(fraude) > 0,7 van toepassing is op zes transacties, waarvan er vier werkelijk frauduleus zijn. De precisie is dan 4/6 = 0,66.

• Recall: Recall, ook wel sensitiviteit of het percentage echte positieven genoemd, is de fractie van alle fraude die door ons beleid wordt herkend. Dit is dus het deel van de fraude waarvoor P(fraude) > 0,7 geldt. Hoe hoger de recall, hoe minder valse negatieven. Stel dat van de tien transacties er vijf werkelijk frauduleus zijn. Als vier van deze transacties volgens ons model een P(fraude) > 0,7 krijgen toegewezen, dan is de recall 4/5 = 0,8.

• Percentage valse positieven: Het percentage valse positieven is de fractie van alle legitieme betalingen die ten onrechte door ons beleid wordt geblokkeerd. Stel dat van de tien transacties er vijf legitiem zijn. Als twee van deze transacties volgens ons model een P(fraude) > 0,7 krijgen toegewezen, dan is het percentage valse positieven 2/5 = 0,4.

Hoewel er andere cijfers worden gebruikt bij het evalueren van een classificatie, richten we ons hier op deze drie.

Precisie-recall- en ROC-curven

De volgende vraag die voor de hand ligt: Wat zijn goede waarden voor de precisie, recall en het percentage valse positieven? In een theoretisch ideale wereld zou de precisie 1,0 zijn: Dus 100% van de transacties die je als fraude aanmerkt, is werkelijk fraude. Dit zou betekenen dat het percentage valse positieven 0 is, omdat je geen enkele legitieme transactie verkeerd hebt aangemerkt als frauduleus. De recall zou ook 1,0 zijn, want 100% van de fraude wordt als zodanig geïdentificeerd.

In werkelijkheid is er een wisselwerking tussen precisie en recall. Als je de waarschijnlijkheidsdrempel voor blokkeren verhoogt, stijgt de precisie (omdat het criterium voor blokkeren strenger is) en daalt de recall (omdat minder transacties overeenkomen met het criterium voor hoge waarschijnlijkheid). De precisie-recallcurve laat zien hoe de gekozen beleidsdrempel van invloed is op de precisie en de recall van een bepaald model:

Ons model wordt beter doordat we het trainen met steeds meer gegevens uit het hele Stripe-netwerk, door het toevoegen van kenmerken die fraude goed kunnen voorspellen en het aanpassen van andere modelparameters. Zoals je kunt zien in het voorbeeld hierboven, verandert de precisie-recallcurve mee. Wanneer onze datawetenschappers en machine-learningengineers modellen aanpassen, houden we de impact op de precisie-recallcurve goed in de gaten. Deze heeft namelijk rechtstreeks invloed op bedrijven die Stripe gebruiken.

'Prestaties' kunnen op twee manieren worden geïnterpreteerd bij een precisie-recallcurve. Het is belangrijk om hier onderscheid tussen te maken. Een model an sich is over het algemeen beter wanneer de lijn de rechterbovenhoek van de grafiek aantikt, waar de precisie en recall allebei 1,0 zijn. Voor het operationeel maken van een model moet er echter meestal een werkpunt op de precisie-recallcurve worden ingenomen waarmee de concrete impact van het model op het bedrijf wordt gecontroleerd. In ons geval is dit de beleidsdrempel voor het blokkeren van een transactie.

Simpel gezegd zijn er twee problemen:

• Het probleem van de datawetenschap om een goed machine-learningmodel te produceren door de juiste kenmerken toe te voegen. Het model geeft de precisie-recallcurve vorm.

• Het probleem van het bedrijf om een beleid te kiezen dat bepaalt hoeveel potentiële fraude moet worden geblokkeerd. Het beleid bepaalt de positie die we op de curve innemen.

Bij het evalueren van een machine-learningmodel wordt er nog een andere curve tegen het licht gehouden: de ROC-curve. ROC staat voor 'receiver operating characteristic' en verwijst naar de oorsprong van de curve in signaalverwerkingstoepassingen. De ROC-curve is een grafiek met het percentage valse positieven (op de x-as) en het percentage echte positieven (hetzelfde als de recall) op de y-as voor verschillende waarden van de beleidsdrempel.

De ideale ROC tikt de linkerbovenhoek van de grafiek aan (waar recall 1,0 is en het percentage valse positieven 0,0). Hoe beter het model wordt, hoe meer de ROC in die richting zal bewegen. Eén manier om de algehele kwaliteit van het model te bepalen, is door het gebied onder de curve (area under the curve, AUC) te berekenen. In een ideale situatie is de AUC 1,0. Bij het ontwikkelen van onze modellen kijken we hoe de precisie-recallcurve, de ROC-curve en de AUC veranderen.

Scoreverdeling

Stel dat we een model hebben dat willekeurig een waarschijnlijkheid van fraude tussen 0,0 en 1,0 aan een transactie toewijst. In de praktijk maakt dit model geen enkel onderscheid tussen legitieme en frauduleuze transacties en hebben we er niet veel aan. Deze willekeurigheid wordt uitgedrukt door de scoreverdeling van het model, het deel van de transacties dat elke mogelijke score krijgt. Bij volledige willekeurigheid zou de scoreverdeling vrijwel uniform zijn:

Een model zal bijvoorbeeld een uniforme scoreverdeling hebben zoals hierboven wanneer er geen kenmerken zijn die op geen enkele manier wijzen op fraude. Als een model wordt verbeterd door het toevoegen van voorspellende kenmerken, training met meer gegevens, enzovoort, zal het vermogen om onderscheid te maken tussen de frauduleuze en legitieme klassen toenemen en zal de scoreverdeling bimodaal worden, met pieken rond de scores van 0,0 en 1,0.

Een bimodale verdeling alleen betekent niet dat een model goed is. Een leeg model dat willekeurig waarschijnlijkheden van alleen 0,0 en 1,0 toekent, zou bijvoorbeeld ook een bimodale scoreverdeling hebben. Als er echter bewijs is dat transacties met een lage score niet frauduleus en transacties met een hoge score wel frauduleus zijn, is een sterke bimodale verdeling een teken van een verbeterde effectiviteit van een model.

Verschillende modellen hebben vaak verschillende scoreverdelingen. Wanneer we nieuwe modellen uitbrengen, vergelijken we de oude en nieuwe verdelingen om eventuele ontwrichtende veranderingen als gevolg van een plotselinge verschuiving in scores te minimaliseren. We houden in het bijzonder rekening met het huidige blokkeringsbeleid van handelaren, oftewel de drempel waarop ze transacties blokkeren, en streven ernaar het percentage transacties dat boven de drempel valt stabiel te houden.

Precisie en recall berekenen

We kunnen de bovenstaande cijfers in twee verschillende contexten berekenen: tijdens modeltraining, met de historische gegevens die worden gebruikt voor het ontwikkelen van modellen, en na modelimplementatie, wanneer de gegevens in het model al worden gebruikt om actie te ondernemen door bijvoorbeeld transacties te blokkeren als P(fraude) > 0,7.

In de eerste context gebruiken datawetenschappers meestal de trainingsgegevens die ze hebben (zie de tabel hierboven) en wijzen ze willekeurig een fractie van de records toe aan een trainingsset en de andere records aan een validatieset. Laten we zeggen dat de eerste 80% van de rijen voor training wordt gebruikt en de laatste 20% voor validatie.

De trainingsset is de invoer voor een machine-learningmethode waarmee een model wordt geproduceerd zoals hierboven beschreven. Zodra we een kandidaat-model hebben, kunnen we het gebruiken om scores toe te wijzen aan elke sample in de validatieset. De scores van de validatieset in combinatie met de uitvoerwaarden worden gebruikt voor het berekenen van de ROC-curve, de precisie-recallcurve, de scoreverdelingen, enzovoort. We gebruiken een aparte validatieset, los van de trainingsset, omdat het model 'het antwoord al heeft gezien' voor de trainingsvoorbeelden en hiervan heeft geleerd. Met een validatieset kunnen we indicatoren genereren die de voorspellende kracht van het model voor nieuwe gegevens correct weergeven.

Machine-learningactiviteiten: modellen veilig en vaak implementeren

We moeten eerst aantonen dat het model de prestaties van het huidige productiemodel overtreft voor een aparte set gegevens. De volgende stap is om het model te implementeren in een productieomgeving. Hierbij moeten we twee belangrijke uitdagingen het hoofd bieden:

• Realtime berekeningen: We moeten de waarde van elk kenmerk voor elke nieuwe betaling in real-time kunnen berekenen, omdat we alle transacties willen blokkeren waarvan onze classificatie denkt dat ze waarschijnlijk frauduleus zijn. Deze berekening staat geheel los van de berekening die wordt gebruikt om trainingsgegevens te produceren. Voor elke kaart die ooit op Stripe is waargenomen, moeten we een actuele status voor de twee meest gebruikte IP-adressen hebben. Deze gegevens moeten snel worden opgehaald en bijgewerkt, omdat deze bewerkingen plaatsvinden als onderdeel van de Stripe API-flow. De teams voor machine-learninginfrastructuur bij Stripe hebben dit eenvoudiger gemaakt door systemen te bouwen die kenmerken op een declaratieve manier specificeren en de huidige waarden van de kenmerken automatisch en snel beschikbaar maken in de productieomgeving.

• Toepassing in de praktijk: Het implementeren van een machine-learningmodel is niet hetzelfde als het implementeren van code. Wijzigingen in de code worden meestal gevalideerd met nauwkeurige testcases, terwijl wijzigingen in modellen normaal gesproken worden getest op een grote samengevoegde gegevensset met indicatoren zoals hierboven zijn gedefinieerd. Een model dat beter fraude herkent in samengevoegde gegevens, hoeft niet beter te zijn voor elke Stripe-gebruiker. Zo kan de prestatieverbetering ongelijk verdeeld zijn, waarbij enkele grotere handelaren er enorm op vooruitgaan terwijl de meeste kleinere handelaren er juist iets op achteruitgaan. Een model kan een hogere recall hebben, maar een piek in het blokkeringspercentage veroorzaken die verstorend werkt voor bedrijven (en hun klanten). Voordat we een model uitbrengen, controleren we dan ook of het in de praktijk goed werkt. Dit doen we door te meten welke veranderingen elk model zou veroorzaken in verschillende indicatoren voor een subset van Stripe-gebruikers, zowel in totaal als per handelaar. Denk hierbij aan indicatoren als het percentage valse positieven, het blokkeringspercentage en het autorisatiepercentage. Als blijkt dat een nieuw model een ongewenste verschuiving zou veroorzaken in een van deze belangrijke indicatoren, passen we het aan voor verschillende subsets van gebruikers voordat we het model uitbrengen. Zo beperken we onderbrekingen en kunnen we optimale prestaties garanderen.

De automatisering van een groot deel van het trainings- en evaluatieproces biedt verschillende voordelen voor de snelheid waarmee we nieuwe modellen kunnen uitbrengen. In het afgelopen jaar hebben we geïnvesteerd in tools om modellen automatisch en regelmatig te trainen, af te stemmen en te evalueren met behulp van onze nieuwste kenmerken en modelarchitectuur. We werken bijvoorbeeld voortdurend prestatiedashboards bij nadat een model is getraind, nog voordat het wordt uitgebracht. Op die manier kan een engineer eenvoudig voor de release zien of een kandidaat-model minder nauwkeurige prestaties levert voor een subset van verkeer en het proactief opnieuw trainen.

Na de release van een nieuw model blijven we de prestaties ervan controleren en beginnen we aan de volgende release te werken. Fraudetrends veranderen snel, waardoor machine-learningmodellen al snel afwijkingen vertonen. De gegevens waarmee ze zijn getraind, zijn niet langer representatief voor de nieuwste fraudeontwikkelingen.

Met deze tools kunnen we modellen nu drie keer sneller uitbrengen dan in het verleden, wat zich direct vertaalt in grote prestatieverbeteringen in productieomgevingen. Zelfs als we een model van afgelopen maand opnieuw trainen met recentere gegevens (en dezelfde kenmerkdefinities en architectuur) en uitbrengen, kunnen we onze recall met wel een half procentpunt per maand verbeteren. Doordat we in staat zijn om modellen regelmatig en op een veilige manier uit te brengen, kunnen we de voordelen van kenmerk-engineering en de modellen benutten om ons aan te passen aan veranderende fraudepatronen voor Radar-gebruikers.

Zodra we een model in productie hebben genomen, houden we de prestaties van ons model plus beleid voortdurend in de gaten. Voor betalingen met scores onder de blokkeringsdrempel kunnen we het uiteindelijke resultaat zien: Heeft de kaarthouder een chargeback ingediend voor de transactie? Betalingen met scores boven de drempel worden echter geblokkeerd en dus kunnen we niet weten wat de resultaten hiervan zouden zijn geweest. Er komt dus meer kijken bij het berekenen van de volledige precisie-recall- en ROC-curven in productieomgevingen dan bij het berekenen van de validatiecurven. Dit komt door de contrafeitelijke analyse die plaatsvindt. We moeten statistisch verantwoorde schattingen verzamelen van wat er zou zijn gebeurd, zelfs voor de betalingen die we hebben geblokkeerd. In de loop der jaren heeft Stripe methoden ontwikkeld om dit te doen. In deze video vertellen we je er meer over.

We hebben zojuist een aantal manieren beschreven om de effectiviteit van modellen te meten die datawetenschappers en machine-learningengineers gebruiken bij het ontwikkelen van machine-learningmodellen. Nu gaan we het hebben over hoe bedrijven naar fraudepreventie zouden moeten kijken.

De voordelen van Stripe

Als je je fraudeprestaties baseert op één cijfer, kan dit leiden tot keuzes die niet optimaal zijn voor je bedrijf. We zien dat bedrijven vaak te veel nadruk leggen op valse negatieven omdat ze geen enkele fraude over het hoofd willen zien, maar dit gaat ten koste van de valse positieven. Deze denkrichting leidt vaak tot ineffectieve en dure, rigide maatregelen zoals het blokkeren van alle internationale kaarten. Over het algemeen is het belangrijk om het verband tussen de verschillende indicatoren in het oog te houden en te kijken wat gezien de omstandigheden het beste bij je past. In dit voorbeeld laten we je zien hoe deze indicatoren je helpen om de effectiviteit van je fraudepreventiesysteem te bepalen:

BENADERINGSMODEL VOOR BREAK-EVENPRECISIE

Als je gemiddelde verkooptransactie 26 euro bedraagt met een marge van 8%, is je winst per verkoop 26 euro x 8,00% = 2,08 euro. Als je product gemiddeld 26,00 euro- 2,08 euro= 23,92 euro kost om te produceren en je chargebackkosten van 15 euro moet betalen, bedraagt je totale verlies voor een frauduleuze transactie 23,92 euro+15 euro = 38,92 euro. Een frauduleuze verkooptransactie kost je de winst van 38,92 euro / 2,08 euro= 18,7 legitieme transacties en je break-evenprecisie is 1 / (1 + 18,71) = 5,07%.

De machine-learning van Radar gebruikt drempels om voor al onze klanten zowel de marges te optimaliseren als de blokkeringspercentages stabiel te houden. Je hebt toegang tot een dashboard om te zien wat de machine-learning doet voor jouw bedrijf. Als je Radar for Fraud Teams gebruikt, kun je hier bovendien de prestaties van je aangepaste regels bekijken. Met deze tools kun je eenvoudig je percentage chargebacks, percentage valse positieven en blokkeringspercentage vergelijken met andere soortgelijke bedrijven. Hiervoor gebruiken we samengevoegde gegevens van bedrijven van ongeveer dezelfde grootte en uit vergelijkbare sectoren.

Prestaties verbeteren met regels en handmatige controles

Radar for Fraud Teams biedt bescherming op maat. Zo kun je het risiconiveau rechtstreeks aanpassen om meer betalingen te blokkeren of toe te staan. Naast de meer automatische algoritmen voor machine-learning kan ieder bedrijf met Radar for Fraud Teams ook zelf regels instellen, bijvoorbeeld om alle transacties boven de 1000 euro te blokkeren wanneer het land van het IP-adres niet overeenkomt met het land van de kaart. Verder kunnen bedrijven ook interventies aanvragen en gemarkeerde betalingen handmatig controleren in het Dashboard.

Dergelijke regels kunnen worden gezien als eenvoudige 'modellen': je zou er tenslotte een beslissingsboom van kunnen maken. Ze moeten daarom op dezelfde manier als modellen worden geëvalueerd, dus rekening houdend met de wisselwerking tussen precisie en recall. Wanneer je een regel maakt met Radar, tonen we je historische statistieken over het aantal overeenkomende transacties dat daadwerkelijk is betwist, terugbetaald of geaccepteerd. Zo kun je de juiste afweging maken vóór het implementeren van een regel. Zodra de regel live is, kun je de impact op de percentages valse positieven en chargebacks per regel bekijken.

En niet te vergeten: met regels, interventies en handmatige controles kunnen gebruikers de vorm van de precisie-recallcurve wijzigen, bijvoorbeeld door eigen, bedrijfsspecifieke logica(regels) toe te voegen of door wat extra moeite te doen (handmatige controles).

Als je merkt dat de machine-learningalgoritmen vaak een bepaald soort fraude missen dat specifiek is voor je bedrijf en dat je eenvoudig zelf kunt herkennen, dan kun je een regel opstellen om dit soort fraude tegen te houden. Dergelijke specifieke interventie zal de recall doen stijgen zonder al te grote gevolgen voor de precisie. De positie op de precisie-recallcurve beweegt daardoor langs een minder steile en dus gunstigere lijn.

Door sommige categorieën met transacties handmatig te controleren in plaats van ze direct te blokkeren, kun je de precisie verbeteren zonder dat dit ten koste gaat van de recall. Op dezelfde manier kun je de recall verbeteren zonder grote impact op de precisie door sommige transacties handmatig te controleren in plaats van ze allemaal toe te staan.
Deze winst komt natuurlijk niet helemaal voor niets, want je maakt kosten voor het extra handmatige werk en je moet vertrouwen op de nauwkeurigheid van de beoordelingen van je team. Je kunt de handmatige controles, regels en interventies dan ook zien als extra tools om klanten met een hoog risico te authenticeren en zo je frauderesultaten te optimaliseren.

Volgende stappen

We hopen dat deze gids je helpt begrijpen hoe machine-learning wordt toegepast bij fraudepreventie van Stripe en hoe je de effectiviteit van je fraudesystemen kunt meten. Je kunt meer te weten komen over de functies van Radar of onze documentatie bekijken.

Heb je vragen of wil je meer informatie over Stripe Radar? Neem dan gerust contact met ons op.