Den senaste tidens massiva acceleration av e-handeln har skapat en motsvarande ökning av bedrägerier med onlinebetalningar. Över hela världen kostar bedrägerier företag mer än uppskattningsvis 20 miljarder dollar per år. Dessutom, för varje dollar som förloras på grund av bedrägerier, är den totala kostnaden för företag faktiskt mycket högre på grund av ökade driftskostnader, nätverksavgifter och kundbortfall.

Bedrägerier är inte bara dyra, utan sofistikerade bedragare hittar ständigt nya sätt att utnyttja svagheter, vilket gör bedrägerier svåra att bekämpa. Det är därför vi byggde Stripe Radar, en maskininlärningsbaserad lösning för bedrägeribekämpning, helt integrerad i Stripe-plattformen. Radars maskininlärning utnyttjar data från hundratals miljarder dollar i betalningar som behandlas i Stripes nätverk varje år för att med precision upptäcka bedrägerier och snabbt anpassa sig till de senaste trenderna, vilket gör att du kan växa utan att öka bedrägerierna.

Den här guiden introducerar Stripe Radar och hur vi utnyttjar Stripes nätverk för att upptäcka bedrägerier, ger en översikt över de maskininlärningstekniker vi använder, förklarar hur vi tänker kring effektiviteten och prestandan hos system för upptäckt av bedrägerier och beskriver hur andra verktyg i Radar-sviten kan hjälpa företag att optimera sin bedrägeriprestanda.

Introduktion till kreditkortsbedrägerier på nätet

En betalning anses vara bedräglig när kortinnehavaren inte godkänner debiteringen. Om en bedragare till exempel gör ett köp med ett stulet kortnummer som inte har rapporterats är det möjligt att betalningen kan behandlas. Sedan, när kortinnehavaren upptäcker bedräglig användning av kortet, skulle han eller hon ifrågasätta betalningen med sin bank genom att lämna in en tvist (även känd som en ”återkreditering”).

Företag kan bestrida en återkreditering genom att skicka in bevis som visar att betalningen var giltig. Men för transaktioner utan kort närvarande, om betalningen av nätverken anses har varit verkligt bedräglig, kommer kortinnehavaren att vinna och företaget kommer att vara ansvarigt för förlust av varor och andra avgifter.

Historiskt sett har företag använt brute-force-regler för att förutsäga och blockera misstänkta bedrägliga debiteringar. Hårdkodade regler, till exempel blockering av alla kreditkort som används utomlands, kan dock leda till att många bra transaktioner blockeras. Maskininlärning, å andra sidan, kan upptäcka mer nyanserade mönster för att hjälpa dig att maximera intäkterna. På maskininlärningsspråk är ett falskt negativt resultat när systemet missar något som det är utformat för att upptäcka – i det här fallet en bedräglig transaktion. En falsk positiv identifiering är när systemet flaggar något som det inte borde ha gjort, till exempel blockerar en legitim kund. Innan vi går in på detaljerna i maskininlärning är det viktigt att förstå kompromisserna.

Med falska negativa resultat är företag ofta ansvariga för det ursprungliga transaktionsbeloppet plus återkrediteringsavgifter (kostnaden för att banken återkallar kortbetalningen), högre nätverksavgifter till följd av tvisten och högre driftskostnader för att granska avgifter eller bekämpa tvister. Dessutom, om du ådrar dig för många tvister, kan du hamna i ett övervakningsprogram för återkrediteringar i nätverket, vilket kan leda till högre kostnader eller, i vissa fall, oförmåga att acceptera kortbetalningar.

Falska positiva resultat, eller falska avslag, är när en legitim kund försöker göra ett köp men hindras från att göra det. Falska avslag kan leda till att företaget får både lägre bruttovinst och ett dåligt rykte. Faktum är att i en nyligen genomförd undersökning sa 33 % av konsumenterna att de inte skulle handla igen hos ett företag efter en falsk avvisning.

Det finns en kompromiss mellan att förhindra fler tvister (falska negativa resultat) och att minska blockering av legitima kunder (falska positiva resultat) – ju färre du har av det förstnämnda, desto mer måste du tolerera av det senare (och vice versa). När du förhindrar fler bedrägerier kommer du att öka antalet bra kunder som blockeras. Å andra sidan ökar en minskning av antalet falska positiva resultat ofta sannolikheten för att fler verkliga bedrägerier faller mellan stolarna. Företag måste bestämma hur de ska balansera de två baserat på deras marginaler, tillväxtprofil och andra faktorer.

