Por Luis Vilanova Blanco, auditor jefe de Legal & Digital Auditors
Llevo bastantes años auditando software para fabricantes y empresas tecnológicas. He participado en proyectos relacionados con la AEAT, VERI*FACTU, firma electrónica, protección de datos, seguridad de la información y diferentes procesos de homologación.
Sin embargo, hay un ámbito que no suele aparecer en las conversaciones habituales con los fabricantes de ERP: la supervisión del Banco de España.
Hasta que aparece.
Actualmente estamos trabajando con un fabricante español de software ERP que necesita regularizar una funcionalidad que, desde el punto de vista tecnológico, parece bastante habitual: conectarse a las cuentas bancarias de sus clientes, obtener los movimientos y saldos y utilizarlos para automatizar la conciliación contable.
Una funcionalidad que aporta un valor evidente a cualquier departamento financiero.
El problema aparece cuando analizamos quién accede realmente a esas cuentas, cómo lo hace y qué responsabilidades asume frente a sus clientes.
Porque lo que para un fabricante es una integración bancaria, para el regulador puede constituir un servicio de información sobre cuentas sujeto a la normativa de servicios de pago.
Y ahí empieza nuestro trabajo.
1. Cuando un ERP deja de ser solamente un ERP
El caso que estamos auditando corresponde a una empresa que desarrolla y comercializa un ERP para pymes.
Su módulo financiero permite que los clientes conecten sus cuentas bancarias y consulten desde el propio programa los movimientos, los saldos y la información necesaria para realizar conciliaciones automáticas.
Hasta aquí, nada especialmente novedoso.
Muchos fabricantes ofrecen funcionalidades parecidas, bien mediante desarrollos propios o utilizando plataformas externas de agregación bancaria.
La cuestión que planteamos durante las primeras reuniones fue bastante sencilla:
¿Quién está prestando realmente el servicio de acceso a la información bancaria?
No es una pregunta menor.
El Real Decreto-ley 19/2018 regula los servicios de pago y contempla expresamente el servicio de información sobre cuentas.
En particular, su artículo 3.38 define este servicio y el artículo 1.2.h lo incluye entre los servicios de pago regulados.
Por tanto, cuando una empresa accede profesionalmente a información de cuentas de pago de terceros y presta un servicio que encaja en esa definición, debemos analizar si necesita estar registrada como proveedor de servicios de información sobre cuentas, conocido como AISP (Account Information Service Provider).
En nuestra primera revisión comprobamos cuatro cuestiones:
- El ERP accedía a cuentas bancarias mantenidas por otras entidades.
- El acceso se realizaba en línea y con consentimiento de los usuarios.
- La funcionalidad formaba parte del servicio comercializado por el fabricante.
- La actividad se desarrollaba desde España.
Los cuatro elementos estaban presentes.
Eso nos llevó a analizar el encaje del fabricante en la figura del AISP y los requisitos para su inscripción en el Registro Especial del Banco de España.
También revisamos el papel del agregador bancario utilizado por el ERP.
Este punto merece especial atención porque contratar a un proveedor tecnológico que ya está registrado no significa necesariamente que todas las empresas que utilizan sus servicios necesiten registrarse. Tampoco significa lo contrario.
Hay que estudiar el modelo contractual, quién presta el servicio al usuario, quién asume las responsabilidades regulatorias y cómo se produce realmente el acceso a los datos.
No basta con revisar la documentación comercial del proveedor.
Hay que entender la arquitectura del producto y comprobar su funcionamiento.
2. El Banco de España no certifica el software
Conviene aclarar algo que genera bastante confusión.
En el mercado se habla con frecuencia de certificación PSD2 o certificación AISP por el Banco de España.
Sin embargo, técnicamente debemos distinguir entre una certificación privada de cumplimiento y la inscripción administrativa de una entidad.
El Banco de España no certifica un ERP ni emite un sello de conformidad sobre su código fuente.
Lo que hace es examinar si la entidad solicitante cumple los requisitos exigidos para desarrollar la actividad regulada y, cuando procede, practicar su inscripción.
El marco principal se encuentra en el Real Decreto-ley 19/2018 y en el Real Decreto 736/2019, junto con la normativa europea aplicable.
Para los proveedores que únicamente prestan servicios de información sobre cuentas existe un régimen específico de registro, diferente del procedimiento ordinario de autorización de una entidad de pago.
Esto no significa que sea un trámite sencillo.
El fabricante debe demostrar que dispone de una organización adecuada, procedimientos de control, medidas de seguridad, gestión de riesgos, cobertura de responsabilidad civil y capacidad para prestar el servicio de forma segura.
Nuestra función como auditores consiste en revisar esos requisitos, identificar las deficiencias y ayudar a preparar un expediente respaldado por evidencias.
Y quiero insistir en la palabra evidencias.
Porque una política de seguridad bien redactada no demuestra, por sí sola, que el software sea seguro.
3. La documentación es importante, pero el software debe demostrar lo que dice
En este proyecto nos hemos encontrado con una situación bastante habitual.
El fabricante tenía un producto tecnológicamente avanzado, con buenas funcionalidades y una integración bancaria que respondía a las necesidades de sus clientes.
Sin embargo, cuando empezamos a solicitar evidencias de cumplimiento, aparecieron las primeras dificultades.
No porque el fabricante hubiera actuado necesariamente de forma negligente, sino porque había desarrollado el producto pensando principalmente en su funcionamiento y en la experiencia del usuario.
Y el cumplimiento normativo exige analizar otras cuestiones.
Una de ellas era el consentimiento.
El sistema disponía de mecanismos para que el cliente autorizara la conexión bancaria, pero tuvimos que revisar si el consentimiento cumplía realmente las exigencias aplicables al servicio de información sobre cuentas.
El artículo 39 del Real Decreto-ley 19/2018 exige que el servicio se preste sobre la base del consentimiento explícito del usuario y que el acceso se limite a la información de las cuentas designadas.
Esto nos obligó a revisar cómo se obtenía el consentimiento, qué información recibía el usuario, cómo quedaba registrada la autorización y qué sucedía cuando decidía revocarla.
También examinamos la trazabilidad de las operaciones y la conservación de los datos.
No es suficiente con incorporar una casilla de aceptación en la pantalla.
Hay que poder demostrar qué autorizó el usuario y cómo se respeta esa autorización durante todo el ciclo de vida del servicio.
4. El acceso a las cuentas bancarias y los certificados eIDAS
Otro de los puntos importantes de nuestra auditoría fue la arquitectura de conexión con las entidades financieras.
Durante la revisión detectamos un mecanismo antiguo de acceso basado en credenciales del usuario que debía ser sustituido.
La normativa técnica europea de PSD2 establece requisitos específicos para la identificación de los proveedores de servicios de pago y la comunicación segura con las entidades que mantienen las cuentas.
En particular, el Reglamento Delegado (UE) 2018/389 contempla la identificación mediante certificados cualificados conforme a eIDAS.
En un servicio AISP debemos comprobar, entre otras cuestiones, cómo se identifica el proveedor, qué certificados utiliza, cómo protege sus claves y cómo gestiona las comunicaciones con las interfaces bancarias.
Desde mi experiencia como auditor de sistemas y de servicios de confianza, este punto es especialmente relevante.
No estamos hablando simplemente de utilizar HTTPS.
Estamos hablando de una arquitectura en la que intervienen identidades reguladas, certificados cualificados, permisos de acceso y responsabilidades frente a terceros.
Por eso revisamos tanto la documentación técnica como la implementación real.
5. El seguro de responsabilidad civil: otro requisito que suele olvidarse
Una de las primeras preguntas que hicimos al fabricante fue si disponía de una póliza de responsabilidad civil adaptada a su actividad como proveedor de información sobre cuentas.
La respuesta fue que tenía contratado un seguro de responsabilidad civil para su actividad tecnológica.
Pero eso no resuelve necesariamente la cuestión.
El artículo 16.2 del Real Decreto-ley 19/2018 exige a estos proveedores disponer de un seguro de responsabilidad civil profesional o una garantía comparable.
Su importe debe determinarse conforme a los criterios regulatorios aplicables, entre ellos las directrices de la Autoridad Bancaria Europea.
No existe una cifra única válida para todos los fabricantes.
Hay que analizar el perfil de riesgo, el volumen previsto de actividad, las características del servicio y las coberturas exigidas.
También debemos comprobar las exclusiones, franquicias y límites de la póliza.
En nuestro caso, esta revisión forma parte del expediente que estamos preparando.
Es un ejemplo de por qué el registro AISP no puede tratarse únicamente como un proyecto de desarrollo de software.
Hay obligaciones que afectan directamente a la estructura y gestión de la empresa.
6. DORA también forma parte de la conversación
Otra cuestión que estamos abordando es la aplicación del Reglamento (UE) 2022/2554, conocido como DORA.
Desde el 17 de enero de 2025, este reglamento establece obligaciones de resiliencia operativa digital para las entidades financieras comprendidas en su ámbito de aplicación, incluidos los proveedores de servicios de información sobre cuentas.
Esto tiene consecuencias importantes para un fabricante que pretende registrarse como AISP.
Debemos revisar su gestión del riesgo TIC, los procedimientos de respuesta ante incidentes, la continuidad de negocio, la gestión de proveedores tecnológicos y las obligaciones de información que resulten aplicables.
Ahora bien, también hay que ser razonables.
No podemos exigir a una pequeña empresa de software la misma estructura organizativa que a una gran entidad bancaria.
DORA incorpora el principio de proporcionalidad y contempla determinadas particularidades para las microempresas.
Nuestro trabajo consiste precisamente en determinar qué obligaciones corresponden a la entidad y cómo puede cumplirlas de una forma proporcionada y verificable.
No se trata de generar cientos de documentos que después nadie utiliza.
Se trata de establecer controles que funcionen.
7. Cómo estamos preparando el expediente para el Banco de España
En Legal & Digital Auditors estamos abordando este proyecto mediante una metodología de auditoría y adecuación organizada en seis fases.
Comenzamos analizando el modelo de negocio y determinando el encaje regulatorio de la actividad.
A continuación realizamos un análisis de brechas utilizando nuestro catálogo de aproximadamente ochenta controles, agrupados en once dominios de revisión.
Este análisis nos permite identificar qué requisitos están cubiertos, cuáles necesitan mejoras y qué evidencias debemos obtener.
Después trabajamos con el fabricante en la preparación del expediente, utilizando los formularios y procedimientos establecidos por el Banco de España.
Entre la documentación que revisamos se encuentran el programa de actividades, el plan de negocio, la estructura organizativa, los mecanismos de control interno, la política de seguridad, la gestión de incidentes, la continuidad de negocio y los requisitos relativos a los administradores y a la cobertura de responsabilidad civil.
Una parte especialmente interesante del proyecto está siendo la adaptación del propio ERP.
Hemos trabajado sobre los mecanismos de consentimiento, la revocación de autorizaciones, la seguridad de las conexiones y la protección de la información obtenida de las entidades financieras.
También estamos revisando los límites de acceso y los mecanismos de autenticación previstos en la normativa técnica.
Por ejemplo, las modificaciones introducidas por el Reglamento Delegado (UE) 2022/2360 establecieron reglas específicas para determinados accesos a información de cuentas mediante proveedores AISP, incluida la renovación periódica de la autenticación reforzada.
Estas cuestiones deben trasladarse al diseño del producto.
Lo que figure en el expediente debe corresponderse con lo que realmente hace el software.
Este es uno de los criterios que considero fundamentales en cualquier auditoría.
8. La presolicitud y la relación con el supervisor
El Banco de España contempla una fase de presolicitud que considero especialmente útil para las entidades que se enfrentan por primera vez a este procedimiento.
Permite presentar el proyecto y mantener un contacto preliminar con el supervisor antes de formalizar el expediente.
En esta fase resulta importante que el fabricante pueda explicar con claridad su modelo de negocio, su organización y el funcionamiento del servicio.
Una demostración práctica del producto puede ayudar a comprender cómo se accede a las cuentas, cómo interviene el usuario y qué información se obtiene.
Después llegará la solicitud formal, la revisión de la documentación y, en su caso, los requerimientos de información adicional.
La normativa contempla un plazo de resolución vinculado a la presentación de un expediente completo, por lo que la calidad de la documentación resulta especialmente importante.
Por experiencia, sé que uno de los problemas más frecuentes en estos procedimientos no es necesariamente la existencia de grandes incumplimientos técnicos.
Muchas veces el problema es que la entidad no sabe demostrar de manera ordenada lo que ya está haciendo.
Y otras veces, al intentar documentarlo, descubrimos que determinados controles no estaban realmente implantados.
Para eso sirve una auditoría previa.
9. Una inscripción que implica obligaciones posteriores
Hay otra cuestión que hemos explicado al fabricante desde el inicio.
Conseguir la inscripción no significa que desaparezcan las obligaciones.
La entidad deberá mantener las condiciones que justificaron su registro y cumplir las obligaciones regulatorias que correspondan a su actividad.
Eso implica revisar periódicamente sus controles de seguridad, mantener actualizada la documentación, gestionar los riesgos tecnológicos y atender las comunicaciones exigibles al supervisor.
También deberá revisar la adecuación de su cobertura de responsabilidad civil y mantener sus procedimientos de gestión de incidentes y continuidad.
Por ese motivo, nuestro planteamiento incluye una revisión periódica de cumplimiento.
Considero que es la manera adecuada de abordar este tipo de proyectos.
No tiene demasiado sentido preparar un expediente excelente para después dejar de comprobar si el producto continúa cumpliendo las condiciones declaradas.
10. PSD3 y el futuro de los servicios de información bancaria
Estamos además en un momento de evolución normativa.
El marco europeo de servicios de pago está avanzando hacia PSD3 y el futuro Reglamento de Servicios de Pago, conocido como PSR.
Las reformas previstas afectan, entre otras materias, a los mecanismos de acceso a cuentas, la gestión de permisos, la prevención del fraude y las obligaciones de los distintos proveedores.
Aunque hay que distinguir cuidadosamente entre las normas ya aplicables y las que todavía están pendientes de entrada en vigor, resulta conveniente tener en cuenta esa evolución al diseñar un servicio nuevo.
No recomendaría a un fabricante realizar una inversión importante para adaptar su ERP sin considerar cómo pueden cambiar las exigencias regulatorias durante los próximos años.
En nuestra auditoría estamos procurando que las decisiones técnicas sean compatibles con el marco vigente y, en la medida de lo posible, faciliten futuras adaptaciones.
11. Mi reflexión como auditor jefe
Después de muchos años auditando fabricantes de software, sigo encontrándome con una situación que se repite.
Las empresas desarrollan nuevas funcionalidades porque sus clientes las necesitan. Es lógico. El mercado exige integrar servicios, automatizar procesos y reducir tareas administrativas.
Pero no siempre se analiza a tiempo si esas funcionalidades introducen a la empresa en una actividad regulada.
Lo hemos visto con la firma electrónica, la facturación, la digitalización certificada y ahora con los servicios de información bancaria.
Un fabricante puede empezar ofreciendo una sencilla conexión con los bancos y terminar prestando un servicio sometido a supervisión financiera.
Por eso considero tan importante que el análisis regulatorio forme parte del diseño del producto y no aparezca cuando la solución ya está comercializada.
En el proyecto que estamos llevando actualmente, la auditoría no se está limitando a preparar documentación para el Banco de España.
Está sirviendo para revisar procesos, mejorar controles y modificar determinadas funcionalidades del ERP.
Y eso, desde mi punto de vista, es lo que aporta valor al fabricante.
No debemos confundir nuestro trabajo con las competencias del supervisor.
La inscripción como AISP corresponde exclusivamente al Banco de España. Nosotros no podemos garantizar su concesión ni sustituir su evaluación.
Lo que sí podemos hacer es revisar técnicamente el producto, comprobar su grado de cumplimiento, documentar las evidencias y preparar un expediente que permita al supervisor evaluar la actividad con toda la información necesaria.
Como auditor CISA y perito judicial informático, siempre he defendido que un informe debe poder sostenerse sobre hechos comprobables.
No sobre declaraciones comerciales, ni sobre documentos preparados únicamente para superar una revisión.
En este caso, el objetivo es el mismo.
Que el fabricante pueda demostrar qué hace su ERP, cómo accede a los datos bancarios, qué medidas de seguridad aplica y cómo cumple las obligaciones que le corresponden.
Porque, al final, una buena auditoría no consiste en acumular documentación.
Consiste en comprobar que lo que una empresa afirma que hace es exactamente lo que sucede cuando su software funciona.
Y si además ese trabajo permite al fabricante mejorar su producto y acceder a nuevas oportunidades comerciales, habremos conseguido algo más que preparar un expediente administrativo.
Luis Vilanova Blanco
Auditor jefe de Legal & Digital Auditors
Auditor CISA (ISACA) · Perito judicial informático
Colegiado nº 498 del COIICV
Auditor líder ISO/IEC 27001 e ISO/IEC 42001
