Vaswani et al., Attention Is All You Need (arXiv, June 2017)
A arquitetura transformer.
O que os clientes fazem, em ordem, mostra quem pode sair e quem está pronto para mais.
Tome dois clientes que acessaram o aplicativo quatro vezes e fizeram uma transferência grande no mês passado. Em uma tabela mensal, eles parecem iguais. No primeiro caso, a transferência foi para uma conta de poupança usada há anos. No segundo, o salário foi movido para outro banco no dia em que chegou, pouco depois de um primeiro acesso a partir de um dispositivo novo. Os totais coincidem, mas as histórias são diferentes.
As equipes fazem resumos porque os modelos clássicos exigem um conjunto fixo de colunas por cliente. Todo resumo é uma decisão sobre o que esquecer: uma contagem de 30 dias não distingue um padrão estável de uma mudança brusca nos últimos três dias. Os analistas compensam com mais janelas e razões, e a lista de variáveis cresce para centenas de colunas difíceis de manter.
O transformer, apresentado em 2017 para a tradução automática, é a arquitetura por trás dos modelos de linguagem de hoje (Vaswani et al.). Um modelo de linguagem é treinado para prever a próxima palavra e, em escala, essa tarefa o leva a aprender gramática e fatos pelo caminho, porque ambos ajudam na previsão.
A mesma ideia funciona com eventos. Trate o histórico de cada cliente como uma frase cujas palavras são eventos: um pagamento com cartão, um acesso, uma transferência, uma ligação para o suporte. Um modelo treinado para prever o próximo evento, ou para preencher eventos ocultos, precisa aprender o que costuma vir depois de quê e como é uma quebra de rotina, sem que lhe digam quais variáveis calcular.
Várias empresas já publicaram essa abordagem. A Stripe descreveu um modelo de base para pagamentos treinado com dezenas de bilhões de transações e informou que ele elevou em 64% a taxa de detecção de ataques de teste de cartões em grandes empresas (TechCrunch, maio de 2025). O Nubank, no Brasil, relatou ganhos em grandes problemas de recomendação com modelos transformer treinados sobre históricos de transações que já tinha, sem novas fontes de dados (Braithwaite et al., 2025). Os modelos PRAGMA da Revolut são pré-treinados em sequências de eventos bancários e usados para pontuação de crédito, detecção de fraude e valor do cliente ao longo da vida (Ostroukhov et al., 2026).
O padrão habitual é um modelo por pergunta, para quem pode sair, quem vai contratar um empréstimo ou que limite de crédito definir, cada um com o seu pipeline, o seu monitoramento e o seu responsável. Ao longo de alguns anos, a equipe passa a manter dezenas de pipelines que descrevem os mesmos clientes de formas ligeiramente diferentes.
Um modelo treinado sobre o comportamento aprende uma única representação de cada cliente a partir dos seus eventos, e cada pergunta se torna uma tarefa menor sobre ela. O artigo do PRAGMA relata que um modelo linear simples sobre essa representação já tem bom desempenho, com ganhos adicionais após um ajuste fino leve. Uma pergunta nova passa a ser um projeto menor do que um novo pipeline, e todas as equipes trabalham com a mesma visão do cliente.
Três condições decidem se essa abordagem vai compensar. Volume significa eventos suficientes para que os padrões se repitam, e por isso pagamentos e bancos digitais são os casos mais claros. Continuidade significa que o mesmo cliente é reconhecível entre sistemas e ao longo do tempo, de modo que o seu histórico seja lido como uma única história, e não como fragmentos guardados pela plataforma de cartões, pelo aplicativo e pelo sistema central. Resultados significa um registro do que aconteceu depois de cada decisão, como se o cliente ficou ou se pagou. Se uma condição estiver faltando, comece por ela.
Cada evento precisa ter pelo menos o seu momento, até o segundo quando possível, o seu tipo, o seu valor e o seu canal. Guarde os eventos brutos além de quaisquer agregados, e um histórico longo o bastante para cobrir os ciclos lentos do seu negócio, como a sazonalidade e os prazos dos empréstimos.
Um credor com uma base de clientes modesta e fotografias mensais, ou um banco cujos registros ainda não podem ser unidos entre sistemas, normalmente tirará mais proveito de modelos clássicos e variáveis bem elaboradas. Para tabelas pequenas, o TabPFN, um modelo pré-treinado para pequenos conjuntos de dados tabulares, superou métodos anteriores em conjuntos de até 10.000 amostras nos testes de seus autores (Hollmann et al., Nature, 2025).
Nesses casos, o passo mais valioso é pôr em ordem o registro de eventos: um único identificador de cliente, marcas de tempo preservadas, resultados ligados às decisões. Esse trabalho compensa com qualquer modelo.
Um modelo treinado com dados pessoais deve ser tratado como um ativo de dados pessoais. Registre por escrito as finalidades a que pode servir e revise qualquer novo uso como faria com os dados. Controle quem pode consultá-lo, defina regras de retenção para o modelo e para os dados e teste se ele não memoriza nem revela registros individuais.
As regras variam conforme a jurisdição. Nos Emirados Árabes Unidos, diferem entre o território continental e as zonas francas financeiras, e no Brasil vale a LGPD. Envolva a assessoria jurídica desde cedo, mantenha o treinamento e a operação onde as suas obrigações exigirem e registre com quais dados cada versão do modelo foi treinada.
Compare um modelo de sequência com o atual em períodos posteriores que ele não viu, com a antecedência de que a equipe precisa, e verifique se as taxas previstas correspondem ao que acontece: se ele diz que 7 em cada 100 clientes de um grupo vão sair, cerca de 7 devem sair.
Depois, meça o resultado de negócio: clientes retidos ou produtos contratados no grupo em que a sua equipe agiu, em comparação com um grupo de controle que ela não contatou, e conte os pipelines separados que a nova abordagem substitui.
Escolha uma pergunta com um responsável claro e resultados registrados, como quem pode sair no próximo trimestre, e rode a nova abordagem ao lado da atual antes de ampliar.
A Mantika Tessera, construída sobre modelos transformer, lê em ordem os eventos de cada cliente e prevê quem pode sair e quem está pronto para mais; a sua equipe escolhe o que fazer.
A arquitetura transformer.
Treinamento com dezenas de bilhões de transações; taxa de detecção de ataques de teste de cartões em grandes empresas 64% maior.
Modelos transformer sobre históricos de transações; ganhos em problemas de recomendação sem novas fontes de dados.
Modelos de base para sequências de eventos bancários, usados para pontuação de crédito, detecção de fraude e valor do cliente ao longo da vida.
TabPFN; resultados em conjuntos de dados de até 10.000 amostras.