TSB, abril de 2018: o fim de semana em que um banco não conseguiu voltar atrás

No domingo, 22 de abril de 2018, por volta da uma da tarde, um banco do Reino Unido autorizou o passo final de um projeto de quase três anos. Naquele fim de semana, ele havia levado para uma plataforma tecnológica nova a maior parte da operação: os sistemas, os serviços e os dados dos clientes. Às seis da tarde, o atendimento por telefone e o internet banking já estavam no ar. O aplicativo demorou um pouco mais: entrou às 18h45 [1].

Quinze minutos depois, o banco desligou todos os seus canais digitais.

Cerca de 40 clientes haviam relatado algo que nenhum banco quer ouvir: ao entrar na conta, viam o dinheiro de outra pessoa, quase sempre de um familiar. Mais tarde se confirmou que isso aconteceu com 440 clientes [1]. O banco se chamava TSB, tinha cerca de 5,2 milhões de clientes [1], e naquela noite começou uma crise que, segundo o regulador, só terminou de fato em 10 de dezembro de 2018 [1].

Este artigo é para quem assina a decisão de trocar um sistema central: direção-geral, finanças, operações ou sistemas. Não é uma história técnica. É a história de uma decisão de comitê que deixou o banco sem uma reversão viável, com sinais de preparação incompleta sobre a mesa, e das perguntas que deveriam ter exigido evidência mais clara antes de autorizar a virada.

Um esclarecimento antes de começar: a Hábil não participou deste caso. Contamos o caso com o que os reguladores (FCA e PRA) informaram publicamente e com o relatório independente que o TSB publicou.

Primeiro, quatro palavras

Para que todos na mesa entendam a mesma coisa:

• Core (sistema central): o sistema onde vivem as contas, os saldos, as movimentações e as regras do negócio. Em um banco, é o que decide se um pagamento foi aplicado.
• Migração: passar a operação e os dados de um sistema para outro.
• «Big bang»: concentrar a maior parte de uma migração em um único evento, quase sempre um fim de semana. Pode haver etapas prévias, mas o risco principal fica nesse momento.
• Reversão (ou roll-back): a possibilidade de voltar ao sistema anterior se o novo falhar.

Guarde esta última. Ela explica todo o resto.

A segunda-feira em que tudo apareceu

Na segunda-feira, 23 de abril, às duas da manhã, o banco religou o internet banking e o app. Mas uma parte da plataforma nova consumia quantidades enormes de memória, e o banco teve de limitar os acessos para que o app não caísse [1].

Naquele dia houve cerca de 900.000 tentativas de entrar no banco on-line. Só cerca de 10% das tentativas pela internet tiveram êxito. Dos pagamentos que os clientes tentaram fazer, não se completaram 48% no app e 59% pela internet [1].

Os clientes que não conseguiram entrar fizeram o lógico: ligaram. Às duas da tarde, a central telefônica já tinha recebido 69.000 ligações. O banco havia se preparado para até 50% mais ligações que o normal, mas um problema de configuração deixou disponível apenas cerca de um quarto da capacidade de linhas que deveria haver. A espera girava em torno de 90 minutos, e sete em cada dez pessoas desligavam antes de ser atendidas [1].

Quem não conseguiu nada por telefone foi à agência. Lá, o aplicativo de caixa travava e as leitoras de cartão não funcionavam. Formaram-se filas longas [1].

O regulador descreve isso como um efeito cascata: a falha digital empurrou as pessoas para o telefone, o telefone saturou e as pessoas chegaram a agências que também estavam falhando [1]. O telefone e as agências tinham seus próprios problemas, de modo que nenhum canal conseguiu absorver a demanda dos outros.

Os canais digitais continuaram «instáveis e quase inutilizáveis» até a quinta-feira, 26 de abril [1]. Até esse dia, o banco havia registrado 10.315 reclamações, contra as 1.146 que esperava [1]. Alguns defeitos continuaram até junho [1].

O custo da crise

O que veio depois pode ser contado em números, todos de documentos oficiais:

• 225.492 reclamações entre 22 de abril de 2018 e 7 de abril de 2019, de cerca de 4,3% dos clientes [1].
• 32,7 milhões de libras pagos aos clientes como compensação nesse mesmo período [1].
• Quase 12 meses para atender às reclamações da migração [1].
• 48,65 milhões de libras em multas em 20 de dezembro de 2022: 29,75 milhões da Financial Conduct Authority (FCA) e 18,9 milhões da Prudential Regulation Authority (PRA), os dois reguladores do Reino Unido. Sem o desconto de 30% por chegar a um acordo, teriam sido 69,5 milhões [1][2][3].
• Uma multa pessoal em abril de 2023: a PRA sancionou o ex-diretor de sistemas com 81.620 libras por não tomar medidas razoáveis para que o banco supervisionasse bem o fornecedor durante a migração [5].

E há um dado que muda a leitura de tudo o que veio antes: a migração dos dados foi bem-sucedida [1]. Isso não evitou as falhas de acesso e de operação, nem os casos de clientes que viram informação alheia. A lição é incômoda: migrar bem os dados não demonstra que uma plataforma esteja pronta para atender milhões de clientes ao mesmo tempo. Segundo a FCA, as causas diretas tiveram a ver com a configuração, a capacidade e o código da plataforma [1].

Como se chegou àquele domingo

Para entender a noite de 22 de abril, é preciso voltar quase três anos.

O TSB nasceu em 2014, ao se separar do grupo Lloyds, e continuava usando a plataforma tecnológica do Lloyds sob contrato. Em 2015, foi comprado pelo banco espanhol Sabadell (por 1,7 bilhão de libras, segundo a Reuters [7]), que tinha experiência em migrar bancos para a própria plataforma, chamada Proteo [1]. A migração do TSB para essa plataforma fazia parte da razão de negócio da compra [1].

Depois da crise, o conselho do TSB encomendou ao escritório Slaughter and May uma revisão independente. O relatório, datado de outubro de 2019 e publicado pelo TSB em novembro daquele ano, reconstrói a história [4][6]. Três de seus achados explicam o domingo de abril.

1. A data veio antes do plano

Em 1º de julho de 2015, um dia depois de a oferta de compra se tornar firme, já se havia escolhido uma data para ligar o sistema novo: domingo, 5 de novembro de 2017 [4]. O primeiro plano formal, concluído nove meses depois, manteve essa mesma data.

O relatório a chama de «ambiciosa e pouco realista» e aponta algo mais grave que a data em si: instalou-se um padrão, o de fixar a data desejada e depois construir um plano que coubesse nela, fosse realista ou não [4].

Em setembro de 2017, o banco adiou a virada e refez o plano, sem revisar a fundo por que o projeto havia atrasado, e nove dias depois anunciou publicamente uma nova data. Em janeiro de 2018, o projeto já havia se desviado outra vez [4].

2. A migração principal, em um fim de semana e sem discuti-la a fundo

A forma de migrar é uma das decisões mais importantes de um projeto assim: por partes ou de uma só vez. O relatório explica sem rodeios: fazê-lo de uma só vez é «a forma mais rápida, barata e menos complexa», mas exige entender seus riscos e testar a plataforma a fundo antes de colocá-la diante de todos os clientes [4].

E acrescenta um matiz importante: não teria sido necessariamente a decisão errada se tivessem sido tomadas as medidas corretas para compensar o risco [4]. O problema foi outro: a escolha não foi discutida a fundo no conselho, não lhe foram apresentadas as opções com seus riscos, e não se pediu consultoria externa sobre esse ponto [4].

O banco, sim, moveu algumas peças antes: pagamentos imediatos, o app e os caixas eletrônicos [1]. Mas o relatório conclui que essas etapas prévias cobriram apenas uma parte pequena da plataforma, e que o piloto com usuários reais não teve escala suficiente para mostrar o que aconteceria com todos os clientes [4].

As razões que o banco deu para fazer quase tudo em um único evento são razoáveis, e por isso vale a pena lê-las: a dificuldade de passar por etapas de um fornecedor para outro, o custo de fazê-lo por etapas, a ideia de que o fornecedor anterior não facilitaria, e a vantagem de o cliente ver todos os seus produtos em um mesmo lugar [1].

3. O que o conselho não chegou a ver

Aqui está o centro da história. Vários sinais existiam, mas não chegaram completos a quem tomava a decisão:

