It has been more than a month since the disastrous IT switchover that led to TSBs chief executive Paul Pester being dragged before the Treasury select committee to explain how such a failure, which is still affecting many of the banks customers, could happen.
Worse still, the ongoing technical issues leave many customers vulnerable to opportunistic fraudsters.
So what could TSB have done differently to avoid the chaos that unfolded and what can other lenders learn from the episode?
Read more: TSB boss Paul Pester faces second round with MPs this week over IT crisis
What happened?
TSB was attempting a long-planned transfer of 1.3bn customer records – a gargantuan task that entailed significant risks. The aim was to move these records from its former parent company, Lloyds Banking Group, to Proteo4, a platform built by TSBs Spanish owner, Banco Sabadell. The changeover, which started on Friday 20 April, was supposed to be completed over the weekend by 18:00 on Sunday. But on Monday morning, millions of customers were unable to use online or mobile banking, or more shockingly, had been given access to other peoples accounts.
Data migrations of this scale are highly risky, especially with a banking platform that needs to be available to its customers 24/7. In fact, no UK bank has previously managed to carry out a transfer of this magnitude successfully.
Testing, testing
With TSB, it appears that some key IT best practices might have been omitted. To start with, it seems that developers were making live fixes to production, which is a big no-no in software development. Then, when it all went wrong, there was no apparent contingency plan or option to revert back to the original platform. What anyone attempting anything of this scale, including TSB, should have done is to validate each change first to ensure it has been implemented successfully before moving on to the next. Testing is crucial. Another key element is proof of concepts (PoCs), which would have revealed any tech and planning errors. TSB should have run PoCs on test accounts, or even staff accounts, before the full release.
It is also crucial that early live support is present, with enough highly-skilled staff available immediately, should anything go wrong. Again, this wasnt the case with TSB, as many customers reported the banks helpline left them waiting for long periods before the line went dead.
Another option available to banks is to collaborate with fintech companies that can achieve the required level of resilience, performance and security at a fraction of the cost and complexity of legacy mainframe banking systems. Modern challenger banking platforms are built from the ground up and are open-source and cloud-based. That gives them the ability to create cost-effective services that mitigate potential risks when attempting a major IT change or data migration between legacy systems. Some banks, such as Santander, are trying to employ a similar approach and are building from scratch themselves with a new brand, culture and even new customers.
If banks are going to attempt such operations alone though, there are a few things worth remembering. First, be meticulous in identifying and mitigating potential risks. Second, initiate high-risk and complex changes as early as possible in the project to leave plenty of time to deal with complications. Third, and most important, test as you go along. Following these steps could just be the difference between a successful operation and a crisis like the one experienced by TSB over the last month.
Read more: TSB faces fresh data crisis as MP claims bank may have broken GDPR laws
[contf]
[contfnew]
CityAM
[contfnewc]
[contfnewc]
