Home / Opinion / Why would a bank change their core system?

Why would a bank change their core system?

I was asked a question about why a bank would change their core system the other day.

There are lots of reasons why a bank would change their core system.

Here’s my top five:

  • Legacy constraints: this is the most obvious one, but it does not create a reason for changing a core system in or of itself. After all, I know of plenty of banks that continue to operate processors and applications developed in the 1960s and 1970s because the view is: ‘if it ain’t’ broke, leave it’. That’s why many City institutions still have a need for FORTRAN and ASSEMBLER programmers, and why some banks process transactions converted to pounds, shillings and pence (pre-decimal systems should have been dropped in 1971!). It is because these systems worked and were too expensive to change back in the 1970s and 1980s. Now, fifty years later, they have the problem that they are too incomprehensible to change. After all, many of the folks who developed these systems didn’t document them and the developers are now retired, suffering from dementia or dead. So the bank keeps them running as they can’t dump them. However, if the legacy is causing them to be uncompetitive and to lose business, then that may finally prompt the change of core system that has been so strategically required for decades but ignored. This leads us to the next major reason for change: competitors.
  • Competition: a bank will often change systems if competitive pressures force them to. For example, no bank wanted to launch call centre or online banking services until someone launched it first and started taking accounts away from them. This is why banks are variously described as sheep or lemmings, because they all follow each other around and copy what each other is doing. The result is that if a new core system capability delivers significant competitive differentiation for a financial institution, then all the other institutions will either buy the same system, buy a similar one from the provider’s competitors or will copy it.
  • Regulations: all of the regulations that have been introduced over the past few years such as MiFID, the PSD, Faster Payments, the Capital Requirements Directive, RegNMS, MT202 Cover Payments and more, have required significant change to systems, structure and processes for the banks and operators in those market sectors impacted. Therefore, every time there’s a legislative change, it will more than likely prompt an assessment as to the fitness for purpose of the existing system to meet and comply with the new obligation and, if they don’t comply or if it is too difficult to adapt, then the bank will change core system.
  • Merger and acquisition: every time a bank merger occurs, there has to be a rationalisation of systems as that is a core rationale for justification of a merger. In other words, cost savings… there is absolutely no rhyme or reason as to why a bank would run two parallel core systems as that would mean twice the cost. Therefore, one of the core systems will change. Unfortunately, it usually means that the core system changes by throwing out the system of the acquired bank and converting it across to the acquirer’s platforms. This has little to do with effectiveness or efficiency and is more to do with ego and power. For example, NatWest’s systems were forced onto Royal Bank of Scotland’s when RBS took over NatWest a decade ago and, more recently, Abbey’s were dumped and converted to Santander’s. In retrospect, it would make more sense for a fuller review to take place before such decisions are made to ask: (a) which is the best system and (b) is there a better one outside the bank overall? Having said that, I cannot imagine any bank converting both their own and their acquired banks systems across to a new platform at the same time but, when acquiring a bank, it would be a good time to consider converting the acquired bank’s core system to the best in the market and, if that means buying externally, then convert your own core systems across to the same platform thereafter.
  • New management: again, it is often just a case of ego and power, but when a new management takeover a bank, the first thing they want to do is to stamp their authority on it. This can be done in two ways: first, sack all of the sycophants who worked for the previous management team; second, replace all of their decisions with new ones that show how ineffective their decisions were. The latter means finding things they did or did not do, and then showing how stupid they were. For example, not replacing an old legacy system may be a good way to highlight this; or the fact that they replaced core systems but didn’t choose a good one is another. Either way, a new management team, given the right prodding, could easily be convinced to change core systems if they thought the previous management had been shirking their responsibilities by not changing it or changing it for a poorer one.

So there you have five good reasons to change core systems: legacy constraints, competitive forces, regulatory mandate, merger and acquisition and new management requirements.

Thinking about these things, the post-crisis fallout means that all of the above are rife. Many banks have new management teams, are going through a tumultuous acquisition, have been forced to change due to regulation, and have new competitors and new customer needs that put a strain on their legacy operations.

This means that 2010 onwards is a great time to see core systems change in many European and American banks.

However, there’s one point that is not made above that is just as critical.

No bank will change a core system because of new technology.

New technologies are great. They may be sexy, interesting, create differential and be very compelling, but new technologies in and of themselves will never justify a core systems change.

It is only when the new technology can demonstrate that it will support the needs to be compliant with new legislation; or to eradicate legacy overhead for operational efficiency; or to improve management and business processes that the bank can maintain competitive parity now and into the future; that the systems are purchased.

In other words, the debate about core systems has nothing to do with the features and functionality of the technology itself, but is triggered by a burning platform that means that if the bank does not change the core system they will flounder.

That is the key to why banks change core systems and the sooner providers get off the feature, functionality and technology platform and get on to the business need, management drivers and strategic platforms, the better.

*

The Financial Services Club is sponsored:
Cisco

For details of sponsorship email us

About Chris M Skinner

Chris M Skinner
Chris Skinner is best known as an independent commentator on the financial markets through his blog, the Finanser.com, as author of the bestselling book Digital Bank, and Chair of the European networking forum the Financial Services Club. He has been voted one of the most influential people in banking by The Financial Brand (as well as one of the best blogs), a FinTech Titan (Next Bank), one of the Fintech Leaders you need to follow (City AM, Deluxe and Jax Finance), as well as one of the Top 40 most influential people in financial technology by the Wall Street Journal’s Financial News. To learn more click here...

Check Also

Don’t be so blasé about people loving FinTech

I find it interesting as we move towards Open Banking and Open APIs through regulations …

  • Fantastic article Chris! I would extend on the legacy constraints and say that for banks the driver should be rapid, but consistent service delivery across all channels.
    Current system silos and difficulties in adapting messaging layers to increasingly diverse channel architecture and presentation layers are a good driver for scrapping legacy systems.

  • Cagatay Duruk

    On‘if it ain’t’ broke, leave it’: I believe there is a also a psychological factor here: Because changing the core system is a very big change, how efficient your initial analysis may be, you may end up with failure, or the better, unpleasant users and clients. Given that, it is very unlikely for employees to propose a core system change. In that case it is only done when you have to do it(the top five you mentioned). And what happens when you do something not because you want to, but you have to?

  • Chris Skinner

    Comment on swiftcommunity from Graham:
    Chris;
    Your text-book, politically correct stance does us a dis-service. Managers in banks responsible for systems development are scared. They have heard of too many horror stories. For instance in 2004 there was a hue-and-cry when National Australia Bank lost $180 to rogue traders. But it largely went under the radar when they wrote off more than $400M in their IT systems, partially due to cancelled IT projects.
    If I want to keep my job I therefore don’t do anything so I can’t make a mistake. The net result is – the bank is eventually placed in a position of high risk and high maintainance cost.
    So what’s a manager to do?
    Well – It boggles the mind that poor project management still happens in this day and age. We know how to avoid the pitfalls of software development but keep them. THere are people who can do this but banks seem to want to go for the mega-companies that do not have a good track record. They seem to want a “big-bum-to-kick” rather than take the time to hire competence.
    A manager in a bank. with responsibility for IT systems must run, not walk, to adopt an enterprise architecture approach. If they have not split up their architecture into at least technology, applications, information (or data) and business systems – they are spending too much on their IT. They must also take a services-bus approach. There should be one identity service, a minimal number of transaction services, one message queue etc. Then redevelopment becomes a series of bite-sized changes that won’t break the bank.
    My reply:
    Hey Graham
    Love the idea of the ‘big bum to kick’ … now, who’s the biggest bum I know out there? Suggestions on email …
    Chris