Open banking y PSD2: API propia frente a agregadores de terceros

La Directiva (UE) 2015/2366, conocida como PSD2, obliga a los bancos de la Zona Económica Europea a exponer interfaces de programación (APIs) seguras para que proveedores autorizados, con el consentimiento explícito del cliente, puedan leer datos de cuentas e iniciar pagos. En España, el marco transpositivo es el Real Decreto-Ley 19/2018, cuyo artículo 4 define los "servicios de información sobre cuentas" y fija las condiciones de acceso (BOE, RDL 19/2018).

La consecuencia práctica para el ecosistema patrimonial es directa: cualquier plataforma que lea saldos, movimientos o posiciones de cuentas bancarias de un tercero está prestando un servicio regulado. No es una cuestión técnica. Es una obligación legal con consecuencias para el operador y para el cliente.

Consentimiento explícito

PSD2 no admite acceso pasivo ni acceso implícito. El cliente debe autorizar de forma activa, identificar al proveedor que recibirá sus datos y conocer el propósito para el que se utilizarán. El consentimiento es revocable en cualquier momento, sin necesidad de justificación, y el banco está obligado a respetar esa revocación de forma inmediata (Molina Law Boutique, análisis AISP/PSD2).

Supervisión: el Banco de España

En España, el supervisor del registro de proveedores de servicios de información sobre cuentas es el Banco de España. El Registro Especial de Entidades Prestadoras de Servicios de Información sobre Cuentas (BdE) es público y consultable. Operar sin inscripción en ese registro constituye un incumplimiento del RDL 19/2018 y puede dar lugar a sanciones de hasta el 10% del volumen anual de negocio o superiores a 5 millones de euros (RDL 19/2018 art. 4; Legal Auditors, análisis de sanciones AISP). Este es el primer criterio de verificación que cualquier CFO debería aplicar a cualquier proveedor que evalúe.

Este artículo es informativo y no constituye asesoramiento jurídico ni de cumplimiento normativo. Para un análisis aplicado a su entidad, consulte con un asesor legal especializado.

La figura AISP: qué puede y qué no

Un proveedor de servicios de información sobre cuentas, o AISP por sus siglas en inglés (Account Information Service Provider), es la figura jurídica que habilita el acceso a datos bancarios bajo PSD2. Sus atribuciones están acotadas por la norma de forma explícita: acceso solo lectura, uso exclusivo para el propósito declarado en el consentimiento, y ninguna capacidad para iniciar movimientos de fondos (Molina Law Boutique, análisis AISP/PSD2).

Un AISP no puede hacer cargos, transferencias ni ninguna otra operación que altere el saldo. La confusión entre "conectar un banco" y "dar acceso a mi dinero" está detrás de la mayoría de las objeciones que los CFOs plantean al evaluar estas plataformas. La respuesta normativa es clara: el banco sigue siendo el custodio; el AISP solo lee.

SCA y renovación cada 180 días

La Autenticación Reforzada de Cliente (SCA) exige que el acceso se autorice con al menos dos de tres factores: algo que el usuario sabe, algo que posee y algo que es. No se aplica solo en el alta del servicio, sino que debe renovarse periódicamente.

Desde el 25 de julio de 2023, ese período de renovación es de 180 días, tras la modificación del artículo 10 bis del Reglamento Delegado (UE) 2018/389 por el Reglamento Delegado (UE) 2022/2360. Este dato importa porque muchas fuentes siguen citando el período anterior de 90 días, ya derogado. Un proveedor que lo mencione está trabajando con documentación desactualizada.

El ecosistema español de open banking en cifras

España es, dentro de la EEA, el mercado con mayor número de proveedores de terceros passported-in. Al cierre de 2022 ese número ascendía a 129 TPPs passported-in, el más elevado de la región, junto a 9 TPPs domésticos, 46 APIs bancarias activas y 25 agregadores de API operando en el mercado local. La cifra de passported-in corresponde al cierre de 2022 y no ha sido actualizada de forma oficial desde entonces.

