O x402 resolve o trilho de pagamentos. Ninguém está construindo a camada de compliance.

Pela primeira vez na história, programas de software estão fazendo pagamentos por conta própria. Não como um cartão salvo que é cobrado automaticamente: um agente de inteligência artificial que avalia uma situação, decide que precisa pagar por um serviço, e executa essa transferência em tempo real, sem que nenhum humano aprove cada operação. Em qualquer escala. Em qualquer velocidade.

Isso é o que o x402 habilita. E já está rodando em produção.

Em 6 de maio de 2025, a Coinbase publicou o x402, um protocolo de pagamentos construído sobre o código de status HTTP 402, um identificador técnico de internet que estava sem uso desde os primeiros dias da web. O mecanismo concreto: um agente de IA acessa um endpoint de API pago, recebe uma resposta com os termos do pagamento, e assina automaticamente uma transferência de USDC (um dólar digital que roda em blockchain) usando EIP-3009. Sem criação de conta. Sem verificação de identidade. Sem humano no processo.

No final de julho de 2026, o x402.org reporta 75,41 milhões de transações e $24,24 milhões em volume nos últimos 30 dias, com aproximadamente 94.000 compradores únicos e 22.000 vendedores. A x402 Foundation, apoiada pela Coinbase e Cloudflare sob a Linux Foundation, está construindo isso como infraestrutura aberta. Esse volume não é uma prova de conceito: é infraestrutura implantada que está rodando em produção.

O marco é real. O que ainda não existe é a camada de compliance que qualquer instituição financeira regulada precisa para operar sobre ele.

Acompanho esse espaço de perto porque na Gu1 estamos construindo exatamente essa camada: o compliance que o x402 assume que será problema de outra pessoa. O que continuo observando é um padrão consistente. O trilho de pagamentos está sendo engenheirado com cuidado e implantado rapidamente. A questão de compliance está sendo adiada. Este post é sobre o custo desse adiamento quando sua instituição opera em um mercado regulado, especificamente na América Latina.

A decisão de design que cria o gap#

Em termos simples: o x402 foi deliberadamente projetado para não saber quem está do outro lado do pagamento. Essa invisibilidade é a sua vantagem técnica. E é exatamente o que o marco legal de qualquer país proíbe quando o dinheiro vem de uma instituição financeira regulada.

A documentação do x402 afirma diretamente: "Zero friction: No accounts or personal information needed." Essa é uma decisão de design deliberada, não uma omissão. Para os casos de uso para os quais o protocolo foi construído (agentes pagando por chamadas de API, recursos de computação e feeds de dados) incluir informações pessoais quebraria o produto por completo. O protocolo é máquina-a-máquina por design, e esse design faz sentido para o que é.

Mas aqui está o que essa decisão de design não muda: se uma instituição financeira regulada está em algum ponto da cadeia, se um banco, uma instituição de moeda eletrônica ou um processador de pagamentos licenciado é a fonte final dos fundos nessas carteiras (carteiras digitais), a obrigação de KYC não viaja com o pagamento. Ela permanece com a instituição.

A Recomendação 15 do GAFI, atualizada em 2019 para incluir ativos virtuais e prestadores de serviços de ativos virtuais, aplica medidas de prevenção à lavagem de dinheiro e ao financiamento do terrorismo a transações de ativos virtuais independentemente do mecanismo técnico que as executa. A regulação não concede exceção para protocolos que fizeram uma escolha arquitetural diferente.

O framework do GAFI não tem uma exceção para protocolos que escolheram não coletar informações de identidade. A obrigação recai sobre a instituição, não sobre a infraestrutura que ela escolheu implantar.

O que o framework exige é a identificação do beneficiário final: a pessoa física que, em última instância, é proprietária ou controla os ativos sendo movimentados. Um agente de IA não é uma pessoa física. A carteira que ele controla não é uma pessoa jurídica. A transação que ele executa de forma autônoma ainda é, da perspectiva de todos os frameworks regulatórios aplicáveis, uma transação da instituição que autorizou o agente a agir.

