Núcleos Auxiliares y Patrón Strangler Fig: La Arquitectura Real de la Modernización Bancaria Progresiva
El patrón de núcleo auxiliar no elimina el riesgo de migración. Reemplaza una sola transición abrupta por un requisito de reconciliación continuo que persiste durante toda la duración de la ejecución en paralelo, que en la mayoría de los programas de modernización bancaria dura entre dos y cinco años. Los bancos que tratan al núcleo auxiliar como un piloto controlado y añaden la reconciliación en una fase posterior descubren consistentemente el problema en el orden equivocado: las brechas de reconciliación aparecen después de que los datos han estado viajando a través de dos sistemas durante meses.
El 40% de los bancos siguen estrategias de núcleo auxiliar a mediados de 2026, con una proyección del 70-80% para 2028. El 85% de las instituciones financieras reportan planes para inversiones de transformación del núcleo de gran envergadura (KPMG European Banking Outlook 2026). La industria ha aceptado que el reemplazo Big Bang es demasiado arriesgado. Si se debe operar un núcleo auxiliar ya no es una decisión abierta. Lo que importa es si la arquitectura del núcleo auxiliar incluye la infraestructura de reconciliación necesaria para operar dos núcleos financieros en paralelo sin acumular estado irreconciliable.
Por Qué Falló el Reemplazo Big Bang
La migración de TSB en 2018 es la referencia canónica. TSB intentó migrar 5,2 millones de clientes de la plataforma del Lloyds Banking Group a su nuevo núcleo Proteo4UK en un solo fin de semana. La migración produjo una interrupción de 18 días que afectó a 1,9 millones de clientes, bloqueó a los clientes de sus propias cuentas, expuso a algunos clientes los datos de transacción de otros clientes y costó a TSB más de GBP 330 millones en remediación, compensación y sanciones regulatorias. La FCA y PRA del Reino Unido impusieron sanciones adicionales de GBP 48,65 millones en 2023.
La causa estructural no fue un solo error. Fue la imposibilidad de validar la equivalencia de comportamiento completa de dos sistemas en un entorno de prueba contra cinco años de datos de producción, estados de clientes e historial de transacciones de casos límite. TSB probó la migración extensivamente. El entorno de producción reveló interacciones que ninguna matriz de prueba había previsto.
Cada reemplazo de core banking a gran escala que ha intentado un solo cambio de fin de semana ha visto el mismo tipo de problema. El comportamiento del sistema heredado no está completamente documentado. El comportamiento del nuevo sistema bajo carga de producción difiere de su comportamiento bajo carga de prueba. El estado del cliente en el momento del cambio contiene casos límite que las pruebas previas a la migración no cubrieron.
La arquitectura de núcleo auxiliar evita el cambio de fin de semana único. Introduce una clase diferente de problema.
El Problema del Cerebro Dividido
Cuando dos núcleos operan simultáneamente contra datos de clientes superpuestos, se convierten en posibles fuentes de verdad contradictoria. La cliente Alice tiene una cuenta en el núcleo heredado (donde residen sus mandatos de domiciliación, domiciliaciones e historial de transacciones) y en el núcleo auxiliar moderno (donde residen sus nuevas cuentas y productos nuevos). Cuando se deposita el salario de Alice, va a la cuenta heredada. Cuando paga una suscripción con el nuevo producto, va a la cuenta auxiliar. Su saldo total disponible es la suma de ambos, pero ninguno de los núcleos conoce el panorama completo.
El problema del cerebro dividido tiene tres dimensiones.
Visibilidad de saldo. La cliente ve un saldo que depende de qué cuenta del sistema consulta. Los agentes de servicio al cliente deben consultar ambos sistemas para responder "¿cuál es mi saldo total?" Cada consulta de saldo orientada al cliente que toca ambos sistemas requiere una operación de unión sobre dos núcleos que pueden no tener su estado sincronizado en el momento de la consulta.
Historial de transacciones. Una cliente que disputa un débito debe poder reconstruir su historial completo de transacciones independientemente de qué núcleo las procesó. Una traza de auditoría que dice "sus transacciones antes de [fecha] están en el sistema heredado; sus transacciones después de [fecha] están en el nuevo sistema" no es un historial completo. Es un particionamiento de dos registros incompletos.
Estado de compliance. Los registros CDD, indicadores AML, designaciones PEP y resultados de screening de sanciones deben ser consistentes a través de ambos núcleos. Si una cliente está marcada en el sistema heredado pero el auxiliar no ha recibido ese indicador, el auxiliar puede procesar transacciones que el sistema heredado habría bloqueado. El Artículo 14 de AMLD5 requiere que los resultados CDD se apliquen consistentemente en todas las líneas de producto, un requisito que se viola estructuralmente cuando los dos núcleos no comparten su estado de compliance en tiempo real.
Reconciliación como Componente Arquitectónico de Primera Clase
El enfoque correcto es tratar la reconciliación como un componente estructural de la arquitectura del núcleo auxiliar, no como un proceso operativo añadido después del despliegue.
Sincronización basada en eventos. Cada cambio de estado en cualquiera de los núcleos se publica como un evento en un log de eventos compartido. El log de eventos es el registro autoritativo de lo que ocurrió, en qué orden. Tanto el núcleo heredado como el auxiliar moderno consumen este log de eventos. Sus estados se derivan de la misma secuencia de eventos. La reconciliación no es una comparación de dos estados independientes. Es la verificación de que ambos núcleos aplicaron correctamente la misma secuencia de eventos.
Esto requiere que ambos núcleos soporten la derivación de estado basada en eventos, lo que los núcleos heredados generalmente no hacen. El enfoque práctico para los sistemas heredados es capturar cambios a través de captura de datos de cambios (CDC): monitorear el log de transacciones de la base de datos del núcleo heredado y convertir cambios de estado en eventos. El CDC introduce latencia (segundos a minutos) y requiere manejo cuidadoso de las peculiaridades del modelo de datos heredado: campos no documentados, máquinas de estado implícitas codificadas en columnas de estado, y reglas de negocio que residen en procedimientos almacenados en lugar de en código de aplicación.
Traza de auditoría inmutable a través de ambos núcleos. Cada transacción procesada por cualquiera de los núcleos debe registrarse en un log de auditoría inmutable compartido con un esquema de ID de correlación común. Cuando una cliente pregunta "¿qué pasó con el pago X?", la respuesta debe ser recuperable desde el log compartido independientemente de qué núcleo la procesó. El log compartido no es una base de datos de reportes que ambos núcleos agregan periódicamente. Es un journal de write-ahead en el que ambos núcleos escriben antes de ejecutar cambios de estado.
Capacidad de retroceso a granularidad de segmento de producto. El patrón Strangler Fig migra clientes o segmentos de producto incrementalmente del núcleo heredado al auxiliar moderno. Si la migración de un segmento de producto revela una diferencia de comportamiento donde el núcleo moderno maneja un caso límite específico de manera diferente al núcleo heredado, la arquitectura debe soportar retroceder ese segmento al núcleo heredado sin pérdida de datos.
El retroceso requiere que el estado del núcleo moderno sea un superconjunto de lo que el núcleo heredado habría tenido para las mismas transacciones. Si el núcleo moderno ha procesado transacciones que el núcleo heredado no puede representar (porque el modelo de datos heredado no soporta el nuevo tipo de cuenta, o el motor de workflow heredado no puede reproducir la secuencia de eventos), el retroceso no es posible. Esto debe verificarse antes de la migración de cada segmento, no descubrirse durante el intento de retroceso.
El Strangler Fig a Granularidad de Producto
El patrón Strangler Fig, nombrado después de la higuera que crece alrededor de un árbol hospedero y lo reemplaza gradualmente, migra funcionalidad incrementalmente. En core banking, la granularidad más efectiva para el Strangler Fig es el segmento de producto: migrar un tipo de producto a la vez, comenzando con la adquisición de nuevos clientes (los nuevos clientes obtienen el núcleo moderno; los clientes existentes permanecen en el núcleo heredado hasta que se migren explícitamente).
La migración de segmento de producto con adquisición de nuevos clientes tiene una ventaja específica: los nuevos clientes no tienen estado histórico en el núcleo heredado. No hay datos de clientes para migrar, ni historial de transacciones para reconciliar, ni mandatos de domiciliación para transferir. La carga de reconciliación para segmentos de nuevos clientes se limita a verificar que el núcleo auxiliar procesa correctamente productos que el núcleo heredado nunca procesó.
La carga de reconciliación aumenta cuando se migran segmentos de clientes existentes. Cada cliente existente trae estado histórico: historial de transacciones, configuraciones de producto, mandatos de domiciliación, domiciliaciones, registros CDD, indicadores AML y procesos en curso (pagos pendientes, disputas abiertas, transferencias programadas). La migración de clientes existentes requiere:
- Extracción del estado actual completo de cada cliente del núcleo heredado.
- Verificación de que el modelo de datos del núcleo moderno puede representar cada elemento de ese estado sin pérdida.
- Transformación del estado heredado al formato del núcleo moderno.
- Carga del estado transformado en el núcleo moderno.
- Operación paralela de ambos núcleos durante un período de verificación, comparando las salidas para las mismas entradas.
- Cambio del tráfico orientado al cliente al núcleo moderno.
- Retención del núcleo heredado en modo de solo lectura durante un período definido para manejar disputas que hacen referencia a datos históricos.
El paso 5 es donde la mayoría de los programas subestiman el esfuerzo. El período de verificación requiere generar entradas de transacciones idénticas contra ambos núcleos y comparar las salidas con cobertura suficiente para tener confianza de que la equivalencia de comportamiento se mantiene en casos límite, no solo para el camino feliz, sino para condiciones de error, transacciones R, actualizaciones concurrentes y eventos activados regulatoriamente. Esto no puede lograrse ejecutando un conjunto de pruebas. Requiere la reproducción simultánea de patrones de tráfico de producción contra ambos sistemas.
El Contexto del CAGR del 14%
El despliegue en la nube en el sector bancario europeo crece con un CAGR del 14% (KPMG 2026). Los modelos SaaS y de core banking alojados han alcanzado una cuota de mercado del 67,5%. El mercado se está desplazando desde sistemas de tercera generación con vendor lock-in hacia núcleos componibles de cuarta generación con APIs abiertas y modelos de despliegue cloud-native.
Este desplazamiento significa que la mayoría de los bancos que actualmente operan programas de núcleo auxiliar están evaluando núcleos modernos construidos específicamente para despliegue en la nube, con arquitecturas basadas en eventos, modelos de datos nativos ISO 20022 y contratos de API estándar. El desafío de reconciliación es menor cuando ambos núcleos hablan el mismo lenguaje de datos: cuando las transacciones del núcleo heredado pueden clasificarse con códigos BankTransactionCode de ISO 20022 y el núcleo moderno usa la misma clasificación de forma nativa, el match de reconciliación es estructural en lugar de heurístico.
La brecha de reconciliación es más amplia cuando el núcleo heredado usa códigos de transacción propietarios, identificadores de cuenta propietarios y contratos de API propietarios, y el núcleo moderno usa estándares ISO de manera completa. Cada match de reconciliación entre estos dos sistemas requiere una capa de traducción, y cada capa de traducción es una carga de mantenimiento y una fuente potencial de discrepancia.
Compromisos
La modernización progresiva a través de núcleo auxiliar introduce costos que el reemplazo Big Bang evita, y evita costos que el reemplazo Big Bang crea.
Sobrecarga operativa continua. Operar dos núcleos en producción duplica la superficie operativa: monitoreo, respuesta a incidentes, planificación de capacidad y parches de seguridad deben cubrir ambos sistemas. Para instituciones que ya operan con poco personal en operaciones de core banking, duplicar la superficie operativa sin aumentar la dotación de personal crea riesgo.
Ventana de consistencia. La sincronización basada en eventos introduce una ventana de latencia entre un cambio de estado en un núcleo y su propagación al otro. Durante esta ventana, los dos núcleos pueden reportar diferentes estados para el mismo cliente. Para fines de compliance, la ventana debe estar acotada y documentada: los reguladores esperan que las instituciones conozcan el retraso máximo en su arquitectura de doble núcleo y hayan evaluado su impacto en las obligaciones de compliance.
Incompatibilidades de modelo de datos. Los núcleos heredados fueron construidos con modelos de datos que precedieron a ISO 20022, PSD2 y GDPR. La migración de datos de clientes desde un modelo heredado a uno moderno requiere manejar campos faltantes (registros de consentimiento GDPR que el núcleo heredado no rastrea), discrepancias estructurales (enumeraciones de códigos de transacción propietarias que no mapean limpiamente a códigos ISO 20022) y ambigüedades semánticas (columnas de estado que codifican reglas de negocio que ya no están documentadas en ningún lugar).
Fernel Context
La arquitectura de Fernel está diseñada desde su descomposición inicial de capas para el despliegue de núcleo auxiliar. Las tres capas estrictamente aisladas (el motor de ledger, el motor de orquestación y la capa de dominio) operan independientemente. Un banco que opera un núcleo auxiliar puede desplegar el motor de ledger de Fernel para segmentos de producto nuevos, mientras retiene el núcleo heredado para clientes existentes, y conectar los dos a través de una capa de sincronización basada en eventos que escribe tanto en el log de transacciones heredado como en el journal de solo apéndice de Fernel. La infraestructura de reconciliación es el log de eventos, no un trabajo de lote periódico: cada cambio de estado en cualquiera de los sistemas es una entrada de journal con una ID de correlación, consultable en cualquier momento.
Leer más: La Arquitectura de un Sistema Operativo Financiero | Reconciliación en Tiempo Real | Workflows, Motor de Ejecución Durable
Fuentes:
- KPMG, European Banking Outlook 2026: 40% adopción de núcleo auxiliar a mediados de 2026, 70-80% proyectado para 2028; 85% planean transformación de gran envergadura; CAGR del 14% de despliegue en la nube; 67,5% cuota de mercado SaaS/alojado
- Fallo de migración de TSB, abril de 2018: GBP 330 millones en costos totales, 1,9 millones de clientes afectados, interrupción de 18 días. Acción de cumplimiento de FCA/PRA del Reino Unido y multa de GBP 48,65 millones (2023)
- ThoughtWorks, "Kill your core: The banking revolution you didn't see coming": principios de arquitectura de coreless banking
- AMLD5, Directiva 2018/843, Art. 14 (Alcance y momento de la verificación CDD, requisito de consistencia)
- Patrón Strangler Fig: Martin Fowler, "StranglerFigApplication" (2004), migración incremental mediante operación de sistemas paralelos
- ISO 20022 BankTransactionCode External Code Sets: el puente de lenguaje de datos para la reconciliación de doble núcleo