Regras de prevenção de fraudes
Use regras de prevenção de fraudes para proteger sua empresa.
As regras de prevenção a fraudes permitem que você tome medidas sempre que um pagamento cumpre determinados critérios.
O Stripe Radar oferece regras prontas para ajudar todos os usuários da Stripe a detectar e se proteger contra riscos de fraude.
Os usuários do Radar for Fraud Teams podem usar o Dashboard para criar regras personalizadas de acordo com a lógica comercial da sua empresa. Por exemplo, você pode:
- Solicitar 3D Secure (3DS) para todos os pagamentos em que ele é aceito e que forem feitos por um novo cliente
- Permitir todos os pagamentos do endereço IP da sua central de atendimento
- Bloquear pagamentos feitos de um local ou cartão emitido fora do seu país
- Revisar todos os pagamentos superiores a USD 1.000 que foram feitos com um cartão pré-pago
Cuidado
Comerciantes na UE podem ser afetados pelo Regulamento de Bloqueio Geográfico e as proibições de bloquear pagamentos de clientes localizados em estados-membros da UE.
Regras integradas
As regras a seguir estão disponíveis por padrão para todos os usuários do Radar.
Verificações de risco por machine learning
O Stripe Radar e o Stripe Radar for Fraud Teams fornecem um conjunto de regras padrão baseadas nas avaliações dos nossos modelos de machine learning, que são:
Bloquear if :risk_level: = 'highest'
A regra bloqueia e não processa pagamentos com um alto risco de fraude. Essa regra é habilitada por padrão para usuários do Radar ou Radar for Fraud Teams.
Revisar if :risk_level: = 'elevated'
O comportamento padrão do Stripe Radar for Fraud Teams é analisar os pagamentos com suspeita de risco elevado de fraude.
Verificações de cartão tradicionais
Um pagamento ainda pode ser bem-sucedido mesmo que a verificação de CVC ou de endereço (AVS) falhe, porque os emissores de cartão consideram vários sinais ao decidir sobre a aprovação ou recusa de um pagamento. Em alguns casos, um emissor de cartão ainda pode aprovar um pagamento que considerar legítimo, mesmo que ocorra falha na verificação do CVC ou do código postal.
A Stripe tem regras integradas que permitem bloquear pagamentos, mesmo que sejam aprovados pelo emissor do cartão. Você pode ativar ou desativar essas regras usando o Stripe Dashboard.
Essas regras também se aplicam ao processo de validação do cartão que ocorre ao anexar um cartão a um cliente. Nos casos em que você cria o cartão e o cliente juntos, a falha na validação de CVC ou código postal impede a criação bem-sucedida do registro do cliente. Essa regra pode não estar habilitada em sua conta por padrão, mas você pode habilitá-la ou desabilitá-la a qualquer momento no Dashboard.
Block if CVC verification fails
Se esta regra estiver habilitada, o Radar bloqueia pagamentos reprovados na verificação de CVC do emissor do cartão. Se o cliente não informar o número de CVC, por exemplo, porque usa uma carteira, ou o emissor do cartão do cliente não aceitar a verificação, a regra não poderá bloquear o pagamento.
Block if postal code verification fails
Se essa regra estiver habilitada, o Radar bloqueia os pagamentos que falham na verificação de código postal do emissor do cartão. Se o cliente não informar o código postal ou o emissor do cartão não aceitar a verificação, a regra não poderá bloquear o pagamento. Essa regra pode não estar habilitada para sua conta por padrão. Você pode ativá-la ou desativá-la a qualquer momento no Dashboard.
Regras integradas para solicitar 3D Secure
O uso do 3DS exige que os clientes cumpram uma etapa de autenticação adicional para concluir o fluxo de compra. Se o 3D Secure autenticar um pagamento, a responsabilidade por qualquer contestação relacionada a fraude nesse pagamento normalmente muda do vendedor para o emissor. Isso significa que, na maioria dos casos, o vendedor não é responsável por custos de fraudes em pagamentos autenticados pelo 3DS.
A Stripe gerencia automaticamente códigos de recusa simples que indicam a exigência do 3DS pelos emissores. Também acionamos o 3DS quando necessário, cumprindo regulamentações como a Autenticação Forte de Cliente (SCA) exigida pelo PSD2. A desativação do Radar não impede que o 3D Secure seja acionado nos casos em que é necessário.
A Stripe oferece três regras desativadas por padrão que você pode ativar para solicitar o 3DS dinamicamente ao usar o Radar com Payment Intents ou Setup Intents:
Request 3D Secure if 3D Secure is required for card- Desativada por padrão. A ativação desta regra encaminha automaticamente o cliente para a autenticação 3DS se o cartão exigir 3DS antes.
- A Stripe processa automaticamente códigos de recusa simples que indicam a exigência de 3DS pelos emissores. Além disso, também acionamos o 3DS quando necessário para cumprir regulamentos como a Autenticação Forte de Cliente determinada pelo PSD2.
Request 3D Secure if 3D Secure is supported for card- Desativado por padrão, mas similar à regra anterior. A ativação dessa regra encaminha o cliente para a autenticação 3DS, desde que o cartão seja compatível.
- Use essa regra em vez da anterior se quiser maximizar o número de pagamentos que têm transferência de responsabilidade. Esteja ciente de que esse requisito adicional pode diminuir as taxas de conversão.
Request 3D Secure if 3D Secure is recommended for card- Desativado por padrão. A ativação dessa regra encaminha o cliente para a autenticação 3DS quando a Stripe acreditar que a autenticação 3DS possa ocorrer com impacto mínimo nas taxas de conversão.
- Habilite essa opção se desejar maximizar a quantidade de pagamentos que têm transferência de responsabilidade.
Como o 3DS exige que seu cliente passe por uma camada adicional de autenticação, o uso indiscriminado do 3DS pode reduzir as taxas de conversão. A Stripe recomenda que você somente ative as regras padrão “Solicitar 3DS” se precisar que todos os pagamentos de cartões aceitos passem pelo 3DS.
A solicitação do 3DS não implica necessariamente em sua execução pelo emissor. Para obter mais detalhes sobre os possíveis resultados, consulte a documentação do 3D Secure.
Regras personalizadas para solicitar o 3D Secure e realizar ações com base em resultados específicos
Se você tiver o Radar for Fraud Teams e tentar a autenticação do 3DS, poderá avaliar o resultado com regras de permissão, bloqueio ou análise.
Os atributos mais importantes para regras personalizadas do Radar são:
is_3d_secure, que é verdadeiro quando o cartão é aceito, o 3DS foi tentado pelo emissor e o usuário não falhou na autenticação. Geralmente, recomendamos usar isso em regras de bloqueio.is_3d_secure_authenticated, que é verdadeira quando o 3DS foi tentado pelo emissor e o usuário concluiu uma autenticação completa com êxito. O uso desse atributo em uma regra de bloqueio exclui transações legítimas que podem ter isenção de SCA ou não se enquadram em uma autenticação com falha ou êxito, como erros de processamento.has_liability_shift, que é verdadeiro quando a Stripe espera que o pagamento seja coberto pela regra de transferência de responsabilidade. Pode não ser sempre o mesmo que o 3DS (por exemplo, o Apple Pay em algumas regiões).
Para regras personalizadas, recomendamos manter as regras Solicitar 3DS e Bloquear dependendo da sua tolerância a riscos. No entanto, não bloqueie transações quando o 3DS não for aceito, como algumas carteiras digitais.
Veja a seguir alguns exemplos que mostram como fazer isso em diferentes casos de uso:
Solicitar o 3D Secure com base no nível de risco do Radar
Recomendamos usar o Radar para solicitar o 3DS em todas as cobranças com base no nível de risco do Radar e acima de um determinado valor.
| Regra do Radar | Descrição |
|---|---|
Solicitar 3D Secure if :risk_level: != | Esta regra verifica o nível de risco do Radar e solicita o 3DS em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3DS não são bloqueados. As tentativas de 3DS com falha na autenticação não continuam para a autorização da cobrança.
Sempre exija o 3D Secure com base no nível de risco do Radar
Recomendamos usar o Radar para solicitar 3DS em todas as cobranças com base no nível de risco elevado ou elevado do Radar e acima de um determinado valor. Se os cartões não aceitarem 3DS, é melhor não aceitá-los.
| Regra do Radar | Descrição |
|---|---|
Solicitar 3D Secure if :risk_level: != | Esta regra verifica o nível de risco do Radar e solicita o 3DS em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Bloquear if not :is_3d_secure: and :risk_level: != | Esta regra bloqueia pagamentos sem um fluxo do 3DS para cobranças com nível de risco elevado ou alto e acima de um determinado valor. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA ou não se enquadrem em uma autenticação com falha ou êxito, como attempt_. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. |
Somente aceite transações totalmente autenticadas pelo 3D Secure quando houver suporte para o 3D Secure
Você conta com a Stripe para ativar o 3DS quando necessário, em situações como a Autenticação Forte de Cliente (SCA), mas não deseja aceitar casos excepcionais, como erros de processamento.
| Regra do Radar | Descrição |
|---|---|
Block if :is_3d_secure: and not :is_3d_secure_authenticated: | Esta regra bloqueia pagamentos em que o cartão está inscrito no 3DS e o 3DS foi tentado, mas a autenticação do usuário não foi bem-sucedida. Cartões incompatíveis com 3DS, isenções da SCA, pagamentos fora da sessão (como cobranças de assinatura recorrentes) e carteiras (como Apple Pay ou Google Pay) são aceitos. |
Solicitar o 3D Secure com base em metadados
Recomendamos usar o Radar para solicitar o 3DS em todas as cobranças com um atributo de metadados personalizado.
| Regra do Radar | Descrição |
|---|---|
Solicitar 3D Secure if ::foo:: = | Esta regra verifica uma condição de metadados e solicita o 3DS. Para verificar metadados do Cliente, substitua ::foo:: = 'bar' por um valor como ::customer:trusted:: = 'false'. |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3DS não são bloqueados. As tentativas de 3DS com falha na autenticação não continuam para a autorização da cobrança.
Sempre exija o 3D Secure com base em metadados
Recomendamos usar o Radar para solicitar o 3DS em todas as cobranças com um atributo de metadados personalizado e bloquear cartões que não o aceitem.
| Regra do Radar | Descrição |
|---|---|
Solicitar 3D Secure if ::foo:: = | Esta regra verifica uma condição de metadados e solicita o 3DS. Para verificar metadados do Cliente, substitua ::foo:: = 'bar' por um valor como ::customer:trusted:: = 'false'. |
Bloquear if ::foo:: = | Esta regra bloqueia pagamentos sem um fluxo de 3DS para cobranças com um atributo de metadados personalizado. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA ou não se enquadrem em uma autorização com falha ou êxito, como attempt_. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. |
Solicite o 3D Secure para todos os novos cartões e faça uma análise se o 3D Secure não era aceito
Recomendamos usar o Radar para solicitar o 3DS em todos os cartões novos e analisar manualmente as cobranças de cartões que não aceitam o 3DS.
| Regra do Radar | Descrição |
|---|---|
Request 3D Secure if is_missing(:seconds_since_card_first_seen:) | Esta regra solicita o 3DS em todos os cartões que não foram usados em sua conta. Para reduzir o atrito dos usuários, você pode adicionar uma condição para solicitar o 3DS somente se :risk_level: != . |
Request 3D Secure if :is_new_card_on_customer: | Como alternativa à regra acima, esta regra solicita o 3DS em todos os cartões usados pela primeira vez em um Customer. Para reduzir o atrito dos usuários, você pode adicionar uma condição para solicitar o 3DS somente se :risk_level: != . |
Revisar if not :is_3d_secure and not:is_off_session: and :digital_wallet: != | Esta regra marca os pagamentos nos quais o 3DS é esperado, mas não é aceito para análise manual. Ela ignora pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. Os pagamentos marcados para análise continuam para a autorização e podem fornecer sinais adicionais, como verificações de CVC do emissor. |
Nesse caso, sem uma regra de bloqueio, os cartões ou carteiras que não aceitam o 3DS não são bloqueados. As tentativas de 3DS com falha na autenticação não continuam para a autorização da cobrança.
Sempre exija o 3D Secure para determinados países de emissores
Recomendamos usar o Radar para solicitar o 3DS em todas as cobranças de emissores de cartão originários de países em uma lista personalizada e bloquear cartões que não o aceitem.
| Regra do Radar | Descrição |
|---|---|
Request 3D Secure if :card_country: in @enforce_3ds_list | Esta regra verifica uma condição baseada em emissores de cartão originários de países e os compara a uma lista personalizada. Se forem iguais, é solicitado o 3DS. |
Bloquear if :card_country: in @enforce_3ds_list and not :is_3d_secure and not :is_off_session: and :digital_wallet: != | Esta regra bloqueia pagamentos sem um fluxo do 3DS para cobranças originadas de países na lista personalizada. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA ou não se enquadrem em uma autorização com falha ou êxito, como attempt_. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. |
Sempre exija o 3D Secure com base no nível de risco do Radar e analise os casos extremos
Recomendamos usar o Radar para solicitar o 3DS em todas as cobranças com base no nível de risco do Radar e bloquear cartões que não aceitam o 3DS, mas analisam manualmente casos extremos.
| Regra do Radar | Descrição |
|---|---|
Solicitar 3D Secure if :risk_level: != | Esta regra verifica o nível de risco do Radar e solicita o 3DS em todas as cobranças com nível de risco elevado ou alto acima de um determinado valor. |
Bloquear if not :is_3d_secure: and :risk_level: != | Esta regra bloqueia pagamentos sem um fluxo do 3DS para cobranças com nível de risco elevado ou alto acima de um determinado valor. No entanto, ela aceita transações legítimas que possam ter uma isenção de SCA. Ela aceita pagamentos fora de sessão, como cobranças de assinatura recorrentes, e carteiras como Apple Pay ou Google Pay. |
Revisar if not :is_3d_secure_authenticated: and :risk_level: != | Esta regra marca para análise manual os pagamentos que estavam usando o 3DS, mas não resultaram em um fluxo totalmente autenticado. Isso analisaria casos extremos como attempt_ e também marcaria pagamentos legítimos apesar das isenções de SCA. Como as regras de análise são avaliadas após as regras de bloqueio, os cartões que não aceitarem o 3DS são bloqueados. |
Quando criar regras
As regras padrão da Stripe podem bloquear uma quantidade considerável de pagamentos fraudulentos. As empresas que precisam aumentar o controle sobre quais pagamentos desejam revisar, permitir ou bloquear podem criar regras personalizadas por meio do Radar for Fraud Teams.
Considere o seguinte ao decidir se deseja habilitar regras personalizadas:
- Se você considera determinados recursos ou comportamentos de usuário como mais arriscados (por exemplo, uso de um e-mail descartável).
- Se você quer implementar regras baseadas em valores de pagamentos ou nível de risco percebido (por exemplo, analisar automaticamente pagamentos superiores a US$ 500 ou permitir automaticamente pagamentos inferiores a US$ 5).
- Se os seus pagamentos atuais contestados e reembolsados têm algum padrão em comum (por exemplo, valores, tipos de cartão ou países similares).
- Se você tem regras existentes que deseja migrar para a Stripe. Muitas dessas regras podem já estar disponíveis nos modelos de machine learning da Stripe. Você pode verificar o desempenho do nosso sistema para sua empresa antes de personalizá-lo.
Como criar regras eficazes
Embora as regras possam ajudar você a automatizar seus fluxos de trabalho existentes, também podem afetar negativamente seu negócio se forem usadas incorretamente. Por exemplo, uma regra pode permitir automaticamente uma grande quantidade de pagamentos fraudulentos ou bloquear uma grande quantidade de pagamentos legítimos se não for definida corretamente.
Lembre-se do seguinte ao configurar regras:
- As regras só se aplicam a pagamentos futuros e não se aplicam a nenhum outro que você já processou.
- As regras Solicitar 3DS aplicam-se somente ao usar Stripe Checkout, Payment Intents ou Setup Intents, e são avaliadas antes das regras de análise, bloqueio e permissão.
- Antes de implementar qualquer regra para bloquear todos os pagamentos que cumprem os critérios, avalie se não é melhor revisar os pagamentos antes.
- Implemente regras de permissão o mínimo possível, pois elas substituem as regras padrão da Stripe por outras regras personalizadas que correspondem aos mesmos critérios.
- Você pode criar um máximo de 200 regras em todos os tipos de regras por conta.
Regras de criação
Você pode adicionar e gerenciar as regras na guia Regras da página do Radar no Dashboard.
Para adicionar uma nova regra:
- Clique em + Adicionar regra.
- Escolha o tipo de regra no submenu.
- No editor de regras, crie uma regra usando a sintaxe
{action} se {attribute} {operator} {value}, em que:{action}: como o Radar responde quando os critérios da regra são cumpridos. Esse valor é preenchido previamente com base na seleção do tipo de regra que você escolheu.{attribute}: o elemento da transação a avaliar, como o valor ou tipo de cartão. Comece a digitar com:para abrir uma lista de atributos válidos. Para avaliar seus metadados personalizados, coloque-os entre dois-pontos . Por exemplo,::product_.sku:: {operator}: como comparar o atributo ao valor, por exemplo,=,>,!=e assim por diante.{value}: o valor do atributo a ser avaliado.
- Clique em Testar regra.
- Se necessário, corrija os erros de validação detectados.
- Na página Revise a nova regra, analise o desempenho da regra em relação às suas transações recentes para confirmar se deseja habilitá-la.
- Clique em Adicionar regra para começar a aplicar a regra em todas as transações futuras.
Usar o Radar Assistant
O editor de regras da Stripe tem um assistente de LLM integrado que cria uma regra do Radar a partir de um instrução de linguagem natural.
Para usar o Radar Assistant:
- Na guia Regras da página do Radar no Dashboard, clique em + Adicionar regra.
- Escolha o tipo de regra no submenu.
- No editor de regras, clique em Radar Assistant.
Criação manual de regras
Radar Assistant
- No campo da mensagem, insira sua solicitação de regra. Você pode pedir para:
- Revise os pagamentos em que o país do cartão e do IP são diferentes.
- Bloqueie pagamentos com cartão Discover de mais de US$ 1.000.
- Permita pagamentos de endereços de e-mail stripe.com.
- Quando o Assistant retorna uma sugestão, você pode inserir um comando adicional para fazer ajustes na regra ou clicar em Testar regra para comparar o desempenho da regra em relação ao seu histórico recente de transações.
- Quando estiver satisfeito com a regra, clique em Adicionar regra para habilitá-la em todas as transações futuras.
Consentimento de dados de treinamento: ao usar o Radar Assistant, você aceita que a Stripe registre e use os dados que você insere no chat para treinar e melhorar as funções do Radar Assistant. Se você não quiser que seus dados inseridos no chat sejam usados para essa finalidade, escreva as regras manualmente.
Saiba mais sobre os serviços da Stripe IA.
Regras de revisão
A Stripe ainda processa pagamentos normalmente quando eles cumprem os critérios de uma regra de análise. No entanto, nós os colocamos em sua fila de análises para que sua equipe possa analisá-los mais detalhadamente. Definir uma regra muito abrangente pode colocar muitos pagamentos na fila de análises, atrasando as entregas e sobrecarregando sua equipe.
A interface de testes de regras da Stripe executa uma simulação nos últimos seis meses de cobranças para determinar quantos pagamentos legítimos, fraudulentos e bloqueados teriam sido afetados pela regra, caso tivesse sido implementada. Ao testar uma regra e examinar os últimos seis meses, certifique-se de que:
- O volume geral de pagamentos seja baixo. A análise desses pagamentos não deve sobrecarregar sua equipe.
- Os revisores humanos agreguem valor. Um revisor humano normalmente pode identificar melhor fraudes em pagamentos do que o sistema automatizado.
- A regra resulte em uma combinação de pagamentos bem-sucedidos e reembolsados ou contestados. Isso significa que uma inspeção adicional nesses tipos de pagamentos pode ajudar a separar os legítimos dos fraudulentos.
A seguir há um exemplo de como melhorar uma regra de análise criada por uma empresa que deseja analisar cartões de crédito pré-pagos.
| Regra original | Regra melhorada |
|---|---|
Review if :card_funding: = | Review if :is_disposable_email: and :card_funding: = |
| Muito abrangente: resulta em excesso de análises | Mais concentrada: resulta em um número menor de análises |
Regras de bloqueio
Você pode usar regras de bloqueio para bloquear pagamentos que tiver certeza de que são fraudulentos ou com base nas restrições em vigor da sua empresa (como o bloqueio de pagamentos de cartões pré-pagos). Se não tiver certeza de como aplicar regras de bloqueio, recomendamos enviar os pagamentos para análise usando uma regra de análise. Depois de analisar esses pagamentos em busca de possíveis falsos positivos, você pode confirmar se deseja criar uma regra de bloqueio.
As regras de bloqueio afetam somente pagamentos fraudulentos e bem-sucedidos, porque pagamentos já bloqueados não são afetados. Ao testar uma regra, não se esqueça de:
- Reduzir ao máximo os falsos positivos. Durante os testes, a Stripe identifica a quantidade de pagamentos bem-sucedidos e malsucedidos que teriam sido correspondidos pela regra. Uma boa regra de bloqueio resulta em muito mais bloqueios fraudes do que de pagamentos legítimos.
- Minimizar regras desnecessárias. Se a sua regra parece ter um ótimo desempenho, mas já está abrangida por uma regra existente, a nova regra pode não ser necessária. Igualmente, se os resultados durante os testes parecerem mistos, considere configurar uma regra de análise para reunir mais informações sobre esses tipos de pagamento.
A seguir há um exemplo de como melhorar uma regra de bloqueio criada por uma empresa que está sofrendo com um nível elevado de fraude em pagamentos fora dos EUA:
| Regra original | Regra melhorada |
|---|---|
Block if :card_country: != | Block if :card_country: != |
| Muito abrangente: alta quantidade de pagamentos legítimos bloqueados | Mais concentrada: resulta em um número menor de análises |
Regras de permissão
As regras de permissão se sobrepõem às outras regras, por isso devem ser usadas com cautela. Muitas empresas talvez não precisem implementar regras de permissão. Se você teme que uma regra de permissão possa deixar passar um pequeno número de pagamentos fraudulentos, considere fazer alguns ajustes para restringir ainda mais essas regras antes de implementá-las.
As regras de permissão se aplicam a novos pagamentos assim que você cria a regra. Isso inclui pagamentos que sejam similares aos pagamentos já bloqueados. Enquanto testa uma regra, certifique-se de:
- Examinar a quantidade de pagamentos já bloqueados que teriam sido permitidos. As regras de permissão sobrepõem as demais regras e a avaliação de risco da Stripe. Ao testar uma nova regra de permissão, todos os pagamentos mostrados teriam sido permitidos se essa regra estivesse ativa. Isso pode incluir pagamentos que foram bloqueados ou contestados, impactando suas futuras taxas de contestação.
- Continuar a bloquear todos os pagamentos de alto risco. É possível fazer isso com esta regra de permissão:
and :risk_level: !='highest' - Avalie um histórico de transações legítimas na sua empresa. Você pode analisar as conexões entre seus clientes para permitir um volume maior de transações com base em um histórico de compras legítimas. Isso ajuda você a bloquear menos pagamentos de clientes que têm um histórico comprovado na sua empresa. Para fazer isso, consulte a lista de atributos e procure atributos que incluam a palavra “customer”.
A seguir temos um exemplo de como melhorar uma regra de permissão para uma empresa que normalmente (mas nem sempre) vê bons pagamentos vindos de clientes no Reino Unido:
| Regra original | Regra melhorada |
|---|---|
Allow if :ip_country: = | Allow if :ip_country: = |
| Muito abrangente: alguns pagamentos fraudulentos são autorizados | Mais concentrada: menos pagamentos fraudulentos são autorizados |
Mantenha suas regras
À medida que sua empresa continua a crescer, é importante que suas regras continuam a refletir os tipos de clientes com os quais deseja fazer negócio. Veja algumas práticas recomendadas para manter as regras alinhadas ao estado da empresa.
Monitore as regras regularmente para verificar se continuam eficazes
Métricas das regras
Os padrões de fraude mudam constantemente, por isso, fornecemos métricas para mostrar o desempenho dessas regras. Essas métricas variam dependendo do tipo de regra, pois os tipos de regra realizam ações diferentes.
Use o gráfico de desempenho das regras para entender o comportamento das suas regras do Radar. Busque picos ou quedas inesperadas no número de pagamentos que correspondem às suas regras, como regras de permissão que aceitam muitos pagamentos ou regras de bloqueio que bloqueiam em excesso. Esses picos podem indicar uma mudança nos tipos de pagamentos que sua empresa está recebendo ou podem justificar atualizações às próprias regras. As atualizações feitas às regras são exibidas como triângulos no gráfico e podem ajudar você a comparar o impacto da mudança antes e depois de fazê-la.
As linhas codificadas por cores acompanham a quantidade de pagamentos que correspondem às regras do 3DS, regras de permissão, bloqueio e análise. Os símbolos triangulares nessas linhas do gráfico representam atualizações às regras do tipo correspondente.
Mostramos informações sobre a eficácia das suas regras e em quantos pagamentos cada uma agiu. Também é possível filtrar e baixar uma lista com todos os pagamentos aos quais uma regra foi aplicada. Avalie essas informações para decidir se é preciso mudar ou remover alguma regra.
Para ver comandos adicionais, clique no menu de navegação (). Os comandos adicionais incluem: Desativar, Ativar, Editar ou Excluir para qualquer regra.
Você também pode usar os nossos produtos de geração de relatórios Sigma e Data Pipelines para consultar dados de contestações e fraudes, incluindo decisões e atributos de regras para cada pagamento individual.
Avalie a eficácia das regras
Mostramos informações sobre a eficácia das suas regras e quantos pagamentos cada uma afetou. Também é possível filtrar e baixar uma lista com todos os pagamentos aos quais uma regra foi aplicada. Revise as questões de amostra na tabela a seguir para ajudar você a decidir se é preciso mudar ou remover alguma regra.
| Tipo de regra | Avaliar | Ações a serem consideradas |
|---|---|---|
| Geral | Se esta regra não corresponder mais a nenhum pagamento | Remova a regra. |
| Se a regra tem um comportamento anômalo, como permitir mais pagamentos do que em períodos anteriores. | Revise manualmente os pagamentos que corresponderam a essa regra para determinar se esse é o comportamento desejado. | |
| 3DS | Se a taxa de conclusão do 3DS for alta, mas o número de contestações ou EFWs for baixo. | Remova a regra, pois você pode criar empecilhos para bons usuários. |
| Se houver muitas fraudes em transações que passam pelo 3DS. | Considere modificar sua regra 3DS para uma regra de bloqueio para evitar que esses usuários passem por um fluxo sem atritos (controlado por emissores) ou cometam fraudes primárias. | |
| Se a taxa de conversão para 3DS for baixa. | Essa pode ser uma boa regra, pois bloqueia principalmente fraudadores, mas considere investigar manualmente os pagamentos correspondentes para garantir que bons usuários não desistam devido a empecilhos adicionais. | |
| Permitir | Se o número de contestações, EFWs, reembolsos ou pagamentos malsucedidos for alto. | Remova a regra que permite a aprovação de pagamentos incorretos. |
| Bloquear | O número de bloqueios está diminuindo, mas sua fraude continua estável ou está aumentando? | Modifique sua regra porque ela pode não ser mais eficaz. |
| Se o número de bloqueios estiver aumentando, mas as fraudes continuarem estáveis ou aumentarem. | Modifique a regra, pois ela pode estar bloqueando usuários válidos. | |
| Se o número de bloqueios está aumentando e as fraudes estão diminuindo. | Isso sugere que sua regra é eficaz, mas considere analisar manualmente algumas transações para assegurar que não esteja bloqueando muitos usuários válidos. | |
| Análise manual | Se a porcentagem de pagamentos analisados é baixa. | Torne a regra mais restritiva, pois ela pode ser muito ampla. |
| Se o número de pagamentos bem-sucedidos ou aprovados é alto. | Remova totalmente a regra de análise manual ou crie uma regra de permissão para esses pagamentos. | |
| Se o número de reembolsos ou contestações e avisos antecipados de fraude forem altos. | Converta em uma regra de bloqueio. |
Regras para solicitação de 3DS
Para as regras para solicitação de 3DS, exibimos:
- 3DS solicitado: o número de vezes que uma regra acionou uma solicitação de 3DS.
Clique em uma regra 3DS para ver as seguintes métricas:
Regras de permissão
Nas regras de permissão, os usuários do Radar for Fraud Teams visualizam:
- Pagamentos permitidos: o número total de pagamentos permitidos pelas suas regras.
- Volume de pagamentos permitidos: o valor total, na moeda local, associado aos pagamentos permitidos por suas regras.
- Pontuação de risco: os resultados de risco correspondentes atribuídos pelos modelos de machine learning da Stripe ao conjunto de pagamentos permitidos pelas suas regras.
- Contestações de sobreposições: o número total de pagamentos permitidos que foram contestados.
- Volume de contestações com sobreposições: o valor total, na moeda local, associado a contestações de pagamentos permitidos.
Clique em uma regra de permissão para ver as seguintes métricas:
Regras de bloqueio
Nas regras de bloqueio, exibimos:
- Pagamentos bloqueados: o número total de pagamentos bloqueados por suas regras.
- Volume de pagamentos bloqueados: o valor total, na moeda local, associado aos pagamentos bloqueados por suas regras.
Os usuários do Radar for Fraud Teams também visualizam:
- Pontuação de risco: os resultados de risco correspondentes atribuídos pelos modelos de machine learning da Stripe ao conjunto de pagamentos permitidos pelas suas regras.
- Taxa estimada de falsos positivos: a porcentagem estimada de pagamentos não fraudulentos que foram bloqueados por suas regras de bloqueio e por regras individuais. Essas estimativas são feitas usando as taxas estimadas de falsos positivos das pontuações de risco de machine learning correspondentes, que calculamos com experimentos em toda a rede Stripe.
- Est. fraudes em pagamentos evitadas: o número estimado de fraudes em pagamentos evitadas pelas regras de bloqueio. A Stripe usa pontuações de risco de machine learning, calculadas ao analisar milhões de transações em toda a rede da Stripe , para prever os pagamentos com alta probabilidade de contestação ou recusa por fraude e estimar quais desses pagamentos foram bloqueados corretamente pelas regras.
Clique em uma regra de bloqueio para ver as seguintes métricas:
Regras de análise
Nas regras de análise, os usuários do Radar for Fraud Teams visualizam:
- Pagamentos enviados para análise: a quantidade total de pagamentos que foram enviados para análise manual por suas regras.
- Volume de análises aprovadas: a quantidade total, na sua moeda local, associada a análises de pagamentos aprovadas.
- Taxa de reembolsos: a porcentagem de análises que foram reembolsadas.
- Contestações de análises aprovadas: o número total de pagamentos que foram aprovados na sua análise, mas que no final das contas foram contestados.
- Volume de contestações de análises aprovadas: o valor total, no sua moeda local, associado a contestações de análises de pagamentos aprovados.
Clique em uma regra de revisão para ver as seguintes métricas:
Monitore regularmente sua fila de análise manual
Se a sua fila de análises estiver ficando longa demais, verifique se está aplicando regras adequadas. Se a maior parte das análises forem reembolsadas por fraude, pode ser recomendável acrescentar algumas regras para bloquear pagamentos. Já se a maioria dos pagamentos for aprovada, pode ser melhor restringir as regras de análise.
Analise seus pagamentos contestados e reembolsados
As contestações são inerentemente vinculadas às fraudes, por isso, quanto mais você reduzir as fraudes, menor será a taxa de contestações. Verifique se os pagamentos contestados têm características similares (por exemplo, dos mesmos locais ou de valores similares). Também é possível realizar esse tipo de investigação analisando pagamentos que foram reembolsados durante uma análise. Se você identificar tendências, poderá testar e criar as regras apropriadas. Se os pagamentos parecerem ser fraudes, reembolse e reporte-os como fraude para evitar possíveis contestações.
Também é possível usar nossos produtos de relatórios, o Sigma e o Data Pipeline, para consultar dados de contestações e fraudes.
Você pode responder a qualquer nova contestação usando o Dashboard ou a API. A nossa documentação de contestação inclui algumas sugestões sobre como apresentar um caso bem documentado.
Antecipe grandes mudanças no seu negócio que possam impactar a taxa de fraudes
Se estiver planejando um lançamento importante de produto ou mudanças no seu serviço (por exemplo, um novo produto de alto valor ou expansão do serviço para novos países), monitore esses pagamentos no começo. Para esses tipos de mudanças, uma prática recomendada é configurar algumas regras de análise para poder examinar todos os novos pagamentos. Ao analisar esses pagamentos e identificar padrões, você conseguirá criar regras e proteger sua empresa contra fraudes.