Om ett företags marginaler är små (till exempel om du säljer mat online) kan kostnaden för en bedräglig transaktion behöva kompenseras med hundratals bra transaktioner – vilket gör varje falskt negativt resultat mycket dyrt. Företag med denna profil kan luta sig mot att kasta ett brett nät när de försöker stoppa potentiella bedrägerier. Å andra sidan, om ett företags marginaler är höga, till exempel för ett SaaS-företag, är det tvärtom. De förlorade intäkterna från en legitim blockerad kund kan uppväga kostnaden för ökade bedrägerier.

Stripe Radar and the Stripe network

Radar is Stripe’s fraud prevention solution that protects businesses against online credit card fraud. It is powered by adaptive machine learning, the result of years of data science and infrastructure work by Stripe’s dedicated machine learning teams. Radar’s algorithms evaluate every transaction for fraud risk and take action appropriately. High-scoring payments are blocked, and Radar for Fraud Teams provides tools so users can specify when other actions should be taken.

Stripe processes hundreds of billions in payments from millions of businesses and interacts with thousands of partner banks across the globe each year. This scale means we often can see signals and patterns much earlier than smaller networks. Aggregate data relevant to fraud from all Stripe transactions—collected automatically through the payments flow—is used to improve our fraud detection ability. Signals like the country in which the card was issued or the IP address from which the payment was made provide valuable insights when predicting whether the payment is likely to be fraudulent.

Previous encounters with a card across the Stripe network also offer a significant amount of data to inform our risk assessments. Ninety percent of the cards used on the Stripe network have been seen more than once, giving us much richer data to make assessments on whether they are being used legitimately or fraudulently.

Another key advantage to our machine learning is that Radar is built directly into Stripe and works out of the box. Other fraud prevention solutions generally require a substantial amount of both upfront and ongoing investment. First, businesses must integrate with the fraud product. This involves engineering work to send data on relevant events and payments. Second, businesses must complete an integration to pass payment labels—a categorization of whether or not the transaction was fraudulent—from their payment processor to their fraud provider or manually label payments themselves, which can be incredibly time consuming and error prone. Radar, on the other hand, receives “ground truth” information directly from the usual Stripe payment flow and taps into timely and accurate data directly from card networks and issuers—no engineering time or coding required.

Let’s dive into a more detailed look at machine learning and how we use it at Stripe.

The basics of machine learning

Machine learning refers to a body of techniques for taking large amounts of data and using that data to produce models that predict outcomes, such as the likelihood a charge will result in a fraud dispute.

One of the main applications of machine learning is prediction: We want to predict the value of some output variable given some input values. In our case, the output value is true if the payment is fraudulent and false otherwise (such binary values are called booleans), and an example of an input value could be the country the card was issued in or the number of distinct countries where the card was used across the Stripe network in the past day. We determine how to make a prediction based on previous examples of input and output data.

The data used to train (or generate) the models consists of records (often obtained from historical data) with both the output value and the various input values as we have in the following (highly simplified) example:

While there are only three inputs in this example, in practice machine learning models often have hundreds or thousands of inputs. The output of the machine learning algorithm might be a model like the following decision tree:

När vi observerar en ny transaktion tittar vi på indatavärdena och klättrar i trädet "20-frågorsstil" tills vi når ett av dess ”löv”. Varje löv består av alla prover i datauppsättningen (tabellen ovan) som uppfyller fråga-svar-paren längs den väg vi följde nedåt i trädet, och sannolikheten att vi tror att den nya transaktionen är bedräglig är antalet prover i lövet som är bedrägliga dividerat med det totala antalet prover i lövet. Med andra ord svarar trädet på frågan: ”Av transaktioner i vår datauppsättning med egenskaper som liknar den transaktion vi undersöker nu, vilken andel var faktiskt bedrägliga?” Maskininlärningsdelen handlar om konstruktionen av trädet – vilka frågor ställer vi, i vilken ordning, för att maximera chanserna att vi kan skilja mellan de två klasserna exakt? Beslutsträd är särskilt lätta att visualisera och resonera kring, men det finns många olika inlärningsalgoritmer, var och en med sitt eget unika sätt att representera de relationer vi försöker modellera.

Dagens maskininlärningsmodeller är vanliga – de driver många av produkterna vi ofta interagerar med bakom kulisserna – och är i allmänhet mycket mer sofistikerade än leksaksmodellen ovan:

• Google ger exakta stavningsförslag med funktionen ”Menade du?” i Sök med hjälp av maskininlärning för att modellera miljontals språkrelaterade parametrar på mindre än tre sekunder.
  
