Le regole predefinite di Stripe utilizzano il machine learning per prevedere e bloccare un numero considerevole di pagamenti fraudolenti. Per le aziende che necessitano di maggiore controllo su quali pagamenti rivedere, consentire o bloccare, le regole sono uno strumento potente per personalizzare la protezione contro le frodi.

Questa guida contiene una serie di argomenti sulle regole di Radar, incluse oltre 100 regole pronte all'uso e le migliori pratiche relative a backtesting, scrittura delle regole e molto altro ancora.

Iniziamo.

L'importanza dell'ordine e della gerarchia delle regole

L'ordine in cui le regole sono elencate nella tua pagina Radar è importante. Ogni pagamento viene valutato rispetto alle regole create, le quali vengono eseguite nel seguente ordine:

1. Request 3DS: regole che richiedono l'autenticazione 3D Secure quando utilizzate con l'API Payment Intents o Checkout. Indipendentemente dalle corrispondenze trovate per questo tipo di regole, le regole Allow, Block e Review vengono sempre valutate dopo.
   
2. Allow: regole che consentono l'elaborazione di un pagamento. Le regole Allow devono essere implementate con attenzione, poiché prevalgono su tutte le altre regole tranne quelle 3DS, compresi i modelli di machine learning di Stripe, e devono essere pertanto usate con la massima cautela. Solo gli esercenti che hanno elaborato oltre 100.000 dollari possono scrivere regole Allow.
   
3. Block: regole che bloccano un pagamento e lo rifiutano. Se un pagamento viene rifiutato, non viene valutato rispetto ad alcuna regola Review.
   
4. Review: questi pagamenti vengono comunque elaborati e addebitati al cliente, ma vengono segnalati in modo che sia possibile dare loro una seconda occhiata in caso di necessità.
   

Per fare un esempio pratico, consideriamo le regole riportate di seguito. In base a queste regole, tutti i pagamenti inferiori a 10 dollari vengono processati. Questo si verifica perché la prima regola consente il pagamento e non vengono quindi valutate altre regole. Allo stesso modo, in base a queste regole, è consentito anche un pagamento di 1500 dollari effettuato all'interno degli Stati Uniti con un livello di rischio normale, nonostante la regola che blocca i pagamenti superiori a 1000 dollari. Questo è reso possibile dalla seconda regola dell'elenco, che permette i pagamenti effettuati all'interno degli Stati Uniti con un livello di rischio normale. Una volta attivata una specifica regola, non ne vengono valutate altre.

• 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

Schema riassuntivo del linguaggio delle regole

Le regole sono scritte in un linguaggio simile a SQL ed è possibile utilizzare vari operatori in base al tipo di dati usati per creare la regola. Ecco un riepilogo.

Se vuoi controllare in modo esplicito se esiste un attributo o un attributo di metadati, non usare l'operatore !=, ma usa la funzione is_missing. Specifica questa funzione con l'attributo o la chiave di metadati potenzialmente mancante. Ad esempio, potresti scrivere una regola per trovare tutti i pagamenti per i quali non hai accesso all'indirizzo email di un cliente:

• Review if is_missing(:email_domain:)
  

Oppure potresti scrivere una regola per trovare tutti i pagamenti per i quali l'indirizzo email del cliente NON è mancante:

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

Scrittura di regole utilizzando il linguaggio naturale

Se vuoi scrivere regole più facilmente o in caso di dubbi sugli attributi da usare per affrontare uno specifico scenario di frode, Assistente di Radar basato sull'IA tradurrà i tuoi prompt in linguaggio naturale in regole nella sintassi di Radar. Puoi eseguire il backtesting della regola direttamente dall'Assistente di Radar, in modo da verificarne il comportamento storicamente prima di implementarla.

Regole Radar di uso comune

Quello che segue è un elenco non esaustivo di regole Radar comunemente usate, suddivise per obiettivi.

Regole per prevenire il testing o il cashing delle carte

Regole per prevenire le frodi con SKU notoriamente rischiosi

In queste regole è necessario inserire metadati o informazioni sullo SKU come descrizione dell'addebito. Questi pagamenti vengono comunque elaborati e addebitati al cliente, ma vengono segnalati in modo che sia possibile riesaminarli.

Regole per prevenire l'abuso di prove con carte prepagate

Analisi delle frodi per orientare la creazione delle regole

Revisioni delle frodi

