Att bedöma risken för bedrägerier är en kontinuerlig process för att identifiera angreppsvektorer, mönster och scenarier och minska dem. I nära samarbete med användarna har vårt team för professionella tjänster observerat att de företag som gör detta mest effektivt ofta har bedrägerianalytiker och dataanalytiker som arbetar tillsammans – med hjälp av en kombination av Stripe Radar for Fraud Teams och Stripe Data-produkter som Stripe Sigma eller Stripe Data Pipeline för att identifiera både vanliga bedrägerimönster och mönster som är specifika för deras verksamhet.

Radar for Fraud Teams hjälper dig att upptäcka och förhindra bedrägerier och ger dig möjlighet att skapa en skräddarsydd bedrägerikonfiguration som är unik för ditt företag, med anpassade regler, rapportering och manuella granskningar. Stripe Sigma är en rapporteringslösning som gör alla dina transaktions-, konverterings- och kunddata tillgängliga i en interaktiv miljö i Stripe Dashboard. Data Pipeline tillhandahåller samma data, men skickar dem automatiskt till ditt Snowflake- eller Redshift-datalager så att de kan nås tillsammans med dina andra företagsdata.

Dessa verktyg samverkar sömlöst för att täcka de fyra pelarna i en effektiv process för hantering av bedrägerier: Identifiering, Utredning, Bekräftelse samt förfining och lindring – som vi kommer att gå närmare in på.

Värdet av att använda Radar for Fraud Teams med Stripe Sigma eller Data Pipeline

Det primära målet med att använda Radar for Fraud Teams med Stripe Sigma eller Data Pipeline är att analysera Radars data, till exempel metadata, tillsammans med dina egna data – inklusive förauktorisering, användarens resa, konvertering och sessionsinformation – för att skilja legitima transaktioner från bedrägligt kundbeteende. På så sätt kan du optimera:

1. Tid till insikt för att proaktivt upptäcka och förhindra bedrägerier
   
2. Reaktionstid för att utveckla regler för förebyggande och identifiering
   
3. Kostnad för bedrägeri, vilket inkluderar återbetalningar, avgifter för bestridande, kundbortfall och nekade betalningar från utfärdare
   

I vår rapport Läget för onlinebedrägerier framhålls driftskostnaderna för manuella granskningsprocesser och att ”ju större [företagen] är, desto mindre andel transaktioner granskas”. Genom att automatisera dessa processer kan du frigöra mer tid för dina bedrägerianalytiker att identifiera nya attackvektorer och utveckla regler för förebyggande och detektering. Det innebär att du kan hitta en bättre balans mellan att blockera bedräglig trafik och minska friktionen för legitima kunder (kundbortfall).

En grundläggande process för att behandla bedrägerier

Låt oss anta att du har en grundläggande process för att hantera bedrägerier som rör transaktioner: Identifiering, utredning, bekräftelse och förfining och minskning som sker inom ett större riskramverk.

• Identifiering, även känt som identifiering, förutsägelse eller incidenthantering, är upptäckten av en datapunkt som kräver ytterligare undersökning. Identifieringen kan vara manuell (t.ex. under en incident), halvautomatisk (via identifieringsregler eller övervakning mot din baslinje), automatiserad (via maskininlärning eller avvikelseidentifiering) eller externt utlöst (t.ex. feedback från kunder eller tvister). När det gäller identifiering kan Radars maskininlärning automatiskt hitta vanliga bedrägerimönster, medan Stripe Sigma kan hjälpa dig att hitta mönster som är specifika för din verksamhet.
  
• Utredning, eller utforskande analys, är utvärdering av misstänkta betalningar eller misstänkt beteende för att bättre förstå företagets inverkan. Detta innebär ofta verifiering mot bredare data för att eliminera brus. Vanligtvis använder bedrägerianalytiker Radars granskningskö eller Stripes Payments Dashboard för att undersöka.
  