• Amazon använder maskininlärning för att förutsäga köp med sitt rekommendationssystem baserat på användarnas behov, preferenser och förändrade beteenden över hela plattformen, även för nya användare utan historiska data.
  

Och det som är mest relevant för den här diskussionen är att maskininlärning är grunden för Stripe Radar, som försöker förutsäga vilka av dina betalningar som är bedrägliga.

Hur fungerar maskininlärning?

Akademiska maskininlärningskurser fokuserar vanligtvis på modelleringsprocessen – metoderna för att översätta data (t.ex. tabellen ovan) till modellerna (t.ex. beslutsträdet), som är algoritmerna som talar om hur indatavärden (det land där kortet utfärdades, antalet länder där kortet användes osv.) mappas till utdatavärden (var transaktionen bedräglig eller inte?). Processen som tar indatatabellen ovan och skapar det ”bästa” trädet är ett exempel på en viss maskininlärningsmetod. Modellering omfattar ett antal steg som beror på vilken typ av data du har och vilka modeller du har valt att använda. Även om vi inte kommer att gå in på för mycket detaljer, följer en översikt på hög nivå.

Först måste vi få träningsdata. Innan vi kan börja upptäcka bedrägerier automatiskt behöver vi en datauppsättning med exempel på det. För varje exempel måste vi ha registrerat (eller kunna beräkna retroaktivt) en rad indataegenskaper som kan vara användbara för att göra framtida förutsägelser om utdatavärdet. Dessa indataegenskaper kallas funktioner. Samlingen av indata tillsammans för ett visst exempel är en funktionsvektor. I vårt exempel ovan hade funktionsvektorn längden tre (det land där kortet utfärdades, antalet länder där kortet användes under den senaste dagen och betalningsbeloppet i USD).

Funktionsvektorer med hundratals eller tusentals funktioner är dock inte ovanliga. Faktum är att Radar använder hundratals funktioner och de flesta av dem är aggregat som beräknas från hela Stripe-nätverket. I takt med att vår nätverksstorlek växer blir varje funktion mer informativ eftersom våra träningsdata blir mer representativa för funktionens hela datauppsättning, inklusive alla data som inte kommer från Stripe. Utdatavärdet – i vårt löpande exempel det booleska värdet för om transaktionen var bedräglig eller inte – kallas ofta för ett mål eller en etikett. Träningsdata består således av ett stort antal funktionsvektorer och deras motsvarande utdatavärden.

För det andra måste vi träna en modell. Med tanke på träningsdata behöver vi en metod för att ta fram vår prediktiva modell. Maskininlärningsklassificerare matar i allmänhet inte bara ut en klassetikett – de tilldelar vanligtvis sannolikheter för att det givna exemplet tillhör varje möjlig klass. Utdata från en bedrägeriklassificerare kan till exempel vara en bedömning av att betalningen har 65 % risk att vara bedräglig och 35 % chans att vara legitim.

Det finns många maskininlärningstekniker som kan användas för att träna modeller. För de flesta industriella maskininlärningsprogram fungerar traditionella metoder som linjär regression, beslutsträd eller slumpmässiga skogar bra.

Sofistikerad teknik, nämligen neurala nät och djupinlärning, inspirerad av neuronernas arkitektur i hjärnan, är ansvariga för många framsteg inom området, bland annat AlphaFolds förutsägelser för 98 % av alla mänskliga proteiner. De verkliga fördelarna med neurala nät kommer bara när de tränas på mycket stora datamängder, så i praktiken kan många företag inte dra full nytta av dem. På grund av storleken på vårt nätverk kan Stripe använda denna mer avancerade metod för att leverera verkliga resultat till våra användare. Våra nya modeller har förbättrat Radars maskininlärningsprestanda med över 20 % jämfört med föregående år, vilket hjälper oss att upptäcka fler bedrägerier samtidigt som vi håller nere antalet falska positiva resultat.

Funktionsteknik

En av de mest involverade delarna av industriell maskininlärning är funktionsteknik. Funktionsteknik består av två delar:
(1) formulering av funktioner som har prediktivt värde baserat på omfattande kunskap om problemområdet och (2) teknik för att göra värdena för dessa funktioner tillgängliga både för modellträning och för modellutvärdering i ”produktion”.

