UK bank execs must get to grips with software standards

Only a few weeks into 2016 and HSBC, RBS and NatWest have already suffered outages that have left customers unable to access their online bank accounts or make some transactions.

These are just the latest in a series of IT failures which continue to disrupt and undermine the credibility of these institutions and chip away at what is already a perilously depleted store of public confidence. Still, despite the anxiety these incidents must be causing, it feels like it is only a matter of time before we are discussing the next 'glitch' or 'technical issue' to bring one of these banking giants to their knees.

So what's the problem? Fundamentally the core banking applications that some of these banks use are more than 30 years old. On top of this dated foundation are a series of software updates, patches and programmes offering customers new services such as online banking and contactless payment. 

A bank’s IT builds up over many years, created by a myriad of different teams, writing in different programming languages on different machines in multiple locations. The systems then become the product of hasty and ill-considered mergers. Problems are inevitable, fixing them can take years and cost a fortune.

The problem these banks face is a lack of software transparency. Traditional software quality assurance (QA) consists of functional and load testing, yet around a third of glitches are found in the very architecture of the software – glitches which can lay dormant for years until additional functionality or a new update exposes it and the system falls over.

  

CAST believes the financial services industry needs standard, low cost, automated measures for evaluating software size and structural quality that can be used in controlling the risk of software that is produced either internally or by third parties.

Code quality standards such as those developed by the Consortium for IT Software Quality (CISQ) can be used to detect critical violations of good coding and architectural practice in software. Employing architectural and structural analysis tools in accordance with the CISQ standards offers insight which non-IT executives can use to identify which applications present the greatest risk to their business and address them accordingly.

This level of insight is key as the top management at these major banks don’t seem to understand the complexity of the technology they’re managing, leaving the responsibility for reliability to their development teams. 

These teams try to do a good job, but are pushed to deliver digital transformation, the next marketing program and the next customer service functionality as soon as possible. As a result, software integrity drops down the list of priorities and the risk builds. 

Essentially, neither developers nor management have all the information in one place to make informed decisions. IT executives do not consider issues with software structure to be their concern, but it’s these that account for the majority of software disasters. Top management need to recognise software integrity as a business-critical issue and take ownership over enterprise IT.

By Vishal Bhatnagar, 

SVP and Country Manager, CAST UK