Per compilare le regole più efficaci, devi comprendere bene l'attività fraudolenta in atto sul tuo account. È importante caratterizzare i diversi tipi di vettori di frode presenti. Ecco alcune domande da porsi:

• Dopo la registrazione, gli account fanno subito acquisti fraudolenti utilizzando nuovi indirizzi email e nuovi nomi di titolari di carta?

• Gli attori fraudolenti accedono ad account obsoleti facendo acquisti per importi stranamente elevati?

• La frode riguarda specifici circuiti o paesi delle carte?

• Si sta verificando una frode ad alta velocità, ovvero diversi tentativi eseguiti dalla stessa carta, email o indirizzo IP in un breve lasso di tempo?

Prendendo in esame la frode ad alta velocità della schermata sopra, le regole che utilizzano gli attributi authorized_charges_per_card_number_hourly o authorized_charges_per_ip_address_hourly sono potenzialmente in grado di contrastare questo vettore di frode.

Ottieni più dati sui fattori determinanti per le frodi

I dati sulle frodi consentono di identificare e affrontare rapidamente le cause delle frodi senza dover analizzare manualmente i dati delle transazioni. La scheda Insights nella Dashboard mostra i principali attributi associati alle transazioni fraudolente. Da qui puoi aggiungere una regola per gestire l'attributo direttamente dalla scheda Insights.

Tre tipi di attributi per creare regole

Tipo 1

Attributi post-autorizzazione: sono utilizzabili da tutti. Se utilizzati, devono essere racchiusi tra un segno di due punti iniziale e finale, ad esempio :cvc_check:.

Ecco un esempio di come utilizzare gli attributi post-autorizzazione:

• Block if :address_line1_check: != 'pass' Questa regola blocca qualsiasi addebito che non supera il controllo eseguito dall'emittente della carta che confronta la prima riga dell'indirizzo di fatturazione fornito con le informazioni registrate per il titolare della carta. In altre parole, se questo controllo è 'unavailable' (non disponibile), se questi dati sono 'unchecked' (non verificati) o 'not_provided' (non forniti) dall'emittente, il pagamento viene bloccato.
  

Tipo 2

Attributi standard: sono utilizzabili da tutti. Devono essere racchiusi tra un segno di due punti iniziale e finale, ad esempio :card_bin: Abbiamo suddiviso i nostri attributi standard in quattro categorie:

• Attributi basati sulla frequenza, utili per prevenire il testing o il cashing delle carte
  
• Attributi basati sui dati della carta
  
• Attributi basati sui dati di pagamento
  
• Attributi basati sui dettagli del cliente
  

Come valori, alcuni attributi richiedono delle stringhe, mentre altri dei numeri. Per maggiore chiarezza, abbiamo fornito un esempio per ciascun attributo. Se l'attributo richiede una stringa, come accade per :card_bin:, nell'esempio il valore sarà racchiuso tra virgolette ' ' e si avrà :card_bin: = '24242'. Se richiede un numero, le virgolette ' ' non saranno presenti e si avrà :amount_in_usd: > 250.

Attributi basati sulla frequenza

Sono disponibili quattro tipi di attributi basati sulla frequenza, che sono particolarmente utili per prevenire le frodi con carte rubate, il testing delle carte e il cashing delle carte.

1. Autorizzazione: basati sulle autorizzazioni da parte dell'emittente
   
2. Addebito: basati sugli addebiti
   
3. Rifiuto: basati sui rifiuti da parte dell'emittente
   
4. Blocco: basati sui blocchi eseguiti dal machine learning di Radar
   

Sono disponibili anche attributi basati sull'esito dell'addebito, inclusi autorizzazioni (basati sulle autorizzazioni riuscite da parte dell'emittente), addebiti (basati sui tentativi di addebito), rifiuti (basati sui rifiuti da parte dell'emittente), contestazioni (transazioni precedenti contestate come fraudolente) e blocchi (basati sui blocchi eseguiti dal machine learning di Radar). I risultati sono combinati con un dato del cliente (email, indirizzo IP, nome o ID cliente) per formare un attributo.

Inoltre, puoi combinare la frequenza di un dato del cliente (email, nome) con la carta o l'indirizzo IP utilizzati in una transazione. In altre parole, sono disponibili due tipi di regole basate sulla frequenza:

1. Basate sull'esito dell'addebito (ad es. authorized_charges_per_email_hourly, blocked_charges_per_email_hourly), il cui esito è autorizzazione riuscita, tentativo di addebito, rifiuti, contestazioni, blocchi
   
