Het beoordelen van frauderisico is een doorlopend proces waarbij aanvalsvectoren, patronen en scenario's in kaart worden gebracht en tot een minimum worden beperkt. Ons professionele dienstverleningsteam heeft nauw samengewerkt met gebruikers en heeft gezien dat de bedrijven die dit het effectiefst doen vaak fraudeanalisten en data-analisten laten samenwerken. Daarbij gebruiken ze een combinatie van Stripe Radar for Fraud Teams en Stripe Data-producten zoals Stripe Sigma of Stripe Data Pipeline om zowel veelvoorkomende fraudepatronen te herkennen als patronen die specifiek voor hun bedrijf gelden.

Radar for Fraud Teams helpt fraude detecteren en voorkomen en geeft je de mogelijkheid om een fraudepreventiesysteem op te zetten dat uniek is voor jouw bedrijf, met regels, rapportage en handmatige controles op maat. Sigma is een rapportageoplossing die al je transactie-, conversie- en klantgegevens toegankelijk maakt met een interactieve omgeving in het Stripe-dashboard. Data Pipeline biedt dezelfde gegevens, maar stuurt deze automatisch naar je Snowflake- of Redshift-datawarehouse, zodat je ze samen met alle andere gegevens van je bedrijf kunt inzien.

Deze tools werken naadloos samen om de vier pilaren van een effectief fraudebeheerproces te verzorgen: detectie, onderzoek, bevestiging en verfijning en risicobeperking. We zullen hier later dieper op ingaan.

De waarde van het gebruik van Radar for Fraud Teams in combinatie met Sigma of Data Pipeline

Het hoofddoel van het gebruik van Radar for Fraud Teams met Sigma of Data Pipeline is om de gegevens vanuit Radar, zoals metadata, te analyseren naast je eigen gegevens, inclusief pre-autorisatie, gebruikerstraject, conversie en sessie-informatie, om legitieme transacties van frauduleus klantgedrag te onderscheiden. Zo kun je de volgende zaken optimaliseren:

1. __ De tijd tot het inzicht__ om fraude proactief te detecteren en te voorkomen
   
2. De reactietijd tot het ontwikkelen van preventieve en detecterende regels
   
3. Kosten van fraude, zoals terugbetalingen, chargebackkosten, klantverloop en geweigerde betalingen door de issuer
   

Ons rapport over de stand van zaken van online fraude beschrijft de bedrijfskosten die gepaard gaan met handmatige controleprocessen en dat 'hoe groter [bedrijven] zijn, hoe kleiner het aantal transacties dat ze controleren'. Door deze processen te automatiseren, kunnen je fraudeanalisten meer tijd besteden aan het identificeren van nieuwe aanvalsvectoren en het ontwikkelen van preventieve en detecterende regels. Dit betekent dat je een betere balans kunt vinden tussen het blokkeren van frauduleus verkeer en het verlagen van het verloop van legitieme klanten.

Een standaardproces voor transactiefraudebeheer

Laten we zeggen dat je een standaardproces voor transactiefraudebeheer hebt, met detectie, onderzoek, bevestiging en verfijning en risicobeperking, dat plaatsvindt binnen een groter risicokader.

• Detectie, ook wel identificatie, voorspelling of incidentrespons genoemd, is de ontdekking van een datapunt dat verder onderzoek vereist. Detectie kan handmatig zijn (bijv. tijdens een incident), semi-geautomatiseerd (via detecterende regels of bewaking van je nullijn), geautomatiseerd (via machine-learning of het detecteren van afwijkingen) of extern geactiveerd (bijv. feedback van een klant of chargebacks). Als het aankomt op detectie, kan de machine-learning van Radar automatisch veelvoorkomende fraudepatronen vinden, terwijl Sigma je kan helpen om patronen te vinden die specifiek zijn voor jouw bedrijf.
  
