Hace unas semanas escribí sobre qué pasa cuando un agente de IA necesita pagar. La versión corta: los rieles de pago que tenemos se construyeron para humanos, y los agentes ya se están topando con esa fricción. Desde entonces, hay una pregunta que vuelve en cada conversación: si un agente puede pagar, ¿cómo sabemos que tiene permiso para hacerlo y, sobre todo, en nombre de quién está actuando realmente?

Dos preguntas distintas, un mismo pago

Cada vez que un agente inicia un pago, en realidad se están produciendo dos comprobaciones separadas, aunque tendamos a mezclarlas. Piensa en ellas como dos formas distintas en las que un pago puede salir mal, y dos tipos de fraude que cada comprobación está diseñada para frenar.

¿A quién va el dinero?

Eso es verificar el destino. Frena el fraude en el que un pago llega al lugar equivocado: un atacante cambia los datos de la cuenta del beneficiario y tu dinero termina en sus manos en lugar de en las del proveedor o negocio real. En concreto, esto significa comprobar que la cuenta que recibe los fondos pertenece realmente a la persona o empresa que el pagador cree. En el comercio agéntico, el agente puede que solo vea la web o la API de un comercio, pero el destino que de verdad importa siempre es la entidad legal detrás, el titular de la cuenta asociado al IBAN.

¿Quién ordena este pago y tenía permiso para hacerlo?

Eso es verificar al agente. Aquí el fraude tiene otra forma: no es que el dinero llegue al destino equivocado, sino que un agente actúa en nombre de la persona equivocada, o que la autorización de una persona real se sobrepasa más allá de los límites que ella misma fijó.

Las preguntas clave son: ¿este software actúa de verdad en nombre del titular de la cuenta? Y ¿está operando dentro de los límites y permisos que esa persona estableció?

En el comercio agéntico, la confianza no puede depender solo de la transacción en sí. Hace falta verificar las dos caras de la interacción: el destino del pago y el agente que lo inicia. Saber adónde va el dinero y quién tiene permiso para moverlo es lo que convierte los pagos autónomos en pagos de confianza.

La verificación del beneficiario ya resolvió el destino

Desde octubre de 2025, el Reglamento de Pagos Instantáneos exige la Verificación del Beneficiario (VoP, Verification of Payee) antes de cada pago en SEPA. El PSP del pagador comprueba si el nombre del beneficiario coincide con el titular real de la cuenta, y devuelve una coincidencia, una coincidencia parcial o ninguna coincidencia.

Aquí hay un matiz que es fácil pasar por alto: la VoP nunca trató de demostrar que alguien existe detrás de una cuenta, eso es tarea del KYC, y se hace cuando se abre la cuenta. La VoP responde a algo más concreto: ¿esa persona es realmente quien el pagador cree que es? Vincula el IBAN a una identidad esperada, en tiempo real, en cada transferencia.

Para un pago de cuenta a cuenta (A2A) dentro de SEPA, eso significa que el lado del destino ya está cubierto. No hace falta inventar nada ahí. La VoP funciona porque es una consulta en vivo entre dos PSP regulados dentro del mismo esquema, y esa raíz de confianza entre PSP ya existe. Por eso verificar un destino se ha vuelto algo rutinario y no un problema de investigación.

Lo cual nos lleva a la parte que todavía no es rutinaria.

Consentimiento y autorización: lo que a los pagos agénticos aún les falta

La VoP te dice a quién pagas. No dice nada sobre quién ordenó el pago ni con qué autoridad. En los flujos SEPA clásicos, el consentimiento nunca fue una pregunta aparte, porque quien iniciaba el pago siempre era una persona, autenticada por su banco mediante SCA bajo PSD2. Autorización e identidad eran el mismo evento.

Un agente que actúa por delegación rompe esa suposición, y la infraestructura actual no tiene respuesta para la pregunta que eso plantea: ¿tenía este agente el consentimiento del titular de la cuenta para ordenar este pago concreto, y dentro de qué límites es válida su autorización?

Hoy no existe una «VoP para agentes».

Para confiar en un pago iniciado por un agente hay que poder demostrar tres cosas.

