El Open Banking es un modelo de intercambio seguro y consentido de datos bancarios y de iniciación de pagos mediante APIs. Para una empresa, no consiste simplemente en «conectarse al banco»: exige coordinar consentimiento, identidad, seguridad, contratos de datos, integración, observabilidad y operación para que cada acceso pueda entenderse, controlarse y auditarse.
Su valor aparece cuando esa conectividad se convierte en una capacidad reutilizable: conciliación automática, visión financiera agregada, pagos integrados, verificación de cuentas o experiencias embebidas. La arquitectura correcta depende del servicio, el territorio, el riesgo y el papel regulatorio de cada participante; ninguna integración garantiza por sí sola cumplimiento, conversión o ahorro.
La decisión ejecutiva es, por tanto, más amplia que elegir un agregador o un API gateway. Consiste en definir qué datos y operaciones necesita el negocio, con qué permisos, qué sistemas son autoritativos, cómo se gestionan excepciones y qué dependencias deben poder sustituirse.
Qué es Open Banking y qué no es
En el marco europeo, la Directiva (UE) 2015/2366 —PSD2— impulsó el acceso de proveedores autorizados a cuentas de pago, con consentimiento del usuario y requisitos de autenticación reforzada y comunicación segura. La Comisión Europea mantiene la información sobre el marco vigente y las propuestas de evolución. Conviene distinguir lo aplicable de lo propuesto: PSD3, el futuro Reglamento de Servicios de Pago y FIDA forman parte de una evolución normativa que no debe describirse como obligación consumada sin comprobar su estado.
Open Banking abre una interfaz regulada o contractual sobre capacidades financieras; la transformación ocurre cuando la organización integra esa interfaz en decisiones, procesos y sistemas con un modelo operativo verificable.
| Concepto | Alcance principal | Activo compartido | Riesgo de confusión |
|---|---|---|---|
| Open Banking | Cuentas de pago, información e iniciación de pagos según mercado y autorización | Datos y operaciones a través de APIs | Reducirlo a una pantalla de agregación |
| Open Finance | Extiende el intercambio a más productos financieros | Ahorro, inversión, crédito, seguros u otros datos | Presentarlo como plenamente homogéneo en todos los países |
| Finanzas embebidas | Integra servicios financieros en experiencias no bancarias | Pago, crédito, seguro o cuenta dentro de otro recorrido | Confundir experiencia comercial con arquitectura y responsabilidad |
| Banking as a Service | Expone capacidades bancarias para crear productos | Infraestructura, cuentas, pagos y cumplimiento según modelo | Suponer que cualquier integrador se convierte en entidad regulada |
| Agregación bancaria | Reúne información de varias cuentas | Saldos, movimientos y titulares permitidos | Tratar el dato agregado como verdad sin reconciliación |
La pieza sobre embedded insurance profundiza en un caso de finanzas embebidas. Aquí el foco es la capacidad transversal: cómo gobernar las conexiones, el consentimiento y los datos para que distintos productos puedan reutilizarlos sin duplicar lógica.
Dónde crea valor y dónde suele atascarse
Los casos de uso más claros conectan una señal financiera con una acción operativa. La conciliación puede asociar cobros y facturas; la tesorería puede consolidar posiciones; una plataforma puede iniciar un pago; un proceso de alta puede comprobar titularidad; y un motor de riesgo puede enriquecer una evaluación, siempre que exista base y propósito aplicables.
- Tesorería conectada. Reunir posiciones y movimientos para reducir descargas y consolidaciones manuales.
- Conciliación. Relacionar pagos, pedidos y facturas con reglas y excepciones explícitas.
- Pagos integrados. Iniciar operaciones desde el recorrido de negocio sin ocultar autenticación, estado o devolución.
- Verificación de cuenta. Confirmar atributos permitidos antes de activar un servicio o cambiar un destino de pago.
- Evaluación contextual. Incorporar datos consentidos a decisiones que conservan razones, versión y supervisión.
- Experiencias embebidas. Integrar una capacidad financiera en un canal sectorial sin convertir el canal en el sistema de registro.
El atasco aparece cuando la demostración funciona con una cuenta y el diseño real debe soportar múltiples bancos, versiones, territorios, consentimientos caducados, latencias, duplicados y estados asíncronos. El Banco de España ha analizado el efecto del Open Banking y señala particularidades del mercado español; la documentación técnica de proveedores también muestra diferencias de comportamiento entre interfaces aparentemente estandarizadas.
Siete capas de una arquitectura de Open Banking gobernable
Una arquitectura robusta separa responsabilidades. Un mismo proveedor puede cubrir varias capas, pero la empresa necesita conocer los límites, los contratos y la evidencia de cada una. Así puede evolucionar una pieza sin rehacer el producto completo.
1. Experiencia y producto
El canal explica el servicio, solicita permisos comprensibles, muestra estados y permite corregir o retirar. No debería guardar la única copia del consentimiento ni resolver por sí solo reglas de riesgo. La experiencia debe poder cambiar sin alterar los contratos internos.
2. Consentimiento e identidad
Esta capa registra quién autoriza, qué cuentas, datos u operaciones, para qué finalidad, durante cuánto tiempo y mediante qué mecanismo. Debe relacionar consentimiento, identidad, tercero, alcance y revocación. Un token válido no demuestra por sí solo que el uso posterior siga siendo adecuado.
3. Conectividad y gestión de APIs
Incluye directorios, certificados, adaptadores bancarios, API gateway, límites, versiones y traducción de errores. La EBA documentó problemas prácticos de las APIs bajo PSD2. La normalización debe ocultar diferencias al producto sin borrar información necesaria para diagnosticar.
4. Contrato y calidad del dato
Los datos se modelan con procedencia, marca temporal, moneda, titularidad, estado y nivel de completitud. La empresa necesita reglas de deduplicación, reconciliación y caducidad. El enfoque de DataOps ayuda a probar y observar estos flujos como productos de datos, no como cargas ocasionales.
5. Orquestación e integración
La orquestación conecta ERP, tesorería, CRM, facturación, fraude, producto y comunicaciones. Gestiona reintentos, tiempos de espera, eventos y compensaciones. Debe ser idempotente: repetir una notificación o una orden no puede duplicar pagos, apuntes o clientes.
6. Decisión y automatización
Reglas, analítica y modelos convierten datos en propuestas o acciones. Cada decisión material conserva variables, versión, motivo, autoridad y resultado. La automatización del flujo de trabajo aporta el patrón correcto: estados, responsables y excepciones antes que robots que repiten clics.
7. Gobierno, seguridad y observabilidad
Identidad y acceso, cifrado, secretos, trazas, retención, costes, acuerdos de servicio, incidentes y continuidad atraviesan todas las capas. La organización debe observar tanto la disponibilidad técnica como la salud del consentimiento, la frescura del dato y el resultado de negocio.
Del consentimiento a la operación: el recorrido completo
| Etapa | Entrada | Salida verificable | Excepción típica |
|---|---|---|---|
| 1. Definir finalidad | Producto y necesidad de negocio | Datos y operaciones mínimos permitidos | Solicitud excesiva o finalidad ambigua |
| 2. Seleccionar entidad | Usuario, cuenta y territorio | Conector y recorrido aplicables | Banco no disponible o interfaz degradada |
| 3. Autorizar | Alcance y autenticación | Consentimiento versionado y token limitado | Abandono, rechazo o autenticación fallida |
| 4. Recuperar o iniciar | Petición firmada y contexto | Dato normalizado u operación identificada | Error, límite, duplicado o respuesta parcial |
| 5. Validar | Esquema, procedencia y reglas | Registro aceptado, rechazado o pendiente | Moneda, fecha o titularidad incoherente |
| 6. Aplicar | Regla o proceso interno | Conciliación, alerta, pago o tarea | Revisión humana o sistema interno caído |
| 7. Evidenciar | Eventos y decisiones | Traza completa y métricas | Hueco de auditoría o retención incorrecta |
El onboarding digital ofrece un paralelismo útil: un flujo no termina cuando el usuario autoriza. Termina cuando el sistema interno queda en un estado coherente y la organización puede reconstruir qué ocurrió. La arquitectura explicada en onboarding digital ayuda a diseñar estados, reanudación y excepciones.
Seguridad: proteger la interfaz y el uso posterior
La seguridad de Open Banking no acaba en TLS. Incluye autenticación reforzada cuando corresponde, certificados, autorización por alcance, rotación de secretos, protección frente a repetición, validación de mensajes, límites de uso y segregación. Los estándares técnicos y perfiles como los promovidos por The Berlin Group ayudan a interoperar, pero cada integración necesita pruebas reales.
También debe protegerse el dato después de entrar. El RGPD exige finalidad, minimización, exactitud, seguridad y conservación limitada. El acceso inicial consentido no legitima cualquier reutilización posterior. La empresa debe relacionar cada tratamiento con una finalidad y revocar o degradar capacidades cuando el permiso caduque.
El control no consiste solo en impedir accesos indebidos; consiste en poder demostrar qué dato se usó, con qué permiso, para qué decisión y qué ocurrió después.
Cómo integrar sistemas heredados sin crear otro silo
Muchas empresas disponen de un ERP, un motor de pagos, tesorería y procesos batch que no fueron diseñados para eventos bancarios en tiempo casi real. Reemplazarlos antes de empezar suele ser innecesario. Puede introducirse una capa de servicios que normalice eventos, mantenga el estado de las operaciones y publique contratos estables.
- Adaptadores en el borde. Absorben diferencias externas sin contaminar el dominio interno.
- Modelo canónico. Representa cuentas, movimientos, consentimientos y pagos con semántica propia.
- Eventos y colas. Desacoplan tiempos y permiten reintentos controlados.
- Reconciliación. Compara el estado externo, el interno y el contable.
- Idempotencia. Evita duplicados mediante claves y estados persistentes.
- Modo degradado. Define qué sigue funcionando cuando un banco o proveedor falla.
Este patrón protege la independencia tecnológica: el negocio se integra con contratos propios y no directamente con cada respuesta de un proveedor. La IA soberana aplica una pregunta equivalente a datos y conectividad: qué dependencias acepta la organización y cuáles debe poder sustituir.
Qué papel puede tener la IA
La IA puede clasificar conceptos, proponer correspondencias, detectar anomalías, resumir expedientes y priorizar excepciones. No debe sustituir reglas contables, permisos ni decisiones que requieren reproducibilidad. En servicios financieros, una salida útil debe estar conectada a fuentes, límites, versiones y supervisión.
| Tarea | Tecnología preferente | Control necesario |
|---|---|---|
| Normalizar formatos | Esquemas y reglas | Validación determinista y rechazo explícito |
| Conciliar movimientos | Reglas más modelos de similitud | Umbral, explicación y cola de excepción |
| Detectar anomalías | Analítica o machine learning | Línea base, deriva, falsos positivos y revisión |
| Explicar un estado | IA generativa con fuentes | Citas, permisos y lenguaje no vinculante |
| Prever liquidez | Modelos predictivos | Horizonte, error, escenarios y responsable |
| Ejecutar una acción | Workflow o agente limitado | Permisos mínimos, aprobación y registro |
La pieza sobre inteligencia artificial en finanzas desarrolla este criterio: control antes que automatización. En Open Banking, la misma regla evita convertir datos consentidos en decisiones opacas.
Construir, comprar o combinar
| Opción | Cuándo encaja | Ventaja | Riesgo |
|---|---|---|---|
| Proveedor agregado | Cobertura rápida de muchas entidades | Menor esfuerzo inicial | Dependencia, coste variable y caja negra operativa |
| Integración directa | Pocas entidades estratégicas y gran volumen | Control y optimización específica | Mantenimiento regulatorio y técnico elevado |
| Plataforma propia | Capacidad central reutilizada por varios productos | Gobierno y contratos internos consistentes | Inversión y operación continuas |
| Modelo híbrido | Cobertura amplia con conectores críticos propios | Equilibra velocidad y control | Necesita una capa canónica realmente independiente |
La selección debe comparar cobertura real, calidad, latencia, consentimiento, soporte, portabilidad, datos derivados, residencia, seguridad, costes y salida contractual. Una prueba de concepto con respuestas perfectas no evalúa reintentos, discrepancias, revocaciones ni continuidad.
Hoja de ruta para implantar Open Banking
| Fase | Pregunta | Entregable |
|---|---|---|
| 1. Línea base | ¿Qué proceso y resultado se quiere mejorar? | Tiempos, errores, coste, riesgo y volumen actuales |
| 2. Finalidad y alcance | ¿Qué dato u operación es imprescindible? | Mapa de propósito, permisos y retención |
| 3. Arquitectura mínima | ¿Qué capas y sistemas intervienen? | Contratos, estados, sistemas autoritativos y excepciones |
| 4. Proveedor y pruebas | ¿Cómo se comporta en casos reales? | Matriz de cobertura, fallos, seguridad y portabilidad |
| 5. Piloto operativo | ¿Mejora frente a la línea base? | Flujo medido con casos normales y degradados |
| 6. Industrialización | ¿Cómo se opera y cambia? | SLA, observabilidad, soporte, incidentes y versiones |
| 7. Reutilización | ¿Qué capacidad sirve al siguiente producto? | Servicios comunes, conectores y gobierno |
El piloto debe incluir consentimiento retirado, credencial caducada, banco indisponible, respuesta duplicada, cuenta sin movimientos, operación pendiente y fallo interno posterior. Si el diseño solo funciona en el camino feliz, todavía no existe una capacidad operativa.
Cómo medir valor y ROI
El retorno es una hipótesis contra una línea base. Debe incluir proveedor, integración, seguridad, operación, soporte, revisión manual, incidentes y cambios normativos. El objetivo no es maximizar llamadas a la API, sino mejorar un resultado sin degradar control ni experiencia.
| Dimensión | Línea base | Señal de mejora |
|---|---|---|
| Negocio | Conversión, cobro, liquidez o tiempo de alta | Mejor resultado en el proceso elegido |
| Operación | Horas manuales, colas y retrabajo | Menor esfuerzo por caso y excepción |
| Dato | Errores, duplicados y antigüedad | Mayor calidad y frescura útil |
| Tecnología | Latencia, disponibilidad y fallos | Servicio estable y recuperable |
| Riesgo | Fraude, incidencias y decisiones corregidas | Mejor discriminación con razones |
| Experiencia | Abandono, reautenticaciones y contactos | Menos fricción evitable |
| Economía | Coste total por operación | Coste sostenible al escalar |
| Gobierno | Tiempo para reconstruir un evento | Evidencia completa y accesible |
Errores que convierten Open Banking en otra integración frágil
- Empezar por el proveedor. La herramienta define el producto y no al revés.
- Pedir todos los datos. Más alcance aumenta exposición sin garantizar utilidad.
- Acoplar el canal. La lógica queda atrapada en una aplicación concreta.
- Ignorar estados asíncronos. Pendiente, rechazado o revocado se tratan como error genérico.
- No reconciliar. El estado externo y el interno divergen silenciosamente.
- Automatizar sin razones. Una puntuación se convierte en decisión sin autoridad clara.
- Medir solo disponibilidad. La API responde, pero el dato llega tarde o no sirve.
- No diseñar salida. Cambiar de proveedor obliga a reconstruir todos los productos.
De conexión bancaria a capacidad financiera reutilizable
Open Banking crea valor cuando el consentimiento y la conectividad se convierten en procesos fiables. Eso exige una arquitectura que separe experiencia, identidad, APIs, datos, integración, decisiones y gobierno; y un modelo operativo capaz de gestionar excepciones, cambios y dependencia de terceros.
OpenSistemas trabaja datos, integración, automatización e IA como capacidades empresariales. El punto de partida útil es seleccionar un proceso concreto —por ejemplo conciliación, tesorería o alta—, medir su línea base y diseñar el contrato operativo que conecta bancos, sistemas y decisiones sin perder control.
GUÍA PARA COMITÉS DE DIRECCIÓN
¿Cómo pasar de los pilotos de IA a una capacidad operativa real?
Una guía para estructurar la conversación sobre adopción de IA empresarial antes de la próxima inversión.
Descargar la guíaPreguntas frecuentes sobre Open Banking
¿Qué es Open Banking?
Open Banking es un modelo que permite compartir datos bancarios o iniciar pagos mediante APIs, con consentimiento y controles aplicables. Para una empresa, requiere integrar identidad, permisos, datos, sistemas y operación. No equivale solo a agregar cuentas ni convierte automáticamente a un integrador en proveedor regulado.
¿Qué diferencia hay entre Open Banking y Open Finance?
Open Banking se desarrolló alrededor de cuentas de pago, información e iniciación de pagos. Open Finance amplía el principio de intercambio controlado a otros productos financieros. El alcance concreto depende del marco vigente, el país y los participantes; no existe una implantación idéntica en todos los mercados.
¿Qué sistemas debe integrar una arquitectura de Open Banking?
Suele conectar experiencia digital, identidad, consentimiento, conectores bancarios, gestión de APIs, datos, tesorería, pagos, ERP, CRM, fraude y observabilidad. La prioridad es definir sistemas autoritativos, contratos de datos, estados e idempotencia para reanudar operaciones sin duplicar pagos o registros.
¿Cómo se protege el consentimiento y los datos?
Se registra finalidad, alcance, identidad, tercero, duración y revocación; se aplican permisos mínimos, cifrado, trazas y retención. El dato recibido conserva procedencia y uso permitido. Un consentimiento inicial no justifica cualquier tratamiento posterior, por lo que cada proceso debe vincularse a una finalidad y política verificables.
¿Conviene integrar bancos directamente o usar un agregador?
Depende de cobertura, volumen, control, velocidad, coste y capacidad operativa. Un agregador acelera la cobertura; la conexión directa permite optimizar interfaces estratégicas. Muchas organizaciones usan un modelo híbrido con una capa canónica propia para evitar que productos y sistemas dependan del formato de un único proveedor.
¿Cómo se mide el ROI de Open Banking?
Se compara el proceso con una línea base: tiempo, trabajo manual, errores, conversión, riesgo, experiencia y coste total. Deben incluirse licencias, llamadas, integración, seguridad, soporte, revisión e incidentes. El retorno es una hipótesis verificable y puede variar por banco, producto, segmento y caso de uso.
Fuentes y documentación consultada
- Comisión Europea: paquete sobre pagos y acceso a datos financieros.
- Comisión Europea: marco de acceso a datos financieros.
- EUR-Lex: Directiva (UE) 2015/2366, PSD2.
- EUR-Lex: Reglamento General de Protección de Datos.
- Autoridad Bancaria Europea: grupo de trabajo sobre APIs bajo PSD2.
- Banco de España: evidencia sobre el efecto de Open Banking en proveedores fintech.
- The Berlin Group: especificaciones NextGenPSD2.
- BBVA: funcionamiento y aplicaciones de Open Banking.
- TrueLayer: guía de Open Banking.
- GFT: estructura de la arquitectura de Open Banking.
- Enable Banking: particularidades técnicas del mercado español.