2. Basate sui collegamenti tra i dati del cliente e la carta o l'IP (ad es. name_count_for_card_weekly, email_count_for_ip_hourly)
   

Le regole basate sulla frequenza non includono il pagamento che si sta elaborando. Ad esempio, l'attributo authorized_charges_per_email_hourly rappresenta il numero di tentativi di addebito correttamente autorizzati da un'email nell'ultima ora. Pertanto, per il primo tentativo di addebito da un'email in una data ora, authorized_charges_per_email_hourly avrà come valore 0. Se il primo tentativo di addebito va a buon fine, il secondo tentativo nella stessa ora da quell'email avrà valore 1 e così via.

Attributi basati sui dati della carta

Attributi basati sui dati di pagamento

Attributi basati sui dettagli del cliente

Ecco un esempio di utilizzo degli attributi standard:

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

Con questa regola in uso, qualsiasi addebito proveniente da una carta emessa in Canada, Germania o Emirati Arabi Uniti viene bloccato.

Tipo 3

Attributi dei metadati: questi attributi dipendono dai metadati inviati a Stripe. Devono essere racchiusi tra un doppio segno di due punti iniziale e finale, ad es. ::Customer Age::. Gli attributi dei metadati possono essere sia stringhe che numeri. Nel primo caso, distinguono tra maiuscole e minuscole.

I metadati consentono di creare regole molto potenti, ad esempio per rivedere manualmente addebiti in base allo SKU acquistato o agevolare le transazioni di clienti di ritorno. Per scoprire come inserire più metadati, consulta questa guida.

Gli attributi dei metadati utilizzano la seguente struttura:

• ::[nome attributo metadati]:: [operatore] [valore_metadati]
  

Supponiamo di avere dei pagamenti con i seguenti dati chiave-valore memorizzati nel campo metadati:

È possibile scrivere una regola per mettere in revisione i pagamenti che soddisfano i seguenti criteri.

• Review if ::Customer Age:: < 30
  

Puoi anche scrivere regole utilizzando sia gli attributi dei metadati che altri attributi supportati illustrati in questo documento. Ad esempio, puoi scrivere una regola che mette un pagamento in revisione solo se l'ID dell'articolo corrisponde a 5A381D e l'importo del pagamento supera i 1000 dollari.

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

Gli attributi dei metadati supportano anche l'operatore IN per trovare corrispondenze rispetto a più valori. Ad esempio, puoi scrivere una regola che mette un pagamento in revisione se l'ID della categoria è "groceries", "electronics" o "clothing".

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

L'operatore INCLUDES può essere utilizzato nelle regole con attributi dei metadati e altri attributi delle stringhe per trovare corrispondenze con sottostringhe. Ad esempio, puoi scrivere una regola che mette un pagamento in revisione se l'ID dell'articolo include la stringa A381. In questo caso, verranno trovate le corrispondenze "A381", "5A381D", "A381D", "5A381" e molte altre.

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

È possibile accedere ai metadati anche negli oggetti cliente e destinazione (se utilizzati per un determinato pagamento). Questi attributi utilizzano la seguente struttura:

• ::[cliente|destinazione]:[nome attributo metadati]::[operatore][valore_metadati]:
  

Supponiamo che per un cliente siano disponibili i seguenti metadati:

Potresti scrivere una regola che consente sempre i pagamenti se il campo dei metadati Trusted del cliente è impostato su true.

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

O se è presente una destinazione con i seguenti metadati:

potresti scrivere una regola che mette un pagamento in revisione se il campo dei metadati Category della destinazione è new.

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

Utilizzo di elenchi salvati nelle regole (ad es. elenchi di consenso, elenchi di blocco)

Nelle regole puoi fare riferimento a un gruppo di valori utilizzando elenchi creati in precedenza, ad esempio elenchi di consenso o elenchi di blocco. Se stai tentando di bloccare un elenco di indirizzi email, dovresti creare un elenco di blocco anziché creare più regole per ogni email da bloccare.

Tutti gli alias degli elenchi a cui fanno riferimento le regole devono iniziare con @. Per compilare una regola che fa riferimento a un elenco, devi utilizzare la seguente struttura:

• {action} [attributo] in [elenco]
  

Supponiamo che tu abbia un elenco di paesi di carte che vorresti bloccare. Per farlo, potresti scrivere una regola con varie clausole OR:

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

