x402 resuelve el riel de pagos. Nadie está construyendo la capa de compliance.

Por primera vez en la historia, los programas de software están haciendo pagos por su propia cuenta. No como una tarjeta guardada que se carga automáticamente: un agente de inteligencia artificial que evalúa una situación, decide que tiene que pagar por un servicio, y ejecuta esa transferencia en tiempo real, sin que ningún humano apruebe cada operación. A cualquier escala. A cualquier velocidad.

Eso es lo que x402 habilita. Y ya está corriendo en producción.

El 6 de mayo de 2025, Coinbase publicó x402, un protocolo de pagos construido sobre el código de estado HTTP 402, un identificador técnico de internet que había estado inactivo desde los primeros días de la web. El mecanismo concreto: un agente de IA llega a un endpoint de API pago, recibe una respuesta con los términos del pago, y firma automáticamente una transferencia de USDC (un dólar digital que corre sobre blockchain) usando EIP-3009. Sin crear una cuenta. Sin verificar identidad. Sin humano en el proceso.

A fines de julio de 2026, x402.org reporta 75,41 millones de transacciones y $24,24 millones en volumen en los últimos 30 días, con aproximadamente 94.000 compradores únicos y 22.000 vendedores. La x402 Foundation, respaldada por Coinbase y Cloudflare bajo la Linux Foundation, está construyendo esto como infraestructura abierta. Ese volumen no es una prueba de concepto: es infraestructura desplegada que está corriendo en producción.

El hito es real. Lo que no existe todavía es la capa de compliance que cualquier institución financiera regulada necesita para operar encima de él.

Sigo este espacio de cerca porque en Gu1 estamos construyendo exactamente esa capa: el compliance que x402 asume que va a ser problema de otro. Lo que veo consistentemente es un patrón claro. El riel de pagos se está ingenieriando con cuidado y se está desplegando rápido. La pregunta de compliance se está postergando. Este post es sobre lo que cuesta esa postergación cuando tu institución opera en un mercado regulado, específicamente en América Latina.

La decisión de diseño que crea el gap#

En términos simples: x402 fue diseñado intencionalmente para no saber quién está del otro lado del pago. Esa invisibilidad es su ventaja técnica. Y es exactamente lo que el marco legal de cualquier país prohíbe cuando el dinero viene de una institución financiera regulada.

La documentación de x402 lo dice directamente: "Zero friction: No accounts or personal information needed." Es una decisión de diseño deliberada, no un error. Para los casos de uso para los que fue construido el protocolo (agentes que pagan por llamadas a APIs, recursos de cómputo, feeds de datos) incluir información personal rompería el producto por completo. El protocolo es máquina-a-máquina por diseño, y ese diseño tiene sentido para lo que es.

Pero acá está lo que esa decisión de diseño no cambia: si una institución financiera regulada está en algún punto de la cadena, si un banco, un emisor de dinero electrónico o un procesador de pagos licenciado es la fuente última de los fondos en esas wallets (billeteras digitales), la obligación de KYC no viaja con el pago. Se queda con la institución.

La Recomendación 15 del GAFI, actualizada en 2019 para incluir activos virtuales y proveedores de servicios de activos virtuales, aplica medidas anti-lavado de dinero y contra el financiamiento del terrorismo a las transacciones de activos virtuales independientemente del mecanismo técnico que las ejecute. La regulación no concede una excepción para los protocolos que tomaron una decisión arquitectónica diferente.

El marco del GAFI no tiene una excepción para los protocolos que eligieron no recolectar información de identidad. La obligación recae sobre la institución, no sobre la infraestructura que eligió desplegar.

Lo que el marco exige es la identificación del propietario beneficiario: la persona física que en última instancia es titular o controla los activos que se están moviendo. Un agente de IA no es una persona física. La wallet que controla no es una persona jurídica. La transacción que ejecuta de forma autónoma sigue siendo, desde la perspectiva de todos los marcos regulatorios aplicables, una transacción de la institución que autorizó al agente a actuar.

