Escrito por
Roda Azziani
Publicado
September 1, 2026
Un banco paraguayo que arrastra un core de veinte o más años no tiene, en el fondo, un problema técnico. Tiene tres problemas distintos que suelen presentarse mezclados: riesgo operativo por procesos que dependen de conocimiento que vive en la cabeza de muy poca gente, costo de oportunidad porque la arquitectura no admite integraciones nuevas sin cirugía mayor, y deuda técnica que hace que cualquier cambio pequeño tome semanas de testing. Tratar los tres como uno solo lleva a dos respuestas igualmente malas: congelar todo, o lanzar una modernización total sin criterio claro de por dónde empezar.
El marco para resolver esto es el mismo en cualquier mercado: cada sistema —o cada componente de cada sistema— admite tres estrategias. Reemplazar, cuando el sistema bloquea capacidades críticas o el costo de mantenerlo ya supera el de migrarlo. Encapsular, cuando el núcleo funciona pero necesita exponerse a canales nuevos a través de una API moderna, sin tocarlo. No tocar, cuando el sistema cumple su función y el riesgo de intervenir supera el beneficio. Ese marco lo desarrollamos en nuestro post general sobre sistemas legacy en banca. Lo que cambia en Paraguay no es el marco: es el contexto que hace que la decisión importe más y que el momento para tomarla sea ahora.
Hasta 2022, una entidad financiera paraguaya que quisiera migrar su infraestructura a la nube no tenía un marco explícito que le dijera qué estaba permitido. La Resolución N° 10, Acta N° 43 del BCP —el Reglamento de Uso de Servicios para Computación en la Nube (RCN)— cerró esa incertidumbre. Ya escribimos sobre lo que exige ese reglamento y por qué moverse temprano da ventaja frente a entidades que esperan. Lo relevante para este post es una consecuencia directa: la decisión de modernizar un sistema legacy ya no puede escudarse en "no sabemos si está permitido". El RCN habilita la nube como destino técnico; lo que queda es decidir, sistema por sistema, si migrar tiene sentido de negocio.
El Banco Nacional de Fomento (BNF) llevó a licitación pública el reemplazo de su sistema core, que llevaba más de 25 años en producción. El presupuesto referencial fue de G. 146.000 millones, con un plazo de implementación de 36 meses que incluye la adquisición del software, el código fuente y la capacitación del equipo interno. Es un ejemplo público del tipo de decisión que describe la categoría "reemplazar": un sistema que ya no sostiene los productos digitales ni la integración con otros sistemas que el negocio necesita hoy, con un costo de mantenimiento que deja de justificarse frente al de migrar. También ilustra algo que vale para cualquier reemplazo de esta escala: es un proyecto de años, no de semanas, y eso es un argumento a favor de decidir temprano en vez de esperar a que el sistema falle.
El sistema financiero paraguayo, con del orden de una quincena de bancos comerciales, es chico en comparación con el argentino o el brasileño. Eso cambia el cálculo de riesgo: una entidad mediana no tiene la misma capacidad de absorber un reemplazo fallido, ni la misma oferta local de proveedores especializados en modernización de core bancario para elegir entre varios. En ese contexto, encapsular —construir una API moderna sobre el núcleo existente, sin tocarlo— suele ser la opción más razonable para el sistema que funciona pero necesita abrirse a un canal digital nuevo o a una integración con un proveedor externo. Es también la vía que deja tiempo para que el reemplazo, si hace falta, se planifique con el rigor de un proyecto de varios años como el del BNF, en vez de decidirse bajo presión.
El otro factor que empuja hacia encapsular es el talento. La escasez de perfiles que puedan mantener sistemas mainframe y lenguajes como COBOL es un fenómeno regional, no exclusivo de Paraguay: la generación que construyó esos sistemas se está jubilando, y muy pocos programadores nuevos se forman hoy en esas tecnologías. Encapsular reduce la superficie de código que ese talento escaso tiene que tocar, mientras el resto de la arquitectura evoluciona por afuera.
El propio directorio del BCP viene señalando que los próximos desafíos del sistema financiero paraguayo pasan por interoperabilidad, digitalización e inclusión, particularmente en medios de pago —la misma agenda de pagos interoperables que impulsa el Sistema Nacional de Pagos. Esa agenda no se resuelve con cumplimiento normativo puntual: requiere que los sistemas core puedan exponer datos y operaciones a terceros —billeteras, agregadores, otros bancos— de forma sostenida. Un sistema que hoy "funciona bien" puede dejar de sostener esa exposición sin que nadie lo haya decidido explícitamente. Por eso "no tocar" tiene una condición que a veces se pasa por alto: es una decisión que hay que revisar, no una que se toma una sola vez.
El punto de partida en los tres casos es el mismo: un inventario honesto de qué sistemas existen, qué dependencias tienen entre sí, y qué tan cerca está cada uno de bloquear algo que el negocio va a necesitar en los próximos doce meses. Sin ese mapa, cualquier decisión se toma a ciegas, y en un mercado con menos margen de error que el de sus vecinos regionales, eso pesa más.
Si tu entidad está evaluando cómo priorizar su hoja de ruta de modernización bajo el marco del RCN, escribimos sobre lo que exige ese reglamento en Paraguay habilitó la nube para su sistema financiero. En Renaiss ofrecemos consultoría cloud para entidades financieras de la región con foco en decidir, sistema por sistema, qué conviene migrar, qué conviene encapsular y qué conviene dejar como está.
© 2026 - Renaiss, hecho con cariño