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. 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 kenmerk of een metadatakenmerk daadwerkelijk bestaat, gebruik dan niet de operator !=, maar de functie is_missing. Voer in deze functie het kenmerk of de metadatasleutel in die mogelijk ontbreekt. Je kunt bijvoorbeeld een regel schrijven om alle betalingen te vinden waar je geen toegang hebt tot het e-mailadres van een klant:

• Review if is_missing(:email_domain:)
  

Je kunt ook een regel schrijven om alle betalingen te vinden waar het e-mailadres van een klant NIET ontbreekt:

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

Regels schrijven in gewone taal

Als je op een makkelijkere manier regels wilt schrijven of als je niet zeker weet welke kenmerken je moet gebruiken voor een bepaald fraudescenario, kun je je vragen in gewone taal aan de AI-gestuurde Radar-assistent stellen. Deze zet ze om in regels met de syntaxis van Radar. Je kunt ook rechtstreeks vanuit de Radar-assistent een backtest uitvoeren op de regel, zodat je kunt zien wat de uitkomst in het verleden zou zijn geweest voordat je de regel implementeert.

Regels opstellen voor betaalmethoden

Radar ondersteunt kaarten en ACH- en SEPA-bankafschrijvingen, en ondersteunt nu ook bepaalde extra betaalmethoden in preview. Check onze docs voor meer info en toegang tot Radar voor extra betaalmethoden.

De attributen :risk-score: en :risk-level: werken alleen met kaart-, ACH- en SEPA-transacties. We ondersteunen ook andere transactieregelattributen die voor elke betaalmethode gelden.

Als je bent toegevoegd aan de preview, kun je backtesten en Radar-regels maken die van toepassing zijn op betalingen met een specifieke betaalmethode door het kenmerk :payment_method_type: te gebruiken. Als je :payment_method_type: gebruikt, geldt je regel voor alle ondersteunde betaalmethoden, zolang je geen attribuut gebruikt dat specifiek is voor een betaalmethode (zoals :card_count_for_ip_address_daily: bijvoorbeeld).

Veelgebruikte regels in Radar

Dit is een niet uitputtende lijst van veelgebruikte Radar-regels gebaseerd op verschillende doeleinden.

Regels die het testen van creditcards of geld opnemen via creditcards helpen voorkomen

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 die helpen om fraude bij je betaalmethoden te voorkomen

Fraude analyseren om het opstellen van regels te leiden

Fraude-evaluaties

Voor het schrijven van effectieve regels is het belangrijk dat je een goed inzicht krijgt in de gepleegde fraude. Het is belangrijk om de verschillende soorten aanwezige fraudevectoren te duiden. Vragen die je daarbij kunt stellen:

• Doen accounts direct na aanmelding frauduleuze aankopen met nieuwe e-mailadressen en namen van kaarthouders?

• Gebruiken fraudeurs verouderde accounts en doen ze aankopen voor abnormaal hoge bedragen?

• Wordt er vooral gefraudeerd op specifieke kaartnetwerken of in bepaalde landen?

• Is er sprake van high-velocity fraude, dat wil zeggen meerdere pogingen met dezelfde betaalmethode, e-mailadres of IP-adres in korte tijd?

Als je kijkt naar de fraude met hoge snelheid op het screenshot hierboven, kun je deze fraudevector bijvoorbeeld bestrijden met regels die authorized_charges_per_card_number_hourly of authorized_charges_per_ip_address_hourly gebruiken.

Meer inzicht krijgen in factoren die fraude veroorzaken

Als je meer inzicht in fraude hebt, kun je snel de oorzaken van de fraude herkennen en bestrijden en hoef je niet elke keer handmatig transactiegegevens te analyseren. Op het tabblad Inzichten in het dashboard staan de meestvoorkomende kenmerken die in verband staan met frauduleuze transacties. Hier kun je een regel toevoegen om het desbetreffende kenmerk rechtstreeks vanaf het tabblad Inzichten aan te pakken.

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 via lijsten die je eerder hebt gemaakt (bijv. toelatingslijsten of blokkeerlijsten). Als je een lijst met e-mails wilt blokkeren, kun je beter een blokkeerlijst maken in plaats van meerdere regels voor elke e-mail die je wilt blokkeren. Zo kun je ook de waarden op een lijst voor alle betaalmethoden blokkeren. Als je bijvoorbeeld een e-mail aan een lijst toevoegt nadat deze met een kaart is gebruikt, wordt een transactie met een bankafschrijving of andere betaalmethode die dat e-mailadres gebruikt, ook geblokkeerd.

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} [attribuut] in [lijst]
  

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

