Treinámos um modelo de linguagem com base em padrões de gastos, em vez de frases, e este detetou mais 35% de fraudes

Sep 10, 2026

Anúncio da Sardine.AI: «Treinámos um modelo de linguagem com dados de despesas e este detetou mais 35% de fraude», junto a uma ilustração abstrata de módulos roxos interligados.

In this page

Subscribe to newsletter

A cada poucos anos, surge uma nova tecnologia que promete transformar para sempre a detecção de fraudes. Normalmente, isso não acontece. Por isso, encaramos com uma dose saudável de ceticismo as grandes promessas sobre IA, inclusive as nossas.

Então, realizamos este experimento.

Usamos o mesmo tipo de modelo que alimenta o ChatGPT, mas, em vez de treiná-lo com textos, nós o treinamos com transações reais de cartões. Em seguida, incorporamos o que ele aprendeu ao modelo de detecção de fraudes de emissão que já usamos em produção.

Esse modelo detectou de 24% a 35% mais fraudes do que antes, mantendo a mesma proporção de transações sinalizadas como de alto risco. E fez isso sem nunca ter sido informado sobre quais transações anteriores acabaram por se revelar fraudulentas.

Esses resultados nos deixaram entusiasmados. Mas, adotando uma perspectiva mais realista, há algumas ressalvas que vale a pena destacar, pois dizem respeito à facilidade de obter os mesmos resultados em outros casos de uso.

Treinando um modelo fundacional para pagamentos

A ideia vem diretamente da forma como os grandes modelos de linguagem aprendem. Um modelo como o ChatGPT lê enormes quantidades de texto e é treinado numa tarefa simples: analisar as palavras apresentadas até ao momento e prever a seguinte. Ao repetir esse processo milhares de milhões de vezes, o modelo desenvolve uma compreensão profunda do funcionamento da linguagem.

Aplicamos a mesma abordagem aos pagamentos. O histórico do cartão de cada cliente torna-se uma sequência, com as transações organizadas pela ordem em que ocorreram. Em seguida, treinámos o modelo para analisar as transações anteriores de um cliente e prever a seguinte.

Para isso, o modelo precisa de interpretar uma transação da mesma forma que interpreta uma palavra. Assim, cada transação é decomposta nos seus vários elementos: quem é o comerciante, o que vende, qual o montante movimentado, através de que canal foi realizada e quanto tempo passou desde a última transação deste cliente. Organizado por ordem, o histórico de um cliente torna-se algo que o modelo consegue interpretar do início ao fim, tal como faria ao ler uma frase.

O que o modelo aprende com isso é o padrão de gastos de uma pessoa: em quais estabelecimentos ela compra, em que ordem, com que frequência e por quais valores. Ao repetir esse processo em milhões de transações, o modelo desenvolve uma compreensão detalhada do que é considerado normal para cada cliente.

Observe que nunca dissemos ao modelo quais transações eram fraudulentas. Fizemos isso de propósito, porque não queríamos que ele tentasse detetar diretamente as fraudes. Queríamos que aprendesse como são os gastos habituais de uma determinada pessoa, para que qualquer desvio ao padrão se destacasse por si só nesse contexto.

Para cada transação, o modelo produz então duas coisas. A primeira é um resumo numérico compacto de tudo o que o cliente fez até aquele momento, o que, em aprendizado de máquina, é chamado de embedding. A segunda é uma pontuação de "surpresa": uma medida de quão inesperada essa transação específica parece ser, considerando o histórico do cliente.

Também é importante salientar que não substituímos o nosso modelo de pontuação por uma rede neural. O nosso modelo de emissão já avalia cada transação através de árvores de decisão com gradient boosting, criadas com o XGBoost, e utiliza 77 variáveis que desenvolvemos ao longo dos anos. Os novos embeddings foram simplesmente adicionados como variáveis adicionais às 77 já existentes e, em seguida, voltámos a treinar o mesmo modelo XGBoost com o conjunto alargado.

Os resultados

Em todos os limiares testados, a inclusão dos embeddings permitiu detectar de 24% a 35% mais fraudes. Em um ponto operacional comum, no qual o 1% das transações de maior risco é sinalizado para análise, a melhoria foi de 28%.

Considerando todos os limiares simultaneamente e usando uma métrica padrão de classificação chamada AUC-PR, que recompensa o modelo por colocar as fraudes confirmadas no topo da lista, a melhoria foi de 68%.

