Avaliar o risco de fraudes é um processo contínuo que envolve a identificação de vetores, padrões e cenários de ataque, além de como mitigá-los. Ao trabalhar de perto com os usuários, nossa equipe de serviços profissionais observou que as empresas que fazem isso com mais eficiência costumam ter analistas de fraude e de dados trabalhando juntos. Esses profissionais usam uma combinação do Stripe Radar for Fraud Teams e produtos do Stripe Data, como o Stripe Sigma ou Stripe Data Pipeline, para identificar tanto padrões de fraudes comuns como os que são específicos às empresas.

O Radar for Fraud Teams ajuda a detectar e prevenir fraudes. Com ele, é possível criar uma configuração sob medida contra fraudes que é exclusiva para sua empresa, com regras personalizadas, relatórios e revisões manuais. O Sigma é uma solução de relatórios que disponibiliza todos os dados transacionais, de conversão e de clientes em um ambiente interativo no Stripe Dashboard. O Data Pipeline fornece os mesmos dados e os envia automaticamente para um armazém de dados Snowflake ou Redshift, onde podem ser acessados juntamente ​​com outros dados da empresa.

Essas ferramentas funcionam em conjunto para cobrir os quatro pilares de um processo eficaz de gerenciamento de fraudes: detecção, investigação, confirmação e, por fim, refinamento e mitigação. Abordaremos cada um deles em mais detalhes.

A importância de usar o Radar for Fraud Teams com o Sigma ou o Data Pipeline

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

1. Tempo para criar insights e detectar e prevenir fraudes de forma proativa.
   
2. Tempo para reagir e desenvolver regras preventivas e de detecção.
   
3. Cálculo do custo de fraudes, que inclui reembolsos, tarifas de contestação, perda de clientes e pagamentos recusados pelo emissor.
   

Nosso relatório Panorama da fraude online destaca as despesas gerais operacionais dos processos de revisão manual e revela que "quanto maiores [são as empresas], menor a fração de transações que revisam". Com a automatização desses processos, os analistas de fraude têm mais tempo para dedicar à identificação de novos vetores de ataque e ao desenvolvimento de regras preventivas e de detecção. Isso significa que você pode encontrar um equilíbrio melhor entre o bloqueio de tráfego fraudulento e a redução da fricção para clientes legítimos (perda de clientes).

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 ponto de dados que deve ser investigado. A detecção pode ser manual (por exemplo, durante um incidente), semiautomática (por meio de regras de detecção ou monitoramento em relação a uma linha de base), automatizada (por meio de machine learning ou detecção de anomalias) ou acionada externamente (por exemplo, comentários ou contestações de clientes). Quando se trata de detecção, o machine learning do Radar pode encontrar automaticamente padrões de fraudes comuns, enquanto o Sigma pode descobrir padrões específicos à sua empresa.
  
• Investigação, ou análise exploratória, é a avaliação de pagamentos ou comportamentos suspeitos para entender melhor o impacto nos negócios. Esse processo geralmente envolve verificação em relação a dados mais amplos para eliminar ruídos. Normalmente, os analistas de fraudes usarão a fila de revisão do Radar ou o Dashboard Payments da Stripe na investigação.
  
• Confirmação, também chamada de modelagem ou backtesting, é a generalização do vetor de ataque de fraude verificado em dimensões e candidatos a modelo. Isso também abrange a validação e avaliação de impacto usando dados anteriores e comparando a outras regras. A funcionalidade de backtesting e simulação do Radar pode ajudar os analistas de fraudes a fazer isso, mas os engenheiros de dados podem usar o Sigma em cenários ainda mais amplos.
  
• Refinamento e mitigação, às vezes referidos como ação ou confinamento, correspondem à implementação do modelo: dimensões e recursos significativos são mapeados a predicados de regras do Radar a fim de prevenir, monitorar ou redirecionar fraudes. Tradicionalmente, essas regras eram preventivas e estáticas, mas, com a contrapartida importante do machine learning e o objetivo de aumentar a precisão, refinamento é o termo mais apropriado. Essa etapa geralmente inclui listas ou regras de bloqueio no Radar.
  

Uma implementação básica desse processo pode envolver ciclos iterativos, como verificações diárias, sprints ou lançamentos de configurações de detecção de fraude baseada em regras. No entanto, como os ciclos podem ter durações diferentes e coincidir com os loops de feedback, preferimos pensar nisso como um processo contínuo.

A seguir, analisamos cada um desses quatro pilares em detalhes no contexto de um cenário hipotético e mostramos como o Radar for Fraud Teams e o 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 examinar mais de perto o exemplo de uma consulta do Sigma ou Data Pipeline para retornar dados de referência. A consulta abaixo mostrará contestações diárias, pagamentos recusados, taxas de bloqueio e outros dados em colunas separadas. Durante as fases de detecção e investigação, dados amplos e esparsos em colunas separadas geralmente são mais fáceis de visualizar. Essa estratégia também facilitará o mapeamento posterior de colunas em predicados do Radar. No entanto, seus cientistas de dados podem preferir um formato alto e denso para análise exploratória durante a investigação ou machine learning nas fases de confirmação e refinamento e mitigação.

