La valutazione del rischio di frode è un processo continuativo che include l'identificazione dei vettori, degli schemi e degli scenari di attacco, nonché la relativa mitigazione. Grazie alla stretta collaborazione con gli utenti, il nostro team di servizi professionali ha appurato che le aziende che gestiscono questi aspetti nel modo più efficace spesso possono contare sulla collaborazione tra analisti delle frodi e analisti dei dati, che usano in combinazione Stripe Radar for Fraud Teams e prodotti per i dati di Stripe come Stripe Sigma o Stripe Data Pipeline per identificare sia gli schemi di frode comuni che quelli specifici della loro attività.

Radar for Fraud Teams supporta il rilevamento e la prevenzione delle frodi e offre la possibilità di creare una configurazione per la gestione delle frodi su misura e specifica per ogni azienda, con regole personalizzate, reportistica e revisioni manuali. Sigma è una soluzione di reportistica per rendere tutti i dati relativi a transazioni, conversioni e clienti disponibili all'interno di un ambiente interattivo nella Dashboard Stripe. Data Pipeline offre gli stessi dati, ma li invia automaticamente al data warehouse Snowflake o Redshift, in modo che siano accessibili insieme agli altri dati aziendali.

La fluida interazione di questi strumenti consente di supportare i quattro pilastri di un processo di gestione delle frodi efficace: Rilevamento, Indagine, Conferma e Perfezionamento e mitigazione, che illustreremo in maggiore dettaglio.

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

L'obiettivo principale dell'utilizzo di Radar for Fraud Teams con Sigma o Data Pipeline è l'analisi dei dati di Radar, come i metadati, insieme ai dati personali, incluse le informazioni sulla preautorizzazione, il percorso dell'utente, la conversione e le informazioni sulla sessione, per distinguere le transazioni legittime da comportamenti dei clienti fraudolenti. Puoi così 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 report La situazione delle frodi online pone l'accento sul sovraccarico operativo dei processi di revisione manuali e sottolinea che "più sono grandi [le aziende] e minore è la frazione di transazioni che vengono riviste." L'automazione di questi processi ti permette di ridurre il carico di lavoro degli analisti delle frodi, in modo che possano dedicare più tempo all'identificazione di nuovi vettori di attacco e all'elaborazione di regole di prevenzione e rilevamento. Potrai così ottenere un migliore equilibrio tra il blocco del traffico fraudolento e la riduzione dell'abbandono per i clienti legittimi.

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.

• Il rilevamento, un processo noto anche come identificazione, previsione o risposta agli incidenti, è l'individuazione di un punto dati che giustifica ulteriori indagini. Il rilevamento può essere manuale (ad esempio, durante un incidente), semi-automatizzato (tramite regole di rilevamento o il monitoraggio in base ai tuoi dati di riferimento), automatizzato (tramite machine learning o rilevamento delle anomalie) o con attivazione esterna (ad esempio, feedback dei clienti o contestazioni). Per il rilevamento, le funzionalità di machine learning di Radar consentono di individuare automaticamente gli schemi di frode comuni, mentre Sigma ti aiuta a trovare gli schemi specifici della tua attività.
  
• Con indagine, o analisi esplorativa, si intende la valutazione dei pagamenti o dei comportamenti sospetti per una migliore comprensione dell'impatto sull'azienda. Questo processo comporta spesso l'esecuzione di verifiche su una base di dati più ampia per escludere quelli non significativi. Per condurre le indagini, gli analisti delle frodi useranno in genere la coda di revisione di Radar o la Dashboard Payments di Stripe.
  
• La conferma, un processo noto anche come modellazione o backtesting, è la generalizzazione del vettore di attacco della frode verificato in dimensioni e modelli candidati. Il processo include anche la convalida e la valutazione dell'impatto tramite dati storici e in base ad altre regole. La funzionalità di backtesting e simulazione di Radar può essere utile a questo scopo per gli analisti delle frodi, ma i data engineer possono utilizzare Sigma per una più ampia gamma di scenari.
  
• Con perfezionamento e mitigazione, un processo noto a volte come azione o confinamento, si intende l'implementazione del modello, ovvero il mapping di dimensioni e funzionalità significative con i predicati per le regole Radar allo scopo di prevenire, monitorare o reindirizzare le frodi. Tradizionalmente si sarebbe parlato di regole di prevenzione, ma ora che il machine learning rappresenta un'alternativa importante all'intervento umano e l'obiettivo è ottenere una maggiore precisione, il termine "perfezionamento" risulta più appropriato. Il processo includerebbe in genere regole o elenchi di blocco in Radar.
  

Un'implementazione semplice di questo processo potrebbe includere cicli iterativi, ad esempio controlli giornalieri, sprint o versioni di una configurazione del rilevamento delle frodi basata 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.

Nelle prossime sezioni esamineremo in dettaglio ognuno dei quattro pilastri nel contesto di uno scenario ipotetico per mostrare le potenzialità di Radar for Fraud Teams e 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 di frode, dovrai avere a disposizione dati di riferimento per i segnali predittivi, come le prestazioni delle regole esistenti. In altri termini, ti serve sapere cosa è "normale" per la tua azienda o cosa contraddistingue una transazione "valida". Questo è l'ambito della collaborazione tra analisti delle frodi e data engineer, 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 il monitoraggio continuativo.

Tabelle Sigma con i dati sulle frodi rilevanti