• Bekräftelse, även kallat modellering eller backtestning, är generaliseringen av den verifierade attackvektorn för bedrägeri i dimensioner och modellkandidater. Detta omfattar också validering och konsekvensbedömning med hjälp av tidigare data och mot andra regler. Radars funktionalitet för backtestning och simulering kan hjälpa bedrägerianalytiker att göra detta, men datatekniker kan använda Stripe Sigma för ett bredare spektrum av scenarier.
  
• Förfining och lindring, som ibland kallas åtgärd eller begränsning, är implementeringen av modellen – kartläggning av dimensioner och viktiga funktioner på Radars regelpredikat för att förhindra, övervaka eller omdirigera bedrägerier. Traditionellt sett skulle detta ha varit statiska förebyggande regler, men nu när maskininlärning är ett viktigt samarbetsverktyg för människor och målet är att öka precisionen är förfining den lämpligare termen. Den består vanligtvis av blockeringsregler eller blockeringslistor i Radar.
  

Det kan handla om iterativa cykler som dagliga kontroller, sprintar eller lanseringar av regelbaserade system för identifiering av bedrägerier. Eftersom cykeltiderna kan variera och feedbackslingor kan förekomma samtidigt föredrar vi dock att behandla detta kontinuerligt.

Därefter kommer vi att titta på var och en av dessa fyra pelare i detalj i samband med ett hypotetiskt scenario och visa dig hur Radar for Fraud Teams och Stripe Sigma eller Data Pipeline kan hjälpa till.

Vårt scenario

I vårt hypotetiska scenario analyserar vi beteenden som inträffar under en viss tidsperiod, i stället för en plötslig ökning.

Låt oss säga att ditt företag är verksamt inom e-handel. Du har konfigurerat övervakning av webhooks i din observerbarhetssvit som visar olika diagram för betalningstrender i realtid. Du har märkt en stadig ökning av antalet nekade betalningar från ett kortmärke som kallas "Mallory" under de senaste dagarna – för en produkt som vanligtvis inte säljs i regionen där detta kortmärke vanligtvis används. (Obs! Mallory är ett fiktivt kort märke som vi använder för att levandegöra detta scenario, till exempel kan detta vara ett märke som inte finns med i Enhanced Issuer Network.) Det finns inga försäljningskampanjer eller andra incidenter som kan förklara denna förändring, så ditt team måste undersöka vad som händer och bestämma nästa åtgärd.

Identifiering

Stripes standardregler använder maskininlärning för att förutsäga, identifiera och blockera ett stort antal bedrägliga betalningar. Radars Dashboard för analys ger dig en snabb översikt över trenderna för bedrägerier. Och för företag som behöver mer kontroll över vilka betalningar som ska granskas, tillåtas eller blockeras är regler ett kraftfullt verktyg för att anpassa ditt skydd mot bedrägerier.

Innan du kan börja upptäcka nya bedrägerimönster måste du först ha en baslinje med prediktiva signaler, till exempel resultatet av dina befintliga regler. Med andra ord måste du veta vad som ser ”normalt” ut för ditt företag eller hur en ”bra” transaktion ser ut. Det är där dina bedrägerianalytiker och datatekniker arbetar tillsammans (de kan också arbeta med DevOps-team och deras observerbarhetssvit). I vårt hypotetiska scenario upptäcks en ökning av nekade transaktioner från Mallory-korttyper genom kontinuerlig övervakning.

Stripe Sigma-tabeller med relevanta uppgifter om bedrägerier

För att upptäcka nya mönster måste du först fastställa basresultat med funktioner som nekad/auktoriserad utfärdare och Radar-blockeringsfrekvens. Därefter måste du ställa frågor om bedrägeritvister , tidiga bedrägerivarningar (utfärdarens bedrägeriregister) och betalningstransaktioner med hög frekvens, höga avvisningsfrekvenser hos utfärdare eller höga Radar-riskpoäng. Helst ska du schemalägga den här frågan så att den körs dagligen baserat på tillgängliga data och alla dashboards visas med tidigare data, inklusive veckovisa och månatliga nedskärningar, utan att ens behöva ställa frågor manuellt till Stripe Sigma eller ditt datalager. På så sätt kan du snabbare hantera incidenter.

