Banca y
sistemas
legados:
Cuando el riesgo no es solo COBOL, sino perder el conocimiento que mantiene el core.
01En banca, modernizar un sistema legado no consiste en trasladar código de una plataforma a otra. El verdadero reto está en preservar el comportamiento de un sistema donde décadas de reglas de negocio, dependencias y conocimiento operativo pueden estar concentradas en tecnologías que siguen procesando transacciones críticas.
El problema tiene una dimensión económica. Una referencia de IDC citada en estudios de modernización sitúa en más de 78% la proporción del presupuesto de TI que algunas organizaciones destinan al mantenimiento de sistemas legados. El dato debe manejarse como una estimación y no como una constante para todos los bancos.
Lo importante es el patrón: cuanto mayor es la proporción del presupuesto dedicada a mantener el core, menor es la capacidad disponible para financiar nuevos productos, mejorar canales o responder a competidores digitales.
A esto se suma un problema demográfico.
Migrar un core bancario hace visible esa complejidad. Un programa COBOL puede depender de COPYBOOKs compartidos, JCL, transacciones CICS, archivos VSAM, IMS o DB2, codificación EBCDIC, campos COMP-3, ventanas batch y rutinas de cálculo que dependen de aritmética decimal exacta. Una migración que convierta indiscriminadamente esos cálculos a punto flotante puede introducir diferencias que no parecen relevantes en una prueba superficial, pero sí afectan saldos, intereses, comisiones o conciliaciones.
La seguridad agrega otra tensión. Las instituciones tienen que atender vulnerabilidades, requisitos regulatorios y cambios en componentes de canales o middleware, pero un parche puede modificar una dependencia de la que dependen decenas de procesos. Cuando no existe un mapa confiable de dependencias ni pruebas que caractericen el comportamiento actual, el cambio se vuelve una apuesta. Esa es una de las razones por las que el legado permanece: no necesariamente porque la institución ignore el problema, sino porque no puede demostrar con suficiente evidencia qué dejará de funcionar después de modificarlo.
Los incidentes de los últimos años muestran el costo de abordar la transformación como un evento único. En mayo de 2018, Banco de Chile sufrió un ataque en el que un malware utilizado como distracción dejó inoperables miles de equipos mientras los atacantes realizaron transferencias fraudulentas por aproximadamente 10 millones de dólares mediante SWIFT. El Fondo Monetario Internacional resume el incidente señalando que el banco desconectó alrededor de 9,000 estaciones y suspendió operaciones en cerca de 400 sucursales durante aproximadamente dos semanas. El caso es relevante porque demuestra que una interrupción en una capa de infraestructura puede utilizarse para ocultar actividad sobre otra capa crítica.
El otro caso es TSB, en Reino Unido. En abril de 2018, la migración de sus servicios a una nueva plataforma provocó problemas de acceso que afectaron hasta 1.9 millones de usuarios digitales. La propia investigación posterior señaló problemas técnicos de configuración que no fueron detectados antes de la migración. El episodio se convirtió en un ejemplo de los riesgos de concentrar el cambio en una sola transición de gran escala.
Por eso una estrategia de Legacy Migration bancaria necesita separar descubrimiento, validación y sustitución. La ingeniería inversa con agentes parte del código existente y produce artefactos como el mapa de dependencias y la extracción de reglas de negocio. El objetivo no es decir que “la IA entiende el código”, sino utilizar agentes para acelerar la producción de artefactos que después son revisados por ingeniería.
La clonación de legados permite construir una implementación nueva contra la cual se pueda comparar el comportamiento del sistema original. Los characterization tests fijan casos existentes antes de modificar la lógica. Después, el replay de transacciones utiliza tráfico real capturado en producción para reproducir operaciones representativas sobre el clon.
La comparación debe ser semántica. En un mainframe, EBCDIC, COMP-3, timestamps y ordenamientos internos pueden hacer que dos representaciones binarias sean diferentes aunque el resultado de negocio sea equivalente. Por eso se requiere normalización previa y tolerancias declaradas según el tipo de dato. Un saldo, una fecha de valor, una comisión o un estado de cuenta se comparan por sus reglas de negocio y no por la identidad física de los bytes.
El criterio de salida tampoco debe expresarse como una “equivalencia matemática” abstracta. Debe definirse mediante cobertura de casos por regla de negocio, umbrales de discrepancias aceptadas y criterios de corte acordados con el cliente. Esa evidencia permite decidir cuándo un módulo puede recibir tráfico real y cuándo debe permanecer en coexistencia.
El patrón Strangler Fig permite aplicar esa lógica módulo por módulo. Una fachada o proxy dirige una proporción controlada de tráfico al sistema nuevo; el porcentaje puede incrementarse conforme los resultados cumplen los criterios definidos. Si un módulo presenta una discrepancia, el rollback afecta ese componente sin obligar a regresar toda la plataforma.
La ventaja no es únicamente técnica. La modernización de banca tiene un efecto directo sobre el negocio. Bain documentó el caso de una institución italiana que, al modernizar la capa de distribución e integración alrededor de su mainframe, redujo el time-to-market de actualizaciones de productos de 39 a 19 días. Ese tipo de diferencia importa cuando fintechs y bancos digitales lanzan mejoras con ciclos mucho más cortos. La experiencia del cliente también entra en la ecuación: una institución puede tener un core robusto y, al mismo tiempo, perder competitividad si cada cambio digital depende de un ciclo largo y riesgoso sobre sistemas centrales.
Mapear dependencias, extraer reglas, caracterizar comportamiento, reproducir transacciones, validar equivalencia funcional y migrar por módulos. Así, el problema demográfico deja de ser únicamente una discusión sobre cuántos especialistas quedan disponibles y se convierte en una razón concreta para capturar ahora el conocimiento que el core necesita para poder evolucionar.
Fuentes de respaldo para revisión editorial
- IDC, estimación sobre mantenimiento de sistemas legados superior al 78% del presupuesto de TI, citada en Future of Enterprise / CIO & Leader.
- Samy Khatib, KTH Royal Institute of Technology, “COBOL-skills, Where art Thou? An assessment of future COBOL needs at Handelsbanken”, 2016.
- Fondo Monetario Internacional, Global Financial Stability Report 2024, capítulo sobre riesgo cibernético y Banco de Chile.
- TSB Bank, publicación sobre la revisión independiente de la migración de 2018.
- Bain & Company, caso de modernización bancaria y reducción de time-to-market de 39 a 19 días.
Banca y sistemas legados: cuando el riesgo es perder el conocimiento que mantiene el core.
Datos duros, implicaciones arquitectónicas y preguntas de decisión para llevar la conversación de contenido a comité ejecutivo.
Qué cambia para un CTO / CIO
Los casos muestran dos riesgos diferentes pero conectados: migrar mal y operar un entorno cuya complejidad impide responder. El control está en conocimiento verificable y transición progresiva.
- TSB demuestra que “testing realizado” no equivale a riesgo controlado: configuración, capacity y governance también importan.
- Banco de Chile muestra cómo una disrupción de infraestructura puede coexistir con fraude en otra capa.
- Bain documenta que modernizar capas alrededor del mainframe puede reducir time-to-market sin un core replacement total.
La ventaja no es únicamente técnica. La modernización de banca tiene un efecto directo sobre el negocio. Bain documentó el caso de una institución italiana que, al modernizar la capa de distribución e integración alrededor de su mainframe, redujo el time-to-market de actualizaciones de productos de 39 a 19 días. Ese tipo de diferencia importa cuando fintechs y bancos digitales lanzan mejoras con ciclos mucho más cortos. La experiencia del cliente también entra en la ecuación: una institución puede tener un core robusto y, al mismo tiempo, perder competitividad si cada cambio digital depende de un ciclo largo y riesgoso sobre sistemas centrales.
La modernización no se mide por cuántas líneas se reescriben. Se mide por cuánta incertidumbre se elimina: dependencias conocidas, comportamiento fijado, evidencia de equivalencia, coexistencia controlada y rollback real.
Preguntas que deberían estar en el steering committee
| Pregunta ejecutiva | Por qué importa |
|---|---|
| ¿Qué evidencia de readiness ve el board antes del corte? | Evita green status sin cobertura real. |
| ¿Qué capacidad puede modernizarse alrededor del core? | Entrega valor antes del ledger. |
| ¿Qué escenarios de capacity están probados? | Evita fallas bajo carga. |
| ¿Qué rollback existe por capability? | Reduce riesgo sistémico. |
Un marco de 90 días para pasar de narrativa a evidencia
Inventario y priorización
Aplicaciones, owners, dependencias, soporte, datos, criticidad y primer heatmap. Seleccionar un flujo con valor visible y blast radius controlable.
Characterization y arquitectura
Fijar comportamiento, preparar replay, mapear dependencias y diseñar coexistencia, observabilidad y rollback.
Prueba operativa
Ejecutar shadow / dual-run o tráfico limitado, clasificar diferencias y entregar al comité evidencia para escalar o corregir.
El costo de esperar rara vez crece de forma lineal. Suele saltar cuando coinciden fin de soporte, auditoría, temporada alta, nueva regulación, una vulnerabilidad crítica o la salida de una persona clave. El diagnóstico temprano compra opciones.
Extensión editorial: del dato a la decisión.
Lo que los incidentes bancarios enseñan sobre arquitectura y gobierno
TSB es un caso especialmente útil para un comité ejecutivo porque la migración de datos se completó, pero la plataforma sufrió fallas técnicas inmediatamente después. La FCA y PRA impusieron una multa total de £48.65 millones; TSB pagó £32.7 millones en compensaciones y recibió 225,492 quejas relacionadas con el incidente.
La lección no es que las migraciones sean malas. Es que data migration, capacity, configuration, outsourcing, testing y governance deben evaluarse como un solo sistema de riesgo. Banco de Chile muestra otra dimensión. El FMI resume que el ataque de 2018 afectó 9,000 computadoras y 500 servidores; el banco desconectó 9,000 estaciones y suspendió operación en cerca de 400 sucursales durante aproximadamente dos semanas, mientras atacantes realizaron transferencias fraudulentas por unos US$10 millones. En un core bancario, continuidad y ciberseguridad no pueden diseñarse por capas independientes.
El contrapunto positivo está en Bain. Un gran banco italiano modernizó la capa de distribución, creó una capa de integración basada en APIs alrededor del core legacy y reconstruyó archivos de información de clientes. El resultado: el tiempo de actualización de productos bajó de 39 a 19 días. No hizo falta empezar por reemplazar todo el core para capturar valor.
Métricas que un CTO bancario debería exigir
Cobertura de reglas críticas por test; porcentaje de transacciones con replay representativo; diferencias por millón de transacciones durante dual-run; latencia p95/p99; conciliaciones pendientes; tiempo de rollback; dependencias de key-person; vulnerabilidades sin ruta de actualización; y lead time de producto. El objetivo es conectar resiliencia con time-to-market.
En estrategia strangler fig core bancario, el orden de extracción importa. Consulta, límites, notificaciones o pricing periférico pueden convertirse en laboratorios de evidencia antes de acercarse al ledger. Cada frontera nueva debe reducir acoplamiento y aumentar trazabilidad.
Fuentes de datos
Los datos se incluyen como contexto editorial. No se extrapolan como resultados garantizados para un cliente. Cada business case debe recalcularse con su baseline.
| Fuente | Referencia |
|---|---|
| FCA – TSB fined £48.65m for operational resilience failings | Fuente citada en el artículo |
| IMF – Banco de Chile cyberattack case | Fuente citada en el artículo |
| Bain – bank modernization case, 39 to 19 days | Fuente citada en el artículo |
Roomie puede empezar por un diagnóstico de dependencias, comportamiento y ruta de coexistencia.
Agendar un diagnóstico ↗