La DSP2 suele verse desde el lado de negocio como una simple «obligación de los bancos de abrir API». Desde el lado técnico, es un ensamblaje nada trivial: múltiples estándares, certificados electrónicos cualificados, OAuth2 reforzado, flujos de autenticación asíncronos y una fragmentación muy real entre bancos.
Este artículo ofrece una visión de alto nivel pero precisa de esa arquitectura, para CTO, PM técnicos y desarrolladores que deben estimar un proyecto DSP2 — ya sea para integrar un TPP socio o para exponer sus propias API. Para la versión de negocio / producto, consulte mejor: Entender la PSD2 visualmente.
El stack DSP2 en una imagen
Una llamada DSP2 atraviesa varias capas que no sirven para lo mismo. Ninguna es negociable.
Para recordar: no basta con firmar las peticiones por HTTPS clásico. El canal es mTLS (ambas partes se autentican), los payloads se firman de forma independiente y la autorización pasa por un OAuth2 estrictamente perfilado.
Los estándares de API: no uno, sino tres
La directiva obliga a abrir API pero no dicta el formato. Tres estándares se han impuesto en Europa.
| Estándar | Cobertura | Estilo |
|---|---|---|
| STET | Francia y Bélgica | REST/JSON, basado en ISO 20022 |
| Berlin Group | Mayoría de la UE | REST/JSON, el más extendido |
| Open Banking UK | Reino Unido | El más maduro, perfil FAPI obligatorio |
Consecuencias concretas:
- Cubrir toda Francia = soportar STET (BNP, Société Générale, BPCE, Crédit Agricole, La Banque Postale, etc.) más algunas implementaciones Berlin Group de bancos en línea.
- Escalar en Europa = añadir Berlin Group con las variantes por país (Alemania, España e Italia no respetan exactamente la misma versión).
- En la práctica, muchos equipos usan un agregador (Bridge, Tink, TrueLayer, Yapily) que absorbe esa fragmentación a cambio de un margen.
La cadena de confianza: eIDAS, QWAC y QSealC
La DSP2 responde a una pregunta sencilla: ¿cómo sabe un banco que una llamada de API viene realmente de un TPP autorizado? La respuesta pasa por los certificados electrónicos cualificados del reglamento eIDAS TSP.
Dos certificados, dos usos:
- QWAC — sirve para establecer el canal mTLS. Identifica al TPP a nivel de transporte. Piense en un «documento de identidad».
- QSealC — firma el contenido de las peticiones (firma separada). Garantiza la integridad y el no repudio del payload. Piense en un «sello de lacre en el sobre».
Ambos codifican los roles PSD2 del TPP (AISP / PISP / CBPII). El banco verifica dinámicamente que el certificado cubra realmente la operación solicitada.
OAuth2: materializar el consentimiento
En el lado de la autorización, es OAuth2 en su flujo Authorization Code + PKCE. Nada exótico, pero con restricciones:
- El TPP construye la URL de autorización y redirige al PSU hacia el banco.
- El banco autentica al PSU (login + SCA) y luego muestra la pantalla de consentimiento.
- Retorno al TPP con un código de un solo uso.
- Intercambio del código por un access token (corto) y un refresh token (largo, hasta 180 días en el lado AISP).
- Cada llamada de API lleva
Authorization: Bearer <token>y la firma QSealC y pasa por mTLS.
Para los perfiles más estrictos (FAPI 1.0 Advanced o 2.0), se añade JWT / JWS / JWE para las peticiones firmadas (JAR) y la vinculación del token al certificado de cliente. Es obligatorio en el Reino Unido, opcional / no impuesto en Berlin Group y STET.
Los tres flujos SCA que hay que soportar
El momento en que el PSU se autentica ante su banco (la SCA) puede adoptar tres formas, y es el banco quien elige, no usted. Cubrir todo el mercado obliga a gestionar las tres — véase Flux SCA.
| Flujo | Cómo funciona | Cuándo lo elige el banco |
|---|---|---|
| Redirect | El PSU es redirigido a la web o la app de su banco, y luego vuelve. | El estándar de hecho en Francia. |
| Decoupled | Notificación push en la app bancaria, validación biométrica, polling en el TPP. | Neobancos, mejor UX móvil. |
| Embedded | El PSU introduce sus credenciales en la interfaz del TPP, que las transmite. | Raro, desaconsejado, a menudo vetado. |
Trampas frecuentes:
- En decoupled, algunos bancos exigen un retardo mínimo entre el disparo y el polling, otros limitan el número de llamadas e imponen un webhook.
- En redirect, los retornos móviles vía deep link son fuente de errores: prevea un fallback web.
- Una sola SCA inicial, y luego 180 días de acceso AIS vía refresh token sin nueva SCA — es el reglamento EBA de 2022. Antes de 2022 eran 90 días.
El consentimiento: un objeto que hay que modelar de principio a fin
El consentimiento no es una variable booleana. Es un objeto almacenado en el banco, con:
- Un perímetro (cuentas, tipos de acceso: saldos, transacciones, detalles).
- Una ventana temporal (hasta 180 días para AIS, de un solo uso para PIS).
- Una frecuencia (4 actualizaciones al día sin presencia del PSU).
- Un estado que evoluciona en el tiempo.
En el lado de la implementación, debe:
- Persistir el consentId y vincularlo a su PSU.
- Vigilar su estado (poll + webhook si está disponible).
- Disparar una renovación antes de la expiración, idealmente con una UX que se anticipe.
- Gestionar la revocación en el banco: un consentimiento activo en su lado puede apagarse sin que usted lo sepa mientras no llame a la API.
Seguridad: mTLS, firma, idempotencia
Tres exigencias técnicas estructuran toda integración DSP2.
- mTLS en todas las llamadas back-channel. El TPP presenta su QWAC, el banco presenta el suyo.
- HTTP Signature de las peticiones vía QSealC: la firma cubre las cabeceras críticas y un hash del body. Imprescindible en el lado PIS para no poder negar una iniciación de pago.
- Idempotency key en todas las operaciones PIS para evitar pagos dobles en caso de reintento de red.
A esto se añade la gestión robusta de los errores: códigos HTTP, códigos de negocio propios de cada estándar, rate limits, franjas de mantenimiento bancario. Ninguna API ASPSP tiene un SLA contractual del 99,99 %.
¿Webhook o polling?
Para seguir el estado de un consentimiento, de un pago iniciado o de un flujo SCA decoupled, coexisten dos mecanismos — véase Webhook / Polling.
- Polling: el TPP consulta la API de estado a intervalos. Universal, pero costoso y lento.
- Webhook: el banco llama a un endpoint del TPP. Reactivo, pero pocos bancos exponen uno fiable en el lado DSP2 de la UE.
En la práctica se combinan: webhook cuando está disponible, polling de respaldo, con backoff exponencial.
Probar sin romper la producción
Tres entornos que hay que conocer:
- Sandbox pública: abierta, sin certificados eIDAS reales. Útil para el POC.
- Sandbox certificada: requiere certificados de prueba emitidos por un QTSP, con un proceso de inscripción por banco. Es donde se valida la integración de extremo a extremo.
- Producción: requiere la autorización ACPR (o equivalente), certificados QWAC + QSealC válidos y el registro previo ante cada banco.
El paso de la sandbox a producción rara vez es transparente: tamaño de los payloads, latencias, códigos de error, SCA real frente a simulada — cada banco reserva sorpresas.
¿Y después? Lo que cambian DSP3 y PSR
Para los equipos técnicos, las evoluciones a anticipar:
- Calidad de API medida y publicada por los reguladores: SLA, tiempos de respuesta, tasa de error.
- Fin del screen scraping: ya no habrá fallback fuera de la API.
- Antifraude reforzado (en particular APP fraud): VoP (Verification of Payee) en los SEPA, intercambio de indicadores entre actores.
- Convergencia FAPI más que probable, alineación con la EUDI Wallet para la identidad.
- FIDA: extensión a nuevas familias de datos (ahorro, crédito, seguros). El modelo técnico está muy inspirado en la DSP2 pero con esquemas de permisos más finos.
Para resumir
Construir o integrar una API DSP2 no es «enchufar una API REST más». Es:
- Elegir uno o varios estándares (STET, Berlin Group, eventualmente OB UK).
- Obtener y mantener vivos los certificados eIDAS (QWAC + QSealC).
- Implementar OAuth2 con PKCE, firma de petición e idempotencia.
- Soportar los tres flujos SCA en el lado UX y en el lado backend.
- Modelar el consentimiento como un objeto de primer orden, con su ciclo de vida.
- Gestionar la fragmentación banco por banco — o subcontratarla a un agregador.
Para la versión de producto / negocio, lea Entender la PSD2 visualmente. Para el vocabulario completo, el glosario Open Banking está indexado por categoría.