De standaardregels van Stripe maken gebruik van machine-learning om een aanzienlijk percentage van de frauduleuze betalingen te detecteren en blokkeren. Voor bedrijven die meer controle willen over betalingen die moeten worden gecontroleerd, toegestaan of geblokkeerd, zijn regels nuttige tools voor fraudepreventie op maat.

In dit whitepaper wordt ingegaan op diverse onderwerpen die verband houden met Radar-regels, waaronder meer dan 100 Radar-regels die je kunt gebruiken en beste werkwijzen op het gebied van backtesting, het schrijven van regels en meer.

Laten we aan de slag gaan.

Het belang van de regelvolgorde en -hiërarchie

De volgorde waarop regels worden weergegeven op je Radar-pagina doet ertoe. Elke betaling wordt geëvalueerd op basis van de regels die je hebt geformuleerd en op onderstaande volgorde:

1. Vereist 3DS: regels die 3D Secure-authenticatie vereisen bij gebruik met de Payment Intents-API of Checkout. Los van het resultaat van de toepassing van deze regel, worden erna nog toelatings-, blokkeer- en controleregels geëvalueerd.
   
2. Toelatingsregels: regels die toestaan dat een betaling wordt verwerkt. Toelatingsregels moeten zorgvuldig worden toegepast, want ze overschrijven alle andere regels, met uitzondering van 3DS-regels, inclusief de machine-learningmodellen van Stripe. Zij moeten daarom voorzichtig worden gebruikt. Alleen handelaren die meer dan $ 100.000 hebben verwerkt, kunnen toelatingsregels schrijven.
   
3. Blokkeerregels: regels die een betaling blokkeren en weigeren. Als een betaling wordt geweigerd, wordt deze niet meer geëvalueerd aan de hand van controleregels.
   
4. Controleregels: betalingen die wel worden verwerkt en waarbij het bedrag dus bij de klant in rekening wordt gebracht, maar die worden gesignaleerd zodat je ze nog eens goed onder de loep kunt nemen.
   

Laten we de volgende regels als voorbeeld nemen om dit in de praktijk toe te passen. Alle betalingen van minder dan $ 10 worden verwerkt. Dit komt doordat de eerste regel de betaling toelaat. Er worden dus verder geen regels meer geëvalueerd. Een betaling van $ 1500 vanuit de VS met een normaal risiconiveau wordt op basis van dezelfde principes ook toegelaten, ondanks de regel dat betalingen boven de $ 1000 geblokkeerd moeten worden. Dit komt door de tweede regel op de lijst, die betalingen vanuit de VS met een normaal risiconiveau toelaat. Zodra een bepaalde regel wordt geactiveerd, worden er geen andere regels meer geëvalueerd.

• Allow payments less than $10

• Allow payments within the US and with a risk level of normal

• Block payments where the risk level is high

• Block payments greater than $1,000

• Review payments with a card issued outside the US

Spiekbriefje regeltaal

Regels zijn vergelijkbaar met SQL en er zijn verschillende operators die je kunt gebruiken afhankelijk van het soort gegevens dat je gebruikt om je regel te maken. Hier heb je een spiekbriefje.

Als je expliciet wilt controleren of een attribuut of metadata-attribuut aanwezig is, gebruik dan niet de operator != maar de functie is_missing . Geef voor deze functie het attribuut of de metadatasleutel op dat/die mogelijk ontbreekt. Zo kun je bijvoorbeeld een regel schrijven die alle betalingen oplevert waarvoor je geen toegang hebt tot het e-mailadres van de klant:

• Review if is_missing(:email_domain:)
  

Of je kunt een regel schrijven die alle betalingen oplevert waarvoor het e-mailadres van de klant NIET ontbreekt:

• Review if !(is_missing(:email_domain:))
  

Veelgebruikte Radar-regels

Dit is een niet-uitputtende lijst van veelgebruikte Radar-regels op basis van verschillende doelen.

Regels ter voorkoming van kaarttesten of kaart-cashing

Regels om fraude met SKU's te voorkomen waarvan bekend is dat ze risicovol zijn

