Avaliar risco de fraude é um processo contínuo de identificar vetores de ataque, padrões e cenários e mitigá-los. Trabalhando junto com usuários, nossa equipe de serviços profissionais observou que as empresas mais eficazes geralmente têm analistas de fraude e de dados atuando lado a lado — usando uma combinação de Stripe Radar for Fraud Teams e produtos da Stripe Data como Stripe Sigma ou Stripe Data Pipeline para detectar tanto padrões comuns quanto padrões específicos do negócio.

O Radar for Fraud Teams ajuda a detectar e prevenir fraudes, permitindo montar uma configuração de segurança exclusiva para seu negócio, com regras personalizadas, relatórios e análises manuais. O Stripe Sigma é uma solução de relatórios que disponibiliza todos os seus dados de transação, conversão e cliente em um ambiente interativo dentro do Dashboard. O Data Pipeline oferece os mesmos dados, mas envia automaticamente ao seu data warehouse (Snowflake ou Redshift), integrando-os com os demais dados do negócio.

Essas ferramentas funcionam de forma integrada para cobrir os quatro pilares de um processo sólido de gestão de fraudes: Detecção, Investigação, Confirmação e Refinamento e mitigação — os quais detalharemos a seguir.

O valor de usar o Radar for Fraud Teams com Stripe Sigma ou Data Pipeline

O objetivo principal de usar o Radar for Fraud Teams junto com o Stripe Sigma ou Data Pipeline é analisar os dados do Radar — como metadados — em conjunto com seus próprios dados, incluindo pré-autorização, jornada do usuário, conversão e informações da sessão, a fim de separar transações legítimas de comportamentos fraudulentos. Assim, você pode otimizar:

1. Tempo para insights a fim de detectar e prevenir fraudes de maneira proativa
   
2. Tempo de reação para criar regras preventivas e de detecção
   
3. Custo das fraudes, que envolve reembolsos, tarifas de disputa, perda de clientes e recusas do emissor
   

Nosso relatório State of online fraud mostra a sobrecarga operacional dos processos de revisão manual e destaca que “quanto maiores as [empresas], menor a fração de transações revisadas”. Ao automatizar esses processos, seus analistas antifraude podem dedicar mais tempo a identificar novos vetores de ataque e criar regras preventivas e de detecção. Isso permite equilibrar melhor o bloqueio de tráfego fraudulento e a redução de atrito para clientes legítimos (churn).

Um processo básico de gerenciamento de fraudes em transações

Vamos supor que você tenha um processo básico de gerenciamento de fraudes em transações envolvendo etapas de detecção, investigação, confirmação, refinamento e mitigação em uma estrutura de risco mais ampla.

• Detecção, também chamada de identificação, previsão ou resposta a incidentes, é a descoberta de um dado que merece investigação adicional. Pode ser manual (ex.: durante um incidente), semi-automatizada (por regras de detecção ou monitoramento em relação à base), automatizada (com machine learning ou detecção de anomalias) ou externa (ex.: feedback de cliente ou disputas). O machine learning do Radar identifica padrões de fraude comuns automaticamente, enquanto o Stripe Sigma ajuda a encontrar padrões específicos ao seu negócio.
  
• Investigação, ou análise exploratória, consiste em avaliar pagamentos ou comportamentos suspeitos para entender melhor o impacto no negócio; normalmente envolve validar com dados mais amplos para eliminar ruídos. Em geral, analistas usam a fila de revisão do Radar ou o Dashboard de Pagamentos da Stripe para investigar.
  
• Confirmação, também chamada de modelagem ou backtesting, é a generalização do vetor de fraude confirmado em dimensões e modelos candidatos. Engloba também a validação e avaliação de impacto com dados passados e contra outras regras. A função de backtesting e simulação do Radar apoia analistas nesse processo, mas engenheiros de dados podem usar o Stripe Sigma em cenários mais diversos.
  
• Refinamento e mitigação, por vezes chamado de ação ou confinamento, é a implementação do modelo — vinculando dimensões e características relevantes a predicados de regra do Radar para prevenir, monitorar ou redirecionar fraudes. Antes, isso se resumia a regras estáticas de prevenção, mas com o machine learning como aliado e o foco em aumentar precisão, o termo Refinamento se torna mais apropriado. Geralmente envolve regras de bloqueio ou listas no Radar.
  