O problema do beneficiário final não tem exceção para IA#

Quando um programa faz uma transferência de dinheiro, alguém é o proprietário legal desse dinheiro. Os reguladores querem saber quem é. E a resposta não pode ser "foi o software".

Quando um agente de IA transaciona via x402, a pergunta de compliance é imediata: quem é o beneficiário final dos fundos nessa carteira?

A resposta não é o agente. O agente é infraestrutura. O beneficiário final é quem autorizou o agente a agir, o que tipicamente significa o cliente institucional ou o usuário final cujos fundos estão sendo implantados. O x402, por design, não tem nenhum mecanismo para capturar ou transmitir essa informação. O pagamento flui por uma carteira, não por uma conta com identidade verificada.

A Recomendação 1 do GAFI exige que as instituições apliquem uma abordagem baseada em risco que identifique e verifique os beneficiários finais antes de executar transações. A Recomendação 16, a Travel Rule, exige que as informações do originador e do beneficiário viajem com a transação para transferências acima de valores limiar. Nenhum desses requisitos desaparece porque a transação foi executada por software em vez de um humano.

A consequência prática para qualquer instituição que implanta agentes com capacidades de pagamento: a cadeia de beneficiário final precisa estar resolvida antes que o agente comece a transacionar. Não depois. O protocolo não fornecerá esses dados de forma retroativa. Se o mapeamento de carteira para identidade verificada não existir antes da primeira transação, ele não pode ser reconstruído de forma confiável após o fato, especialmente quando a atividade de agentes escala para milhares de operações autônomas por dia.

Este não é um gap que pode ser corrigido após a implantação. É um gap estrutural que precisa ser fechado na arquitetura antes que qualquer agente que lide com fluxos financeiros reais entre em produção.

O gap de identidade das carteiras#

Uma carteira digital é como uma conta bancária sem nome. Pode guardar dinheiro e fazer transferências, mas não tem data de nascimento, endereço nem número de documento anexado. Esse é o instrumento de pagamento que o x402 usa.

O protocolo x402 usa endereços de carteiras compatíveis com EVM como instrumento de pagamento. Um agente gera uma carteira, a carrega com USDC de algum lugar upstream e executa transações. Da perspectiva da camada de protocolo, isso é eficiente. Da perspectiva da camada de compliance, a carteira não tem nenhuma âncora de identidade inerente.

O compliance de pagamentos tradicional foi construído em torno de contas. Você verifica uma pessoa, a vincula a uma conta, e a conta é o instrumento de pagamento. A conta carrega a identidade. Nos pagamentos nativos de agentes, a carteira é o instrumento, e a carteira foi criada programaticamente por software. Nada no processo de criação da carteira exige ou registra informações de identidade.

Na prática, isso significa que as instituições que implantam agentes via x402 enfrentam um problema de mapeamento: cada carteira que o agente usa precisa estar vinculada, em um registro durável mantido pela instituição, a uma pessoa física ou jurídica verificada antes da primeira transação ser executada. Isso não é uma configuração única. Os agentes podem gerar novas carteiras programaticamente como parte de sua arquitetura. Se a camada de compliance não rastrear cada nova carteira à medida que é criada, o mapeamento de identidade se quebra.

Vimos esse problema surgir em produção com clientes cripto-nativos em nossa plataforma. Um processador de pagamentos implanta um fluxo automatizado que cria carteiras dinamicamente. Meses depois, uma revisão de compliance detecta carteiras com históricos de transações e sem registro de identidade anexado. Reconstruir esses mapeamentos a partir de dados on-chain e logs internos é caro e frequentemente incompleto. A lição é consistente: o mapeamento precisa ser construído quando a carteira é criada, não recuperado depois do fato.

Cinco reguladores, um requisito não negociável#

