PSD2 y open banking: roles, API, autenticación reforzada y certificados eIDAS

Antes de 2018, si querías crear una aplicación que mostrara todas las cuentas bancarias de un cliente en un solo lugar, le pedías la contraseña de su banca online y entrabas como si fueras él. Funcionaba, era frágil y, desde el punto de vista de la seguridad, era indefendible. La segunda Directiva de Servicios de Pago — la PSD2 — sustituyó ese apaño por algo mejor: terceros con licencia, consentimiento explícito del cliente e interfaces que los bancos están legalmente obligados a ofrecer.

El resultado es un ecosistema de API regulado con una propiedad poco habitual para un ingeniero: la especificación de qué hay que ofrecer es un texto legal, mientras que el cómo se dejó en manos del mercado, lo que dio lugar a varios estándares técnicos que compiten sobre una misma obligación. Esta guía cubre ambas mitades: el modelo regulatorio que tienes que cumplir y la mecánica de las API contra las que vas a programar de verdad.

Qué cambió y por qué

La PSD2 perseguía tres objetivos a la vez: más competencia en los pagos, más seguridad y una base legal para un acceso a las cuentas que ya se producía de manera informal. Su disposición de mayor calado es el acceso a las cuentas: un banco que gestiona una cuenta de pago accesible online debe permitir que un tercero con licencia, actuando con el consentimiento explícito del cliente, consulte esa cuenta o inicie un pago desde ella, sin cobrar por ello y sin exigir un contrato entre el banco y el tercero.

Otras dos disposiciones marcan la ingeniería del día a día. La autenticación reforzada de clientes pasó a ser obligatoria para la mayoría de los pagos electrónicos y para el acceso online a las cuentas. Y las reglas de responsabilidad se inclinaron claramente a favor del cliente: las operaciones no autorizadas se reembolsan con rapidez salvo que el proveedor demuestre fraude o negligencia grave, y por eso los bancos invierten tanto en el paso de autenticación.

«Open banking» es el término comercial para el ecosistema que creó la directiva. En otras partes del mundo existen marcos similares, con bases jurídicas distintas y formas técnicas comparables.

Los roles regulados

Cuatro siglas sostienen todo el modelo.

• ASPSP — Account Servicing Payment Service Provider, el proveedor gestor de la cuenta. Es la entidad que tiene la cuenta y está obligada a exponer la interfaz; en la práctica, el banco.
• AISP — Account Information Service Provider, el proveedor de información sobre cuentas. Lee datos de la cuenta: saldos, movimientos, datos de la cuenta. Solo lectura: agregación, gestión de presupuestos, evaluación crediticia.
• PISP — Payment Initiation Service Provider, el proveedor de iniciación de pagos. Ordena un pago desde la cuenta del cliente con su consentimiento. Nunca toca los fondos; quien ejecuta es el banco.
• CBPII — Card Based Payment Instrument Issuer, el emisor de instrumentos de pago basados en tarjeta. Le hace al banco una única pregunta de sí o no: ¿están disponibles estos fondos ahora mismo? Lo usan emisores de tarjetas cuyas tarjetas se cargan en una cuenta de otra entidad.

Una misma empresa puede tener varios roles. El cliente, el usuario de servicios de pago en el lenguaje de la norma, es la única parte que puede otorgar el consentimiento, y puede revocarlo en cualquier momento.

El rol de PISP merece atención porque cambia la economía del comercio electrónico: al comerciante se le puede pagar con una transferencia de cuenta a cuenta iniciada en el checkout, sin red de tarjetas, sin tasa de intercambio y —si por debajo hay un esquema instantáneo— con fondos irrevocables en segundos. Es un perfil de riesgo realmente distinto del flujo de tarjeta descrito en pagos con tarjeta, porque una transferencia no tiene mecanismo de chargeback.

La autenticación reforzada de clientes

La SCA (Strong Customer Authentication) exige autenticar con al menos dos elementos independientes de tres categorías:

• Conocimiento — algo que solo sabe el usuario (un código secreto, no una palabra memorable enviada por correo electrónico).
• Posesión — algo que solo tiene el usuario (un teléfono registrado con una clave vinculada, un token físico, una tarjeta con chip).
• Inherencia — algo que el usuario es (huella dactilar, rostro o biometría del comportamiento).