Här är de mest relevanta tabellerna:

Dina bedrägeri- eller företagsanalytiker bör ha en uppfattning om vilka ytterligare uppdelningsdimensioner som kan vara viktiga att utvärdera baserat på din företagsdomän. Tabellen Radars regelattribut i Radar for Fraud Teams innehåller detaljerad information om befintliga transaktioner som utvärderats av Radar, men den går inte tillbaka i historiken före april 2023 och innehåller inte metadata och slutresultat. Tidigare skulle du fråga följande fält:

Den nya tabellen över Radars regelattribut innehåller samma och många fler dimensioner för varje transaktion som utvärderas av Radar med det exakta namnet på Radars attribut. Du kan till exempel spåra hastighetstrender som name_count_for_card_weekly.

Det finns olika sätt att visualisera trender, men ett enkelt pivoterat linjediagram per uppdelning är ett bra sätt att enkelt jämföra med andra faktorer. När du fördjupar dig i utredningsfasen kanske du vill kombinera olika uppdelningar. Här är en exempeltabell som visar uppdelningar av produktsegment för ökningen av avvisade transaktioner från Mallory-korttyper:

Och du kan visualisera det så här i ditt kalkylbladsverktyg:

Låt oss ta en närmare titt på exemplet med en Stripe Sigma eller Data Pipeline-fråga för att returnera basdata. I frågan nedan ser du dagliga bestridanden, nekade betalningar, blockeringsfrekvenser med mera som separata kolumner. Under identifiering och utredning är breda och glesa data i separata kolumner ofta lättare att visualisera. Det gör det också lättare att mappa kolumner till Radar-predikat senare. Men dina dataforskare kanske föredrar ett högt och tätt format för utforskande analys under utredning, eller maskininlärning i bekräftelse- och finjusteringsfaserna och begränsningsfaserna.

I det här exemplet inkluderar vi metadata om betalningen för att visa en uppdelning efter produktsegment. I ett brett perspektiv skulle vi behöva liknande frågor för kortens varumärke (”Mallory”) och finansieringstyp, enligt vårt scenario. Vi gör här en deduplicering för att fokusera på faktiska avsikter och få en bättre känsla av omfattningen. Vi valde att göra en deduplicering för betalningar – djupare integrationer kan skicka ett fält (t.ex. ett beställnings-id, i metadata) för att säkerställa deduplicering över hela användarens resa. Det här exemplet visar hur du kan öka precisionen i dina åtgärder för att bekämpa bedrägerier genom att lägga till ytterligare en faktor. I vårt scenario skulle detta vara produktsegmentet ”presentkort”. Vi återkommer till sätt att öka precisionen senare i avsnittet Förfining och begränsning.

Den här frågan inkluderar inte den faktiska tidpunkten för bestridande, vilket är en eftersläpande indikator, men vi har inkluderat några exempelindikatorer, till exempel nya försök som en indikator på carding. Med den här frågan får vi några dagliga mätvärden på ett enkelt sätt:

• Volymen debiteringar, både deduplicerade och obearbetade: Till exempel 1 150 debiteringar om dagen, varav 100 nekas och 50 blockeras av Radar, fördelade på 1 000 betalning.
  
• Auktorisering: I det här exemplet 90 % för debiteringar, eftersom blockerade betalningar inte går till utfärdaren, och 100 % för betalningsförsök, eftersom de alla så småningom försökte igen.
  
• Den höga risken och blockeringsfrekvensen: I det här fallet skulle båda vara 1,6 % (alla 50 höga risker blockerades också).
  
• Den bakåtblickande bestridandegraden för betalningar från samma period: Till exempel har 5 av 1 000 debiteringar bestridits. Antalet per betalning kommer att öka när fler tvister kommer in. Därför inkluderar vi körningstiden för fråga för att spåra ändringen.
  

Vi har förenklat de här frågorna för att göra dem mer läsbara. I verkligheten skulle den här frågan ha ännu fler dimensioner, till exempel trender, avvikelser eller förlustskillnader.