Uma implementação básica pode incluir ciclos iterativos como checagens diárias, sprints ou lançamentos de configurações de detecção de fraude baseadas em regras. Porém, como ciclos podem ter durações distintas e sobrepor feedbacks, é mais adequado encarar como um processo contínuo.

Em seguida, veremos cada um dos quatro pilares com mais detalhe em um cenário hipotético e mostraremos como o Radar for Fraud Teams e o Stripe Sigma ou Data Pipeline podem ajudar.

Nosso cenário

Em nosso cenário hipotético, analisaremos um comportamento que ocorre ao longo de um período, em vez de um pico repentino.

Você tem uma empresa de e-commerce e configurou o webhook de monitoramento em seu pacote de observabilidade para criar vários gráficos de tendências de pagamento em tempo real. Nos últimos dias, os gráficos indicaram um aumento constante no volume de pagamentos recusados de uma bandeira de cartão chamada Mallory para um produto que geralmente não é vendido na região onde essa bandeira é usada. (Observação: Mallory é uma bandeira de cartão fictícia que estamos usando como ilustração nesse cenário e que pode, por exemplo, não estar incluída na Enhanced Issuer Network.) Como não há promoções de vendas ou outros incidentes que possam explicar essa mudança, sua equipe precisa investigar o que está acontecendo e decidir o próximo curso de ação.

Detecção

As regras padrão da Stripe usam machine learning para prever, detectar e bloquear um número substancial de pagamentos fraudulentos. O Dashboard de análises do Radar fornece uma visão geral rápida das tendências de fraude. Para empresas que precisam de mais controle sobre quais pagamentos devem ser revisados, permitidos ou bloqueados, as regras são uma ferramenta poderosa para personalizar a proteção contra fraudes.

Antes de começar a detectar novos padrões de fraudes, é necessário ter uma referência de sinais preditivos, por exemplo, o desempenho das regras existentes. Em outras palavras, você precisa saber o que é normal para seu negócio ou quais são as características de uma transação genuína. É nessa parte que analistas de fraude e engenheiros de dados trabalham juntos, podendo também envolver equipes de DevOps e um pacote de observabilidade. Em nosso cenário hipotético, um aumento nas transações recusadas dos tipos de cartão Mallory é detectado por meio de monitoramento contínuo.

Tabelas Sigma com dados de fraude relevantes

Para detectar padrões emergentes, o primeiro passo é estabelecer o desempenho de referência usando recursos como taxa de recusa/autorização do emissor e taxa de bloqueio do Radar. Em seguida, você deve consultar contestações fraudulentas, alertas antecipados de fraude (Registros de fraude do emissor) e transações de pagamento com alta velocidade, volume alto de recusas do emissor ou altas pontuações de risco do Radar. O ideal é programar essa consulta para ser executada diariamente com base nos dados disponíveis e visualizar todos os dashboards com dados passados, incluindo cortes semanais e mensais, sem precisar consultar manualmente o Sigma ou seu armazém de dados. Esse processo acelerará o tempo de resposta a incidentes.

Estas são as tabelas mais relevantes:

Seus analistas de fraude ou de negócios devem saber quais outras dimensões de detalhamento são importantes avaliar com base na sua área de negócio. A tabela de atributos de regras do Radar no Radar for Fraud Teams traz informações detalhadas sobre as transações existentes avaliadas pelo Radar, mas, além de não incluir dados anteriores a abril de 2023, não contém metadados nem resultados finais. Anteriormente, estes eram os campos consultados:

A nova tabela de atributos de regras do Radar rastreia as mesmas dimensões, e ainda muitas outras, para cada transação avaliada pelo Radar com os mesmos nomes de atributos. Por exemplo, é possível rastrear tendências de velocidade como name_count_for_card_weekly.

Existem diferentes maneiras de visualizar tendências, mas um gráfico simples de linhas dinâmicas por detalhamento facilita a comparação com outros fatores. Um detalhamento feito na fase de investigação deve combinar diferentes aspectos. Esta tabela de exemplo mostra divisões por segmento de produto e o aumento de transações recusadas de cartões Mallory:

E os dados podem ser mostrados assim na ferramenta de planilha de sua escolha:

Vamos analisar mais de perto um exemplo de consulta do Stripe Sigma ou Data Pipeline para obter dados de referência. A consulta abaixo mostra disputas diárias, recusas, taxas de bloqueio e mais, em colunas separadas. Durante as fases de Detecção e Investigação, dados amplos e esparsos em colunas distintas são geralmente mais fáceis de visualizar. Isso também facilita mapear essas colunas para predicados do Radar mais tarde. Mas analistas de dados podem preferir um formato “alto e denso” para análise exploratória ou para machine learning nas etapas de Confirmação e Refinamento.

Neste exemplo, adicionamos metadados no pagamento para exibir a divisão por segmento de produto. Em uma abordagem ampla, seriam necessárias consultas semelhantes para a bandeira do cartão (“Mallory”) e o tipo de financiamento, dentro do cenário. Aqui removemos tentativas duplicadas para focar nas intents reais e ter noção mais clara da magnitude. Optamos por deduplicar no nível dos intents de pagamento — integrações mais profundas podem enviar um campo (como ID de pedido em metadados) para garantir a remoção de duplicatas em toda a jornada. Esse exemplo mostra como melhorar a precisão das medidas antifraude ao incluir outro fator. No caso, o segmento de produto “cartões-presente”. Voltaremos a falar sobre formas de aumentar a precisão na seção de Refinamento e mitigação.

Esta consulta não mostra o tempo exato da contestação, que é um indicador atrasado, mas adicionamos alguns exemplos — como novas tentativas sendo usadas como sinal de testes de cartão. Aqui, extraímos algumas métricas diárias de forma simplificada:

• O volume de cobranças, tanto deduplicadas quanto em valor bruto: por exemplo, 1.150 cobranças por dia, das quais 100 foram recusadas e 50 bloqueadas pelo Radar, dentro de 1.000 intents de pagamento.
  
• A taxa de autorização: neste caso, 90% das cobranças, já que pagamentos bloqueados não chegam ao emissor, e 100% nos intents de pagamento, pois todos acabaram sendo refeitos com sucesso.
  
• A taxa de alto risco e bloqueio: nesse cenário, ambas ficam em 1,6% (os 50 riscos altos também foram bloqueados).
  
• A taxa retroativa de contestação nos pagamentos do mesmo período: por exemplo, 5 em cada 1.000 cobranças sofreram disputa. Esse número cresce por dia de pagamento conforme entram novas contestações; por isso, incluímos o horário de execução da consulta para acompanhar a variação.
  

Como dito antes, simplificamos essas consultas para facilitar a leitura. Na prática, uma consulta real incluiria ainda mais dimensões, como tendências, desvios ou diferenças de perdas.

Também incluímos um exemplo de média móvel de 30 dias utilizando uma função de janela. Abordagens mais complexas, como usar percentis em vez de médias para identificar ataques de cauda longa, são possíveis, mas raramente necessárias na detecção inicial de fraudes, pois acompanhar tendências é mais relevante do que números exatos.

Depois de entender a linha de base, você pode começar a rastrear anomalias e tendências para investigar, como um aumento na fraude ou na taxa de bloqueio em certo país ou método de pagamento (no nosso exemplo hipotético, seria a bandeira “Mallory”). Em geral, anomalias são examinadas com relatórios ou análises manuais no Dashboard, ou ainda com consultas ad hoc no Stripe Sigma.

Investigação

Depois que seus analistas identificam uma anomalia, o próximo passo é realizar uma consulta no Stripe Sigma (ou em seu data warehouse via Data Pipeline) para explorar os dados e formular uma hipótese. É importante incluir dimensões de detalhamento ligadas às hipóteses — como métodos de pagamento (uso de cartão), canal ou interface (metadados), cliente (reputação) ou produtos (categoria de risco) mais suscetíveis a fraude. Na etapa de Confirmação, essas dimensões passam a ser chamadas de “características” e são mapeadas em predicados do Radar.

Retomando nossa hipótese: um grande volume de transações com cartões pré-pagos “Mallory” apresenta taxas de fraude mais altas, o que pode ser tratado como dimensão de agrupamento para análise. Nessa fase, a consulta costuma ser iterada e ajustada — logo, é recomendável testar diferentes candidatos a predicados, em versões reduzidas ou ampliadas das hipóteses, removendo atributos secundários para medir o impacto. Por exemplo:

Essa abordagem daria uma ideia da magnitude para priorizar o impacto. A tabela informa com confiança razoável que a regra candidata 3 parece detectar o excesso de transações maliciosas. Uma avaliação mais elaborada se basearia na exatidão, precisão ou revocação. Você pode criar uma saída como a consulta abaixo.

Nessa consulta, removemos duplicatas para facilitar a leitura, mas incluímos a taxa de contestação e alertas antecipados de fraude, que são importantes para programas de monitoramento de bandeiras de cartões. No entanto, esses são indicadores de atraso ​​que só serão rastreados retroativamente nessa consulta simplificada. Também incluímos amostras arbitrárias de pagamento para verificação cruzada e investigação mais profunda dos padrões encontrados na consulta. Falaremos sobre isso mais tarde.

É indicado dividir métricas adicionais em um histograma para identificar clusters, o que pode ser útil para definir regras de velocidade que você pode usar para limitar a taxa (por exemplo, total_charges_per customer_hourly).

Identificar tendências por meio da análise de histograma é uma excelente maneira de entender o comportamento desejado do cliente em todo o ciclo de vida e funil de conversão. Adicionar esse aspecto à consulta acima seria muito complexo, mas apresentamos um exemplo simples de como obter tal nível de detalhamento sem a complicada lógica de janela móvel, supondo que o tipo de cliente é indicado em seus metadados (por exemplo, usuário convidado):

No nosso cenário, você talvez não queira bloquear todos os cartões pré-pagos da bandeira “Mallory”, mas sim identificar com segurança outros fatores de risco relacionados. Essa consulta de velocidade pode aumentar a confiança para, por exemplo, evitar o bloqueio de clientes ocasionais de baixa frequência.

Uma forma simples de investigar é analisar amostras diretamente no Dashboard através da visualização “Pagamentos relacionados”, entendendo o comportamento — ou seja, o vetor de ataque ou padrão fraudulento — e os insights de risco do Radar associados. É por isso que adicionamos amostras arbitrárias de pagamentos na consulta anterior. Dessa forma, você também consegue encontrar transações mais recentes que ainda não constam no Stripe Sigma. Um caminho mais defensivo e manual é transformar sua hipótese em uma regra de revisão, que ainda permite a aprovação de pagamentos, mas os encaminha para revisão manual pelos analistas. Alguns clientes usam isso para decidir reembolsar pagamentos abaixo da tarifa de disputa enquanto bloqueiam os acima.

Confirmação

Agora, vamos supor que o padrão identificado não seja simples, não possa ser resolvido apenas com reembolso e bloqueio do cliente fraudulento, e não se encaixe em uma lista de bloqueio padrão.

Depois de identificar e priorizar esse padrão, é necessário avaliar seu impacto sobre a receita legítima. Não é uma otimização trivial, pois a quantidade ideal de fraude não é zero. Entre os diferentes candidatos de modelo, selecione aquele que traz o melhor equilíbrio para o seu apetite de risco — seja por magnitude, precisão ou recall. Esse processo é chamado às vezes de backtesting, sobretudo quando as regras são escritas primeiro e validadas depois. (Também é possível inverter: descobrir padrões primeiro e só então criar as regras). Por exemplo, em vez de escrever uma regra por país, crie uma regra assim para facilitar a confirmação:

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

A consulta mencionada na seção de Investigação pode igualmente servir de modelo, apenas com ênfases em valores diferentes — falaremos disso mais adiante, nas técnicas de refinamento e mitigação.

Esquema do Stripe Sigma para mapeamento das regras do Radar

Chegou a hora de traduzir suas consultas exploratórias do Stripe Sigma ou Data Pipeline para ajudar a mapear regras do Radar para o Stripe Sigma em testes retroativos. Eis alguns mapeamentos comuns, assumindo que você esteja enviando os sinais corretos ao Radar:

Os dois últimos itens, risk_level e risk_score, diferem dos outros, pois o próprio modelo de machine learning é derivado de outros fatores. Em vez de escrever regras muito complexas, recomendamos que você se baseie no machine learning do Radar. Falaremos mais sobre isso na seção sobre refinamento usando machine learning.

A nova tabela de atributos de regras do Radar rastreia as mesmas dimensões, e ainda muitas outras, para cada transação que foi avaliada pelo Radar com os mesmos nomes de atributos.