La independencia significa que comprometer un elemento no debe comprometer los demás; un código que se muestra en el mismo navegador que tiene la sesión no cumple el requisito. Para los pagos remotos hay una exigencia adicional, la vinculación dinámica: el código de autenticación debe quedar vinculado criptográficamente al importe y al beneficiario concretos, y cualquier cambio en uno u otro lo invalida. Esa sola regla elimina toda una clase de ataques en los que una autenticación aprobada se reutiliza contra otro beneficiario.

Las normas técnicas de regulación definen exenciones que el banco puede aplicar bajo su propio riesgo:

Hay dos puntos que los ingenieros suelen entender mal. Las exenciones las solicita el proveedor de pagos, pero las concede el emisor, así que tu código debe gestionar un challenge que llegue de todos modos. Y el acceso a la información de cuentas tiene su propio ritmo: SCA en el primer acceso, después un periodo durante el cual el tercero puede actualizar los datos de forma desatendida un número limitado de veces al día, y luego una nueva autenticación.

La interfaz, y cómo demostrar quién eres

Los bancos pueden exponer una interfaz dedicada —una API creada a propósito— y la gran mayoría lo hace. Las reglas imponen obligaciones que parecen un SLA redactado por un regulador: la interfaz dedicada debe ofrecer una disponibilidad y un rendimiento al menos equivalentes a los de los canales que el banco ofrece a sus propios clientes, publicar estadísticas de disponibilidad y de errores, proporcionar un entorno de pruebas con sandbox y admitir pruebas a gran escala antes del lanzamiento. Cuando la interfaz dedicada de un banco no cumple esos estándares, debe existir un mecanismo de contingencia para que los terceros sigan pudiendo llegar al canal del cliente; los bancos que demuestren una interfaz conforme pueden quedar exentos de construirlo. Es uno de los aspectos que la legislación sucesora pretende simplificar.

La identificación se basa en certificados eIDAS, emitidos por prestadores cualificados de servicios de confianza, que incluyen como extensión el número de autorización del tercero y sus roles:

• QWAC — Qualified Website Authentication Certificate, que se presenta en un handshake TLS con autenticación mutua. Identifica a quien llama en la capa de transporte.
• QSEALC — Qualified Certificate for Electronic Seal, que se usa para firmar la propia petición HTTP, de modo que el mensaje siga siendo atribuible con independencia del transporte.

Ambos codifican los atributos de rol (PSP_AI, PSP_PI, PSP_IC), lo que permite a un banco comprobar la autorización sin un contrato bilateral. Los certificados prueban la identidad; no autorizan el acceso a una cuenta concreta. Lo que concede el acceso es el consentimiento del cliente, recogido mediante una redirección a la autenticación de su propio banco —una separación que encaja de forma natural con el flujo authorization code de OAuth 2.0 que usan la mayoría de las implementaciones, a menudo con OpenID Connect por encima.

El panorama de los estándares

Una directiva, varios estándares de API, porque la normativa especificó deliberadamente resultados y no esquemas.

Berlin Group NextGenPSD2 es el más implantado en Europa continental: REST y JSON, un recurso de consentimiento explícito y varios enfoques de SCA (redirección, desacoplado, embebido). Su flexibilidad es también su debilidad: cada banco elige opciones distintas, así que «compatible con Berlin Group» no significa que se pueda conectar sin más.

UK Open Banking nació de una medida correctora de la autoridad de competencia británica y no solo de la PSD2, lo que permitió una especificación más estricta y con gobierno centralizado, con un directorio, pruebas de conformidad y un perfil de OpenID Connect obligatorio. Por eso es el más homogéneo de los tres.

STET, originario de Francia, es una especificación REST compacta y muy alineada con el vocabulario de ISO 20022 en los payloads de iniciación de pagos.

Consecuencia práctica: incluso dentro de un mismo estándar, cuenta con peculiaridades de cada banco en la paginación, la profundidad del histórico de movimientos, la semántica de la fecha contable, el tratamiento de divisas y los códigos de error. Los equipos o bien integran a través de un agregador, o bien construyen una capa de adaptadores por banco detrás de un modelo interno normalizado: un uso de manual de la idea de capa anticorrupción, y de las cuestiones de enrutamiento y cuotas que se tratan en gestión de API y gateways.

Un flujo típico de información de cuentas

La forma es la misma en todos los estándares aunque los detalles cambien. Primero se crea un consentimiento que describe exactamente lo que se solicita:

POST /v1/consents HTTP/1.1
Host: api.examplebank.test
X-Request-ID: 1a2b3c4d-5e6f-4a7b-8c9d-0e1f2a3b4c5d
PSU-IP-Address: 203.0.113.14
TPP-Signature-Certificate: <base64 QSEALC>
Signature: keyId="SN=...,CA=...",algorithm="rsa-sha256",headers="digest x-request-id",signature="..."
Content-Type: application/json

{
  "access": { "balances": [ { "iban": "GB11ABCD12345678901234" } ],
              "transactions": [ { "iban": "GB11ABCD12345678901234" } ] },
  "recurringIndicator": true,
  "validUntil": "2026-12-07",
  "frequencyPerDay": 4,
  "combinedServiceIndicator": false
}

El banco responde con un identificador de consentimiento y un enlace a su página de autenticación. El cliente es redirigido allí, se autentica con SCA ante su propio banco y vuelve a tu URI de redirección. El consentimiento pasa entonces de received a valid, y ya se pueden hacer llamadas de datos:

GET /v1/accounts/3dc3d5b3-7023-4848-9853-f5400a64e80f/transactions?bookingStatus=booked&dateFrom=2026-08-01 HTTP/1.1
Consent-ID: 4a1e7a2c-88f1-4f2f-9a1e-8b7c6d5e4f30
Authorization: Bearer eyJhbGciOiJQUzI1NiIsInR5cCI6IkpXVCJ9...

Una iniciación de pago sigue el mismo patrón: crear el recurso de pago, redirigir para la autenticación y consultar después el estado —RCVD, ACTC, ACSC y compañía, tomados directamente del vocabulario de ISO 20022 descrito en fundamentos de los sistemas de pago.

Notas de diseño que ahorran semanas:

• El consentimiento es una entidad de primer nivel en tu dominio. Persiste su identificador, alcance, caducidad, estado y la frecuencia diaria restante; haz que el recorrido de renovación dependa de él.
• No guardes nunca las credenciales bancarias de los clientes. Además de estar prohibido, el mero hecho de recibirlas convierte tu servicio en objetivo de phishing.
• Trata a todos los bancos como poco fiables. Timeouts, ventanas de mantenimiento y datos parciales son lo normal; usa circuit breakers, cachea indicando claramente la antigüedad de los datos y degrada a una «última actualización» en lugar de a una página de error.
• Registra para auditar, no el contenido. Los reguladores y las disputas necesitan pruebas del consentimiento y de lo que se solicitó; el contenido de las cuentas en los logs de la aplicación es un pasivo.
• Minimiza los datos. Pedir noventa días de todas las cuentas cuando necesitas un saldo actual es a la vez un riesgo de cumplimiento y un producto más lento.

Hacia dónde van las reglas

La Comisión Europea ha propuesto un paquete sucesor: una directiva revisada (conocida habitualmente como PSD3) junto con un reglamento de servicios de pago de aplicación directa, además de un marco independiente para un acceso más amplio a los datos financieros. La dirección del cambio apunta a obligaciones de rendimiento de las interfaces más estrictas, con el requisito de contingencia eliminado para los bancos que las cumplan; a reglas más claras sobre la autenticación y sobre la responsabilidad en el fraude por suplantación de identidad; a una supervisión más coherente, y al paso del detalle técnico de las transposiciones nacionales a un texto de aplicación directa. Los textos todavía se están moviendo; construye para las reglas actuales y mantén reemplazables las partes de tu arquitectura dedicadas al consentimiento y la autenticación.

Ideas clave

• La PSD2 obliga a los bancos a abrir las cuentas de pago a terceros con licencia que actúan con el consentimiento explícito del cliente, en sustitución del screen scraping basado en compartir credenciales.
• Importan cuatro roles: el banco gestor de la cuenta, el proveedor de información sobre cuentas, el proveedor de iniciación de pagos y el rol de confirmación de fondos para emisores de tarjetas.
• La autenticación reforzada de clientes requiere dos factores independientes más la vinculación dinámica del importe y el beneficiario; las exenciones las solicita el proveedor, pero las concede el banco.
• Los certificados eIDAS identifican al tercero en la capa de transporte y en la de mensaje, mientras que las redirecciones al estilo OAuth transportan el consentimiento del cliente.
• Berlin Group, UK Open Banking y STET resuelven la misma obligación de forma distinta, y la variación entre bancos obliga a tener una capa de adaptadores o un agregador.
• Modela el consentimiento de forma explícita, cuenta con caducidades e interfaces inestables, minimiza los datos que pides y mantén reemplazable la capa de autenticación a medida que lleguen la PSD3 y el reglamento de servicios de pago.