Vi har också tagit med ett exempel på ett rullande genomsnitt på 30 dagar med hjälp av en fönsterfunktion. Mer komplexa metoder, som att titta på percentiler istället för genomsnitt för att identifiera long tail-attacker, är möjliga, men behövs sällan för att identifiera bedrägerier, eftersom trendlinjer är viktigare än helt exakta siffror.

När du förstår baslinjen kan du börja spåra avvikelser och trender för att till exempel undersöka en ökning av bedrägerier eller blockeringsfrekvensen från ett visst land eller en viss betalningsmetod (i vårt hypotetiska scenario skulle detta vara kortets varumärke "Mallory"). Avvikelser undersöks vanligtvis med hjälp av rapporter eller manuella analyser i Dashboard eller ad hoc-frågor i Stripe Sigma.

Utredning

När dina analytiker har hittat en avvikelse att undersöka är nästa steg att fråga i Stripe Sigma (eller ditt datalager via Data Pipeline) för att utforska data och bygga en hypotes. Du vill inkludera några uppdelningsdimensioner baserade på dina hypoteser, till exempel betalningsmetoder (kortanvändning), kanal eller yta (metadata), kund (rykte) eller produkter (riskkategori) som har en tendens till bedrägeri. Senare i bekräftelsefasen kan du kalla dessa dimensioner för ”funktioner”. Dessa mappas till Radar-predikat.

Låt oss återgå till vår hypotes att en stor mängd transaktioner på förbetalda kort från ”Mallory” har högre bedrägerigrad, vilket du kan representera som en gruppdimension att vända dig till med hjälp av ditt analysverktyg. Vanligtvis itereras och justeras frågan i det här skedet, så det är en bra idé att inkludera olika predikatkandidater som reducerade eller utökade versioner av hypoteserna och ta bort mindre funktioner för att mäta deras inverkan. Till exempel:

Det här tillvägagångssättet skulle ge dig en uppfattning om omfattningen för att prioritera effekt. Tabellen visar med rimlig säkerhet att regelkandidat 3 verkar fånga upp överskottet av skadliga transaktioner. En mer sofistikerad utvärdering skulle vara baserad på noggrannhet, precision eller återkallelse. Du kan skapa ett resultat som detta med frågan nedan.

I den här frågan tog vi bort dedupliceringen för att göra den läsbar, men inkluderade andelen bestridda och tidiga bedrägerivarningar, vilket är viktigt för övervakningsprogram för kortmärken. Det här är dock indikatorer som släpar efter, och i den här förenklade frågan spårar vi dem bara bakåt. Vi inkluderade också godtyckliga betalningar för dubbelkontroll och djupare undersökning av de mönster som hittades i frågan – vi tar upp det här mer senare.

Du kanske vill dela upp ytterligare mätvärden i ett histogram för att identifiera kluster, vilket kan vara användbart för att definiera hastighetsregler som du kan använda för frekvensbegränsning (t.ex. total_charges_per customer_hourly).

Att identifiera trender via histogramanalys är ett utmärkt sätt att förstå kundernas beteende under hela livscykeln och konverteringstratten. Det skulle vara för komplicerat att lägga till det i frågan ovan, men här är ett enkelt exempel på hur du kan dela upp detta utan komplicerad logik för löpande fönster, förutsatt att du har en kundtyp i metadata (t.ex. gästanvändare):

I vårt scenario kanske du inte vill blockera alla förbetalda kort från "Mallory", men ändå vill kunna identifiera andra korrelerade riskfaktorer. Den här hastighetsfrågan kan förbättra förtroendet för att till exempel undvika att blockera gästkunder med låg frekvens.

Ett enkelt sätt att undersöka detta är att titta på exempel direkt i Dashboard via vyn Relaterade betalningar för att få en förståelse för beteendet – det vill säga attackvektorn eller det bedrägliga mönstret – och tillhörande Radar-riskinsikter. Det är därför vi inkluderade godtyckliga betalningar i frågan ovan. På så sätt kan du också hitta nyare betalningar som ännu inte är tillgängliga i Stripe Sigma. Ett mer defensivt sätt vore att modellera din hypotes som en granskningsregel som fortfarande tillåter betalningar, men dirigerar dem till dina analytiker för manuell granskning. Vissa kunder gör det för att överväga att återbetala betalningar under den bestridda avgiften samtidigt som de blockeras över den.