Oppure potresti scrivere una regola utilizzando un elenco in linea:

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

In alternativa, potresti creare un elenco di paesi di carte da bloccare, denominato card_countries_to_block, aggiungervi i paesi desiderati e farvi riferimento in una regola:

• Block if :card_country: in @card_countries_to_block
  

Non solo la regola che utilizza l'elenco è più concisa, ma è anche molto più facile da modificare ed è possibile aggiungervi un gran numero di voci.

Scrittura di regole complesse con più condizioni

Puoi creare condizioni complesse unendo fra loro condizioni di base con gli operatori AND, OR e NOT. Puoi anche usare i rispettivi equivalenti simbolici: &&, || e !. Analogamente ai linguaggi di programmazione come C, Python e SQL, Stripe supporta la precedenza (ordine delle operazioni). Ad esempio, la condizione complessa:

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

viene interpretata come:

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

È supportato anche il raggruppamento di sottocondizioni all'interno di condizioni complesse tramite l'uso delle parentesi. Ad esempio, è possibile modificare l'esempio precedente per cambiare esplicitamente l'ordine di valutazione dei sottopredicati:

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

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

Usando le parentesi in posizioni diverse, ognuna di queste condizioni complesse genera risultati diversi.

Nelle combinazioni con OR o AND è inoltre possibile utilizzare la funzione is_missing:

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

Oppure è possibile utilizzare la funzione is_missing quando un attributo non è mancante. Nell'esempio sotto, i pagamenti vengono bloccati se :ip_country: NON è mancante e se l'IP è US o PR.

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

Backtesting delle regole

Come approccio generale all'analisi delle regole, esiste un compromesso tra la prevenzione delle frodi e il blocco delle transazioni valide o dei falsi positivi. Il backtesting aiuta a identificare le regole che soddisfano la tua propensione al rischio o a trovare il giusto equilibrio tra contestazioni evitate e aumento di falsi positivi. Per stimare l'impatto di una regola, puoi eseguire il backtesting di varie combinazioni utilizzando i dati delle transazioni degli ultimi sei mesi tramite la Dashboard di Radar e condurre analisi più mirate per capire come si sarebbe comportata la regola se fosse stata implementata di recente.

Backtesting nella Dashboard

Le definizioni di ciò che costituisce un pagamento fraudolento e degli altri pagamenti riusciti variano a seconda del tipo di regola che stai testando:

Regola di blocco

• Contestati, con preavviso di frode o rimborsati per frode: addebiti andati a buon fine che erano stati contestati o rimborsati per frode o addebiti andati a buon fine messi in revisione che erano stati contestati o rimborsati per frode

• Altri pagamenti riusciti: addebiti andati a buon fine che non erano stati contestati o rimborsati per frode o addebiti andati a buon fine messi in revisione che non erano stati contestati o rimborsati per frode

• Tentativi di pagamento non riusciti: rifiutati dall'emittente o bloccati da Radar

Regola di revisione

• Contestati, con preavviso di frode o rimborsati per frode: addebiti andati a buon fine che erano stati contestati o rimborsati per frode

• Altri pagamenti riusciti: addebiti andati a buon fine che non erano stati contestati o rimborsati per frode

• Non riusciti o già in revisione: rifiutati dall'emittente, bloccati da Radar o andati a buon fine messi in revisione (indipendente dallo stato della contestazione o del rimborso)

Regola di consenso

• Bloccati da Stripe o da regole personalizzate: addebiti bloccati da Radar

• Contestati, con preavviso di frode o rimborsati per frode: addebiti andati a buon fine che erano stati contestati o rimborsati per frode o addebiti andati a buon fine messi in revisione che erano stati contestati o rimborsati per frode

• Altri pagamenti riusciti o rifiutati dalle banche: rifiutati dall'emittente, addebiti andati a buon fine che non erano stati contestati o rimborsati per frode o rimborsati per frode o addebiti andati a buon fine messi in revisione che non erano stati contestati o rimborsati per frode

Esecuzione di analisi di backtesting personalizzate

La funzionalità di backtesting della Dashboard Radar considera gli ultimi sei mesi di transazioni e include contestazioni, preavvisi di frode e addebiti rimborsati come fraudolenti.

