Última actualización: 19 de agosto de 2026
A fecha de agosto de 2026, migrar de agregador bancario sin romper el producto exige cinco fases: capa de abstracción propia, integración en paralelo, contraste de datos entre proveedores, reconsentimiento progresivo de usuarios y corte con ventana de reversión. El punto crítico es el reconsentimiento, porque el permiso concedido a un proveedor no se transfiere a otro.
Resumen rápido
- El consentimiento de acceso a cuentas es específico del proveedor autorizado: cada usuario debe volver a autenticarse con el nuevo agregador.
- La migración se ejecuta con los dos proveedores en paralelo y contraste de datos antes de cortar, nunca con sustitución directa.
- Los identificadores internos de cuenta cambian entre proveedores y obligan a mantener una tabla de correspondencia durante la transición.
- El coste dominante no es el desarrollo, sino el porcentaje de usuarios activos que no completan la reconexión.
- Las cláusulas de salida, portabilidad del histórico y duración mínima del contrato anterior condicionan el calendario.
¿Se puede migrar de agregador sin que el usuario note nada?
No de forma completa: el usuario debe autenticarse de nuevo ante su banco para autorizar al nuevo proveedor, porque el artículo 94, apartado 2, de la Directiva (UE) 2015/2366 (PSD2) exige consentimiento explícito del usuario para que un proveedor concreto acceda, trate y conserve sus datos. Lo que sí puede quedar invisible es todo lo demás, incluidos el histórico, las categorías de movimientos y los identificadores que el usuario ve en pantalla.
La consecuencia de diseño es que la migración se convierte en una campaña de producto, no solo en un proyecto técnico. Hay que decidir el mensaje, el momento y el incentivo para que el usuario complete la reconexión, y hay que medir la finalización por segmento y por entidad bancaria.
El escenario más favorable es aprovechar una interacción que el usuario ya tiene previsto realizar, como una renovación periódica de permisos. La renovación de la autenticación reforzada ya obliga a reconectar de forma recurrente: el artículo 10 del Reglamento Delegado (UE) 2018/389 fijó ese plazo en 90 días y el Reglamento Delegado (UE) 2022/2360, de 3 de agosto de 2022 lo amplió a 180 días, vigente a fecha de agosto de 2026.
¿Qué fases tiene una migración de agregador bancario?
La migración tiene cinco fases con criterio de salida verificable en cada una. Saltarse el contraste de datos es el atajo que más incidencias produce después del corte.
| Fase | Objetivo | Criterio de salida | Riesgo si se acelera |
|---|---|---|---|
| Capa de abstracción | Aislar el proveedor detrás de una interfaz propia | El producto no llama a la API del proveedor de forma directa | Cada cambio de proveedor se propaga a todo el producto |
| Integración en paralelo | Nuevo proveedor operativo sin exponerlo a usuarios | Lecturas correctas con cuentas del propio equipo | Errores descubiertos con usuarios reales |
| Contraste de datos | Comparar saldos, movimientos y categorías entre proveedores | Diferencias explicadas y documentadas por entidad | Descuadres detectados por el cliente final |
| Reconsentimiento progresivo | Reconectar usuarios por cohortes | Tasa de reconexión estable y por encima del umbral fijado | Pérdida masiva de conexiones activas |
| Corte y reversión | Apagar el proveedor anterior con posibilidad de volver atrás | Ventana de reversión superada sin incidencias | Sin plan de vuelta atrás ante un fallo grave |
La capa de abstracción es la inversión que determina el coste de todas las migraciones futuras. Conviene construirla incluso si no hay cambio previsto, y el argumento está desarrollado en el análisis de alternativas a TrueLayer y Powens en España.
¿Qué se rompe al cambiar de proveedor?
Se rompen cuatro cosas de forma sistemática: identificadores de cuenta, categorías de movimientos, códigos de error y profundidad de histórico. Ninguna es difícil de resolver por separado, pero todas afectan a datos que el usuario ya ha visto.
- Identificadores de cuenta: cada proveedor genera los suyos, por lo que necesitas tabla de correspondencia entre identificadores antiguos y nuevos para no duplicar cuentas.
- Categorías de movimientos: la clasificación cambia y con ella los informes históricos del usuario. Decide si recategorizas el histórico o si conservas la categoría original por periodo.
- Códigos y semántica de error: la lógica de reintentos y los mensajes al usuario deben reescribirse por completo.
- Profundidad y granularidad del histórico: el nuevo proveedor puede devolver menos meses en algunas entidades, lo que crea huecos visibles en gráficos.
- Deduplicación de movimientos: durante el solapamiento, los dos proveedores devuelven los mismos apuntes y hay que evitar duplicados en base de datos.
- Webhooks y trabajos programados: cambian los eventos disponibles y la frecuencia de refresco permitida.
El apartado de errores merece una revisión previa específica, porque concentra la mayor parte de las incidencias posteriores al corte. El catálogo está en el artículo sobre errores comunes al integrar una API bancaria.
¿Cómo se reconsienten los usuarios ya conectados?
El reconsentimiento se ejecuta por cohortes, empezando por los usuarios más activos y por las entidades con mejor tasa de éxito. Lanzarlo a toda la base al mismo tiempo impide corregir el mensaje y sobrecarga el soporte.
La secuencia que funciona tiene cuatro pasos. Primero, aviso previo explicando el motivo y el beneficio concreto para el usuario. Segundo, reconexión disponible dentro del flujo habitual del producto, no en un correo aislado. Tercero, recordatorio a los que no completan, con límite de insistencia. Cuarto, canal de soporte con guion específico para las entidades que más fricción presentan.
Cada evento debe quedar registrado con alcance, fecha y proveedor, porque el nuevo permiso sustituye al anterior y debe poder acreditarse. Las obligaciones de traza aplicables están recogidas en la guía de RGPD y datos bancarios y en la de gestión de consentimientos de usuario bajo PSD2.
¿Cómo se comprueba que los datos nuevos coinciden con los antiguos?
El contraste se hace sobre una muestra de cuentas leídas por los dos proveedores en la misma ventana temporal, comparando saldo, número de apuntes, suma de importes y fechas. Las diferencias deben explicarse una por una antes del corte.
Las discrepancias legítimas más habituales son tres: distinta profundidad de histórico por entidad, distinto tratamiento de operaciones pendientes frente a contabilizadas y distinta normalización de la fecha valor. Documentar cuál aplica en cada entidad evita que el equipo de soporte trate un comportamiento esperado como una incidencia.
El contraste también sirve para fijar los umbrales del nuevo acuerdo de servicio, porque produce medición propia por entidad. El detalle de qué comprometer está en la guía sobre qué SLA y uptime exigir a un proveedor de datos bancarios.
¿Qué cláusulas del contrato anterior pueden bloquear la salida?
Tres cláusulas condicionan el calendario: duración mínima con penalización por cancelación anticipada, preaviso de terminación y condiciones de portabilidad del histórico. Conviene leerlas antes de negociar con el nuevo proveedor, no después.
- Duración mínima y penalización: determina si conviene solapar contratos o esperar al vencimiento.
- Preaviso de terminación: fija la fecha límite para comunicar la baja sin renovación automática.
- Portabilidad del histórico: formato, plazo de entrega y coste de la exportación de datos.
- Supresión certificada: el artículo 28 del Reglamento (UE) 2016/679 (RGPD) exige que el contrato de encargado prevea la supresión o devolución de los datos al terminar la prestación, y conviene pedir evidencia documentada de que se ha ejecutado.
- Servicio durante la transición: mantenimiento del nivel de servicio hasta la fecha efectiva de baja.
Para el contrato nuevo, la recomendación es incorporar desde el principio la cláusula de salida que habrías querido tener en el anterior. Los puntos negociables están recogidos en el análisis de cuánto cuesta una API de agregación bancaria y en la comparativa de proveedores de open banking.
¿Cuánto dura y cuánto cuesta una migración?
La integración técnica se resuelve en semanas; la migración completa la marca el ritmo de reconexión de la base instalada. Un producto con muchos usuarios activos y refresco continuo tarda varios ciclos de facturación en completar el traspaso.
El presupuesto debe contemplar cuatro partidas: desarrollo e integración, solapamiento de dos contratos, campaña de reconexión y soporte reforzado durante la transición. La partida que suele faltar es la pérdida de conexiones activas de usuarios que no completan el nuevo permiso, que se estima aplicando una tasa de reconexión conservadora al número de usuarios activos. El desglose de fases y plazos está en la guía sobre cuánto tarda integrar open banking.
Preguntas frecuentes
¿Se puede transferir el consentimiento de un agregador a otro?
No. El permiso de acceso a la cuenta se concede a un proveedor autorizado concreto, por lo que cada usuario debe autenticarse de nuevo ante su banco para autorizar al nuevo agregador. Es el factor que marca la duración real de la migración.
¿Hay que mantener los dos proveedores a la vez?
Sí, durante el contraste de datos y el reconsentimiento progresivo. El solapamiento permite comparar resultados y volver atrás si aparece un problema grave, a cambio de pagar dos contratos durante ese periodo.
¿Qué pasa con el histórico de movimientos ya almacenado?
Se conserva en tu base de datos si lo has guardado, y el nuevo proveedor solo aporta el histórico que sus conectores permitan por entidad. Mantén una tabla de correspondencia de identificadores para no duplicar cuentas ni apuntes.
¿Cómo se evita duplicar movimientos durante el solapamiento?
Con una clave de deduplicación propia construida a partir de fecha, importe, concepto y cuenta normalizada. Confiar en el identificador del proveedor produce duplicados en cuanto conviven dos fuentes.
¿Cuánto se pierde de base instalada en una migración?
Depende del canal de reconexión y de la calidad del aviso, por lo que debe medirse por cohortes y no estimarse con una cifra genérica. Planifica con una tasa conservadora y ajústala con los datos de la primera cohorte.
¿Conviene migrar y ampliar alcance al mismo tiempo?
No es aconsejable. Cambiar de proveedor y añadir productos nuevos en el mismo despliegue impide saber qué ha causado un problema. Migra primero con alcance equivalente y amplía después.
Siguiente paso
Una migración de agregador se complica cuando no hay capa propia de abstracción y cuando el reconsentimiento se lanza sin cohortes ni medición. Wealth Reader trabaja con cobertura declarada por entidad y una sola integración para cuentas, tarjetas y productos de inversión, lo que permite contrastar datos frente al proveedor actual antes de cortar. Si estás evaluando un cambio de agregador, solicita una demo de Wealth Reader y plantea la migración por fases.
Criterio propio: qué rompe una migración
La migración se rompe por creer que es un proyecto técnico. La integración se resuelve en semanas; lo que marca el calendario es cuántos usuarios completan la reconexión, y eso depende del canal, del mensaje y del momento en que se les pide. Lanzarlo a toda la base a la vez impide corregir el mensaje y sobrecarga el soporte justo cuando más hace falta.
El segundo fallo es cortar sin contraste. Sin comparar saldo, número de apuntes, suma de importes y fechas entre los dos proveedores sobre las mismas cuentas y la misma ventana temporal, los descuadres los detecta el cliente final. El tercero es no construir la capa de abstracción: quien llama a la API del proveedor desde el producto paga la migración entera cada vez que cambia de agregador.
Fuentes
- Unión Europea (EUR-Lex). Directiva (UE) 2015/2366 sobre servicios de pago en el mercado interior (PSD2). 25 de noviembre de 2015, DO L 337 de 23.12.2015. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32015L2366
- Unión Europea (EUR-Lex). Reglamento Delegado (UE) 2018/389, normas técnicas de autenticación reforzada y comunicación segura. 27 de noviembre de 2017, DO L 69 de 13.3.2018. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32018R0389
- Unión Europea (EUR-Lex). Reglamento Delegado (UE) 2022/2360, por el que se modifica la exención de 90 días para el acceso a las cuentas. 3 de agosto de 2022, DO L 312 de 5.12.2022. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32022R2360
- Unión Europea (EUR-Lex). Reglamento (UE) 2016/679, protección de datos personales (RGPD). 27 de abril de 2016, DO L 119 de 4.5.2016. https://eur-lex.europa.eu/legal-content/ES/TXT/?uri=CELEX%3A32016R0679
Deja un comentario