Neste exemplo, incluímos metadados no pagamento para mostrar uma divisão por segmento de produto. Em uma abordagem ampla, precisaríamos de consultas semelhantes para a bandeira do cartão (Mallory) e o tipo de financiamento, de acordo com nosso cenário. Removemos as duplicatas de novas tentativas aqui para focar nas intenções reais e ter uma melhor ideia da magnitude. Optamos por remover intenções de pagamento duplicadas: integrações mais profundas podem enviar um campo (por exemplo, ID do pedido, em metadados) para garantir a remoção das duplicatas em toda a jornada do usuário. Este exemplo mostra como você pode aumentar a precisão das medidas antifraude adicionando outro fator. Em nosso cenário, esse seria o segmento de produto "cartões-presente". Voltaremos às formas de aumentar a precisão posteriormente na seção Refinamento e mitigação.

Essa consulta não inclui o tempo real da contestação, que é um indicador de atraso, mas incluímos alguns indicadores de amostra, por exemplo, novas tentativas como um indicador de teste de cartão. A consulta simplifica algumas métricas diárias:

• Volume de cobranças (sem duplicatas e como valor bruto): por exemplo, 1.150 cobranças por dia, sendo 100 recusadas e 50 bloqueadas pelo Radar, em 1.000 intenções de pagamento.
  
• Taxa de autorização: neste exemplo, 90% são referentes às cobranças, porque os pagamentos bloqueados não são enviados ao emissor, e 100% de intenções de pagamento, já que todos eles tentaram novamente com sucesso.
  
• Alto risco e taxa de bloqueio: nesse caso, ambos seriam 1,6% (todos os 50 riscos altos também foram bloqueados).
  
• Taxa de contestação retroativa para pagamentos do mesmo período: por exemplo, 5 em 1.000 cobranças foram contestadas. O número por dia de pagamento aumentará quando houver mais contestações. Portanto, incluímos o horário de execução da consulta para rastrear a alteração.
  

Conforme mencionado anteriormente, simplificamos essas consultas para facilitar a leitura. Uma consulta real desse tipo teria ainda mais dimensões, por exemplo, tendências, desvios ou diferenças de perda.

Também incluímos um exemplo de média contínua de 30 dias usando uma função de janela. É possível usar abordagens mais complexas, como observar percentis em vez de médias para identificar ataques de cauda longa, mas isso raramente é necessário na detecção inicial de fraudes, quando é mais importante ter linhas de tendência do que números precisos.

Depois de entender a referência, você pode começar a rastrear anomalias e tendências para investigar, por exemplo, um aumento no número de fraudes ou da taxa de bloqueio em um determinado país ou forma de pagamento (em nosso cenário hipotético, seria a bandeira do cartão Mallory). As anomalias são normalmente investigadas usando relatórios ou análises manuais no Dashboard ou consultas ad hoc no Sigma.

Investigação

Depois que os analistas encontram uma anomalia a ser investigada, a próxima etapa é realizar uma consulta no Sigma (ou no armazém de dados pelo Data Pipeline) para conferir os dados e criar uma hipótese. Recomendamos incluir algumas dimensões de detalhamento com base nas hipóteses levantadas, por exemplo, formas de pagamento (uso de cartão), canal ou superfície (metadados), cliente (reputação) ou produtos (categoria de risco) com tendência a fraudes. Posteriormente, na etapa de confirmação, essas dimensões podem ser chamadas de características e serão mapeadas em predicados do Radar.

Vamos voltar à hipótese de que um grande volume de transações em cartões pré-pagos Mallory tem taxas de fraude mais altas, que pode ser representada como uma dimensão de agrupamento para comparação usando a ferramenta de análise. Normalmente, nesse estágio, a consulta é iterada e ajustada, por isso é uma boa ideia incluir vários predicados possíveis, como versões reduzidas ou estendidas das hipóteses, e remover características secundárias para avaliar seu 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):

Em nosso cenário, supomos que você não queira bloquear todos os cartões pré-pagos Mallory, mas queira identificar com confiança outros fatores de risco correlacionados. Essa consulta de velocidade pode melhorar a confiança para, por exemplo, evitar o bloqueio de clientes convidados de baixa frequência.

Uma maneira simples de investigar é examinar as amostras diretamente no Dashboard na seção "Pagamentos relacionados" para entender o comportamento registrado, ou seja, o vetor de ataque ou padrão fraudulento, e os insights de risco do Radar associados. É por isso que incluímos amostras de pagamento arbitrárias na consulta acima. Dessa forma, você também pode encontrar pagamentos mais recentes que ainda não estão disponíveis no Sigma. Uma maneira mais defensiva e com contato pessoal seria modelar a hipótese como uma regra de revisão que permite pagamentos, mas os encaminha aos analistas para revisão manual. Alguns clientes fazem isso para analisar o reembolso de pagamentos abaixo da tarifa de contestação e bloquear aqueles acima dessa tarifa.