När en datavetare från Stripe formulerar en funktion kan han eller hon ha en föraning om att en användbar funktion skulle vara att beräkna om kortbetalningen kommer från en IP-adress som är vanlig för det kortet. Till exempel är det mindre sannolikt att en kortbetalning som kommer från IP-adresser som setts tidigare (t.ex. kortinnehavarens hem eller arbetsplats) är bedräglig än om IP-adressen var från en annan delstat. I det här fallet är idén intuitiv, men i allmänhet kommer dessa föraningar från att undersöka tusentals fall av bedrägeri. Du kan till exempel bli förvånad över att det hjälper till att upptäcka bedrägerier genom att beräkna skillnaden mellan tiden på användarenheten och den aktuella UTC-tiden (Coordinated Universal Time) eller antalet länder där kortet har auktoriserats.

När vi har funktionsidén måste vi beräkna dess historiska värden så att vi kan träna en ny modell som innehåller funktionen – det här är processen att lägga till en ny kolumn i ”tabellen” med data som vi använder för att skapa vår modell. För att göra detta för vår kandidatfunktion måste vi för varje betalning i Stripes historik beräkna de två vanligaste IP-adresserna från vilka tidigare betalningar gjordes med kortet. Vi kan göra detta på ett distribuerat sätt med ett Hadoop-jobb, men även då kan vi upptäcka att jobbet tar för mycket tid (eller minne). Vi kan sedan försöka optimera beräkningen med hjälp av en utrymmesbesparande probabilistisk datastruktur. Även för funktioner som är intuitivt enkla kräver produktion av data för modellträning dedikerad infrastruktur och etablerade arbetsflöden.

Alla funktioner är inte handgjorda av ingenjörer. En del kan lämnas kvar för att modellen ska beräknas med efterföljande testning före distributionen. Kategoriska värden, t.ex. ett korts ursprungsland eller handlaren som behandlade en transaktion (i motsats till numeriska funktioner), lämpar sig väl för detta tillvägagångssätt. Dessa funktioner har ofta ett brett utbud av värden, och det kan vara svårt att definiera en bra representation för dem.

På Stripe utbildar vi våra modeller för att lära sig en inbäddning för varje handlare baserat på transaktionsmönster. En inbäddning kan ses som koordinaterna för den enskilda handlaren jämfört med andra. Liknande handlare har ofta liknande inbäddningar (mätt som cosinusavstånd), vilket gör det möjligt för modellen att överföra lärdomar från en handlare till nästa. Tabellen nedan visar hur dessa inbäddningar kan se ut, med tanke på att Uber och Lyft sannolikt är mer lika varandra än Slack. På Stripe använder vi inbäddningar för en mängd olika kategoriska funktioner, till exempel utfärdande bank, handlar- och användarland, veckodag med mera.

Användningen av inbäddningar blir allt vanligare i storskaliga industriella tillämpningar av maskininlärning. Ordinbäddningar som dessa, till exempel, hjälper till att fånga de komplexa semantiska relationerna mellan ord och har varit inblandade i milstolpar för naturlig språkbehandling som Word2Vec, BERToch GPT-3. Stripe skapar inbäddningar för att fånga likhetsrelationer mellan olika enheter i Stripe-nätverket på samma sätt som metoderna ovan fångar likheter mellan ord. Inbäddningar är ett kraftfullt sätt att lära sig begrepp på högre nivå utan explicit träning. Till exempel är bedrägerimönstren ofta ojämnt fördelade geografiskt. Om vårt system identifierar ett nytt bedrägerimönster i Brasilien kan det automatiskt identifiera samma mönster om det dyker upp i USA, utan ytterligare utbildning. På så sätt hjälper algoritmiska framsteg till att ligga steget före skiftande bedrägerimönster och skydda våra kunder.

Utvärdering av maskininlärningsmodeller

När vi har utvecklat en maskininlärningsklassificerare för bedrägerier som använder hundratals funktioner och tilldelar en sannolikhet (eller poäng) för att betalningen är ett bedrägeri till varje inkommande transaktion, måste vi avgöra hur effektiv modellen är på att upptäcka bedrägerier.

Viktiga begrepp

För att bättre förstå hur vi utvärderar våra maskininlärningssystem är det bra att definiera några viktiga termer.

Låt oss börja med att anta att vi har skapat en policy för att blockera en betalning om maskininlärningsmodellen tilldelar transaktionen en sannolikhet för att vara bedräglig på minst 0,7. (Vi skriver detta som P(bedrägeri)>0,7). Här är några kvantiteter som är användbara för att resonera om prestanda för vår modell och policy:

• Precision: Precisionen i vår policy är den andel av transaktionerna vi blockerar som faktiskt är bedrägliga. Ju högre precisionen är, desto färre falska positiva resultat finns det. Låt oss säga att av 10 transaktioner är P(bedrägeri)>0,7 för sex och av dessa sex är fyra faktiskt bedrägliga. Precisionen blir då 4/6=0,66.

• Träffsäkerhet: Det är även känt som känslighet eller den verkliga positiva frekvensen. Träffsäkerhet är den andel av alla bedrägerier som fångas upp av vår policy; det vill säga den andel av bedrägeriet för vilken P(bedrägeri)>0,7. Ju högre återkallelsen är, desto färre falska negativa resultat finns det. Låt oss säga att av 10 transaktioner är fem faktiskt bedrägliga. Om fyra av dessa transaktioner tilldelas ett P(bedrägeri)>0,7 av vår modell, är träffsäkerhet 4/5=0,8.

• Falskt positivt resultat: Det falska positiva värdet är den andel av alla legitima betalningar som felaktigt blockeras av vår policy. Låt oss säga att av 10 transaktioner är fem legitima. Om två av dessa transaktioner tilldelas ett P(bedrägeri)>0,7 av vår modell, är den falska positiva frekvensen 2/5=0,4.

Även om det finns andra kvantiteter som används vid utvärdering av en klassificerare så fokuserar vi på dessa tre.

Precision-träffsäkerhet och ROC-kurvor

Nästa naturliga fråga är vilka bra värden som är för precision, träffsäkerhet och falsk positiv frekvens. I en teoretiskt idealisk värld skulle precisionen vara 1,0 (det vill säga 100 % av transaktionerna som du klassificerar som bedrägeri är faktiskt bedrägeri), vilket skulle göra att din falska positiva frekvens är 0 (du klassificerade inte felaktigt en enda legitim transaktion som bedräglig), och träffsäkerhet skulle också vara 1,0 (100 % av bedrägerierna identifieras som sådana).

I verkligheten finns det en kompromiss mellan precision och träffsäkerhet – när du ökar sannolikhetströskeln för blockering ökar precisionen (eftersom kriteriet för blockering är strängare) och träffsäkerhet minskar (eftersom färre transaktioner matchar kriteriet för hög sannolikhet). För en viss modell avbildar en precision-träffsäkerhetskurva kompromissen mellan precision och träffsäkerhet eftersom policytröskeln varierar:

I takt med att vår modell blir bättre överlag – tack vare att vi tränar mer och mer data från hela Stripe-nätverket, lägger till funktioner som är bra på att förutsäga bedrägerier och justerar andra modellparametrar – kommer kurvan för precision-träffsäkerhet att ändras, som i exemplet ovan. Eftersom Stripe styr avvägningen för företag övervakar vi noga hur kurvan för precisions-träffsäkerhet påverkas när våra datavetare och maskininlärningstekniker ändrar modeller.

När du överväger ett diagram för precisions-träffsäkerhet är det viktigt att skilja mellan de två begreppen ”prestanda”. På egen hand är en modell bättre totalt sett ju närmare den kramar det övre högra hörnet av diagrammet (det vill säga där både precision och träffsäkerhet är 1,0). Att operationalisera en modell kräver dock vanligtvis att man väljer en operativ punkt på precision-träffsäkerhetskurvan (i vårt fall policytröskeln för att blockera en transaktion), som styr den konkreta inverkan som användningen av modellen har på ett företag.

Enkelt uttryckt finns det två problem:

• Datavetenskapsproblemet med att ta fram en bra maskininlärningsmodell genom att lägga till rätt funktioner. Modellen styr formen på kurvan för precision-träffsäkerhet.

• Affärsproblemet med att välja en policy för att bestämma hur mycket potentiella bedrägerier som ska blockeras. Policyn styr var på kurvan vi är verksamma.

En annan kurva som undersöks vid utvärdering av en maskininlärningsmodell är ROC-kurvan (ROC är en förkortning för ”receiver operating characteristic”, en kvarleva från kurvans ursprung i signalbehandlingstillämpningar). ROC-kurvan är ett diagram över den falska positiva frekvensen (på x-axeln) och den sanna positiva frekvensen (som är densamma som träffsäkerheten) på y-axeln för olika värden på principtröskeln.