Argentina, Brasil, México, Colômbia e Chile têm frameworks legais separados, mas todos dizem a mesma coisa: toda transação financeira precisa ser rastreável até uma pessoa física real. Não há exceção para transações automáticas. Nenhum regulador da LATAM aceita "o protocolo não tinha essa informação" como resposta válida.

Quero ser específico sobre como esse requisito parece na prática.

No Brasil, o BCB e o COAF avançaram mais rapidamente em stablecoins do que qualquer outro regulador da LATAM. As Resoluções BCB 519, 520 e 521, publicadas em novembro de 2025 e vigentes a partir de fevereiro de 2026, estabeleceram um framework formal de autorização para entidades que operam com stablecoins. A Resolução 561, vigente a partir de outubro de 2026, restringe os provedores de eFX licenciados de liquidar pagamentos internacionais em stablecoins fora do perímetro licenciado. O BCB deixou explícito que os fluxos de origem brasileira em stablecoins estão sujeitos à sua supervisão, com identificação exigida no nível do CPF e CNPJ. Um agente de IA que transaciona em USDC a partir da carteira de um usuário brasileiro não está fora desse perímetro porque a transação foi automatizada.

Na Argentina, o BCRA e a UIF operam sob frameworks que exigem às instituições financeiras identificar o beneficiário final de cada transação: a pessoa física com controle ou titularidade efetiva dos fundos. A Comunicação A 7724 do BCRA e suas atualizações posteriores aplicam esses requisitos a provedores de serviços de pagamento independentemente do canal técnico utilizado. A UIF estendeu suas obrigações de reporte AML para incluir ativos virtuais.

No México, o CNBV e o Banxico mantêm um framework sob a Ley Fintech que trata as transações de ativos digitais como sujeitas às obrigações AML e CFT quando fluem por instituições licenciadas. A UIF México exige identificação rastreável para o originador e o beneficiário de cada transação relevante. Na Colômbia, a SFC e a UIAF aplicam o mesmo princípio. No Chile, a CMF e a UAF.

Cinco países, cinco frameworks regulatórios separados, um requisito consistente: uma pessoa física precisa ser identificável no final de cada cadeia de transações. Nenhuma avaliação mútua do GAFI dá crédito por "o protocolo não coletou essa informação."

A camada de stablecoins adiciona outra variável#

USDC é o dinheiro que o x402 usa para os pagamentos. Para quem não conhece o termo: é um "dólar digital" emitido pela empresa Circle, que vale sempre um dólar e roda em blockchain. Na maioria dos países da América Latina, esse tipo de instrumento já está sob regulação ativa e crescente.

O x402 liquida em USDC por padrão. Isso adiciona outra dimensão ao problema de compliance que é específica da América Latina, e do Brasil em particular.

O USDC é emitido pela Circle em múltiplas chains. No Brasil, o BCB já estabeleceu um framework que torna os fluxos de stablecoins de origem brasileira sujeitos à sua supervisão. Mas o contexto vai além da regulação técnica. O TRM Labs reportou em abril de 2026 que redes criminosas processaram mais de USD 103 bilhões em fluxos ilícitos em 2025, usando os corredores da LATAM como ponto de roteamento chave, frequentemente por meio de stablecoins. Esse é o contexto no qual os reguladores da região estão avaliando o compliance de stablecoins. O nível de escrutínio é alto e está aumentando.

O Open Finance BR, que avança com integração entre instituições reguladas, cria um ambiente onde os fluxos de dados e pagamentos entre participantes são rastreáveis pelo BCB. Um agente de IA que opera fora desse framework regulado, mas usa fundos que originaram dentro dele, cria uma descontinuidade de compliance que as normas vigentes não toleram.