Confirmação

A partir de agora, vamos supor que o padrão que você identificou não é simples, não pode ser mitigado reembolsando e bloqueando o cliente fraudulento e não se enquadra apenas em uma lista de bloqueio padrão.

Depois de identificar e priorizar um novo padrão a ser abordado, é necessário analisar o impacto potencial sobre a receita legítima. Esse não é um problema de otimização trivial, porque a quantidade ideal de fraude é diferente de zero. De todos os diferentes possíveis modelos, escolha aquele que representa a melhor compensação para a quantidade de risco que você se dispõe a correr, seja por magnitude simples ou precisão e revocação. Às vezes, esse processo é chamado de backtesting, especialmente quando as regras são escritas primeiro e em seguida validadas em relação aos dados. O processo também pode acontecer no sentido contrário: descobrir os padrões primeiro e escrever as regras depois. Por exemplo, em vez de escrever uma regra por país, use o exemplo abaixo, que facilita a confirmação:

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

A consulta compartilhada na seção Investigação acima também pode ser usada como um modelo. No entanto, valores diferentes seriam enfatizados. Falaremos sobre isso mais tarde quando chegarmos às técnicas de refinamento e mitigação.

Esquema Sigma para mapeamento de regras do Radar

É hora de utilizar as consultas exploratórias do Sigma ou do Data Pipeline para mapear as regras do Radar no Sigma para o backtesting. Estes são alguns mapeamentos comuns, supondo que você esteja enviando os sinais corretos para o 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, depois de testar as regras de bloqueio, você aplica o modelo para evitar, monitorar ou redirecionar fraudes. Chamamos isso de refinamento porque o objetivo é aumentar a precisão das medidas gerais antifraude, principalmente quando também se usa o machine learning. Há diversas técnicas que podem ser implementadas para ter uma precisão maior. Às vezes, essa etapa, que também pode ser chamada de contenção ou mitigação, ocorre simultaneamente à de confirmação. Nesse caso, em vez de usar regras de revisão, testes A/B (metadados) ou simulações para avaliar o modelo, você bloqueia imediatamente as cobranças suspeitas para mitigar o risco.

Mesmo que já tenha realizado uma ação, você poderá usar algumas técnicas para refinar o modelo desenvolvido nas etapas 1 a 3 e melhorar os resultados ao longo do tempo:

Refinamento usando regras de revisão

Se quiser evitar o risco de ter uma taxa de falsos positivos mais alta, o que pode afetar a receita, implemente regras de revisão. Embora seja um processo mais manual que pode adicionar atrito à experiência do cliente, o uso de regras de revisão pode permitir a aprovação de um número maior de transações legítimas. Você também pode usar regras de velocidade para adicionar limitação às regras de bloqueio existentes para transações mais lentas. Uma opção mais avançada no uso de regras de revisão é o teste A/B, que é especialmente útil para gerenciar o número total de casos na fila de revisão. Os metadados dos pagamentos podem ser utilizados para permitir uma pequena quantidade de tráfego, como clientes conhecidos ou simplesmente usando um número aleatório, durante o teste A/B. Recomendamos adicionar esse recurso às regras de bloqueio, em vez de criar regras de permissão. Regras de permissão se sobrepõem às de bloqueio, dificultando o rastreamento do desempenho da regra de bloqueio ao longo do tempo.

Monitoramento do desempenho das regras para otimização

É possível monitorar o desempenho de uma regra verificando o objeto de resultado de cobrança na API Payment Intents, em particular o objeto de regra. A análise dos campos charges.outcome_rule_id, charges.outcome_type e payment_intents.review_id do Sigma funciona de maneira semelhante. Confira este exemplo de como rastrear o desempenho de uma regra no Sigma usando a tabela especial 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 Sigma ou o Data Pipeline podem ser usados ​​para criar uma referência e vários modelos de fraudes que representam cenários e padrões de ataque que somente você e sua empresa podem julgar. Também mostramos como é possível ampliar e ajustar o Radar para reagir a uma ampla gama de transações fraudulentas com base em regras personalizadas.

Esse processo precisa evoluir continuamente para acompanhar a evolução constante das fraudes de pagamentos, conforme descrito em nosso modelo de detecção, investigação, confirmação, refinamento e mitigação. Executar esses ciclos continuamente, além de um loop de feedback rápido, permitirá que você gaste menos tempo reagindo a incidentes e mais tempo desenvolvendo uma estratégia proativa de proteção a fraudes.

Aprenda mais sobre o Radar for Fraud Teams aqui. Se você já usa o Radar for Fraud Teams, confira a página de regras em seu Dashboard para começar a escrever regras.

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