Het beoordelen van frauderisico's is een continu proces van het identificeren van aanvalsvectoren, patronen en scenario's en het beperken daarvan. Door nauw samen te werken met gebruikers heeft ons professional services-team gemerkt dat de ondernemingen die dit het meest effectief doen, vaak fraudeanalisten en data-analisten hebben die samenwerken. Ze gebruiken een combinatie van Stripe Radar for Fraud Teams en Stripe Data-producten zoals Stripe Sigma of Stripe Data Pipeline om zowel veelvoorkomende fraudepatronen als patronen die specifiek zijn voor hun onderneming te identificeren.

Radar for Fraud Teams helpt bij het opsporen en voorkomen van fraude en biedt je de mogelijkheid om een op maat gemaakte fraudeconfiguratie te creëren die uniek is voor jouw onderneming, met aangepaste regels, rapportage en handmatige controles. Stripe Sigma is een rapportageoplossing die al je transactie-, conversie- en klantgegevens beschikbaar maakt in 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 je andere ondernemingsgegevens kunt bekijken.

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.

Het nut van Radar voor fraudeteams met Stripe Sigma of Data Pipeline

Het belangrijkste doel van het gebruik van Radar voor fraudeteams met Stripe Sigma of Data Pipeline is om de gegevens van Radar, zoals metadata, samen met je eigen gegevens te analyseren, waaronder pre-autorisatie, gebruikerservaring, conversie en sessie-informatie, om legitieme transacties te onderscheiden van frauduleus klantgedrag. Op deze manier kun je het volgende 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 uitgever
   

Ons rapport Status van online fraude laat zien dat handmatige beoordelingsprocessen veel werk kosten en dat "hoe groter [ondernemingen] zijn, hoe minder transacties ze beoordelen". Door deze processen te automatiseren, kunnen je fraudeanalisten meer tijd besteden aan het vinden van nieuwe aanvalsvectoren en het ontwikkelen van preventieve en detectieve regels. Dit betekent dat je een betere balans kunt vinden tussen het blokkeren van frauduleus verkeer en het verminderen van wrijving voor legitieme klanten (verloop).

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 bekend als identificatie, voorspelling of incidentrespons, is het ontdekken van een gegevenspunt dat nader onderzoek vereist. Detectie kan handmatig zijn (bijvoorbeeld tijdens een incident), semi-automatisch (via detectieregels of monitoring ten opzichte van je baseline), automatisch (via machine learning of anomaliedetectie) of extern geactiveerd (bijvoorbeeld door feedback van klanten of geschillen). Als het gaat om detectie, kan de machine learning van Radar automatisch veelvoorkomende fraudepatronen vinden, terwijl Stripe Sigma je kan helpen bij het vinden van patronen die specifiek zijn voor jouw onderneming.
  
• Onderzoek, of verkennende analyse, is het evalueren van verdachte betalingen of gedrag om de impact op het onderneming beter te begrijpen; dit houdt vaak in dat gegevens worden vergeleken met bredere gegevens om ruis te elimineren. Meestal gebruiken fraudeanalisten de Radar-beoordelingswachtrij of Stripe's betalingsdashboard om onderzoek te doen.
  
• Bevestiging, ook wel modellering of backtesting genoemd, is het omzetten van de geverifieerde fraudevector in dimensies en modelkandidaten. Dit omvat ook de validatie en impactbeoordeling op basis van historische gegevens en in vergelijking met andere regels. De backtesting- en simulatiefuncties van Radar kunnen fraudeanalisten hierbij helpen, maar data-engineers kunnen Stripe Sigma gebruiken voor een breder scala aan scenario's.
  
• Verfijning en mitigatie, ook wel actie of beperking genoemd, is het implementeren van het model: het toewijzen van de dimensies en belangrijke kenmerken aan Radar-regelpredicaten om fraude te voorkomen, te monitoren of om te leiden. Vroeger waren dit statische preventieve regels, maar nu machine learning een belangrijke tegenhanger van mensen is en het doel is om de nauwkeurigheid te verhogen, is verfijning de meer geschikte term. Dit omvat meestal blokkeringsregels 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 gaan we elk van deze vier pijlers in detail bekijken in de context van een hypothetisch scenario en laten we zien hoe Radar for Fraud Teams en Stripe Sigma of Data Pipeline kunnen 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 onderneming, 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.

Stripe Sigma-tabellen met relevante fraudegegevens

