Os movimentos de Visa, Mastercard e Stripe nesta semana me parecem mostrar um avanço importante no uso de agentes de IA em serviços financeiros: a possibilidade de delegar tarefas que envolvem dinheiro, com regras para autorizar e acompanhar sua execução.
Na edição passada, comentei a plataforma de infraestrutura da Mastercard com a BVNK, que incluía o comércio por agentes entre suas possibilidades futuras. Nesta semana, a Mastercard apresentou uma demonstração desse uso. Visa e Stripe também trouxeram movimentos que ajudam a aprofundar a discussão: como uma empresa pode delegar tarefas financeiras a um agente e manter controle sobre sua execução?
Pagar uma fatura, contratar um serviço digital ou transferir recursos são atividades diferentes. Quando passam a ser executadas por software em nome de uma empresa, exigem clareza sobre quem autorizou, quanto pode ser gasto e como conferir o que foi feito.
As três iniciativas atacam problemas distintos. Entender essas diferenças ajuda a separar a proposta de cada produto da expectativa mais ampla sobre o futuro dos agentes.
Visa: concluir um pagamento que a empresa já aprovou
No piloto anunciado em 20 de outubro com a BILL e a Billtrust, um agente executa o pagamento de faturas já aprovadas pelo comprador em portais de fornecedores.
A BILL é uma plataforma de automação financeira que, nesse fluxo, atua do lado de quem paga. A Billtrust oferece soluções de cobrança e recebimento B2B, apoiando o fornecedor. A Visa fornece mecanismos para reconhecer o agente, proteger as credenciais de pagamento e aplicar controles vinculados à instrução do comprador.
O piloto envolve compradores que usam a BILL e fornecedores atendidos pela Billtrust. O agente conclui uma operação previamente autorizada, sem decidir se aquela conta deve ser paga. Fonte: Visa.
A oportunidade aparece em uma passagem entre sistemas. Uma empresa pode ter digitalizado a aprovação da fatura e ainda depender de alguém para entrar no portal do fornecedor e concluir o pagamento.
Automatizar essa etapa pode reduzir digitação e trabalho operacional. Para isso, o agente precisa ser reconhecido pelo sistema de quem recebe e respeitar tanto as instruções do comprador quanto as condições de aceitação do fornecedor.
Para a Visa, há também uma oportunidade comercial. O comunicado aponta a possibilidade de ampliar pagamentos com cartão a fornecedores que historicamente tinham automação concentrada em outros meios.
Minha leitura é que o piloto combina duas oportunidades: reduzir o esforço para concluir pagamentos e aumentar a participação da rede nesse fluxo. O resultado dependerá da aceitação dos fornecedores e da economia completa da operação.
Mastercard: comprar serviços para realizar uma tarefa
Na demonstração do Agent Pay for Machines, apresentada em 20 de outubro, um agente recebeu a tarefa de preparar uma campanha com orçamento aprovado. Para executá-la, contratou pesquisa e geração de imagens de dois fornecedores, realizando nove pagamentos dentro daquele limite.
O exemplo foi desenvolvido com a agência Hype. A Mastercard também abriu acesso inicial para desenvolvedores construírem e testarem experiências com a solução. Fonte: Mastercard.
Aqui, o pagamento acompanha o consumo dos serviços necessários ao trabalho. A autorização delimita uma tarefa e um orçamento, dentro dos quais o agente pode operar.
Isso pode abrir espaço para fornecedores venderem dados, imagens ou capacidade de processamento por uso. Para o comprador, a proposta é executar o trabalho sem estabelecer uma relação de cobrança separada com cada fornecedor.
A questão econômica é se essa flexibilidade compensa. Em serviços de baixo valor, o custo de cobrar, verificar e liquidar pode consumir uma parcela relevante da receita.
A demonstração mostra um caminho de implementação. O teste comercial será verificar se os compradores voltam a utilizar o modelo e se os fornecedores conseguem atendê-los com margem. O volume de transações, isoladamente, não responde a essas perguntas.
Stripe: operar o financeiro a partir do assistente
Com o Treasury for agents, anunciado em 21 de outubro, a Stripe apresentou a possibilidade de agentes consultarem saldos, pagarem faturas, transferirem recursos entre contas e converterem moedas.
O público anunciado são startups e empreendedores que utilizam o Stripe Treasury. Criação de cartões e definição de limites de gasto foram apresentadas como capacidades futuras; os limites estavam previstos para as semanas seguintes ao anúncio. Fonte: Stripe.
A proposta aproxima a execução financeira do assistente utilizado pelo empreendedor. Uma solicitação pode começar na ferramenta em que ele organiza o trabalho e resultar em uma operação na infraestrutura da Stripe.
O benefício potencial está em reduzir o esforço entre identificar uma necessidade e resolvê-la. Consultar o caixa e executar um pagamento podem passar a fazer parte de uma mesma interação, conforme as permissões e capacidades disponíveis.
Isso também muda a exigência sobre a experiência. Consultar um saldo e transferir dinheiro têm consequências diferentes. O produto precisa tornar compreensível quais ações o agente pode executar e quais exigem aprovação.
Para a Stripe, essa abordagem pode ampliar a utilização de sua infraestrutura a partir de interfaces de terceiros. A empresa continua participando da operação financeira mesmo quando o cliente inicia a tarefa em outro ambiente.
Delegar exige definir também quando o agente deve parar
Os três casos ajudam a distinguir diferentes graus de delegação.
Na Visa, o fluxo parte de um pagamento aprovado. Na demonstração da Mastercard, o agente utiliza um orçamento autorizado para contratar serviços necessários a uma tarefa. Na Stripe, o escopo abrange diferentes atividades da operação financeira.
Quanto mais ampla a tarefa, mais importante se torna definir seus limites e tornar a execução verificável.
Autorizar um agente a pagar uma fatura envolve mais do que estabelecer um teto de gasto. Em um desenho de produto, é preciso considerar quais fornecedores ele pode pagar, de qual conta saem os recursos e em quais situações deve pedir uma nova aprovação. Uma operação pode estar dentro do orçamento e ainda contrariar a intenção de quem autorizou.
Essas regras precisam ser aplicadas pelo sistema que executa a operação. Uma instrução na conversa, como “não gaste mais de mil reais”, precisa corresponder a um controle capaz de impedir uma transação fora desse limite.
Há também situações em que o problema aparece depois da tentativa. Imagine que o agente envie um pagamento, mas não receba a confirmação. Tentar novamente pode duplicar a operação; considerar a tarefa concluída pode deixar uma conta em aberto.
O produto precisa permitir verificar o estado do pagamento e encaminhar a exceção para quem pode resolvê-la. Esse é um exemplo conceitual dos desafios de execução, sem pressupor que as três iniciativas adotem o mesmo tratamento.
O registro deve conectar a autorização ao que foi feito: quem delegou, quais eram as condições, qual ação foi realizada e qual foi o resultado. Esse histórico ajuda a conferir a operação, investigar falhas e definir quem deve agir.
O ganho precisa aparecer no processo inteiro
Minha leitura é que boa parte do valor desses produtos estará na capacidade de lidar com exceções.
Se cada pagamento automatizado exigir uma conferência manual completa, parte do trabalho apenas muda de lugar. O ganho econômico aparece quando a empresa reduz o esforço total para concluir a tarefa, incluindo supervisão, correções e atendimento quando algo falha.
Eu começaria a avaliação por três perguntas: quantas tarefas terminam sem intervenção, quanto retrabalho geram e qual é o custo total por tarefa concluída.
Depois, olharia para o efeito comercial. A automação trouxe uso adicional? Gerou receita? A contribuição permanece positiva depois dos custos de processamento, suporte e correção?
Existe também uma consequência para a distribuição. Se a solicitação começa em um assistente, parte da interação pode acontecer fora do aplicativo financeiro. A instituição precisa conseguir executar bem a operação mesmo quando outra empresa oferece a interface.
Os anúncios desta semana mostram caminhos de implementação. Ainda não permitem concluir quem terá adoção ou retorno econômico superior.
Para quem desenvolve produtos financeiros, a pergunta que eu colocaria primeiro é: qual tarefa o cliente está disposto a delegar — e o que precisa funcionar para que ele confie em deixar essa execução com o software?
Outros movimentos da semana
iFood e Caju: força no consumidor e na gestão do RH
Em 20 de outubro, o iFood Benefícios anunciou um acordo para adquirir a Caju. A operação depende de aprovações regulatórias. Para mim, é uma união que faz muito sentido pela complementaridade das duas empresas. Fonte: Caju.
Durante minha passagem pelo iFood, não trabalhei com iFood Benefícios, mas participei de diversas agendas executivas em que o negócio foi apresentado e discutido. Essa proximidade ajuda a explicar meu olhar para a aquisição: vejo uma combinação de forças construídas em lados diferentes dessa relação.
O iFood traz sua força no relacionamento com o consumidor. O Clube iFood e a expansão da frente Comer Fora ampliam os motivos para usar o ecossistema em diferentes ocasiões de consumo. Comer Fora, aliás, merece uma análise própria aqui no destrincha. Na minha leitura, a Caju está mais à frente nas soluções e na experiência voltadas ao RH. Sua contribuição vai além do cartão: inclui o trabalho de quem contrata e administra os benefícios.
Essa complementaridade importa porque o mercado tem duas decisões conectadas. A empresa precisa escolher uma solução que funcione para o RH; o trabalhador precisa perceber valor no benefício que recebe. Facilitar a administração pode ajudar a conquistar e manter o contrato. Entregar uma experiência desejada por quem usa pode fortalecer essa escolha dentro da empresa.
Vejo potencial para a união impulsionar o sonho grande do iFood de se tornar o maior cartão de benefícios do país. A consolidação pode trazer escala e uma oferta mais completa, combinando a capacidade da Caju de atender o RH com a presença do iFood na vida do consumidor.
O trabalho será transformar essa complementaridade em uma experiência que funcione dos dois lados: simples para quem administra e relevante para quem usa. É nessa conexão que, para mim, está a força da combinação.
Banco Central: três mudanças que aparecem na tela do cliente
Não sou especialista em regulação. Meu olhar aqui é de produto e negócio: esta é minha leitura das normas e do que elas podem mudar na experiência do cliente. Para aplicar as regras, é preciso conferir o enquadramento com a equipe responsável.
O BC aprovou três regras. Uma ajuda o cliente a entender suas dívidas; outra permite escolher quais ofertas receber; a terceira organiza a oferta de empréstimo na hora de fazer um Pix.
601 — Antes de pegar mais dinheiro, entender o que já deve.
- O que faz: exige um painel de dívidas, simulações e alertas para os clientes abrangidos.
- Exemplo: além de conhecer o custo de um empréstimo, a pessoa consegue entender como a nova parcela se soma às contas que já precisa pagar.
- Quem precisa olhar: bancos e demais instituições abrangidas, inclusive instituições de pagamento. Produto e Dados precisam transformar essas informações em algo compreensível.
602 — Escolher quais ofertas quer receber.
- O que faz: exige uma opção para controlar ofertas individuais, incluindo crédito, pagamentos e outros serviços, conforme a instituição.
- Exemplo: o cliente escolhe não receber ofertas de empréstimo. Essa escolha precisa chegar às campanhas e aos parceiros envolvidos.
- Atenção: na regra geral, se ele não escolher, a instituição pode fazer ofertas. Há proteção reforçada para clientes em situações de maior vulnerabilidade. Não é um aceite prévio obrigatório para toda campanha.
Atinge quem faz essas ofertas, inclusive por terceiros. As regras 601 e 602 tratam de pessoas físicas, incluindo empresários individuais. Fonte: Resolução 602.
603 — Pagar por Pix usando dinheiro emprestado.
Imagine uma pizza de R$ 50. O exemplo é hipotético:
- Você inicia o pagamento por Pix.
- Na jornada, seu banco oferece financiar os R$ 50, respeitando a autorização prévia exigida.
- Você aceita as condições e contrata o empréstimo.
- O recebedor recebe R$ 50 na hora. Você fica com a dívida, para pagar conforme o contrato.
A autorização para receber essas ofertas só começa a valer após 24 horas. Quem recebe o Pix não espera esse prazo. O crédito precisa ser concedido por instituição financeira autorizada; o aplicativo que apresenta a oferta pode envolver parceiros, conforme as regras.
É essa resolução que muda diretamente o arranjo Pix. Para quem combina conta, Pix e crédito, há trabalho em autorização, simulação, contratação e consulta da dívida. Fonte: Resolução 603.
E o efeito no negócio? Vejo custos de adequação e possível mudança na conversão das ofertas. Também há espaço para soluções que ajudem a organizar dívidas e respeitar preferências. Melhor resultado financeiro dependerá da execução; não vem garantido pela regra.
As principais obrigações da 602 começam em 31/03/2027; as da 601 e da 603, em 01/07/2027. Mas 601 e 602 já estabelecem prazos anteriores de adequação. Para Produto, o planejamento começa antes dessas datas.
Itaú e NeoSpace: adquirir capacidade de IA muda a decisão de investimento
O Itaú anunciou, em 26 de outubro, um acordo para adquirir a totalidade da NeoSpace por R$ 2,925 bilhões. A startup já prestava serviços ao banco havia quase dois anos, e a conclusão depende de aprovações do Cade e do Banco Central. Fonte: Exame.
O movimento abre uma discussão sobre quais capacidades de IA uma instituição considera estratégicas a ponto de adquirir.
Minha leitura é que a decisão precisa ser avaliada pela ligação entre tecnologia, dados e problemas concretos do banco. Controlar uma capacidade pode facilitar sua evolução e integração ao negócio, mas também exige investimento contínuo e retenção de pessoas especializadas.
O preço da aquisição não comprova o retorno dessa escolha. O teste será a capacidade de transformar a tecnologia em melhor resultado: produtividade, decisões de crédito, prevenção a fraudes ou experiência do cliente, conforme as aplicações efetivamente desenvolvidas.
Para outras instituições, a comparação relevante é entre contratar, construir e adquirir — considerando tempo, custo, diferenciação e capacidade de manter a solução ao longo dos anos.
Recorte desta edição: movimentos de 19 a 25 de outubro, com a inclusão do anúncio do Itaú em 26/10. Pilotos, demonstrações e declarações das empresas não equivalem a resultados econômicos comprovados. Os exemplos de controles e exceções são análise conceitual; as capacidades variam por solução.