Também verificámos até que ponto o modelo de pontuação utilizava efetivamente os embeddings ao calcular a pontuação. Quando ordenados por importância, os embeddings figuraram entre as funcionalidades em que o modelo mais se apoiava, representando mais de metade das vinte e cinco principais.

No entanto, a primeira versão que criámos teve, na verdade, um desempenho pior do que o nosso modelo existente. Fornecer a um modelo de árvores de decisão algumas centenas de novas variáveis sem nome introduz tanto ruído suscetível de o confundir quanto sinal, e foi necessário um ajuste considerável para superar esse problema. O modelo final precisou de quase o dobro das árvores de decisão do modelo de referência para tirar partido do que lhe tínhamos fornecido.

O modelo também melhorou à medida que o treinámos com dados de mais clientes. Treiná-lo com dados de vários clientes produziu resultados cerca de um terço melhores do que treiná-lo com os dados de apenas um. Ao analisar mais transações, o modelo aprende mais sobre os padrões gerais dos gastos com cartões, beneficiando assim da abrangência que uma rede partilhada permite.

Mas o resultado mais impressionante veio de um cliente que excluímos totalmente do conjunto de treino. Pegámos num portefólio cujos dados nunca tinham sido usados no treino do modelo de linguagem e construímos o respetivo modelo de emissão da mesma forma que construímos todos os outros. Os embeddings melhoraram o seu desempenho em 29%.

O modelo havia aprendido algo suficientemente geral sobre gastos com cartão para ajudar uma carteira da qual nunca tinha visto uma única transação. Curiosamente, a melhoria foi maior entre as transações que ele classificou com mais confiança como fraudulentas — justamente aquelas com maior probabilidade de serem recusadas ou bloqueadas.

Esse resultado traz um benefício prático. Como o modelo aprende com o histórico de transações, e não com classificações de fraude, um novo cliente não precisa esperar meses até acumular casos de fraude confirmados suficientes para ter um modelo minimamente eficaz. O histórico de transações de que o modelo precisa já existe no dia em que o cliente começa a usar o serviço.

O que impulsionou o aumento de desempenho

O resultado deveu-se ao formato dos dados de emissão e, em particular, a três características desses dados.

A primeira é um histórico longo e ordenado. Um titular usa o mesmo cartão várias vezes por semana durante anos, por isso o emissor acumula um registo detalhado do comportamento de cada cliente. Mais de 90% dos clientes no nosso teste tinham pelo menos 75 transações anteriores registadas. São muitos sinais, e a ordem dessas transações contém informações que um simples total nunca conseguiria transmitir.

A segunda é a pouca informação que um emissor vê sobre cada transação individual. Quando uma autorização de cartão chega ao banco emissor, o comerciante e a rede já removeram a maior parte do contexto. O banco não vê o dispositivo, a sessão de checkout nem o que foi efetivamente comprado. Vê um cartão, um valor, uma categoria de comerciante e um carimbo de data e hora.

É por isso que nosso modelo de emissão operava com apenas 77 atributos principais. Havia pouco a partir do qual criar mais. E esse é o melhor cenário possível para essa abordagem: atributos existentes pouco abrangentes dão ao modelo de linguagem espaço para acrescentar algo que os antigos não conseguiam alcançar.

A terceira razão é que as sequências resistem a ser reduzidas a valores agregados, e é exatamente isso que as variáveis tradicionais fazem. Contam as transações dos últimos 30 dias. Calculam o valor médio. Medem até que ponto esta compra se desvia do padrão habitual do cliente. Cada uma dessas variáveis escolhe uma janela e, dentro dela, a ordem e o ritmo desaparecem.

Eis um exemplo para ajudar a ilustrar o princípio: imagine um cartão utilizado segundo uma rotina regular durante a semana — café perto do escritório todas as manhãs, compras no supermercado a caminho de casa e combustível a cada duas sextas-feiras. Numa determinada semana, o mesmo cartão é utilizado para fazer três compras de produtos eletrónicos online numa única hora, em comerciantes onde nunca tinha sido usado, a meio de um dia de trabalho.

Nenhuma agregação isolada vai detetar isto: todos os montantes estão dentro do intervalo habitual do cliente, a contagem dos últimos 30 dias parece normal e cada comerciante, por si só, não tem nada de invulgar. O que destoa é a sequência, a ordem dos tipos de comerciantes e a quebra de um padrão que o cliente mantém há meses.

