O Analista que Gritava 'Lobo!': Como Deixamos de Combater Alertas e Passamos a Pensar em Fraude de Forma Diferente

Olá, Habr! Aqui é Vladimir Syropyatov, Analista Sênior na Garage Eight. Todos nós ouvimos contos de fadas na infância, certo? Bem, eu gostaria de relembrar um deles – sobre o menino e os lobos. Na história, o menino gritava 'Lobo!' em falso com tanta frequência que os moradores da vila pararam de reagir aos avisos. E quando os lobos realmente apareceram, ninguém acreditou nele. Eu digo tudo isso porque, no combate à fraude (antifraud), essa história se repete regularmente. A única diferença é que, em vez do menino, temos um sistema de monitoramento; em vez da vila, uma equipe operacional; e em vez dos lobos, a fraude real que 'se aproxima' sorrateiramente enquanto todos estão ocupados com alarmes falsos. Essa foi exatamente a situação que encontrei em uma plataforma de gestão de investimentos quando cheguei lá como analista antifraude.

Neste artigo, contarei como um sistema de monitoramento sobrecarregado nos levou a um modelo de busca preventiva de fraudadores através de grafos de conexão.

Ato Um: O Sistema Contra Si Mesmo

O que me esperava no local Assim que me juntei à equipe da plataforma de investimentos, comecei a estudar a estrutura do sistema de monitoramento. Parecia bastante robusto: dezenas de regras para cada critério de fraude conhecido – desde grandes saques e atividades atípicas até a mudança de dados de pagamento e frequência anormal de operações. Para cada ameaça específica, existia sua própria regra tecnicamente correta. Se padrões específicos eram detectados no comportamento dos usuários, o sistema gerava alertas. No entanto, como todos os critérios operavam em total isolamento uns dos outros, eles apareciam separadamente na fila geral. Por exemplo, se o sistema considerava um usuário suspeito com base em quatro sinais, ele enviava quatro alertas ao operador em vez de um único com todos os critérios consolidados. Para entender que se tratava do mesmo caso, era preciso analisar todas as linhas – o que, é claro, ninguém fazia. E a fila não permitia isso. Embora, se o operador visse todas as regras violadas pelo usuário de uma vez, ele poderia tomar uma decisão diferente. Parte dos critérios se sobrepunha. Imagine: um critério dispara um grande saque, outro – um saque acima do valor médio histórico para um sistema de pagamento específico. Para um cliente com um ticket médio alto, o alerta seria acionado duas vezes, o que apenas aumentaria a fila de solicitações. Havia também regras historicamente desatualizadas: por exemplo, um cliente verificado com mais de um ano de histórico recebia automaticamente uma prioridade de fraude reduzida para vários critérios, pois já era considerado confiável. Mas, nesse caso, o sistema perdia um detalhe muito importante: um fraudador pode assumir o controle de qualquer conta, mesmo que o usuário opere na plataforma há cinco anos. Assim, o invasor ganhava uma chance de se esconder temporariamente do sistema de monitoramento.

O que acontecia com a equipe O departamento operacional recebia diariamente um fluxo aparentemente interminável de alertas, que eram priorizados apenas por critérios subjetivos dos operadores. Pela manhã, a equipe se afogava na fila, lidando com tudo o que se acumulava durante a noite – essencialmente trabalhando em regime de emergência, especialmente após feriados e grandes eventos. Ao mesmo tempo, a carga de trabalho durante o dia era irregular. Processar todos os alertas de forma oportuna era fisicamente impossível, então a equipe desenvolveu uma estratégia informal – lidar primeiro com o que parecia mais perigoso. Inicialmente, prestar atenção a grandes somas, se houvesse tempo – a padrões familiares, e depois a alertas incomuns. Mas estes últimos muitas vezes não eram abordados, e em alguns casos poderiam ser os mais sérios, mesmo que à primeira vista, isoladamente de outros critérios, não parecessem ser.

Por que não é possível simplesmente limpar os alertas Quando você vê um sistema tão sobrecarregado, a primeira coisa que você quer fazer é limpá-lo: remover duplicatas, aumentar os limites (thresholds), adicionar filtros. Eu mesmo quase segui esse caminho, mas fui parado por um detalhe: alguém, em algum momento, notou um padrão específico de fraude e escreveu uma regra exatamente para ele. É por isso que, por exemplo, se você aumentar o limite, pode perder casos limítrofes. A limpeza ajudaria a reduzir o ruído, mas não resolveria o problema principal – o fluxo irregular de tarefas com picos localizados. Os funcionários ora ficavam praticamente sem trabalho, ora se sobrecarregavam com a fila – e ainda assim descobririam sobre a fraude após o fato, na melhor das hipóteses no momento do incidente, e novamente teriam que lidar com o acúmulo em regime de emergência. Era preciso pensar em como mudar a lógica dos alertas em geral.

