Soluciones de Pago
Research Papers
RESEARCH PAPER 18
Open Finance en España
Datos financieros compartidos, control del cliente y nuevos servicios para empresas.
Serie: Biblioteca de Investigación de Soluciones de Pago.
Ámbito: España, con contexto europeo e internacional.
Edición: septiembre de 2026. Revisión documental: 24 de septiembre de 2026.
Enfoque: investigación documental y análisis operativo; los escenarios empresariales son hipotéticos.
1. Resumen ejecutivo, alcance y método
1.1. La pregunta que orienta esta investigación
Open Finance plantea una pregunta empresarial concreta: ¿qué decisiones podrían mejorar si una persona o una empresa compartiera determinados datos financieros con un proveedor elegido, durante un periodo definido y para un servicio comprensible? La respuesta no consiste en reunir toda la información disponible. Consiste en identificar qué dato adicional cambia una decisión, qué permiso permite acceder a él y qué responsabilidad asume cada participante cuando la información resulta incompleta, se utiliza incorrectamente o deja de estar autorizada.
Este documento estudia esa pregunta desde la perspectiva de las empresas que operan en España. Su tesis es que el valor de las finanzas abiertas depende de combinar utilidad, control y continuidad. Una conexión técnicamente correcta puede aportar poco valor si el usuario no entiende el resultado. Una propuesta comercial atractiva puede fracasar si exige demasiada información. Una experiencia sencilla puede resultar frágil si nadie sabe resolver discrepancias entre entidades. El análisis conecta estas dimensiones mediante criterios de diseño y evaluación que pueden aplicarse antes de contratar una solución.
1.2. Qué entendemos por Open Finance
En este paper, Open Finance designa el intercambio autorizado de información financiera entre organizaciones para prestar servicios definidos, con un alcance conceptual más amplio que las cuentas de pago. Puede incluir información sobre financiación, ahorro, inversiones u otros productos, dependiendo de las reglas y acuerdos aplicables. Esta definición operativa no implica que todos esos datos sean accesibles hoy en España mediante una interfaz común ni que cualquier empresa tenga derecho a solicitarlos. La disponibilidad debe comprobarse para cada producto, proveedor y finalidad.
La Comisión Europea presenta su propuesta de acceso a datos financieros como una ampliación más allá de las cuentas de pago, orientada al control del cliente, la competencia y la seguridad. Ese planteamiento institucional ayuda a delimitar el tema. Nuestro análisis posterior es propio: examina cómo una empresa podría convertir una conexión autorizada en un proceso útil, medible y reversible, sin atribuir a la propuesta resultados comerciales que todavía deban demostrarse.
1.3. Diferencias que evitan decisiones equivocadas
Open Banking y Open Finance guardan relación, pero no son etiquetas intercambiables. En la discusión europea, el primero se vincula especialmente al acceso a información de cuentas de pago y a servicios regulados asociados. El segundo amplía la conversación hacia otros datos financieros. Tampoco debe confundirse acceso a información con capacidad para ordenar una transferencia. Una pantalla que reúne saldos puede carecer de cualquier función de movimiento de fondos. La empresa debe separar esos permisos desde la contratación y reflejarlos de forma visible en la experiencia del usuario.
Las finanzas integradas describen otra dimensión: el lugar donde aparece un servicio financiero dentro de una experiencia comercial. Una plataforma puede integrar financiación sin operar un ecosistema amplio de datos abiertos. A su vez, una herramienta de Open Finance puede funcionar fuera de una compra. La inteligencia artificial representa una técnica de análisis posible, no un requisito definitorio. Estas distinciones permiten evaluar productos concretos sin asumir que una denominación de mercado garantiza todas las capacidades sugeridas por su nombre.
1.4. Método y límites de la evidencia
La investigación combina ocho fuentes primarias institucionales con razonamiento operativo original. Se han consultado documentos europeos para el contexto legislativo, publicaciones del Banco de Pagos Internacionales para experiencias y arquitectura, y orientaciones de protección de datos para delimitar responsabilidades. No se ha realizado una encuesta representativa de empresas españolas, una prueba de proveedores ni una estimación econométrica del mercado. Por ello no se presentan porcentajes de adopción, ahorros medios o probabilidades de aprobación crediticia como resultados propios.
Los ejemplos se construyen para mostrar decisiones y puntos de control. Sus importes, plazos y umbrales, cuando aparecen, son supuestos didácticos. No describen la oferta de una entidad ni predicen un resultado. Las recomendaciones se expresan como propuestas de gestión que necesitan adaptación al tamaño, actividad y recursos de cada organización. Una conclusión válida para una empresa con varios sistemas financieros puede resultar innecesariamente compleja para un pequeño comercio con una sola cuenta y procesos estables.
1.5. Una hipótesis de valor verificable
La hipótesis principal es que compartir datos aporta valor cuando reduce una incertidumbre relevante con un coste y un riesgo proporcionados. Un ejemplo sería conocer mejor los vencimientos de obligaciones para preparar una previsión de tesorería. El beneficio no es el número de conexiones creadas, sino la mejora de una tarea: menos tiempo reconstruyendo información, menos errores al interpretar compromisos o mayor capacidad para explicar una necesidad de financiación. Si esa mejora no puede observarse, añadir conexiones amplía la complejidad sin demostrar utilidad.
Esta hipótesis obliga a establecer una situación inicial. Antes del proyecto conviene describir cómo se realiza la tarea, cuánto esfuerzo requiere y qué errores aparecen. Después se evalúa el mismo proceso con criterios comparables. Un resultado favorable exige mirar también el esfuerzo del cliente, las incidencias y la dependencia del proveedor. Ahorrar minutos al equipo financiero mientras se obliga a los usuarios a renovar permisos constantemente puede trasladar trabajo en lugar de eliminarlo. El balance debe considerar a todos los participantes afectados.
1.6. El contexto legislativo se trata con precisión
En la consulta realizada para esta edición, el expediente 2023/0205(COD) del Parlamento Europeo figura a la espera de la posición del Parlamento en primera lectura. Por tanto, este paper trata FiDA como un expediente legislativo en tramitación y no como una obligación general ya aplicable. No fija una fecha de implantación ni presupone que un texto negociador sea la redacción definitiva. Las decisiones de cumplimiento deben comprobarse de nuevo cuando se adopten.
Esta cautela no impide preparar procesos. Una empresa puede ordenar su inventario de datos, revisar contratos, mejorar la calidad de sus registros y ensayar experiencias de permisos sin afirmar que una futura norma le concede derechos presentes. La preparación más útil es aquella que mantiene valor aunque cambie el calendario legislativo. Documentar finalidades y responsabilidades tiene utilidad operativa inmediata; construir una inversión irreversible sobre una fecha no confirmada introduce un riesgo adicional que debe aparecer explícitamente en el presupuesto.
1.7. Cómo utilizar el documento
Los capítulos siguientes avanzan desde el modelo institucional hacia el funcionamiento cotidiano. Primero se distinguen actores y responsabilidades. Después se examinan casos de uso, permisos, arquitectura, seguridad y economía del proyecto. El último capítulo propone una secuencia de implantación y reúne las referencias. La lectura completa ofrece un marco de decisión; cada capítulo también puede servir como agenda para una reunión entre negocio, operaciones, tecnología y las personas responsables de protección de datos.
Dentro de la biblioteca del sitio, esta investigación complementa el Framework de Pagos Digitales y el Framework de Operaciones de Pago. La conexión entre documentos reside en la disciplina de implementación: definir el problema, asignar responsables, comprobar evidencia y mantener capacidad de corrección. Open Finance añade nuevas fuentes de información a esa disciplina, pero no sustituye la necesidad de procesos claros ni convierte automáticamente los datos en decisiones acertadas.
2. Ecosistema, responsabilidades y evolución europea
2.1. El cliente como participante efectivo
Un ecosistema de datos financieros comienza con una persona o una empresa que necesita resolver una tarea. Ese cliente no debería quedar reducido a un botón de aceptación. Debe poder identificar el servicio, comprender qué información necesita, reconocer a las entidades participantes y encontrar una vía de ayuda. Desde la perspectiva del diseño, el control es efectivo cuando puede ejercerse durante todo el servicio: al comenzar, al modificar una conexión, al corregir un error y al terminar la relación.
En una empresa, además, quien utiliza la herramienta puede no ser quien tiene autoridad para permitir el acceso. Una persona del departamento contable quizá pueda consultar una cuenta, mientras que otra representa legalmente a la sociedad. El proyecto necesita distinguir usuario, representante y administrador interno. Esta distinción evita convertir una capacidad práctica de navegación en una autorización empresarial. El inventario inicial debería identificar quién solicita el servicio, quién puede aprobarlo y quién debe recibir avisos cuando cambian los accesos.
2.2. Titulares de datos y proveedores de servicios
La organización que mantiene un registro financiero y la que utiliza información para prestar un servicio ocupan posiciones distintas. En términos operativos, la primera debe comunicar qué representa cada campo, cómo se actualiza y qué limitaciones tiene. La segunda debe explicar qué hace con los datos recibidos y cómo transforma esa información en resultados. Una misma entidad puede desempeñar varias funciones, pero el cliente necesita distinguirlas para saber a quién reclamar cuando un dato de origen y una interpretación posterior no coinciden.
Consideremos una fecha de vencimiento mostrada incorrectamente en una aplicación. Puede existir un error en el registro original, una conversión de formato defectuosa o una regla equivocada de presentación. Un acuerdo que únicamente prometa disponibilidad no resuelve esa incertidumbre. La empresa contratante debería pedir un recorrido de investigación: quién consulta el origen, quién revisa la transformación y quién informa al cliente. La responsabilidad operativa puede organizarse antes de conocer la causa, mediante un interlocutor que coordine la resolución sin trasladar al usuario entre proveedores.
2.3. Intermediarios y dependencias invisibles
Entre el origen del dato y la aplicación pueden existir agregadores, proveedores de identidad, servicios de alojamiento y herramientas de seguimiento. No todos necesitan acceder al contenido financiero. El mapa del servicio debería mostrar qué participante transporta información, cuál la almacena y cuál puede interpretarla. Dibujar estas funciones ayuda a detectar accesos innecesarios y dependencias comunes. Dos aplicaciones aparentemente alternativas pueden apoyarse en el mismo intermediario, por lo que contratarlas simultáneamente no siempre aporta la continuidad esperada.
La evaluación de proveedores debe incorporar esta cadena de forma comprensible. No basta con recibir una lista extensa de empresas sin relación con el flujo real. Resulta más útil un esquema que conecte cada dependencia con un servicio concreto y con una consecuencia de fallo. Si el proveedor de autenticación deja de funcionar, quizá no puedan crearse conexiones nuevas; si falla el almacenamiento de resultados, tal vez tampoco puedan consultarse informes anteriores. Son impactos diferentes y requieren respuestas diferentes.
2.4. Qué aporta el debate sobre FiDA
El Consejo de la Unión Europea acordó su posición negociadora el 4 de diciembre de 2024. Su comunicación abordaba alcance, implantación gradual, control del cliente y mecanismos de intercambio. También aclaraba que todavía eran necesarias negociaciones y adopción formal. Es una referencia sobre la posición de esa institución en aquella fecha, no una prueba de que todos sus elementos se hayan convertido en obligaciones vigentes o de que coincidan con el resultado final.
Para una empresa, el debate muestra qué preguntas conviene preparar: qué conjuntos de datos estarán incluidos, qué participantes podrán utilizarlos, cómo se distribuirán costes y cómo se resolverán conflictos. Este paper no utiliza respuestas provisionales como requisitos definitivos de contratación. Propone separar una capa estable de buenas prácticas operativas de otra capa adaptable al marco que finalmente resulte aplicable. Esa separación reduce el coste de actualización y evita presentar una interpretación comercial del proveedor como si fuera una conclusión legislativa.
2.5. La diferencia entre preparación y cumplimiento
Prepararse significa desarrollar capacidades útiles: registrar permisos, conocer dependencias, probar revocaciones y documentar decisiones. Cumplir exige identificar normas concretas, sujetos obligados, fechas y condiciones aplicables. Una organización puede estar bien preparada para un intercambio futuro sin estar autorizada a realizarlo hoy. También puede cumplir requisitos formales y ofrecer una experiencia pobre. Mantener estas dimensiones separadas permite asignar responsables adecuados y evita que una presentación técnica sustituya la revisión jurídica que necesita un servicio concreto.
El registro de supuestos es una herramienta sencilla para gestionar esta diferencia. Cada decisión relevante puede indicar su fundamento, el documento consultado, la fecha de revisión y el acontecimiento que obligaría a reconsiderarla. Si una integración depende de un acuerdo bilateral, debe constar como tal. Si una funcionalidad depende de una norma futura, debe aparecer como condicionada. El registro no necesita convertirse en una enciclopedia: su utilidad consiste en impedir que una hipótesis pierda su etiqueta y termine tratándose como certeza.
2.6. Competencia, especialización y concentración
La apertura de datos puede facilitar que una herramienta especializada compita mediante una mejor experiencia o un análisis más útil. Sin embargo, el acceso por sí solo no garantiza competencia. Las empresas con mayor capacidad comercial pueden atraer clientes con más facilidad, y un intermediario ampliamente utilizado puede convertirse en una dependencia difícil de sustituir. El diseño del proyecto debe examinar tanto la posibilidad de conectar como la posibilidad de cambiar de proveedor sin perder contexto, permisos documentados o capacidad de continuar operaciones.
El BIS Paper 168, publicado en marzo de 2026, analiza experiencias internacionales y destaca el papel de la interoperabilidad y de marcos sólidos para desarrollar las finanzas abiertas. Sus autores examinan oportunidades y dificultades; ello no equivale a una estimación del efecto en España. Como inferencia operativa propia, proponemos que la contratación valore la portabilidad práctica y los costes de salida junto con las funcionalidades iniciales. La facilidad de entrada pierde valor si la salida exige reconstruir todo el servicio.
2.7. Una matriz de responsabilidades utilizable
Antes de un piloto conviene acordar quién decide, quién ejecuta y quién verifica cada actividad. No es necesario que todas las funciones pertenezcan a equipos distintos, pero sí que exista una persona responsable. Una pequeña empresa puede combinar tareas y apoyarse en asesoramiento externo. Lo que no debería desaparecer es la trazabilidad de decisiones: quién aprobó una nueva finalidad, quién confirmó que un conjunto de datos era suficiente y quién autorizó pasar de una prueba a un proceso habitual.
| Actividad | Responsable propuesto | Evidencia esperada |
|---|---|---|
| Definir utilidad | Negocio y operaciones | Tarea, problema y resultado observable |
| Validar acceso | Responsable jurídico y de privacidad | Finalidad, legitimación y condiciones |
| Comprobar información | Equipo financiero | Reglas de calidad y excepciones |
| Gestionar conexión | Tecnología y proveedor | Pruebas, monitorización y recuperación |
| Resolver reclamaciones | Atención designada | Seguimiento hasta cierre explicado |
Esta matriz es una propuesta organizativa, no una asignación legal universal. Debe adaptarse al contrato y a la actividad. Su prueba más útil consiste en simular una incidencia y comprobar que cada participante sabe qué debe hacer. Si la simulación termina con una discusión sobre quién es responsable, el proyecto todavía tiene trabajo pendiente aunque todas las conexiones técnicas funcionen correctamente.
3. Casos de uso y decisiones empresariales
3.1. Previsión de tesorería con información contextual
Una previsión de tesorería necesita distinguir dinero disponible, cobros esperados y obligaciones futuras. Reunir saldos mejora la visibilidad, pero no explica por sí solo cuándo vencerá una cuota, si existe una condición contractual relevante o si una obligación ya se ha pagado desde otra cuenta. Un caso de Open Finance podría combinar información autorizada de diferentes productos para ofrecer una visión más contextual. Su valor se mediría en la capacidad de preparar decisiones, no en la apariencia de un panel que muestra muchas cifras.
Imaginemos una empresa de servicios con ingresos estacionales y varias obligaciones de financiación. El piloto podría centrarse únicamente en construir un calendario de vencimientos verificable. Cada fecha debería mostrar su origen y su última actualización. Las estimaciones se separarían de los compromisos contractuales. Antes de utilizar el calendario para decidir, el equipo compararía una muestra con sus documentos. Si aparecen discrepancias, el sistema debería señalarlas y permitir revisión. Un total agregado sin esas distinciones puede aumentar la confianza justo cuando debería invitar a comprobar.
3.2. Preparación de documentación para financiación
Compartir información estructurada puede reducir el trabajo de recopilar documentos para una solicitud, siempre que el receptor acepte esos datos y la empresa tenga autoridad para transmitirlos. La mejora posible reside en evitar transcripciones, ordenar periodos y explicar la procedencia. No garantiza una aprobación, una oferta más barata ni una evaluación favorable. El proveedor de financiación conserva sus criterios y debe valorar la operación dentro de las condiciones que le resulten aplicables. El servicio de datos debe comunicar ese límite antes de pedir accesos.
Un ejemplo de evaluación sería comparar dos recorridos para preparar el mismo expediente: uno basado en documentos aportados manualmente y otro apoyado en conexiones autorizadas. Se registrarían tiempo empleado, solicitudes de aclaración y errores de conciliación. También se comprobaría si el cliente puede corregir información y aportar contexto sobre hechos excepcionales. Una caída temporal de ingresos no debería convertirse automáticamente en una conclusión sin explicación. La herramienta aporta evidencia organizada; la interpretación y la decisión requieren un proceso identificado y revisable.
3.3. Comparación de productos con criterios transparentes
Una aplicación podría ayudar a comparar características de productos financieros que el cliente ya mantiene o que considera contratar. Para que la comparación sea útil, necesita una unidad de análisis coherente. No es suficiente colocar una comisión junto a otra si corresponden a servicios, periodos o condiciones distintos. La información importada debe conservar el significado de cada coste, la fecha de vigencia y las exclusiones conocidas. Cuando falte una condición relevante, la comparación debería mostrar esa carencia en lugar de producir una clasificación aparentemente completa.
El modelo comercial del comparador también importa. Si recibe remuneración por determinados resultados, la empresa usuaria necesita entender cómo afecta esa relación a la selección y al orden de presentación. Como propuesta de diseño, recomendamos separar coincidencia con necesidades, disponibilidad de información y relación comercial. Un producto puede aparecer primero por una razón patrocinada sin ser la opción que mejor encaja en todos los criterios. La transparencia exige explicar la lógica utilizada y permitir que el cliente revise sus propias prioridades.
3.4. Control de obligaciones y alertas
El seguimiento de compromisos puede ser un caso de uso acotado: avisar de un vencimiento próximo, de una información desactualizada o de una diferencia respecto a un calendario interno. La alerta útil identifica una acción posible y un responsable. Un mensaje que únicamente anuncia un cambio genera trabajo de interpretación. Por ello conviene diseñar el aviso con una pregunta operativa: qué ha cambiado, qué fuente lo indica, qué consecuencias podrían existir y qué comprobación debe realizar una persona antes de actuar.
En un escenario hipotético, una empresa recibiría un aviso porque una cuota registrada difiere de su previsión. El sistema no debería concluir automáticamente que existe un incumplimiento. Primero tendría que comprobar si el dato representa una actualización contractual, una fecha de contabilización o una incidencia de sincronización. La tasa de alertas que terminan sin acción relevante sería un indicador importante del piloto. Un servicio que produce muchas notificaciones puede parecer activo mientras consume atención y reduce la probabilidad de detectar una excepción realmente importante.
3.5. Visión patrimonial sin falsas equivalencias
Para una persona o una empresa, reunir información sobre posiciones financieras puede facilitar conversaciones de planificación. Sin embargo, sumar importes de productos diferentes puede inducir a errores. Una valoración de mercado, un saldo disponible y un importe sujeto a condiciones de rescate no representan la misma capacidad de pago. El diseño debería mantener categorías separadas y evitar que una cifra global oculte restricciones. La utilidad del conjunto depende de explicar las diferencias, no de eliminarlas para simplificar una pantalla.
La aplicación también debe distinguir información y recomendación. Mostrar productos y condiciones no equivale necesariamente a aconsejar una decisión adecuada para una situación particular. Si el servicio incorpora recomendaciones, su alcance y sus obligaciones deben revisarse específicamente. Como criterio editorial de este estudio, ninguna capacidad de agregación se presenta como garantía de asesoramiento. Las empresas que evalúen estas soluciones deberían pedir ejemplos completos de las salidas y comprobar qué conclusiones podría interpretar razonablemente el cliente al leerlas.
3.6. Relación con cobros y operaciones comerciales
En pagos, la aportación de Open Finance puede aparecer alrededor de la transacción: comprender obligaciones, preparar previsiones o contextualizar flujos. El cobro con tarjeta, el enlace de pago o el checkout siguen necesitando sus propios procesos de aceptación, liquidación y conciliación. Un dato financiero adicional no sustituye la confirmación de que una operación se ha completado. Por eso el servicio debe diferenciar estados observados en una cuenta de estados comunicados por el proveedor que procesa el pago.
Una tienda con ventas físicas y digitales podría utilizar información financiera para preparar su planificación mensual, mientras mantiene la conciliación diaria en un sistema especializado. Mezclar ambos procesos sin reglas claras crea riesgo de duplicación. El mismo ingreso puede aparecer como venta, liquidación y movimiento bancario. La integración debería vincular esas representaciones cuando exista evidencia suficiente y conservarlas separadas cuando no la haya. Esta disciplina conecta con el Framework de Pagos Omnicanal, donde la continuidad de información debe acompañar al recorrido comercial.
3.7. Priorización de oportunidades
Para elegir un primer caso proponemos valorar utilidad observable, disponibilidad real de datos, sensibilidad, esfuerzo de integración y reversibilidad. Una puntuación interna puede ayudar a ordenar opciones, siempre que no oculte condiciones excluyentes. Si no existe una vía válida de acceso o nadie puede explicar la finalidad, una puntuación comercial alta no compensa la carencia. El equipo debería mantener un pequeño conjunto de criterios de entrada que se cumplan antes de comparar rentabilidad o facilidad técnica.
Entre dos proyectos atractivos suele ser preferible comenzar por aquel que permite aprender con un alcance limitado. Un calendario informativo revisado por una persona puede proporcionar evidencia sobre calidad y experiencia antes de automatizar decisiones más sensibles. Esto no implica que los casos complejos carezcan de valor, sino que necesitan más preparación y controles. La secuencia debe responder a la capacidad de la organización para detectar errores, corregirlos y sostener el servicio cuando termina la atención especial del lanzamiento.
3.8. Casos en los que conviene esperar
Existen situaciones donde una conexión nueva añade poco. Si la tarea se realiza ocasionalmente, los documentos son sencillos y la información cambia despacio, una importación controlada puede ser suficiente. También conviene esperar cuando el proveedor no demuestra cobertura del producto necesario o cuando la empresa todavía no sabe quién utilizará el resultado. Automatizar una tarea mal definida puede cristalizar confusiones que antes eran fáciles de corregir mediante conversación.
La decisión de posponer debe quedar documentada con condiciones de revisión. Puede reconsiderarse si aumenta el volumen, cambia la disponibilidad o aparece una necesidad concreta. Así se evita tanto adoptar tecnología por presión comercial como rechazarla de forma indefinida. Un proyecto de Open Finance debería competir con otras mejoras posibles, incluida la simplificación del proceso existente. El objetivo empresarial es resolver mejor una necesidad; la conexión es un medio cuya conveniencia debe demostrarse en cada contexto.
4. Permisos, privacidad y experiencia del cliente
4.1. Tres decisiones que deben distinguirse
Contratar un servicio, permitir una conexión y determinar la base jurídica de un tratamiento son cuestiones relacionadas, pero diferentes. Una interfaz puede reunirlas en un recorrido sencillo sin borrar sus límites. El cliente necesita saber qué servicio solicita y qué información se utilizará; la organización debe identificar además las condiciones que legitiman cada tratamiento. Llamar consentimiento a todas las acciones de una pantalla dificulta esa tarea y puede generar expectativas incorrectas sobre los efectos de cancelar una conexión.
Las Directrices 06/2020 del Comité Europeo de Protección de Datos distinguen el consentimiento explícito de naturaleza contractual previsto en el artículo 94.2 de PSD2 del consentimiento bajo el RGPD. Es una distinción formulada para ese marco concreto. No debe trasladarse mecánicamente a cualquier servicio de Open Finance. La consecuencia práctica que extraemos es exigir un análisis específico de cada finalidad, en lugar de suponer que un botón de autorización resuelve todas las obligaciones.
4.2. Pedir información en el momento adecuado
Una solicitud de datos resulta más comprensible cuando aparece junto a la función que necesita esos datos. Si el usuario quiere consultar vencimientos, la explicación debería referirse a ese calendario y a los productos pertinentes. Pedir acceso amplio al iniciar una cuenta, antes de mostrar utilidad, obliga a decidir con poco contexto. Como propuesta de experiencia, recomendamos una progresión en la que cada ampliación se vincule a una función elegida y a una explicación concreta de lo que cambiará.
El permiso también debe describir su duración y el tipo de acceso de forma reconocible. Términos internos como alcance o recurso pueden traducirse a categorías que el cliente entienda, sin perder precisión. Una prueba de comprensión puede pedir a participantes que expliquen con sus palabras qué compartieron, con quién y para qué. Si las respuestas difieren sustancialmente del funcionamiento real, el problema no se resuelve añadiendo una frase al final de un texto extenso. Debe revisarse el recorrido completo.
4.3. Minimización como decisión de producto
La AEPD explica la protección de datos por defecto como aplicación de la minimización mediante medidas que limiten el tratamiento a lo necesario para finalidades definidas desde el diseño. Este principio ofrece un punto de partida claro. En nuestro modelo operativo se traduce en una pregunta para cada campo solicitado: qué función perdería el servicio si ese dato no estuviera disponible. Si nadie puede responder, la petición requiere una justificación adicional antes de incorporarse.
La necesidad también depende de la precisión, la frecuencia y el periodo histórico. Una tendencia mensual puede no exigir un detalle diario. Una comparación puntual puede no necesitar una conexión permanente. Un informe agregado puede evitar mostrar identificadores completos a todos sus usuarios. Estas alternativas deben examinarse durante el diseño porque después resulta más difícil retirar datos que ya alimentan informes, métricas y procesos internos. Minimizar desde el inicio simplifica también pruebas, soporte y revisión de accesos.
4.4. Panel de conexiones comprensible
Proponemos un panel que muestre servicios conectados, categorías de datos, finalidades, fecha de activación, estado y acciones disponibles. La utilidad del panel reside en explicar relaciones, no en enumerar entidades desconocidas. Si una marca comercial y una razón social difieren, la interfaz debería ayudar a reconocerlas. También debería distinguir una conexión activa de otra caducada, interrumpida o pendiente de confirmación. Un único indicador verde puede esconder estados que requieren acciones muy diferentes por parte del usuario.
La información del panel debe coincidir con el comportamiento efectivo. Si el usuario cancela una conexión, las tareas programadas no deberían seguir solicitando datos bajo el permiso revocado. La comprobación incluye procesos diferidos y reintentos, no solo la pantalla principal. Como prueba de aceptación, el equipo puede registrar una autorización de ensayo, verificar una consulta, retirarla y confirmar que nuevas consultas quedan bloqueadas. La evidencia se obtiene del funcionamiento observado, no de la desaparición de un elemento visual.
4.5. Revocación, conservación y cierre
Interrumpir futuros accesos no significa necesariamente que desaparezca de inmediato toda información obtenida previamente. El tratamiento de datos conservados exige examinar finalidades, obligaciones y derechos aplicables. La experiencia debe explicar estas diferencias con precisión: qué deja de actualizarse, qué información permanece, durante cuánto tiempo y cómo solicitar actuaciones adicionales. Una promesa absoluta de borrado puede resultar incorrecta; una explicación vaga sobre conservación indefinida tampoco permite al cliente comprender la situación.
Desde el diseño operativo proponemos separar el cierre de conexión, la cancelación del servicio y las solicitudes relativas a datos personales. Pueden iniciarse desde un punto común, pero necesitan seguimiento propio. El sistema debería producir una confirmación comprensible y ofrecer un canal de consulta. Cuando un informe histórico se conserve, su estado debe indicar que ya no recibe actualizaciones. Esa señal evita que una decisión futura se apoye inadvertidamente en una fotografía antigua presentada con la apariencia de información actual.
4.6. Representación empresarial y cambios de equipo
En una sociedad, las autorizaciones deben sobrevivir a cambios organizativos de forma controlada. Si la persona que configuró el servicio abandona la empresa, otra debe poder administrarlo con las comprobaciones adecuadas. Usar una cuenta personal compartida por todo el equipo dificulta atribuir acciones y revocar accesos individuales. El proyecto debería definir altas, bajas y sustituciones, además de un procedimiento para casos donde la persona administradora ya no esté disponible o no pueda completar el traspaso.
La representación merece una revisión separada de la autenticación. Saber quién inicia sesión no demuestra por sí solo que pueda actuar en nombre de la empresa para todas las finalidades. El proveedor debe explicar qué verifica y qué presupone. Durante el piloto conviene probar escenarios de permisos limitados: consulta sin administración, administración sin acceso al detalle y acceso temporal para una tarea concreta. La granularidad útil depende del trabajo real, no del número de opciones que pueda ofrecer una herramienta.
4.7. Accesibilidad y alternativas reales
Un servicio puede ser técnicamente seguro y resultar difícil de utilizar para personas con necesidades diversas. Textos pequeños, estados comunicados solo mediante color, plazos demasiado breves o cambios inesperados de aplicación pueden impedir completar el recorrido. Proponemos evaluar tareas completas con teclado, tecnologías de apoyo y dispositivos habituales. La prueba debería incluir tanto conectar como corregir un error y revocar acceso, porque el control pierde sentido si únicamente el alta recibe atención de diseño.
Las alternativas deben permitir resolver la necesidad sin presión injustificada para compartir más información. Cuando exista una vía manual razonable, conviene explicar sus tiempos y limitaciones sin presentarla de forma disuasoria. La comparación entre recorridos debería considerar esfuerzo, claridad y resultados. Un cliente que prefiere aportar documentos puede tener motivos legítimos o simplemente necesitar ayuda. Convertir esa preferencia en una señal automática de riesgo confunde decisiones de privacidad con características financieras que requieren evidencia independiente.
4.8. Datos de terceros y usos secundarios
Los registros financieros pueden contener referencias a personas distintas del usuario que autoriza una conexión. El diseño debe analizar esa posibilidad antes de ampliar accesos internos o reutilizar información. Un nombre en un concepto, una contraparte o una referencia comercial no se convierte en material disponible para cualquier finalidad. Como control propuesto, la organización debería revisar qué detalles necesita cada función y evitar que campos textuales completos lleguen a herramientas auxiliares cuando bastan categorías o identificadores limitados.
Los usos secundarios merecen una decisión explícita. Mejorar el producto, elaborar estadísticas o entrenar modelos son actividades que deben evaluarse por separado del servicio solicitado. La utilidad potencial no elimina la necesidad de revisar condiciones y legitimación. El inventario de tratamientos debería mantenerse conectado al inventario técnico para que una nueva exportación o integración no escape a la revisión. La confianza se sostiene cuando el funcionamiento cotidiano coincide con la explicación que recibió el cliente al decidir participar.
5. Arquitectura, calidad e interoperabilidad
5.1. Del dato recibido al resultado mostrado
Una arquitectura de Open Finance debería poder explicar el recorrido desde una fuente hasta una decisión. Entre ambos extremos suelen existir autenticación, comprobación de permisos, consulta, validación, transformación, almacenamiento y presentación. Cada paso puede introducir errores diferentes. El mapa técnico debe vincularse al mapa de negocio para identificar dónde se determina el significado de un campo y dónde se decide qué mostrar. Sin esa conexión, una incidencia puede quedar atrapada entre equipos que consideran correcta su parte aislada del proceso.
El informe del CGIDE sobre estándares de API para compartir datos, publicado por el BIS en 2022, examina modelos de intercambio y destaca retos de coordinación, estandarización e infraestructura. No prescribe una única arquitectura para todas las empresas. A partir de ese contexto, proponemos elegir componentes según el caso de uso y la capacidad operativa. Centralizar puede simplificar algunas tareas, mientras que también concentra dependencias; distribuir responsabilidades exige coordinación y observabilidad suficientes.
5.2. Contratos de datos y significado
Un contrato de datos describe qué se espera recibir y cómo debe interpretarse. Debería incluir campos, formatos, unidades, estados, periodicidad y reglas para valores ausentes. La estructura técnica es solo una parte. Un importe puede representar capital pendiente, cuota o valoración; una fecha puede indicar operación, registro o actualización. Si esas distinciones no están documentadas, dos sistemas pueden intercambiar mensajes válidos y producir un resultado conceptualmente incorrecto. La interoperabilidad semántica necesita trabajo conjunto entre especialistas del producto y del sistema.
Conviene mantener ejemplos representativos de cada campo, incluidos casos límite. Un valor cero, un valor desconocido y un producto no disponible deben tratarse de forma distinta. Sustituir todos por cero facilita cálculos, pero altera el significado. Del mismo modo, un campo opcional no debería convertirse silenciosamente en obligatorio porque una pantalla necesita rellenar una casilla. Cuando falta información, la experiencia debe señalarlo y definir qué funciones siguen siendo fiables. La incertidumbre visible es preferible a una precisión fabricada por defecto.
5.3. Actualidad, cobertura y procedencia
La calidad tiene varias dimensiones. Una información puede ser correcta y estar desactualizada; puede ser reciente pero incompleta; puede tener cobertura amplia y carecer de una procedencia clara. Proponemos registrar estas dimensiones por separado. La fecha de consulta no siempre coincide con la fecha del dato original, de modo que ambas pueden ser necesarias. Un usuario necesita saber si acaba de recuperar una información producida hoy o un registro antiguo que la fuente todavía mantiene sin cambios.
La cobertura debe describirse sobre el universo relevante. Decir que un proveedor conecta muchas entidades no demuestra que cubra los productos que utiliza una empresa. El piloto debería partir de una lista concreta y comprobar campos esenciales, historia disponible y frecuencia efectiva. Las exclusiones se documentan junto a los resultados. Si falta una obligación importante, el panel no debería anunciar una visión completa. La transparencia sobre cobertura permite decidir qué comprobaciones manuales siguen siendo necesarias y evita abandonar controles prematuramente.
5.4. Duplicados, correcciones y versiones
Los datos pueden llegar más de una vez o cambiar después de una primera consulta. El sistema necesita identificar registros de forma estable y distinguir repetición de corrección. Un reintento no debería duplicar un compromiso en un calendario. Una actualización no debería borrar sin rastro el contexto de una decisión anterior. Las reglas deben diseñarse según el producto y conservar suficiente evidencia para reconstruir qué información estaba disponible cuando se generó un informe o se emitió una alerta.
El tratamiento de versiones también afecta a las interfaces. Un proveedor puede añadir un campo, modificar un estado o retirar una versión. El contrato debería explicar cómo se notifican cambios y cuánto tiempo existe para adaptarse. Antes de desplegar una actualización conviene probar ejemplos conocidos y situaciones incompletas. La compatibilidad no se demuestra únicamente porque la conexión responde: debe comprobarse que los resultados mantienen el significado esperado. Un cambio pequeño de formato puede tener consecuencias importantes si altera una clasificación utilizada por operaciones.
5.5. Procesos diferidos y límites de consulta
No todas las tareas necesitan información instantánea. Un informe mensual puede funcionar con actualizaciones programadas, mientras que una consulta interactiva requiere otra experiencia. Diseñar cada función según su necesidad reduce llamadas innecesarias y evita prometer una inmediatez que la fuente no ofrece. Los límites de consulta, las ventanas de mantenimiento y los tiempos de respuesta deben incorporarse al servicio. Cuando una actualización se retrasa, la pantalla debería mostrar el estado real y ofrecer una opción coherente para continuar.
Los reintentos necesitan reglas para no agravar una incidencia. Repetir peticiones continuamente puede sobrecargar una dependencia y generar más fallos. Como práctica propuesta, se definirían esperas crecientes, límites y un estado de revisión cuando persista el problema. La expiración de un permiso debe diferenciarse de una indisponibilidad temporal, porque requiere una respuesta distinta. El equipo de soporte necesita mensajes accionables: pedir al usuario una nueva autorización no ayuda cuando el problema está en una interrupción del proveedor.
5.6. Pruebas con escenarios representativos
El entorno de prueba debe cubrir tanto el recorrido normal como situaciones difíciles: productos sin información reciente, permisos limitados, datos corregidos, respuestas parciales y desconexiones. Los datos sintéticos ayudan a ensayar estas situaciones sin exponer información real innecesariamente. Sin embargo, un entorno de demostración puede no reproducir todos los comportamientos de producción. La validación debe reconocer esa limitación y reservar una fase controlada para observar el funcionamiento efectivo con participantes y condiciones apropiadas.
Una prueba útil vincula entrada, transformación y resultado esperado. Por ejemplo, si dos registros representan el mismo compromiso, el calendario debería mostrar una sola obligación y conservar la relación con sus fuentes. Si no existe evidencia suficiente para unirlos, debería pedir revisión. El criterio no puede definirse después de ver el resultado para justificarlo. Establecer casos y expectativas antes de la ejecución permite detectar regresiones y comparar proveedores sin que cada uno elija únicamente sus ejemplos más favorables.
5.7. Interoperabilidad internacional y sus límites
El Proyecto Aperta del BIS explora mediante un prototipo la interconexión transfronteriza de redes de finanzas abiertas. Su documentación presenta una capa de interoperabilidad y aprendizajes para posibles desarrollos posteriores. La existencia del prototipo demuestra trabajo experimental, no disponibilidad comercial universal ni autorización automática para intercambiar cualquier dato entre países. Esa diferencia es especialmente importante cuando una empresa compara promesas de cobertura internacional con las capacidades que puede contratar y utilizar efectivamente.
Una operación internacional requiere comprobar productos, participantes, condiciones y tratamiento de datos en cada recorrido. Traducir campos no resuelve por sí solo diferencias contractuales o de responsabilidad. Como criterio de evaluación, conviene pedir una demostración del caso exacto que interesa a la empresa, con sus limitaciones documentadas. Una hoja de ruta puede ser relevante para valorar al proveedor, pero debe mantenerse separada de las funciones disponibles. El presupuesto base debería apoyarse en capacidades verificadas, dejando los desarrollos futuros como escenarios condicionados.
5.8. Una arquitectura que permita corregir
La calidad sostenida depende de que las correcciones puedan propagarse sin improvisación. Si un dato de origen cambia, el equipo debe saber qué informes, alertas y exportaciones podrían estar afectados. No siempre será apropiado modificar automáticamente un documento histórico; a veces será necesario emitir una versión corregida y explicar el motivo. El sistema debe conservar vínculos suficientes para localizar consecuencias y evitar que una corrección en la pantalla principal deje resultados contradictorios en otros canales.
Proponemos que cada resultado importante incluya una referencia a su versión, periodo y estado de revisión. Estas señales facilitan conversaciones entre personas y sistemas. También permiten retirar una función temporalmente sin detener todo el servicio cuando el problema está localizado. La arquitectura más útil para una empresa no es necesariamente la más sofisticada, sino aquella que sus equipos pueden entender, mantener y corregir. Esa capacidad práctica debería demostrarse durante el piloto antes de ampliar conexiones o automatizar decisiones.
6. Seguridad, continuidad y gestión de riesgos
6.1. Un modelo de amenazas centrado en el servicio
La seguridad de una conexión no puede evaluarse únicamente por el uso de cifrado. El análisis debe incluir quién puede solicitar datos, cómo se comprueba su permiso, dónde aparecen los resultados y qué ocurre cuando un componente se compromete. Proponemos comenzar con un modelo de amenazas sencillo, construido alrededor de las tareas del servicio. Para cada paso se identifican acciones indebidas posibles, impacto, controles y evidencia de funcionamiento. El ejercicio necesita participación de operaciones porque los errores humanos y organizativos también forman parte del recorrido.
Entre los escenarios que conviene ensayar están el acceso de una persona que ya no trabaja en la empresa, una consulta fuera del alcance autorizado y la exposición accidental de un informe mediante un enlace. Cada uno exige medidas distintas. Un control fuerte de entrada no evita necesariamente una exportación posterior mal compartida. El mapa de amenazas debería acompañar al mapa de datos y actualizarse cuando se añade una función, una dependencia o un nuevo tipo de usuario.
6.2. Acceso mínimo y separación de funciones
Los permisos internos deben responder a tareas concretas. Quien revisa incidencias técnicas puede necesitar identificadores de operación sin ver importes o conceptos completos. Quien administra usuarios puede no necesitar consultar todos los productos conectados. Esta separación reduce exposición y facilita atribuir acciones. En organizaciones pequeñas puede haber funciones combinadas, pero conviene reconocer esa concentración y establecer revisiones proporcionadas. La simplicidad operativa no debería equivaler a dar acceso total por defecto a todas las personas.
Los accesos excepcionales requieren duración y seguimiento. Si un proveedor necesita investigar una incidencia, la empresa debería conocer qué información utilizará y cómo termina ese acceso. Un permiso temporal que permanece activo después de resolver el problema se convierte en una dependencia olvidada. Proponemos revisar periódicamente usuarios, funciones y excepciones con una persona de negocio que reconozca a quienes realmente necesitan acceso. Una lista técnicamente correcta puede seguir incluyendo personas cuya necesidad desapareció hace meses.
6.3. Credenciales, sesiones y recuperación
Las credenciales de integración y los elementos que permiten consultar datos deben gestionarse con mecanismos adecuados de protección, rotación y revocación. El equipo necesita procedimientos para responder cuando se sospecha una exposición. También debe conocer qué conexiones quedarán afectadas al reemplazar una credencial. Una rotación sin planificación puede interrumpir servicios; una ausencia de rotación ante un compromiso prolonga el riesgo. La prueba del procedimiento debería realizarse antes de que una incidencia real obligue a ejecutarlo con presión.
La recuperación de una cuenta merece atención equivalente al inicio de sesión. Si recuperar acceso resulta mucho más fácil que autenticarse normalmente, ese recorrido puede convertirse en el punto débil. El diseño debe equilibrar protección y capacidad de restablecer el servicio para usuarios legítimos. En el piloto conviene ensayar pérdida de dispositivo, cambio de responsable y bloqueo accidental. Las instrucciones de soporte deben evitar pedir información innecesaria y mantener un registro suficiente de las comprobaciones realizadas.
6.4. Registros útiles sin exposición excesiva
La observabilidad permite saber qué ocurrió, pero no exige copiar todo el contenido financiero a cada registro técnico. Proponemos registrar identificadores, estados, tiempos y categorías de error, reservando el detalle sensible para situaciones justificadas y controladas. Los registros deben tener acceso y conservación definidos. Una herramienta de seguimiento puede convertirse en un repositorio paralelo si recibe mensajes completos por comodidad durante el desarrollo y esa configuración permanece después del lanzamiento.
Una investigación debería poder reconstruir una secuencia: qué permiso estaba activo, qué consulta se realizó, qué respuesta se recibió y qué resultado se mostró. Esa reconstrucción debe proteger la información de otras personas y empresas. Los informes de incidencias destinados a distintos equipos pueden necesitar niveles de detalle diferentes. La calidad de la evidencia depende de su coherencia y trazabilidad, no de acumular más datos. También es importante comprobar que los relojes y referencias temporales permiten ordenar eventos correctamente.
6.5. Indisponibilidad y funcionamiento degradado
Una dependencia puede fallar sin que exista un ataque. El plan de continuidad debería definir qué funciones pueden seguir operando con información anterior y cuáles deben detenerse. Mostrar un informe histórico puede ser razonable si está claramente fechado; emitir una alerta basada en una actualización fallida puede resultar engañoso. La decisión depende del uso. Por ello se recomienda clasificar funciones según la actualidad mínima que necesitan y diseñar mensajes específicos para cada estado de indisponibilidad.
El funcionamiento degradado debe ensayarse con usuarios reales del proceso. Una alternativa manual que nadie conoce o que requiere un acceso no disponible no constituye una solución práctica. El equipo debería comprobar cuánto tarda en activarse, quién la mantiene y cómo se reconcilia la información al recuperar el servicio. Volver a conectar no cierra por sí solo la incidencia: pueden quedar tareas pendientes, informes desactualizados o consultas duplicadas que requieren revisión antes de declarar la operación normalizada.
6.6. Respuesta coordinada a incidentes
El plan de respuesta necesita un punto de coordinación, criterios de escalado y canales alternativos. Debe distinguir incidentes de disponibilidad, integridad, confidencialidad y permisos, aunque puedan coincidir. Cuando aparece una anomalía, la primera decisión puede ser limitar una función mientras se investiga. La capacidad de aislar una conexión o un grupo afectado reduce la necesidad de detener todo el servicio. Los criterios de comunicación deben considerar las obligaciones aplicables y la información que necesitan las personas afectadas.
Proponemos un ejercicio de mesa con un escenario concreto: el sistema muestra información de una empresa en una sesión que no debería verla. El equipo debe identificar cómo se detiene la exposición, quién conserva evidencia, quién determina el alcance y quién coordina las actuaciones posteriores. El ejercicio no busca producir respuestas perfectas, sino descubrir vacíos. Si los participantes desconocen los contactos del proveedor o las facultades para suspender acceso, esas carencias deben corregirse antes de ampliar el proyecto.
6.7. Integridad de resultados y decisiones sensibles
Un error de interpretación puede causar daño aunque nadie haya accedido de forma indebida. Por ejemplo, clasificar una información incompleta como ausencia de obligaciones puede alterar una previsión. La gestión de riesgos debe incluir controles sobre resultados, no solo sobre infraestructura. Los casos que influyen en financiación, seguros u otras decisiones relevantes requieren una evaluación específica de sus consecuencias y de las reglas aplicables. La conexión de datos no justifica automatizar conclusiones sin mecanismos de revisión adecuados.
Como propuesta operativa, el sistema debería conservar razones comprensibles para los resultados importantes y permitir aportar información adicional. También conviene examinar si ciertos grupos de clientes quedan peor representados por la cobertura disponible. La falta de datos no demuestra necesariamente un riesgo mayor. Puede reflejar productos no conectados, decisiones de privacidad o trayectorias diferentes. Las métricas del piloto deben detectar esas situaciones para evitar que una limitación técnica se convierta silenciosamente en un criterio comercial desfavorable.
6.8. Salida del proveedor y cierre ordenado
La continuidad incluye poder terminar una relación. Antes de contratar conviene definir qué información puede exportarse, en qué formato, qué permisos deben cancelarse y cómo se verificará el cierre. La portabilidad de un informe no equivale a portar toda la lógica del servicio, por lo que la empresa debe identificar qué conocimiento necesita conservar. Un proveedor puede entregar archivos completos que resulten difíciles de interpretar si faltan diccionarios, versiones o explicaciones de los cálculos.
Un ensayo de salida limitado permite comprobar estas condiciones sin esperar a una ruptura contractual. El equipo puede exportar un conjunto de prueba, reconstruir una tarea y verificar la cancelación de accesos asociados. Los resultados forman parte de la evaluación económica y técnica. Si abandonar la solución exige meses de reconstrucción, ese coste debe conocerse al inicio. Un servicio sostenible mantiene valor mientras se utiliza y permite una transición ordenada cuando cambian las necesidades de la empresa.
7. Economía del proyecto y evaluación del piloto
7.1. Medir una mejora que importe
La evaluación económica comienza con una tarea y una unidad de medida. Puede ser preparar un expediente, revisar un calendario o resolver una discrepancia. Medir conexiones activas o consultas realizadas informa sobre utilización, pero no demuestra beneficio. Proponemos vincular cada indicador técnico con un resultado operativo: tiempo para completar la tarea, errores que requieren corrección, consultas de soporte o capacidad de explicar un resultado. La empresa debe elegir indicadores que pueda observar de forma consistente antes y después del piloto.
El ahorro de tiempo tampoco equivale automáticamente a ahorro monetario. Si una persona dispone de más minutos pero no cambia la capacidad de trabajo ni se reduce un coste, el beneficio puede ser flexibilidad o mejor atención. Sigue siendo valioso, pero debe describirse correctamente. Convertir todo minuto liberado en una reducción de plantilla produce una estimación engañosa. La evaluación debería distinguir costes evitados, capacidad adicional y mejoras de calidad, indicando qué parte se ha observado y qué parte permanece como hipótesis.
7.2. Coste total y esfuerzo interno
El presupuesto debe incluir configuración, integración, revisión, formación, soporte, mantenimiento y salida, además de la tarifa del proveedor. También importa el tiempo de quienes participan en permisos, comprobaciones y resolución de incidencias. Una solución barata por conexión puede resultar costosa si requiere revisiones frecuentes. Al contrario, una tarifa mayor puede justificarse si reduce trabajo comprobable y ofrece un servicio adecuado. La comparación necesita el mismo volumen, alcance y nivel de soporte para evitar enfrentar ofertas que en realidad cubren necesidades diferentes.
Los costes variables requieren escenarios. El número de clientes, productos conectados, consultas y reintentos puede evolucionar de manera distinta. La empresa debería comprender qué evento genera facturación y qué ocurre durante fallos o pruebas. Un presupuesto que solo utiliza el volumen inicial puede subestimar el coste de una implantación exitosa. También conviene identificar compromisos mínimos, cambios de tarifa y servicios opcionales necesarios para operar. Estas condiciones deben constar en la evaluación, no descubrirse cuando el proyecto ya depende de la herramienta.
7.3. Ejemplo económico ilustrativo
Supongamos, únicamente como ejercicio, que una empresa prepara doscientos informes al mes. Si una prueba comparable observa una reducción de diez minutos por informe, se liberarían dos mil minutos, aproximadamente treinta y tres horas mensuales. Esta operación aritmética no demuestra que todas esas horas puedan monetizarse. Debe comprobarse si la reducción se mantiene, si aparecen tareas nuevas de revisión y si el equipo utiliza la capacidad liberada para un resultado útil. Los supuestos no representan una estimación del mercado español.
Si el servicio exige ocho horas mensuales de supervisión adicional, el beneficio bruto de tiempo debe reducirse antes de compararlo con la tarifa. También habría que considerar incidencias, formación y amortización de la implantación. Un escenario conservador podría suponer menor utilización o más revisiones. Otro examinaría crecimiento sin aumento equivalente del equipo. El objetivo no es obtener una cifra atractiva, sino entender qué variables hacen que el proyecto sea razonable y en qué condiciones dejaría de serlo.
7.4. Diseño de una comparación justa
El piloto debería incluir tareas representativas y registrar excepciones. Seleccionar únicamente clientes con información completa puede producir una imagen excesivamente favorable. Del mismo modo, comparar un proceso nuevo atendido por especialistas con uno antiguo sin apoyo introduce un sesgo. Una evaluación práctica puede utilizar periodos comparables o grupos de tareas semejantes, documentando diferencias relevantes. No siempre será posible un experimento formal, pero sí es posible reconocer limitaciones y evitar conclusiones que los datos disponibles no sostienen.
Los criterios de éxito deben acordarse antes de examinar resultados. Además de una mejora de eficiencia, pueden exigirse condiciones mínimas de comprensión, calidad y revocación. Una media favorable no debería compensar errores graves sin resolver. El informe final debe mostrar distribución y casos problemáticos, no solo un promedio. Si la herramienta funciona bien para un segmento y mal para otro, la decisión puede ser ampliar de forma selectiva o rediseñar el servicio, en lugar de emitir una conclusión universal.
7.5. Cuadro de indicadores propuesto
El siguiente cuadro es una propuesta para organizar la observación. Los umbrales deben definirse según el riesgo y la tarea, por lo que no se presentan valores universales. Cada métrica necesita una definición, una fuente y una persona responsable. También debe aclararse qué se excluye del cálculo. Una tasa de éxito que omite abandonos o respuestas parciales puede parecer excelente mientras la experiencia completa sigue siendo deficiente.
| Dimensión | Indicador | Pregunta de revisión |
|---|---|---|
| Utilidad | Tareas completadas correctamente | ¿Se resuelve la necesidad original? |
| Esfuerzo | Tiempo total por tarea | ¿Incluye revisión y soporte? |
| Calidad | Resultados que necesitan corrección | ¿Qué causas se repiten? |
| Control | Revocaciones verificadas | ¿Cesan los accesos posteriores? |
| Experiencia | Comprensión y abandonos | ¿El cliente entiende su elección? |
| Continuidad | Recuperación de tareas pendientes | ¿Quedan errores después del fallo? |
La revisión conjunta evita optimizar una dimensión a costa de otra. Acelerar el alta puede elevar activaciones y reducir comprensión. Consultar con mayor frecuencia puede mejorar actualidad y aumentar coste sin utilidad adicional. Los indicadores deben servir para discutir esas compensaciones, no para premiar automáticamente a quien eleva una cifra aislada. El responsable del proyecto debería poder explicar qué cambió en el proceso y qué evidencia respalda la decisión de continuar.
7.6. Contratación basada en demostraciones
La selección de proveedor debería utilizar un guion común de demostración. Se pide conectar un producto relevante, mostrar información incompleta, retirar permiso y exportar un resultado. También se examina una incidencia representativa y el procedimiento de soporte. Las respuestas comerciales se convierten así en evidencia observable. Una presentación sobre capacidades futuras puede acompañar la evaluación, pero no reemplaza las pruebas de las funciones que necesita la empresa en el momento de contratar.
Las referencias de clientes pueden ayudar a formular preguntas, aunque no sustituyen la validación propia. El contexto, volumen y recursos de otra organización pueden diferir. Conviene pedir ejemplos de límites y fallos, además de casos de éxito. Un proveedor que explica con claridad dónde no encaja su servicio facilita una decisión informada. La confianza contractual se construye mediante alcance preciso, responsabilidades claras y mecanismos de resolución, no mediante promesas generales de transformación que resultan difíciles de verificar.
7.7. Decidir ampliar, modificar o detener
El cierre del piloto debería producir una decisión concreta y sus condiciones. Ampliar exige recursos para mantener controles fuera del entorno protegido de la prueba. Modificar requiere identificar qué hipótesis se revisará y cómo se comprobará. Detener puede ser una decisión correcta si la utilidad no compensa el coste o si persisten carencias relevantes. La evaluación pierde valor cuando todos los resultados conducen automáticamente a continuar porque ya se ha invertido esfuerzo.
Una decisión documentada debería incluir resultados, limitaciones, riesgos pendientes y próxima revisión. También conviene conservar aprendizajes reutilizables, como el inventario de datos o las pruebas de comprensión, aunque se abandone una solución concreta. Así el piloto produce conocimiento y evita repetir errores. Open Finance debe tratarse como una capacidad empresarial que se desarrolla con evidencia, no como una compra única que garantiza resultados por el simple hecho de habilitar nuevas conexiones.
8. Hoja de ruta, conclusiones y referencias
8.1. Fase inicial: definir y delimitar
La primera fase consiste en redactar una ficha de proyecto comprensible para todas las personas implicadas. Debe identificar la tarea que se quiere mejorar, los usuarios, los datos necesarios y las decisiones que seguirán requiriendo intervención humana. También debe señalar lo que queda fuera del piloto. Una delimitación clara reduce cambios de alcance y facilita evaluar resultados. Si la ficha necesita expresiones abstractas para explicar su utilidad, conviene volver al proceso cotidiano y describir un problema observable.
El entregable de esta fase es una hipótesis verificable acompañada de un inventario preliminar. La organización identifica fuentes, productos, responsables y condiciones de acceso que necesita comprobar. No se presupone disponibilidad por el mero hecho de que una entidad aparezca en una lista comercial. Antes de avanzar se confirma que existe un recorrido viable y que las personas responsables de negocio, operaciones y revisión especializada comparten la misma interpretación del servicio.
8.2. Fase de diseño: conectar responsabilidades
La segunda fase transforma la hipótesis en un recorrido completo. Se dibujan alta, autorización, consulta, resultado, incidencia y cierre. Para cada paso se especifica quién actúa y qué evidencia demuestra que ha funcionado. El diseño incorpora mensajes para datos ausentes, conexiones interrumpidas y permisos retirados. Estas situaciones forman parte del producto desde el principio. Resolverlas después del lanzamiento suele exigir cambios más costosos porque afectan simultáneamente a interfaz, soporte, contratos y procesos internos.
El entregable es un conjunto pequeño de escenarios de aceptación. Deben incluir tareas normales y excepciones, con resultados esperados definidos antes de probar. También se acuerdan reglas para detener una función cuando aparezca un problema relevante. La capacidad de pausa debe ser concreta: una persona autorizada, un mecanismo disponible y un procedimiento de comunicación. Un principio general de prudencia no ayuda si nadie sabe cómo suspender una consulta o retirar un informe incorrecto.
8.3. Fase de prueba: observar el proceso completo
La tercera fase utiliza un alcance limitado para comprobar utilidad, calidad y comprensión. Se registra el esfuerzo de todas las personas participantes, incluidas quienes resuelven incidencias. El equipo compara resultados con la situación inicial y revisa los casos que no encajan. Las reuniones de seguimiento deberían centrarse en decisiones: qué explicación debe mejorarse, qué dato no resulta fiable y qué control necesita ajuste. Acumular métricas sin cambiar nada convierte el piloto en una demostración prolongada.
La prueba debe terminar con una revisión de cierre, incluso si el servicio parece funcionar bien. Se comprueba revocación, exportación y continuidad, y se registran limitaciones. La organización decide qué parte puede pasar a uso habitual y qué parte requiere más evidencia. Un piloto exitoso no obliga a desplegar todas las capacidades del proveedor. Puede justificar únicamente una función acotada que aporta valor demostrado y que el equipo está preparado para mantener.
8.4. Fase de operación: mantener la evidencia
En operación, los responsables deben revisar cambios de cobertura, contratos, personas y finalidades. También se necesita una rutina para actualizar documentación y pruebas cuando cambian interfaces o productos. El proyecto no termina al conectar la última entidad. La información financiera evoluciona y las decisiones empresariales también. Un servicio que fue adecuado al inicio puede dejar de serlo si aumenta su alcance sin una revisión equivalente de permisos, calidad y capacidad de soporte.
La revisión periódica puede ser breve si se apoya en registros mantenidos durante el trabajo. Debe preguntar qué funciones siguen utilizándose, qué datos ya no son necesarios y qué incidencias se repiten. Retirar conexiones sin utilidad reduce complejidad y coste. La mejora continua también puede consistir en simplificar. Añadir una fuente solo debería proponerse cuando exista una necesidad identificada y una forma de comprobar que el beneficio supera el esfuerzo adicional.
Para facilitar el mantenimiento, cada revisión puede terminar con tres decisiones registradas: conservar una función, modificarla o retirarla. El acta debe indicar responsable y fecha de comprobación. Este hábito evita que las observaciones queden sin respuesta y permite distinguir problemas conocidos de cambios recientes. También proporciona continuidad cuando otra persona asume la gestión del servicio y necesita comprender decisiones anteriores.
8.5. Preguntas frecuentes
¿Open Finance permite mover dinero? El acceso a información no implica por sí mismo una autorización para iniciar pagos. Cada capacidad debe identificarse y revisarse por separado. ¿Es necesario conectar todos los productos? No como criterio de diseño de este paper: se propone comenzar con los datos necesarios para una tarea definida y justificar cualquier ampliación. La disponibilidad y las condiciones concretas dependen del servicio contratado y del marco aplicable.
¿Un permiso basta para cualquier reutilización? No debe suponerse. Finalidades, condiciones y legitimación necesitan evaluación específica. ¿FiDA garantiza hoy acceso universal? Este documento no realiza esa afirmación; el estado consultado se describe en el primer capítulo y debe verificarse de nuevo para decisiones posteriores. ¿Cómo saber si merece la pena? Mediante una comparación del proceso completo, que incluya utilidad, esfuerzo, calidad, control y coste de salida.
8.6. Conclusiones de la investigación
El análisis sostiene que Open Finance puede ser útil cuando resuelve una necesidad concreta mediante información pertinente y controlable. La ampliación del acceso no elimina las diferencias entre productos, las limitaciones de cobertura ni la responsabilidad de interpretar correctamente los resultados. La empresa necesita mantener separadas la capacidad técnica, la autorización, la legitimación del tratamiento y la utilidad comercial. Confundir cualquiera de estas dimensiones puede producir una solución aparentemente completa que no sea adecuada para el uso previsto.
La estrategia propuesta es gradual: empezar por un caso comprensible, establecer evidencia inicial, probar el recorrido completo y ampliar solo lo que pueda sostenerse. La confianza depende tanto de una conexión correcta como de una salida clara y de una respuesta competente ante errores. Las finanzas abiertas aportan una nueva forma de organizar información; su valor empresarial aparece cuando esa información mejora procesos sin ocultar incertidumbre ni reducir la capacidad del cliente para decidir.
8.7. Glosario operativo
Open Finance: intercambio autorizado de información financiera para servicios definidos, con alcance conceptual más amplio que las cuentas de pago. FiDA: expediente europeo sobre un marco de acceso a datos financieros. Interoperabilidad: capacidad de intercambiar e interpretar información entre sistemas. Procedencia: relación documentada entre un dato, su fuente y sus transformaciones. Revocación: retirada de un permiso de acceso, cuyos efectos deben distinguirse de otras actuaciones sobre datos conservados.
Cobertura: parte del universo relevante que el servicio puede observar efectivamente. Funcionamiento degradado: modo limitado de operación cuando una dependencia falla. Contrato de datos: especificación de estructura, significado y condiciones de una información. Portabilidad operativa: capacidad práctica de recuperar información utilizable para continuar una tarea. Estas definiciones sirven al análisis del documento y no sustituyen las definiciones jurídicas que correspondan a cada servicio o norma.
8.8. Fuentes primarias y trazabilidad
Referencias consultadas para esta edición. Los documentos institucionales sustentan el contexto expresamente atribuido; la hoja de ruta, las matrices y los escenarios son propuestas analíticas propias. Las fuentes internacionales no se utilizan como mediciones directas del mercado español.
- Comisión Europea. Framework for financial data access.
- Parlamento Europeo. Expediente legislativo 2023/0205(COD).
- Consejo de la UE. Posición negociadora sobre acceso a datos financieros, diciembre de 2024.
- BIS. Opening doors to open finance: evidence from the international experience, marzo de 2026.
- BIS y CGIDE. API standards for data-sharing, octubre de 2022.
- BIS. Project Aperta: open finance interoperability, 2026.
- CEPD. Directrices 06/2020 sobre PSD2 y RGPD, versión final.
- AEPD. Protección de datos por defecto.
Soluciones de Pago · Biblioteca de Investigación. Información sobre el equipo de redacción e investigación.