Deze regel vereist metadata of er moet SKU-informatie worden doorgegeven in de beschrijving van de betaling. Deze betalingen worden wel verwerkt en het bedrag wordt in rekening gebracht bij de klant. Maar ze worden gesignaleerd zodat je ze nog eens goed onder de loep kunt nemen.

Regels om misbruik van proefabonnementen met prepaidkaarten te voorkomen

Regels om meerdere chargebacks voor één betaalkaart te voorkomen

Drie soorten attributen om regels te maken

Type 1

post-autorisatie-attributen: Deze kunnen door iedereen worden gebruikt. Wanneer je voor deze attributen kiest, moet je dubbele punten gebruiken voor en na post-autorisatie-attributen. Voorbeeld::cvc_check:.

Dit is een voorbeeld van hoe post-autorisatie-attributen worden gebruikt:

• Block if :address_line1_check: != 'pass' Als deze regel actief is, worden alle betalingen geblokkeerd die niet voldoen aan de eis van de kaartverstrekker dat de eerste regel van het opgegeven factuuradres overeen moet komen met de informatie over de kaarthouder die de verstrekker heeft. Dit betekent dat de betaling wordt geblokkeerd als deze controle niet beschikbaar is (‘unavailable’), als de gegevens niet door de verstrekker zijn gecontroleerd (‘unchecked’) of als de verstrekker de gegevens niet heeft verstrekt (‘not_provided’).
  

Type 2

standaardattributen: deze kunnen door iedereen worden gebruikt. Je moet dubbele punten gebruiken voor en na standaardattributen, bijvoorbeeld: :card_bin: We hebben onze standaardattributen ingedeeld in vier categorieën:

• Attributen op basis van frequentie: nuttig om kaarttesten en kaart-cashing te voorkomen
  
• Attributen op basis van kaartgegevens
  
• Attributen op basis van betaalgegevens
  
• Attributen op basis van klantgegevens
  

Voor sommige attributen moeten de waarden tekenreeksen zijn en voor andere nummers. We geven een voorbeeld van elk attribuut om dit te verduidelijken. Als het attribuut een tekenreeks als :card_bin: vereist, zie je in het voorbeeld dat het nummer tussen ‘ ’ staat. Bijvoorbeeld: :card_bin: = ‘424242’. Als een nummer vereist is, staat het nummer niet tussen ‘ ’, bijvoorbeeld :amount_in_usd: > 250.

Attributen op basis van frequentie

Er zijn vier soorten attributen op basis van frequentie die bijzonder handig zijn om fraude met gestolen betaalkaarten, kaarttesten en kaart-cashing te voorkomen.

1. Autorisatie: gebaseerd op autorisatie door de verstrekker
   
2. Betaling: gebaseerd op betalingen
   
3. Weigering: gebaseerd op weigeringen door de verstrekker
   
4. Blokkering: gebaseerd op blokkeringen door de machine-learning van Radar.
   

Er zijn ook attributen die zijn gebaseerd op de uitkomst van de betaling, inclusief autorisaties (op basis van geslaagde autorisaties door de verstrekker), betalingen (op basis van betaalpogingen), weigeringen (op basis van weigeringen door de verstrekker), chargebacks (eerdere transacties die zijn betwist wegens fraude) en blokkeringen (op basis van blokkeringen door de machine-learning van Radar). Uitkomsten worden gecombineerd met een informatie-element over de klant (e-mail, IP-adres, naam of klant-ID) om een attribuut te vormen.

Daarnaast kun je de frequentie van een informatie-element over de klant (e-mail, naam) combineren met het kaart- of IP-adres van een transactie. In andere woorden kunnen frequentieregels twee vormen aannemen:

1. op basis van de uitkomst van de betaling (bijv. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly) waarbij de uitkomst geslaagde autorisatie, betaalpoging, weigering, chargeback of blokkering is
   
2. op basis van verbanden tussen klantinformatie en een betaalkaart of IP (bijv. name_count_for_card_weekly, email_count_for_ip_hourly)
   

Frequentieregels zijn exclusief de betaling die je op dat moment verwerkt. Zo staat authorized_charges_per_email_hourly bijvoorbeeld voor het aantal eerdere geslaagde betaalpogingen met het e-mailadres in het voorgaande uur. Voor de eerste betaalpoging in een bepaald uur met een e-mailadres heeft authorized_charges_per_email_hourly dus een waarde van 0. Als de eerste poging slaagt, heeft de tweede betaalpoging in datzelfde uur met dat e-mailadres een waarde van 1, enzovoort.

