Why banks are struggling to update their ageing IT

“Spaghet­ti sys­tems” is a catchy name for a ter­ri­ble prob­lem. Go back­stage at most banks and the tech sce­nario is usu­al­ly a tan­gled mess. Thou­sands of appli­ca­tions are patched togeth­er, with some of the most crit­i­cal plat­forms dat­ing back to the 1980s. Cash machines still run Cobol, writ­ten in 1959.

This spaghet­ti leads to dis­as­ters. IT teams are ter­ri­fied of updat­ing ancient appli­ca­tions. Sys­tems go down. Errors creep in. On one occa­sion the Finan­cial Con­duct Author­i­ty iden­ti­fied 750,000 cus­tomers pay­ing the wrong amount in mort­gages – a dis­as­ter for those involved. The cost of bank sys­tems is mind-blow­ing. Bank of Amer­i­ca allo­cat­ed $10bn in a sin­gle year to mod­ernise its IT, while JP Mor­gan spent $11.4bn. 

But why are banks stuck with out-of-date soft­ware? It’s not down to desire. Banks talk a great game about the need to mod­ernise.

There’s even an agreed method­ol­o­gy to upgrade. Instead of run­ning appli­ca­tions with a mono­lith­ic code base, banks should chop them up into pieces, called microser­vices. Each microser­vice can run autonomous­ly, oper­at­ed by a team focused exclu­sive­ly on their own sub-domain. It means upgrades can be done much faster. 

And then there’s Con­tin­u­ous Inte­gra­tion and Con­tin­u­ous Deploy­ment (CI/CD). This means code is updat­ed reg­u­lar­ly in a bliz­zard of tiny improve­ments, rather than a big bang upgrade every year or six months. Ama­zon, for exam­ple, updates its code every 11 sec­onds. The advan­tage is that each tweak can be test­ed indi­vid­u­al­ly. If it works, it’s retained. If not, the ver­sion is rolled back. 

Cutting-edge software

If banks embraced CI/CD, the soft­ware would always be cut­ting edge, as it would always be improv­ing. “It’s a much quick­er and more effi­cient way of rolling out prod­ucts and ser­vices,” says Pre­ma Varad­han, deputy chief prod­uct offi­cer at Temenos, one of the world’s largest providers of bank­ing soft­ware. “The ben­e­fits are numer­ous and vast. It enables banks to inno­vate at a much faster pace and respond much more quick­ly to rapid­ly chang­ing cus­tomer needs. This in turn gives cus­tomers a much bet­ter expe­ri­ence and makes them much stick­i­er, which clear­ly has finan­cial ben­e­fits.”

Varad­han says CI/CD can end the crip­pling finan­cial bur­den of soft­ware. “Banks can make changes in this man­ner at a frac­tion of the cost of try­ing to achieve the same results on lega­cy sys­tems. And as the inno­va­tion becomes fre­quent, banks can fail fast, fix, improve and this in turn will reduce accu­mu­lat­ing tech­ni­cal debt and costs in the longer run.”

And the down­sides of CI/CD? “Ben­e­fits far out­weighs any costs or com­pli­ca­tions of adopt­ing this method­ol­o­gy,” says Varad­han.

So why is CI/CD so under-used? Reg­u­la­tions are restric­tive. Where­as a retail busi­ness can exper­i­ment with the stack, risk­ing down­time in a worst-case sce­nario, bank reg­u­la­tors for­bid any cav­a­lier behav­iour. This means even fin­tech com­pa­nies, who pro­mote CI/CD as a prac­tice, are ultra-cau­tious about its usage. 