Potresti voler eseguire un'analisi più mirata se, ad esempio, sei a rischio di identificazione in un Programma di monitoraggio delle frodi di Visa (focalizzato esclusivamente sui preavvisi di frode) o se di recente hai notato un picco di frodi provenienti da un tipo di wallet o dal paese di un IP specifico. Per farlo, puoi compilare una query SQL in Sigma o esportare e analizzare report di dati di pagamento nella Dashboard. Il backtesting personalizzato permette una certa flessibilità circa l'intervallo di tempo (oltre i sei mesi) e analisi più mirate (ad esempio, puoi concentrarti solo sulle contestazioni o sui preavvisi di frode). La query di esempio riportata sotto consente di eseguire il backtesting dei preavvisi di frode di Visa su transazioni superiori a 100 dollari nel caso tu abbia ipoteticamente scoperto che il volume delle frodi è recentemente aumentato e che transazioni con un punteggio di rischio elevato hanno generato un rischio per il programma di monitoraggio:

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

Il backtesting sugli ultimi 60 giorni in base alla data di creazione del preavviso di frode individua la frode più recente, mentre il backtesting degli ultimi 60-120 giorni di vendite non fraudolente consente alla frode di consolidarsi in modo più completo.

Vettori di frode comuni

La maggior parte dei truffatori segue uno schema comune quando commette una frode. Innanzitutto, verificano i dati di pagamento rubati (ad esempio, le carte). Dopo averne verificato il funzionamento, usano queste credenziali per ricavarne un valore sotto forma di beni fisici per uso personale o per la rivendita (beni di lusso o strumenti elettronici), servizi per uso personale o per la rivendita (servizi di consegna di cibo a domicilio) oppure servizi e prodotti che consentono di commettere ulteriori frodi (ad esempio, servizi di hosting, servizi di spamming e così via).

Continua a leggere per saperne di più su alcuni dei vettori di frode più comuni e sui possibili modi di utilizzare le regole di Radar per contrastarli.

Testing

Il testing delle carte si verifica quando i truffatori utilizzano script o processi manuali per verificare se i numeri di carta rubati sono ancora attivi. In questa fase della frode, lo scopo non è quello di procurarsi un bene fisico o un servizio, ma di verificare che le carte siano attive. Questi addebiti riguardano generalmente transazioni di basso valore o autorizzazioni. Il testing è caratterizzato in genere da addebiti molto veloci in rapida successione. Gli attributi che possono essere utili sono quelli che rilevano la concentrazione e la velocità, ad esempio:

• total_charges_per_customer

• card_count_for_email

• card_count_for_ip_address

• total_charges_per_ip

I truffatori cercano in genere di aggirarli creando false email e utilizzando indirizzi email distinti. I truffatori più esperti mascherano gli indirizzi IP o usano addirittura più dispositivi per fornire dati univoci su ogni dispositivo. A questo punto, conoscere il comportamento legittimo e tipico del cliente è importante. Funzionalità come il dominio email e il paese dell'IP, tra le categorie più generali, possono aiutare a identificare le transazioni a più alto rischio. Molti truffatori utilizzano domini email popolari di provider di posta elettronica molto diffusi, come gmail.com. Potresti notare domini come gmail.comms o gomail.co, che cercano di mascherare l'identità dei truffatori. È anche possibile utilizzare il paese della carta e il paese dell'IP per segmentare i clienti e assicurarsi che le transazioni provengano da aree geografiche tipiche della tua base di utenti. In questo caso, potrebbe essere interessante rivedere o bloccare le transazioni originate al di fuori di queste aree.

Un'ultima funzionalità per contrastare il testing delle carte è utilizzare la verifica CAPTCHA.

In Stripe Checkout la richiesta di autenticazione CAPTCHA viene attivata automaticamente quando il machine learning di Stripe rileva un attacco di tipo testing delle carte. Per limitare il testing delle carte, Stripe utilizza una serie di controlli automatici e manuali, compresi i limitatori di frequenza, gli avvisi e le revisioni su base continuativa, oltre ad addestrare modelli di testing delle carte per rilevare automaticamente gli attacchi. Questi modelli attivano le richieste di autenticazione solo quando è in corso un attacco, quindi il CAPTCHA non viene quasi mai visualizzato da utenti reali, ma solo dai bot. Questo ha consentito alle attività che utilizzano Stripe Checkout di ridurre il testing delle carte di un ragguardevole 80%, con un impatto quasi inesistente sulla conversione.

Tieni presente che puoi anche scrivere regole personalizzate di tipo "Bloccare in caso di rifiuto per più di tre volte da un determinato indirizzo IP" per ridurre gli attacchi di testing delle carte.