En cuanto a estándares, la mayor parte del mercado europeo ha convergido hacia el protocolo Berlin Group NextGenPSD2, que agrupa a más de 3.600 bancos europeos y representa más del 75% de las interfaces de open banking activas en la EEA. Convergencia de estándares no es, sin embargo, homogeneidad de calidad.

Según WealthReader, proveedor especializado en conectividad bancaria, algunos bancos medianos exponen APIs con tiempos de respuesta de entre 8 y 12 segundos, frente a la referencia de rendimiento de 300 a 500 milisegundos. Los formatos de datos son también inconsistentes en determinadas entidades, y la calidad de los entornos de prueba varía de forma significativa. Esta desigualdad tiene consecuencias directas en la calidad del dato que llega a la plataforma de consolidación, con independencia del modelo de conectividad que se use.

Dos modelos de conectividad

La pregunta de arquitectura que distingue a los proveedores no es si están regulados, sino cómo acceden al dato bancario. Hay dos modelos estructuralmente distintos.

Conectividad subcontratada: banco a agregador a plataforma

En este modelo, la plataforma de consolidación no establece conexión directa con los bancos. Externaliza esa capa a un agregador especializado, que es quien mantiene las conexiones API con las entidades y entrega los datos normalizados a la plataforma.

El ejemplo más documentado públicamente en España es CaixaBank GlobalView, lanzado en abril de 2026 para banca privada. La arquitectura pública del servicio incluye a Flanks como proveedor de agregación de datos, inscrito en el Registro del Banco de España como AISP desde el 11 de mayo de 2021, con más de 500.000 carteras procesadas mensualmente y presencia en más de 600 conexiones en 33 países. El motor de análisis es Aladdin Wealth de BlackRock. La cadena completa es: banco del cliente, API del banco, Flanks, plataforma de CaixaBank, cliente.

Esta arquitectura es legítima y está compuesta por entidades reguladas. Lo relevante para el CFO no es si el modelo es seguro o inseguro, sino qué implica añadir eslabones a la cadena. Cada nodo adicional es un punto potencial de latencia, de transformación del dato y de responsabilidad distribuida. Ante una incidencia en la calidad del dato o en la disponibilidad del servicio, la resolución requiere coordinar al menos dos proveedores: la plataforma y el agregador.

Para un análisis comparativo completo sobre independencia e implicaciones de este modelo, puede consultarse VUMI vs CaixaBank Open Wealth: consolidar todos tus bancos y el artículo pilar banca privada vs software independiente de consolidación patrimonial.

API propia: banco a plataforma directo

En el modelo de API propia, la plataforma es ella misma el AISP registrado y mantiene las conexiones directamente con los bancos y custodios, sin intermediarios de conectividad. VUMI opera bajo este modelo y es, a fecha de redacción de este artículo, el único proveedor en España con API de conexión propia a bancos y custodios.

Las implicaciones son estructurales. El dato llega de la fuente a la plataforma sin reinterpretación intermedia. La trazabilidad ante cualquier incidencia remite a un único interlocutor. Y el SLA de conectividad es responsabilidad directa de la plataforma, sin dependencia de un tercero externo.

Tabla comparativa: dos modelos de conectividad

El riesgo de la "cuarta parte" y la responsabilidad ante el consejo

El Reglamento (UE) 2022/2554, conocido como DORA (Digital Operational Resilience Act), está en vigor desde el 17 de enero de 2025. Su principio central en materia de subcontratación es que la responsabilidad final sobre la cadena TIC recae en el órgano de dirección de la entidad, no en el proveedor externo (EUR-Lex, DORA, en vigor 17-ene-2025).

El Reglamento Delegado (UE) 2025/532, en vigor desde el 22 de julio de 2025, desarrolla los criterios para la evaluación de la subcontratación TIC de funciones esenciales, estableciendo requisitos específicos de documentación, auditoría y gestión de riesgos para los proveedores de terceros (BOE, Reg. Delegado 2025/532). Adicionalmente, la EBA abrió en julio de 2025 una consulta pública, cerrada en octubre de 2025, para ampliar la gestión de terceros más allá del perímetro actual de DORA (Linklaters, análisis EBA jul. 2025).

