Imagine, por um momento, que uma equipa de combate à fraude deteta um novo ataque numa segunda-feira. A regra que o impede só chega ao ambiente de produção uma semana depois, por vezes duas, e, durante todo esse período, o atacante esteve a criar contas ou a esvaziá-las. A explicação habitual para esses dias perdidos é a passagem do trabalho para a equipa de engenharia: o analista que concebe a solução entrega-a a uma equipa distinta, responsável pelo ambiente de produção; a solução fica numa fila, atrás de outras tarefas; e cada passagem de responsabilidade ao longo do processo acrescenta mais tempo.
Acreditávamos nesse diagnóstico, e ele está parcialmente correto, por isso passámos anos a eliminar essa transferência de responsabilidade da nossa plataforma. Os analistas criam e implementam regras diretamente a partir do painel, sem terem de abrir um pedido. As implementações de modelos passam por um pipeline automatizado, e os testes estão integrados em ambos os processos, pelo que uma alteração que antes esperava dias por uma janela de implementação pode agora entrar em produção em poucos minutos.
Esse trabalho deu frutos, e eu faria o mesmo investimento novamente. As implementações que levavam dias agora levam minutos, e essa é a parte da infraestrutura cujo impacto os clientes sentem primeiro. Esse trabalho também revelou a limitação que estava por trás disso: mesmo sem a transferência entre equipes, o tempo entre a detecção de um ataque e a aplicação de uma correção em produção ainda era medido em dias, o que significava que, desde o início, a maior parte desse tempo não era gasta nessa transferência. Só conseguimos perceber isso depois de eliminar o gargalo conhecido.
Onde o tempo é gasto durante o ciclo de resposta a fraudes
Demorámos algum tempo a perceber isto claramente, em parte porque a fase mais lenta se situa entre duas funções, e não dentro de qualquer uma delas. Uma investigação produz uma teoria sobre um ataque. Os testes transformam essa teoria num controlo que pode ser implementado. A ligação entre estas duas fases — em que uma teoria tem de ser verificada com base nos seus dados reais antes de alguém a implementar — consumia a maior parte do tempo disponível.
Há alguns problemas distintos nessa lacuna, e vale a pena analisá-los separadamente, pois cada um deles resiste a um tipo diferente de automação.
Os dados de sinais de fraude chegaram a ser capturados?
A primeira parte do tempo é dedicada a confirmar que os dados existem. Um analista quer testar se um determinado sinal do dispositivo permite distinguir o ataque do tráfego normal e, antes que qualquer teste possa ser realizado, alguém precisa explicar por que esse campo está vazio em um terço dos eventos. Esses dados chegaram a ser coletados para esse segmento de tráfego? Alguma integração com um fornecedor deixou de funcionar em algum momento sem que ninguém percebesse? Ou seria a explicação mais banal: o campo só é preenchido para clientes que usam uma versão mais recente do SDK, de modo que metade da população afetada fica invisível para a regra.
Essas perguntas parecem básicas. Respondê-las exige saber como cada campo é gerado, o que, na maioria das organizações, significa encontrar uma das poucas pessoas que detêm esse conhecimento. Nenhuma das automações de implantação que criamos abrange esse trabalho, pois ele acontece muito antes de haver algo para implantar.
O problema da rotulagem de fraudes
A segunda parte diz respeito aos rótulos, e os rótulos em casos de fraude são uma confusão de uma forma que as pessoas de fora da área tendem a subestimar.
Um estorno pode levar semanas a chegar. Uma denúncia de fraude pode nunca chegar a ser feita, pois depende de um comerciante, de um banco parceiro ou de a vítima reparar em algo e dar-se ao trabalho de apresentar uma denúncia. E os seus próprios controlos limitam os dados disponíveis: as transações que bloqueou — as decisões em que tinha mais confiança — não geram qualquer feedback, porque um pagamento bloqueado não produz nenhum resultado com o qual se possa aprender.
Portanto, antes que um analista possa avaliar uma regra proposta, ele precisa dedicar um tempo considerável para determinar o que de fato constitui a verdade fundamental para esse ataque. O backtest leva uma hora. Decidir se o resultado é confiável leva dias.
Vazamento de dados no backtest de fraude
O modo de falha que mais me preocupa é o vazamento de dados: uma regra ou um modelo apresenta bom desempenho no backtest porque informações sobre o resultado vazaram para a avaliação, mas depois fracassa em produção. Às vezes, uma variável só existia em retrospectiva. Outras vezes, a janela de rotulagem se sobrepõe à janela de avaliação de uma forma que ninguém percebeu.
O que torna isso perigoso é a rapidez com que acontece. A regra é aprovada na revisão, entra em produção e começa imediatamente a tomar decisões automatizadas. Assim, uma falha que seria revelada aos poucos em um processo manual acaba se agravando em questão de horas. Já vimos casos em que reverter os danos levou mais tempo do que lidar com o ataque original.
Detectar isso antes da implantação exige uma infraestrutura de diagnóstico e uma boa dose de paranoia. Ambos os custos recaem justamente nessa zona de transição entre a investigação e os testes.
O que isso significa se você estiver adquirindo agentes de IA para operações antifraude
A maioria das ferramentas de IA agêntica para combate a fraudes é promovida com base na velocidade, e a rapidez oferecida geralmente se concentra nas extremidades do ciclo: criação mais rápida de regras e implantação mais rápida. Se o seu mecanismo de regras for razoavelmente bom, essas etapas já eram rápidas — e era exatamente essa a nossa situação.
Os ganhos que realmente observamos vêm do uso de agentes nas etapas intermediárias, e isso só funciona quando existe a infraestrutura subjacente necessária:
- Vinculação de entidades, o que, na prática, significa contar com recursos de grafos, para que um agente que esteja delimitando uma rede de fraude possa percorrer as conexões em vez de tentar adivinhá-las
- Modelos de dados organizados subjacentes porque um agente não consegue combinar dados fragmentados de forma mais confiável do que um analista
- Rótulos com proveniência conhecida, para que a avaliação de uma regra se baseie em dados verídicos que você defenderia
- Contexto associado a cada sinal: o que gera o campo e quando ele deixa de ser confiável
Sem esse trabalho de base, um agente chega a conclusões à velocidade de uma máquina, com os mesmos pontos cegos que os seus analistas tinham.
Um princípio tem-nos ajudado repetidamente neste contexto: tudo o que criamos para agentes tem de funcionar também para uma pessoa através da mesma interface. Passámos anos a desenvolver ferramentas de investigação para pessoas antes de as disponibilizarmos aos agentes, e as lições desse período — onde os dados enganam e que ligações entre entidades induzem em erro — estão incorporadas naquilo que os agentes utilizam atualmente.
Verifique o seu próprio ciclo de implementação de regras antifraude
Chen já escreveu neste blog sobre o ciclo de reação — o tempo entre a identificação de uma falha e a implementação de uma correção — como a métrica que uma equipa de combate à fraude deve acompanhar. Do ponto de vista da engenharia, acrescentaria o seguinte: ao analisar onde foi gasto o tempo nos últimos incidentes, é provável que a resposta esteja numa etapa que ninguém tem procurado otimizar. No nosso caso, era a transição entre a investigação e os testes, e foi a eliminação de todos os obstáculos nas etapas seguintes que tornou essa transição visível.
O que é a implementação de regras antifraude e por que ela é importante para as equipes de prevenção a fraudes?
A implementação de regras antifraude é o processo de levar um controlo de fraude — seja uma regra, um modelo ou um ajuste de limiar — desde a investigação, passando pelos testes, até ao ambiente de produção. É importante porque o tempo entre a identificação de um ataque e a disponibilização de uma correção em produção determina os danos que uma rede de fraude pode causar no intervalo entre a deteção e a resposta. Um processo de implementação de regras antifraude mais rápido e fiável reduz diretamente essa exposição.
O que é vazamento de dados em backtests de fraude e por que ele é perigoso?
O vazamento de dados em backtests de fraude ocorre quando informações sobre o desfecho de um evento fraudulento acabam sendo usadas na avaliação de uma regra ou de um modelo proposto, fazendo com que seu desempenho pareça melhor do que será em produção. Isso é particularmente perigoso porque uma regra aprovada devido a esse vazamento é implantada e começa imediatamente a tomar decisões automatizadas, o que significa que uma falha que um processo manual revelaria aos poucos pode se agravar em questão de horas. Detectar esse tipo de vazamento exige uma infraestrutura de diagnóstico antes da implantação, não depois.
O que é o problema da classificação de fraude?
Os rótulos de fraude são os sinais de referência que indicam a um modelo ou a uma regra se um evento passado foi fraudulento. O problema é que, no contexto de fraude, esses rótulos costumam ser incompletos, tardios ou censurados. Os estornos podem levar semanas para chegar. As denúncias de golpes podem nunca surgir. E as transações bloqueadas pelas suas regras antifraude não geram nenhum retorno sobre o resultado, pois um pagamento bloqueado não produz dados com os quais aprender. Antes que um backtest possa ser considerado confiável, um analista precisa dedicar um tempo considerável para determinar como a referência correta realmente se apresenta naquele ataque específico, o que pode levar dias, mesmo quando o backtest em si leva apenas uma hora.
O que significa, na prática, a captura de dados de sinais de fraude?
A captura de dados de sinais de fraude refere-se à verificação de que os sinais do dispositivo, comportamentais ou de rede que um analista pretende usar numa regra foram efetivamente recolhidos para a população em avaliação. Um campo presente no modelo de dados pode estar vazio para um subconjunto de eventos porque uma integração com um fornecedor deixou de ser acionada, uma diferença entre versões do SDK causou inconsistências na recolha ou o sinal nunca foi recolhido para um determinado segmento de tráfego. Confirmar isto exige conhecer a forma como cada campo é gerado — conhecimento que, na maioria das organizações, está concentrado num pequeno grupo de pessoas, em vez de estar documentado.
Onde os agentes de IA realmente ajudam nas operações de combate a fraudes?
Os agentes de IA para operações antifraude costumam ser apresentados como uma forma de acelerar as etapas periféricas do ciclo de implantação de regras de fraude, especificamente a criação e a implantação de regras. Se o mecanismo de regras já for eficiente, essas etapas já serão rápidas. Os ganhos realmente relevantes vêm do uso de agentes no meio do ciclo: vinculação de entidades para rastrear redes de fraude, modelos de dados estruturados que os agentes possam consultar de forma confiável, classificações de fraude com procedência conhecida e contexto associado a cada sinal, explicando o que o gera e quando ele deixa de ser confiável. Sem essa base, um agente produz conclusões na velocidade de uma máquina, mas com os mesmos pontos cegos que um analista humano teria.
Como as equipes antifraude devem medir o desempenho da implementação de suas regras de prevenção a fraudes?
Acompanhe todo o ciclo de resposta a fraudes, desde o momento em que um ataque é detectado até a entrada de uma correção em produção. Em seguida, identifique onde o tempo foi gasto nos últimos incidentes. Normalmente, a resposta está em uma etapa que ninguém vinha otimizando ativamente. Entre os problemas mais comuns estão lacunas na captura de dados de sinais de fraude, problemas na qualidade dos rótulos de fraude e verificações de vazamento em backtests de fraude — todos anteriores à própria implantação. Eliminar o gargalo conhecido, seja ele a transferência para a equipe de engenharia ou o pipeline de implantação, muitas vezes é o que permite revelar, pela primeira vez, o verdadeiro gargalo na detecção de fraudes.
Qual é o gargalo na detecção de fraudes que a maioria das equipes não percebe?
A maioria das equipes antifraude presume que o gargalo na detecção de fraudes seja a transferência para a equipe de engenharia, quando um analista entrega uma correção proposta a uma equipe separada, responsável pelo ambiente de produção. Eliminar essa transferência, permitindo que os próprios analistas implementem regras, é valioso, mas muitas vezes revela um gargalo mais profundo: a lacuna entre a investigação e os testes. Essa lacuna inclui verificar a captura de dados dos sinais de fraude, lidar com o problema da rotulagem de fraudes e diagnosticar o vazamento de dados nos backtests de fraude antes que qualquer regra antifraude automatizada entre em produção. Esses problemas ficam entre duas funções, em vez de pertencerem exclusivamente a uma delas, e é por isso que tendem a permanecer sem otimização por mais tempo.
