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 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-assistent van Radar stellen. Deze zet ze om in regels met de syntaxis van Radar. Je kunt ook rechtstreeks vanuit Radar Assistant een backtest uitvoeren op de regel, zodat je kunt zien wat de uitkomst in het verleden zou zijn geweest voordat je de regel implementeert.

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 om misbruik van proefabonnementen met prepaidkaarten 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 fraude met hoge snelheid, dat wil zeggen worden er in korte tijd meerdere pogingen gedaan met dezelfde creditcard, hetzelfde e-mailadres of IP-adres?

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 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

• 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.

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.

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.