I have a bank account with TSB and got compensation as a result of this mix-up.<p>Some rather personal experiences of the fiasco:<p>– Rather pointlessly, the website changed from being mostly static to entirely written in a very JS-heavy, "dynamic" way. I still can't use it in my normal browser (FF) with its extensions because it relies heavily upon CORS requests and referrer information that my somewhat privacy-paranoid extensions block.<p>– This was introduced at the time of the switchover, and until that point the IT system used looked identical between Lloyds, TSB and Halifax / BOS systems (I have accounts with some of those)<p>– The online browser-based system was telemetry and JS heavy, replacing a far leaner page<p>– I was unable to log in during the time of the fiasco, mostly due to 403 errors or timeouts. Often the page would just hang as an async request wasn't answered.<p>– Once I did manage to log in, I was amazed to see another person's account details (!!!), replete with (their) name and statement.<p>– I was unable to use online banking to pay bills or check my balance – I could see someone else's account in detail but was too honest to do anything with that knowledge. I can't remember if my card stopped working but I was effectively forced to make other arrangements for quite an extended period of time.
The 250+ page analysis of the incident was an excellent insight into how large IT projects fail: <a href="https://www.tsb.co.uk/news-releases/slaughter-and-may/slaughter-and-may-report.pdf" rel="nofollow">https://www.tsb.co.uk/news-releases/slaughter-and-may/slaugh...</a><p>money quote:
> This situation has all the hallmarks of business management strong-arming the IT organization into an unrealistic timeline. When business leaders push for overly-aggressive timelines, or regulators ask for multiple competing risk frameworks and excessive after-the-fact incident reporting, this all puts a strain on the delivery organization’s ability to untangle the complexity before ‘go live’.
2008: "The UK-based IT department of the fifth largest bank continues to dwindle as more jobs go overseas... This round of cuts, starting in June and lasting 12 months, involves up to 250 permanent IT roles and 200 contractors from the bank's technical delivery division, responsible for software development and design." [1]<p>2018: "Timeline of trouble: how the TSB IT meltdown unfolded". [2]<p>It's probably more complicated than that, but perhaps not much more complicated.<p>[1] <a href="https://www.itpro.co.uk/197982/lloyds-tsb-cuts-more-uk-it-jobs" rel="nofollow">https://www.itpro.co.uk/197982/lloyds-tsb-cuts-more-uk-it-jo...</a>
[2] <a href="https://www.theguardian.com/business/2018/jun/06/timeline-of-trouble-how-the-tsb-it-meltdown-unfolded" rel="nofollow">https://www.theguardian.com/business/2018/jun/06/timeline-of...</a>
I will always remember this incident as the time when the UK general public were exposed, en masse, to Spring error messages.<p>The confusion caused by ordering a member of the general public not to request a bean from a bean factory in a destroy method implementation still makes me laugh, even now.
Sounds like classic A type personalities with zero technical chops deciding how long a technical project should take to further their own agenda:<p>> The Migration Programme experienced delays from the outset and fell behind the IMP timings. While progress had been made, on 20 September 2017 the firm decided that the Migration Programme would have to be re-planned. However, nine days after it had resolved to re-plan, and before it had concluded its re-planning exercise, TSB publicly announced it would now migrate in Q1 2018.
It's not just the CEO who should've been fired. The COO, CTO and CIO also should've left the building with a cardboard box in their hands.<p>This is a shameless indulgence in incompetence and recklessness. They didn't even bother to test large swaths of the transitional data or have a fallback plan if things went wrong.<p>Most likely their customers will now simply leave and the bank will be shut down.
I sneer at the emphasis on “1.4 billion records!” in the article as if it’s a lot.<p>At a recent place of employment I created and was responsible for a database that had about that many records and in actuality was a single 2tb postgres db and completely unremarkable.<p>I never claimed to have worked with big data.
Hopefully Virgin Money will get one too. They broke their Android app earlier this year and since they make you verify web logins using the app I was unable to access any of my business accounts for ~3 weeks.<p>If something really urgent had come up I could have done what I needed via telephone banking or in a branch, but it was a huge pain in the arse because of a single point of failure.<p>Just let me use a Yubikey as my second factor damnit.
The actual report by the FCA: <a href="https://www.fca.org.uk/publication/final-notices/tsb-bank-plc-2022.pdf" rel="nofollow">https://www.fca.org.uk/publication/final-notices/tsb-bank-pl...</a>
Discussed variously at the time, eg.<p><a href="https://news.ycombinator.com/item?id=16910947" rel="nofollow">https://news.ycombinator.com/item?id=16910947</a><p>Others<p><a href="https://hn.algolia.com/?dateEnd=1600300800&dateRange=custom&dateStart=1515110400&page=0&prefix=false&query=tsb&sort=byPopularity&type=story" rel="nofollow">https://hn.algolia.com/?dateEnd=1600300800&dateRange=custom&...</a>
i remember this. for at least a week people couldn't access their money. it was chaos. the bank lost lots of money and customers due to this botched transfer.
I remember when this all happened. Would be interesting if it was the result of some really interesting technical bug that nobody could have foresaw followed by a fascinating effort to save the migration.<p>In fact it was all quite boring and simply the result of the sheer incompetence of the bank’s leadership in running bank IT.