• Os defeitos. O conselho foi informado de «cerca de 800 defeitos» que passariam para o sistema em funcionamento. O relatório concluiu que, na realidade, eram 3.317: os 800 eram grupos de funções que reuniam vários defeitos, e faltavam os encontrados em outros testes [4]. O problema não foi só o número, mas que o relatório apresentado ao conselho não dizia o que contava e o que deixava de fora.
• As metas de teste. Nos testes de carga do internet banking e do app, as metas foram reduzidas depois que os testes não passaram com a carga original. O resumo não deixou clara a mudança, e o uso real depois da virada superou as metas reduzidas [4].
• A configuração real não foi testada por completo. A operação dependia de dois centros de dados trabalhando juntos, mas os testes de desempenho foram feitos em um só. Os problemas de configuração entre os dois, que atingiram os clientes digitais desde o primeiro momento, não podiam aparecer nesses testes [4]. A FCA acrescenta que uma decisão tomada fora do órgão competente, no fim de fevereiro de 2018, cortou um teste que provavelmente teria encontrado o problema [1].
• O fornecedor. O fornecedor que construía e operaria a plataforma, uma subsidiária do Sabadell, dependia por sua vez de 85 terceiros [1]. Um relatório de uma firma de auditoria, encomendado por esse fornecedor, que encontrou deficiências em seus controles internos, não foi compartilhado com o TSB [4].

O relatório resume sua conclusão em duas frases: a plataforma nova não estava pronta para atender a todos os clientes, e o fornecedor não estava pronto para operá-la [4]. Sobre o conselho, diz que ele fez perguntas pertinentes, mas lhe faltaram algumas de «bom senso», e que sua reunião de 10 de abril de 2018 foi uma oportunidade perdida de parar para pensar [4].

Por justiça, é preciso dizer que o conselho do TSB não concordou com tudo no relatório. Sustentou que uma causa fundamental foi que os dois centros de dados ficaram configurados de forma diferente, embora tivessem sido especificados como idênticos, e que decidiu avançar com base em testes extensos, relatórios de prontidão e garantias do fornecedor [6]. Os achados desta seção são do relatório independente; a posição do conselho é a que o TSB publicou.

A palavra que faltava: reversão

De tudo o que falhou, há uma decisão que transforma uma virada ruim em uma crise de oito meses.

A FCA explica assim: quando se migra quase todos os clientes ao mesmo tempo, um problema sério pode prejudicar muitíssima gente. Por isso, às vezes se prepara um plano para voltar ao sistema anterior. Para o TSB, esse plano não era possível [1]. Por contrato, ao avisar o Lloyds de que sairia por meio de uma migração, o banco abria mão de sua outra opção de saída: uma cópia da plataforma operada por um terceiro. E, depois de migrar os dados, restava uma janela muito curta antes de a plataforma anterior ser desativada. Na prática, voltar era tecnicamente quase impossível [1].

O risco não era secreto. Em dezembro de 2015, a ata do conselho do TSB advertiu que o conselho não podia ficar em uma posição em que tivesse aberto mão de sua opção de saída e a migração emperrasse ou se mostrasse inviável, «deixando o banco sem infraestrutura tecnológica» [1].

E a preparação para uma crise não esteve à altura dessa aposta. Os manuais de gestão de incidentes foram desenhados para as primeiras 48 horas [1]. Os simulacros supunham que os incidentes seriam resolvidos em poucos dias; muitos levaram semanas [1]. A FCA conclui que, sem volta atrás e dependendo de um único fornecedor para resolver vários problemas ao mesmo tempo, o banco deveria ter se preparado muito mais [1].

O que um diretor leva desta história

O TSB não é um caso de tecnologia ruim. É um caso de risco concentrado em um só momento, sem saída, com informação incompleta na mesa. Isso pode acontecer com qualquer empresa que troque o core, o ERP (o sistema que integra finanças, compras, estoque e operação) ou o sistema de apólices, seja qual for a marca. Seis lições, em linguagem de negócio.

1. Se a data manda mais que a evidência, o plano é um desejo. Quando cada atraso é resolvido apertando o plano e não movendo a data, o risco se acumula em silêncio. Peça critérios mensuráveis para a virada, e que o comitê possa mover a data sem que isso pareça um fracasso.

2. A pergunta não é «vai funcionar?», mas «o que acontece se não funcionar?». Uma virada de uma só vez pode ser a opção certa. Mas, se não há como voltar, o custo de errar já não é um fim de semana ruim: é a operação inteira por meses. Antes de aprovar, pergunte qual é a saída de reversão, por quanto tempo ela está disponível e quem decide usá-la.