• Onderzoek of exploratieve analyse is het beoordelen van verdachte betalingen of gedrag om beter de impact op het bedrijf te begrijpen. Hierbij wordt vaak verificatie uitgevoerd aan de hand van meer gegevens om meer duidelijkheid te scheppen. Doorgaans gebruiken fraudeanalisten de Radar-controlewachtrij of het Payments-dashboard van Stripe om onderzoek te doen.
  
• Bevestiging, ook wel modeling of backtesting genoemd, is het generaliseren van een geverifieerde aanvalsvector om mogelijke fraudepogingen te kunnen identificeren. Hiertoe behoort ook de validatie en impactanalyse aan de hand van historische gegevens en andere regels. De backtesting- en simulatiefunctionaliteit van Radar kan fraudeanalisten helpen dit te doen, maar gegevenstechnici kunnen Sigma gebruiken voor een groter aantal scenario's.
  
• Verfijning en risicobeperking, soms ook wel actie genoemd, is de implementatie van het model, waarbij de afmetingen en belangrijke eigenschappen worden ingevoerd in Radar-regelpredicaten om fraude te voorkomen, te monitoren of door te sturen. Dit zouden normaal gesproken statische preventieve regels zijn, maar nu dat machine-learning een belangrijke tegenhanger is voor mensen en het doel is om precisie te vergroten, is verfijning een betere term. Dit zou normaal gesproken bestaan uit blokkeerregels of -lijsten in Radar.
  

Een standaard implementatie van dit proces kan bestaan uit iteratieve cycli, zoals dagelijkse controles, sprints, of releases van een op regels gebaseerd fraudedetectiesysteem. Gezien het feit dat doorlooptijden kunnen verschillen en feedbackloops tegelijkertijd kunnen plaatsvinden, zien we dit als een doorlopend proces.

Vervolgens kijken we in detail naar elk van deze vier pilaren in een hypothetisch scenario en laten we je zien hoe Radar for Fraud Teams en Sigma of Data Pipeline kan helpen.

Ons scenario

In ons hypothetisch scenario analyseren we gedrag dat gedurende een langere periode plaatsvindt, in plaats van een plotse piek.

Laten we zeggen dat je een e-commercebedrijf hebt. Je hebt webhookmonitoring ingesteld in je zichtbaarheidssuite, die verschillende grafieken voor betalingstrends maakt in real time. Je hebt de afgelopen dagen steeds meer geweigerde betalingen opgemerkt bij een kaartmerk genaamd 'Mallory', voor een product dat normaal gesproken niet wordt verkocht in de regio waar dit kaartmerk wordt gebruikt. (Opmerking: Mallory is een fictief kaartmerk dat we gebruiken om dit scenario realistisch te laten lijken. Dit kan bijvoorbeeld een merk zijn dat niet op het Verbeterd uitgevernetwerk staat.) Er zijn geen verkooppromoties of andere incidenten die deze verschuiving kunnen verklaren, dus moet je team onderzoeken wat er aan de hand is en hoe er moet worden gereageerd.

Detectie

De standaardregels van Stripe gebruiken machine-learning om een aanzienlijk aantal frauduleuze betalingen te voorspellen, te detecteren en te blokkeren. Het Radar-analysedashboard kan je een snel overzicht geven van fraudetrends. En voor bedrijven die meer controle nodig hebben over welke betalingen moeten worden gecontroleerd, toegestaan of geblokkeerd, vormen regels een krachtige tool om je fraudebescherming op maat te maken.

Voordat je kunt beginnen nieuwe fraudepatronen te detecteren, moet je eerst een nullijn hebben voor voorspellende signalen, zoals de prestaties van je bestaande regels. Met andere woorden: je moet weten hoe het er 'normaal' uitziet voor jouw bedrijf, of hoe een 'goede' transactie eruitziet. Dit is waar je fraudeanalisten en data engineers kunnen samenwerken. Ze kunnen ook samenwerken met DevOps-teams en hun 'observability suite' (een tool om overzicht te kunnen houden over een cloud-omgeving). In ons hypothetische scenario wordt een toename aan geweigerde transacties met Mallory-kaarttypen gedetecteerd via doorlopende monitoring.