Ato Dois: De Alertas a Grafos

Quando o ponto de virada aconteceu Comecei a analisar casos de fraude confirmados (aqueles que já haviam sido investigados e fechados) e comecei a notar um padrão. Fraudadores raramente agiam em completo isolamento: um fraudador quase sempre tinha interseções com outros clientes. Individualmente, eles não diziam nada, mas em conjunto formavam um esquema fraudulento compreensível. Perguntei-me: e se, em vez de esperar que esses clientes conectados se tornassem fraudadores confirmados, nós os encontrássemos antecipadamente e os verificássemos antes que eles conseguissem implementar seus esquemas fraudulentos e exceder os limites de alerta?

Como o sistema funciona No final, reconfigurei o sistema de monitoramento. Agora, quando um cliente recebe o status de fraudador confirmado, o algoritmo procura todos que tiveram interseções com esse cliente. O algoritmo opera com base em um conjunto de parâmetros que defini como marcadores de conexão – uma combinação de características que distingue uma conexão significativa de uma aleatória. Os clientes encontrados não recebiam o status de fraudadores automaticamente: eles entravam na fila para verificação preventiva. Cada um tinha seu próprio contexto: de onde veio o caso, com quem houve interseções, por quais parâmetros. A equipe operacional analisava esses clientes e tomava a decisão se era um fraudador ou não. É importante notar que tais casos não criam picos de carga: eles se acumulam no sistema e são distribuídos uniformemente – a equipe os analisa em um regime planejado. Isso também muda a qualidade da análise: o operador toma decisões mais ponderadas, em vez de tentar fazer qualquer coisa apenas para limpar a fila antes do fim do turno. Em seguida, analisamos os resultados do trabalho dos operadores nos casos encontrados e, com base neles, aumentamos a precisão do modelo.

O que mudou Houve vários resultados, e nem todos foram previstos por nós:

• Os picos de carga desapareceram. Em vez de mais de 200 alertas pela manhã que precisavam ser resolvidos urgentemente, construímos um fluxo uniforme de casos. A equipe parou de começar o dia em modo de emergência.
• A qualidade das verificações aumentou. O operador vê não um alerta isolado, mas todo o histórico. Ele entende de onde veio o caso, com quem o fraudador original está conectado e por que o sistema decidiu que a conexão era significativa. O funcionário se interessa em desvendar esse nó e conduzir sua própria investigação.
• O sistema começou a encontrar fraudes de forma proativa. Parte dos clientes da fila preventiva acabou sendo fraudadores – e a verificação ajudou a prevenir incidentes antes que eles excedessem os limites.
• Surgiu feedback para o modelo. Com base no trabalho dos operadores, alteramos os critérios e seus pesos para o modelo, aumentando assim sua precisão. É por isso que cada caso confirmado da fila preventiva ajuda a aprimorar os princípios de funcionamento do modelo.

Ato Três: O Essencial sobre essa Abordagem Gostaria de chamar a atenção para os pontos mais importantes:

• A qualidade do sistema depende inteiramente da qualidade do caso inicial. Se a confirmação de um fraudador foi errônea, uma onda de verificações é iniciada a partir de um ponto falso. Para evitar isso, é preciso definir altos padrões de verificação do caso inicial – uma tarefa nada trivial.
• É preciso verificar constantemente a completude e a precisão do modelo. A completude é monitorada em casos históricos que identificamos anteriormente manual e automaticamente. A precisão é controlada por meio de verificações adicionais de casos que o modelo encontra através dos operadores.
• Interseções podem ser acidentais. Parte dos casos da fila preventiva será false-positive, e isso é normal. É importante que essa porcentagem permaneça aceitável e não crie carga adicional para a equipe.

Epílogo Esquemas fraudulentos geralmente têm características distintas: métodos semelhantes, ferramentas comuns, às vezes conexões diretas entre os participantes. Se você encontrar o ponto de entrada, terá a oportunidade de desvendar todo o emaranhado de fraudes. Graças à abordagem preventiva, você não buscará os sintomas do problema, mas as condições potenciais sob as quais ele pode se manifestar. E vamos voltar ao conto do menino. Se ele não tivesse gritado 'Lobo!' sem motivo, mas tivesse estudado os rastros e preparado armadilhas com antecedência, a história teria terminado de forma diferente. Foi o que fizemos: paramos de gritar 'Lobo!' após cada alerta e começamos a procurar as trilhas dos lobos. Se você trabalhou com tarefas semelhantes, ficarei feliz em discuti-las nos comentários. Especialmente a questão sobre o dimensionamento do grafo: onde você traça a linha? Como evitar que a fila preventiva cresça ao mesmo tamanho da antiga sistema de alertas?