Si tu producto lee y agrega las cuentas bancarias de tus usuarios, estás prestando un servicio de información sobre cuentas. Es la puerta de entrada más barata al mundo regulado de los pagos: sin capital inicial, pero con seguro de responsabilidad civil profesional y un expediente ante el Banco de España que hay que construir bien.
¿Tu producto necesita licencia AISP? Te lo decimos en 24 h
Cuéntanos qué datos lees, de quién y para qué. Te decimos si estás dentro del perímetro, si te conviene licencia propia o ir sobre la de un tercero, y qué cuesta cada vía.
Aquí no explicamos qué es el open banking: para eso tenemos páginas específicas. Esto es lo que hay que decidir, construir y presentar para que tu empresa quede registrada y pueda operar.
Antes de abrir un expediente conviene mirar la vía corta: prestar el servicio como agente de una entidad autorizada o apoyarte en un proveedor que ya tiene el registro. Menos control y menos margen, pero salida a mercado en una fracción del tiempo.
Si el plan pasa por mover dinero —cobros, transferencias, monederos—, el AIS no basta y el proyecto salta a entidad de pago, con capital inicial en los importes que fija la normativa, salvaguarda de fondos y un expediente de otro peso.
Leer cuentas e iniciar pagos son dos servicios distintos con dos regímenes distintos. Si además vas a ordenar pagos desde la cuenta del usuario, esa página es la tuya.
Muchos proyectos combinan información sobre cuentas con otra actividad comercial o financiera. Ahí el diseño societario y el perímetro de la licencia se deciden antes de solicitar.
Depende de los servicios que prestes: el catálogo del artículo 2 de la Ley 10/2010 hay que contrastarlo con tu modelo real antes de dar nada por hecho.
Información sobre cuentas, iniciación de pagos, dinero electrónico, crédito o criptoactivos: cada modelo tiene su figura y su coste regulatorio.
Casi nadie arranca queriendo una licencia de pagos. Se llega aquí porque el producto necesita leer la cuenta del usuario y alguien pregunta con qué amparo se hace.
"Los extractos en PDF que nos suben los clientes no valen: queremos leer la cuenta con su permiso y decidir en minutos. Nos han dicho que eso ya es un servicio regulado."
"Nuestro valor es enseñar en una pantalla lo que el usuario tiene repartido en cinco entidades. Sin acceso a las cuentas no hay producto, y el acceso exige estar registrado."
"Queremos que el movimiento bancario entre solo en el software y cuadre con la factura. Es una función más de nuestro ERP, pero técnicamente es información sobre cuentas."
"Alquileres, selección de proveedores, altas de clientes: pedimos justificantes que se falsifican en dos minutos. Leer la cuenta con consentimiento es más fiable y más rápido."
El régimen del AISP es el más asequible de los pagos, pero eso no lo convierte en un trámite. Estos tres fallos son los que más dinero y más meses cuestan.
Creer que pedir las credenciales al usuario te saca del perímetro: lo que define el servicio es la actividad, no el canal técnico por el que accedes. Si consolidas información de cuentas de pago de tus usuarios como servicio, necesitas registro, uses la interfaz del banco o cualquier otro método.
Abrir expediente cuando aún no hay producto: muchos proyectos pueden validar mercado sobre la licencia de un tercero y solicitar la suya cuando el volumen lo justifique. Pedir registro con una demo y sin equipo de seguridad es la forma más cara de aprender.
Presentar la parte de seguridad y datos en blanco: el expediente de un AISP se juega en gestión de riesgos operativos, continuidad, control de accesos y tratamiento de datos personales. Es justo lo que más se despacha con dos párrafos genéricos, y lo que más requerimientos genera.
| Vía | Qué te exige | Cuándo tiene sentido |
|---|---|---|
| Registro propio como AISP | Expediente ante el Banco de España: programa de actividades, gobierno, seguridad y seguro de responsabilidad civil profesional o garantía comparable. No exige capital inicial. | Cuando la agregación es el núcleo de tu producto, quieres controlar la relación con el usuario y prever pasaporte a otros mercados. |
| Sobre la licencia de un tercero | Contrato con una entidad autorizada, alta como agente cuando proceda y dependencia operativa y reputacional del titular de la licencia. | Cuando necesitas salir a mercado ya, validar demanda o el acceso a cuentas es accesorio dentro de un producto mayor. |
| Entidad de pago o entidad de pago híbrida | Régimen completo: capital inicial en los importes que fija la normativa, salvaguarda de fondos de clientes y estructura de cumplimiento mucho más pesada. | Cuando además de leer cuentas vas a iniciar pagos, cobrar por cuenta de terceros o mantener fondos de usuarios. |
Analizamos tu producto, los datos que necesitas leer y tu calendario comercial, y te decimos cuál de las tres vías te sale mejor. Si toca registro propio, preparamos el expediente completo ante el Banco de España: programa de actividades, gobierno, seguro, seguridad y protección de datos.
Un AISP es el proveedor autorizado a prestar el servicio de información sobre cuentas: acceder, con el consentimiento del usuario, a los datos de sus cuentas de pago y presentarlos de forma consolidada. No mueve dinero, no ordena pagos y no mantiene fondos de clientes.
Si buscas entender el marco general —qué es el open banking o qué introdujo la PSD2— tenemos páginas dedicadas: open banking y PSD2. Esta página va de otra cosa: del expediente que convierte a tu empresa en AISP registrado.
Ninguno. Es el dato que sorprende a casi todos los proyectos: el régimen de los proveedores de servicios de información sobre cuentas no exige capital inicial. A cambio, sí exige un seguro de responsabilidad civil profesional o una garantía comparable que cubra la responsabilidad frente a los bancos y frente a los usuarios.
Eso no significa que el proyecto sea gratis: hay que sostener estructura, seguridad, cumplimiento y auditoría. Pero el listón de entrada es incomparablemente más bajo que el de una entidad de pago.
En muchos casos sí, y es la primera pregunta que hacemos. Dos vías habituales: prestar el servicio como agente de una entidad autorizada, o construir tu producto sobre un proveedor que ya tiene el registro y aporta el acceso a las cuentas.
Ninguna de las dos te libera de todo: firmas un contrato con obligaciones, dependes de la licencia ajena y tu tratamiento de datos sigue siendo tuyo. Pero permiten validar mercado sin abrir expediente. Conviene revisar también las exclusiones del régimen de servicios de pago antes de asumir que estás dentro.
No damos plazos: el de resolución es el que fija la normativa y lo que decide el calendario real es otra cosa. Un expediente completo, con la documentación de seguridad y de protección de datos hecha de verdad, avanza; uno que llega a medias entra en una rueda de requerimientos que puede durar más que la preparación entera.
Lo que sí podemos anticiparte es qué preguntan y en qué orden. Esa es la parte que reduce el calendario: llegar con las respuestas escritas antes de que se formulen las preguntas.
Solo si vas a ordenar pagos desde la cuenta del usuario. Leer y agregar información es un servicio; iniciar una transferencia es otro, con su propio régimen —ese sí con requisitos de capital y de seguro— que explicamos en servicio de iniciación de pagos.
Muchos proyectos empiezan por el AIS, comprueban que el usuario responde y añaden el PIS después. Si sabes ya que vas a acabar ahí, conviene diseñar el programa de actividades y la estructura pensando en la ampliación, no en un parche posterior.
Hay que verificarlo caso a caso y no darlo por supuesto en ninguna dirección. El catálogo de sujetos obligados está en el artículo 2 de la Ley 10/2010 y su aplicación depende de los servicios que prestes realmente: un proyecto que solo consolida información no está en la misma posición que uno que combina agregación con otros servicios de pago o financieros.
Lo que sí conviene tener claro desde el diseño es el conocimiento del cliente y la trazabilidad de accesos. Lo analizamos contigo junto a nuestro servicio de PBC/FT.
Es la mitad del expediente y donde más proyectos van cortos. El acceso se apoya en un consentimiento explícito y limitado a la finalidad concreta que el usuario ha aceptado: no puedes reutilizar esos datos para otros fines ni conservarlos más allá de lo necesario.
Eso obliga a diseñar minimización, plazos de conservación, control de accesos internos, cifrado, registro de tratamientos y evaluación de impacto cuando proceda. El supervisor de pagos pregunta por ello, y además tienes al regulador de datos detrás: lo trabajamos junto a nuestro servicio de protección de datos.
Entonces tienes una capa más de regulación. La evaluación de solvencia y el credit scoring de personas físicas es un caso de alto riesgo del AI Act (Reglamento (UE) 2024/1689), cuyo grueso de obligaciones para sistemas de alto riesgo se aplica desde agosto de 2026.
Traducido a tu proyecto: gobernanza del modelo, calidad de datos, documentación técnica, supervisión humana y trazabilidad de decisiones. Es perfectamente compatible con un AISP bien montado, pero hay que diseñarlo desde el principio. Lo desarrollamos en AI Act.
Sí. El paquete PSD3/PSR, propuesto por la Comisión en junio de 2023, sigue en tramitación, y el reglamento de open finance (FIDA) está en negociación. Ninguno de los dos elimina el registro: apuntan a reordenar interfaces, responsabilidades y acceso a datos más allá de los pagos.
Quien ya esté registrado llegará con estructura, contratos y controles hechos; quien espere, empezará de cero cuando el mercado ya se haya movido. Seguimos ambos expedientes en PSD3 y FIDA.
Un expediente de AISP es corto comparado con el de una entidad de pago, pero se evalúa con la misma lupa en lo que importa: gobierno, seguridad y datos. Esta es la ruta.
Analizamos qué datos lees, de quién, con qué consentimiento y para qué. De ahí sale si necesitas registro propio, si te conviene ir sobre un tercero o si tu caso encaja en alguna exclusión del régimen de servicios de pago.
Programa de actividades, estructura societaria e idoneidad, seguro de responsabilidad civil profesional, política de seguridad y gestión de riesgos operativos, continuidad, externalización y protección de datos. Todo coherente entre sí.
Certificados y conexión a las interfaces de las entidades, contratos con usuarios y con proveedores, gestión de incidentes, reporting al supervisor y revisión periódica de seguros, políticas y controles.
Si tu modelo también va a mover dinero, mira antes la licencia de entidad de pago o la fórmula de entidad de pago híbrida, porque el diseño societario cambia.
Términos que vas a leer en la solicitud, en los contratos con los bancos y en los requerimientos. Usarlos con precisión evita semanas de malentendidos.
Entidad registrada para acceder, con consentimiento del usuario, a la información de sus cuentas de pago y presentarla de forma consolidada.
Servicio de información sobre cuentas: la actividad regulada que da lugar al registro. Se define por lo que haces, no por la tecnología que uses.
Proveedor de servicios de pago gestor de cuenta: la entidad que debe permitir el acceso a la información cuando el usuario lo autoriza.
Mecanismo por el que el usuario se autentica ante su banco para autorizar el acceso, con los elementos independientes que exige la normativa.
Canal que las entidades ponen a disposición de los proveedores registrados, con sus requisitos de disponibilidad, rendimiento y mecanismos alternativos.
Cobertura —o garantía comparable— que responde frente a las entidades gestoras de cuenta y frente a los usuarios por la actividad del proveedor.
Autorización explícita del usuario, limitada a la finalidad concreta aceptada, revocable y documentada con evidencia de cuándo y cómo se obtuvo.
Inscripción pública que acredita que estás habilitado. Los bancos la consultan antes de darte acceso, y tus clientes también deberían.
El marco europeo permite extender la actividad a otros países de la UE mediante notificación a través de tu supervisor, en los términos que fija la normativa.
Descripción precisa de qué información se lee, de qué cuentas, con qué finalidad y con qué recorrido del usuario, sin ambigüedades sobre el alcance del servicio.
Memoria del servicio con flujos de datos y pantallas, diagramas de arquitectura, condiciones de uso del usuario y descripción de los medios técnicos y humanos.
Sociedad constituida con accionariado transparente y órgano de administración con honorabilidad y capacidad para dirigir una entidad supervisada.
Escritura y estatutos, cuadro de socios y titulares reales, cuestionarios de idoneidad, CV documentados y certificados de antecedentes.
Cobertura o garantía comparable proporcionada al perfil de riesgo, al volumen previsto y a los mercados en los que vas a operar.
Póliza o compromiso en firme del asegurador con alcance y exclusiones, cálculo justificativo del importe y evidencia de renovación periódica.
Gestión documentada de riesgos operativos y de seguridad, control de accesos, cifrado, gestión de incidentes y capacidad de seguir operando ante una caída.
Política de seguridad aprobada, análisis de riesgos, procedimiento de incidentes con canales de comunicación, plan de continuidad y pruebas realizadas.
Tratamiento limitado a la finalidad consentida, con minimización y conservación acotada, y proveedores críticos bajo control contractual efectivo.
Registro de tratamientos, textos de consentimiento y evidencia de su obtención, evaluación de impacto cuando proceda y contratos con proveedores y encargados.
Si te reconoces en alguna, conviene parar y validar el encaje antes de conectar con el primer banco.
Esta página vende una cosa concreta: el expediente de autorización y registro del AISP ante el Banco de España. Si lo que necesitas es entender el marco —qué es el open banking, qué introdujo la PSD2, qué cambiará con PSD3 o hasta dónde llegará el acceso a datos financieros con FIDA—, tienes páginas dedicadas a cada cosa y te van a servir mejor que este texto.
El modelo de acceso a datos y a cuentas que hizo posible esta figura, explicado desde cero y sin jerga de expediente.
La Directiva (UE) 2015/2366 y su traslado en España mediante el RD-ley 19/2018, con sus servicios, sujetos y obligaciones.
El paquete propuesto en junio de 2023 sigue en tramitación: qué se está negociando y qué conviene anticipar en tu diseño.
El acceso a datos de inversión, seguros y pensiones que se negocia ahora mismo, y cómo afecta a quien ya agrega cuentas.
Y si lo que quieres es empezar, el orden importa: compara antes la vía del agente de una entidad de pago con el registro propio, revisa si tu caso encaja en alguna exclusión del régimen de servicios de pago y mira el mapa de licencias fintech para situar tu proyecto.
Última actualización: 4 de agosto de 2026
El proveedor de servicios de información sobre cuentas (AISP) es la figura con la que se accede, previo consentimiento del usuario, a la información de sus cuentas de pago para presentarla de forma consolidada. Su marco es la PSD2 (Directiva (UE) 2015/2366) y, en España, el RD-ley 19/2018, y su registro corresponde al Banco de España. Este texto no explica el open banking —para eso tienes nuestra página de open banking y la de PSD2—: aquí se cuenta cómo se construye el expediente.
El dato que casi nadie conoce y que cambia muchos planes de negocio: el régimen del proveedor de servicios de información sobre cuentas no exige capital inicial. A cambio, exige un seguro de responsabilidad civil profesional o una garantía comparable que responda frente a las entidades gestoras de cuenta y frente a los usuarios por los daños derivados de tu actividad. Esa sola diferencia separa dos mundos: la entidad de pago arranca con capital en los importes que fija la normativa y con la obligación de salvaguardar fondos de clientes, mientras que el AISP puede levantarse con una estructura mucho más ligera porque nunca toca el dinero. Lo que sí comparte con el resto de entidades supervisadas es la exigencia cualitativa: gobierno, gestión de riesgos, seguridad, continuidad y control de proveedores. Ahí no hay régimen aligerado que valga. Por eso el error más frecuente en estos proyectos no es infravalorar el capital —no lo hay—, sino infravalorar el coste de sostener una entidad supervisada: pólizas que se renuevan, políticas que se revisan, incidentes que se comunican y auditorías que se pasan. Nuestro trabajo empieza precisamente ahí, poniendo números y calendario a ese coste antes de que decidas si quieres registro propio o prefieres apoyarte en la licencia de un tercero mientras validas el producto.
Un expediente de AISP es más corto que el de una entidad de pago, pero se lee con la misma exigencia en lo que de verdad importa. El primer bloque es el programa de actividades: qué información vas a leer, de qué cuentas, con qué finalidad, con qué recorrido del usuario y con qué arquitectura técnica. Tiene que ser tan concreto que cualquiera pueda dibujar el flujo de datos leyéndolo. El segundo es la estructura: sociedad, socios, titulares reales y órgano de administración, con la honorabilidad y la capacidad de quienes van a dirigir una entidad supervisada. El tercero, el seguro de responsabilidad civil profesional o la garantía comparable, con un alcance justificado frente a tu volumen y a los mercados donde vas a operar. El cuarto —el que más requerimientos genera— es el paquete de seguridad y riesgos operativos: control de accesos, cifrado, gestión de incidentes, plan de continuidad y pruebas hechas, no prometidas. Y el quinto es el de datos personales y proveedores: consentimiento explícito y granular, minimización, conservación acotada y contratos de externalización con los terceros que sostienen tu conexión. Cinco bloques que deben contar la misma historia: cuando el programa de actividades dice una cosa y la política de seguridad otra, el requerimiento llega solo.
Preferimos perder un encargo a venderte un expediente que no necesitas. Hay al menos tres situaciones en las que un proyecto de agregación puede salir a mercado sin registro propio. La primera: operar como agente de una entidad autorizada, con contrato, alta cuando proceda y el paraguas de su licencia. La segunda: construir tu producto sobre un proveedor ya registrado que aporta el acceso a las cuentas mientras tú aportas la capa de valor; pierdes margen y control de la relación técnica, pero ganas meses. La tercera: comprobar que tu caso encaja en alguna exclusión del régimen de servicios de pago, que existen y a veces resuelven el problema entero. Ninguna de las tres es gratis: sigues respondiendo del tratamiento de datos, del contrato con tu usuario y de tu propia seguridad, y en las dos primeras aceptas además condiciones económicas y operativas que no controlas —tarifa por consulta, cobertura de bancos, calidad del servicio y prioridad frente a otros clientes del proveedor—. Y ninguna es para siempre: cuando la agregación pasa a ser el núcleo del negocio, depender de la licencia de otro se convierte en un riesgo estratégico —cambios de precio, de condiciones o de dueño— y el registro propio deja de ser un coste para ser un activo. Esa transición conviene planificarla, no improvisarla.
El marco se está moviendo en dos frentes. El paquete PSD3/PSR, propuesto por la Comisión en junio de 2023, sigue en tramitación y apunta a reordenar el acceso a cuentas, las interfaces y el reparto de responsabilidades entre bancos y proveedores. Y el reglamento de acceso a datos financieros —FIDA, propuesto en junio de 2023 y también en negociación— quiere llevar el modelo más allá de los pagos, hacia inversión, seguros y pensiones, mediante proveedores autorizados y esquemas de compartición de datos. Ninguno de los dos elimina la figura ni el registro; ambos elevan el listón de gobierno, seguridad y contratos. La conclusión práctica es la contraria a la intuitiva: quien se registra ahora llega a ese escenario con entidad constituida, controles rodados y relación con el supervisor, y adaptarse le costará una revisión; quien espera empezará de cero cuando el mercado ya se haya repartido. A eso se suma el resto del perímetro que un proyecto de datos financieros arrastra —protección de datos, resiliencia operativa y, si decides con modelos automáticos, el AI Act—. Ordenarlo desde el diseño cuesta una fracción de lo que cuesta reconstruirlo después, cuando ya tienes usuarios, contratos firmados con entidades gestoras de cuenta y un supervisor que te pregunta por escrito. Nuestra recomendación, cuando el negocio ya está validado, es no esperar a la norma perfecta: registrarse con el marco vigente y dejar el expediente preparado para absorber lo que llegue.
Este contenido tiene carácter divulgativo y no constituye asesoramiento jurídico. La normativa citada puede haber sido modificada con posterioridad a la fecha de actualización indicada: verifica siempre la versión vigente o consúltanos para analizar tu caso concreto.