Sigma-tabellen met relevante fraudegegevens

Om nieuwe patronen te detecteren moet je eerst nullijnprestaties vaststellen met kenmerken zoals het aantal betalingen dat wordt geweigerd door issuers/het autorisatiepercentage en het percentage blokkeringen door Radar. Vervolgens is het goed om een query uit te voeren voor frauduleuze chargebacks, vroegtijdige fraudewaarschuwingen (Frauderecords voor issuers) en betalingstransacties met hoge snelheid, veel issuer-weigeringen of hoge Radar-risicoscores. Idealiter plan je deze query dagelijks in op basis van de beschikbare gegevens en zorg je dat alle dashboards historische gegevens laten zien, inclusief wekelijkse en maandelijkse weergaven, zonder dat je ook maar handmatig een query hoeft in te dienen bij Sigma of je datawarehouse. Dit zal je incidentresponstijd verkorten.

Hier zijn onze meest relevante tabellen:

Jouw fraudeanalisten of zakelijke analisten horen te weten welke extra overzichten belangrijk kunnen zijn om te evalueren op basis van je branche. De tabel voor Radar-regelkenmerken in Radar for Fraud Teams bevat gedetailleerde informatie voor bestaande transacties die door Radar zijn geëvalueerd. Deze gaat alleen niet verder terug dan april 2023 en bevat ook geen metadata of eindresultaten. Eerder zou je vragen stellen over deze gebieden:

De nieuwe tabel voor Radar-regelkenmerken houdt dezelfde en meer elementen bij voor iedere transactie die is geëvalueerd door Radar, inclusief de exacte naam van de Radar-kenmerken. Je kunt nu bijvoorbeeld trends bijhouden als: name_count_for_card_weekly.

Er zijn verschillende manieren om trends te visualiseren, maar een eenvoudig gekanteld lijndiagram per overzicht is een goede manier om te vergelijken met andere factoren. Wanneer je verder graaft tijdens de onderzoeksfase, kan het goed zijn om verschillende overzichten te combineren. Hier volgt een voorbeeldtabel die overzichten per productsegment laat zien voor de toename aan geweigerde betalingen met Mallory-kaarttypen:

En je zou deze als volgt kunnen visualiseren in jouw spreadsheet-tool naar keuze:

Laten we eens goed kijken naar het voorbeeld van een Sigma- of Data Pipeline-query om nullijngegevens te krijgen. In de onderstaande query zie je de dagelijkse percentages chargebacks, geweigerde betalingen, blokkeringen en nog meer, als afzonderlijke kolommen. Tijdens detectie en onderzoek zijn brede en schaarse gegevens in afzonderlijke kolommen vaak makkelijker te visualiseren. Dit maakt het ook makkelijker om later kolommen op Radar-predicaten in te voeren. Je gegevenstechnici geven echter mogelijk de voorkeur aan een hoog en dicht format voor exploratieve analyse tijdens onderzoek, of machine-learning in de bevestigings-, verfijnings- en risicobeperkingsfasen.

In dit voorbeeld voegen we metadata over de betaling toe om een overzicht te laten zien per productsegment. In een brede benadering zouden we vergelijkbare query's nodig hebben voor het kaartmerk ('Mallory') en het financieringstype, volgens ons scenario. We dedupliceren herhaaldelijke pogingen hier om te focussen op eigenlijke bedoelingen en een beter idee te krijgen van de schaal. We kozen ervoor om te dedupliceren op Payment Intents. Diepere integraties kunnen een veld versturen (bijv. een bestellings-ID, in metadata) om voor deduplicatie in het gehele gebruikerstraject te zorgen. Dit voorbeeld laat zien hoe je de precisie van je fraudebestrijdingsmaatregelen kunt vergroten door een extra factor toe te voegen. In ons scenario zou dit het productsegment 'cadeaubonnen' zijn. We komen later terug op manieren om de precisie te vergroten, in het onderdeel Verfijning en risicobeperking.