3. Exija ver as opções, não só a recomendação. Ao conselho do TSB não foram apresentadas as formas de migrar com seus riscos [4]. Um comitê que vê apenas uma proposta não está decidindo: está aprovando.

4. O número que importa é o que ninguém quer apresentar. Defeitos contados para baixo, metas de teste ajustadas sem aviso, um teste cortado sem passar pelo órgão correto. Nenhum parece grave isoladamente. Peça o número bruto, quem mudou cada critério e quando, e que um terceiro independente o confirme antes da reunião de virada.

5. O fornecedor crítico precisa demonstrar que sabe operar, não só construir. São duas capacidades diferentes. Se o fornecedor depende de dezenas de terceiros, a empresa também depende. Peça evidência de operação, não só cartas de garantia.

6. Prepare-se para semanas, não para 48 horas. Pergunte o que acontece no décimo dia: quem atende as ligações, como os clientes são compensados e como se identificam os mais vulneráveis.

E uma sétima, que o caso deixa clara: a responsabilidade chega às pessoas. A multa ao ex-diretor de sistemas foi por não tomar medidas razoáveis para que o banco supervisionasse adequadamente o fornecedor [5]. A garantia de um fornecedor não substitui a evidência que a própria empresa deve obter e revisar.

A alternativa: modernizar por partes, convivendo com o core

O caso TSB não prova que toda troca de core fracassa, nem que modernizar por partes seja possível em qualquer contexto. Mostra, sim, o que um comitê deve exigir quando concentra em um só momento as mudanças críticas, todos os clientes e a falta de reversão.

Se o risco do TSB foi concentrar tudo em um só momento sem saída, a alternativa é distribuí-lo: modernizar por partes, com o sistema atual operando enquanto isso, e com uma saída de reversão em cada etapa.

Em palavras de negócio, é assim:

• O core atual segue operando. Não se desliga na sexta para ligar outro no domingo. Ao redor dele se constrói uma camada que o conecta com os canais, os parceiros e as novas funções, sem mexer em suas regras por dentro.
• Muda-se uma função de cada vez. Por exemplo, primeiro a consulta de saldos para um grupo pequeno de clientes; depois, os pagamentos; depois, outro produto. Cada parte é aceita antes de começar a seguinte.
• Cada etapa tem a reversão acordada. Antes de começar, combina-se como devolver essa função ao caminho anterior se algo der errado, sem arrastar o resto da operação.
• O velho e o novo são conciliados. Enquanto convivem, compara-se o que diz um com o que diz o outro. A função nova ganha o lugar com evidência, não com uma data.
• O crescimento é gradual. Primeiro um grupo de clientes, depois outro. Os problemas tendem a aparecer quando afetam poucos e são mais fáceis de corrigir.

Esse caminho não é de graça: enquanto os dois mundos convivem, é preciso sustentar conexões, conciliação e duas equipes. Costuma demorar mais, e exige disciplina para não deixar a convivência aberta para sempre.

Tampouco elimina o risco: muda o que é preciso demonstrar antes de ampliar o escopo, e a viabilidade depende dos sistemas, dos dados e dos contratos de cada empresa. Mas muda a natureza do risco. Em uma virada de uma só vez, aposta-se quase tudo em que o primeiro dia dê certo. Em uma modernização por partes, cada etapa expõe sobretudo o que está sendo mudado nela. Quando o sistema central decide se um cliente recebe o dinheiro, essa diferença vale mais que as semanas economizadas.

Cenário (ilustrativo, sem cliente). Uma seguradora quer renovar a forma como os agentes cotam e emitem apólices, mas o sistema de apólices é antigo e ninguém quer mexer nele. Em vez de substituí-lo de uma vez, liga-se a ele uma camada nova. Primeiro, só a cotação de um produto passa por essa camada, para um grupo pequeno de agentes. Durante um período combinado, cada cotação nova é comparada com a do sistema anterior. Quando conferem, entram mais agentes; depois, a emissão. Se algo não confere, essa função volta ao caminho de sempre com a reversão que foi combinada antes de começar. O sistema de apólices continua sendo o que manda.

Cinco perguntas para o próximo comitê

