Comparando o desempenho de sistemas de prevenção a fraudes

White Paper

Com frequência, potenciais clientes nos pedem para realizar "POCs competitivas" que demonstrem o ganho em detecção de fraudes obtido ao migrar para a FraudAverse. Neste white paper, discutimos as restrições e os limites dessa abordagem.

O caso simples

Em um cenário "greenfield", em que ainda não existe nenhuma prevenção a fraudes, é relativamente simples realizar uma POC de desempenho relevante para um sistema de prevenção a fraudes. O único pré-requisito é que os registros históricos de pagamentos estejam marcados quanto a fraude, ou que exista um arquivo separado de alertas de fraude que possamos cruzar com esses registros.

Normalmente usamos 3 meses de registros de pagamentos com marcação de fraude como "conjunto de dados de treinamento" e o mês seguinte de registros sem marcação como "conjunto de dados de verificação". Com os dados de treinamento, criamos uma configuração da FraudAverse e a calibramos para os padrões de fraude do potencial cliente. Em seguida, processamos os dados de verificação na FraudAverse e registramos os alertas de fraude e os scores gerados. Comparando esses dados com as fraudes que o cliente de fato sofreu no período de verificação, é possível calcular com precisão o resultado que a FraudAverse teria alcançado. Essa abordagem também é chamada de "teste cego", pois, no período de verificação, não sabemos de antemão quais pagamentos se revelarão fraudulentos e quais não.

Normalmente pedimos que o conjunto de dados de treinamento inclua no mínimo 10.000 pagamentos fraudulentos. Com uma quantidade substancialmente menor, torna-se difícil criar um modelo de predição de fraude "estável", que "generalize" suficientemente os padrões de fraude. Em outras palavras, se o modelo não generalizar o bastante, bastaria aos criminosos alterar ligeiramente seus esquemas para escapar da detecção.

O caso padrão

Hoje, a maior parte do processamento de pagamentos já conta com algum mecanismo de prevenção a fraudes. Por isso, o cenário greenfield descrito acima se tornou raro. O caso padrão de POC, portanto, é demonstrar o desempenho que a FraudAverse pode agregar ao sistema de prevenção a fraudes já existente.

Essa abordagem tem uma falha importante: o viés estatístico presente nos dados de treinamento/verificação que conseguimos obter nesse caso. Ele está nos pagamentos rejeitados/recusados pelo mecanismo de prevenção a fraudes existente. Esses pagamentos nunca são concluídos e, portanto, em geral não há como saber se teriam se revelado legítimos ou não.

Isso limita especialmente a demonstração do desempenho da FraudAverse, que normalmente se destaca não só pela redução das perdas com fraude, mas também por uma redução substancial de falsos positivos. Em outras palavras, nunca saberemos quais pagamentos de alto risco, mas não fraudulentos, rejeitados pelo sistema existente teriam sido (corretamente) aprovados pela FraudAverse.

Por exemplo: se o cliente sofre 10 BP de fraude monetária (US$ 1 de perda com fraude a cada US$ 1.000 de volume transacionado) e o sistema de prevenção a fraudes existente captura 4 BP disso com uma taxa de falsos positivos de 1:20, e a POC mostra que a FraudAverse capturaria 2 BP adicionais (pagamentos que o sistema existente não rejeitou) com uma taxa de falsos positivos de 1:5, isso seria um indicador relevante de que substituir o sistema existente pela FraudAverse muito provavelmente aumentaria a taxa de detecção de fraudes e reduziria substancialmente os falsos positivos. Ainda assim, não há como determinar o resultado exato antes de uma migração.

O melhor caso

Se o potencial cliente precisar de dados precisos sobre o ganho que a FraudAverse proporciona, deverá operar os dois sistemas em paralelo, direcionando uma parte das transações ao sistema existente e o restante à FraudAverse. Como a FraudAverse é um serviço hospedado, o esforço é limitado: ela pode ser fornecida sem nenhum investimento em hardware ou software. Basta que o potencial cliente implemente o roteamento necessário.