Estrazione di valore

Carte di credito rubate (comportamento novità)

In questo vettore di frode, l'attore fraudolento utilizza la carta rubata convalidata sul proprio dispositivo personale o su un dispositivo utilizzato per commettere frodi.

Questo vettore viene in genere violato attraverso attacchi di massa con script o su scala più ridotta attraverso frodi mirate. In ogni caso, utilizzando gli attributi delle regole che misurano la novità di un account su Stripe, ad esempio hours_since_email_first_seen_on_stripe, in combinazione con risk_score e altre funzionalità, è possibile tenere sotto controllo questi nuovi titolari di carta. Inoltre, limitazioni della velocità su IP, email e carte possono proteggere ulteriormente gli esercenti da attacchi su vasta scala in cui gli attori fraudolenti cercano di monetizzare le credenziali rubate il più velocemente possibile.

Carte di credito rubate (comportamento mascheramento)

In questo vettore di frode, l'attore fraudolento utilizza la carta rubata convalidata sul suo dispositivo personale o su un dispositivo utilizzato per commettere una frode oppure ha violato un account in abbonamento ottenendo l'accesso ai dati della carta di credito memorizzati nell'account.

L'attore fraudolento farà del suo meglio per mascherare la sua presenza:

• Usando lo stesso nome delle precedenti transazioni effettuate

• Usando lo stesso indirizzo di fatturazione delle precedenti transazioni effettuate

• Usando una VPN per cercare di far credere di essere il titolare della carta. Può usare una VPN nella stessa città e talvolta anche nello stesso isolato

• Cambiando solo un dettaglio minore, come l'indirizzo email o il numero di telefono

• Modificando l'indirizzo di spedizione rispetto alle transazioni precedenti, nel caso di un bene fisico, con potenzialmente una grande distanza tra l'indirizzo di fatturazione e quello di spedizione. Questo è un segnale difficile da intercettare

Il comportamento di mascheramento descritto sopra rende difficile capire chi stia effettivamente effettuando la transazione, il titolare della carta oppure un attore malintenzionato che ha compromesso l'account. Questo spesso significa che questo tipo di frode passa inosservato più a lungo, sia per l'esercente che per il titolare originario della carta.

Anche in questo caso la strategia è la stessa: l'attore fraudolento cercherà di estrarre più valore possibile dalle credenziali rubate. Le regole che utilizzano funzionalità di limitazione della velocità, combinate con riskscore, errori di cvccheck o errori di zip_check, possono aiutare a proteggere da questo comportamento.

Altre pratiche migliori

Di seguito sono riportate altre pratiche migliori per ottimizzare la scrittura delle regole in Radar.

Importanza dell'utilizzo di Stripe.js

• Includi stripe.js nel percorso di pagamento completo per la migliore segnalazione di frodi
  
• Per ottenere il massimo da Radar senza compromettere il tempo di caricamento della pagina, carica stripe.js in modalità asincrona sulle pagine non per il pagamento
  
• Il modo più semplice è inserirlo dopo lo script dei tag di Google Analytics
  
• La dimensione del bundle stripe.js compresso è 29,6 KB (formato gzip)
  
  • In futuro radar.js potrà essere incluso separatamente da stripe.js
    

Conclusione

Le regole possono essere uno strumento straordinariamente potente per personalizzare la tua protezione antifrode. Implementando una logica personalizzata, sulla base di alcune delle migliori pratiche descritte in questa guida, puoi creare in Radar una configurazione di prevenzione delle frodi specifica per le tue esigenze aziendali.

Se vuoi sapere di più su Radar for Fraud Teams, leggi qui.

Se sei già un utente di Radar for Fraud Teams, consulta la pagina delle regole nella tua Dashboard per iniziare a scrivere regole.

Altre note

Radar per le piattaforme

La tua attività riguarda una piattaforma che utilizza Stripe Connect? In questo caso, le eventuali regole create si applicano solo ai pagamenti creati nell'account della piattaforma (in termini Connect, si applicano agli addebiti indiretti o per conto di).
I pagamenti creati direttamente nell'account connesso sono soggetti alle regole di quell'account.

Radar per Terminal

Gli addebiti di Terminal non sono controllati da Radar. Questo significa che se usi Terminal, puoi scrivere regole basate sulla frequenza IP senza preoccuparti di bloccare i tuoi pagamenti di persona.