What can banks learn from TSB’s digital transformation fiasco?

If you’re in the banking and financial services industry, you’ll know that there’s a lot of pressure to embrace new technologies to transform and streamline internal processes and to provide customers with a better experience.

However, the truth is, moving too quickly can interrupt business as usual — and for companies in the banking and financial services space, this can be quite catastrophic.

Earlier this year, the UK’s TSB attempted to migrate to a new IT system, and unfortunately, turned into a case study for how banks should not go about digital transformation projects. The botched systems upgrade cost it upwards of GBP176.4 million (US$226.82 million) and lost the business more than 26,000 customers.

The migration, which started on 20th April seemed to continue to cause problems for customers well into May, according to local media, and prompted the UK’s Financial Conduct Authority (FCA) to launch an investigation into the issue — jointly with the Prudential Regulation Authority.

To fix the issue, TSB brought in experts from IBM whose initial findings suggest that the bank rushed into the public launch, and didn’t test the robustness of the system before going live. In light of these findings, here are some best practices that bankers must keep in mind when working on digital transformation projects:

# 1 | Test, test, and test before you deploy

According to IBM’s report for TSB, initial studies didn’t reveal any evidence of the application of a rigorous set of go-live criteria to prove production readiness. Further, performance testing did not provide the required evidence of capacity.

Clearly, not enough emphasis was placed on testing the new digital system before releasing it to the public.

To some, testing sounds like common sense, and to others, it sounds incredibly impractical — but experience suggests that no matter how challenging, players in critical industries such as banking must make sure they rigorously test all proposed upgrades to their ecosystem.

In fact, experts recommend stress testing upgrades, especially those part of an ambitious digital transformation project, as you never know what will cause a spike in one of the critical variables that could spell doom for your new digital system.

# 2 | Avoid overhauling your system all at once

IBM’s review found that the project was of substantial scale and complexity, and thus required longer than normal to prove the platform through incremental customer take-on in order to observe and mitigate any operational risks.

The complexity also resulted in a broad range of technical and functional problems that are hard to diagnose.

The takeaway from this, and one of the most important ‘best practices’ that technology project owners insist on is splitting important and complex upgrades into phases.

In the case of TSB, all of its customers were adversely affected, all at once. Salvaging the issue would have been easier had the team thought of trialing the new system with one user-group before scaling it up to other user groups.

# 3 | Prepare an effective roll-back strategy 

Given the digital-first world we live in, system upgrades are part and parcel of life — and most of us have been at the receiving end of a frustrating upgrade that failed.

However, the interruptions don’t seem to last very long as companies either fix the issue or roll-back the upgrade.

IBM’s review of TSB suggested that since a combination of new applications and advanced microservices have been used, extensive engineering, testing and proving, as well as significant mitigation strategies, including roll-back should have been present.

For key projects, especially those in critical industries such as banking and finance, the importance of a roll-back strategy in the migration plans cannot be emphasized enough.

If TSB had one that could ‘restore’ services at the first sign of trouble, it wouldn’t lose the customers or cause the FCA to launch an investigation. Instead, a team of specialists could have simply used data from the failed upgrade, run diagnostics, plugged the issues — and prepared for the launch (in phases, ideally).