Per rilevare schemi emergenti, sarà prima opportuno stabilire le prestazioni di riferimento con funzionalità come il tasso di autorizzazione/rifiuto della società emittente e il tasso di blocco di Radar. Potrai quindi eseguire query per recuperare le contestazioni fraudolente, preavvisi di frode (Record di frode dell'emittente) e transazioni di pagamento ad alta velocità, con molti rifiuti da parte dell'emittente o con punteggi di rischio Radar elevati. Nel caso ideale, dovrai pianificare l'esecuzione giornaliera di questa query in base ai dati disponibili e visualizzare tutte le dashboard con i dati storici, incluse sezioni settimanali e mensili, senza dover mai eseguire query manualmente in Sigma o nel tuo data warehouse. Il tempo di risposta agli incidenti risulterà così ridotto.

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 l'esempio di una query Sigma o Data Pipeline per ottenere i dati di riferimento. Nella query seguente i tassi giornalieri di contestazione, rifiuto, blocco e altri dati sono visualizzati come colonne separate. Durante le fasi Rilevamento e Indagine, i dati estesi e sparsi in colonne separate sono spesso più semplici da visualizzare. Così è anche più facile mappare le colonne ai predicati Radar in un secondo momento. I tuoi data scientist potrebbero però preferire un formato verticale e denso per l'analisi esplorativa durante la fase Indagine o il machine learning nelle fasi 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 concentrarci 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 "gift cards". Nella sezione Perfezionamento e mitigazione più avanti torneremo sull'argomento dei modi per migliorare la precisione.

Questa query non include i tempi effettivi della contestazione, che sono un indicatore di lagging, ma abbiamo incluso alcuni indicatori di esempio, come la ripetizione dei tentativi come indicatore di testing delle carte. In questa query otteniamo alcune metriche giornaliere con facilità:

• Volume di addebiti, sia il valore deduplicato che 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 i tuoi analisti trovano un'anomalia su cui indagare, il passaggio successivo prevede l'esecuzione di una query in Sigma, o nel tuo data warehouse tramite Data Pipeline, per esplorare i dati e formulare un'ipotesi. Vorrai includere alcune dimensioni di dettaglio in base alle ipotesi formulate, ad esempio le modalità di pagamento (utilizzo della carta), il canale o la superficie (metadati), il cliente (reputazione) o i prodotti (categoria di rischio) per cui esiste una tendenza per la frode. In seguito, nella fase Conferma, queste dimensioni potrebbero essere chiamate "funzionalità" e verranno mappate ai predicati di Radar.

Torniamo all'ipotesi che un volume elevato di transazioni con carte prepagate di "Mallory" abbia tassi di frode più alti, situazione che puoi rappresentare come dimensione di raggruppamento trasformabile tramite pivot 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 la canalizzazione 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 di "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 con bassa frequenza.

Un modo semplice per condurre le indagini consiste nell'esaminare gli esempi direttamente nella Dashboard tramite la visualizzazione "Pagamenti correlati" per ottenere informazioni sul comportamento, ovvero il vettore di attacco o lo schema di frode, e gli approfondimenti sui rischi Radar associati. Ecco perché abbiamo incluso esempi di pagamenti arbitrari nella query precedente. In questo modo puoi anche trovare pagamenti più recenti non ancora disponibili in Sigma. Un approccio più difensivo e high-touch prevederebbe la modellazione dell'ipotesi come regola di revisione, in modo da consentire ancora i pagamenti indirizzandoli però agli analisti per la revisione manuale. Alcuni clienti scelgono questo approccio per valutare il rimborso dei pagamenti inferiori alla commissione di contestazione bloccando invece quelli superiori.

Conferma

Procediamo supponendo che lo schema identificato non sia semplice, non possa essere mitigato rimborsando e bloccando il cliente fraudolento e non rientri semplicemente in un elenco di blocco predefinito.

Dopo aver identificato un nuovo schema a cui dare priorità, dovrai analizzarne il potenziale impatto sui tuoi ricavi legittimi. Non è un problema di ottimizzazione banale, perché l'importo ottimale delle frodi è diverso da zero. Tra tutti i vari candidati, scegli il modello che rappresenta il compromesso migliore per la tua propensione al rischio, semplicemente in base all'ordine di grandezza o in base a precisione e richiamo. Questo processo è noto a volte come backtesting, in particolare quando le regole vengono prima scritte e poi convalidate con i tuoi dati. Puoi anche procedere al contrario, ovvero prima individuare gli schemi e poi scrivere le regole. Ad esempio, invece di scrivere una sola regola per paese, puoi scrivere una regola come questa che semplifica il processo di 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, anche se verrebbero enfatizzati valori diversi. Approfondiremo questo argomento più avanti nella sezione dedicata alle tecniche di perfezionamento e mitigazione.

Mapping di schema Sigma e regole Radar

È giunta l'ora di trasformare le query esplorative da Sigma o Data Pipeline per facilitare il mapping delle regole Radar in Sigma per il backtesting. Ecco alcuni mapping comuni, supponendo che tu stia inviando i segnali corretti a Radar:

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 testing 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 testing 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, puoi controllare l'oggetto charge outcome nell'API Payment Intents, in particolare l'oggetto rule. In modo analogo, in Sigma puoi usare i campi charges.outcome_rule_id, charges.outcome_type e payment_intents.review_id per l'analisi. Ecco un esempio di come monitorare le prestazioni di una regola in Sigma usando la tabella decisioni regola di Radar speciale:

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.

Conclusioni

In questa guida abbiamo visto come è possibile utilizzare Sigma o Data Pipeline per creare sia una base di riferimento che vari modelli di frode che rappresentano scenari e schemi di attacco, che solo tu e la tua azienda 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 alle tue regole personalizzate.

Le frodi per i pagamenti sono in continua evoluzione e anche questo processo deve evolvere 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 trovare altre informazioni su Radar for Fraud Teams qui. Se sei già un utente di Radar for Fraud Teams, vedi la pagina Regole nella tua Dashboard per iniziare a scrivere le tue regole.

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