El concepto de "cuarta parte" describe el riesgo operativo que se genera cuando un proveedor contratado externaliza, a su vez, una función crítica a un tercero. En el contexto de la consolidación patrimonial, el CFO que reporta al consejo sobre el patrimonio del grupo puede estar operando con datos cuya cadena de producción incluye un proveedor que él no contrató directamente, y cuyo SLA no forma parte de su contrato.

Esto no convierte el modelo de agregación en algo inaceptable. Lo que exige es que el órgano de dirección conozca esa cadena, la documente y evalúe el riesgo residual, tal y como requiere DORA. Para orientarse sobre qué información debe incluir ese reporte, puede ser útil revisar qué debe incluir un informe patrimonial para el consejo de administración.

Este artículo es informativo y no constituye asesoramiento jurídico ni de cumplimiento normativo con respecto a DORA o cualquier otra normativa. Para un análisis aplicado, consulte con un asesor legal especializado.

Qué cambiará con PSD3 y FIDA

El marco regulatorio de open banking está en evolución activa, aunque ninguna de las normas en tramitación está vigente hoy.

PSD3 y el Reglamento de Servicios de Pago (PSR) alcanzaron un acuerdo provisional el 27 de noviembre de 2025, confirmado por el Consejo de la UE en abril de 2026. La publicación en el Diario Oficial está prevista para el primer semestre de 2026, con un período de transposición de 21 meses. La aplicabilidad estimada en España es alrededor de 2027 (Crassula, análisis PSD3; Hogan Lovells, publicación abr. 2026). PSD3 no elimina el modelo de solo lectura ni modifica la figura AISP de forma sustancial: refuerza los estándares de calidad de las APIs bancarias y amplía el perímetro de activos cubiertos.

FIDA (Financial Data Access) amplía el concepto de open banking al conjunto de datos financieros del cliente, seguros, pensiones e inversiones incluidos. A fecha de este artículo el reglamento sigue en trílogo en el Parlamento Europeo, con operatividad estimada no antes de 2029-2030 (Taylor Wessing, análisis FIDA jul. 2025). No está en vigor.

La implicación práctica para quien evalúa plataformas hoy es esta: una plataforma que mantiene su propia infraestructura de conectividad tiene más capacidad para absorber cambios regulatorios sin depender de que un tercero actualice su capa de agregación. Cada revisión normativa que obliga a actualizar el protocolo de acceso es un punto de fricción adicional cuando la cadena incluye un intermediario.

Por qué la API propia de VUMI es relevante para el CFO

VUMI está inscrito en el Registro del Banco de España como AISP, lo que lo habilita para acceder a datos bancarios bajo el marco PSD2 con plena cobertura regulatoria. La diferencia estructural respecto a plataformas que subcontratan la conectividad es que VUMI mantiene sus propias conexiones directas con bancos y custodios. Es el único proveedor en España con este modelo.

Para el CFO, eso se traduce en tres implicaciones concretas. El dato que llega al informe es el dato de la fuente, sin transformación intermedia. Ante cualquier incidencia técnica, hay un único interlocutor responsable del SLA. Y la cadena de responsabilidad que exige DORA es más corta y más fácil de documentar ante el consejo.

A esto se añade que VUMI consolida todas las clases de activo en una sola vista: cuentas corrientes, inversiones financieras, inmobiliario y participadas. La cobertura no se limita a los activos conectables por open banking; incluye el patrimonio completo del grupo. El informe resultante es personalizable en formato, periodicidad y nivel de detalle, y está diseñado para presentarse ante la familia o el consejo sin trabajo de edición adicional.

Contrastar si este modelo se ajusta a los requisitos concretos de un family office o de un holding familiar requiere una conversación, no una comparativa genérica. VUMI pone ese análisis a disposición de los equipos que quieran hacerlo.

Preguntas frecuentes