Om nieuwe patronen te ontdekken, moet je eerst een basisprestatie vaststellen met functies zoals de weigering-/autorisatiegraad van de uitgever en de Radar-blokkeringsgraad. Vervolgens moet je frauduleuze geschillen, vroege fraudewaarschuwingen (fraudegegevens van uitgevers) en betalingstransacties met een hoge snelheid, veel afwijzingen door uitgevers of hoge Radar-risicoscores opvragen. Idealiter plan je deze query in om dagelijks te worden uitgevoerd op basis van beschikbare gegevens en laat je alle dashboards visualiseren met historische gegevens, inclusief wekelijkse en maandelijkse overzichten, zonder dat je Stripe Sigma of je datawarehouse handmatig hoeft te raadplegen. Dit versnelt je reactietijd op incidenten.

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 Stripe 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-hoc query's in Stripe Sigma.

Onderzoek

Zodra je analisten een afwijking hebben gevonden die ze willen onderzoeken, is de volgende stap om een query uit te voeren in Stripe Sigma (of je datawarehouse via Data Pipeline) om de gegevens te verkennen en een hypothese op te stellen. Je wilt een aantal uitsplitsingsdimensies opnemen op basis van je hypothesen, bijvoorbeeld betaalmethoden (kaartgebruik), kanaal of oppervlak (metadata), klant (reputatie) of producten (risicocategorie) die vatbaar zijn voor fraude. Later, in de bevestigingsfase, 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 makkelijke manier om dit te onderzoeken is door rechtstreeks in het dashboard naar voorbeelden te kijken via de weergave 'Gerelateerde betalingen' om inzicht te krijgen in het gedrag, dat wil zeggen de aanvalsvector of het frauduleuze patroon, en de bijbehorende Radar-risico-inzichten. Daarom hebben we willekeurige betalingsvoorbeelden in de bovenstaande query opgenomen. Op deze manier kun je ook recentere betalingen vinden die nog niet beschikbaar zijn in Stripe Sigma. Een meer defensieve en intensieve manier is om je hypothese te modelleren als een beoordelingsregel die betalingen nog steeds toestaat, maar ze doorstuurt naar je analisten voor handmatige beoordeling. Sommige klanten doen dat om betalingen onder de geschilkosten terug te betalen en betalingen daarboven te blokkeren.

Bevestiging

Laten we ervan uitgaan dat het patroon dat je hebt ontdekt niet simpel is, niet kan worden opgelost door terugbetaling en het blokkeren van de frauduleuze klant, en niet zomaar onder een standaardblokkeerlijst valt.

Nadat je een nieuw patroon hebt gevonden en prioriteit hebt gegeven, moet je kijken wat de mogelijke impact ervan is op je legitieme inkomsten. Dit is geen simpel optimalisatieprobleem, omdat de optimale hoeveelheid fraude niet nul is. Kies uit alle verschillende modelkandidaten het model dat het beste past bij je risicobereidheid, of dat nu op basis van eenvoudige omvang of nauwkeurigheid en annulering is. Dit proces wordt soms backtesting genoemd, vooral wanneer eerst regels worden opgesteld en deze vervolgens worden gevalideerd aan de hand van je gegevens. (Je kan dit ook omgekeerd doen, dat wil zeggen eerst patronen ontdekken en vervolgens regels opstellen.) In plaats van bijvoorbeeld één regel per land op te stellen, kan je een regel zoals deze opstellen, 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.

Stripe Sigma-schema naar Radar-regeltoewijzing

Het is tijd om je verkennende queries van Stripe Sigma of Data Pipeline te vertalen, zodat je Radar-regels kunt toewijzen aan Stripe Sigma voor backtesting. Hier zijn een paar veelvoorkomende toewijzingen, ervan uitgaande dat je de juiste signalen naar Radar stuurt:

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 checken, kun je het betaaluitkomst-object in de Payment Intents-API bekijken, vooral het regelobject. Ook in Stripe Sigma kun je de charges.outcome_rule_id, charges.outcome_type en payment_intents.review_id gebruiken voor analyse. Hier is een voorbeeld van hoe je de prestaties van een regel in Stripe Sigma kunt volgen met behulp van de speciale Radar-regelbeslissingstabel:

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 Stripe Sigma of Data Pipeline gebruikt kan worden om zowel een baseline als verschillende fraudemodellen te bouwen die aanvalscenario's en patronen weergeven die alleen jij en je onderneming kunnen beoordelen. We hebben ook laten zien hoe je Radar kunt uitbreiden en verfijnen om te reageren op een breder scala aan frauduleuze transacties op basis van je eigen regels.

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 info vinden over Radar for Fraud Teams. Als je al Radar for Fraud Teams gebruikt, check dan de Rules-pagina in je Dashboard om te beginnen met het schrijven van regels.

Je kunt hier meer lezen over Stripe Sigma en hier over Stripe Data Pipeline.