Posted on FinExtra: 


There’s a lot about TESLA’s way of doing business I admire; especially when I think about what it could bring to the world of financial technology. I don’t mean a banking system powered by lithium-ion batteries or setting up branches on Mars (at least, not yet anyway), but Tesla’s approach to upgrading users’ software automatically is something the banking industry should actively look into.

I’m a proud owner of a TESLA vehicle myself. When you park the car, and the system is idle, any software updates are automatically downloaded and installed. When you enter the car again, you will be informed on the large screen about the new version of the software. If required, you will be guided through the new features and changes. It’s as easy as that – and I experience the benefits straight away, without having to worry about visiting a dealer or the car system falling behind newer models.

Applying this to banking, why can’t software updates – covering applications from trade finance to payments – be handled in a similar way? I’m sure many bankers dream of a world in which they don’t need to worry about system upgrades, with the large projects and the complexity involved. To my mind, I don’t think we’re far away from automating this process and making it a reality.

The upgrade challenge

First let’s consider the scale of the problem. Over the years banks have implemented a wide range of product systems across each line of business, often separate silo systems, with the need to customise the software to meet their exact requirements. While customising the source code seemed a good idea at the time, when it comes to subsequently upgrading to new releases or new versions, it creates major headaches as custom edits are simply not supported. At best it’s time consuming and inconvenient to resolve this, at worst it can lead to serious errors and failure in business processes – unless significant time and effort is spent mitigating the risk and managing the upgrade process.

Given the scale of the task, it’s not uncommon for banks to refuse routine upgrades and to find themselves in a situation where they haven’t upgraded for many years. They can then be faced with the stark fact that the system will no longer be supported, or is unable to accommodate new industry requirements or SWIFT upgrades.

The situation is often further compounded when banks have rolled out separate instances of the same software across their international offices and customized each on a local basis, ending up with one source code of each product system per country. Often an army of consultants is required even to carry out a simple upgrade. Such a process certainly doesn’t come cheap – and it can take years for the bank just to catch up to the latest release.

What can be done?

The answer to the problem is relatively simple. Banks should implement a flexible, adaptable and functionally rich IT solution, designed and developed as a global package and where the provider can commit to maintaining and supporting one single global source code. The solution would include “development tools” to enable the bank to implement the required customisation and introduce new products, changes in pricing, new business rules etc – without leaving the standard package, without ending up with a separate source code and without development projects.  A solution developed in this way paves the way for automatic testing systems and automatic upgrade systems, which in turn allow upgrades to be rolled out as often as required, be that annually, monthly or even weekly. Such an approach could allow global upgrades to be rolled-out more or less automatically – in agreement with the bank – and with no impact on the day-to-day operation of the business. 

Sound simple? It is, but only if one designs and develops IT Solutions with these goals as one of the main requirements. This kind of development makes sense and I predict it will become the standard across the industry in the years to come.

If you’re reading this Elon… No need to get involved, the issue’s being solved.