• Blokkeer als :card_country: = ‘CA’ OF :card_country: = ‘DE’ OF :card_country: = ‘AE’
  

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

• Blokkeer als :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:

• Blokkeer als :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.

Je kunt een meer gerichte analyse uitvoeren als je bijvoorbeeld het risico loopt te worden geïdentificeerd in een Visa Fraud Monitoring Program (dat zich uitsluitend richt op vroege fraudewaarschuwingen) of als je een recente piek in fraude vanuit een specifiek IP-land of type wallet constateert. Hiervoor kun je een SQL-query bouwen in Stripe Sigma of rapporten met betalingsgegevens exporteren en analyseren in het dashboard. Aangepaste backtesting biedt flexibiliteit in tijdsbestekken (langer dan zes maanden) en meer gerichte analyses (je kunt je bijvoorbeeld alleen richten op chargebacks of EFW's). De onderstaande voorbeeldquery voert een backtest uit op vroege fraudewaarschuwingen (EFW's) van Visa voor transacties > $ 100, als je hypothetisch zou vaststellen dat het fraudevolume recentelijk piekte bij hogere waarden en dat transacties met een verhoogde risicoscore een risico vormden voor het monitoringprogramma:

Gebruik van velden en tabellen die beschikbaar zijn in Stripe Sigma

met basis als (
    selecteer
        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)
.

selecteer 
    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

van basis

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

• card_count_for_email

• card_count_for_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 ondernemingen die Stripe Checkout gebruiken met maar liefst 80% gedaald, met een verwaarloosbaar effect op de conversie.

Je kunt overigens ook regels schrijven als ”Blokkeren indien meer dan 3 keer geweigerd vanaf een bepaald IP-adres” om dit soort aanvallen te beperken.

Waarde-extractie