Bekräftelse

Låt oss anta att mönstret du har identifierat i framtiden inte är enkelt, inte kan minskas genom att återbetala och blockera den bedrägliga kunden och inte bara hamnar på en standardblockeringslista.

När du har identifierat och prioriterat ett nytt mönster att ta itu med måste du analysera dess potentiella inverkan på dina legitima intäkter. Detta är inte ett trivialt optimeringsproblem, eftersom den optimala mängden bedrägerier inte är noll. Av alla de olika modellkandidaterna ska du välja den modell som ger bäst avvägning för din riskbenägenhet, antingen genom enkel omfattning eller precision och återkallelse. Ibland kallas det backtestning, särskilt när regler skrivs först och sedan valideras mot dina data. (Du kan också vända på detta – det vill säga upptäcka mönster först och sedan skriva regler.) Istället för att skriva en regel per land kan du till exempel skriva en regel som denna som gör det enklare att bekräfta:

Blockera om :card_funding: = 'prepaid och :card_country: i @preaid_card_countries_to_block

Frågan som delas ovan i avsnittet Utredning kan också användas som modell, med undantag för andra värden som skulle betonas – vi kommer att prata mer om detta senare när vi kommer till förfinings- och begränsningstekniker.

Stripe Sigma-schema till Radar-regelmappning

Det är dags att översätta dina sonderingsfrågor från Stripe Sigma eller Data Pipeline för att hjälpa dig att mappa Radars regler till Stripe Sigma för backtestning. Här är några vanliga mappningar, förutsatt att du skickar rätt signaler till Radar:

De två sista punkterna, risk_level och risk_score, är inte som de andra, eftersom själva maskininlärningsmodellen härrör från de andra faktorerna. Istället för att skriva alltför komplexa regler rekommenderar vi att du förlitar dig på Radars maskininlärning – vi kommer att prata mer om detta i avsnittet Förfining med maskininlärning.

Den nya tabellen över Radars regelattribut spårar samma och många fler dimensioner för varje transaktion som faktiskt utvärderats av Radar med det exakta namnet på Radar-attributen.

Tabellen ovan visar Standarden för attribut och utelämnar avsiktligt signaler som du skulle anpassa för din kunds resa, till exempel Radar Sessions eller metadata.

Baserat på undersökningen ovan kan vi anta att du kommer fram till en regel som ser ut så här:

Blockera om :card_funding: = 'prepaid' och :card_funding: = 'mallory' och :amount_in_usd: > 20 och ::CustomerType:: = 'guest' och :total_charges_per_customer_hourly: > 2

Nästa steg är att bekräfta hur den här regeln påverkar dina faktiska betalningstransaktioner. Vanligtvis gör du det med blockeringsregler. Läs vår guide Radar for Fraud Teams: Rules 101 för vägledning om hur du skriver rätt regelsyntax. Ett enkelt sätt att testa en blockeringsregel är att skapa den i testläge och skapa manuella testbetalningar för att validera att den fungerar som avsett.

Både blockeringsregler och granskningsregler kan backtestas i Radar med hjälp av Radar for Fraud Teams simuleringsfunktion.

En fördel med att använda Radar for Fraud Teams-simuleringar är att den tar hänsyn till effekten av andra befintliga regler. Underhåll av regler är inte fokus för den här guiden, men att ta bort och uppdatera regler bör också vara en del av din kontinuerligt förbättrade process. Generellt sett bör antalet regler du har vara tillräckligt litet för att varje regel ska vara atomär och kunna övervakas med hjälp av de basfrågor som utvecklats i identifierings- och utredningsfaserna, och backtestas tydligt, utan risk för biverkningar (regel 2 fungerar endast på grund av att regel 1 filtrerar bort något annat).

Du kan också göra detta genom att använda granskningsregler istället för blockeringsregler, som vi tar upp i nästa avsnitt.

