Written By
Rodrigo Azziani
Published
May 22, 2026
Cuando un gerente de IT de un banco argentino plantea la idea de modernizar el core, lo primero que escucha es una lista de razones por las que no es el momento. La regulación no puede esperar. Los sistemas están en producción. El equipo no tiene capacidad. Y en algún punto del año, la BCRA saca una circular que reorganiza las prioridades de toda el área.
Esa resistencia no es irrazonable. En la banca argentina, los sistemas que sostienen la operación crítica llevan décadas acumulando dependencias que nadie documentó completamente, procesos que nadie se atrevió a tocar y decisiones de arquitectura que en su momento tenían sentido pero que hoy funcionan como restricciones invisibles. Modernizar en ese contexto no es lo mismo que modernizar en una startup que puede permitirse dos horas de downtime.
De ahí que la pregunta no sea si modernizar —esa decisión ya está tomada para la mayoría de las organizaciones del sector—, sino cómo hacerlo sin detener lo que no puede detenerse.
La mayor parte de los proyectos de modernización en banca fracasan antes de arrancar, porque el diagnóstico fue superficial. El equipo identifica los sistemas que quiere reemplazar, arma un cronograma, define las tecnologías destino y empieza. Lo que no mapea con suficiente detalle es el grafo de dependencias reales: qué sistema depende de qué, en qué condiciones, y qué falla primero si algo sale mal.
En banca, ese grafo suele ser más denso de lo que parece. Un sistema de liquidación no solo procesa transacciones: alimenta reportes regulatorios, se conecta con sistemas de compensación externos, tiene interfaces con terminales de los propios usuarios y en varios casos mantiene lógica de negocio que nunca se documentó porque quien la sabía ya no trabaja en la organización.
Antes de definir cualquier estrategia técnica, hay que responder tres preguntas concretas sobre cada sistema candidato:
Las respuestas determinan la estrategia más directamente que cualquier criterio tecnológico.
No hay una única forma de modernizar un core bancario. Según el diagnóstico, una organización puede optar por tres caminos distintos, y la decisión debería seguir criterios concretos, no preferencias tecnológicas.
Reemplazar tiene sentido cuando el sistema tiene dependencias acotadas, la lógica de negocio está documentada o puede relevarse, y existe una ventana de migración que el negocio puede tolerar. También aplica cuando el costo de mantener el sistema en producción supera ampliamente el costo de reemplazarlo —algo que hay que calcular explícitamente, no asumir.
Encapsular es la estrategia correcta cuando el sistema tiene demasiadas dependencias para reemplazarlo de una vez, pero la organización necesita exponer sus capacidades a nuevos consumidores: una aplicación mobile, una API para terceros, un sistema de analytics en tiempo real. La encapsulación construye una capa de interfaz moderna sobre el sistema existente sin tocarlo, lo que permite avanzar sin detener la operación. El riesgo de esta estrategia es diferir la deuda técnica sin eliminarla; hay que tenerlo claro desde el inicio, porque si no aparece como sorpresa dos años después.
No tocar es una decisión válida, no una capitulación. Si un sistema está estabilizado, tiene dependencias críticas que harían muy costosa cualquier intervención y no bloquea ninguna iniciativa de negocio prioritaria, la mejor decisión puede ser dejarlo donde está y modernizar lo que lo rodea. El error es asumir que modernizar significa reemplazar todo.
En la práctica, los proyectos bien diseñados combinan las tres estrategias según el perfil de cada sistema. No hay una respuesta única para toda la infraestructura.
Para los equipos de IT de la banca argentina, la regulación no es un factor externo que complica el proyecto: es parte del diseño desde el inicio. Hay dos dimensiones que afectan directamente la estrategia técnica.
La primera es la disponibilidad. Los sistemas que procesan operaciones sujetas a normativa de la BCRA tienen restricciones de tiempo de respuesta y disponibilidad que no son negociables. Cualquier arquitectura de modernización tiene que garantizar que esos sistemas no van a quedar fuera de servicio durante períodos que pongan en riesgo el cumplimiento. Eso no es un requerimiento que se agrega al final: determina desde el inicio qué tipo de rollout es posible y qué nivel de paralelismo se puede sostener durante la migración.
La segunda es la trazabilidad. La regulación exige que ciertos eventos sean auditables: quién hizo qué, cuándo, con qué resultado. Si la modernización implica cambiar cómo se registran esos eventos —migrar a un nuevo sistema de logs, modificar el modelo de datos de auditoría—, ese cambio tiene que estar coordinado con compliance antes del primer commit, no después de que el sistema ya esté en producción.
Tratar la regulación como una restricción a sortear es la forma más rápida de generar problemas que toman meses en resolverse. Tratarla como un parámetro de diseño desde el inicio cambia completamente el tipo de arquitectura que se propone.
Más allá de la estrategia técnica, los proyectos de modernización bancaria que llegan a producción sin incidentes críticos tienen algunos patrones en común.
El primero es que el equipo que conoce el sistema legado participa activamente del diseño. El conocimiento sobre cómo funciona ese sistema en condiciones de carga real, qué excepciones procesa que no están en ningún documento y qué condiciones de borde generan comportamientos inesperados está en la cabeza de las personas que trabajan con él todos los días. Si ese conocimiento no se transfiere de forma estructurada al inicio del proyecto, aparece como bug crítico en producción seis meses después.
El segundo es que la estrategia de rollout está definida antes de escribir la primera línea de código. Para la banca, eso generalmente significa migración gradual con capacidad de rollback: una porción del tráfico va al sistema nuevo, se monitorea, y solo cuando se valida el comportamiento en producción se aumenta el porcentaje. No es la estrategia más rápida, pero es la que reduce el riesgo a niveles manejables.
El tercero es que el éxito se define en términos que el negocio entiende, no solo el equipo técnico. Reducir la deuda técnica no es un objetivo de negocio. Reducir el tiempo de integración con nuevos proveedores de un mes a una semana, sí. Habilitar la oferta de un nuevo producto sin depender de un ciclo de releases de seis meses, también. Cuando el equipo técnico puede articular el impacto en esos términos, consigue el acompañamiento que los proyectos de esta escala inevitablemente necesitan.
La regulación no es una restricción a sortear: es un parámetro de diseño. Si la tratás como lo primero, el problema aparece en producción, no antes.
Rodrigo Azziani
Si estás evaluando un proyecto de modernización del core y todavía no tenés claro por dónde entrar, el primer paso no es elegir la tecnología: es mapear las dependencias reales de los sistemas críticos y clasificarlos según los tres criterios que mencioné antes.
Ese diagnóstico tarda entre dos y cuatro semanas si se hace con rigor. Y es la diferencia entre un proyecto que llega a producción en los plazos previstos y uno que se extiende indefinidamente porque cada semana aparece algo que nadie sabía que estaba ahí.
En Renaiss trabajamos con organizaciones del mercado financiero argentino en ese tipo de proyectos: desde el diagnóstico inicial hasta la operación en producción. Si querés conversar sobre el estado de tu infraestructura, coordinemos una reunión.
© 2026 - Renaiss with love