Um modelo sequencial nunca precisa escolher uma janela. Ele analisa todo o histórico ordenado e determina por si só quais eventos passados fornecem informações sobre o próximo.

Ele também lida com aspectos que nenhum engenheiro de atributos pensaria em criar. Os nomes dos estabelecimentos são inconsistentes. "HARBOR COFFEE #4471" e "Harbor Coffee Co" são a mesma loja para uma pessoa, mas duas sequências de caracteres sem relação para um computador. Um modelo de sequência aprende a tratá-los como um só, porque as compras em ambos apresentam padrões semelhantes nos dados: valores parecidos, horários semelhantes e os mesmos tipos de transações ao redor delas.

É claro que se pode argumentar que tudo o que o modelo fundacional produz poderia, em princípio, ser desenvolvido manualmente. O problema é o custo. São necessários meses de trabalho de pessoas que entendem tanto de fraude quanto de dados — justamente os profissionais mais escassos em qualquer equipe de risco. E os recursos ainda precisam de manutenção muito tempo depois de serem criados.

Onde esperamos que ele deixe a desejar

A conclusão mais óbvia é que os modelos fundacionais são o futuro da detecção de fraudes em um sentido mais amplo, não apenas para a emissão de cartões. No entanto, as mesmas características que fizeram com que funcionassem tão bem nesse contexto são justamente o motivo pelo qual somos cautelosos em relação a outros casos de uso.

Dois fatores determinam se vale a pena analisar sequências: a quantidade de histórico acumulado por conta e o nível de detalhe obtido em cada evento. A emissão de cartões é o caso extremo de um histórico extenso com poucos detalhes. Mas outros casos de uso de detecção de fraude são completamente diferentes.

Um comerciante ou adquirente vê praticamente o inverso. Quando alguém finaliza uma compra num site de comércio eletrónico, o comerciante vê o dispositivo, a sessão, os artigos no carrinho, a morada de entrega e a identidade apresentada no momento da compra. Estes conjuntos de características já são abrangentes e maduros. E, mesmo que os compradores visitem esse site com frequência, o número médio de visitas está certamente longe das 75, pelo que há muito pouco histórico para analisar. Como há mais detalhes em cada evento e menos histórico por conta, acreditamos que os modelos fundacionais baseados em sequências provavelmente não teriam um desempenho tão bom nestes casos de utilização.

O onboarding e a finalização de compra como convidado estão no extremo oposto. Há apenas um evento, sem qualquer histórico anterior. Não há nenhuma sequência para analisar, portanto essa abordagem não tem nada a acrescentar.

As carteiras digitais e os aplicativos de movimentação de dinheiro ficam em algum ponto intermediário. As pessoas fazem transações com frequência suficiente para acumular algum histórico, e o provedor tem acesso a mais informações sobre cada evento do que um emissor.

No entanto, para o caso de uso de emissão, esta abordagem funciona muito bem. Os dados brutos são escassos e permitem apenas um conjunto reduzido de atributos, pelo que a adição de um novo conjunto rico de atributos melhora naturalmente o desempenho. Quando os dados brutos já são abrangentes e os atributos existentes já captam a maior parte da informação, os mesmos embeddings têm menos a acrescentar.

Da pesquisa à produção

Ainda há dois desafios a resolver antes que algo assim possa funcionar num ambiente real e regulamentado, e são precisamente eles que, muito provavelmente, determinarão onde poderá ser implementado.

O primeiro é a explicabilidade. Quando uma característica tradicional determina uma decisão, é possível identificá-la: esta transação foi sinalizada porque o valor era dez vezes superior ao habitual para o cliente. Quando o que determina a decisão é a 192.ª dimensão de um embedding, não há nada que se possa identificar.

Mas esse número significa o que quer que o modelo tenha decidido que ele deveria significar, e os seres humanos não conseguem inferir nenhum significado a partir dele. Em um setor regulamentado, essa falta de explicação é um obstáculo intransponível.

A segunda é a latência. Processar todo o histórico de um cliente por meio de um modelo fundacional no exato momento em que uma transação exige execução em tempo real não é uma tarefa para a qual esses modelos são otimizados. A abordagem habitual é calcular os embeddings antecipadamente e armazená-los, trocando um pouco de atualidade por muito mais velocidade. Essa troca parece aceitável neste caso, pois uma transação a mais praticamente não altera o panorama de seis meses dos hábitos de consumo de uma pessoa.