Den idealiska ROC kommer att krama det övre vänstra hörnet i diagrammet (där återkallelse är 1,0 och den falska positiva frekvensen är 0,0), och när modellen förbättras kommer ROC att röra sig mer i den riktningen. Ett sätt att fånga modellens övergripande kvalitet är att beräkna arean under kurvan (eller AUC). I det ideala fallet kommer AUC att vara 1,0. När vi utvecklar våra modeller tittar vi på hur precisions-träffsäkerhetskurvan, ROC-kurvan och AUC förändras.

Poängfördelningar

Föreställ dig att vi har en modell som slumpmässigt tilldelar en sannolikhet för bedrägeri mellan 0,0 och 1,0 till en transaktion. I praktiken gör denna modell ingenting för att skilja mellan legitima och bedrägliga transaktioner och är till liten nytta för oss. Den här slumpmässigheten fångas upp av modellens poängfördelning – den del av transaktionerna som får varje möjlig poäng. I det helt slumpmässiga fallet skulle poängfördelningen vara nästan enhetlig:

En modell kommer ha en enhetlig poängfördelning som ovan om, till exempel, modellen inte har några funktioner som ens är lite prediktiva för bedrägeri. När en modell förbättras – genom att lägga till prediktiva funktioner, träning på mer data och så vidare – kommer dess förmåga att skilja mellan bedrägliga och legitima klasser att öka och poängfördelningen kommer att bli mer bimodal, med toppar runt poängen 0,0 och 1,0.

En bimodal fördelning säger i sig inte att en modell är bra. (En innehållslös modell som slumpmässigt tilldelar sannolikheter på bara 0,0 och 1,0 skulle också ha en bimodal poängfördelning.) Men när det finns bevis på att transaktioner med en låg poäng inte är bedrägliga och transaktioner med en hög poäng är bedrägliga, är en alltmer bimodal fördelning ett tecken på förbättrad effektivitet för en modell.

Olika modeller har ofta olika poängfördelningar. När vi släpper nya modeller jämför vi de gamla och uppdaterade distributionerna för att minimera eventuella störande förändringar som orsakas av en plötslig förändring i poäng. I synnerhet tar vi hänsyn till handlarnas nuvarande blockeringspolicyer, mätt som den tröskel vid vilken de blockerar transaktioner, och strävar efter att hålla andelen transaktioner som faller över tröskelvärdet stabilt.

Beräkningsprecision och träffsäkerhet

Vi kan beräkna måtten ovan i två olika sammanhang: under modellträning, med hjälp av historiska data som driver modellutvecklingsprocessen, och efter modelldistribution, med hjälp av produktionsdata; det vill säga data från världen när modellen redan används för att vidta åtgärder genom att, till exempel, blockera transaktioner om P(bedrägeri)>0,7.

För det förstnämnda tar dataexperter vanligtvis de träningsdata de har (referera till tabellen ovan) och tilldelar slumpmässigt en del av posterna till en träningsuppsättning och de andra posterna till en valideringsuppsättning. Man kan till exempel tänka sig att de första 80 % av raderna går in i den förra och de sista 20 % i den senare.

Träningsuppsättningen är de data som matas in i en maskininlärningsmetod för att skapa en modell enligt beskrivningen ovan. När vi har en kandidatmodell kan vi sedan använda den för att tilldela poäng till varje prov i valideringsuppsättningen. Valideringsuppsättningens poäng tillsammans med deras utdatavärden används för att beräkna ROC- och precisions-träffsäkerhetskurvorna, poängfördelningarna och så vidare. Anledningen till att vi använder en separat valideringsuppsättning som hålls utanför träningsuppsättningen är att modellen redan har ”sett svaret” för sina träningsexempel och lärt sig av dessa svar. En valideringsuppsättning hjälper oss att generera mätvärden som är ett korrekt mått på modellens prediktiva kraft på nya data.

Maskininlärningsprocesser: distribuera modeller säkert och ofta

När en modells prestanda har visat sig överträffa den aktuella produktionsmodellen på en uthållen uppsättning är nästa steg att distribuera den till produktion. Det finns två viktiga utmaningar i den här processen:

• Realtidsberäkningar: Vi måste kunna beräkna värdet av varje funktion för varje ny betalning i realtid eftersom vi vill kunna blockera alla transaktioner som vår klassificerare tror sannolikt är bedrägliga. Den här beräkningen är helt skild från den som används för att producera träningsdata – vi måste upprätthålla ett uppdaterat tillstånd för de två mest använda IP-adresserna för varje kort som någonsin setts på Stripe, och det måste gå snabbt att hämta och uppdatera dessa siffror eftersom dessa operationer sker som en del av Stripe API-flödet. Infrastrukturteamen för maskininlärning på Stripe har gjort detta enklare genom att bygga system för att specificera funktioner på ett deklarativt sätt och göra de aktuella värdena för funktionerna tillgängliga automatiskt i produktion med låg latens.

