Em resumo: Testámos o Jev, o novo modelo de Sistema Um da TypeSafe AI para avaliações rápidas entre sistemas de software, em três problemas de fraude e conformidade da Sardine. Num caso real de uma rede de fraude, detetou 93% das transações fraudulentas, contra 62% do Claude Sonnet (uma taxa de deteção 31 pontos percentuais superior), por cerca de 1/25 do custo e com ~100 ms por chamada.
- Decisões sobre redes de fraude: O Jev detectou 27 das 29 transações fraudulentas, em comparação com 26 detectadas pela nossa abordagem baseada em regras e 18 pelo Sonnet.
- Incompatibilidade entre nome e e-mail: um sinal que há anos resistia à implementação em código agora é rápido e preciso o suficiente para ser usado em uma decisão em tempo real.
- Respostas de KYB para outros softwares: O Jev agora é um nó no Sardine Flow, transformando descobertas em respostas estruturadas que o agente de um cliente pode usar.
A Sardine ajuda bancos, fintechs e empresas de pagamentos a determinar se um início de sessão, um pagamento ou uma nova conta empresarial é legítimo. Essas decisões são tomadas centenas de vezes por segundo, e cada uma tem de ser concluída numa fração de segundo, pois há um cliente à espera.
Essa restrição explica por que o setor se baseia em regras e modelos de aprendizagem automática e por que os grandes modelos de linguagem têm permanecido, em grande parte, à margem. Um LLM consegue analisar bem uma transação suspeita, mas demora vários segundos a responder e custa cerca de um cêntimo por chamada — e nenhuma dessas características é viável quando se tomam decisões sobre milhares de pagamentos por minuto.
A TypeSafe AI lançou o Jev em setembro como um tipo diferente de modelo. Foi concebido para ser chamado por software, sem qualquer intervenção humana. Envia-se-lhe um bloco de dados e uma lista de perguntas tipificadas, e o modelo devolve uma resposta por pergunta: um sim ou não acompanhado de uma probabilidade, uma opção de uma lista definida pelo utilizador ou uma posição numa escala também definida pelo utilizador. Cada chamada demora cerca de 100 milissegundos e custa uma fração de um cêntimo.
A TypeSafe AI chama-lhe um modelo de Sistema 1, em referência ao modo de pensamento rápido e intuitivo descrito por Daniel Kahneman em «Pensar, Depressa e Devagar». Uma plataforma de combate à fraude está repleta de situações em que o software precisa exatamente disso: uma avaliação rápida e consistente com base em evidências estruturadas. Testámos o Jev em três delas.
Primeiro, como a decisão final sobre uma rede de fraude; depois, como uma forma de calcular um sinal que há anos desafia qualquer implementação em código; e, por fim, como o componente que transforma uma verificação de negócio em respostas que outros softwares podem usar.
1. Detecção de transações ligadas a redes de fraude
Em setembro, um dos nossos clientes, uma plataforma de conversão de moeda fiduciária em stablecoins, lançou um novo produto e, em poucos dias, foi alvo de um grupo de fraudadores. O cliente enviou-nos os dados de cinco utilizadores que sabia serem fraudulentos. A nossa análise de ligações, que associa contas que partilham um dispositivo, um endereço de e-mail ou um cartão, ampliou essa lista para 13 utilizadores e 29 transações fraudulentas com cartão que não tinham sido detetadas.
Usamos esse incidente para comparar três formas de tomar a decisão sobre fraude nessas 29 transações.
A primeira foi a nossa abordagem atual. O nosso Agente Analista de Dados, um agente de IA que investiga incidentes criando as suas próprias consultas à base de dados, comparou o comportamento do grupo com o de milhares de utilizadores normais durante os mesmos dez dias. Constatou que o grupo utilizava, em média, quatro cartões por conta, contra 1,8 para os restantes utilizadores, e alternava entre mais do dobro de endereços IP.
Em seguida, propôs três regras de velocidade (regras que contabilizam a frequência com que algo acontece num determinado intervalo de tempo) com base nessas diferenças. Essas regras teriam detetado 26 das 29 transações, o que corresponde a uma taxa de deteção de 90%.
A segunda e a terceira abordagens partem do mesmo ponto: o código calcula os dados de cada transação, como quantos clientes diferentes compartilham este cartão ou dispositivo e quantas transações foram associadas a este e-mail na última hora. Esses dados são então fornecidos a um modelo para que ele tome a decisão. Em um dos pipelines, o modelo era o Claude Sonnet, um LLM de uso geral. No outro, era o Jev, que fazia uma única pergunta: em uma escala de baixo a muito alto, qual é o risco de esta transação estar ligada a uma rede de fraude?
O Jev detectou 27 de 29 casos, ou 93%. O LLM detectou 18, ou 62%.
A diferença se resume à consistência. Uma das contas do grupo, registrada com o nome "Jedi Force", realizou 12 transações em cerca de 100 minutos. Algumas dessas transações usaram um cartão que outra conta do grupo também havia usado, enquanto outras usaram um cartão novo.
Uma ressalva: fizemos a Jev uma única pergunta abrangente: «qual é o nível de risco de esta transação estar associada a uma rede de fraude?» Depois de discutirmos os resultados com a TypeSafe, o nosso próximo passo será decompor esta questão em perguntas mais específicas, como, por exemplo, se a conta está a apresentar um pico de atividade e se o cartão ou dispositivo está associado a outras contas. Vamos testar se isso torna as pontuações ainda mais precisas. Estes resultados são da versão com uma única pergunta.
O Jev classificou todas as 12 transações como de alto risco, dentro de uma faixa estreita, porque considerou o facto de terem ocorrido doze transações em menos de duas horas como o elemento predominante e a partilha do cartão como um pequeno agravante. O Sonnet avaliou cada transação individualmente e permitiu que a sinalização do cartão alterasse o seu veredicto em um nível completo, pelo que o mesmo pico de atividade da mesma conta resultou numa combinação de risco médio e alto. O nível mais baixo dos dois geralmente não bloqueia um pagamento.
O Jev também foi muito mais barato e rápido. As suas chamadas continham menos de mil tokens de entrada (aproximadamente uma página de texto), demoravam cerca de 100 milissegundos cada uma e, no total, as 29 decisões custaram cerca de um décimo de cêntimo. A execução com o LLM custou aproximadamente 25 vezes mais, mesmo com as 29 avaliações agrupadas num único pedido — algo que não é possível num fluxo de pagamentos em tempo real. Ao avaliar cada transação à medida que chega, um LLM teria de processar todas as instruções em cada chamada e demoraria vários segundos a responder.
O Jev não mantém estado: não tem memória entre chamadas e não consegue obter dados por conta própria, por isso tudo o que sabe sobre uma transação tem primeiro de ser calculado em código e incluído no pedido. É também por isso que as regras chegaram tão perto. A associação de contas e as contagens de frequência são responsáveis pela maior parte da deteção de fraudes e são idênticas em todos os pipelines. O que o Jev acrescenta é uma forma mais barata, rápida e consistente de transformar essas evidências numa decisão.
Essa consistência também traz benefícios nas etapas seguintes. Nossos agentes de recomendação de regras aprendem com casos rotulados, e um modelo que avalia o mesmo comportamento da mesma forma todas as vezes produz rótulos melhores do que um cujas respostas variam de uma chamada para outra — e esses rótulos se transformam em regras mais robustas.
2. Identificação de sinais suspeitos durante o onboarding
Uma conta é aberta em nome de Krista Thomason, mas o endereço de e-mail associado a ela é dylan.whitman@gmail.com. Uma pessoa identifica o problema em um segundo. Criar um código que o detecte de forma confiável tem se mostrado surpreendentemente difícil, e todas as equipes antifraude vêm tentando fazer isso há anos.
A dificuldade reside no facto de a maioria das discrepâncias ser inocente. As pessoas usam alcunhas, iniciais e nomes do meio, e cônjuges e familiares partilham um endereço. Os nomes são transliterados, reordenados e desprovidos de acentos, e uma grande parte dos endereços de e-mail não contém qualquer nome, apenas um nome de utilizador ou uma sequência de algarismos. Uma regra suficientemente rigorosa para detetar Dylan também assinala milhares de clientes legítimos.
Já tentámos resolver este problema antes, tal como quase todas as pessoas que trabalham há tempo suficiente na área da fraude, e os dois problemas foram sempre os mesmos: precisão e latência. As abordagens suficientemente precisas, incluindo recorrer a um LLM, demoravam demasiado tempo a ser executadas no âmbito de uma decisão que tem de ser concluída antes de a página carregar.
Então, passamos o problema para o Jev. A solicitação contém os campos de nome e o endereço de e-mail. A pergunta oferece três opções:
- o e-mail corresponde ao nome
- o e-mail não contém informações de nome utilizáveis
- o e-mail pertence claramente a outra pessoa.
As instruções explicitam os casos inocentes para que o modelo os considere consistentes e reservam "pessoa diferente" para e-mails que contenham o nome de outra pessoa.
Aprimoramos essa pergunta algumas vezes. Cada versão separou as contas incompatíveis das legítimas com mais precisão do que nossa abordagem anterior, e até mesmo as probabilidades padrão retornadas pelo Jev, antes de qualquer ajuste, produziram uma separação útil. Todas as respostas chegaram rápido o suficiente para serem usadas na decisão em tempo real. Em nossa ferramenta interna de testes, "Richard Anderson" associado ao e-mail de um desconhecido é identificado como uma pessoa diferente, enquanto o mesmo nome com um e-mail r.anderson é considerado consistente com 98% de confiança.
A resposta é uma feature, no sentido de aprendizagem automática: um novo sinal que as nossas regras e modelos podem utilizar em conjunto com os milhares de sinais que já têm. O plano é disponibilizá-lo da mesma forma que disponibilizamos qualquer outro dado. Seria então possível criar uma regra como «se o e-mail pertencer a outra pessoa e o cartão tiver sido adicionado na última hora, solicitar uma etapa adicional de verificação». O caso-limite ainda em aberto diz respeito aos apelidos de pessoas casadas, que podem mudar legitimamente, e estamos a trabalhar nisso antes do lançamento. Ao integrarmos o Jev no nosso motor de regras, não só podemos disponibilizar funcionalidades avançadas como esta aos nossos clientes, como também permitimos que os nossos utilizadores definam as suas próprias funcionalidades personalizadas para efetuar verificações rápidas de todo o tipo de problemas.
3. Automatização das verificações de risco de KYB
Quando mostramos esse terceiro uso à equipe da TypeSafe AI, eles o chamaram de caso de uso canônico do Jev.
Quando uma empresa solicita uma conta de comerciante ou uma conta bancária, a instituição precisa confirmar que se trata de uma empresa registrada e em atividade, entender o que ela faz e verificar possíveis sinais de alerta antes de aprovar a solicitação. O setor chama esse processo de Know Your Business, ou KYB. Nosso produto Web360 faz a coleta das informações: verifica o número de identificação fiscal e os registros estaduais da empresa, analisa seu site, realiza pesquisas na web e reúne avaliações online. Em seguida, apresenta os resultados para que um investigador possa avaliá-los.
Nos últimos meses, um número crescente de clientes tem pedido algo diferente. Eles estão criando seus próprios agentes de IA e fluxos automatizados de abertura de contas e querem que as informações encontradas pelo Web360 sejam fornecidas como respostas que seus softwares possam usar para tomar decisões.
Esta empresa tem ocorrências negativas graves, como processos judiciais ou medidas regulatórias? A atividade observada está em conformidade com a nossa política de integração? Esta é a entidade jurídica correta? Cada uma dessas questões exige sempre um campo fixo com um conjunto definido de valores.
Nossa abordagem anterior consistia em escrever manualmente a lógica da aplicação para cada pergunta. Veja, por exemplo, o histórico de reclamações. Usávamos uma heurística aplicada às avaliações do Better Business Bureau para tentar distinguir um padrão de reclamações graves de simples queixas, e cada cliente queria que isso fosse definido de uma forma ligeiramente diferente. Manter uma lógica personalizada para cada pergunta e cada cliente não é escalável.
Com o Jev, escrevemos a pergunta uma única vez, fornecemos-lhe as informações que recolhemos e recebemos uma resposta numa estrutura fixa. Adicionámos o Jev como um nó no Sardine Flow, o nosso criador de fluxos de trabalho. Agora, um fluxo pode recolher as informações nas suas primeiras etapas, fazer ao Jev um conjunto de perguntas específicas sobre essas informações e registar as respostas como etiquetas estruturadas. Numa demonstração realizada no nosso ambiente de testes, usando a própria Sardine, um fluxo que adiciona uma etapa de pesquisa na Web e pergunta «esta empresa é financiada por capital de risco?» responde afirmativamente e indica um valor superior a 100 milhões de dólares.
O mesmo pipeline de investigação agora termina de uma de duas formas. O fluxo voltado para o investigador mostra a uma pessoa tudo o que o Web360 encontrou. Já o fluxo voltado para a API — aquele que outros softwares acionam — processa as mesmas informações pelo Jev e retorna as respostas estruturadas que o agente do próprio cliente está aguardando.
Estamos finalizando a solução integrada Web360 e Jev com uma empresa da Fortune 500 como parceira de design. Um dos maiores bancos digitais do mundo também planeja usar agentes com tecnologia Jev para analisar seus alertas de conformidade e integrar os resultados aos seus próprios fluxos de trabalho.
Onde isso nos deixa
Nos três casos de uso, o Jev assumiu uma tarefa específica: tomar uma decisão com base em evidências estruturadas dentro do tempo que um cliente está disposto a esperar. Até agora, essa decisão cabia a uma pessoa, a uma heurística frágil ou a um LLM lento demais para decidir em tempo real. A coleta de dados, a vinculação de contas e as regras permanecem, pois o Jev só vê aquilo que o código coloca à sua frente.
Primeiro: testar perguntas decompostas para a pontuação de redes de fraude, seguindo as orientações da TypeSafe. A rotulagem de eventos, as recomendações de regras e a pontuação de risco têm a mesma estrutura, por isso são as próximas áreas em que pretendemos experimentar essa abordagem. Publicaremos mais informações à medida que repetirmos os experimentos em um número maior de incidentes. Se você estiver desenvolvendo sistemas de decisão com o Jev em outro domínio, gostaríamos de trocar experiências.