Uma instituição que implanta pagamentos nativos de agentes usando USDC via x402 está rodando dois tracks de compliance simultaneamente: o track de identidade (se a carteira mapeia para um beneficiário final verificado) e o track de stablecoins (se o uso de USDC atende ao framework regulatório local da jurisdição). O protocolo não lida com nenhum dos dois. Ambos exigem infraestrutura que alguém precisa construir.

O que a camada de compliance realmente precisa#

Em termos simples: antes que qualquer agente de IA faça sua primeira transação, há quatro perguntas que o x402 não responde e que a instituição precisa ter resolvido. Não são opcionais. São o mínimo que qualquer regulador da LATAM vai exigir.

O gap é estrutural, não incidental. Isso é o que qualquer instituição regulada precisa antes de implantar agentes que transacionem via x402, e que o protocolo não fornece.

Resolução de identidade antes da execução. O beneficiário final por trás de cada carteira usada por um agente precisa ser verificado por meio de um processo que satisfaça o framework aplicável antes que essa carteira execute sua primeira transação. Para usuários brasileiros, isso significa verificação de CPF ou CNPJ nos termos exigidos pelo BCB. Para usuários argentinos, CUIL ou CUIT vinculado a um onboarding conforme à UIF. Para usuários mexicanos, RFC e validação de documento governamental nos padrões do CNBV. Essa verificação não pode acontecer dentro do fluxo de transação do x402. Ela precisa acontecer em uma camada de identidade separada, mantida pela instituição, antes que qualquer autorização de pagamento seja concedida.

Mapeamento durável de carteira para entidade. Um registro persistente e auditável vinculando cada endereço de carteira a uma pessoa jurídica ou física verificada. Esse registro precisa sobreviver a consultas regulatórias: imutável, com timestamp e acessível para a equipe de compliance e examinadores. Uma carteira que o agente gerou programaticamente e usou uma vez ainda é uma transação que precisa de um titular verificado no registro.

Monitoramento transacional em fluxos autônomos. A obrigação AML não termina no onboarding. As transações executadas por agentes precisam fluir pelas mesmas regras de monitoramento que se aplicam às transações iniciadas por humanos: tipologias do GAFI, indicadores de risco locais e detecção de padrões em janelas de tempo. Um agente executando milhares de microtransações por dia gera um dataset de monitoramento que exige processamento automatizado de regras em uma escala que a maioria das equipes de compliance ainda não precisou lidar.

Trilha de auditoria para decisões autônomas. Quando um agente executa uma transação sem aprovação humana a cada etapa, o log de compliance precisa documentar quem autorizou o agente, o escopo dessa autorização e o contexto completo da transação no momento da execução. Esse é o registro que um examinador do BCB, BCRA, CNBV, SFC ou CMF vai solicitar quando algo der errado.

Na Gu1, operamos infraestrutura de compliance para 34 instituições financeiras em seis países da América Latina. KYC, monitoramento transacional AML e reporte regulatório, sob frameworks que cobrem BCB e COAF no Brasil, BCRA e UIF na Argentina, CNBV e Banxico e UIF no México, SFC e UIAF na Colômbia, e CMF e UAF no Chile. Temos certificações ISO 27001, SOC 2, GDPR e PCI DSS, e operamos sob SLAs contratuais de 99,5 por cento de disponibilidade. Processamos mais de 20 milhões de transações para um único cliente no Brasil.

O que estamos vendo agora é a mesma pergunta de compliance chegando de uma nova direção: como essa infraestrutura se estende para fluxos de transações geradas por agentes? As instituições que fazem essa pergunta não estão rodando experimentos. Estão implantando fluxos agentivos em produção e descobrindo que o trilho de pagamentos que escolheram não inclui uma camada de compliance.

O x402 construiu o que se propôs a construir. O trilho de pagamentos é real e funciona. A infraestrutura de compliance que qualquer instituição regulada precisa para operar sobre ele ainda está, em sua maior parte, por ser construída. Entre "a transação foi executada" e "a transação estava em conformidade" há um gap que cresce a cada nova implantação de agentes.