TSB, abril de 2018: el fin de semana en que un banco no pudo regresar

El domingo 22 de abril de 2018, alrededor de la una de la tarde, un banco del Reino Unido autorizó el paso final de un proyecto de casi tres años. Durante ese fin de semana había movido a una plataforma tecnológica nueva la mayor parte de su operación: sus sistemas, sus servicios y los datos de sus clientes. A las seis de la tarde, la banca por teléfono y la banca por internet ya estaban en línea. La aplicación móvil tardó un poco más: arrancó a las 6:45 [1].

Quince minutos después, el banco apagó todos sus canales digitales.

Unos 40 clientes habían reportado algo que ningún banco quiere oír: al entrar a su cuenta veían el dinero de otra persona, casi siempre de un familiar. Más tarde se confirmó que les pasó a 440 clientes [1]. El banco se llamaba TSB, tenía alrededor de 5.2 millones de clientes [1], y esa noche empezó una crisis que, según el regulador, no terminó del todo hasta el 10 de diciembre de 2018 [1].

Este artículo es para quien firma la decisión de cambiar un sistema central: dirección general, finanzas, operaciones o sistemas. No es una historia técnica. Es la historia de una decisión de comité que dejó al banco sin una reversa viable, con información incompleta sobre si estaba listo. Y es la historia de las preguntas que debieron exigir evidencia más clara antes de autorizar el arranque.

Una aclaración antes de empezar: Hábil no participó en este caso. Lo contamos con lo que informaron públicamente los reguladores (FCA y PRA) y con el informe independiente que TSB publicó.

Primero, cuatro palabras

Para que todos en la mesa entiendan lo mismo:

• Core (sistema central): el sistema donde viven las cuentas, los saldos, los movimientos y las reglas del negocio. En un banco, es lo que decide si un pago se aplicó.
• Migración: pasar la operación y los datos de un sistema a otro.
• «Big bang»: concentrar la mayor parte de una migración en un solo evento, casi siempre un fin de semana. Puede haber pasos previos, pero el riesgo principal queda en ese momento.
• Reversa (o roll-back): la posibilidad de regresar al sistema anterior si el nuevo falla.

Guarde la última. Explica todo lo demás.

El lunes en que todo se notó

El lunes 23 de abril, a las dos de la mañana, el banco volvió a encender la banca por internet y la app. Pero una parte de la plataforma nueva consumía cantidades enormes de memoria, y el banco tuvo que limitar las entradas para que la app no se cayera [1].

Ese día hubo cerca de 900,000 intentos de entrar a la banca en línea. Solo alrededor del 10 % de los intentos por internet lo logró. De los pagos que los clientes intentaron hacer, no se completó el 48 % en la app y el 59 % por internet [1].

Los clientes que no pudieron entrar hicieron lo lógico: llamaron. A las dos de la tarde, el centro telefónico ya había recibido 69,000 llamadas. El banco se había preparado para hasta 50 % más de llamadas de lo normal, pero un problema de configuración dejó disponible solo cerca de una cuarta parte de la capacidad de líneas que debía tener. La espera rondaba los 90 minutos, y siete de cada diez personas colgaban antes de ser atendidas [1].

Quien no logró nada por teléfono fue a la sucursal. Ahí, la aplicación de caja se caía y los lectores de tarjeta no funcionaban. Se formaron filas largas [1].

El regulador lo describe como un efecto en cascada: la falla digital empujó a la gente al teléfono, el teléfono se saturó y la gente llegó a sucursales que también fallaban [1]. El teléfono y las sucursales tenían sus propios problemas, así que ningún canal alcanzó a absorber la demanda de los otros.

Los canales digitales siguieron «inestables y casi inutilizables» hasta el jueves 26 de abril [1]. Para ese día, el banco había registrado 10,315 quejas, contra las 1,146 que esperaba [1]. Algunos defectos siguieron hasta junio [1].

El costo de la crisis

Lo que siguió se puede contar en números, todos de documentos oficiales:

• 225,492 quejas entre el 22 de abril de 2018 y el 7 de abril de 2019, de cerca del 4.3 % de sus clientes [1].
• 32.7 millones de libras pagados a clientes como compensación en ese mismo periodo [1].
• Casi 12 meses para atender las quejas de la migración [1].
• 48.65 millones de libras de multas el 20 de diciembre de 2022: 29.75 millones de la Financial Conduct Authority (FCA) y 18.9 millones de la Prudential Regulation Authority (PRA), los dos reguladores del Reino Unido. Sin el descuento de 30 % por llegar a un acuerdo, habrían sido 69.5 millones [1][2][3].
• Una multa personal en abril de 2023: la PRA sancionó al exdirector de sistemas con 81,620 libras por no tomar medidas razonables para que el banco supervisara bien a su proveedor durante la migración [5].

Y hay un dato que cambia cómo se lee todo lo anterior: la migración de los datos fue exitosa [1]. Eso no evitó las fallas de acceso, de operación ni los casos de clientes que vieron información ajena. La lección es incómoda: migrar bien los datos no demuestra que una plataforma esté lista para atender a millones de clientes al mismo tiempo. Según la FCA, las causas directas tuvieron que ver con la configuración, la capacidad y el código de la plataforma [1].

Cómo se llegó a ese domingo

Para entender la noche del 22 de abril hay que regresar casi tres años.

TSB nació en 2014, al separarse del grupo Lloyds, y seguía usando la plataforma tecnológica de Lloyds bajo contrato. En 2015 lo compró el banco español Sabadell (por 1,700 millones de libras, según Reuters [7]), que tenía experiencia migrando bancos a su propia plataforma, llamada Proteo [1]. La migración de TSB a esa plataforma formaba parte de la razón de negocio de la compra [1].

Después de la crisis, el consejo de TSB encargó al despacho Slaughter and May una revisión independiente. El informe, fechado en octubre de 2019 y publicado por TSB en noviembre de ese año, reconstruye la historia [4][6]. Tres de sus hallazgos explican el domingo de abril.

1. La fecha llegó antes que el plan

Para el 1 de julio de 2015, un día después de que la oferta de compra quedara firme, ya se había elegido una fecha para encender el sistema nuevo: el domingo 5 de noviembre de 2017 [4]. El primer plan formal, terminado nueve meses después, conservó esa misma fecha.

El informe la llama «ambiciosa y poco realista» y señala algo más grave que la fecha en sí. Se instaló un patrón: fijar primero la fecha deseada y luego construir un plan que cupiera en ella, fuera realista o no [4].

En septiembre de 2017 el banco pospuso el arranque y rehízo el plan, sin revisar a fondo por qué se había retrasado, y nueve días después anunció en público una nueva fecha. Para enero de 2018, el proyecto ya se había desviado otra vez [4].

2. La migración principal, en un fin de semana y sin discutirla a fondo

La forma de migrar es una de las decisiones más importantes de un proyecto así: por partes o de un solo golpe. El informe lo explica sin rodeos: hacerlo de un solo golpe es «la forma más rápida, barata y menos compleja», pero exige entender sus riesgos y probar la plataforma a fondo antes de ponerla frente a todos los clientes [4].

Y agrega un matiz importante: no habría sido necesariamente la decisión equivocada si se hubieran tomado las medidas correctas para compensar el riesgo [4]. El problema fue otro: la elección no se discutió a fondo en el consejo, no se le presentaron las opciones con sus riesgos, y no se pidió una opinión externa sobre ese punto [4].

El banco sí movió antes algunas piezas: pagos inmediatos, la app y los cajeros [1]. Pero el informe concluye que esas etapas previas cubrieron solo una parte pequeña de la plataforma, y que el piloto con usuarios reales no tuvo la escala suficiente para mostrar lo que pasaría con todos los clientes [4].

Las razones que dio el banco para hacerlo casi todo en un solo evento son razonables, y por eso vale la pena leerlas: lo difícil de pasar por etapas de un proveedor a otro, el costo de hacerlo por etapas, la idea de que el proveedor anterior no lo facilitaría, y la ventaja de que el cliente viera todos sus productos en un mismo lugar [1].

3. Lo que el consejo no alcanzó a ver

Aquí está el centro de la historia. Varias señales existían, pero no llegaron completas a quien tomaba la decisión:

• Los defectos. Al consejo se le informó de «alrededor de 800 defectos» que pasarían al sistema en vivo. El informe concluyó que en realidad eran 3,317: los 800 eran grupos de funciones que juntaban varios defectos, y faltaban los encontrados en otras pruebas [4]. El problema no fue solo el número, sino que el reporte no decía qué contaba y qué dejaba fuera.
• Las metas de prueba. En las pruebas de carga de la banca por internet y la app, las metas se bajaron después de que las pruebas no pasaron con la carga original. El resumen no dejó claro el cambio, y el uso real después del arranque superó las metas reducidas [4].
• La configuración real no se probó completa. La operación dependía de dos centros de datos trabajando juntos, pero las pruebas de desempeño se hicieron en uno solo. Los problemas de configuración entre ambos, que pegaron a los clientes digitales desde el primer momento, no podían aparecer en esas pruebas [4]. La FCA añade que, a finales de febrero de 2018, se recortó una prueba que probablemente habría encontrado el problema, y que esa decisión se tomó fuera del órgano que debía tomarla [1].
• El proveedor. El proveedor que construía y operaría la plataforma, una filial de Sabadell, dependía a su vez de 85 terceros [1]. Además, ese proveedor encargó a una firma de auditoría un informe que encontró deficiencias en sus controles internos, y ese informe no se compartió con TSB [4].

El informe resume su conclusión en dos frases: la plataforma nueva no estaba lista para atender a todos los clientes, y el proveedor no estaba listo para operarla [4]. Sobre el consejo, dice que hizo preguntas pertinentes pero le faltaron algunas de «sentido común», y que su reunión del 10 de abril de 2018 fue una oportunidad perdida para detenerse a pensar [4].

Para ser justos, hay que decir que el consejo de TSB no estuvo de acuerdo con todo el informe. Sostuvo que una causa clave fue que los dos centros de datos quedaron configurados de forma distinta, aunque se habían especificado idénticos, y que decidió avanzar con base en pruebas extensas, reportes de preparación y garantías del proveedor [6]. Los hallazgos de este apartado son del informe independiente; la postura del consejo es la que publicó TSB.

La palabra que faltaba: reversa

De todo lo que falló, hay una decisión que convierte un mal arranque en una crisis de ocho meses.

La FCA lo explica así: cuando se migra a casi todos los clientes al mismo tiempo, un problema serio puede dañar a muchísima gente. Por eso, a veces se prepara un plan para regresar al sistema anterior. Para TSB, ese plan no era posible [1]. Por contrato, al avisar a Lloyds que saldría mediante una migración, TSB renunciaba a su otra opción de salida: una copia de la plataforma operada por un tercero. Y después de migrar los datos quedaba una ventana muy corta antes de que la plataforma anterior se desactivara. En la práctica, regresar era técnicamente casi imposible [1].

El riesgo no era secreto. En diciembre de 2015, el acta del consejo de TSB advirtió que el consejo no podía quedar en una posición en la que hubiera renunciado a su opción de salida y la migración se atorara o resultara inviable, «dejando al banco sin infraestructura tecnológica» [1].

Y la preparación para una crisis no estuvo a la altura de esa apuesta. Los manuales de manejo de incidentes estaban diseñados para las primeras 48 horas [1]. Los simulacros suponían que los incidentes se resolverían en pocos días; muchos tardaron semanas [1]. La FCA concluye que, sin vuelta atrás y dependiendo de un solo proveedor para arreglar varios problemas a la vez, el banco debió prepararse mucho más [1].

Qué se lleva un director de esta historia

TSB no es un caso de mala tecnología. Es un caso de riesgo concentrado en un solo momento, sin salida, con información incompleta en la mesa. Eso puede pasarle a cualquier empresa que cambie su core, su ERP (el sistema que integra finanzas, compras, inventario y operación) o su sistema de pólizas, sin importar la marca. Seis lecciones, en lenguaje de negocio.

1. Si la fecha manda sobre la evidencia, el plan es un deseo. Cuando cada retraso se resuelve apretando el plan y no moviendo la fecha, el riesgo se acumula en silencio. Pida criterios medibles para arrancar, y que el comité pueda mover la fecha sin que parezca un fracaso.

2. La pregunta no es «¿funcionará?», sino «¿qué pasa si no funciona?». Un arranque de un solo golpe puede ser la opción correcta. Pero si no hay forma de regresar, el costo de equivocarse ya no es un mal fin de semana: es la operación entera durante meses. Antes de aprobar, pregunte cuál es la salida de reversa, cuánto tiempo está disponible y quién decide usarla.