Mark Holt, chief prod­uct and engi­neer­ing offi­cer at 10x Future Tech­nolo­gies and for­mer CTO at Train­line, says this cau­tion is well found­ed. “It’s impor­tant to recog­nise that, in busi­ness, con­text is every­thing,” says Holt. “While in some busi­ness­es, con­tin­u­ous pro­duc­tion releas­es – and roll backs where fea­tures don’t work – is the best approach, a fail­ing fea­ture in bank­ing just isn’t appro­pri­ate. A fail­ing fea­ture being in pro­duc­tion for just 30 sec­onds may be the dif­fer­ence between a customer’s pay­ment suc­cess and pay­ment fail­ure, which could mean the dif­fer­ence between them safe­ly get­ting home that evening or not.”

The answer for 10X is to retain a phi­los­o­phy of CI/CD, but to delay the release pat­tern until test­ing is over and part­ners are pre­pared. “Because of this, we bal­ance risk by releas­ing and test­ing con­tin­u­ous­ly with­in our devel­op­ment and test envi­ron­ments, and then per­form month­ly releas­es into client bank­ing envi­ron­ments to ensure they have the robust­ness to deliv­er for end-cus­tomers,” Holt explains. 

Human element

Then there’s the human ele­ment. The archa­ic nature of bank soft­ware means IT teams may strug­gle to under­stand new­er prac­tices. Gae­tano Ziri, soft­ware engi­neer at Auri­ga, an Ital­ian provider of bank soft­ware, says the human issue is the main rea­son banks are slow to move to CI/CD. The skills required are so broad. Ziri says a pro­fes­sion­al will need the abil­i­ty to man­age cloud providers such as Ama­zon Web Ser­vices and Google Cloud: famil­iar­i­ty with soft­ware pack­ing tools (.exe, .deb, .rpm, Dock­er); famil­iar­i­ty with ver­sion con­trol tools (Git, Sub­ver­sion, Mer­cu­r­ial), plus exper­tise in secu­ri­ty tools, code cov­er­age ana­lyt­i­cal tools and mon­i­tor­ing tools. And that’s before an organ­i­sa­tion’s cul­ture is tak­en into account. 

“Many busi­ness­es still pre­fer tra­di­tion­al method­olo­gies when it comes to soft­ware devel­op­ment,” says Ziri. “Imple­ment­ing Con­tin­u­ous Inte­gra­tion means that they would have to retrain their staff and also change exist­ing oper­a­tions. Most com­pa­nies want to meet their objec­tives quick­ly and may be resis­tant to change.”

Some­times banks are just too old to imple­ment effec­tive CI/CD. Varad­han says auto­mat­ed test­ing may not be pos­si­ble in spaghet­ti sys­tem tech envi­ron­ments. “Test­ing mod­erni­sa­tion requires access to con­sis­tent and qual­i­ty data to be able to repli­cate real pro­duc­tion-like sce­nar­ios,” she says. “Yet in many organ­i­sa­tions, data pro­vi­sion­ing remains a very man­u­al process, which is both slow and unre­li­able, and results in out-of-date data.”

Where does that leave banks? CI/CD is clear­ly the future. Just like Google, Ama­zon, Uber, Spo­ti­fy and oth­er tech pio­neers, banks will be able to upgrade soft­ware bit by bit, ele­ment by ele­ment. It will make them agile, able to imple­ment even small improve­ments with the min­i­mum of fuss. Neobanks already enjoy the ben­e­fits of CI/CD. Star­ling Bank, for exam­ple, is a major ben­e­fi­cia­ry. 

But larg­er banks remain behind the curve. They may not have the staff for CI/CD, nor the cul­ture. Reg­u­la­tion pre­cludes rapid adop­tion or deploy­ment. And the prospect of rip­ping out spaghet­ti sys­tems is intim­i­dat­ing. 

It’s a valu­able issue to under­stand. Banks want to move on from the era of spaghet­ti sys­tems. They want to mod­ernise. The desire is nev­er in doubt. 

But when cus­tomers, part­ners, and com­men­ta­tors scratch their heads and won­der why banks don’t adopt CI/CD imme­di­ate­ly, it’s worth remem­ber­ing there are good rea­sons for the gap.