Gestolen creditcards (nieuw gedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen kaart op zijn eigen apparaat of op een apparaat dat voor fraude wordt gebruikt.

Deze vector wordt doorgaans gebruikt in gescripte massa-aanvallen of op kleinere schaal met meer gerichte fraudenetwerken en -bendes. Hoe dan ook, als je regelkenmerken gebruikt waarin de nieuwheid van een account op Stripe wordt gemeten, bijvoorbeeld hours_since_email_first_seen_on_stripe, in combinatie met een risicoscore en andere kenmerken, kun je deze splinternieuwe kaarthouders op afstand houden. Bovendien kunnen snelheidsbeperkingen op IP, e-mails en kaarten handelaren verder beschermen tegen grootschalige aanvallen waarbij fraudeurs zo snel mogelijk willen profiteren van gestolen inloggegevens.

Gestolen creditcards (maskeergedrag)

Bij deze fraudevector gebruikt de fraudeur de gevalideerde gestolen kaart op zijn eigen apparaat of op een apparaat dat voor fraude wordt gebruikt of heeft de fraudeur het account van een abonnee gehackt en toegang gekregen tot de creditcardgegevens die in het account worden bewaard.

De fraudeur zal zijn best doen om zijn aanwezigheid te maskeren door:

• Dezelfde naam te gebruiken als bij eerdere voltooide transacties

• Hetzelfde factuuradres te gebruiken als bij eerdere voltooide transacties

• Een VPN te gebruiken om zich voor te doen als de oorspronkelijke kaarthouder. Ze kunnen proberen de VPN af te stemmen op dezelfde plaats en soms zelfs dezelfde straat

• Slechts een klein detail te veranderen, bijvoorbeeld in het e-mailadres of het telefoonnummer

• Een ander bezorgadres op te geven dan bij eerdere transacties, voor een fysiek artikel, mogelijk met een grote afstand tussen het factuur- en bezorgadres. Dit is een onduidelijk signaal

Het hierboven beschreven maskeergedrag maakt het moeilijk om precies te zien wie nu eigenlijk de transactie heeft uitgevoerd, de oorspronkelijke kaarthouder of een fraudeur die het account heeft gehackt. Dit betekent doorgaans dat dit soort fraude langer ongemerkt blijft, zowel door de handelaar als door de oorspronkelijke kaarthouder.

De strategie is dezelfde: de fraudeur probeert zoveel mogelijk waarde te halen uit de gestolen inloggegevens. Regels die gebruikmaken van snelheidsbeperkende functies, naast risicoscore, mislukte cvc-controles of mislukte postcodecontroles, kunnen je helpen beschermen tegen dit soort gedrag.

Fraudevectoren voor verschillende betaalmethoden

Nu bedrijven zich niet alleen op kaarten richten, maar ook op bankafschrijvingen, “koop nu, betaal later”-opties zoals Klarna en andere lokale betaalmethoden, hebben fraudeurs hun tactieken aangepast om misbruik te maken van de unieke kenmerken en kwetsbaarheden van elke betaalmethode. Inzicht in deze veranderende fraudepatronen is essentieel voor het opzetten van een uitgebreide bescherming.

Van betaalmethode wisselen

Fraudeurs wisselen systematisch tussen verschillende betaalmethoden om de snelheidscontroles voor individuele betaalmethoden te omzeilen. Ze kunnen hun kaartlimieten opgebruiken, vervolgens overschakelen naar ACH en daarna naar Klarna, waardoor ze hun transactiecapaciteit effectief verdrievoudigen voordat de controles van een enkele betaalmethode worden geactiveerd.

Aanbevolen kenmerken om dit patroon aan te pakken:

• total_charges_per_email_daily
  
• total_charges_per_ip_address_hourly
  
• payment_method_type in combinatie met snelheidscontroles
  

Misbruik van specifieke betaalmethoden

• Dubbele terugbetalingsfraude bij asynchrone betaalmethoden: Bij bankafschrijvingen en sommige lokale betaalmethoden maken fraudeurs misbruik van het tijdsverschil tussen het moment waarop ze goederen ontvangen en het moment waarop betalingen worden verwerkt. Ze vragen tegelijkertijd terugbetaling aan bij zowel hun bank (met het argument dat het om een ongeautoriseerde transactie gaat) als bij de handelaar (met het argument dat ze ontevreden zijn), in de hoop dat beide terugbetalingen worden verwerkt voordat een van beide de dubbele terugbetalingsaanvraag opmerkt.

• Fraude met eerste betalingen bij BNPL-diensten: Fraudeurs richten zich op ‘koop nu, betaal later’-diensten (BNPL) door aankopen te doen, goederen te ontvangen na de eerste termijn en vervolgens het betalingsplan te staken. Ze gebruiken vaak gehackte accounts of vervalste identiteiten, waardoor het voor BNPL-aanbieders moeilijk is om de resterende termijnen te innen.

Arbitrage op het gebied van regelgeving en beleid

• Gericht gebruik van geschillenvriendelijke betaalmethoden: Fraudeurs onderzoeken welke betaalmethoden de meest kopersvriendelijke geschillenbeslechtingsprocedures hebben en richten zich specifiek op die methoden voor frauduleuze aankopen.

  • dispute_count_on_ip_all_time in combinatie met specifieke risicovolle payment_method_type waarden
    
  • is_disposable_email in combinatie met geschillenvriendelijke betaalmethoden
    
  • Geografische patronen waarbij geschillenregelgeving in het voordeel van kopers is
    

Andere aanbevolen werkwijzen

Hier zijn nog enkele aanbevolen werkwijzen om je te helpen het schrijven van regels in Radar te optimaliseren.

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.

Als je meer wilt weten over Radar for Fraud Teams, kijk dan hier.

Als je al een gebruiker bent van Radar for Fraud Teams, ga dan naar de pagina Regels in je dashboard om aan de slag te gaan met het schrijven van regels.

Andere opmerkingen

Radar for 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).
kosten), tenzij je vraagt om deel te nemen aan onze Radar voor platforms preview. Betalingen die rechtstreeks op het gekoppeld account zijn gemaakt, vallen onder de regels van dat account.

Radar for 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.