A tabela acima mostra o conjunto padrão de atributos e omite deliberadamente sinais que seriam personalizados para a jornada do cliente, como sessões do Radar ou metadados.

Com base na investigação acima, vamos supor que você chegue a uma regra semelhante a esta:

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

A próxima etapa é confirmar o impacto dessa regra nas transações de pagamentos reais. Normalmente, isso é feito com regras de bloqueio. Leia nosso guia Radar for Fraud Teams: Regras 101 para saber como escrever regras com a sintaxe correta. Uma maneira simples de testar uma regra de bloqueio é criá-la no modo de teste e criar pagamentos manuais de teste para validar seu funcionamento.

Tanto as regras de bloqueio quanto as de revisão podem ser submetidas a backtesting no Radar usando o recurso de simulação do Radar for Fraud Teams.

Uma vantagem de usar as simulações do Radar for Fraud Teams é que ele considera o impacto de outras regras existentes. Manutenção de regras não é o foco deste guia, mas a remoção e a atualização de regras também deve ser parte do seu processo de melhoria contínua. De um modo geral, o número de regras usado deve ser pequeno o suficiente para que cada uma seja atômica e possa ser monitorada usando as consultas de referência desenvolvidas nas fases de detecção e investigação, e ainda testada com clareza, sem risco de efeitos colaterais (por exemplo, a regra 2 só funciona porque a regra 1 elimina um aspecto).

Você também pode fazer isso usando regras de revisão em vez de regras de bloqueio, que abordaremos na próxima seção.

Refinamento e mitigação

Por fim, após testar suas regras de bloqueio, aplica-se o modelo para prevenir, monitorar ou redirecionar fraudes. Chamamos isso de Refinamento porque o objetivo é aumentar a precisão das medidas antifraude como um todo, sobretudo em conjunto com o machine learning. Para aumentar a precisão, várias técnicas podem ser usadas. Às vezes, essa etapa (também chamada de contenção ou mitigação) acontece junto à de Confirmação: em vez de usar regras de revisão, testes A/B (metadados) ou simulações para avaliar o modelo, bloqueiam-se imediatamente as cobranças suspeitas para reduzir o risco imediato.

Mesmo que ações já tenham sido tomadas, ainda há técnicas para refinar o modelo desenvolvido nas etapas 1 a 3 e melhorar os resultados com o tempo:

Refinamento com uso de regras de revisão

Se quiser evitar aumentar a taxa de falsos positivos, o que pode afetar a receita, é possível adotar regras de revisão. Apesar de ser um processo mais manual e que adiciona algum atrito à experiência do cliente, elas permitem liberar mais transações legítimas. É possível também incluir regras de velocidade para acrescentar limitação às regras de bloqueio já existentes em transações mais lentas. Uma alternativa mais avançada é usar teste A/B, útil para gerenciar o volume total de casos na fila de revisão. Você pode usar metadados dos pagamentos para liberar uma fração pequena de tráfego enquanto testa A/B — por exemplo, de clientes conhecidos ou mesmo de forma aleatória. Recomendamos aplicar isso dentro das regras de bloqueio em vez de criar regras de permissão, pois as de permissão se sobrepõem às de bloqueio e dificultam acompanhar o desempenho da regra ao longo do tempo.

Otimização das regras via monitoramento de desempenho

Para acompanhar o desempenho, é possível consultar o charge outcome object na API Payment Intents, em especial o objeto de regra. De forma similar, no Stripe Sigma você pode usar os campos charges.outcome_rule_id, charges.outcome_type e payment_intents.review_id para análise. Aqui está um exemplo de como monitorar o desempenho de uma regra no Stripe Sigma usando a tabela de decisões de regras do Radar.

Refinamento usando machine learning

A etapa mais comum após o bloqueio de um ataque imediato é refinar iterativamente a regra com machine learning para reduzir o número de falsos positivos, permitindo o tráfego mais legítimo e, portanto, a receita.

