Cuando la directiva PSD2 entró en vigor en 2018, los proveedores de servicios de información sobre cuentas (AISP, por sus siglas en inglés) obtuvieron una identidad formal. Los bancos tuvieron que abrir sus API a terceros autorizados y los consumidores adquirieron el derecho legal de permitir que dichos terceros accedieran a los datos de sus cuentas de pago. Siete años después, hay cientos de AISP registrados en toda Europa y el modelo se ha extendido al Reino Unido, Brasil, Australia y partes de Oriente Medio.
Pero la realidad de construir sobre AISP infraestructura es más compleja de lo que sugiere la regulación. La calidad de las API bancarias varía según el banco y el país. Lo que se puede construir sobre los datos de un AISP no depende solo de lo que el AISP pueda extraer del banco, sino de lo que sucede una vez que esos datos salen de la entidad: dónde terminan y qué sistema los reconcilia. Para los bancos y las empresas fintech que evalúan cómo encajan los AISP en su estrategia de producto, los detalles a ambos lados de la conexión importan más que el concepto en sí.
Qué hace realmente un AISP (y qué no hace)
Un AISP tiene acceso de solo lectura a las cuentas de pago de un usuario, otorgado mediante consentimiento explícito y autenticado a través de la Autenticación Reforzada de Cliente (SCA, por sus siglas en inglés). Puede extraer datos de transacciones y metadatos básicos como la divisa y el IBAN. No puede mover dinero ni modificar los datos de la cuenta de ninguna manera. La iniciación de pagos requiere una licencia distinta.
En la práctica, los AISP extraen datos estructurados de transacciones de los bancos a través de API dedicadas y los agregan en una vista única. Un cliente con cuentas en varios bancos puede ver sus saldos y movimientos en un solo lugar, sin tener que iniciar sesión en cada aplicación bancaria por separado. Esa capa de agregación es la base para la gestión de finanzas personales, la contabilidad automatizada y la calificación crediticia.
Bajo la normativa PSD2, el consentimiento del usuario es válido durante 180 días antes de requerir una nueva autenticación. La PSD3 y su reglamento complementario, el PSR, alcanzaron un acuerdo político provisional el 27 de noviembre de 2025; se espera su publicación en la primera mitad de 2026 y su aplicación plena entre finales de 2027 y principios de 2028. Los mecanismos de consentimiento cambian en dos aspectos importantes. Primero, el banco solo realiza la SCA en el primer acceso del usuario a través de un AISP determinado. A partir de ahí, el propio AISP gestiona la reautenticación cada 180 días, eliminando la fricción de tener que redirigir al usuario al banco en cada renovación. Segundo, las API bancarias deberán igualar el rendimiento y la disponibilidad de datos de los canales directos del propio banco, cerrando una de las brechas más persistentes de la PSD2.
El problema de conectividad que nadie resolvió con la primera directiva
La PSD2 obligó a los bancos a proporcionar API, pero no exigió que fueran de buena calidad. El resultado ha sido desigual. Algunos bancos implementaron API compatibles con Berlin Group o STET, con un tiempo de actividad sólido y estructuras de datos coherentes. Otros ofrecieron lo mínimo indispensable, con interrupciones frecuentes y formatos de respuesta no estándar que hicieron inviables los casos de uso en tiempo real.
Esto es importante porque el valor de los productos basados en AISP depende de la fiabilidad del flujo de datos. Una herramienta de gestión de finanzas personales que muestra saldos desactualizados o transacciones mal categorizadas hace más daño que no tener ninguna herramienta. Un modelo de calificación crediticia que procesa historiales de transacciones incompletos produce peores resultados que uno que utiliza datos tradicionales de agencias de crédito.
La capa de agregación surgió debido a esta fragmentación. Tink (adquirida por Visa en 2022) y TrueLayer crearon un middleware que normaliza las conexiones entre cientos de bancos, gestionando las diferencias en los formatos de API y los flujos de autenticación para que la aplicación final no tenga que hacerlo. Para la mayoría de las fintech que desarrollan productos basados en datos de banca abierta, conectarse a un agregador en lugar de integrar banco por banco es el camino más práctico. Se construye una sola integración en lugar de decenas, y el agregador se encarga del mantenimiento de los conectores.
La contrapartida es que se hereda la cobertura y la latencia del agregador. Si no admiten un banco concreto en un país determinado, su producto no funcionará allí. Si su lógica de normalización categoriza erróneamente un tipo de transacción, sus datos heredarán ese error. Elegir un agregador es una decisión de adquisición con consecuencias directas para el producto.
La otra mitad de la conexión: Contabilidad Abierta
La mayoría de las discusiones sobre productos basados en AISP se detienen en la API bancaria. Esa es solo la mitad de la historia. Todo caso de uso que consume datos bancarios también necesita enviar esos datos, o los conocimientos derivados de ellos, a algún lugar. Para los casos de uso de pymes y empresas, el destino es casi siempre un sistema contable o un ERP.
Contabilidad Abierta es el término que utiliza Open Banking Tracker para referirse a esta segunda conexión. Describe la misma idea que la Banca Abierta aplicada a los datos contables: acceso estandarizado y programático a los registros almacenados en sistemas contables y ERP, intercambiados a través de API. La mecánica es similar a la integración con un AISP, pero el marco regulatorio es diferente en un aspecto importante: no existe tal marco.
Ninguna directiva obligó a Intuit o Xero a exponer sus API; lo hicieron por razones de ecosistema. Sus API varían en alcance y patrones de autenticación tanto como las API bancarias que la PSD2 debía estandarizar. El mismo patrón de agregador que se impuso en la Banca Abierta ha aparecido en el ámbito contable. Apideck ofrece API contables unificadas que se conectan a más de 40 plataformas contables y ERP a través de una única integración. Rutter y Merge ofrecen una cobertura similar con diferentes modelos comerciales y soporte para un menor número de conectores.
Para un banco o una fintech que desarrolla productos que abarcan ambas conexiones, ignorar esta capa significa tener que reconstruirla. Una integración con QuickBooks lleva semanas. Extender esa integración a Xero y NetSuite, y luego a la larga lista de plataformas restantes, se convierte en meses de trabajo más el mantenimiento continuo. El agregador de Contabilidad Abierta es para la contabilidad lo que Tink y TrueLayer son para la banca: la capa que le permite lanzar una sola integración en lugar de decenas.
Donde las dos tuberías alimentan productos reales
La agregación de cuentas para la gestión de finanzas personales (PFM) sigue siendo el caso de uso más consolidado para los AISP. Varios grandes bancos europeos ofrecen ahora vistas de cuentas agregadas que muestran a los clientes una imagen financiera completa, incluso cuando tienen cuentas en otras entidades. Esto es tanto una estrategia de retención (su banco se convierte en el panel central para todas sus finanzas) como una estrategia de datos (usted aprende dónde gastan el dinero sus clientes fuera de su ecosistema). La agregación es también lo que más se beneficia de la reducción de la fricción en la autenticación reforzada de cliente (SCA) que propone la PSD3.
La toma de decisiones crediticias es donde la presión regulatoria es más alta en este momento. Los prestamistas en la UE se están preparando para la CCD2, la Directiva de Crédito al Consumo revisada, que se aplica a partir de noviembre de 2026 y exige a los prestamistas verificar que los prestatarios puedan permitirse lo que están contratando. Los datos de transacciones de los AISP ofrecen una visión granular de los ingresos, los gastos recurrentes y los patrones de gasto que va mucho más allá de una verificación tradicional de una agencia de crédito. Para los proveedores de BNPL, esto es urgente, ya que la CCD2 los somete a los mismos requisitos de evaluación de asequibilidad que a los prestamistas de consumo tradicionales.
¿Qué es la CCD2? El contexto, el cronograma y lo que realmente significa para los prestamistas y el BNPL
La automatización de la contabilidad es el ejemplo más claro de por qué ambas tuberías son importantes. El AISP extrae las transacciones bancarias en un formato estructurado. Un motor de coincidencia reconcilia esas transacciones con los registros contables mediante el cruce de importes y descripciones de pago. El resultado reconciliado se escribe de nuevo en el sistema contable que utilice el cliente. El lado bancario de ese bucle lo resuelve un AISP. El lado contable lo resuelve un agregador de contabilidad abierta. Si se omite cualquiera de las dos capas, se vuelve a tener que crear docenas de integraciones.
La banca ERP es el caso de uso que más atención está recibiendo por parte de los equipos de banca comercial en 2025 y 2026. La idea es integrar la funcionalidad bancaria directamente en el ERP o sistema contable que la empresa ya utiliza a diario. La integración de Monzo con Xero sincroniza transacciones y categorías de seguimiento sin salir de la aplicación de Monzo. Allica Bank envía feeds bancarios de nivel ERP a los sistemas contables que utilizan sus clientes pymes, con el importe de la transacción y la información del comercio registrados como datos estructurados. J.P. Morgan y HSBC están desarrollando propuestas similares para clientes corporativos. Q2 lanzó su producto Direct ERP en mayo de 2025 para ofrecer a los bancos estadounidenses y cooperativas de crédito más pequeños la misma capacidad sin tener que desarrollarla ellos mismos. Datos Insights estima que el mercado de banca ERP tiene un valor de entre 11.000 y 19.000 millones de dólares, con un crecimiento cercano al 10% anual. Nada de esto funciona sin ambas tuberías conectadas.
Qué cambia la FIDA (y cuándo)
El Reglamento de Acceso a Datos Financieros (FIDA), propuesto junto con la PSD3 y el PSR en junio de 2023, extiende el modelo de banca abierta más allá de las cuentas de pago. Cubre los datos de inversión y pensiones bajo una nueva categoría de Proveedor de Servicios de Información Financiera (FISP), incluyendo también las pólizas de seguro y los datos hipotecarios.
El cronograma de la FIDA es menos certero que el de la PSD3. El primer diálogo tripartito comenzó en abril de 2025. Algunos comentaristas esperan su adopción en la primera mitad de 2026, con una aplicación 24 meses después de su entrada en vigor. Otros señalan que el diálogo ha sido complicado y que la FIDA aparece como un tema pendiente en el Programa de Trabajo de la UE para 2026, lo que deja la puerta abierta a nuevos retrasos. El mecanismo de compensación entre los titulares de datos y los usuarios de datos, es decir, quién paga a quién por qué datos, sigue siendo el punto más controvertido en las negociaciones.
Para los bancos y las fintech que ya operan sobre la infraestructura AISP, la FIDA representa una expansión significativa de lo que pueden incluir las vistas financieras consolidadas. Una herramienta de PFM que hoy muestra cuentas bancarias y tarjetas de crédito podría, bajo la FIDA, mostrar también saldos de pensiones y carteras de inversión. La superficie del producto crece. También lo hace la complejidad de la integración, ya que los datos de seguros e inversiones residen en sistemas aún más fragmentados que los datos contables.
Se espera que los registros AISP existentes se integren en el régimen de la PSD3 con una reautorización mínima. Las empresas que planeen expandirse a datos de inversión o seguros bajo la FIDA necesitarán la nueva licencia FISP, pero la vía regulatoria está diseñada para ampliar el marco AISP en lugar de reemplazarlo.
Elegir cómo conectarse
Para un banco o una fintech que decide cómo incorporar capacidades AISP a un producto, el espectro va desde la plena autosuficiencia hasta la externalización total.
En un extremo, usted obtiene su propia licencia AISP (o PISP, si también necesita iniciación de pagos) e integra la API de cada banco individualmente. Obtiene el máximo control sin dependencia de agregadores, pero debe mantener conectores para cada banco que admita y gestionar los flujos de SCA en todas las jurisdicciones. Esto tiene sentido si todo su modelo de negocio se basa en datos de cuentas.
En el otro extremo, usted se integra una vez con un agregador que mantiene cientos de conexiones bancarias. Obtiene una amplia cobertura y una rápida llegada al mercado, pero depende de su calidad de datos y sus precios. Para la mayoría de las fintech que lanzan su primera función de banca abierta, esta es la opción pragmática.
Un punto intermedio común para los propios bancos es convertirse en AISP para acceder a los datos de otras entidades, al tiempo que exponen sus propias API a terceros autorizados. Puede ofrecer agregación multibancaria a sus propios clientes mientras participa en el ecosistema más amplio de banca abierta como fuente de datos.
La misma decisión se aplica a la contabilidad abierta (Open Accounting). Puede crear usted mismo los conectores para las principales plataformas contables o contratar una API contable unificada y lanzar el producto más rápido. La mayoría de los bancos que desarrollan productos bancarios ERP terminan optando por la segunda opción, ya que la alternativa implica mantener un equipo de integraciones permanente para algo que no es su actividad principal.
Lo que es práctico ahora mismo
El panorama regulatorio está cambiando. Se espera que la publicación de la PSD3 tenga lugar en la primera mitad de 2026, y que el cumplimiento total llegue a finales de 2027 o principios de 2028. FIDA seguirá un calendario similar, aunque más lento. Los bancos que traten 2026 como un año de preparación en lugar de esperar al texto definitivo estarán en una mejor posición cuando lleguen los plazos de implementación.
En cuanto al producto, los casos de uso con mayor retorno de inversión en este momento son la agregación de cuentas, la toma de decisiones crediticias y la banca ERP. Los tres se benefician de la reducción de la fricción de la SCA que aporta la PSD3 y de la mejora en la calidad de las API que exige la nueva normativa. Los casos de uso que abarcan ambos canales, como la banca ERP y la automatización de la contabilidad, necesitan una capa de contabilidad abierta para poder lanzarse a una velocidad razonable.
Para los bancos que ya están invirtiendo en el enriquecimiento de datos de transacciones (convertir cadenas de pago sin procesar en nombres de comercios y categorías legibles), los datos de AISP son un complemento natural. Los datos enriquecidos de sus propias transacciones con tarjeta, combinados con los datos agregados de las cuentas externas de un cliente, le ofrecen una visión financiera que ninguna de las dos fuentes puede proporcionar por sí sola. Si a esa visión le añade una vía de escritura en el sistema contable del cliente, tendrá la base para obtener información sobre gastos entre instituciones y productos bancarios integrados en ERP que funcionan en toda la posición financiera del cliente, no solo en la parte que ocurre dentro de sus cuatro paredes.