Förfining och begränsning

Slutligen, efter att ha testat dina blockeringsregler, tillämpar du modellen för att förhindra, övervaka eller omdirigera bedrägerier. Vi kallar detta för finjustering eftersom det handlar om att öka precisionen i dina övergripande åtgärder mot bedrägerier, särskilt i samråd med maskininlärning. För att öka precisionen kan du implementera en mängd olika tekniker. Ibland utförs det här steget, som även kan kallas begränsning eller lindring, samtidigt som bekräftelse, där du istället för att använda granskningsregler, A/B-tester (metadata) eller simuleringar för att utvärdera din modell, omedelbart blockerar misstänkta debiteringar för att minska den omedelbara risken.

Även om du redan har vidtagit åtgärder finns det några tekniker som du kan använda för att förfina modellen du utvecklade i steg 1–3 för att förbättra resultaten över tid:

Förfining med granskningsregler

Om du inte vill riskera en högre frekvens av falska positiva transaktioner, vilket kan påverka dina intäkter, kan du välja att implementera granskningsregler. Även om det här är en mer manuell behandling och kan skapa friktion i kundupplevelsen kan granskningsregler göra det möjligt för fler legitima transaktioner att fortlöpa. (Du kan också lägga till strypning, i form av hastighetsregler, i befintliga blockeringsregler för långsammare transaktioner.) Ett mer avancerat alternativ för att använda granskningsregler är A/B-testning, som är särskilt användbart för att hantera det totala antalet ärenden i granskningskön. Du kan utnyttja metadata från dina betalningar för att börja tillåta en liten mängd trafik medan du A/B-testar, till exempel från kända kunder eller helt enkelt använda ett slumpmässigt nummer. Vi rekommenderar att du lägger till detta i blockeringsregler istället för att skapa tillåtelseregler, eftersom tillåtelseregler åsidosätter blockeringar och därför gör det svårare att spåra blockeringsregelns prestanda över tid.

Optimera regler genom att övervaka deras resultat

Du kan kontrollera resultatet av debiteringen i Payment Intents API, särskilt regelobjektet, för att kontrollera hur väl regeln fungerar. På samma sätt kan du i Stripe Sigma använda fälten charges.outcome_rule_id, charges.outcome_type och payment_intents.review_id för analys. Här är ett exempel på hur du spårar en regels resultat i Stripe Sigma med hjälp av den särskilda tabellen över Radars regelbeslut:

Förfining med hjälp av maskininlärning

Nästa steg efter att ha blockerat en omedelbar attack är ofta att iterativt förfina regeln tillsammans med maskininlärning för att minska antalet falska positiva resultat, vilket gör att mer legitim trafik, och därmed intäkter, kan komma igenom.

Ta till exempel blockering av BIN eller IIN (utfärdarens identifieringsnummer). Under en carding-attack kan du tillfälligt ha lagt till ett BIN i en blockeringslista, vilket ger utfärdaren tid att åtgärda sina brister. Blockering av en utfärdare direkt kan dock minska dina intäkter. Ett mer förfinat tillvägagångssätt är att tillämpa mer granskning över tid och förfina modellen. Det här är ett bra tillfälle att se över hur man skriver effektiva regler och hur man utvärderar risk, särskilt Radars riskbedömning. Vi rekommenderar i allmänhet att du kombinerar Radars maskininlärning med din intuition. Istället för att bara ha en regel för att blockera alla högrisktransaktioner, kombinerar du poängen med manuella regler som representerar en riskmodell eller ett scenario som ofta skapar en bättre balans mellan att blockera skadlig trafik och tillåta intäkter. Till exempel:

Blockera om :card_funding: = 'prepaid' och :card_funding: = 'mallory' och :card_country: i @high_risk_card_countries_to_block och :risk_score: > 65 och :amount_in_usd: > 10

Förfining med hjälp av 3DS