Deze query omvat niet het daadwerkelijke tijdstip van de chargeback, want dit is een achterlopende indicator, maar we hebben een paar voorbeeldindicatoren toegevoegd, zoals herhaaldelijke betaalpogingen als indicator van het testen van creditcards. In deze query krijgen we een paar dagelijkse meetwaarden op een eenvoudige manier:

• Het volume van betaling, zowel gededupliceerde als ruwe waarde: Bijvoorbeeld: 1150 betalingen per dag, waarvan er 100 worden geweigerd en 50 geblokkeerd door Radar, over 1000 Payment Intents.
  
• Het autorisatiepercentage: In dit voorbeeld: 90% voor betalingen, omdat geblokkeerde betalingen niet naar de issuer gaan, en 100% voor Payment Intents, aangezien deze uiteindelijk allemaal een succesvolle nieuwe poging deden.
  
• Het hoge risico- en blokkeringspercentage: In dit geval zouden beide 1,6% zijn (alle 50 hoge risico's zijn ook geblokkeerd).
  
• Het retrospectieve percentage chargebacks voor betalingen vanuit dezelfde periode: Bijvoorbeeld: 5 op de 1000 betalingen leidde tot een chargeback. Het aantal per betalingsdag zal toenemen wanneer er meer chargebacks binnenkomen. Daarom voegen we de uitvoeringstijd van de query toe om de wijziging bij te houden.
  

Zoals eerder aangegeven, hebben we deze query's vereenvoudigd voor de leesbaarheid. In werkelijkheid zou deze query nog meer dimensies hebben, bijvoorbeeld trends, afwijkingen of verschillen qua verliezen.

We hebben ook een voorbeeld toegevoegd van een voortschrijdend gemiddelde van 30 dagen, met behulp van een vensterfunctionaliteit. Complexere benaderingen, zoals kijken naar percentielen in plaats van naar gemiddelden om long-tail-aanvallen te identificeren, zijn mogelijk maar zeldzaam nodig voor initiële fraudedetectie, aangezien trends belangrijker zijn dan perfect nauwkeurige getallen.

Zodra je de nullijn goed begrijpt, kun je afwijkingen en trends gaan volgen om te onderzoeken. Bijvoorbeeld: een toename aan fraude- of blokkeringspercentages vanuit een bepaald land of met een bepaalde betaalmethode (in ons hypothetisch scenario zou dit het kaartmerk 'Mallory' zijn). Afwijkingen worden doorgaans onderzocht aan de hand van rapporten of handmatige analyses in het dashboard, of ad-hocquery's in Sigma.

Onderzoek

Zodra je analisten een afwijking vinden om te onderzoeken, is de volgende stap om een query in te dienen in Sigma (of je datawarehouse via Data Pipeline), om de gegevens te verkennen en een hypothese op te bouwen. Mogelijk moet je wat uitsplitsingsdimensies toevoegen op basis van je hypotheses. Bijvoorbeeld: betaalmethoden (gebruik van betaalkaart), kanaal of surface (metadata), klant (reputatie) of producten (risicocategorie), die de neiging hebben tot fraude. Later, in het bevestigingsstadium kun je die dimensies 'kenmerken' noemen. Deze worden toegewezen aan Radar-predicaten.

Laten we teruggaan naar onze hypothese dat een groot volume aan transacties met prepaidkaarten van 'Mallory' hogere fraudepercentages heeft, die je kunt laten zien als een groeperingsdimensie om te gebruiken als basis voor je analysetool. Doorgaans wordt de query in dit stadium geïtereerd en getweakt, dus is het een goed idee om verschillende kandidaten voor predicaten toe te voegen als geminimaliseerde of uitgebreide versies van de hypotheses, waarbij je minder belangrijke kenmerken weglaat, om hun impact te meten. Bijvoorbeeld:

deze benadering geeft je een idee van de omvang, zodat je de impact kunt prioriteren. De tabel vertelt je met redelijke zekerheid dat regelkandidaat 3 het leeuwendeel van de kwaadwillende transacties lijkt te omvatten. Een meer verfijnde beoordeling zou gebaseerd worden op nauwkeurigheid, precisie of recall. Je kunt een output zoals deze maken met de onderstaande query.

In deze query hebben we deduplicatie verwijderd voor de leesbaarheid, maar hebben we het percentage chargebacks en vroegtijdige fraudewaarschuwingen toegevoegd, die belangrijk zijn voor monitoringsprogramma's van kaartmerken. Dit zijn echter achterlopende indicatoren en in deze vereenvoudigde query sporen we ze alleen achterwaarts op. We hebben ook arbitraire betalingsvoorbeelden toegevoegd voor cross-checking en een diepgaander onderzoek naar de patronen gevonden in de query. We vertellen hier later meer over.

Mogelijk wil je aanvullende meetwaarden uitsplitsen tot een histogram om clusters te identificeren. Dit kan nuttig zijn om snelheidsregels te bepalen, die je kunt gebruiken om limieten te stellen (bijv. total_charges_per customer_hourly).

Trends identificeren via histogramanalyse is een uitstekende manier om het gewenste klantgedrag te begrijpen, gedurende hun gehele levenscyclus en conversietrechter. Dit aan de bovenstaande query toevoegen zou te complex zijn, maar hier volgt een eenvoudig voorbeeld van hoe je dit kunt uitsplitsen zonder complexe voortschrijdende vensters te gebruiken, ervan uitgaande dat je een klanttype in de metadata hebt (bijv. gastgebruikers):

In ons scenario wil je mogelijk niet alle prepaidkaarten van 'Mallory' blokkeren, maar wil je wel met andere gecorreleerde risicofactoren kunnen identificeren. Deze snelheidsquery kan je meer zekerheid bieden om bijvoorbeeld te voorkomen dat je gastgebruikers met een lage regelmaat blokkeert.

Een eenvoudige manier om dit te onderzoeken is door rechtstreeks naar de voorbeelden te kijken in het dashboard, via de weergave 'Gerelateerde betalingen', om een inzicht te krijgen in het gedrag (d.w.z. de aanvalsvector of het fraudepatroon) en de bijbehorende Radar-inzichten in risico's. Daarom hebben we arbitraire betalingsvoorbeelden toegevoegd aan de bovenstaande query. Zo kun je ook recentere betalingen vinden die nog niet in Sigma beschikbaar zijn. Een voorzichtigere en arbeidsintensievere manier is om je hypothese te modelleren als een controleregel, die betalingen nog steeds toestaat, maar die ze doorstuurt naar je analisten voor handmatige controle. Sommige klanten doen dat om te overwegen om betalingen onder chargebackkosten terug te betalen en die erboven te blokkeren.

Bevestiging

Laten we nu aannemen dat het patroon dat je hebt geïdentificeerd niet eenvoudig is, niet kan worden beheerst door de frauduleuze klant terug te betalen en te blokkeren en niet gewoon valt onder een standaard blokkeerlijst.

Nadat je een nieuw patroon hebt geïdentificeerd en geprioriteerd om aan te pakken, moet je zijn potentiële impact op jouw legitieme inkomsten analyseren. Dit is geen triviaal optimalisatieprobleem, want de optimale hoeveelheid fraude is niet nul. Van alle mogelijke modellen kies je het model dat de beste afweging is van je risicobereidheid, op basis van omvang of van precisie en recall. Dit proces noemen we soms ook wel backtesting, vooral wanneer regels eerst worden geschreven en vervolgens worden gevalideerd aan de hand van jouw gegevens. (Je kunt dit ook omgekeerd doen, d.w.z. eerst patronen ontdekken en vervolgens de regels schrijven.) In plaats van bijvoorbeeld een regel per land te schrijven, kun je een regel zoals deze schrijven die bevestiging gemakkelijker maakt:

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

De hierboven gedeelde query in het onderdeel Onderzoek kan ook als model worden gebruikt, maar dan met uitlichting van andere waarden. We zullen het hier later over hebben als we komen bij de verfijnings- en risicobeperkingstechnieken.

Sigma-schema voor het toewijzen van Radar-regels

Het is tijd om je exploratieve query's vanuit Sigma of Data Pipeline te vertalen om je te helpen Radar-regels toe te wijzen aan Sigma voor backtesting. Hier zijn een paar veelvoorkomende toewijzingen, ervan uitgaande dat je de juiste signalen naar Radar verstuurt:

De laatste twee items, risk_level en risk_score, zijn niet zoals de andere, aangezien het machine-learning-model zelf is afgeleid van de andere factoren. In plaats van te complexe regels schrijven, raden we je aan om gebruik te maken van de machine-learning van Radar. We vertellen hier meer over in het onderdeel verfijning aan de hand van machine-learning.

De nieuwe tabel voor Radar-regelkenmerken houdt dezelfde en meer elementen bij voor iedere transactie die daadwerkelijk is geëvalueerd door Radar, inclusief de exacte naam van de Radar-kenmerken.

Deze tabel hierboven toont de standaard set kenmerken en laat opzettelijk signalen weg die je zou aanpassen voor je klanttraject, zoals Radar-sessies of metadata.

Laten we op basis van het bovenstaande onderzoek ervan uitgaan dat je bij een regel uitkomt die er als volgt uitziet:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

De volgende stap is om de impact van deze regel op je daadwerkelijke betaaltransacties te bevestigen. Je doet dit doorgaans met blokkeerregels. Lees onze gids Radar for Fraud Teams: basisregels voor richtlijnen over hoe je de juiste regelsyntaxis schrijft. Een eenvoudige manier om een blokkeerregel te testen is door deze te maken in de testmodus en handmatige testbetalingen te maken om te bevestigen dat de regel naar behoren werkt.

Zowel blokkeerregels als controleregels kunnen in Radar worden gebacktest aan de hand van de Radar for Fraud Teams-simulatiefunctionaliteit.

Een voordeel van het gebruik van Radar for Fraud Teams-simulaties is dat het de impact van andere bestaande regels meeneemt. Onderhoud van de regels is niet de focus van deze gids, maar het verwijderen en bijwerken van regels moet ook een onderdeel zijn van je doorlopende verbeteringsproces. Doorgaans zou het aantal regels dat je hebt, klein genoeg moeten zijn zodat elke regel onopdeelbaar is en kan worden gemonitord aan de hand van de nullijnquery's die zijn ontwikkeld in de detectie- en onderzoeksfasen en duidelijk kan worden gebacktest zonder het risico op neveneffecten (bijv. regel 2 werkt alleen omdat regel 1 iets anders wegfiltert).

Je kunt dit ook doen door controleregels te gebruiken in plaats van blokkeerregels, wat we zullen behandelen in het volgende onderdeel.

Verfijning en risicobeperking

Uiteindelijk kun je na het testen van je blokkeerregels het model toepassen om fraude te voorkomen, te monitoren of door te sturen. We noemen dit verfijning omdat het gaat om het vergroten van de precisie van je algemene fraudebestrijdende maatregelen, met name in combinatie met machine-learning. Om de precisie te vergroten, kun je allerlei technieken toepassen. Soms wordt deze stap, die ook wel (risico)beperking wordt genoemd, op hetzelfde moment toegepast als Bevestiging, waarbij je in plaats van controleregels, A/B-testen (metadata) of simulaties te gebruiken om je model te evalueren, onmiddellijk de verdachte betalingen blokkeert om het directe risico te beperken.

Zelfs als je al actie hebt ondernomen, zijn er een aantal technieken die je kunt gebruiken om het model te verfijnen dat je hebt ontwikkeld in stappen 1-3 om de resultaten na verloop van tijd te verbeteren:

Verfijning aan de hand van controleregels

Als je niet het risico wilt lopen op een hoger percentage valse positieven, dat impact kan hebben op je omzet, kun je ervoor kiezen om controleregels te implementeren. Hoewel dit een handmatiger proces is en frictie kan toevoegen aan de klantbeleving, kunnen controleregels zorgen dat meer legitieme transacties uiteindelijk kunnen doorgaan. (Je kunt ook vernauwing, in de vorm van snelheidsregels, toevoegen aan bestaande blokkeerregels voor langzamere transacties.) Een meer geavanceerde optie voor het gebruiken van controleregels is A/B-testing, wat met name handig is voor het beheren van het totaalaantal gevallen in de controlewachtrij. Je kunt metadata vanuit je betalingen gebruiken om een kleine hoeveelheid verkeer toe te staan, tijdens A/B-testing, bijvoorbeeld vanuit bekende klanten of gewoon aan de hand van een willekeurig aantal. We raden je aan om dit toe te voegen aan blokkeerregels in plaats van toelatingsregels te maken, aangezien toelatingsregels blokkeerregels vervangen en het daardoor moeilijker maken om de prestaties van de blokkeerregel na verloop van tijd bij te houden.

Regels optimaliseren door hun prestaties te monitoren

Om de prestaties van regels te monitoren, kun je het betaaluitkomst-object in de Payment Intents-API controleren, met name het regel-object. Evenzo kun je in Sigma de velden charges.outcome_rule_id, charges.outcome_type en payment_intents.review_id gebruiken ter analyse. Hier is een voorbeeld van hoe je de prestaties van een regel in Sigma bij kunt houden met behulp van de tabel met Radar-regelbeslissingen:

Verfijning met behulp van machine-learning

Vaak is de volgende stap na het blokkeren van een directe aanval om de regel iteratief te verfijnen, in combinatie met machine-learning om het aantal valse positieven te verkleinen, waardoor meer legitiem verkeer door kan gaan en daarmee meer omzet binnen kan komen.

Neem bijvoorbeeld het blokkeren van het BIN of IIN (issuer-identificatienummer). Tijdens een aanval met het testen van creditcards kun je een BIN mogelijk tijdelijk aan een blokkeerlijst hebben toegevoegd, wat issuers de tijd geeft om hun lekken te dichten. Het direct blokkeren van een issuer kan echter je omzet verkleinen. Een verfijndere benadering is om na verloop van tijd meer onderzoek te doen en het model te verfijnen. Dit is een goed moment om nog eens te kijken hoe je effectieve regels schrijft en hoe je risico's beoordeelt, met name de risicobeoordeling van Radar. We raden in het algemeen aan om de machine-learning van Radar te combineren met je eigen intuïtie. In plaats van slechts één regel hebben om alle transacties met hoog risico te blokkeren, zorgt het combineren van de beoordeling door Radar met handmatige regels die een risicomodel of scenario vertegenwoordigen vaak voor een betere balans tussen het blokkeren van kwaadwillend verkeer en het toestaan van transacties die voor omzet zorgen. Bijvoorbeeld:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

Verfijning met behulp van 3DS

Zoals eerder al werd benoemd, weidt deze gids niet volledig uit over 3D Secure-authenticatie (3DS), maar moet je deze authenticatie wel overwegen als onderdeel van je risicobeperkingsstrategie. Bijvoorbeeld: verschuiving van aansprakelijkheid verlaagt misschien je chargeback-kosten voor frauduleuze transacties, maar deze transacties tellen nog steeds mee voor kaartmonitoringsprogramma's en daarmee voor je gebruikerservaring. In plaats van een vast bedrag te gebruiken kun je deze regel van 'alle relevante betalingen blokkeren' verfijnen tot 'om 3DS vragen':

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = 'true' or :is_disposable_email: = 'true'

Vervolgens gebruik je een regel om betaalkaarten te blokkeren die zich niet succesvol konden authenticeren of die om andere redenen geen verschuiving van aansprakelijkheid bieden:

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = 'true' or :is_disposable_email: = 'true') and :risk_score: > 65 and :has_liability_shift: != 'true'