Embora tenhamos ideias sólidas sobre como abordar essas questões, elas foram intencionalmente deixadas de fora da fase de pesquisa. Agora, com a prova de conceito concluída com sucesso, estamos avançando para colocá-la em produção, preparando-a para a implantação em ambiente real.

Os modelos fundacionais são o futuro da detecção de fraudes?

Voltando ao ceticismo com que começámos: no que diz respeito à emissão, e com base nos dados de que dispomos, esta abordagem demonstra o seu valor — permite detetar até mais um terço das fraudes graças a melhores dados de entrada para um modelo em que já confia, sem que sejam necessários dados de fraude previamente classificados.

Mas, à medida que nos afastamos da emissão e avançamos para conjuntos de atributos mais ricos e históricos mais curtos, esperamos que a vantagem diminua, talvez até desaparecer. Essa é uma linha de investigação que continuamos a explorar ativamente.

Portanto, antes de perguntar se um modelo fundacional é a opção certa para você, há uma pergunta mais simples a responder primeiro: como são, de fato, os seus dados?

O que você acabou de ler é a versão resumida. O whitepaper completo, Como construir um modelo fundacional de risco, foi escrito para as equipes responsáveis por desenvolver esse tipo de solução. Ele apresenta o método completo, para que seus próprios cientistas de dados possam segui-lo, os resultados integrais para cada limiar, a análise de quanto histórico o modelo realmente precisa e uma avaliação franca das questões em aberto, desde a explicabilidade e a latência até os experimentos que ainda não realizamos.

Se você está avaliando se uma abordagem como esta é adequada para a sua organização, encontre todos os detalhes aqui.

