Infraestructuras heredadas encarecen cambios, ralentizan operaciones y exponen a usuarios a demoras, datos desfasados e interrupciones.
Los sistemas legacy bancarios son plataformas heredadas que continúan operando cuentas, movimientos, créditos y pagos. El problema surge cuando modificarlas resulta lento, costoso o riesgoso.
Aunque trabajan lejos de la vista del cliente, sus limitaciones llegan directamente a la aplicación. Pueden reflejarse en transferencias demoradas, saldos desactualizados, trámites repetidos y respuestas contradictorias.
Sin embargo, no toda interrupción bancaria proviene de tecnología antigua. Una plataforma moderna también puede fallar por errores de diseño, capacidad, pruebas, proveedores o cambios mal ejecutados.
Qué convierte una plataforma en legacy
El término legacy suele traducirse como heredado. No significa únicamente que un programa tenga muchos años ni que utilice una apariencia anticuada.
Una aplicación se vuelve problemática cuando depende de componentes difíciles de sustituir. También cuando nadie comprende completamente sus conexiones o requiere especialistas cada vez más escasos.
Puede tratarse de un core bancario, la plataforma central que registra cuentas, saldos y operaciones. Alrededor suelen acumularse aplicaciones para tarjetas, créditos, sucursales, atención, fraude y cumplimiento.
Cada integración resuelve una necesidad inmediata. Con los años, la institución termina sosteniendo una red de conexiones, parches, adaptadores y procesos manuales.
Conoce cómo los sistemas legacy bancarios provocan lentitud, datos desfasados e interrupciones, y por qué reemplazarlos también implica riesgos.
IBM identifica entre las señales comunes los altos costos de mantenimiento, poca capacidad de adaptación, escalabilidad limitada e incompatibilidad con estándares recientes. También advierte riesgos cuando las tecnologías dejaron de recibir actualizaciones.
La antigüedad, por sí sola, no condena al sistema. Una plataforma de décadas puede ser estable, estar documentada y procesar grandes cantidades de operaciones.
También ocurre lo contrario. Un desarrollo relativamente reciente puede convertirse rápidamente en legacy si resulta cerrado, rígido, mal documentado o dependiente de un solo proveedor.
Madurez financiera revela deuda técnica
México cerró 2025 con 795 empresas fintech locales activas. Siete de cada diez acumulaban al menos cinco años de operación, según Finnovista Fintech Radar México 2026.
Ese dato refleja una etapa distinta. Muchas compañías dejaron de concentrarse únicamente en captar usuarios y ahora necesitan demostrar eficiencia, rentabilidad, capacidad operativa y permanencia.
Cuando una institución comienza, puede resolver tareas mediante procesos manuales o aplicaciones separadas. El modelo parece suficiente mientras existen pocos clientes, productos y movimientos.
El problema aparece al crecer. Cada alta, crédito, aclaración o transferencia puede cruzar varios sistemas que no comparten información de forma automática.
Las SOFIPO, SOFOM y empresas fintech enfrentan entonces una decisión. Pueden seguir agregando parches o revisar la arquitectura que sostiene sus operaciones.
Ernesto García, director general de AurumCore, considera que “la infraestructura tecnológica deja de ser un soporte y se convierte en una decisión estratégica”.
La empresa sostiene que una mayor intervención manual genera cuellos de botella. También puede provocar información desfasada, respuestas prolongadas y dificultades para modificar productos.
Su comunicado sirve como punto de partida, pero la modernización no debe interpretarse como una sustitución automática. Cambiar el corazón operativo de una institución también introduce riesgos.
Falla visible comienza años antes
Para el usuario, el problema aparece cuando necesita realizar una operación concreta. Abre la aplicación, introduce los datos y espera una respuesta inmediata.
Detrás puede existir una cadena mucho más compleja. La aplicación consulta identidad, saldo, límites, seguridad, beneficiarios, historial, motor antifraude y sistema de pagos.
Si alguna conexión responde lentamente, toda la experiencia puede detenerse. La pantalla quizá muestre un mensaje genérico, aunque el resto de la infraestructura continúe procesando.
También puede ocurrir que la orden llegue a un componente, pero tarde en reflejarse en otro. El cliente ve un cargo, mientras el destinatario todavía no observa el depósito.
En otros casos, un crédito parece aprobado, pero falta registrar el resultado en el sistema central. El usuario vuelve a presentar documentos que otra área ya recibió.
La fragmentación también afecta la atención. El agente telefónico puede consultar una base distinta de la utilizada por la aplicación o la sucursal.
Por eso, el cliente termina explicando nuevamente el caso. Cada área ofrece una versión parcial porque ninguna observa el recorrido completo.
Procesos manuales multiplican demoras
Los sistemas cerrados suelen obligar a exportar archivos, capturar datos otra vez o realizar conciliaciones posteriores. Cada paso agrega tiempo y posibilidad de error.
Una operación puede completarse técnicamente, pero quedar pendiente de una revisión manual. Mientras tanto, el usuario desconoce si debe esperar o intentarlo nuevamente.
Repetir una transferencia durante una interrupción puede agravar el problema. La segunda orden podría procesarse cuando el primer intento ya había sido aceptado.
Lo mismo ocurre con pagos, domiciliaciones y retiros. Un mensaje de error no siempre significa que la operación fue descartada.
La institución necesita diseñar respuestas claras. Debe indicar si la solicitud no ingresó, continúa pendiente o terminó con éxito.
Un mensaje como “inténtalo más tarde” resulta insuficiente para operaciones monetarias. El cliente necesita saber si su dinero se movió.
Interrupciones no siempre son ataques
Las fallas tecnológicas suelen asociarse inmediatamente con un ciberataque. Sin embargo, numerosas interrupciones comienzan dentro de la propia operación.
El Comité de Basilea de Supervisión Bancaria analizó incidentes no maliciosos reportados en 16 jurisdicciones, incluida México. Su informe fue publicado en junio de 2026.
Las causas más frecuentes fueron controles deficientes durante cambios, problemas de diseño y pruebas, capacidad insuficiente y fallas de proveedores externos.
El reporte también encontró dificultades para identificar todas las dependencias entre servicios, aplicaciones, activos tecnológicos y terceros. La escasez de personal especializado agrava la situación.
Esto cambia el diagnóstico. Una aplicación puede dejar de funcionar sin que alguien haya penetrado deliberadamente la red.
Una actualización mal probada puede resultar tan disruptiva como un ataque. También puede serlo una base saturada o una conexión externa indisponible.
La diferencia importa durante la respuesta. Una institución debe determinar rápidamente si enfrenta un error operativo, una agresión o ambos problemas simultáneamente.
Estabilidad general no elimina tropiezos particulares
El Banco de México señaló en junio de 2026 que el sistema financiero mexicano no presentaba vulnerabilidades macrofinancieras relevantes. También confirmó que continúa expuesto a riesgos de ciberseguridad.
La evaluación se refiere al conjunto del sistema. No significa que cada aplicación, banco o producto permanezca libre de interrupciones individuales.
Una institución puede mantener capital, liquidez y solvencia adecuados mientras enfrenta una caída tecnológica. La fortaleza financiera y la continuidad digital son dimensiones diferentes.
El dinero puede permanecer protegido, aunque temporalmente no resulte posible consultarlo o moverlo. Esa distinción debe comunicarse con claridad.
Una falla sin explicación genera temor. El cliente puede pensar que perdió fondos, sufrió un fraude o bloqueó su cuenta.
La institución debe informar qué canales permanecen activos. También necesita explicar si los movimientos pendientes se procesarán automáticamente.
Modernizar también puede romper
Sustituir tecnología heredada parece la solución evidente. Sin embargo, una migración precipitada puede producir una interrupción mayor que el problema original.
El caso de TSB Bank, en Reino Unido, muestra ese peligro. En 2018, la institución trasladó datos y operaciones hacia una plataforma nueva.
La información fue migrada, pero el nuevo entorno presentó fallas inmediatamente. Sucursales, banca telefónica, sitio web y aplicación resultaron afectados.
Una proporción considerable de sus 5.2 millones de clientes sufrió problemas. Algunas afectaciones continuaron durante meses y el banco pagó 32.7 millones de libras en compensaciones.
Las autoridades británicas impusieron multas conjuntas por 48.65 millones de libras. Señalaron deficiencias de planeación, gobierno tecnológico y manejo del proveedor externo.
El ejemplo no demuestra que modernizar sea inconveniente. Muestra que reemplazar una plataforma crítica exige controles, pruebas y capacidad de regresar al estado anterior.
También obliga a cuestionar los proyectos de “gran salto”. Cambiar todos los componentes durante una sola fecha concentra demasiado riesgo.
Razones para no reemplazar todo
Una institución financiera no puede apagar su sistema central durante meses para construir uno nuevo. Las cuentas, pagos y obligaciones deben continuar operando.
Además, muchos procesos fueron personalizados durante años. Algunas reglas viven dentro del código, mientras otras dependen de prácticas conocidas por pocos empleados.
La documentación puede estar incompleta. Antes de retirar un componente, el equipo necesita descubrir quién lo utiliza y qué procesos dependen de él.
También existen requisitos históricos. La institución debe conservar registros, comprobantes, autorizaciones y trazabilidad para aclaraciones o revisiones regulatorias.
Una sustitución total puede requerir transferir millones de registros. Cada saldo, movimiento y contrato debe conservar integridad.
Mover datos tampoco basta. El nuevo sistema debe reproducir correctamente intereses, fechas de corte, comisiones, límites y reglas acumuladas.
Por eso, algunas organizaciones prefieren mantener plataformas antiguas. Consideran que el riesgo de cambiarlas supera temporalmente el costo de conservarlas.
El problema surge cuando “temporalmente” se convierte en una política permanente. La deuda técnica continúa creciendo y cada modificación resulta más difícil.
Transición por capas reduce riesgo
Modernizar no significa necesariamente eliminar todo. Una estrategia puede conservar componentes confiables y sustituir gradualmente las áreas más rígidas.
El Comité de Basilea recoge precisamente un enfoque modular y por capas. La finalidad consiste en reemplazar componentes heredados sin aumentar innecesariamente la complejidad.
Una institución puede comenzar separando funciones. Identidad, notificaciones, pagos, crédito y atención dejan de depender de una sola aplicación monolítica.
Después puede crear interfaces controladas. Las aplicaciones nuevas consultan funciones específicas sin ingresar directamente a toda la base central.
También conviene operar temporalmente ambos entornos. Los resultados se comparan antes de entregar la operación definitiva al componente nuevo.
Cada etapa necesita criterios de aceptación, pruebas de volumen y mecanismos de reversión. La migración debe detenerse cuando los resultados no coinciden.
Otro requisito es la observabilidad. Los responsables deben conocer dónde se ralentiza una operación y qué componente produjo el error.
Sin esa visibilidad, la organización sólo recibe síntomas. Sabe que los clientes no pueden transferir, pero desconoce cuál dependencia falló.
Nube no corrige una arquitectura defectuosa
Trasladar una aplicación antigua hacia servicios de cloud computing puede mejorar capacidad y disponibilidad. No necesariamente resuelve sus limitaciones internas.
Un sistema rígido seguirá siendo rígido después de cambiar de servidor. Sus dependencias, procesos manuales y dificultades de mantenimiento pueden permanecer intactas.
IBM distingue varias estrategias. Incluyen trasladar, adaptar, reorganizar, rediseñar o reemplazar completamente una aplicación.
La elección depende del riesgo, presupuesto y estado del sistema. Una migración rápida puede conservar la mayoría de los problemas anteriores.
La nube tampoco elimina la responsabilidad de la institución. Sólo cambia parte de la infraestructura y añade una relación con nuevos proveedores.
Por ello, la entidad debe vigilar configuraciones, respaldos, accesos, continuidad y concentración. Un proveedor ampliamente utilizado puede convertirse en un punto común de falla.
APIs abren puertas, pero exigen control
Una API permite que dos aplicaciones intercambien datos mediante reglas definidas. Funciona como una ventanilla tecnológica con campos, permisos y respuestas específicas.
Esta capacidad evita conexiones improvisadas. También permite que una aplicación consulte únicamente la información necesaria para completar una tarea.
México incorporó este concepto en la Ley para Regular las Instituciones de Tecnología Financiera. Su artículo 76 prevé interfaces estandarizadas para intercambiar información.
Las disposiciones publicadas en 2020 establecieron requisitos de interoperabilidad, autenticación, arquitectura y seguridad para determinadas APIs financieras.
La apertura facilita nuevos productos, comparadores, pagos e integraciones. Sin embargo, cada conexión añade una dependencia que debe supervisarse.
Una API mal diseñada puede exponer información excesiva. También puede saturarse, devolver datos incompletos o aceptar solicitudes duplicadas.
Por eso, la interoperabilidad necesita controles de identidad, límites de uso, cifrado, registros y procedimientos ante incidentes.
Conectar rápidamente no equivale a conectar correctamente. La competencia financiera depende tanto de la velocidad como de la confiabilidad.
Seguridad exige inventario completo
Una organización no puede proteger lo que desconoce. Antes de modernizar, debe identificar aplicaciones, servidores, bases, conexiones, credenciales y responsables.
Este inventario también debe incluir componentes externos. Muchas funciones dependen de proveedores de nube, identidad, mensajería, tarjetas o prevención de fraude.
El riesgo no termina en el proveedor contratado. Ese proveedor puede utilizar a otras compañías, creando dependencias de tercer y cuarto nivel.
El Comité de Basilea señala dificultades para conservar visibilidad sobre esas cadenas. También advierte sobre concentración y controles poco transparentes de terceros.
Los sistemas antiguos pueden complicar el monitoreo. Algunos generan registros limitados o no se integran fácilmente con herramientas actuales.
También pueden conservar cuentas técnicas con permisos amplios. Estas credenciales merecen controles especiales, rotación y seguimiento continuo.
Modernizar sin revisar accesos trasladaría vulnerabilidades hacia una plataforma nueva. La seguridad debe formar parte del diseño, no añadirse después.
Impacto cotidiano para usuarios
El cliente no necesita conocer la arquitectura interna de su banco. Sí tiene derecho a recibir un servicio claro, confiable y recuperable.
Una infraestructura rígida puede retrasar el alta de beneficiarios. También puede prolongar aclaraciones, cambios de datos, cancelaciones y actualizaciones de límites.
En crédito, puede dificultar la consulta de información reciente. El solicitante recibe una evaluación basada en datos incompletos o debe repetir documentos.
En atención, el historial puede aparecer fragmentado. La persona relata el problema a varios representantes sin que exista continuidad.
En pagos, el principal riesgo es la incertidumbre. El usuario desconoce si la instrucción fue recibida, rechazada o procesada parcialmente.
Una buena experiencia no consiste únicamente en una aplicación atractiva. También requiere consistencia entre lo mostrado, lo registrado y lo informado por atención.
El core bancario quizá nunca sea visible. Sus efectos aparecen cada vez que una cifra no coincide o un trámite se detiene.
💻 Visita YoUsuarioFinal 📱
🇲🇽 Conoce más en SuperMexicanos 🎬
Comunicación forma parte de la continuidad
Durante una interrupción, guardar silencio empeora el problema. Los usuarios comienzan a repetir operaciones, llamar simultáneamente y buscar explicaciones no oficiales.
La institución debe reconocer la afectación. También necesita señalar qué funciones fallan, cuáles continúan activas y cuándo ofrecerá una nueva actualización.
No debe declarar resuelto el incidente mientras existan movimientos pendientes. La recuperación técnica puede ocurrir antes que la conciliación completa.
Después, conviene explicar qué ocurrió sin exponer detalles sensibles. La comunicación debe distinguir entre falla operativa, mantenimiento, ataque y problema externo.
También debe precisar si los usuarios necesitan actuar. Muchas veces, la mejor instrucción consiste en no repetir la operación.
La transparencia protege al cliente y reduce carga en los canales de soporte. Ocultar información produce el efecto contrario.
Qué hacer cuando la operación no aparece
Ante una transferencia dudosa, primero conviene evitar un segundo envío. Hay que revisar movimientos, notificaciones y saldo antes de intentarlo nuevamente.
El usuario debe conservar la clave de rastreo, fecha, hora, cantidad, institución receptora y cuenta beneficiaria. También conviene guardar capturas y mensajes.
Para movimientos realizados mediante SPEI, Banco de México ofrece MI-SPEI y el Comprobante Electrónico de Pago. Ahí puede revisarse el estado y la conexión de las instituciones participantes.
Un pago liquidado debe contar con información que permita confirmar su acreditación. Cuando el estado sea distinto, la consulta ayuda a determinar dónde continuar la aclaración.
Después corresponde contactar a la institución mediante canales oficiales. El usuario debe solicitar un folio y conservar la respuesta recibida.
Cuando la atención ordinaria no resuelva el caso, puede acudirse a la Unidad Especializada de Atención a Usuarios. Toda institución financiera debe contar con una.
La CONDUSEF también dispone de mecanismos electrónicos para determinadas reclamaciones bancarias y contra instituciones de tecnología financiera.
Responsabilidad no termina en tecnología
La institución financiera elige, configura y opera su infraestructura. También decide qué proveedores participan y cuánto riesgo considera aceptable.
Por ello, no debería trasladar al usuario conflictos internos entre aplicaciones. Tampoco basta atribuir una demora al “sistema”.
El cliente necesita una explicación verificable, un plazo y una solución. La complejidad tecnológica no reduce las obligaciones frente al dinero administrado.
Los directivos también deben participar. La modernización no puede quedar únicamente bajo responsabilidad del área técnica.
Implica continuidad, experiencia, regulación, seguridad y reputación. Cada decisión tecnológica modifica la capacidad futura de ofrecer productos confiables.
La inversión tampoco debe concentrarse solamente en novedades visibles. Una nueva aplicación puede continuar apoyándose en componentes incapaces de responder al crecimiento.
Modernización sin salto al vacío
Eliminar todos los sistemas legacy bancarios no sería realista ni necesariamente conveniente. El objetivo debe ser reducir dependencias peligrosas y recuperar capacidad de cambio.
La transición necesita inventario, prioridades, pruebas, operación paralela y rutas de reversión. También requiere responsables claros para cada servicio crítico.
Los componentes estables pueden mantenerse mientras se aíslan mediante interfaces seguras. Las funciones más frágiles deben reemplazarse por etapas medibles.
La institución debe probar no sólo que el sistema nuevo funciona. También debe demostrar que puede fallar sin detener todo el servicio.
Para el usuario, el resultado ideal es sencillo. La transferencia se refleja, el saldo coincide y la aclaración conserva continuidad entre canales.
Cuando eso no ocurre, el problema quizá empezó mucho antes de abrir la aplicación. Puede encontrarse en una arquitectura que acumuló años de decisiones aplazadas.