Attributen op basis van kaartgegevens

Attributen op basis van betaalgegevens

Attributen op basis van klantgegevens

Dit is een voorbeeld van hoe standaardkenmerken kunnen worden gebruikt:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Als deze regel actief is, worden alle betalingen met betaalkaarten die zijn uitgegeven in Canada, Duitsland of de Verenigde Arabische Emiraten geblokkeerd.

Type 3

Metadatakenmerken: deze kenmerken zijn afhankelijk van de metadata die je naar Stripe verstuurt. Bij deze kenmerken moet je twee dubbele punten gebruiken voor en na standaardkenmerken. Voorbeeld:::Customer Age::. Metadatakenmerken kunnen de vorm aannemen van tekenreeksen of nummers. Wanneer ze worden gebruikt als tekenreeksen zijn kenmerken hoofdlettergevoelig.

Metadata kunnen worden gebruikt om buitengewoon nuttige regels te maken, bijvoorbeeld om betalingen aan een handmatige controle te onderwerpen als er een bepaalde SKU wordt aangeschaft of om de frictie voor terugkerende klanten te verminderen. In deze whitepaper lees je hoe je meer metadata kunt doorgeven.

Metadatakenmerken worden met de volgende opmaak genoteerd:

• ::[naam metadatakenmerk]:: [operator] [waarde_metadata]
  

Stel dat we betalingen met de volgende sleutel-waardegegevens hebben opgeslagen in het metadataveld:

Er kan een regel worden geschreven om betalingen die voldoen aan de volgende criteria aan een controle te onderwerpen.

• Review if ::Customer Age:: < 30
  

Je kunt ook regels schrijven met zowel metadata-attributen als andere in dit document genoemde ondersteunde attributen. Zo kun je een regel schrijven waardoor betalingen alleen aan controle worden onderworpen als de item-ID 5A381D is en het bedrag hoger is dan US $ 1000.

• Review if ::Item ID:: = '5A381D' and :amount_in_usd: > 1000
  

Met metadata-attributen kan de operator IN ook worden gecombineerd met meerdere waarden. Zo kun je bijvoorbeeld een regel schrijven waardoor een betaling aan controle worden onderworpen als de categorie-ID “groceries”, “electronics” of “clothing” is.

• Review if ::Category ID:: IN ('groceries', 'electronics', 'clothing')
  

De operator INCLUDES kan worden gebruikt met regels voor metadata-attributen en andere tekenreeksattributen die overeen moeten komen met subtekenreeksen. Zo kun je bijvoorbeeld een regel schrijven waardoor betalingen aan controle worden onderworpen als de item-ID de tekenreeks A381 bevat. Onder meer 'A381', '5A381D', 'A381D' en '5A381' voldoen aan die criteria.

• Review if ::Item ID:: INCLUDES 'A381'
  

Metadata kunnen ook worden geraadpleegd op klant- en bestemmingsobjecten (als deze worden gebruikt voor een bepaalde betaling). Deze attributen worden met de volgende opmaak genoteerd:

• ::[customer|destination]:[metadata attribute name]::[operator][metadata_value]:
  

Stel je hebt een klant met de volgende metadata:

Je kunt een regel schrijven waardoor betalingen altijd worden toegestaan als het metadataveld Trusted van de klant true is.

• Allow if ::customer:Trusted:: = 'true'
  

Of als je een bestemming zou hebben met de volgende metadata:

Je kunt een regel schrijven waardoor een betaling aan controle wordt onderworpen als het metadataveld Category van de bestemming new is.

• Review if ::destination:Category:: = 'new'
  

Opgeslagen lijsten (bijv. toelatingslijsten, blokkeerlijsten) in je regels gebruiken

Je kunt in je regels verwijzen naar een groep waarden met behulp van lijsten die je eerder hebt samengesteld (bijv. toelatingslijsten of blokkeerlijsten). Als je probeert een lijst e-mailadressen te blokkeren, moet je een blokkeerlijst maken in plaats van een afzonderlijke regel op te stellen voor elk e-mailadres dat je wilt blokkeren.