--- title: Treinámos um modelo de linguagem com base em padrões de gastos, em vez de frases, e este detetou mais 35% de fraudes source_page: https://www.sardine.ai/pt/blog/foundation-model-issuer-fraud-detection canonical: https://www.sardine.ai/pt/blog/foundation-model-issuer-fraud-detection format: text/markdown date: 2026-09-10T17:00:00.000Z author: Chen Zamir description: Como o treinamento de um modelo no estilo de um LLM com sequências de transações de cartão, seguido de sua integração a um modelo de detecção de fraude na emissão, permitiu identificar até 35% mais fraudes sem usar dados rotulados. --- **Quick links:** [Human page](https://www.sardine.ai/pt/blog/foundation-model-issuer-fraud-detection) · [Home](https://www.sardine.ai) · [Customers](https://www.sardine.ai/pt/customers) · [Blog](https://www.sardine.ai/pt/blog) · [Demo](https://www.sardine.ai/pt/demo) --- # Treinámos um modelo de linguagem com base em padrões de gastos, em vez de frases, e este detetou mais 35% de fraudes **Author:** Chen Zamir · **Published:** 2026-09-10T17:00:00.000Z · **Categories:** Fraud, Payments, Agentic AI Como o treinamento de um modelo no estilo de um LLM com sequências de transações de cartão, seguido de sua integração a um modelo de detecção de fraude na emissão, permitiu identificar até 35% mais fraudes sem usar dados rotulados. A cada poucos anos, surge uma nova tecnologia que promete transformar para sempre a detecção de fraudes. Normalmente, isso não acontece. Por isso, encaramos com uma dose saudável de ceticismo as grandes promessas sobre IA, inclusive as nossas. Então, realizamos este experimento. Usamos o mesmo tipo de modelo que alimenta o ChatGPT, mas, em vez de treiná-lo com textos, nós o treinamos com transações reais de cartões. Em seguida, incorporamos o que ele aprendeu ao modelo de detecção de fraudes de emissão que já usamos em produção. Esse modelo detectou de 24% a 35% mais fraudes do que antes, mantendo a mesma proporção de transações sinalizadas como de alto risco. E fez isso sem nunca ter sido informado sobre quais transações anteriores acabaram por se revelar fraudulentas. Esses resultados nos deixaram entusiasmados. Mas, adotando uma perspectiva mais realista, há algumas ressalvas que vale a pena destacar, pois dizem respeito à facilidade de obter os mesmos resultados em outros casos de uso. Treinando um modelo fundacional para pagamentos A ideia vem diretamente da forma como os grandes modelos de linguagem aprendem. Um modelo como o ChatGPT lê enormes quantidades de texto e é treinado numa tarefa simples: analisar as palavras apresentadas até ao momento e prever a seguinte. Ao repetir esse processo milhares de milhões de vezes, o modelo desenvolve uma compreensão profunda do funcionamento da linguagem. Aplicamos a mesma abordagem aos pagamentos. O histórico do cartão de cada cliente torna-se uma sequência, com as transações organizadas pela ordem em que ocorreram. Em seguida, treinámos o modelo para analisar as transações anteriores de um cliente e prever a seguinte. Para isso, o modelo precisa de interpretar uma transação da mesma forma que interpreta uma palavra. Assim, cada transação é decomposta nos seus vários elementos: quem é o comerciante, o que vende, qual o montante movimentado, através de que canal foi realizada e quanto tempo passou desde a última transação deste cliente. Organizado por ordem, o histórico de um cliente torna-se algo que o modelo consegue interpretar do início ao fim, tal como faria ao ler uma frase. O que o modelo aprende com isso é o padrão de gastos de uma pessoa: em quais estabelecimentos ela compra, em que ordem, com que frequência e por quais valores. Ao repetir esse processo em milhões de transações, o modelo desenvolve uma compreensão detalhada do que é considerado normal para cada cliente. Observe que nunca dissemos ao modelo quais transações eram fraudulentas. Fizemos isso de propósito, porque não queríamos que ele tentasse detetar diretamente as fraudes. Queríamos que aprendesse como são os gastos habituais de uma determinada pessoa, para que qualquer desvio ao padrão se destacasse por si só nesse contexto. Para cada transação, o modelo produz então duas coisas. A primeira é um resumo numérico compacto de tudo o que o cliente fez até aquele momento, o que, em aprendizado de máquina, é chamado de embedding. A segunda é uma pontuação de "surpresa": uma medida de quão inesperada essa transação específica parece ser, considerando o histórico do cliente. Também é importante salientar que não substituímos o nosso modelo de pontuação por uma rede neural. O nosso modelo de emissão já avalia cada transação através de árvores de decisão com gradient boosting, criadas com o XGBoost, e utiliza 77 variáveis que desenvolvemos ao longo dos anos. Os novos embeddings foram simplesmente adicionados como variáveis adicionais às 77 já existentes e, em seguida, voltámos a treinar o mesmo modelo XGBoost com o conjunto alargado. Os resultados Em todos os limiares testados, a inclusão dos embeddings permitiu detectar de 24% a 35% mais fraudes. Em um ponto operacional comum, no qual o 1% das transações de maior risco é sinalizado para análise, a melhoria foi de 28%. Considerando todos os limiares simultaneamente e usando uma métrica padrão de classificação chamada AUC-PR, que recompensa o modelo por colocar as fraudes confirmadas no topo da lista, a melhoria foi de 68%. Também verificámos até que ponto o modelo de pontuação utilizava efetivamente os embeddings ao calcular a pontuação. Quando ordenados por importância, os embeddings figuraram entre as funcionalidades em que o modelo mais se apoiava, representando mais de metade das vinte e cinco principais. No entanto, a primeira versão que criámos teve, na verdade, um desempenho pior do que o nosso modelo existente. Fornecer a um modelo de árvores de decisão algumas centenas de novas variáveis sem nome introduz tanto ruído suscetível de o confundir quanto sinal, e foi necessário um ajuste considerável para superar esse problema. O modelo final precisou de quase o dobro das árvores de decisão do modelo de referência para tirar partido do que lhe tínhamos fornecido. O modelo também melhorou à medida que o treinámos com dados de mais clientes. Treiná-lo com dados de vários clientes produziu resultados cerca de um terço melhores do que treiná-lo com os dados de apenas um. Ao analisar mais transações, o modelo aprende mais sobre os padrões gerais dos gastos com cartões, beneficiando assim da abrangência que uma rede partilhada permite. Mas o resultado mais impressionante veio de um cliente que excluímos totalmente do conjunto de treino. Pegámos num portefólio cujos dados nunca tinham sido usados no treino do modelo de linguagem e construímos o respetivo modelo de emissão da mesma forma que construímos todos os outros. Os embeddings melhoraram o seu desempenho em 29%. O modelo havia aprendido algo suficientemente geral sobre gastos com cartão para ajudar uma carteira da qual nunca tinha visto uma única transação. Curiosamente, a melhoria foi maior entre as transações que ele classificou com mais confiança como fraudulentas — justamente aquelas com maior probabilidade de serem recusadas ou bloqueadas. Esse resultado traz um benefício prático. Como o modelo aprende com o histórico de transações, e não com classificações de fraude, um novo cliente não precisa esperar meses até acumular casos de fraude confirmados suficientes para ter um modelo minimamente eficaz. O histórico de transações de que o modelo precisa já existe no dia em que o cliente começa a usar o serviço. O que impulsionou o aumento de desempenho O resultado deveu-se ao formato dos dados de emissão e, em particular, a três características desses dados. A primeira é um histórico longo e ordenado. Um titular usa o mesmo cartão várias vezes por semana durante anos, por isso o emissor acumula um registo detalhado do comportamento de cada cliente. Mais de 90% dos clientes no nosso teste tinham pelo menos 75 transações anteriores registadas. São muitos sinais, e a ordem dessas transações contém informações que um simples total nunca conseguiria transmitir. A segunda é a pouca informação que um emissor vê sobre cada transação individual. Quando uma autorização de cartão chega ao banco emissor, o comerciante e a rede já removeram a maior parte do contexto. O banco não vê o dispositivo, a sessão de checkout nem o que foi efetivamente comprado. Vê um cartão, um valor, uma categoria de comerciante e um carimbo de data e hora. É por isso que nosso modelo de emissão operava com apenas 77 atributos principais. Havia pouco a partir do qual criar mais. E esse é o melhor cenário possível para essa abordagem: atributos existentes pouco abrangentes dão ao modelo de linguagem espaço para acrescentar algo que os antigos não conseguiam alcançar. A terceira razão é que as sequências resistem a ser reduzidas a valores agregados, e é exatamente isso que as variáveis tradicionais fazem. Contam as transações dos últimos 30 dias. Calculam o valor médio. Medem até que ponto esta compra se desvia do padrão habitual do cliente. Cada uma dessas variáveis escolhe uma janela e, dentro dela, a ordem e o ritmo desaparecem. Eis um exemplo para ajudar a ilustrar o princípio: imagine um cartão utilizado segundo uma rotina regular durante a semana — café perto do escritório todas as manhãs, compras no supermercado a caminho de casa e combustível a cada duas sextas-feiras. Numa determinada semana, o mesmo cartão é utilizado para fazer três compras de produtos eletrónicos online numa única hora, em comerciantes onde nunca tinha sido usado, a meio de um dia de trabalho. Nenhuma agregação isolada vai detetar isto: todos os montantes estão dentro do intervalo habitual do cliente, a contagem dos últimos 30 dias parece normal e cada comerciante, por si só, não tem nada de invulgar. O que destoa é a sequência, a ordem dos tipos de comerciantes e a quebra de um padrão que o cliente mantém há meses. Um modelo sequencial nunca precisa escolher uma janela. Ele analisa todo o histórico ordenado e determina por si só quais eventos passados fornecem informações sobre o próximo. Ele também lida com aspectos que nenhum engenheiro de atributos pensaria em criar. Os nomes dos estabelecimentos são inconsistentes. "HARBOR COFFEE #4471" e "Harbor Coffee Co" são a mesma loja para uma pessoa, mas duas sequências de caracteres sem relação para um computador. Um modelo de sequência aprende a tratá-los como um só, porque as compras em ambos apresentam padrões semelhantes nos dados: valores parecidos, horários semelhantes e os mesmos tipos de transações ao redor delas. É claro que se pode argumentar que tudo o que o modelo fundacional produz poderia, em princípio, ser desenvolvido manualmente. O problema é o custo. São necessários meses de trabalho de pessoas que entendem tanto de fraude quanto de dados — justamente os profissionais mais escassos em qualquer equipe de risco. E os recursos ainda precisam de manutenção muito tempo depois de serem criados. Onde esperamos que ele deixe a desejar A conclusão mais óbvia é que os modelos fundacionais são o futuro da detecção de fraudes em um sentido mais amplo, não apenas para a emissão de cartões. No entanto, as mesmas características que fizeram com que funcionassem tão bem nesse contexto são justamente o motivo pelo qual somos cautelosos em relação a outros casos de uso. Dois fatores determinam se vale a pena analisar sequências: a quantidade de histórico acumulado por conta e o nível de detalhe obtido em cada evento. A emissão de cartões é o caso extremo de um histórico extenso com poucos detalhes. Mas outros casos de uso de detecção de fraude são completamente diferentes. Um comerciante ou adquirente vê praticamente o inverso. Quando alguém finaliza uma compra num site de comércio eletrónico, o comerciante vê o dispositivo, a sessão, os artigos no carrinho, a morada de entrega e a identidade apresentada no momento da compra. Estes conjuntos de características já são abrangentes e maduros. E, mesmo que os compradores visitem esse site com frequência, o número médio de visitas está certamente longe das 75, pelo que há muito pouco histórico para analisar. Como há mais detalhes em cada evento e menos histórico por conta, acreditamos que os modelos fundacionais baseados em sequências provavelmente não teriam um desempenho tão bom nestes casos de utilização. O onboarding e a finalização de compra como convidado estão no extremo oposto. Há apenas um evento, sem qualquer histórico anterior. Não há nenhuma sequência para analisar, portanto essa abordagem não tem nada a acrescentar. As carteiras digitais e os aplicativos de movimentação de dinheiro ficam em algum ponto intermediário. As pessoas fazem transações com frequência suficiente para acumular algum histórico, e o provedor tem acesso a mais informações sobre cada evento do que um emissor. No entanto, para o caso de uso de emissão, esta abordagem funciona muito bem. Os dados brutos são escassos e permitem apenas um conjunto reduzido de atributos, pelo que a adição de um novo conjunto rico de atributos melhora naturalmente o desempenho. Quando os dados brutos já são abrangentes e os atributos existentes já captam a maior parte da informação, os mesmos embeddings têm menos a acrescentar. Da pesquisa à produção Ainda há dois desafios a resolver antes que algo assim possa funcionar num ambiente real e regulamentado, e são precisamente eles que, muito provavelmente, determinarão onde poderá ser implementado. O primeiro é a explicabilidade. Quando uma característica tradicional determina uma decisão, é possível identificá-la: esta transação foi sinalizada porque o valor era dez vezes superior ao habitual para o cliente. Quando o que determina a decisão é a 192.ª dimensão de um embedding, não há nada que se possa identificar. Mas esse número significa o que quer que o modelo tenha decidido que ele deveria significar, e os seres humanos não conseguem inferir nenhum significado a partir dele. Em um setor regulamentado, essa falta de explicação é um obstáculo intransponível. A segunda é a latência. Processar todo o histórico de um cliente por meio de um modelo fundacional no exato momento em que uma transação exige execução em tempo real não é uma tarefa para a qual esses modelos são otimizados. A abordagem habitual é calcular os embeddings antecipadamente e armazená-los, trocando um pouco de atualidade por muito mais velocidade. Essa troca parece aceitável neste caso, pois uma transação a mais praticamente não altera o panorama de seis meses dos hábitos de consumo de uma pessoa. Embora tenhamos ideias sólidas sobre como abordar essas questões, elas foram intencionalmente deixadas de fora da fase de pesquisa. Agora, com a prova de conceito concluída com sucesso, estamos avançando para colocá-la em produção, preparando-a para a implantação em ambiente real. Os modelos fundacionais são o futuro da detecção de fraudes? Voltando ao ceticismo com que começámos: no que diz respeito à emissão, e com base nos dados de que dispomos, esta abordagem demonstra o seu valor — permite detetar até mais um terço das fraudes graças a melhores dados de entrada para um modelo em que já confia, sem que sejam necessários dados de fraude previamente classificados. Mas, à medida que nos afastamos da emissão e avançamos para conjuntos de atributos mais ricos e históricos mais curtos, esperamos que a vantagem diminua, talvez até desaparecer. Essa é uma linha de investigação que continuamos a explorar ativamente. Portanto, antes de perguntar se um modelo fundacional é a opção certa para você, há uma pergunta mais simples a responder primeiro: como são, de fato, os seus dados? O que você acabou de ler é a versão resumida. O whitepaper completo, Como construir um modelo fundacional de risco, foi escrito para as equipes responsáveis por desenvolver esse tipo de solução. Ele apresenta o método completo, para que seus próprios cientistas de dados possam segui-lo, os resultados integrais para cada limiar, a análise de quanto histórico o modelo realmente precisa e uma avaliação franca das questões em aberto, desde a explicabilidade e a latência até os experimentos que ainda não realizamos. Se você está avaliando se uma abordagem como esta é adequada para a sua organização, encontre todos os detalhes aqui.