3. Exija ver las opciones, no solo la recomendación. Al consejo de TSB no se le presentaron las formas de migrar con sus riesgos [4]. Un comité que solo ve una propuesta no está decidiendo: está aprobando.

4. La cifra que importa es la que nadie quiere presentar. Defectos contados a la baja, metas de prueba ajustadas sin aviso, una prueba recortada sin pasar por el órgano correcto. Ninguna parece grave por separado. Pida el número crudo, quién cambió cada criterio y cuándo, y que un tercero independiente lo confirme antes de la reunión de arranque.

5. Su proveedor crítico debe demostrar que puede operar, no solo construir. Son dos capacidades distintas. Si su proveedor depende de decenas de terceros, usted también. Pida evidencia de operación, no solo cartas de garantía.

6. Prepárese para semanas, no para 48 horas. Pregunte qué pasa el día diez: quién atiende las llamadas, cómo se compensa a los clientes y cómo se identifica a los más vulnerables.

Y una séptima, que el caso deja clara: la responsabilidad llega a las personas. La multa al exdirector de sistemas fue por no tomar medidas razonables para que el banco supervisara adecuadamente al proveedor [5]. La garantía de un proveedor no sustituye la evidencia que la propia empresa debe obtener y revisar.

La alternativa: modernizar por partes, conviviendo con el core

El caso TSB no prueba que todo cambio de core fracase, ni que modernizar por partes sea posible en cualquier contexto. Sí muestra qué debe exigir un comité cuando junta en un solo momento los cambios críticos y a todos los clientes, sin reversa.

Si el riesgo de TSB fue concentrar todo en un solo momento sin salida, la alternativa es repartirlo: modernizar por partes, con el sistema actual operando mientras tanto, y con una salida de reversa en cada etapa.

En palabras de negocio, se ve así:

• El core actual sigue operando. No se apaga el viernes para encender otro el domingo. Alrededor de él se construye una capa que lo conecta con los canales, los socios y las nuevas funciones, sin tocar sus reglas por dentro.
• Se cambia una función a la vez. Por ejemplo, primero la consulta de saldos para un grupo pequeño de clientes; después, los pagos; después, otro producto. Cada parte se acepta antes de empezar la siguiente.
• Cada etapa tiene su reversa pactada. Antes de empezar se acuerda cómo regresar esa función al camino anterior si algo sale mal, sin arrastrar al resto de la operación.
• Lo viejo y lo nuevo se concilian. Mientras conviven, se compara lo que dice uno contra lo que dice el otro. La función nueva se gana su lugar con evidencia, no con una fecha.
• El crecimiento es gradual. Primero un grupo de clientes, luego otro. Los problemas tienden a aparecer cuando afectan a pocos y son más fáciles de corregir.

Este camino no es gratis: mientras conviven los dos mundos hay que sostener conexiones, conciliación y dos equipos. Suele tardar más, y exige disciplina para no dejar la convivencia abierta para siempre.

Tampoco elimina el riesgo: cambia qué hay que demostrar antes de ampliar el alcance, y su viabilidad depende de los sistemas, los datos y los contratos de cada empresa. Pero cambia la naturaleza del riesgo. En un arranque de un solo golpe, se apuesta casi todo a que el primer día salga bien. En una modernización por partes, cada etapa arriesga, sobre todo, lo que cambia en ella. Cuando su core decide si un cliente recibe su dinero, esa diferencia vale más que las semanas que se ahorran.

Escenario (ilustrativo, sin cliente). Una aseguradora quiere renovar cómo sus agentes cotizan y emiten pólizas, pero su sistema de pólizas es antiguo y nadie quiere tocarlo. En lugar de reemplazarlo de golpe, se conecta a él una capa nueva. Primero, solo la cotización de un producto pasa por esa capa, para un grupo pequeño de agentes. Durante un periodo acordado, cada cotización nueva se compara con la del sistema anterior. Cuando cuadran, se suman más agentes; después, la emisión. Si algo no cuadra, esa función regresa al camino de siempre con la reversa que se pactó antes de empezar. El sistema de pólizas sigue siendo el que manda.

Cinco preguntas para su próximo comité