Verfijning met behulp van lijsten

Het gebruik van standaardlijsten of lijsten op maat kan een zeer effectieve manier zijn om een aanval te blokkeren tijdens een incident, zonder het risico te lopen regels te veranderen, bijvoorbeeld door een frauduleuze klant, e-maildomeinnaam of het land van de betaalkaart te blokkeren. Een onderdeel van verfijning is bepalen welke patronen een regel moeten krijgen, welke een regelpredicaat moeten wijzigen en welke simpelweg waarde kunnen toevoegen aan een bestaande lijst. Breakglass-regels zijn een goed voorbeeld van een lapmiddel tijdens een incident dat naderhand verfijnd kan worden tot een lijst of een wijziging van een bestaande regel.

Feedbackproces

Verfijning betekent ook dat je terugkeert naar stap 1. Dat wil zeggen: je regelprestaties en fraudepatronen monitoren. Goede monitoring is afhankelijk van vooraf bepaalde nullijnen en losstaande, onopdeelbare wijzigingen voor optimale traceerbaarheid, precisie en recall van backtesting. Om deze reden raden we aan om alleen regels en predicaten te wijzigen in duidelijke, traceerbare handelingen en verder te berusten op lijsten, controles en proactieve blokkering en terugbetaling.

Hoe Stripe kan helpen