• Användartillämpning i verkligheten: Att distribuera en maskininlärningsmodell skiljer sig från att distribuera kod. Kodändringar valideras ofta med exakta testfall, men modelländringar testas vanligtvis på en stor aggregerad datamängd med hjälp av mått som de vi definierade ovan. Men en modell som är bättre på att fånga upp bedrägerier i aggregerad form kanske inte är bättre för alla Stripe-användare. Det kan vara så att förbättringen av prestanda är ojämnt fördelad, med ett fåtal stora handlare som ser stora vinster medan många små handlare ser små regressioner. En modell kan ha högre träffsäkerhet men orsaka en topp i blockeringsfrekvensen, vilket skulle vara störande för företag (och deras kunder). Innan vi släpper en modell verifierar vi att den fungerar bra i praktiken. För att göra det mäter vi den förändring som varje modell skulle orsaka i en mängd olika mätvärden, till exempel falsk positiv frekvens, blockeringsfrekvens och auktoriseringsfrekvens aggregerat och per handlare för en undergrupp av Stripe-användare. Om vi upptäcker att en ny modell skulle orsaka en oönskad ändring i ett av dessa skyddsmätetal justerar vi den för olika delmängder av användare innan vi släpper den för att minimera störningar och säkerställa optimal prestanda.

Vi har upptäckt att automatisering av så mycket av tränings- och utvärderingsprocessen som möjligt ger adderade fördelar för modellens iterationshastighet. Under det senaste året har vi investerat i verktyg för att automatiskt och regelbundet träna, finjustera och utvärdera modeller med hjälp av våra senaste funktioner och modellarkitektur. Till exempel uppdaterar vi kontinuerligt dashboards för prestanda efter att en modell har tränats – innan den släpps. På så sätt kan en ingenjör enkelt upptäcka om en modellkandidat har blivit inaktuell på en delmängd av trafiken innan han ens släpper den och proaktivt träna om den.

När vi har släppt en modell övervakar vi dess prestanda och börjar arbeta med nästa version. Eftersom bedrägeritrenderna förändras snabbt börjar maskininlärningsmodeller snabbt att avvika: de data som de har tränats på är inte längre representativa för bedrägerier i dag.

Med hjälp av dessa verktyg har vi tredubblat hastigheten med vilken vi släpper modeller, vilket direkt översätts till stora prestandavinster i produktionen. Faktum är att även om vi tränar om en modell från förra månaden på nyare data (med samma funktionsdefinitioner och arkitektur) och släpper den kan vi öka vår träffsäkerhet med så mycket som en halv procentenhet varje månad. Att kunna släppa modeller ofta och säkert gör det möjligt för oss att dra nytta av och öka vinsterna med funktionsteknik och modelleringsarbete och anpassa oss till förändrade bedrägerimönster för Radar-användare.

När vi sätter en modell i produktion övervakar vi kontinuerligt prestandan för vårt modell-policypar. För betalningar som har poäng under tröskeln för blockering kan vi observera det slutliga resultatet – bestreds transaktionen av kortinnehavaren som bedrägeri? Betalningar som har poäng över tröskelvärdet är dock blockerade, så vi kan inte veta vad deras resultat skulle ha varit. Att beräkna hela produktionens precision-träffsäkerhets- eller ROC-kurva är därför mer komplicerat än att beräkna valideringskurvorna, eftersom det innebär kontrafaktisk analys – vi måste få statistiskt sunda uppskattningar av vad som skulle ha hänt även med de betalningar vi blockerade. Under årens lopp har Stripe utvecklat metoder för att göra detta, som du kan lära dig mer om i det här samtalet.

Vi har precis beskrivit några av de mått på modelleffektivitet som dataexperter och maskininlärningstekniker tittar på när de utvecklar maskininlärningsmodeller. Härnäst kommer vi att prata om hur företag bör tänka för att förebygga bedrägerier.

Så kan Stripe hjälpa dig

Att fixera sig vid bara en siffra för att fånga din bedrägeriprestanda kan resultera i val som inte är optimala för ditt företag. Vi har funnit att företag ofta överbetonar falska negativa resultat – de är mycket oroade över bedrägerier som missas – och underbetonar falska positiva resultat. Detta tankesätt resulterar ofta i ineffektiva och kostsamma brute-force-åtgärder som att blockera alla internationella kort. Generellt sett bör du tänka på hur alla de olika prestationsmåtten relaterar till varandra och vilka avvägningar som är rätt med tanke på dina specifika omständigheter. Här är ett exempel på hur dessa mätvärden hänger ihop för att hjälpa dig att avgöra hur effektivt ditt system för bedrägeribekämpning är:

