La arquitectura Frankenstein no es un insulto, es un diagnóstico
Con los años, los equipos internos van pegando módulos nuevos sobre los viejos. Un middleware aquí, un conector allá, un workaround manual para cumplir con una norma que llegó sin aviso. Jouk Pleiter, CEO de Backbase, describe este patrón como arquitectura Frankenstein en su libro AI Waits For No Bank: un stack armado por capas que solo se hacen visibles cuando algo se rompe.
Cada capa resolvió un problema puntual en su momento. Juntas, forman un sistema que ya nadie entiende por completo, y que se vuelve más caro de tocar con cada año que pasa.
Este diagnóstico cambia la pregunta. Ya no es si construir o comprar. Es cuánto tiempo más se puede seguir parchando antes de que el costo de mantenimiento supere el valor de seguir operando así.
Por qué la migración de big bang casi siempre falla
La tentación, una vez que se reconoce el problema, es reemplazar todo de una vez. Migrar el código completo hacia una plataforma nueva en un solo proyecto grande. McKinsey advierte que menos del 30% de las transformaciones de core banking logran completar la migración total en la última década, y los bancos suelen subestimar el tiempo requerido por hasta un 75%.
Un big bang también arriesga algo que rara vez se mide en la hoja de cálculo: el conocimiento de negocio que ese equipo interno acumuló durante años. Reescribir todo desde cero con un proveedor externo significa empezar esa curva de aprendizaje otra vez, mientras la operación diaria sigue corriendo.
Migrar journey por journey, no todo de una vez
La alternativa que McKinsey documenta como la más elegida por los bancos es la modernización progresiva. Mantener el core actual y construir alrededor de él, migrando la lógica de negocio hacia una capa moderna un dominio a la vez.
En la práctica, esto significa elegir un journey (onboarding, servicio al cliente, resolución de disputas), migrar su lógica fuera del código monolítico, y probar el resultado antes de tocar el siguiente. Es el mismo motivo por el que tantos pilotos de IA en banca fallan: se construyen sobre una base fragmentada, sin coordinación entre lo que cada sistema ya sabe del cliente.
El mercado ya está reaccionando a esta presión. Tres adquisiciones recientes muestran hacia dónde se mueve la interfaz de cliente en banca, y confirman que la competencia ya no se define solo por el core, sino por quién controla la ejecución sobre él. Si tu banco está considerando proveedores, es fundamental comparar Backbase con alternativas como Temenos antes de asumir que una migración completa es la única vía viable.
El Control Plane: Banking OS, Nexus y Sentinel sin tocar el core
Migrar journey por journey solo funciona si hay algo que coordine el trabajo entre el código viejo y el nuevo. Ese algo es lo que Backbase llama Banking OS: un Control Plane que se ubica sobre los sistemas de registro y coordina la ejecución, sin reemplazar el core, el CRM ni las plataformas de datos que ya existen.
Nexus, la capa semántica del Banking OS, le da a cada sistema y a cada agente la misma versión de la verdad sobre el cliente, el llamado Customer State Graph. Sentinel, la capa de autoridad, exige un Decision Token antes de que cualquier acción se ejecute, así el proceso migrado no pierde control ni trazabilidad frente al regulador.
Vale la pena entender la diferencia entre un Control Plane real y una capa de inteligencia artificial superpuesta sin coordinación de fondo. La comparación entre un Banking OS nativo en IA y una plataforma solo potenciada por IA explica por qué esa distinción importa tanto al momento de migrar, y este resumen sobre las plataformas de IA bancaria líderes en 2026 ayuda a comparar opciones sin caer en promesas vacías.
Quién decide esto en tu banco, y cómo empezar
Esta decisión rara vez la toma una sola persona. El CTO define la arquitectura, el CIO responde por la continuidad operativa, y el jefe de arquitectura tiene que garantizar que cada migración use el mismo patrón. Todos necesitan el mismo dato de partida: cuánto cuesta hoy mantener cada journey, y cuánto tiempo toma lanzar un cambio sobre él.
Ese dato, más que cualquier debate filosófico sobre construir versus comprar, es el que arranca la conversación con el directorio. Si tu equipo todavía está definiendo el criterio para decidir qué mantener internamente y qué migrar hacia una base compartida, la guía [ENLACE A LA GUÍA] ofrece un marco práctico para tomar esa decisión journey por journey.
La industria ya dejó atrás la pregunta de construir o comprar desde cero. La pregunta ahora es qué tan rápido puede un banco retirar, un dominio a la vez, las partes de su stack que nadie se atreve a tocar. Empieza por auditar el journey que más cuesta mantener hoy, y migra ese primero.
Preguntas frecuentes
¿Qué significa migrar una app bancaria de desarrollo interno?
Significa mover la lógica de negocio de una app construida por el equipo propio del banco hacia una base moderna, sin reescribir todo de una vez. En vez de un reemplazo total, el banco migra journey por journey mientras el core original sigue operando sin interrupciones.
¿Por qué es tan costoso mantener una app bancaria construida internamente?
Porque cada capacidad nueva se agrega sobre capas anteriores de código, creando lo que se conoce como arquitectura Frankenstein. Con los años, los bancos terminan gastando hasta dos tercios de su presupuesto de digitalización solo en sostener esa deuda técnica, en vez de invertir en productos nuevos.
¿Cómo se migra una app bancaria sin detener las operaciones?
La forma más segura es la modernización progresiva: elegir un journey específico, como onboarding o servicio al cliente, migrar su lógica hacia un Banking OS que actúa como Control Plane sobre el core, y validar resultados antes de avanzar al siguiente dominio. El core sigue funcionando durante todo el proceso.
¿Quién debe liderar la migración de la app bancaria dentro del banco?
La decisión suele ser conjunta entre el CTO, el CIO y el jefe de arquitectura. El CTO define la arquitectura objetivo, el CIO responde por la continuidad y el riesgo operativo, y arquitectura garantiza que cada dominio migrado siga el mismo patrón técnico y de gobierno.
¿Cuáles son los beneficios de migrar hacia un Banking OS en vez de seguir parchando el core?
Un Banking OS reduce el costo de mantenimiento porque coordina el trabajo entre sistemas en vez de agregar más parches. También acelera el lanzamiento de nuevas capacidades, mantiene trazabilidad completa de cada decisión y evita perder el conocimiento de negocio que el equipo interno acumuló durante años.
