# Arquitectura técnica de una API DSP2: lo que hay que saber antes de escribir la primera línea de código > Panorama técnico de la DSP2 para CTO, desarrolladores y PM técnicos: estándares de API, seguridad (mTLS, certificados eIDAS), OAuth2, flujos SCA, gestión del consentimiento, trampas de implementación. _Publicado el: 2026-04-07 · Category: técnico · Tags: #dsp2 #psd2 #open-banking #arquitectura #api #técnico_ --- La [DSP2](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/tpp) socio o para exponer sus propias API. Para la versión de negocio / producto, consulte mejor: [Entender la PSD2 visualmente](/blog/comprendre-psd2-visuellement). ## El stack DSP2 en una imagen Una llamada DSP2 atraviesa varias capas que no sirven para lo mismo. Ninguna es negociable. ```mermaid flowchart TB subgraph APP["Aplicación TPP"] BL["Lógica de negocio\n(agregación, pago…)"] end subgraph SEC["Capa de seguridad"] OAUTH["OAuth2\n(consentimiento y tokens)"] SIG["Firma de las peticiones\n(QSealC)"] TLS["mTLS\n(QWAC)"] end subgraph API["API ASPSP"] STD["Estándar de API\n(STET / Berlin Group / OB UK)"] ENDPOINTS["Endpoints AIS / PIS / CBPII"] end BL --> OAUTH OAUTH --> SIG SIG --> TLS TLS --> STD STD --> ENDPOINTS ``` 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](https://openfinanceguide.com/es/glossary/stet) | Francia y Bélgica | REST/JSON, basado en [ISO 20022](https://openfinanceguide.com/es/glossary/iso-20022) | | [Berlin Group](https://openfinanceguide.com/es/glossary/berlin-group) | Mayoría de la UE | REST/JSON, el más extendido | | [Open Banking UK](https://openfinanceguide.com/es/glossary/open-banking-uk) | Reino Unido | El más maduro, perfil [FAPI](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/bridge), [Tink](https://openfinanceguide.com/es/glossary/tink), [TrueLayer](https://openfinanceguide.com/es/glossary/truelayer), [Yapily](https://openfinanceguide.com/es/glossary/yapily)) que absorbe esa fragmentación a cambio de un margen. > **Info:** > Fuera de la UE, el estándar [FAPI](https://openfinanceguide.com/es/glossary/fapi) de la OpenID Foundation > se impone como referencia (Reino Unido, Brasil, Australia). Berlin Group y STET > retoman sus principios pero de forma más flexible — se espera convergencia con > [DSP3](https://openfinanceguide.com/es/glossary/dsp3) y [FIDA](https://openfinanceguide.com/es/glossary/fida). ## 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](https://openfinanceguide.com/es/glossary/eidas-tsp). ```mermaid flowchart TB NCA["⚖️ NCA\n(p. ej. ACPR)"] QTSP["🔏 QTSP\n(p. ej. Certigna)"] TPP["🏢 TPP\nPosee los certificados"] ASPSP["🏦 ASPSP\nVerifica en cada llamada"] NCA -->|"1. Autoriza al TPP"| TPP TPP -->|"2. Solicita los certificados"| QTSP QTSP -->|"3. Emite QWAC + QSealC"| TPP TPP -->|"4. Presenta sus certificados"| ASPSP ASPSP -->|"5. Verifica en el registro"| NCA ``` Dos certificados, dos usos: - [QWAC](https://openfinanceguide.com/es/glossary/qwac) — sirve para establecer el canal [mTLS](https://openfinanceguide.com/es/glossary/mtls). Identifica al TPP a nivel de transporte. Piense en un «documento de identidad». - [QSealC](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/oauth2) en su flujo **Authorization Code + PKCE**. Nada exótico, pero con restricciones: 1. El TPP construye la URL de autorización y redirige al PSU hacia el banco. 2. El banco autentica al PSU (login + [SCA](https://openfinanceguide.com/es/glossary/sca)) y luego muestra la pantalla de consentimiento. 3. Retorno al TPP con un código de un solo uso. 4. Intercambio del código por un **access token** (corto) y un **refresh token** (largo, hasta 180 días en el lado AISP). 5. Cada llamada de API lleva `Authorization: Bearer ` **y** la firma QSealC **y** pasa por mTLS. Para los perfiles más estrictos ([FAPI](https://openfinanceguide.com/es/glossary/fapi) 1.0 Advanced o 2.0), se añade [JWT / JWS / JWE](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/sca-flows). | 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. | ```mermaid sequenceDiagram autonumber participant TPP participant AS as Authorization Server (ASPSP) participant PSU participant RS as Resource Server (ASPSP) TPP->>AS: 1. Crea el consentimiento AS-->>TPP: consentId + URL de auth TPP->>PSU: 2. Redirect / Decoupled / Embedded PSU->>AS: 3. Autenticación + SCA AS-->>TPP: 4. Código OAuth (callback) TPP->>AS: 5. Intercambia código → access_token (mTLS) AS-->>TPP: access_token + refresh_token TPP->>RS: 6. GET /accounts (Bearer + QSealC + mTLS) RS-->>TPP: Datos de cuentas ``` 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. ```mermaid stateDiagram-v2 [*] --> Created: El TPP crea el consentimiento Created --> Authenticated: El PSU se autentica + SCA Authenticated --> Valid: El banco valida Created --> Rejected: El PSU rechaza Created --> Expired: Plazo SCA superado Valid --> Revoked: El PSU revoca Valid --> Expired: 180 días transcurridos Rejected --> [*] Revoked --> [*] Expired --> [*] ``` 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](https://openfinanceguide.com/es/glossary/mtls), firma, idempotencia Tres exigencias técnicas estructuran toda integración DSP2. - **[mTLS](https://openfinanceguide.com/es/glossary/mtls)** en todas las llamadas back-channel. El TPP presenta su [QWAC](https://openfinanceguide.com/es/glossary/qwac), el banco presenta el suyo. - **[HTTP Signature](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/dsp3) y [PSR](https://openfinanceguide.com/es/glossary/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](https://openfinanceguide.com/es/glossary/app-fraud)): [VoP](https://openfinanceguide.com/es/glossary/vop) (Verification of Payee) en los SEPA, intercambio de indicadores entre actores. - **Convergencia FAPI** más que probable, alineación con la [EUDI Wallet](https://openfinanceguide.com/es/glossary/eudi-wallet) para la identidad. - **[FIDA](https://openfinanceguide.com/es/glossary/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: 1. Elegir uno o varios **estándares** (STET, Berlin Group, eventualmente OB UK). 2. Obtener y mantener vivos los **certificados eIDAS** (QWAC + QSealC). 3. Implementar [OAuth2](https://openfinanceguide.com/es/glossary/oauth2) con PKCE, firma de petición e idempotencia. 4. Soportar los **tres flujos SCA** en el lado UX y en el lado backend. 5. Modelar el **consentimiento** como un objeto de primer orden, con su ciclo de vida. 6. Gestionar la **fragmentación** banco por banco — o subcontratarla a un agregador. Para la versión de producto / negocio, lea [Entender la PSD2 visualmente](/blog/comprendre-psd2-visuellement). Para el vocabulario completo, el [glosario Open Banking](/glossary) está indexado por categoría. --- Fuente: https://openfinanceguide.com/es/blog/architecture-api-dsp2