El problema del propietario beneficiario no tiene excepción para IA#

Cuando un programa hace una transferencia de dinero, alguien es el dueño legal de ese dinero. Los reguladores quieren saber quién es. Y la respuesta no puede ser "fue el software".

Cuando un agente de IA transacciona vía x402, la pregunta de compliance es inmediata: quien es el propietario beneficiario de los fondos en esa wallet?

La respuesta no es el agente. El agente es infraestructura. El propietario beneficiario es quien autorizó al agente a actuar, lo que típicamente significa el cliente institucional o el usuario final cuyos fondos se están desplegando. x402, por diseño, no tiene ningún mecanismo para capturar o transmitir esa información. El pago fluye a través de una wallet, no a través de una cuenta verificada con identidad.

La Recomendación 1 del GAFI exige que las instituciones apliquen un enfoque basado en riesgo que identifique y verifique a los propietarios beneficiarios antes de ejecutar transacciones. La Recomendación 16, la Travel Rule, exige que la información del originador y el beneficiario viaje con la transacción para transferencias por encima de los montos umbral. Ninguno de estos requisitos desaparece porque la transacción la haya ejecutado un software en lugar de un humano.

La consecuencia práctica para cualquier institución que despliega agentes con capacidades de pago: la cadena de propiedad beneficiaria tiene que estar resuelta antes de que el agente empiece a transaccionar. No después. El protocolo no va a brindar esa información de forma retroactiva. Si el mapeo de wallet a identidad verificada no existe antes de la primera transacción, no puede reconstruirse de forma confiable después del hecho, especialmente cuando la actividad de agentes escala a miles de operaciones autónomas por día.

Este no es un gap que se puede parchear post-despliegue. Es un gap estructural que hay que cerrar en la arquitectura antes de que cualquier agente que maneje flujos financieros reales entre en producción.

El gap de identidad de wallets#

Una wallet (billetera digital) es como una cuenta bancaria sin nombre. Puede guardar dinero y hacer transferencias, pero no tiene fecha de nacimiento, domicilio ni número de documento adjunto. Eso es lo que x402 usa para hacer los pagos.

El protocolo x402 usa direcciones de wallets compatibles con EVM como instrumento de pago. Un agente genera una wallet, la carga con USDC de algún lugar upstream, y ejecuta transacciones. Desde la capa del protocolo, esto es eficiente. Desde la capa de compliance, la wallet no tiene ningún ancla de identidad inherente.

El compliance de pagos tradicional fue construido alrededor de cuentas. Verificás a una persona, la enlazás con una cuenta, y la cuenta es el instrumento de pago. La cuenta lleva la identidad. En los pagos nativos de agentes, la wallet es el instrumento, y la wallet fue creada programáticamente por software. Nada en el proceso de creación de la wallet requiere ni registra información de identidad.

En la práctica, esto significa que las instituciones que despliegan agentes vía x402 enfrentan un problema de mapeo: cada wallet que usa el agente necesita estar enlazada, en un registro durable mantenido por la institución, a una persona física o jurídica verificada antes de que se ejecute la primera transacción. Esto no es un setup de una sola vez. Los agentes pueden generar nuevas wallets programáticamente como parte de su arquitectura. Si la capa de compliance no rastrea cada nueva wallet a medida que se crea, el mapeo de identidad se rompe.

Hemos visto este problema surgir en producción con clientes crypto-nativos en nuestra plataforma. Un procesador de pagos despliega un flujo automatizado que crea wallets de forma dinámica. Meses después, una revisión de compliance detecta wallets con historiales de transacciones y sin registro de identidad adjunto. Reconstruir esos mapeos a partir de datos on-chain y logs internos es costoso y frecuentemente incompleto. La lección es consistente: el mapeo tiene que construirse cuando la wallet se crea, no recuperarse después del hecho.

Cinco reguladores, un requisito no negociable#