Alle lijstaliassen waarnaar in de regels wordt verwezen moeten beginnen met @. Om een regel samen te stellen waarin wordt verwezen naar een lijst, moet je de volgende structuur volgen:

• {action} [attribute] in [list]
  

Stel dat je bijvoorbeeld een lijst met kaartlanden hebt die je wilt blokkeren. Je zou dan een regel kunnen schrijven met diverse OR-clausules:

• Block if :card_country: = 'CA' OR :card_country: = 'DE' OR :card_country: = 'AE'
  

Je kunt de regel ook schrijven aan de hand van een inline-lijst:

• Block if :card_country: IN ('CA', 'DE', 'AE')
  

Je kunt ook een lijst opstellen met kaartlanden die je wilt blokkeren, getiteld card_countries_to_block. Je kunt de landen van je keuze dan toevoegen aan de lijst en in een regel naar die lijst verwijzen:

• Block if :card_country: in @card_countries_to_block
  

Een regel die gebruikmaakt van een lijst is niet alleen exacter, maar het is ook eenvoudiger om zo'n lijst te bewerken en er een groot aantal elementen aan toe te voegen.

Complexe regels schrijven met meerdere voorwaarden

Je kunt complexe voorwaarden bouwen door basisvoorwaarden samen te voegen met behulp van the operators AND, OR en NOT. Je kunt ook hun symbolische equivalenten gebruiken: &&, || en !. Vergelijkbaar met programmeertalen zoals C, Python en SQL, ondersteunt Stripe standaard operator precedence (bewerkingsvolgorde). Bijvoorbeeld de complexe voorwaarde:

• {condition_X} OR NOT {condition_Y} AND {condition_Z}
  

wordt geïnterpreteerd als:

• {condition_X} OR ((NOT {condition_Y}) AND {condition_Z})
  

Het groeperen van subvoorwaarden binnen complexe voorwaarden wordt ook ondersteund door haakjes te gebruiken. Het voorgaande voorbeeld kan bijvoorbeeld worden aangepast om de evaluatievolgorde van subpredicaten expliciet te wijzigen:

• ({condition_X} OR (NOT {condition_Y})) AND {condition_Z}

• {condition_X} OR NOT ({condition_Y} AND {condition_Z})

Door haakjes op verschillende plaatsen te gebruiken, leiden al deze complexe voorwaarden tot verschillende resultaten.

De functie is_missing kan ook worden gebruikt in OR- of AND-conjuncties:

• Review if is_missing(:email_domain:) OR :email_domain: IN ('yopmail.net', 'yandex.ru')
  

Of je kunt de functie is_missing gebruiken als deze niet ontbreekt, in dit geval als het betalingen blokkeert als de :ip_country: NIET ontbreekt en het IP-adres afkomstig is uit de Verenigde Staten of Puerto Rico.

• Block if !(is_missing(:ip_country:))AND :ip_country: IN ('US', 'PR')
  

Regels voor backtesting

Als algemene filosofie voor regelanalyse is er een afweging tussen het voorkomen van fraude en het blokkeren van goede transacties of fout-positieven. Met behulp van backtesting kun je regels identificeren die binnen je risicobereidheid vallen of de juiste balans vinden tussen voorkomen chargebacks en een toename van valse positieven. Om de impact van een regel in te schatten, kun je combinaties backtesten met behulp van transactiegegevens van de afgelopen zes maanden via het Radar Dashboard en meer gerichte analyses uitvoeren om te begrijpen hoe de regel zou hebben gepresteerd als deze onlangs was ingesteld.

Backtesting in het Dashboard

De definities van frauduleuze en andere geslaagde betalingen variëren afhankelijk van het soort regel dat je test:

Blokkeerregel

• Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en die zijn betwist of terugbetaald wegens fraude

• Andere geslaagde betalingen: geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en niet zijn betwist of terugbetaald wegens fraude -

Mislukte betaalpogingen: geweigerd door verstrekker of geblokkeerd door Radar

Controleregel

• Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude

• Andere geslaagde betalingen: geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude

• Mislukt of al aan controle onderworpen: geweigerd door verstrekker, geblokkeerd door Radar of geslaagde betalingen die aan controle zijn onderworpen (ongeacht chargeback- of terugbetalingsstatus)

Toelatingsregel

• Geblokkeerd door Stripe of je regels op maat: door Radar geblokkeerde betalingen

• Chargeback, vroegtijdige fraudewaarschuwing ontvangen of terugbetaald wegens fraude: geslaagde betalingen die zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en die zijn betwist of terugbetaald wegens fraude

• Andere geslaagde of door de bank geweigerde betalingen: geweigerd door verstrekker, geslaagde betalingen die niet zijn betwist of terugbetaald wegens fraude of geslaagde betalingen die aan controle zijn onderworpen en niet zijn betwist of terugbetaald wegens fraude

Uitvoering van backtesting-analyses op maat

De backtesting-functie op het Radar-dashboard gebruikt de transacties van de voorgaande zes maanden en bevat informatie over chargebacks, vroegtijdige fraudewaarschuwingen en wegens fraude terugbetaalde betalingen.

Het kan een goed idee zijn om een meer gerichte analyse uit te voeren als je risico loopt te worden opgenomen in het programma voor fraudemonitoring van Visa (uitsluitend gericht op vroegtijdige fraudewaarschuwingen) of als je hebt opgemerkt dat het aantal fraudegevallen voor een specifiek IP-land of soort wallet sterk is gestegen. Om dat te doen kun je een SQL-query in Sigma ontwikkelen of rapporten met betaalgegevens op het dashboard exporteren en analyseren. Bij backtesting op maat kun je flexibele perioden gebruiken (meer dan zes maanden) en meer gerichte analyses uitvoeren (je kunt je bijvoorbeeld uitsluitend richten op chargebacks of vroegtijdige fraudewaarschuwingen). In de voorbeeld-query hieronder wordt een backtest uitgevoerd op vroegtijdige fraudewaarschuwingen van Visa voor transacties van meer dan $ 100 in het hypothetische geval dat je hebt geconstateerd dat je fraudevolume bij hogere bedragen de laatste tijd sterk is gestegen en dat transacties met een verhoogde risicoscore hebben geleid tot een risico dat je in het monitoringprogramma word opgenomen:

Using fields and tables available in Sigma

with base as (
    select
        c.id,
        c.amount,
        c.captured,
        e.created as efw_created
    from charges c
    left join early_fraud_warnings on e.charge_id = c._id
    where card_brand = ‘visa’
    and (c.amount / 100) >= 100
    and c.captured >= dateadd(‘day’, -180, current_date)
)

select 
    count(case when efw_created >= dateadd(‘day’, -60, current_date) then id else null end) as fraud_charge_count,

sum(case when efw_created >= dateadd(‘day’, -60, current_date) then amount else null end) as fraud_amount,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then id else null end) as false_positive_charge_count,

count(case when efw_created is null and captured between dateadd(‘day’, -120, current_date) and dateadd(‘day’, -60, current_date) then amount else null end) as false_positive_amount

from base

Backtesting op de laatste 60 dagen op EFW-aanmaakdatum richt zich op de meest recente fraude, terwijl bij backtesting op de laatste 60-120 dagen van niet-frauduleuze verkopen de kans op fraude toeneemt.

Veelvoorkomende fraudevectoren

De meeste fraudeurs volgen een vast patroon voor het plegen van fraude. Eerst valideren ze de gestolen betalingsgegevens (bijvoorbeeld kaarten). Als ze hebben vastgesteld dat ze werken, gebruiken ze deze referenties om waarde te onttrekken in de vorm van fysieke goederen voor persoonlijk gebruik of wederverkoop (luxegoederen of elektronica), diensten voor persoonlijk gebruik of wederverkoop (voedselbezorgdiensten) of diensten en producten die helpen bij het plegen van verdere fraude (bijvoorbeeld webhostingdiensten, berichtspamdiensten enzovoort).

Lees verder voor meer informatie over enkele van de meest voorkomende fraudevectoren en suggesties voor het gebruik van Radar-regels om ze te beperken.

Testen