• Delegación y consentimiento. El titular de la cuenta, cuya identidad está fuertemente verificada, firma una credencial que declara que un agente concreto actúa en su nombre. La identidad fuerte reside en la persona o la empresa, el agente solo hereda una porción de esa autoridad, y únicamente para lo que realmente se consintió.
• Autorización acotada. La credencial incluye límites: un importe máximo, un tope diario, una fecha de caducidad. Un pago de 2.000 euros se rechaza si la credencial limita al agente a 500, incluso si esa credencial es perfectamente auténtica.
• Prueba de posesión. El agente tiene que demostrar que posee la clave privada asociada a esa credencial en el momento de firmar el pago, de modo que una credencial robada no pueda reutilizarse sin más por quien la haya conseguido.

Nada de esto es criptografía exótica. Lo que falta es un acuerdo sobre quién la emite y cómo encaja en un flujo de pago.

Dar identidad a los agentes de IA: credenciales verificables para la autorización delegada

Una Credencial Verificable (VC, Verifiable Credential) es una credencial digital firmada que contiene afirmaciones de confianza sobre una persona, organización o dispositivo. Se puede verificar criptográficamente sin contactar con el emisor, lo que garantiza que la información es auténtica y no se ha alterado.

El modelo de datos VC del W3C estandariza exactamente esto, y es la misma tecnología que ya sustenta el lado del destino en esta ecuación. Solo cambia la afirmación: en vez de «este IBAN pertenece a este nombre», pasa a ser «este agente actúa en nombre de este titular de cuenta, dentro de estos límites».

Trasladado a un pago real, el flujo sería así.

1. El titular de la cuenta tiene una identidad fuertemente verificada.
2. Firma una credencial de delegación para su agente, con límites explícitos asociados.
3. El agente, al iniciar un pago, presenta esa credencial y demuestra que posee la clave correspondiente.
4. Nuestro sistema verifica el lado del agente: permiso, límites y validez.
5. La VoP verifica el lado del destino: IBAN contra nombre.
6. El pago se ejecuta solo si ambos lados se validan.

Hay un detalle que aquí importa más de lo que importó nunca con la identidad humana: la revocación. Los agentes son efímeros. Se crean, hacen su trabajo, desaparecen o se ven comprometidos. Las credenciales de vida corta combinadas con una revocación rápida no son un extra deseable, son todo el mecanismo de seguridad.

Una brecha institucional, no técnica

No hay un estándar maduro para el eslabón «agente» de la cadena. eIDAS y la Cartera de Identidad Digital Europea están pensados para que personas y empresas demuestren quiénes son, no para que un software demuestre que tiene permiso para actuar en nombre de otro. El problema de la identidad del titular de la cuenta está resuelto. El problema de la identidad del agente delegado es territorio nuevo por completo.

La adopción y la privacidad tiran en ambas direcciones. Nadie exige credenciales de agente si casi nadie las emite todavía, y un esquema de credenciales mal diseñado puede dejar un rastro de todo lo que hace un agente. Existen mitigaciones para esto, pero añaden complejidad, no la reducen.

Hacia dónde llevamos esto en Devengo

Operamos pagos A2A (de cuenta a cuenta) dentro de SEPA, así que el lado del destino ya lo cubre la VoP. Ahora nuestro foco está en el lado del agente, y estamos empezando de forma conservadora a propósito.

Para titulares de cuenta corporativos, ya contamos con un modelo de exención corporativa desde el que construir, algo que no se aplicaría de la misma manera a personas físicas. A partir de ahí, la idea es simple: un agente nunca tiene disposición libre de fondos. Opera dentro de límites estrictos fijados por el titular de la cuenta y una lista blanca de posibles destinatarios. Sin gasto abierto, sin destinos arbitrarios, nunca.

Ya estamos probando piezas de esto de forma práctica, incluido un prototipo de un agente que paga a través de HTTP 402.

Seguiremos compartiendo lo que aprendamos mientras lo construimos, ¡así que estad atentos!

Si estás explorando los pagos agénticos y quieres saber cómo integrarlos en tus productos, contacta con nosotros.