1. Se o sistema novo falhar no primeiro dia, como voltamos, em quanto tempo e quem decide? Se a resposta for «não dá», o conselho sabe disso?
2. Que opções de implementação foram avaliadas, com o custo e o risco de cada uma, e por que as demais foram descartadas?
3. Que critérios mensuráveis precisam ser cumpridos para a virada, e quem pode mover a data se não forem?
4. Quantos defeitos abertos há hoje, e alguma meta de teste mudou desde que o plano foi aprovado? Quem autorizou?
5. Que evidência temos de que o fornecedor sabe operar o sistema em escala, não só construí-lo, e de quais terceiros ele depende?

Se em duas ou mais a resposta for «não sei», ali pode estar o risco da empresa.

Por onde começar esta semana

Pegue o projeto de modernização em andamento, ou o que está para ser aprovado, e desenhe em uma folha o momento de risco máximo: o dia em que mais clientes, mais funções e mais dinheiro mudam ao mesmo tempo. Escreva ao lado o que aconteceria se esse dia desse errado e como se voltaria atrás. Se esse momento abrange todos os clientes e não tem saída, já se sabe que conversa ter com o comitê.

O que a Hábil faz

A Hábil é uma consultoria mexicana de engenharia, fundada em 2006, que se integra aos sistemas centrais que a empresa já tem. Não substituímos o core: construímos ao redor dele a camada que permite modernizar por partes, com o sistema atual operando, com conciliação entre o velho e o novo, e com uma saída de reversão acordada em cada etapa. Assim, cada função nova ganha o lugar com evidência, e a modernização é desenhada para que a operação continue enquanto isso. Veja a página Modernizar o core sem frear o negócio.

Peça a primeira conversa, sem custo. Ela parte do projeto atual: onde se concentra o risco, o que hoje tem saída de reversão e o que não tem. Escreva para nós pelo WhatsApp.

Perguntas frequentes

O que aconteceu com o TSB em abril de 2018?

De 20 a 22 de abril de 2018, o TSB moveu a maior parte da operação para uma plataforma nova. Os dados foram migrados bem, mas a plataforma falhou em todos os canais, e o banco só voltou à normalidade em dezembro [1].

De quanto foram as multas e quem as impôs?

Em 20 de dezembro de 2022, a FCA multou o TSB em 29,75 milhões de libras e a PRA em 18,9 milhões: 48,65 milhões no total, com desconto de 30% por chegar a um acordo [1][2][3]. Em abril de 2023, a PRA multou o ex-diretor de sistemas em 81.620 libras [5].

Então uma migração de uma só vez é sempre um erro?

Não. O relatório independente diz que não teria sido necessariamente a decisão errada se tivessem sido adotadas as medidas corretas para compensar o risco [4]. O que não se sustenta é escolhê-la sem avaliar as alternativas, sem testes na escala real e sem uma saída se algo falhar.

Modernizar por partes não sai mais caro?

Pode custar mais em calendário e em manter dois sistemas ao mesmo tempo. Em troca, cada etapa expõe menos. O TSB mostra o outro lado da conta: compensações, multas e quase um ano atendendo reclamações [1].

Isso vale só para bancos?

Não. Vale para qualquer empresa que troque o sistema que decide a operação: o sistema de apólices de uma seguradora, o ERP de uma empresa industrial, o sistema de pedidos de um comércio. O tamanho muda; o risco de concentrar tudo em um só momento sem saída, não.

Quando não convém modernizar por partes?

Quando as funções não podem ser separadas entre si, quando os dados não podem ser conciliados entre o sistema velho e o novo, ou quando um contrato obriga a deixar o sistema anterior em uma data fixa. Nesses casos, a conversa muda: que parte do risco pode ser reduzida e qual precisa ser aceita de olhos abertos.

A Hábil substitui o nosso core?

Não. A Hábil se integra ao core atual e constrói ao redor dele a camada que permite modernizar por partes. O core continua operando e cada etapa tem a reversão acordada.

As citações estão traduzidas do inglês. Os números, as datas e as sanções vêm das decisões da FCA e da PRA; a análise das decisões do projeto, do relatório independente da Slaughter and May, publicado pelo TSB; a posição do conselho, do comunicado do TSB. Fontes consultadas em 20 e 21 de outubro de 2026.