Vamos tomar o exemplo do bloqueio BIN ou IIN (número de identificação do emissor). Durante um ataque de teste de cartões, você pode ter adicionado temporariamente um BIN a uma lista de bloqueio, o que dá aos emissores tempo para corrigir uma lacuna. No entanto, bloquear um emissor pode reduzir a receita. Uma abordagem mais refinada é aplicar mais escrutínio ao longo do tempo e refinar o modelo. Este é um bom momento para relembrar como escrever regras eficazes e como avaliar risco, em particular a pontuação de risco do Radar. Geralmente, recomendamos aliar sua intuição ao machine learning do Radar. Em vez de ter apenas uma regra para bloquear todas as transações de alto risco, combinar a pontuação com regras manuais que representam um modelo ou cenário de risco geralmente oferece um equilíbrio melhor entre bloquear tráfego malicioso e permitir a geração de receita. Por exemplo:

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

Refinamento usando 3DS

Conforme mencionado anteriormente, embora este guia não cubra toda a amplitude da autenticação 3D Secure (3DS), considere esse recurso em sua estratégia de mitigação de risco. Por exemplo, embora a transferência de responsabilidade possa diminuir as tarifas de contestação em transações fraudulentas, essas transações ainda são incluídas nos programas de monitoramento de cartões e afetam a experiência do usuário. Em vez de um valor fixo, você pode refinar a regra de "bloquear todas as cobranças relevantes" para "solicitar 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’

Em seguida, use uma regra para bloquear os cartões que não foram autenticados ou que não fornecem transferência de responsabilidade por outro motivo:

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’

Refinamento usando listas

Usar as listas padrão ou manter listas personalizadas pode ser uma maneira muito eficaz de bloquear um ataque durante um incidente sem o risco de alterar as regras, por exemplo, bloqueando um cliente fraudulento, um domínio de e-mail ou o país do cartão. Parte do refinamento é decidir quais padrões devem ser uma regra, quais devem alterar um predicado de regra e quais podem simplesmente agregar valor a uma lista existente. As regras do Breakglass são um bom exemplo de paliativo durante um incidente que pode posteriormente ser refinado em uma lista ou na alteração de uma regra existente.

Processo de feedback

O refinamento também implica retornar à primeira etapa, ou seja, monitorar o desempenho das regras e os padrões de fraudes. Um bom monitoramento depende de referências estabelecidas e alterações atômicas únicas para rastreabilidade, precisão e revocação de backtesting ideais. Por isso, recomendamos apenas alterar regras e predicados em implantações claras e distintas e, em outros casos, confiar em listas, revisões e bloqueio e reembolso proativos.

Como a Stripe pode ajudar?

Radar para plataformas

Você tem uma plataforma que usa o Stripe Connect? Nesse caso, todas as regras que você criar se aplicam apenas a pagamentos criados na conta da plataforma (nos termos do Connect, cobranças de destino ou em nome
de). Os pagamentos criados diretamente na conta conectada estão sujeitos às regras dessa conta.

Radar para Terminal

As cobranças do Stripe Terminal não são rastreadas pelo Radar. Isso significa que, se você usar o Terminal, poderá escrever regras com base na frequência do IP sem se preocupar em bloquear pagamentos presenciais.

Serviços profissionais da Stripe

A equipe de serviços profissionais da Stripe pode ajudar você a implementar um processo de gerenciamento de fraudes com melhoria contínua. Do fortalecimento da integração atual ao lançamento de novos modelos de negócios, as orientações dos nossos especialistas ajudam a ampliar sua solução atual da Stripe.

Conclusão

Neste guia, vimos como o Stripe Sigma ou o Data Pipeline podem ser usados tanto para estabelecer uma linha de base quanto para criar modelos de fraude que refletem cenários e padrões que só você e sua empresa conseguem avaliar. Também mostramos como estender e ajustar o Radar para lidar com uma gama maior de transações fraudulentas com base em suas regras personalizadas.

Como fraudes em pagamentos evoluem constantemente, esse processo também precisa evoluir continuamente para acompanhar — como descrevemos no modelo de Detecção, Investigação, Confirmação e Refinamento e mitigação. Executar esses ciclos de forma contínua, com feedback ágil, permite gastar menos tempo reagindo a incidentes e mais tempo desenvolvendo uma estratégia antifraude proativa.

Você pode saber mais sobre o Radar for Fraud Teams aqui. Se já usa o Radar for Fraud Teams, acesse a página Regras no Dashboard para começar a criar suas próprias regras.

Saiba mais sobre o Stripe Sigma aqui e sobre o Stripe Data Pipeline aqui.