¿Qué es un AISP y qué puede hacer con mis datos?

Un AISP (Account Information Service Provider) es un proveedor regulado bajo PSD2 que, con el consentimiento explícito del cliente, puede leer datos de cuentas bancarias, como saldos y movimientos. Solo puede acceder con ese propósito declarado, y únicamente en modo lectura. No puede realizar ninguna operación sobre los fondos.

¿Puede un AISP mover o disponer de mi dinero?

No. La categoría AISP es estrictamente de lectura. Cualquier operación que implique movimiento de fondos, como una transferencia o un cargo, requiere una figura diferente (PISP, Payment Initiation Service Provider) y un consentimiento específico para esa operación. Los dos permisos son independientes y no se solapan.

¿Puedo revocar el acceso que he dado a un AISP?

Sí, en cualquier momento y sin necesidad de justificación. El banco está obligado a ejecutar la revocación de forma inmediata. El AISP no puede conservar el acceso ni los datos más allá del propósito para el que se autorizó.

¿Qué es la SCA y cada cuánto se renueva?

La SCA (Strong Customer Authentication) o Autenticación Reforzada de Cliente exige confirmar la identidad mediante al menos dos de tres factores: algo que sabes, algo que tienes y algo que eres. Desde el 25 de julio de 2023, la renovación de ese consentimiento autenticado para acceso continuado de un AISP es obligatoria cada 180 días, según el Reglamento Delegado (UE) 2022/2360. El plazo anterior de 90 días está derogado.

¿Qué diferencia a un agregador de terceros de una plataforma con API propia?

Un agregador de terceros es un intermediario que mantiene las conexiones con los bancos y entrega los datos normalizados a la plataforma final. La cadena es: banco, agregador, plataforma, cliente. Una plataforma con API propia conecta directamente con los bancos, sin ese intermediario. La diferencia práctica está en la responsabilidad del SLA, la trazabilidad ante incidencias y la integridad del dato en el trayecto.

¿Está el open banking regulado en España? ¿Quién supervisa?

Sí. La norma de referencia en España es el Real Decreto-Ley 19/2018, que transpone PSD2. El supervisor del registro de proveedores AISP y PISP es el Banco de España, que mantiene un registro público consultable. Operar sin inscripción puede dar lugar a sanciones de hasta el 10% del volumen anual de negocio o superiores a 5 millones de euros.

¿Qué es DORA y qué obliga respecto a los proveedores tecnológicos?

DORA (Reglamento UE 2022/2554, en vigor desde el 17 de enero de 2025) establece que la responsabilidad final sobre la cadena tecnológica y los terceros proveedores recae en el órgano de dirección de la entidad, no en el proveedor externo. El Reglamento Delegado 2025/532 (en vigor desde el 22 de julio de 2025) desarrolla los requisitos de evaluación de subcontratación TIC para funciones esenciales. Ante una incidencia con un proveedor externo, la entidad no puede delegar esa responsabilidad.

¿Qué cambiará con PSD3 y FIDA?

PSD3 alcanzó un acuerdo provisional en noviembre de 2025 y su aplicabilidad en España se estima alrededor de 2027. Refuerza la calidad de las APIs bancarias y amplía el perímetro de activos, pero no elimina el modelo de solo lectura ni modifica la figura AISP de forma sustancial. FIDA, que amplía el open banking a seguros, pensiones e inversiones, sigue en trílogo y no se espera operativa antes de 2029-2030. Ninguna de las dos normas está en vigor actualmente.

Para profundizar en la objeción de seguridad desde un enfoque más operativo, puede consultarse [¿Es seguro conectar mis bancos a una plataforma de consolidación?](https://www.vumi.io/blog/seguridad-conectar-bancos-plataforma-consolidacion).

Fuentes

• Open Banking Tracker / Noda, oct. 2024
• Finreg360, jul. 2023
• Noda, oct. 2024
• WealthReader, blog técnico jul. 2025
• Fintech Global, abr. 2026; Funds Society, may. 2021; CaixaBank, comunicado de prensa abr. 2026