1. Si el sistema nuevo falla el primer día, ¿cómo regresamos, en cuánto tiempo y quién lo decide? Si la respuesta es «no se puede», ¿lo sabe el consejo?
2. ¿Qué opciones de implementación se evaluaron, con el costo y el riesgo de cada una, y por qué se descartaron las demás?
3. ¿Qué criterios medibles tienen que cumplirse para arrancar, y quién puede mover la fecha si no se cumplen?
4. ¿Cuántos defectos abiertos hay hoy, y cambió alguna meta de prueba desde que se aprobó el plan? ¿Quién lo autorizó?
5. ¿Qué evidencia tenemos de que el proveedor puede operar el sistema a escala, no solo construirlo, y de qué terceros depende?

Si en dos o más la respuesta es «no sé», ahí puede estar su riesgo.

Por dónde empezar esta semana

Tome el proyecto de modernización que tenga en curso, o el que esté por aprobar, y dibuje en una hoja su momento de máximo riesgo: el día en que más clientes, más funciones y más dinero cambian al mismo tiempo. Escriba al lado qué pasaría si ese día sale mal y cómo se regresaría. Si ese momento abarca a todos sus clientes y no tiene salida, ya sabe qué conversación tener con su comité.

Qué hace Hábil

Hábil es una consultora mexicana de ingeniería, fundada en 2006, que se integra a los sistemas centrales que su empresa ya tiene. No reemplazamos su core: construimos alrededor de él la capa que permite modernizar por partes, con el sistema actual operando, con conciliación entre lo viejo y lo nuevo, y con una salida de reversa pactada en cada etapa. Así, cada función nueva se gana su lugar con evidencia, y la modernización se diseña para que su operación siga mientras tanto. Vea la página Modernizar el core sin frenar el negocio.

Pida su primera conversación, sin costo. La conversación parte de su proyecto actual: dónde se concentra el riesgo, qué tiene hoy salida de reversa y qué no. Escríbanos por WhatsApp.

Preguntas frecuentes

¿Qué pasó con TSB en abril de 2018?

Del 20 al 22 de abril de 2018, TSB movió la mayor parte de su operación a una plataforma nueva. Los datos se migraron bien, pero la plataforma falló en todos los canales, y el banco no volvió a la normalidad hasta diciembre [1].

¿De cuánto fueron las multas y quién las impuso?

El 20 de diciembre de 2022, la FCA multó a TSB con 29.75 millones de libras y la PRA con 18.9 millones: 48.65 millones en total, con un descuento de 30 % por llegar a un acuerdo [1][2][3]. En abril de 2023, la PRA multó al exdirector de sistemas con 81,620 libras [5].

¿Entonces una migración de un solo golpe siempre es un error?

No. El informe independiente dice que no habría sido necesariamente la decisión equivocada si se hubieran tomado las medidas correctas para compensar el riesgo [4]. Lo que no se sostiene es elegirla sin evaluar las alternativas, sin pruebas a la escala real y sin una salida si algo falla.

¿Modernizar por partes no sale más caro?

Puede costar más en calendario y en sostener dos sistemas a la vez. A cambio, cada etapa expone menos. TSB muestra el otro lado de la cuenta: compensaciones, multas y casi un año atendiendo quejas [1].

¿Esto aplica solo a bancos?

No. Aplica a cualquier empresa que cambie el sistema que decide su operación: el sistema de pólizas de una aseguradora, el ERP de una empresa industrial, el sistema de órdenes de un comercio. El tamaño cambia; el riesgo de concentrarlo todo en un solo momento sin salida, no.

¿Cuándo no conviene modernizar por partes?

Cuando las funciones no se pueden separar entre sí, cuando los datos no se pueden conciliar entre el sistema viejo y el nuevo, o cuando un contrato obliga a dejar el sistema anterior en una fecha fija. En esos casos, la conversación cambia: qué parte del riesgo se puede reducir y cuál hay que aceptar con los ojos abiertos.

¿Hábil reemplaza nuestro core?

No. Hábil se integra a su core actual y construye la capa que permite modernizar por partes alrededor de él. El core sigue operando y cada etapa tiene su reversa pactada.

Las citas están traducidas del inglés. Las cifras, fechas y sanciones provienen de las resoluciones de la FCA y la PRA; el análisis de las decisiones del proyecto, del informe independiente de Slaughter and May, publicado por TSB; la postura del consejo, del comunicado de TSB. Fuentes consultadas el 20 y 21 de octubre de 2026.