BERÄKNAD MODELL FÖR BREAK-EVEN-PRECISION

Om din genomsnittliga försäljning är 26 USD med en marginal på 8 % är din vinst per försäljning 26,00 USD × 8,00 % = 2,08 USD. I genomsnitt, om din produkt kostar 26.00 USD – 2,08 USD = 23,92 USD att producera och du debiteras en återbetalningsavgift på 15 USD, är din totala förlust för en bedräglig försäljning 23,92 USD + 15,00 USD = 38,92 USD. Därför kostar en bedräglig försäljning dig vinsten på 38,92 USD / 2,08 USD = 18,71 i legitim försäljning, och din break-even-precision är 1 / (1 + 18,71) = 5,07 %.

Radars tröskelvärden för maskininlärning kompromissar med att optimera för handlarnas marginaler och hålla blockeringsfrekvenserna stabila i vår användarbas. Du kan komma åt en dashboard för att se hur Radars maskininlärning presterar för ditt företag, samt din prestanda för anpassade regler om du använder Radar for Fraud Teams. Med de här verktygen kan du enkelt jämföra dina bedrägliga tvistfrekvenser, falska positiva frekvenser och blockeringsfrekvenser med andra liknande företag baserat på sammanlagda, anpassade kohorter av företag som befinner sig i liknande vertikaler eller samma storlek som du.

Förbättra prestanda med regler och manuella granskningar

Med Radar for Fraud Teams kan du finjustera ditt skydd genom att direkt justera din risktröskel för att blockera eller tillåta fler betalningar. Vid sidan av de mer automatiska maskininlärningsalgoritmerna låter Radar for Fraud Teams också enskilda företag komponera anpassade regler (till exempel ”blockera alla transaktioner över 1 000 USD när IP-landet inte matchar kortets land”), begära ingripanden och manuellt granska flaggade betalningar i Dashboard.

Sådana regler kan ses som enkla ”modeller” (de kan trots allt representeras som beslutsträd!), och de bör utvärderas – med full hänsyn till avvägningen mellan precision och träffsäkerhet – på samma sätt som modeller. När du skapar en regel med Radar visar vi historisk statistik över antalet matchande transaktioner som faktiskt har bestridits, återbetalats eller godkänts för att hjälpa till med dessa beräkningar innan regeln ens har implementerats. När du är live kan du se effekten på andelen falska positiva identifieringar och tvister per regel.

Lika viktigt är att regler, ingripanden och manuella granskningar gör det möjligt för användare att ändra formen på precisions-träffsäkerhetskurvan till sin fördel genom att lägga till egenutvecklad, affärsspecifik logik (regler) eller genom att lägga ner lite extra arbete (manuell granskning).

Om du inser att maskininlärningsalgoritmerna ofta missar en viss typ av bedrägeri som är specifik för ditt företag (och att bedrägerier är lätta att identifiera för dig) kan du skapa en regel för att blockera det. Det specifika ingreppet ökar vanligtvis träffsäkerheten med liten kostnad för precisionen, vilket i praktiken innebär att operationspunkten flyttas längs en mindre brant, mer gynnsam precisions-återkallelsekurva.

Genom att skicka vissa klasser av transaktioner till manuell granskning istället för att blockera dem direkt kan du få precision utan att träffsäkerhet påverkas. På samma sätt, genom att skicka vissa transaktioner till manuell granskning istället för att tillåta dem direkt, kan du få träffsäkerhet utan att uppoffra precisionen.
I dessa fall betalar du naturligtvis för dessa vinster med ytterligare mänskligt arbete (och utsätter dig själv för noggrannheten i teamets bedömningar), men att ha manuell granskning, regler och ingripanden för att autentisera högriskkunder som ytterligare verktyg ger dig ytterligare en hävstång för att optimera bedrägeriresultaten.

Nästa steg

Vi hoppas att den här guiden hjälper dig att förstå hur maskininlärning tillämpas för att förebygga bedrägerier hos Stripe och hur du kan mäta effektiviteten i dina bedrägerisystem. Du kan lära dig mer om Radars funktioner eller utforska våra dokument.

Om du har några frågor eller vill veta mer om Stripe Radar kan du kontakta oss.