Som tidigare nämnts omfattar den här guiden inte bredden av 3D Secure-autentisering, men du bör överväga det som en del av din riskreduceringsstrategi. Även om ansvarsförskjutning till exempel kan sänka avgifterna för bedrägliga transaktioner som du bestrider, räknas dessa transaktioner fortfarande in i kortövervakningsprogram – och därmed din användarupplevelse. Istället för ett fast belopp kan du förfina den här regeln från att blockera alla relevanta debiteringar till att begära 3DS:

Begär 3DS om :card_country: i @high_risk_card_countries_to_block eller :ip_country: i @high_risk_card_countries_to_block eller :is_anonymous_ip: = ‘true’ eller :is_disposable_email: = ‘true’

Och använd sedan en regel för att spärra kort som inte autentiserades korrekt eller av andra skäl inte ger ansvarsförskjutning:

Blockera om (:card_country: i @high_risk_card_countries_to_block eller :ip_country: i @high_risk_card_countries_to_block eller :is_anonymous_ip: = ‘true’ eller :is_disposable_email: = ‘true’) och :risk_score: > 65 och :has_liability_shift: != ‘true’

Förfining med hjälp av listor

Att använda standardlistorna eller underhålla anpassade listor kan vara ett mycket effektivt sätt att blockera en attack under en incident utan risk för att ändra regler, till exempel genom att blockera en bedräglig kund, e-postdomän eller kortland. En del av förfiningen är att bestämma vilka mönster som ska vara en regel, vilket bör ändra ett predikat för en regel och vilka som helt enkelt kan tillföra värde till en befintlig lista. Breakglass-regler är ett bra exempel på en tillfällig lösning under en incident som efteråt kan förfinas till antingen en lista eller en ändring av en befintlig regel.

Process för feedback

Förfining innebär också att du återgår till steg 1 – dvs. att övervaka regelresultat och bedrägerimönster. God övervakning bygger på fastställda utgångsvärden och enskilda atomära ändringar för optimal spårbarhet, precision och återkallelse av backtestning. Därför rekommenderar vi att du endast ändrar regler och predikat i tydliga, distinkta distributioner och i övrigt förlitar dig på listor, granskningar och proaktiv blockering och återbetalning.

Så kan Stripe hjälpa till

Radar för plattformar

Använder du plattformen Stripe Connect? Om så är fallet gäller alla regler du skapar endast betalningar som skapas på plattformens konto (i Connect är dessa destinationsbetalningar eller betalningar för
annans räkning). Betalningar som skapas direkt på det anslutna kontot omfattas av det kontots regler.

Radar för Terminal

Stripe Terminals avgifter granskas inte av Radar. Det innebär att om du använder Terminal kan du skriva regler baserade på IP-frekvens utan att behöva oroa dig för att blockera betalningar i fysisk miljö.

Stripes professionella tjänster

Stripes team för professionella tjänster kan hjälpa dig att kontinuerligt förbättra hanteringen av bedrägerier. Våra experter ger vägledning som hjälper dig att bygga vidare på din befintliga Stripe-lösning, från att stärka din nuvarande integration till att lansera nya affärsmodeller.

Slutsats

I den här guiden har vi sett hur Stripe Sigma eller Data Pipeline kan användas för att bygga både en basmodell och olika bedrägerimodeller som representerar angreppsscenarier och mönster som bara du och ditt företag kan bedöma. Vi har också visat hur du kan utöka och finjustera Radar för att reagera på ett bredare utbud av bedrägliga transaktioner baserade på dina anpassade regler.

Eftersom betalningsbedrägerier utvecklas kontinuerligt måste även denna process utvecklas kontinuerligt för att hålla jämna steg – som vi har beskrivit i vår modell för identifiering, utredning, bekräftelse samt förfining och begränsning. Genom att regelbundet köra dessa cykler med en snabb återkopplingsslinga kan du lägga mindre tid på att reagera på incidenter och mer tid på att utveckla en proaktiv strategi för bedrägerier.

Du kan läsa mer om Radar for Fraud Teams här. Om du redan är Radar for Fraud Teams-användare kan du gå till kassan på sidan Regler i Dashboard för att börja skriva regler.

Du kan läsa mer om Stripe Sigma här och om Stripe Data Pipeline här.