As Spanish lender Banco Sabadell’s disastrous acquisition of UK TSB has shown, banks looking to take over or merge with a rival lender should never underestimate the complexity of integrating the new business into its existing IT platform.
A few weeks ago, Spain’s second largest bank, BBVA, initiated preliminary talks over a possible merger with its smaller embattled rival, Banco Sabadell (fifth in the national pecking order). The proposed deal appeared to have everything going for it:
- BBVA was flush with cash, having just sold its US lending business to Pittsburgh’s PNC for close to €10 billion, in one of the biggest banking deals in the U.S. since the collapse of Lehman Brothers.
- BBVA is keen to strengthen its position in its domestic market, after Spain’s third-largest lender, Caixabank, recently agreed to tie the knot with majority state-owned Bankia to create a new market leader.
- After its own disastrous merger with UK lender TSB, Sabadell is on the ropes and has been looking to merge with another Spanish bank for months.
- The proposed deal apparently enjoyed the support of the Spanish government, the Bank of Spain, regulatory authorities in Brussels and Frankfurt, as well as the gushing approval of Spain’s financial press.
Yet it was not to be. In a standalone statement, BBVA said that talks with Banco de Sabadell had ended “without a deal,” allegedly due to differences over price. An insider cited by the FT described the collapse in talks as “embarrassing”, given the widespread media and political support for the deal in Madrid and Brussels.
“It was a very surprising piece of news to wake up to this morning, this crashed and burned so quickly… [It is] difficult to explain and quite embarrassing because there was such supportive momentum among the media and regulators, for it to explode apart isn’t a good look”.
The “Biggest IT Disaster in British Banking History,”
Besides the reported differences over price, there are plenty of other possible reasons why the deal “crashed and burned”. Apparently Sabadell treated the proposed deal as a merger between relative equals, whereas BBVA, whose market cap is over ten times bigger than Sabadell’s, saw it more as an acquisition. Perhaps BBVA’s analysts, after taking a look under Sabadell’s bonnet, didn’t like what they saw. Maybe they got a glimpse of the true state of Sabadell’s financial health following its disastrous acquisition, in 2015, of mid-sized UK lender TSB, for €2.3 billion.
Experts at the time warned that Sabadell was significantly overpaying for TSB while underestimating the potential costs of integrating the new business into its existing IT platform. But Sabadell ignored the warnings and went ahead with the operation, believing that it would serve as a catapult onto the international scene as well as cement its place as a pioneer in Internet banking. In both cases, the exact opposite happened.
Branded the “biggest IT disaster in British banking history,” the botched IT upgrade led to hundreds of thousands of customers being unable to access their online accounts for weeks on end. Standing orders, payrolls, mortgage instalments and other payments and transfers failed. Thousands of customers fell victim to fraud attacks. Even when the bank tried to apologize, it sent apologies out to the wrong people, in the process breaking the EU’s new data protection laws.
At the root of all this chaos was Sabadell’s stubborn determination to get the new IT system up and running as swiftly as possible, in order to save millions of euros in monthly fees it was having to pay to TSB’s former parent company, Lloyds Bank plc, to use its old legacy IT system. Sabadell’s Proteo4UK system was not even close to being ready to roll out at TSB, as IBM consultants brought in to try to remedy the problems have since attested. But senior management went ahead anyway, adopting, as one insider put it, a hope-and-pray attitude.
The Sabadell / TSB IT merger is an extreme example of what can happen when merging two very different IT systems goes visibly wrong, says Clive, speaking from over 20 years’ experience as a project manager for a too-big-to-fail European bank. But often, Clive adds, the problems are far less visible:
What’s less obvious is how often hundreds of millions of dollars of investment gets sunk into IT migration programmes before the banks involved manage to pull themselves back from the brink and cancel the merger. Not only do these represent a waste of resources (and eat up bank capital), they also leave whatever problems that initiated the impetus to merge IT systems in the first place unaddressed. More simply, it becomes easier to let a rickety patchwork of separate systems stagger on than to try to implement a risky integration strategy.
Of course, that does not mean you’re out of the woods. Just ask Deutsche Bank, for instance, what happens when you run on flaky IT systems, this being just the latest of many, many examples of their intractable problems.
Caught, then, between the rock of an aging and virtually-unmanageable IT estate and the hard place of attempting a big IT integration task, some, like TSB do decide to opt for going to a hard place. There has been an official so-called “independent” report into the TSB debacle which while, to be fair, did give a comprehensive assessment of the events leading up to the botched migration and also an excellent “Seconds from Disaster” genre style rundown of events, it still pulls its most important punch. One of the most interesting sections in the report is that on pg. 20 in Fig 4.1.
As gloomily noted, in the past five years or so of available experience in bank IT mergers, no merger seems to have been able to migrate everything. The scope always had to be cut. Either some products were left unmerged, or some channels weren’t touched or even entire market segments (like commercial or corporate) had to be left behind.
The unstated, but to me inescapable, conclusion is that bank IT which has grown in an unplanned and organic fashion over the past 50 years — and there are indeed documented examples of systems and code this old which are still in use today, largely untouched since their original implementations — are simply unmergeable if the scope of the intended merger is to be “everything”.
Paying the Price for “Everything”
Sabadell’s senior management and in-house IT provider Sabis wanted to merge everything — or as close to everything as possible. And as quickly as possible. Without carrying out the rigorous tests necessary to prove production readiness. The result was chaos.
Predictably, management at the Spanish bank emerged largely unscathed from the fiasco, while the bank itself, including its shareholders, has paid a huge price. It has had to shell out hundreds of millions of euros to undo the IT problems it itself created at TSB, including contracting IBM to rectify the issues and accounting errors. At the beginning of this year, Sabadell bit the bullet and paid “Big Blue” $1 billion to take full control of TSB’s IT systems.
Since April 2018, when the IT upgrade went live, Sabadell’s shares have slumped around 80%, from €1.70 a piece to €0.35. The price-to-book value ratio — an indicator often used to reflect the value market participants attach to a company’s equity — is now less than 0.2%. Normally, when a company’s P/B ratio falls below 1, it means the market is either undervaluing it and as such it could be good value, or the company is in trouble. When the ratio slumps below 0.2%, as is the case with Sabadell, it’s almost certain to be the latter.
There’s no way of knowing for sure how big a part Sabadell’s ownership of TSB played in jettisoning the merger talks with BBVA. Both banks have revealed little about their actual motives, but one thing that did leak out during the talks is that BBVA had scant interest in acquiring TSB.
Now that BBVA’s offer to take over Sabadell has been taken off the table, Sabadell says it is seeking “strategic alternatives for creating value with regard to the group’s international assets, including TSB”. In other words, it will try to offload TSB, no doubt incurring big losses in the process. With the virus crisis raging and the UK about to sever its ties with the EU, now is not exactly a good time to sell a British bank under duress, especially one that keeps losing money. According to the finance section of El País, Goldman Sachs analysts hired by Sabadell to help formulate a survival strategy for the Spanish lender have placed the current value of the UK lender at or even below zero.
Under its new survival plan, Sabadell will also try to offload its operations in Mexico, lay off 1,800 workers in Spain and close 164 TSB branches. Once all that is done, the bank says it will refocus its attentions on its domestic market, Spain. In other words, back to square-one. The problem with this plan is that Spain’s tourism-dependent economy has been hit harder by the fallout of the virus crisis than just about any other European economy. Through its vast portfolio of small business loans, many of which will soon be souring as debt holidays come to an end, Sabadell will be heavily exposed to that fallout.
One possible silver lining of all this sorry mess is that central bankers, regulators and senior executives of other banks may have actually learnt a thing or two from Sabadell’s masterclass on what not to do when it comes to merging IT systems. However, as Clive says, “while central banks and regulators may see the upsides in bank mergers, perhaps as stealth recapitalisations for failed or failing institutions, or an attempt to create larger entities to compete on the global stage (notwithstanding how many times that has been shown to be little more than a pipe dream) or even to try to keep all their problems in one place to better keep an eye on them, few have any real knowledge of experience of what a bank merger entails as a practical exercise”:
Still, if you’re willing to throw enough time and money at a problem, it might, eventually, prove to be solvable. Given sufficient political willpower, it’s vaguely conceivable. And most of the issues with bank IT mergers historically have come from too little investment and too little time being allotted to the work required. There is, though, a final sting in the tail if we return to our original premise of creating one, or more, sizable pan-European banking giant (or giants). As the Slaughter and May report on the botched TSB merger highlighted — it devoted an entire chapter to it (Chapter7) — what proved fatal to the TSB/Sabadell IT integration programme was the requirement to provide country-specific, regulation-specific and 3rd-party-interface-specific customisation to what should have been a lift-and-drop migration.
Even if sufficient resources and time were made available, backed up by political and regulatory commitment, and you could, somehow, genuinely merge one or several smaller-scale regional bank players and their IT, how would you ever subsequently change-manage the resultant fiendishly complex IT system you’d end up creating?
There’s two basic options. The first is that the customisation and local market, legal and regulatory-specific feature sets diverge over time so that, even if you start off with what you could reasonably describe as a single system, you end up back with the same old divergences that plagued you to begin with. The other is that you try to completely integrate all banking regulation and national legal frameworks in an attempt to prevent the fragmentation from creeping in again. The former scarcely seems desirable, but the latter scarcely seems plausible.
I would bet money the only documentation of any use in old IT system is the source code itself.
The world is drowning in software, and I cannot conceive hos the world will cope when all the plethora of current “new” code in a variety of programming languages is 40 years old.
2% of the current expense budget spent yearly over 40 years ends up as 80% of the expense budget in 40 years from now, for new systems, spent over 3 or 4 years,
If they even have the source code. Mainframes are from a time when disk space is expensive so files are automatically backed up onto tape and deleted from the drive. Also, tapes are re-used. So source code which is not constantly being updated stands a real chance of being permanently deleted.
I personally know of one case where this happened and have heard rumours that it isn’t all that uncommon.
Sometimes all the documentation is in one person’s head; if he’s hit by a Mack truck, it’s all over. In the 80s, after a couple of mergers, we on the west coast had an IBM shop, headquartered on the east that closed promptly at 2.00 our time. Computer room was filled with overhead tape racks, the Data General and the Wang were in another room, and the PDP 2 was on the floor, where one person knew how to keep it running. He went on vacation, and a couple of departments had to do everything by hand for a week
Read years ago that some corporations seeking to make themselves resilient to being taken over by hostile firms would ‘sour the milk’ by taking on toxic levels of debt. One look at the books and those firms would lose all interest in that corporation. After what happened to Sabadell because of arrogant, cheap management, perhaps it might be better if possible to have some corporations develop an opaque, obscure IT system to do the same. One with no documentation. And running software developed in-house using their own standards and their own obscure formats. Maybe using software from the 90s that runs only on Windows 98 SE.
This happens enough times organically without doing it on purpose. E.g with the fewer and fewer manufacturing companies where the documentation for all those machines is very out of date and the manufacturer of most machines out of business for years.
It would also incur a real world constant cost each year due to inefficient IT if you do it in purpose which might be costly in itself.
While the difficulties of those who borrow short to lend long (so-called “maturity transformation”) can be amusing, the real question is why those difficulties should affect the real economy?
And the answer is that we have only a SINGLE* payment system that must work through those clowns (aka “the banks”) or not at all.
*Besides grubby coins and paper Central Bank Notes.
IT vendors are notorious for downplaying the potential nightmare nested in integration projects. The complexity is usually brushed off by suggesting to non-technical clients that all integration is is building a couple of bi-directional interfaces between disparate systems, add a dose of customization and voila, your integration is served on a plate with a side of change management thrown in to prepare the client to pony up the cash for the (hefty) invoice. It doesn’t help that most clients don’t have in-house experts with the technical chops to call BS on these vendor promises and ground the project in a realistic appraisal of the complexities of even mid-scale integration. In reality, integration is hard, and is doubly so in highly regulated industries like banking where all manner of regulatory requirements have to be baked into the scope of the project.
in highly regulated industries like banking Thuto
Here again we have the problem of having only a SINGLE payment system that MUST work through private banks or not at all.
Thanks for the additional testimony.
I remember that in the early 2000s the Royal Bank of Scotland, spent some $350 million to outsource its IT functions to IBM.
A couple of years later the entire thing failed and RBS spent another $350 million to insource IT.
This came as no surprise to anyone actually involved in IT infrastructure.
Some of you may recall the failed Washington Mutual, at one time the 6th largest bank in the US, with wreckage bought by JP Morgan Chase in an FDIC-supported action in 2008. WaMu had grown via acquisition, and in the go go mortgage times in 2004 – 2008, there were something like 9 different loan origination systems in operation, inherited from acquisitions and often overlapping on what to customers would look like a single mortgage product. As you’d expect, these weren’t the only duplicative systems in use. I worked in an IT-adjacent function and it was mystifying as to how the bank was able to operate with this back-end. As well, the inefficiencies of duplicative and incompatible IT systems contributed to the bank having a higher cost structure than competitors . . . and this cost structure, together with management stupidity and greed, drove the bank to chase top line growth at all costs in the subprime and alt-a markets. Ultimate results were relatively predictable. I’ve often wondered how or if JP Morgan chase has fixed these problems, or whether WaMu’s pile of rickety systems were just incremental additions to an existing similar mess at JPMC.
It was around 2006 when I started reading Tanta at Calculated Risk, and this led me to the point of view that most banks are likely a similar house of IT cards. Articles and comments here at NC have only reinforced my sentiments. And, honestly, the systems have grown too complex to be easily fixed by anyone, even if there were appetite and ability to invest in the same.
I would say there is probably less risk involved in an intra-Eurozone merger vs one between two banks within the EU but with different base currencies. A lot but not all of the intra-Eurozone payments systems have been harmonized. Nonetheless there are significant integration risks in mergers. Interestingly enough what you are now seeing the US with the Reigle-Neal 10% deposit cap for new acquisitions starting to kick is banks like JPM are now opening new de novo branches in areas of the US where they did not previously have a physical presence. For example JPM opening branches in places like Fargo, ND or Little Rock, AR.
The Canadian government had a big fail in IT called the Phoenix system between two opposing government parties that lasted far too long.
That’s harmonization of external interfaces, which aren’t used much, if at all, in internal processes. Therefore this doesn’t help when merging.