La valutazione del rischio di frode è un processo continuo di identificazione di vettori, modelli e scenari di attacco e mitigazione. Lavorando a stretto contatto con gli utenti, il nostro team di servizi professionali ha osservato che le attività che agiscono in modo più efficace hanno spesso analisti di frodi e di dati che lavorano insieme, utilizzando una combinazione di Stripe Radar for Fraud Teams e prodotti Stripe Data come Stripe Sigma o Stripe Data Pipeline per identificare sia modelli di frode comuni, sia modelli specifici per la loro attività.

Radar for Fraud Teams aiuta a rilevare e prevenire le frodi e permette di creare una configurazione delle frodi su misura, unica per la tua attività, con regole, reportistica e revisioni manuali personalizzate. Stripe Sigma è una soluzione di reportistica che rende disponibili tutti i dati transazionali, di conversione e dei clienti all'interno di un ambiente interattivo nella dashboard di Stripe. Data Pipeline fornisce gli stessi dati, ma li invia automaticamente al data warehouse Snowflake o Redshift in modo che sia possibile accedervi insieme agli altri dati dell'attività.

La fluida interazione di questi strumenti consente di supportare i quattro pilastri di un processo di gestione efficace delle frodi: rilevamento, indagine, conferma e perfezionamento, e mitigazione, che illustreremo con maggiori dettagli.

Valore dell'utilizzo di Radar for Fraud Teams con Stripe Sigma o Data Pipeline

L'obiettivo principale dell'utilizzo di Radar for Fraud Teams con Stripe Sigma o Data Pipeline è analizzare i dati di Radar, come i metadati, insieme ai propri dati, tra cui le preautorizzazioni, il percorso dell'utente, la conversione e le informazioni sulla sessione, per separare le transazioni legittime dai comportamenti fraudolenti dei clienti. In questo modo, puoi ottimizzare:

1. Il tempo necessario per gli approfondimenti per il rilevamento e la prevenzione proattivi delle frodi
   
2. Il tempo di reazione per l'elaborazione di regole di prevenzione e rilevamento
   
3. Il costo della frode, che include rimborsi, commissioni di contestazione, abbandono dei clienti e pagamenti rifiutati dalla società emittente
   

Il nostro Stato delle frodi online evidenzia la costi fissi di gestione dei processi manuali di revisione e che "più grandi sono [le aziende], minore è la frazione di transazioni che rivedono". Grazie all'automazione di questi processi, puoi liberare i tuoi analisti delle frodi per dedicare più tempo all'identificazione di nuovi vettori di attacco e allo sviluppo di regole preventive e investigative. Ciò significa che puoi trovare un migliore equilibrio tra il blocco del traffico fraudolento e la riduzione dei disagi per i clienti legittimi (abbandono).

Processo di base di gestione delle frodi per le transazioni

Supponiamo che sia stato definito un processo di base di gestione delle frodi per le transazioni, che include i pilastri Rilevamento, Indagine, Conferma e Perfezionamento e mitigazione ed è incluso in un framework più ampio di gestione dei rischi.

• Rilevamento, noto anche come identificazione, previsione o risposta all'incidente, è la scoperta di un punto dati che merita ulteriori indagini. Il rilevamento può essere manuale (ad esempio, durante un incidente), semi-automatizzato (tramite regole di indagine o monitoraggio rispetto alla linea di base), automatizzato (tramite machine learning o rilevamento delle anomalie) o attivato dall'esterno (ad esempio, feedback dei clienti o contestazioni). Per quanto riguarda il rilevamento, il machine learning di Radar è in grado di trovare automaticamente i modelli fraudolenti più comuni, mentre Stripe Sigma può aiutarti a trovare modelli specifici per la tua attività.
  
• Indagine, o analisi esplorativa, è la valutazione di pagamenti o comportamenti sospetti per comprendere meglio l'impatto sull'attività; questo spesso comporta la verifica rispetto a dati più ampi per eliminare il rumore. In genere gli analisti delle frodi utilizzano la coda di revisione Radar o la dashboard di Stripe Payments per l'indagine.
  
• Conferma, della anche modellazione o backtesting, è la generalizzazione del vettore di attacco fraudolento verificato in dimensioni e modelli candidati. Ciò riguarda anche la convalida e la valutazione d'impatto sulla base dei dati passati e rispetto ad altre norme. Il backtesting e la simulazione delle funzionalità di Radar può aiutare gli analisti delle frodi a farlo, ma i tecnici dei dati possono utilizzare Stripe Sigma per una gamma più ampia di scenari.
  
