Na Parte 1 da nossa série de artigos sobre falsos positivos, aceitamos a realidade de que o seu sistema não foi criado para relatar os próprios erros. Discutimos o uso de triangulação para contornar isso e gerar uma visão útil dos seus falsos positivos.
Agora vem o próximo problema.
Quantificar falsos positivos é apenas uma observação. Não é um plano.
Para reduzir falsos positivos de forma significativa, é preciso ir um nível mais fundo e fazer um conjunto diferente de perguntas:
- De onde eles vêm?
- Quais são impulsionados por parceiros?
- Quais são, na verdade, problemas de qualidade de dados disfarçados de risco de fraude?
- E, mais importante: por onde devemos começar?
É disso que trata esta segunda parte da série: dividir seus falsos positivos em categorias que você possa priorizar e tratar.
Como você faz isso? Tudo se resume a um processo de 7 etapas.
Fluxo A: Agrupar falsos positivos por agente e solução
Etapa 1: Quem realmente recusou o evento?
O primeiro e mais importante passo é associar cada falso positivo ao responsável que tomou a decisão.
Quando uma transação é recusada ou uma tentativa de onboarding é bloqueada, alguém ou alguma coisa disse "não."
Essa pessoa pode ser:
- Uma regra no seu sistema
- Um limite de modelo de aprendizado de máquina
- Um agente de IA
- Um analista humano em revisão manual
- Um parceiro terceirizado: um banco, emissor, adquirente ou fornecedor de serviços de prevenção a fraudes
Sem essa categorização, você tenderá a otimizar apenas o que consegue ver, geralmente suas regras e seus modelos.
É assim que as equipes passam meses ajustando regras, apenas para depois descobrir que a maior parte de suas recusas vinha de um emissor com quem nunca haviam falado.
A primeira tarefa é basicamente contábil: para cada recusa, registre qual agente tomou a decisão.
Às vezes será uma única regra. Às vezes será uma decisão baseada em um determinado limite de pontuação de modelo. Às vezes será uma intervenção manual. Às vezes será uma resposta binária vinda de um parceiro de pagamento.
Você não precisa fazer isso perfeitamente no primeiro dia; mesmo uma divisão aproximada faz uma enorme diferença.
Passo 2: Quanto do problema é causado por fatores anteriores?
Depois que você tiver esse mapa básico, poderá fazer uma pergunta que a maioria das pessoas ignora: quanto disso está realmente sob o seu controle?
Isso é particularmente importante em pagamentos com cartão, em que uma única transação pode passar por meia dúzia de intermediários antes que o emissor finalmente diga sim ou não.
Entre o titular do cartão e o banco emissor, você geralmente tem:
- O próprio comerciante ou plataforma
- Um prestador de serviços de pagamento
- Um adquirente
- Um processador adquirente
- Uma bandeira de cartão
- Um processador emissor
- E, por fim, o banco emissor
E isso sem contar os fornecedores terceirizados de prevenção a fraudes que alguns desses agentes integram às suas próprias pilhas.
Cada um desses agentes pode recusar uma transação. Cada um tem sua própria lógica de risco. Cada um contribui com seus próprios falsos positivos.
Se 60% dos seus falsos positivos são gerados por parceiros upstream, então sua esfera máxima de influência fica limitada a 40%.
Isso não significa que você deva desistir e ir embora. Significa que você deve repensar seus objetivos, como os comunica internamente e onde investe sua energia.
Você não pode ajustar regras que não são suas. Você não pode modificar modelos que nunca vê. Você não pode re-treinar o mecanismo de risco de um emissor.
Você pode, no entanto, quantificar o impacto, torná-lo visível e garantir que todos na organização entendam onde, de fato, estão os limites da sua influência. Só esse passo já evita muita frustração mais tarde.
Do ponto de vista estratégico, se você está insatisfeito com o desempenho de um parceiro e acredita que está abaixo do padrão, você sempre pode trabalhar para substituí-lo. Mas, muitas vezes, ainda haverá agentes que você não controla impactando seus falsos positivos.
Etapa 3: Identificar os piores infratores
Depois que você tiver suas decisões organizadas em categorias de alto nível, é hora de ir um nível mais fundo. Pegue cada mecanismo de decisão individual que você tiver e detalhe-os separadamente: cada regra, fluxo de trabalho, analista e agente de IA. É aqui que você precisa ser bem minucioso.
Na prática, a execução perfeita é difícil e demorada.
Concentre-se primeiro nas soluções que geram a maior parte de suas recusas. Mesmo que uma regra seja relativamente precisa, um alto volume geralmente significa que ela é uma fonte primária de falsos positivos.
Conte-os separadamente e identifique aqueles responsáveis pela maior quantidade de falsos positivos em termos absolutos. Esses são seus "quick wins", porque você terá dados suficientes para trabalhar.
Ao mesmo tempo, sua intuição pode dizer que alguns infratores estão passando despercebidos: regras legadas, políticas desatualizadas ou soluções que nunca foram devidamente validadas.
Se você suspeitar que uma regra de baixo volume está causando problemas, use a revisão manual para validar sua intuição. Você não precisa de um conjunto de dados enorme para identificar uma política com falhas.
Fluxo B: Agrupar falsos positivos por fluxo e qualidade dos dados
Etapa 4: Quem está sendo bloqueado?
Agora sabemos o que está bloqueando seus usuários, mas ainda precisamos saber de onde esses usuários estão vindo.
Mesmo na parte da stack que você controla, falsos positivos raramente são distribuídos de forma uniforme. Eles tendem a se concentrar em fluxos específicos, como:
- Celular vs. web
- iOS vs. Android
- Produto
- Forma de pagamento
- Novos vs. usuários estabelecidos
Se você olhar apenas para o agente que recusou o evento, verá uma regra ou um modelo se comportando de forma incorreta. Mas se você observar por qual fluxo o usuário passou, poderá encontrar um problema mais profundo: um fluxo específico que gera dados corrompidos ou ausentes, fazendo com que toda a sua stack falhe.
Considere um bug de integração no seu SDK móvel que envia dados de IP incorretos para cadastros no iOS. Você não percebe esse bug de imediato. O que você vê é que várias regras baseadas em geolocalização de repente passam a ter taxas de falso positivo mais altas nessa plataforma. Um modelo que usa recursos baseados em IP também parece sofrer desvio. Analistas reclamam que os eventos vindos do mobile parecem estranhos.
Se você olhar apenas para o nível das regras, vai desperdiçar semanas recalibrando modelos. Ao dividir isso por fluxo, você rapidamente percebe que a lógica está correta na web e que o problema está isolado ao fluxo de registro no iOS.
Nem sempre é um erro de dados. Pode ser que um fluxo específico concentre muitos bons usuários que se comportam de forma diferente da sua população geral, o que por si só pode aumentar os falsos positivos.
Então, depois de agrupar seus falsos positivos por ator, faça o mesmo por jornada do usuário:
- Qual superfície do produto? (por exemplo, app vs. desktop)
- Qual é a plataforma? (por exemplo, iOS vs. Android)
- Qual é o método de pagamento? (por exemplo, Apple Pay vs. cartão de crédito)
- Qual geografia? (por exemplo, mercados de nível 1 vs. mercados emergentes)
- Qual funil específico? (por exemplo, checkout como convidado vs. usuário logado)
Padrões surgirão muito rapidamente.
Passo 5: Procure explicitamente por problemas de qualidade de dados
No momento em que você começar a ver padrões por fluxo, quase sempre encontrará o mesmo culpado: a qualidade dos dados.
Às vezes, a lógica de fraude subjacente está, na verdade, correta. As regras são razoáveis. O modelo está bem calibrado. Os analistas são experientes. E, ainda assim, em um determinado segmento de tráfego, o seu desempenho despenca.
Isso geralmente acontece porque o sistema está operando com entradas corrompidas ou ausentes:
- Endereços IP padrão quando o IP real não pôde ser capturado
- E-mails de placeholder ou valores inválidos
- IDs de dispositivo que são redefinidos para nulo em algumas versões de sistema operacional
- Metadados de pagamento que nunca são repassados para um determinado método
- Tempos limite ou erros de integração com fontes de inteligência de terceiros
Um bom método para identificar rapidamente esses problemas é agrupar os pontos de dados pelo seu valor e procurar por valores que tenham uma contagem suspeitamente alta.
Etapa 6: Associar problemas de dados a soluções com mau funcionamento
Depois de identificar problemas de qualidade de dados, você terá algum trabalho de investigação pela frente.
Você precisa rastrear cada ponto de dados corrompido até os recursos que ele influencia (por exemplo, e-mail até velocidade de e-mail) e, em seguida, vincular esses recursos às suas regras ou modelos com comportamento inadequado.
Para a maioria das organizações, este exercício pode ser incrivelmente difícil, mas você tem um atalho: sua lista das principais soluções problemáticas da Etapa 3.
Faça uma correlação entre seus pontos de dados corrompidos e as entradas usadas por suas regras de pior desempenho. Você pode encontrar uma conexão oculta sem precisar passar dias analisando esquemas de dados.
Ao associar problemas de dados a soluções, você conseguirá completar o último elo da cadeia: atribuir valor a cada um desses problemas, assim como fez com seus piores casos.
Agora é hora de reunir tudo.
Unindo os dois fluxos
Etapa 7: Identifique e priorize os grupos que você deseja corrigir
Com esse mapa em mãos, a priorização se torna muito mais simples.
Você começa com categorias que são:
- Grande o suficiente para fazer diferença
- Sob o seu controle
- Não é obviamente causado por problemas de origem ou de qualidade de dados que pertençam a outro lugar
Em muitas organizações, isso significa:
- Um pequeno número de regras de alto volume e alto impacto
- Um ou dois limites de modelo que foram definidos de forma conservadora
- Políticas específicas de gestão de casos que incentivam o bloqueio excessivo
- Alguns fluxos em que o seu sistema gera problemas de dados
Essas são exatamente as áreas em que vamos nos concentrar na Parte 3, onde entraremos na mecânica de podar regras problemáticas, ajustar limites e redesenhar partes da lógica de decisão para que sejam menos impulsivas.
Esse trabalho só é eficaz porque você fez primeiro a análise da causa raiz e sabe como investir de forma inteligente.
Do mapa ao roteiro
Ao final deste processo, você deverá ter três recursos:
- Um mapa do cenário de falsos positivos detalhado por ator, fluxo e integridade dos dados
- Uma compreensão clara de quais partes do problema são de sua responsabilidade e quais são herdadas de parceiros ou de restrições arquitetônicas
- Uma lista curta de áreas de alto impacto e passíveis de correção, onde você pode começar a fazer mudanças com uma expectativa razoável de gerar resultados significativos
É isso que transforma os "falsos positivos" de uma reclamação amorfa em um fluxo de trabalho concreto.
Na Parte 3 desta série, vamos nos aprofundar nesses grupos de alto impacto e discutir as táticas específicas para resolução:
- Como decidir se uma regra com mau funcionamento deve ser desativada, flexibilizada ou enviada para revisão manual em vez de rejeição automática
- Como usar a “imagem espelhada” do seu processo de detecção de fraude para criar exclusões que eliminem falsos positivos sem abrir espaço para mais fraudes
- Como lidar com problemas de qualidade de dados que estão prejudicando o desempenho do seu sistema de prevenção a fraudes
Por fim, na Parte 4, vamos construir uma rede de segurança global: heurísticas de alto nível que ficam acima de todo o seu sistema e identificam bons usuários antes que qualquer solução subjacente (regra, modelo, agente ou humano) possa bloqueá-los por engano.
Por enquanto, se você passou de "temos falsos positivos" para "sabemos de onde a maioria deles vem e quais partes podemos realmente corrigir", você já está bem à frente da maioria das equipes.
É um bom lugar para estar.
