Cada cierto tiempo vuelve la misma pregunta: si COBOL nació hace décadas, ¿por qué sigue dentro del corazón de la banca? La respuesta corta no me convence nada cuando se reduce a “porque los bancos van atrasados”. Me parece una explicación pobre. La realidad es bastante más incómoda y, al mismo tiempo, bastante más interesante: COBOL no sigue ahí por romanticismo tecnológico, sino porque todavía sostiene lógica de negocio crítica, corre sobre infraestructuras diseñadas para máxima continuidad y está incrustado en procesos que no se pueden apagar sin consecuencias. IBM define COBOL como un lenguaje de alto nivel orientado al procesamiento de datos empresariales, legible y pensado para ejecutarse en mainframes y otros sistemas operativos; además, recuerda que el lenguaje cumplió 65 años en 2024.
Lo importante, para mí, no es debatir si COBOL “es viejo”, sino entender qué hace todavía en un banco. Cuando una tecnología sigue viva en un entorno tan sensible, normalmente no es porque sea bonita, sino porque resuelve algo que sigue importando: estabilidad, precisión, compatibilidad con décadas de procesos y un coste de sustitución gigantesco. IBM, al hablar de modernización bancaria, explica que muchos bancos arrastran deuda técnica en sus mainframes, que los ingenieros originales ya no están y que la interrupción del negocio simplemente no es una opción. Red Hat, desde el ángulo de modernización, dice algo parecido: reemplazar sistemas heredados de golpe eleva el coste y el riesgo, y por eso la transición suele plantearse por fases.
Qué es COBOL y qué papel juega todavía en la banca
COBOL nació para el mundo empresarial, no para el glamour del desarrollo moderno. Su propia definición ya da una pista de por qué sigue teniendo sentido en ciertos contextos: fue diseñado para procesar grandes volúmenes de datos de negocio y para ser legible por humanos, con una sintaxis cercana al inglés. IBM destaca precisamente esa combinación de legibilidad, mantenimiento y compatibilidad con entornos mainframe como una de las razones por las que COBOL se asentó tan bien en organizaciones grandes.
Cómo encaja COBOL en el core bancario
Cuando hablo del “core bancario”, me refiero a la capa menos visible y más delicada del banco: cuentas, movimientos, conciliaciones, lotes nocturnos, reglas de negocio, integraciones antiguas y piezas que llevan años funcionando sin hacer ruido. Ese silencio operativo, en banca, vale oro. IBM señala que muchos bancos todavía ejecutan su deuda técnica sobre mainframes escritos en COBOL u otros lenguajes anteriores a la era de los sistemas distribuidos, y que precisamente por eso la transformación se retrasa: no porque nadie entienda el problema, sino porque tocarlo mal puede generar una interrupción del negocio.
En otras palabras: COBOL no suele estar en la “app bonita” que ve el cliente, sino en la sala de máquinas que decide qué pasa cuando un pago entra, una tarjeta se valida o un proceso batch cierra el día. Esa es la clave. Mucha gente imagina que modernizar un banco consiste en rediseñar la interfaz móvil, pero el cuello de botella real está debajo. Y debajo, muy a menudo, hay lógica que lleva años probada en producción.
Qué operaciones bancarias siguen dependiendo de sistemas heredados
No todos los bancos dependen igual de COBOL, y no todo lo heredado es automáticamente malo. Pero sí hay una pauta clara: cuanto más crítica y más interconectada está una operación, más probable es que siga apoyándose en componentes legacy. IBM, por ejemplo, explica que en modernización bancaria muchas entidades quieren extraer valor de sus mainframes en un contexto distribuido, no tirarlos a la basura. Y el caso de BBVA Francés muestra justo esa filosofía: en vez de rehacer de cero sus aplicaciones COBOL centrales, optimizó cargas existentes sobre IBM Z para mejorar rendimiento y eficiencia sin reescribir el código fuente.
Un banco no conserva COBOL solo porque “todavía funciona”, sino porque alrededor de ese código hay dependencias, procesos, pruebas, controles y años de ajustes que resultan carísimos de reconstruir. A veces lo más racional no es sustituir, sino encapsular, optimizar y modernizar por capas.
7 razones por las que los bancos siguen usando COBOL
Décadas de lógica de negocio que no se pueden tirar
La primera razón es la más aburrida de contar, pero seguramente la más poderosa: el código bancario viejo no suele ser solo código; es negocio comprimido en miles o millones de reglas. Ahí dentro hay cálculos, excepciones, validaciones y comportamientos que se han refinado durante años. IBM resume muy bien el problema cuando explica que los ingenieros originales muchas veces ya no están y que los bancos retrasan la transformación porque la interrupción del negocio no es una opción. Traducido: no siempre sabes todo lo que romperías al tocar una pieza que lleva décadas conectada a otras.
Fiabilidad para sistemas donde un error cuesta muchísimo
En banca no gana el lenguaje más moderno, sino el sistema que falla menos en los procesos que importan. Por eso COBOL conserva valor en entornos donde la prioridad no es “moverse rápido”, sino sostener operaciones críticas con previsibilidad. Red Hat subraya que cuando los bancos intentan modernizar de una sola vez, los riesgos y los costes se disparan; por eso insiste en reducir el riesgo de la transición antes que prometer una reinvención completa.
Yo aquí haría una distinción importante: que algo sea antiguo no implica automáticamente que sea frágil en producción. Muchas veces ocurre lo contrario. Lo frágil no es el sistema que lleva años comportándose igual, sino el proceso de cambiarlo deprisa sin comprender todas sus dependencias.
Precisión numérica y orientación natural al dato empresarial
Otra razón de peso es que COBOL nació pensando en datos de negocio y cálculos decimales de alta precisión. IBM destaca como una de sus grandes fortalezas el soporte para cálculos decimales de punto fijo de gran precisión, una capacidad que ayudó a impulsar su adopción en instituciones financieras. Para un banco, donde los errores pequeños pueden acumularse y convertirse en problemas muy grandes, esto no es un detalle menor.
No quiero vender la idea simplista de “solo COBOL sabe hacer números”, porque no sería verdad. Lo que sí es verdad es que COBOL se ganó su sitio histórico precisamente en aplicaciones donde el dato financiero, la exactitud y la consistencia eran el centro de todo.
Integración profunda con mainframes y procesos internos
Aquí entra la palabra que suele asustar a quien no es técnico: integración. COBOL no vive aislado; vive unido a mainframes, sistemas operativos, colas, programas batch, bases de datos, monitores transaccionales y procesos que han crecido juntos. IBM insiste en que muchos bancos están intentando modernizar el valor de sus mainframes dentro de arquitecturas más distribuidas, lo que confirma que la discusión real no es “mainframe sí o no”, sino cómo convivir con él mientras el resto del banco cambia.
Ese “mientras” es la palabra decisiva. Porque la banca no se moderniza en un vacío: tiene que seguir atendiendo clientes todos los días.
Coste y riesgo de reescribir sistemas críticos
Esta, para mí, es la razón más fácil de entender a nivel ejecutivo. Reescribir suena bien en una presentación. En la vida real, significa años de trabajo, presupuesto enorme, pruebas interminables y un riesgo muy serio de degradar algo que ya funcionaba. El caso de BBVA Francés es bastante ilustrativo: la entidad evaluó migrar sus aplicaciones a una versión más nueva de COBOL, pero concluyó que cambiar y probar el código fuente requería demasiado tiempo y esfuerzo; por eso optó por una vía de optimización que reducía el riesgo inmediato.
Eso no significa que todos los bancos deban hacer exactamente lo mismo. Sí significa que “quitar COBOL” no es un botón: es una decisión con coste, riesgo operativo y mucha dependencia acumulada.
Continuidad de negocio por encima de todo
Cuando un e-commerce falla, pierde ventas. Cuando un banco falla, el impacto puede tocar pagos, saldos, canales, conciliaciones y confianza del cliente. IBM lo plantea con crudeza: la interrupción del negocio no es una buena opción, y por eso muchos responsables posponen transformaciones profundas aunque sepan que la deuda técnica existe.
Aquí es donde la conversación cambia por completo. Ya no estamos comparando COBOL con lenguajes modernos en abstracto, sino evaluando qué tecnología permite sostener continuidad con menos sobresaltos mientras llega la siguiente fase de modernización.
Modernización gradual: mejor convivir que romperlo todo
Red Hat lo formula de manera muy clara: los bancos suelen optar por reemplazos graduales porque intentar resolverlo todo en una sola etapa incrementa riesgos y costes. Su recomendación pasa por dividir el sistema heredado en partes más pequeñas, apoyarse en microservicios y contenedores, e ir sustituyendo funciones de manera progresiva.
Y esa es, probablemente, la mejor respuesta a la keyword del artículo. Los bancos siguen usando COBOL no solo porque siga siendo útil en ciertos núcleos, sino porque la forma sensata de salir de él no es apagarlo, sino convivir con él durante bastante tiempo.
Los problemas reales de seguir dependiendo de COBOL
Hasta aquí podría parecer que estoy defendiendo COBOL a capa y espada, y no es el caso. Que tenga sentido conservarlo en ciertas capas no elimina sus problemas. El primero es obvio: talento. IBM señala que en muchos entornos los ingenieros que diseñaron el sistema original ya no están, y eso complica el mantenimiento, la comprensión del código y la velocidad de cualquier cambio.
El segundo problema es la deuda técnica. Un sistema puede seguir cumpliendo su función y, al mismo tiempo, volverse cada vez más caro de adaptar. Red Hat explica que los sistemas heredados suelen depender de tecnologías obsoletas cuya integración con otros servicios requiere tiempo y grandes costes, y que precisamente por eso la interoperabilidad se convierte en un obstáculo central.
El tercer problema es que tocar código crítico da miedo por una razón legítima: los errores no se quedan en un entorno de pruebas simpático, sino que pueden impactar operaciones reales. El propio caso de BBVA Francés deja ver esa prudencia: la entidad avanzó con plan de contingencia y por lotes semanales, justo para mantener el riesgo bajo control mientras optimizaba aplicaciones COBOL de producción.
Así que no, el mensaje no es “dejemos todo como está”. El mensaje correcto sería este: seguir dependiendo de COBOL tiene costes crecientes, pero deshacerse de él mal puede costar todavía más. Esa tensión es la historia real.
Cómo están modernizando los bancos sin dejar COBOL de golpe
La modernización bancaria seria no suele empezar con una reescritura masiva. Suele empezar con comprensión. IBM explica que sus herramientas de modernización asistida por IA primero analizan relaciones y dependencias dentro del sistema COBOL para identificar servicios empresariales que puedan refactorizarse selectivamente a Java. Ese detalle me parece clave: antes de convertir, hay que entender.
APIs, microservicios y encapsulación del legacy
Una estrategia muy común consiste en no arrancar el corazón del sistema, sino envolverlo. Red Hat plantea que la nube moderna, los microservicios y los contenedores permiten ir reemplazando funciones gradualmente, mejorar la interoperabilidad y crear entornos de prueba más cercanos a producción. Es decir: en vez de desmontar el banco entero, extraes capacidades concretas, las expones mejor y dejas que lo nuevo conviva con lo heredado.
Este enfoque tiene otra ventaja práctica: permite que el cliente vea mejoras antes. La app móvil puede evolucionar, los canales pueden ganar velocidad y ciertas piezas pueden migrarse, sin obligar a reescribir de una vez la lógica central que lleva años operando.
El patrón Strangler explicado fácil
Si tuviera que resumir la estrategia estrella de modernización legacy en una sola imagen mental, usaría esta: construir una ruta alternativa alrededor del sistema viejo hasta que cada parte nueva vaya sustituyendo una función concreta. Eso es, en esencia, lo que Red Hat describe como patrón Strangler: poner el sistema heredado detrás de una capa intermediaria y añadir poco a poco los servicios que lo irán reemplazando. La ventaja es evidente: reduces el riesgo general de transición y puedes generar retorno antes de que el proyecto termine.
A mí me parece una forma mucho más realista de contar la modernización. Menos épica, sí. Pero bastante más útil.
IA y traducción a Java: ayuda, pero no milagro
También está entrando en juego la IA, aunque conviene no vender humo. IBM describe watsonx Code Assistant for Z como una solución para modernizar y refactorizar servicios COBOL de forma incremental, transformándolos selectivamente en Java y apoyándose en análisis de dependencias y metadatos del sistema. Fíjate en dos palabras: incremental y selectivamente. No dice “pulsa un botón y se acabó COBOL”.
Ese matiz importa muchísimo. La IA puede acelerar el análisis, la comprensión del código y parte de la refactorización, pero no elimina la necesidad de validar comportamiento, probar integraciones ni entender reglas de negocio acumuladas durante décadas. El cuello de botella no es solo traducir sintaxis; es conservar correctamente el significado del sistema.
¿COBOL va a desaparecer de la banca?
Yo no compraría un titular rotundo de “COBOL va a desaparecer ya” ni el contrario de “COBOL reinará para siempre”. Lo más razonable, viendo cómo se mueven bancos y proveedores, es esperar una convivencia larga. IBM habla explícitamente de clientes que ejecutan una combinación de programas COBOL heredados y modernizados, y sus propias propuestas de modernización parten de esa convivencia, no de una sustitución instantánea. Red Hat también empuja la idea de reemplazo gradual, no de corte brusco.
Eso significa que en los próximos años probablemente veremos tres cosas a la vez: capas nuevas construidas con tecnologías más modernas, servicios extraídos del legacy y una base COBOL que seguirá viva en determinados procesos hasta que el coste, el riesgo y la oportunidad de negocio justifiquen mover cada pieza. No es una historia de inmortalidad tecnológica. Es una historia de transición lenta en un sector que no puede permitirse improvisar.
Conclusión
La mejor respuesta a por qué los bancos siguen usando COBOL no es “porque no quieran cambiar”, sino “porque cambiar bien es mucho más difícil de lo que parece”. COBOL sigue en banca porque concentra lógica de negocio probada, encaja con infraestructuras críticas y forma parte de sistemas cuya continuidad vale más que la moda tecnológica del momento. Y, al mismo tiempo, seguir dependiendo de él tiene un coste real: escasez de talento, deuda técnica y más dificultad para integrarse con lo nuevo.
Por eso la salida más realista no suele ser una gran reescritura heroica. Suele ser algo menos vistoso y mucho más inteligente: entender primero, aislar después, modernizar por capas y sustituir solo donde tenga sentido. Dicho de otro modo, el problema no es que COBOL exista. El problema es cómo salir de él sin romper el banco.
FAQs
¿COBOL sigue usándose de verdad en los bancos?
Sí. Tanto IBM como Red Hat siguen publicando soluciones y casos de uso de modernización bancaria que parten de sistemas heredados y aplicaciones COBOL en mainframe, lo que confirma que el lenguaje sigue presente en ese entorno.
¿Por qué no lo cambian por Java o por otro lenguaje moderno?
Porque el reto no es solo cambiar un lenguaje, sino conservar la lógica de negocio, validar dependencias y evitar interrupciones del negocio. IBM y Red Hat coinciden en que el coste y el riesgo de una migración brusca son muy altos.
¿COBOL es mejor que los lenguajes modernos?
No en términos generales. Lo que ocurre es que sigue siendo valioso en ciertos núcleos bancarios porque fue diseñado para procesamiento de datos empresariales y cálculos decimales precisos, y porque ya está integrado en sistemas críticos.
¿La IA puede eliminar la dependencia de COBOL?
Puede ayudar mucho, sobre todo en comprensión, análisis y refactorización selectiva a Java, pero no convierte automáticamente una migración compleja en algo trivial. IBM presenta estas herramientas como apoyo a una modernización incremental.
¿Cuál es la estrategia más sensata para un banco?
Modernizar por etapas: exponer servicios, aislar funciones, usar microservicios y aplicar estrategias como el patrón Strangler para reducir el riesgo de transición.