Argentina, Brasil, México, Colombia y Chile tienen marcos legales separados, pero todos dicen lo mismo: toda transacción financiera tiene que poder rastrearse hasta una persona física real. No hay excepción para transacciones automáticas. Ningún regulador de LATAM acepta "el protocolo no tenía esa información" como respuesta válida.

Quiero ser específico sobre cómo se ve ese requisito en la práctica.

En Argentina, el BCRA y la UIF operan bajo marcos que exigen a las instituciones financieras identificar al propietario beneficiario último de cada transacción: la persona física con control o titularidad efectiva de los fondos. La Comunicación A 7724 del BCRA y sus actualizaciones posteriores aplican estos requisitos a los proveedores de servicios de pago independientemente del canal técnico utilizado para ejecutar la transacción. La UIF extendió sus obligaciones de reporte AML para incluir activos virtuales. Ninguno de los dos marcos tiene una exención para transacciones autónomas de agentes.

En Brasil, el BCB y el COAF avanzaron más rápido sobre stablecoins que cualquier otro regulador de LATAM. Las Resoluciones 519, 520 y 521 del BCB, publicadas en noviembre de 2025 y vigentes desde febrero de 2026, establecieron un marco de autorización formal para las entidades que operan con stablecoins. La Resolución 561, vigente desde octubre de 2026, restringe a los proveedores de eFX licenciados de liquidar pagos internacionales en stablecoins fuera del perímetro licenciado. El BCB dejó explícito que los flujos de origen brasileño a través de stablecoins están sujetos a su supervisión, con identificación requerida a nivel de CPF y CNPJ. Un agente de IA que transacciona en USDC desde la wallet de un usuario brasileño no queda fuera de ese perímetro porque la transacción fue automatizada.

En México, el CNBV y Banxico mantienen un marco bajo la Ley Fintech que trata las transacciones de activos digitales como sujetas a obligaciones AML y CFT cuando fluyen a través de instituciones licenciadas. La UIF México exige identificación trazable para el originador y el beneficiario de cada transacción relevante. En Colombia, la SFC y la UIAF aplican el mismo principio. En Chile, la CMF y la UAF.

Cinco países, cinco marcos regulatorios separados, un requisito consistente: una persona física tiene que ser identificable al final de cada cadena de transacciones. Ninguna evaluación mutua del GAFI acepta como control válido "el protocolo no recolectó esa información."

La capa de stablecoins agrega otra variable#

USDC es el dinero que x402 usa para los pagos. Para quien no conoce el término: es un "dólar digital" emitido por la empresa Circle, que vale siempre un dólar y corre sobre blockchain. En la mayoría de los países de América Latina, ese tipo de instrumento ya está bajo regulación activa y creciente.

x402 liquida en USDC por defecto. Eso agrega otra dimensión al problema de compliance que es específica de América Latina.

USDC es emitido por Circle en múltiples chains. En la mayoría de las jurisdicciones de LATAM, las stablecoins ocupan una posición regulatoria que se está endureciendo activamente. Brasil es el más avanzado: el marco de autorización del BCB implica que los flujos de stablecoins de origen brasileño están sujetos a su supervisión, y el endurecimiento regulatorio continúa durante el resto de 2026. La UIF de Argentina extendió el reporte AML a activos virtuales. El CNBV de México mantiene una postura cautelosa, tratando el uso no autorizado de stablecoins por instituciones financieras como fuera del perímetro licenciado.

El riesgo no es abstracto. TRM Labs reportó en abril de 2026 que redes criminales procesaron más de USD 103.000 millones en flujos ilícitos en 2025, usando los corredores de LATAM como punto de enrutamiento clave, frecuentemente a través de stablecoins. Ese es el contexto en el que los reguladores de LATAM están evaluando el compliance de stablecoins. El nivel de escrutinio es alto y está aumentando.

Una institución que despliega pagos nativos de agentes usando USDC vía x402 está corriendo dos tracks de compliance simultáneamente: el track de identidad (si la wallet mapea a un propietario beneficiario verificado) y el track de stablecoins (si el uso de USDC cumple el marco regulatorio local de esa jurisdicción). El protocolo no maneja ninguno de los dos. Ambos requieren infraestructura que alguien tiene que construir.