• Perfezionamento e mitigazione, a volte indicato come azione o confinamento, è l'implementazione del modello, ovvero la mappatura su predicati delle dimensioni e delle caratteristiche significative delle regole Radar per prevenire, monitorare o reindirizzare la frode. Tradizionalmente, queste sarebbero state regole preventive statiche, ma ora che il machine learning è una controparte importante per gli esseri umani e l'obiettivo è aumentare la precisione, raffinamento è il termine più appropriato. Questo di solito comprende regole di blocco o liste in Radar.
  

Un'implementazione semplice di questo processo potrebbe includere cicli iterativi, ad esempio controlli giornalieri, sprint o versioni di configurazione del rilevamento delle frodi basate su regole. Tuttavia, considerato che i tempi di ciclo possono essere diversi e i cicli di feedback possono verificarsi in simultanea, preferiamo considerarlo un processo continuativo.

Successivamente esamineremo in dettaglio ciascuno di questi quattro pilastri nel contesto di uno scenario ipotetico e mostreremo come possono aiutarti Radar for Fraud Teams e Stripe Sigma o Data Pipeline.

Scenario

Nel nostro scenario ipotetico analizzeremo un comportamento rilevato per un periodo di tempo, anziché un picco improvviso.

Supponi di avere un'attività di e-commerce. Hai configurato il monitoraggio dei webhook nella tua suite di osservabilità che traccia vari grafici delle tendenze di pagamento in tempo reale. Negli ultimi giorni hai notato un costante aumento del volume di pagamenti rifiutati da un circuito di carte denominato "Mallory" per un prodotto solitamente non venduto nell'area geografica in cui questo circuito è di utilizzo comune. (Nota: Mallory è un circuito di carte fittizio scelto per rendere più reale questo scenario. Potrebbe, ad esempio, trattarsi di un circuito non incluso nella rete Enhanced Issuer Network.) Questo incremento non è giustificato da promozioni o altri incidenti, quindi il tuo team decide di indagare per scoprire cosa sta accadendo e decidere come procedere.

Rilevamento

Le regole predefinite di Stripe si avvalgono del machine learning per prevedere, rilevare e bloccare un numero considerevole di pagamenti fraudolenti. La dashboard dei dati analitici di Radar può offrirti una panoramica generale delle tendenze per le frodi. Inoltre, per le aziende che devono controllare in maggiore dettaglio i pagamenti da rivedere, consentire o bloccare, le regole sono uno strumento molto efficace per personalizzare la protezione contro le frodi.

Prima di poter avviare il rilevamento di nuovi schemi fraudolenti, dovrai avere a disposizione i dati di riferimento dei segnali predittivi, come le prestazioni delle regole esistenti. In altri termini, ti serve sapere cosa è "normale" per la tua attività o cosa contraddistingue una transazione "valida". Questo è l'ambito della collaborazione tra analisti delle frodi e tecnici dei dati, che potrebbero lavorare anche con i team DevOps e la relativa suite di osservabilità. Nel nostro scenario ipotetico, l'aumento delle transazioni rifiutate dai tipi di carta "Mallory" viene rilevato tramite monitoraggio continuativo.

Tabelle Stripe Sigma con dati relativi alle frodi