Testen van creditcards houdt in dat fraudeurs scripts of handmatige processen gebruiken om te testen of onbewerkte gestolen kaartnummers nog steeds actief zijn. In deze fraudefase gaat het niet om het verkrijgen van een fysiek goed of dienst, maar om te valideren of de kaarten actief zijn. Deze kosten zijn over het algemeen voor transacties van lagere bedragen of autorisaties. Testen worden over het algemeen snel achter elkaar uitgevoerd. Kenmerken die nuttig kunnen zijn, zijn groeps- en snelheidskenmerken, zoals:

• total_charges_per_customer

• cards_per_email_address

• cards_per_ip_address

• total_charges_per_ip

Fraudeurs proberen deze meestal te omzeilen door valse e-mails op te stellen en specifieke e-mailadressen te gebruiken. Meer geavanceerde fraudeurs maskeren IP-adressen of hebben zelfs meerdere apparaten om unieke apparaatgegevens te verstrekken. Op dat moment is het belangrijk om goed en typisch klantgedrag te herkennen. Functies zoals e-maildomein en IP-land, naast andere bredere categorieën, kunnen helpen bij het identificeren van transacties met een hoger risico. Veel frauduleuze klanten gebruiken populaire e-maildomeinen van bekende e-mailproviders, zoals gmail.com. Je ziet misschien domeinen als gmail.comms of gomail.co, die de identiteit van fraudeurs proberen te maskeren. Het land van de kaart en het IP-land kunnen ook worden gebruikt om klanten te segmenteren en ervoor te zorgen dat de transacties afkomstig zijn uit gebieden die kenmerkend zijn voor je gebruikersbestand. Transacties buiten deze locaties worden mogelijk eerder gecontroleerd of geblokkeerd.

Een laatste functionaliteit om dit testgedrag in te perken, is het instellen van CAPTCHA.

In Stripe Checkout worden CAPTCHA-uitdagingen automatisch aangepakt wanneer onze machine learning een aanval voor het testen van creditcards detecteert. Om het testen van creditcards te beperken, gebruikt Stripe een reeks geautomatiseerde en handmatige controles, waaronder limietbegrenzers, waarschuwingen en voortdurende controles naast het trainen van kaarttestmodellen om aanvallen automatisch te detecteren. Deze modellen pakken alleen uitdagingen aan wanneer er een kaarttestaanval aan de gang is, zodat echte gebruikers bijna nooit een CAPTCHA zien, alleen de bots. Hierdoor is het aantal kaarttesten bij bedrijven die Stripe Checkout gebruiken met maar liefst 80% gedaald, met een verwaarloosbaar effect op de conversie.

Je kunt ook aangepaste regels opstellen, bijvoorbeeld 'Blokkeren indien meer dan 3 keer geweigerd op een bepaald IP-adres' om het aantal kaarttestaanvallen te verminderen.

Waarde-extractie