Radar for platforms

Heb je een platform dat Stripe Connect gebruikt? In dat geval gelden alle regels die je toepast alleen voor betalingen gemaakt in het platformaccount (in Connect-terminologie zijn dit Destination Charges of 'on-behalf-of'-betalingen
). Betalingen die rechtstreeks in het gekoppelde account worden gemaakt, volgen de regels van dat account.

Radar for Terminal

Stripe Terminal-betalingen worden niet gescreend door Radar. Dit betekent dat als je Terminal gebruikt, je regels kunt schrijven op basis van IP-regelmaat, zonder dat je je zorgen hoeft te maken dat je je fysieke betalingen blokkeert.

Professionele dienstverlening van Stripe

Het professionele dienstverleningsteam van Stripe kan je helpen een voortdurend verbeterend fraudebeheerproces te implementeren. Van het verbeteren van je huidige integratie tot het lanceren van nieuwe businessmodellen: onze experts begeleiden je zodat je kunt bouwen op je bestaande Stripe-oplossing.

Conclusie

In deze gids hebben we gezien hoe Sigma of Data Pipeline kan worden gebruikt om zowel een nullijn op te bouwen, als verschillende fraudemodellen die aanvalsscenario's en -patronen vertegenwoordigen die alleen jij en je bedrijf zullen herkennen. We hebben ook laten zien hoe je Radar kunt uitbreiden en verfijnen om op een groter aantal frauduleuze transacties te kunnen reageren, aan de hand van je regels op maat.

Aangezien betalingsfraude zich blijft ontwikkelen, moet dit proces ook voortdurend verder worden ontwikkeld om bij te blijven, zoals we beschreven in ons detectie-, onderzoeks-, bevestigings-, verfijnings- en risicobeperkingsmodel. Als je deze cycli doorlopend blijft uitvoeren met een snelle feedbackloop, hoef je minder tijd te besteden aan reageren op incidenten en heb je meer tijd over voor het ontwikkelen van een proactieve fraudestrategie.

Je kunt hier meer informatie vinden over Radar for Fraud Teams. Als je al een Radar for Fraud Teams-gebruiker bent, bekijk dan de pagina Regels in je dashboard om te beginnen met het schrijven van regels.

Je kunt hier meer informatie over Sigma en hier meer informatie over Stripe Data Pipeline vinden.