Per rilevare i modelli emergenti, è necessario innanzitutto stabilire le prestazioni di base con funzionalità come la frequenza di rifiuti/autorizzazioni dei pagamenti della società emittente e la frequenza dei blocchi Radar. Successivamente, consigliamo di eseguire una query delle contestazioni per frode, degli avvisi precoci di frode (Record di frode dell'emittente) e dei pagamenti di transazioni ad alta velocità, dei rifiuti elevati della società emittente, oppure dei punteggi di rischio elevati di Radar. L'ideale sarebbe programmare la query per un'esecuzione giornaliera sui dati disponibili, visualizzando tutte le dashboard con i dati passati, inclusi i rifiuti settimanali e mensili, senza nemmeno dover eseguire manualmente una query in Stripe Sigma o nel data warehouse. Questo accelererà i tempi di risposta agli incidenti.

Ecco le tabelle più rilevanti:

I tuoi analisti aziendali o delle frodi dovrebbero avere le idee chiare sulle dimensioni di dettaglio aggiuntive che potrebbe essere importante valutare in base al dominio della tua attività. La tabella degli attributi delle regole di Radar in Radar for Fraud Teams contiene informazioni dettagliate sulle transazioni esistenti valutate da Radar, ma la cronologia non risale a prima di aprile 2023 e non include i metadati e i risultati finali. In precedenza avresti eseguito le query su questi campi:

La nuova tabella degli attributi delle regole di Radar tiene traccia delle stesse dimensioni e di molte altre per ogni transazione valutata da Radar con il nome esatto degli attributi di Radar. Ad esempio, puoi tenere traccia di tendenze relative alla velocità come name_count_for_card_weekly.

Esistono modi diversi per visualizzare le tendenze, ma un semplice grafico a linee pivot per ogni dettaglio è una buona soluzione per eseguire facilmente confronti con altri fattori. Quando si passa alla fase Indagine, può essere utile combinare dettagli diversi. Ecco una tabella di esempio che mostra i dettagli dei segmenti di prodotto per l'aumento delle transazioni rifiutate dai tipi di carta "Mallory":

Potresti anche visualizzarli in questo modo nel tuo strumento per fogli di calcolo preferito:

Esaminiamo più da vicino un esempio di query Sigma o Data Pipeline per ottenere i dati di riferimento. Nella query seguente i tassi giornalieri di contestazioni, rifiuti, blocchi e altri dati sono visualizzati come colonne separate. Durante le fasi di rilevamento e indagine, i dati per esteso, sparsi in colonne separate, sono spesso più semplici da visualizzare. Così è anche più facile mappare in seguito le colonne sui predicati Radar. I tuoi analisti dei dati potrebbero però preferire un formato verticale e denso per l'analisi esplorativa durante la fase di indagine, o il machine learning nelle fasi di conferma e perfezionamento e mitigazione.

In questo esempio includiamo i metadati per il pagamento in modo da visualizzare i dettagli in base al segmento del prodotto. In base al nostro scenario, nell'approccio esteso avremmo bisogno di query simili per il circuito della carta ("Mallory") e il tipo di finanziamento. I tentativi di ripetizione vengono qui deduplicati per concentrarsi sugli intent effettivi e ottenere una migliore percezione dell'ordine di grandezza. Abbiamo scelto di eseguire la deduplicazione in base ai payment intent. Nelle integrazioni più approfondite si potrebbe inviare un campo (ad esempio l'ID dell'ordine nei metadati) per garantire la deduplicazione nell'intero percorso dell'utente. Questo esempio mostra come puoi migliorare la precisione delle misure antifrode con l'aggiunta di un altro fattore. Nel nostro scenario si tratterebbe del segmento del prodotto "carte regalo". Più avanti, nella sezione di perfezionamento e mitigazione torneremo sui modi per migliorare la precisione.

Questa query non include la tempistica effettiva della contestazione, che è un indicatore del ritardo, ma abbiamo incluso alcuni indicatori di esempio, ad esempio i tentativi come indicatore di test delle carte. Con questa query otteniamo in modo semplice alcune metriche giornaliere:

• Volume di addebiti, sia il valore deduplicato, sia quello grezzo: ad esempio, 1.150 addebiti al giorno, dei quali 100 vengono rifiutati e 50 bloccati da Radar, su 1.000 payment intent.
  
• Tasso di autorizzazione: in questo esempio, il 90% per gli addebiti, perché i pagamenti bloccati non passano alla società emittente, e il 100% per i payment intent, perché alla fine tutti i tentativi successivi hanno esito positivo.
  
• Tasso di rischio elevato e di blocco: in questo caso sarebbe dell'1,6% (anche tutti i 50 rischi elevati sono stati bloccati).
  
• Tasso di contestazione retrogrado per i pagamenti dallo stesso periodo: ad esempio, sono stati contestati 5 addebiti su 1.000. Il numero per ogni giorno di pagamento aumenterà con l'arrivo di ulteriori contestazioni, perciò includiamo il tempo di esecuzione della query per tenere traccia delle variazioni.
  

Come già segnalato, abbiamo semplificato queste query per una migliore leggibilità. Questa query avrebbe in realtà ancora più dimensioni, ad esempio, tendenze, deviazioni o differenze di perdita.

Abbiamo anche incluso un esempio di media mobile di 30 giorni utilizzando una funzione finestra. Gli approcci più complessi, come l'esame dei percentili anziché delle medie per identificare gli attacchi con coda lunga, sono applicabili ma raramente necessari per il rilevamento iniziale delle frodi, dato che le linee di tendenza sono più importanti di valori con precisione perfetta.

Quando i dati di riferimento sono chiari, puoi iniziare a tenere traccia di anomalie e tendenze per indagare, ad esempio, sull'aumento del tasso di frode o di blocco da un determinato Paese o metodo di pagamento (nel nostro scenario ipotetico si tratterrebbe del circuito della carta "Mallory"). Le indagini sulle anomalie vengono in genere condotte tramite i report o le analisi manuali nella dashboard oppure con query ad hoc in Sigma.

Indagine

Quando gli analisti trovano un'anomalia su cui indagare, il passaggio successivo prevede l'esecuzione di una query in Sigma, o nel data warehouse tramite Data Pipeline, per esaminare i dati e formulare un'ipotesi. È opportuno includere alcune dimensioni di dettaglio in base alle ipotesi formulate, ad esempio i metodi di pagamento (utilizzo delle carte), il canale o la superficie (metadati), il cliente (reputazione) o i prodotti (categoria di rischio) per cui esiste una tendenza per le frodi. In seguito, nella fase Conferma, queste dimensioni potrebbero essere chiamate "funzioni" e verranno mappate sui predicati di Radar.

Riprendiamo ipotizzando che un volume elevato di transazioni con carte prepagate "Mallory" abbia percentuali di frodi più alte, situazione che puoi rappresentare come dimensione di raggruppamento su cui ruotare con il tuo strumento di analisi. In questa fase si eseguono in genere iterazioni e messe a punto della query, quindi è una buona idea includere vari predicati candidati come versioni ridotte o estese delle ipotesi, rimuovendo le funzionalità minori per valutarne l'impatto. Ad esempio:

Con questo approccio puoi farti un'idea dell'ordine di grandezza per dare priorità all'impatto. La tabella indica con una ragionevole sicurezza che la regola candidata 3 sembra possa intercettare le transazioni fraudolente in eccesso. Una valutazione più sofisticata sarebbe basata su accuratezza, precisione o richiamo. È possibile creare un output simile a questo con la query seguente.

In questa query abbiamo rimosso la deduplicazione per la leggibilità, ma abbiamo incluso il tasso di contestazione e il tasso di preavvisi di frode, importanti per i programmi di monitoraggio dei circuiti delle carte. Questi sono indicatori di lagging, tuttavia, e in questa query semplificata ne teniamo traccia solo in modalità retrograda. Abbiamo anche incluso esempi di pagamento arbitrari per il controllo incrociato e per un'indagine più approfondita degli schemi individuati nella query. Parleremo di questo aspetto in maggiore dettaglio più avanti.

Si potrebbero distribuire metriche aggiuntive in un istogramma per identificare i cluster, che possono essere utili per definire le regole di velocità utilizzabili per la limitazione della velocità (ad esempio, total_charges_per customer_hourly).

L'identificazione delle tendenze tramite l'analisi con istogramma è un modo eccellente per comprendere il comportamento dei clienti desiderato per l'intero ciclo di vita e lungo il funnel di conversione. Sarebbe troppo complesso aggiungere questa analisi nella query precedente, ma ecco un semplice esempio di come eseguire questa operazione senza una logica complessa di finestra scorrevole, supponendo che i tuoi metadati includano il tipo di cliente, ad esempio gli utenti guest:

Nel nostro scenario, è possibile che tu preferisca evitare di bloccare tutte le carte prepagate "Mallory", ma che tu voglia comunque identificare con certezza altri fattori di rischio correlati. Questa query per la velocità potrebbe consentire, ad esempio, di evitare con maggiore sicurezza il blocco di clienti guest a bassa frequenza.

Un modo semplice per indagare consiste nel guardare i campioni direttamente nella dashboard tramite la vista "Pagamenti correlati", per comprendere il comportamento, ovvero il vettore di attacco o il modello fraudolento, e gli approfondimenti Radar sui rischi associati. Ecco perché abbiamo incluso esempi di pagamento arbitrari nella query precedente. In questo modo puoi trovare anche pagamenti più recenti che non sono ancora disponibili in Stripe Sigma. Un modo più difensivo e di alto livello consisterebbe nel modellare la tua ipotesi come regola di revisione che consente ancora i pagamenti ma li indirizza agli analisti per la revisione manuale. Alcuni clienti lo fanno per prendere in considerazione il rimborso dei pagamenti al di sotto della commissione di contestazione mentre blocca quelli al di sopra.

Conferma

Proseguendo, supponiamo che il modello che hai identificato non sia semplice, non possa essere mitigato da rimborso e blocco del cliente fraudolento e non rientri semplicemente in un elenco di blocco predefinito.

Dopo aver identificato e dato priorità a un nuovo modello da affrontare, è necessario analizzare il suo potenziale impatto sui ricavi legittimi. Questo non è un banale problema di ottimizzazione, perché il livello ottimale di frodi è diverso da zero. Tra tutti gli svariati modelli candidati, scegli il modello che rappresenta il compromesso migliore per la tua propensione al rischio, sia per semplice grandezza, sia per precisione e richiamo. Questo processo viene a volte chiamato backtesting, soprattutto quando le regole vengono prima scritte e poi convalidate rispetto ai dati. È possibile eseguire questa operazione anche al contrario, ovvero individuando prima i modelli, quindi scrivendo le regole. Ad esempio, invece di scrivere una regola per ogni Paese, puoi scrivere una regola come questa, che rende più facile la conferma:

Block if :card_funding: = 'prepaid and :card_country: in @preaid_card_countries_to_block

La query presentata in precedenza nella sezione Indagine potrebbe anche essere utilizzata come modello, nonostante verrebbero enfatizzati valori diversi. Approfondiremo questo argomento più avanti nella sezione dedicata alle tecniche di perfezionamento e mitigazione.

Mappatura da schema Stripe Sigma a regole Radar

È il momento di trasferire le query esplorative da Stripe Sigma o Data Pipeline per aiutarti a mappare le regole Radar su Stripe Sigma per il backtesting. Di seguito sono riportate alcune mappature comuni, supponendo che tu stia inviando a Radar i segnali giusti:

Le ultime due voci, risk_level e risk_score, non sono uguali alle altre, perché il modello di machine learning stesso è derivato dagli altri fattori. Invece di scrivere regole eccessivamente complesse, ti consigliamo di ricorrere alle funzionalità di machine learning di Radar. Approfondiremo questo argomento nella sezione Perfezionamento tramite machine learning.

La nuova tabella degli attributi delle regole di Radar tiene traccia delle stesse dimensioni e di molte altre per ogni transazione effettivamente valutata da Radar con il nome esatto degli attributi di Radar.

La tabella qui sopra mostra il set standard di attributi, omettendo intenzionalmente i segnali che dovresti personalizzare per il tuo percorso dei clienti, come sessioni Radar o metadati.

In base all'indagine precedente, supponiamo che tu sia arrivato a una regola simile alla seguente:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :amount_in_usd: > 20 and ::CustomerType:: = 'guest' and :total_charges_per_customer_hourly: > 2

Il passaggio successivo consiste nel confermare l'impatto di questa regola sulle tue transazioni di pagamento effettive. In genere, questa operazione verrebbe eseguita tramite regole di blocco. Leggi la nostra guida Radar for Fraud Teams: Nozioni di base sulle regole di Radar per indicazioni sulla sintassi corretta per scrivere le regole. Un modo semplice per testare una regola di blocco consiste nel crearla in modalità di test e creare pagamenti di test manuali per verificare che funzioni come previsto.

È possibile eseguire il backtesting in Radar sia delle regole di blocco che delle regole di revisione utilizzando la funzionalità di simulazione di Radar for Fraud Teams.

Uno dei vantaggi dell'utilizzo delle simulazioni di Radar for Fraud Teams è il fatto che venga considerato l'impatto di altre regole esistenti. La manutenzione delle regole non è un argomento centrale di questa guida, ma anche la rimozione e l'aggiornamento delle regole dovrebbero fare parte del processo di miglioramento continuo. In termini generali, il numero di regole disponibili dovrebbe essere sufficientemente contenuto da consentire che ogni regola sia atomica e possa essere monitorata utilizzando le query di riferimento sviluppate nelle fasi Rilevamento e Indagine, oltre a poter essere sottoposta a backtesting in modo chiaro senza rischi di effetti collaterali, ad esempio la regola 2 funziona solo perché la regola 1 esclude qualcos'altro.

A tale scopo puoi anche utilizzare le regole di revisione anziché le regole di blocco, argomento che verrà trattato nella prossima sezione.

Perfezionamento e mitigazione

Infine, dopo aver testato le regole di blocco, applicherai il modello per la prevenzione, il monitoraggio o il reindirizzamento della frode. Questa fase viene detta Perfezionamento perché implica il miglioramento della precisione delle misure antifrode nel loro complesso, in particolare insieme al machine learning. Per migliorare la precisione, puoi implementare svariate tecniche. Questo passaggio, noto anche come contenimento o mitigazione, viene a volte eseguito in contemporanea con la fase Conferma e in questo caso, anziché utilizzare regole di revisione, test A/B (metadati) o simulazioni per valutare il modello, bloccherai immediatamente gli addebiti sospetti per mitigare il rischio immediato.

Anche se ti sei già attivato, esistono alcune tecniche per perfezionare il modello sviluppato nei passaggi 1-3 e migliorare i risultati nel tempo:

Perfezionamento tramite regole di revisione

Se vuoi evitare il rischio di un tasso più alto di falsi positivi, con potenziale impatto sui ricavi, puoi scegliere di implementare regole di revisione. Anche se si tratta di un processo più manuale che potrebbe complicare l'esperienza del cliente, le regole di revisione possono consentire alla fine il completamento delle transazioni più legittime. Puoi anche aggiungere una limitazione, sotto forma di regole di velocità, nelle regole di blocco esistenti per transazioni più lente. Il test A/B è un'opzione più avanzata per l'utilizzo delle regole di revisione, particolarmente utile per gestire il numero totale di casi nella coda di revisione. Puoi sfruttare i metadati dai tuoi pagamenti per iniziare a consentire una piccola parte del traffico durante il test A/B, ad esempio il traffico da clienti noti o semplicemente utilizzando un numero casuale. Consigliamo di aggiungere questi criteri alle regole di blocco, anziché creare regole di consenso, perché queste ultime hanno la priorità rispetto ai blocchi e complicano il monitoraggio delle prestazioni della regola di blocco nel tempo.

Ottimizzazione delle regole monitorandone le prestazioni

Per monitorare le prestazioni delle regole, è possibile controllare l'oggetto risultato dell'addebito nell'API Payment Intents, in particolare l'oggetto regola. Allo stesso modo, in Stripe Sigma è possibile utilizzare i campi charges.outcome_rule_id,charges.outcome_type, epayment_intents.review_id per l'analisi. Ecco un esempio di come tener traccia delle prestazioni di una regola in Stripe Sigma utilizzando l'apposita tabella delle decisioni sulle regole Radar:

Perfezionamento tramite machine learning

Il passaggio successivo dopo il blocco di un attacco immediato prevede spesso il perfezionamento iterativo del regola insieme all'applicazione del machine learning per ridurre i falsi positivi, in modo da consente il traffico più legittimo e quindi i ricavi.

Prendiamo ad esempio il blocco di BIN o IIN (Issuer Identification Number). Durante un attacco di testing delle carte, potresti avere aggiunto temporaneamente un BIN a un elenco di blocco, in modo da consentire alle società emittenti di correggere i problemi. Il blocco immediato di una società emittente potrebbe, tuttavia, ridurre i tuoi ricavi. Un approccio più raffinato prevede indagini più accurate nel tempo e il perfezionamento del modello. Questo è un buon momento per rivedere la procedura per scrivere regole efficaci e per valutare il rischio, in particolare il punteggio di rischio di Radar. A livello generale, consigliamo di affiancare il machine learning di Radar al tuo intuito. Invece di utilizzare una sola regola per bloccare tutte le transazioni ad alto rischio, la combinazione del punteggio con regole manuali che rappresentano un modello o uno scenario di rischio consente spesso di trovare un migliore equilibrio tra il blocco del traffico dannoso e la realizzazione dei ricavi. Ad esempio:

Block if :card_funding: = 'prepaid' and :card_funding: = 'mallory' and :card_country: in @high_risk_card_countries_to_block and :risk_score: > 65 and :amount_in_usd: > 10

Perfezionamento tramite 3DS

Come accennato in precedenza, anche se in questa guida non viene presentata in modo dettagliato l'autenticazione 3DS (3D Secure), ti consigliamo di prenderla in considerazione nell'ambito della tua strategia di mitigazione del rischio. Ad esempio, anche se la traslazione di responsabilità potrebbe ridurre le commissioni di contestazione per le transazioni fraudolente, queste transazioni vengono comunque considerate dai programmi di monitoraggio delle carte e hanno effetti sull'esperienza d'uso. Invece di utilizzare un valore fisso, potresti perfezionare questa regola sostituendo "blocca tutti gli addebiti rilevanti" con "richiedi autenticazione 3DS":

Request 3DS if :card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = 'true' or :is_disposable_email: = 'true'

Potrai quindi usare una regola per bloccare le carte che non completano l'autenticazione o che non forniscono la traslazione di responsabilità per altri motivi:

Block if (:card_country: in @high_risk_card_countries_to_block or :ip_country: in @high_risk_card_countries_to_block or :is_anonymous_ip: = 'true' or :is_disposable_email: = 'true') and :risk_score: > 65 and :has_liability_shift: != 'true'

Perfezionamento tramite elenchi

Gli elenchi predefiniti o gli elenchi personalizzati possono essere un metodo efficace per bloccare un attacco durante un incidente, senza correre il rischio di modificare le regole bloccando, ad esempio, un cliente, un dominio email o un paese della carta fraudolento. Parte della fase Perfezionamento richiede di decidere quali schemi devono essere una regola, quali devono modificare un predicato di regola e quali possono semplicemente aggiungere valore a un elenco esistente. Le regole di emergenza (o break-glass) sono un buon esempio di soluzione provvisoria durante un incidente, perfezionabile in seguito in un elenco o in una modifica a una regola esistente.

Processo di feedback

Perfezionamento significa anche tornare all'inizio e monitorare la prestazioni delle regole e gli schemi di frode. La qualità del monitoraggio dipende dalle basi di riferimento definite e da singole modifiche atomiche per ottenere tracciabilità, precisione e richiamo ottimali del backtesting. Per questo motivo, consigliamo di modificare le regole e i predicati solo in distribuzioni chiare e distinte, affidandosi altrimenti a elenchi, revisioni e blocchi e rimborsi proattivi.

I vantaggi di Stripe

Radar per le piattaforme

La tua piattaforma utilizza Stripe Connect? In questo caso, qualsiasi regola creata si applica solo ai pagamenti creati per l'account della piattaforma, ovvero gli addebiti indiretti o
per conto di, secondo la terminologia di Connect. I pagamenti creati direttamente nell'account Connect sono soggetti alle regole di tale account.

Radar per Terminal

Gli addebiti di Stripe Terminal non vengono esaminati da Radar. Se utilizzi Terminal, questo significa che puoi scrivere regole basate sulla frequenza IP senza doverti preoccupare di bloccare i tuoi pagamenti di persona.

Servizi professionali di Stripe

Il team dei servizi professionali di Stripe può aiutarti a implementare un processo di gestione delle frodi continuamente migliorabile. Dal consolidamento dell'integrazione attuale al lancio di nuovi modelli aziendali, i nostri esperti forniscono indicazioni per consentirti di sviluppare ulteriormente la soluzione Stripe esistente.

Conclusione

In questa guida abbiamo visto come è possibile utilizzare Sigma o Data Pipeline per creare sia una base di riferimento, sia diversi modelli di frode che rappresentano scenari e schemi di attacco, che solo tu e la tua attività potete giudicare. Abbiamo anche illustrato come puoi estendere e mettere a punto Radar per reagire a una più ampia gamma di transazioni fraudolente in base a regole personalizzate.

Le frodi nei pagamenti sono in continua evoluzione e anche questo processo deve evolversi in modo continuativo per restare al passo, come abbiamo descritto nel modello Rilevamento, Indagine, Conferma e Perfezionamento e mitigazione. Eseguire questi cicli su base continuativa con un ciclo di feedback veloce dovrebbe consentirti di dedicare meno tempo a reagire agli incidenti e più tempo alla definizione di una strategia proattiva per le frodi.

Puoi saperne di più su Radar for Fraud Teams qui. Se sei già un utente di Radar for Fraud Teams, consulta la pagina Regole nella dashboard per iniziare con la scrittura delle regole.

Puoi saperne di più su Stripe Sigma qui e su Stripe Data Pipeline qui.