Gestolen creditcards (nieuw gedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen betaalkaart op zijn persoonlijke apparaat of een apparaat dat wordt gebruikt om fraude te begaan.

Van deze vector wordt meestal misbruik gemaakt door middel van massale script-aanvallen of op kleinere schaal met meer gerichte fraude-'rings' en -'pockets'. Hoe dan ook kunnen regelattributen die meten hoe nieuw een account is op Stripe, zoals email_first_time_seen_on_stripe, in combinatie met risk_score en andere functies deze nieuwe kaarthouders op afstand houden. Daarnaast kun je met snelheidsbeperkingen voor IP-adressen, e-mails en betaalkaarten handelaren verder beschermen tegen volumeaanvallen waarbij fraudeurs proberen zo snel mogelijk aankopen te doen met gestolen creditcards.

Gestolen creditcards (maskeringsgedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen kaart op zijn persoonlijke apparaat of een apparaat dat wordt gebruikt om fraude te begaan, of heeft de fraudeur toegang gekregen tot een abonnementsaccount en de in dat account opgeslagen creditcardinformatie.

De fraudeur zal proberen zijn aanwezigheid te maskeren door:

• dezelfde naam te gebruiken als bij de voorgaande afgeronde transacties;

• hetzelfde factuuradres te gebruiken als bij de voorgaande afgeronde transacties;

• een VPN te gebruiken zodat hij de oorspronkelijke kaarthouder lijkt te zijn. Hij kan een VPN gebruiken voor dezelfde stad en soms zelfs hetzelfde blok;

• alleen één klein detail, zoals het e-mailadres of telefoonnummer, te veranderen;

• in het geval van fysieke goederen, het bezorgadres te veranderen ten opzichte van dat van eerdere transacties, waarbij de afstand tussen het factuur- en het bezorgadres mogelijk groot is. Dit is een lastig te detecteren signaal.

Het hierboven beschreven maskeringsgedrag maakt het lastig om te bepalen wie de transactie daadwerkelijk uitvoert: de oorspronkelijke kaarthouder of een fraudeur die toegang tot het account heeft gekregen. Hierdoor wordt dit soort fraude vaak niet ontdekt door de handelaar en de oorspronkelijke kaarthouder.

Hier wordt opnieuw dezelfde strategie toegepast: de fraudeur probeert zoveel mogelijk aankopen te doen met de gestolen gegevens. Regels die gebruikmaken van functies om de snelheid te beperken in combinatie met riskscore, cvccheck fails of zip check fails bieden bescherming tegen dit gedrag.

Je fraude analyseren om optimale regels op te stellen

Fraude-evaluaties

Om optimaal effectieve regels op te stellen, moet je een grondig inzicht hebben in de fraudeactiviteit in je account. Het is belangrijk om te weten welke verschillende soorten fraudevectoren aanwezig zijn. Een aantal vragen die je moet stellen:

• Worden accounts aangemaakt om daarna onmiddellijk frauduleuze aankopen te doen met nieuwe e-mails en nieuwe kaarthoudernamen?

• Krijgen fraudeurs toegang tot oude accounts en doen zij aankopen voor abnormaal hoge bedragen?

• Komt fraude meer voor bij specifieke kaartnetwerken of betaalkaarten uit bepaalde landen?

• Is er sprake van hogesnelheidsfraude, ofwel diverse pogingen met dezelfde betaalkaart of hetzelfde e-mail- of IP-adres gedurende een korte periode?

Als we kijken naar de hogesnelheidsfraude die plaatsvindt in de schermafbeelding hierboven, kunnen regels die gebruikmaken van authorized_charges_per_card_number_hourly of authorized_charges_per_ip_address_hourly mogelijk worden gebruikt om deze fraudevector aan te pakken.

Andere beste werkwijzen

Hier zijn nog een paar aanbevolen werkwijzen om optimale regels te schrijven met Radar.

Belang van het gebruik van Stripe.js

• Neem stripe.js op in het volledige betaaltraject voor maximale signalering van fraude
  
• Om het maximale uit Radar te halen zonder gevolgen voor de paginalaadtijd, laad je stripe.js asynchroon op niet-betaalpagina's
  
• Het eenvoudigst is om dit naast de Google Analytics-scripttags te plaatsen
  
• Volledige stripe.js-bundelgrootte is 29,6 kB (gzip-formaat)
  
  • In de toekomst zal het mogelijk zijn radar.js los van stripe.js op te nemen
    

Conclusie

Regels kunnen een buitengewoon nuttig instrument zijn voor fraudebescherming op maat. Door een unieke logica toe te passen op basis van een aantal van de beste werkwijzen die in dit whitepaper worden beschreven, kun je in Radar een configuratie voor fraudepreventie opzetten die aansluit op de behoeften van je bedrijf.

Voor meer informatie over Radar for Fraud Teams kun je hier terecht.

Als je al gebruikmaakt van Radar for Fraud Teams, ga dan naar de pagina Regels op je dashboard om te beginnen met het schrijven van regels.

Andere opmerkingen

Radar voor platforms

Heb je een platform dat gebruikmaakt van Stripe Connect? Dan worden de regels die je opstelt alleen toegepast op betalingen die worden gemaakt op het platformaccount (in Connect-termen zijn dit bestemmings- of namens-betalingen).
Voor betalingen die direct in het gekoppelde account worden gemaakt, gelden de regels van dat account.

Radar voor Terminal

Terminal-betalingen worden niet gescreend door Radar. Als je Terminal gebruikt, kun je daarom regels schrijven op basis van IP-frequentie zonder je zorgen te maken dat fysieke betalingen worden geblokkeerd.