Lo que la capa de compliance realmente necesita#

En términos simples: antes de que cualquier agente de IA haga su primera transacción, hay cuatro preguntas que x402 no responde y que la institución tiene que haber resuelto. No son opcionales. Son el mínimo que cualquier regulador de LATAM va a pedir.

El gap es estructural, no incidental. Esto es lo que cualquier institución regulada necesita antes de desplegar agentes que transaccionen vía x402, y que el protocolo no provee.

Resolución de identidad antes de la ejecución. El propietario beneficiario detrás de cada wallet usada por un agente necesita ser verificado a través de un proceso que satisfaga el marco aplicable antes de que esa wallet ejecute su primera transacción. Para usuarios brasileños, eso significa verificación de CPF o CNPJ bajo los requisitos del BCB. Para usuarios argentinos, CUIL o CUIT enlazado a un onboarding conforme a la UIF. Para usuarios mexicanos, RFC y validación de documentación gubernamental bajo los estándares del CNBV. Esa verificación no puede suceder dentro del flujo de transacción de x402. Tiene que suceder en una capa de identidad separada, mantenida por la institución, antes de que se otorgue cualquier autorización de pago.

Mapeo durable de wallet a entidad. Un registro persistente y auditable que enlaza cada dirección de wallet a una persona jurídica o física verificada. Este registro tiene que sobrevivir consultas regulatorias: inmutable, con timestamp, y accesible para el equipo de compliance y los examinadores. Una wallet que el agente generó programáticamente y usó una vez sigue siendo una transacción que necesita un titular verificado en el registro.

Monitoreo transaccional sobre flujos autónomos. La obligación AML no termina en el onboarding. Las transacciones ejecutadas por agentes necesitan fluir a través de las mismas reglas de monitoreo que aplican a las transacciones iniciadas por humanos: tipologías del GAFI, indicadores de riesgo locales, y detección de patrones en ventanas de tiempo. Un agente que ejecuta miles de micro-transacciones por día genera un dataset de monitoreo que requiere procesamiento automatizado de reglas a una escala que la mayoría de los equipos de compliance no ha tenido que manejar antes.

Audit trail para decisiones autónomas. Cuando un agente ejecuta una transacción sin aprobación humana en cada paso, el log de compliance necesita documentar quién autorizó al agente, el alcance de esa autorización, y el contexto completo de la transacción en el momento de la ejecución. Ese es el registro que un examinador del BCRA, el BCB, el CNBV, la SFC o la CMF va a pedir cuando algo salga mal.

En Gu1 corremos infraestructura de compliance para 34 instituciones financieras en seis países de América Latina. KYC, monitoreo transaccional AML, y reporte regulatorio, bajo marcos que cubren BCRA y UIF en Argentina, BCB y COAF en Brasil, CNBV y Banxico y UIF en México, SFC y UIAF en Colombia, y CMF y UAF en Chile. Tenemos certificaciones ISO 27001, SOC 2, GDPR y PCI DSS, y operamos bajo SLAs contractuales de 99,5 por ciento de disponibilidad. Procesamos más de 20 millones de transacciones para un solo cliente en Brasil.

Lo que estamos viendo ahora es la misma pregunta de compliance llegando desde una nueva dirección: como se extiende esta infraestructura a los flujos de transacciones generadas por agentes? Las instituciones que hacen esa pregunta no están corriendo experimentos. Están desplegando flujos agentivos en producción y descubriendo que el riel de pagos que eligieron no viene con una capa de compliance.

x402 construyó lo que se propuso construir. El riel de pagos es real y funciona. La infraestructura de compliance que cualquier institución regulada necesita para operar encima de él todavía está en su mayor parte sin construir. Entre "la transacción se ejecutó" y "la transacción fue compliant" hay un gap que crece con cada nuevo despliegue de agentes.