What's this all about?
Core banking migrations are a high-risk business and the effects can be significant. But what are the alternatives? And what are the potential pitfalls banks face if they remain on a legacy system? Eoin Fleming, Chief Information Security Officer at LEVERIS, gives us the lowdown on core migrations, their limitations and effects, and outlines five alternative approaches to banking innovation.
Read on if you:
- Want the jargon-free definition of core banking
- Are interested in how to update legacy technology
- Want to know five alternatives to core migration
- Have an eye on the future of banking
A core banking migration is a bit like getting spinal surgery whilst juggling bundles of burning dollar bills. Even if successful, it’s expensive, dangerous and you will get burned.
Before we get into the expense, the burning and the pain of a core banking migration project, we first need to define what it is and then describe all the aspects involved in starting one – a project that is risky, costly and ultimately doomed to fail.
What is a core banking system?
A core banking system is essentially the nerve centre of a bank. Every transaction – regardless of how or where it is generated – eventually ends up at the core where reconciliation, reporting and accounting is finalised.
The vast majority of banks have been in operation for more than 30 years. As such, they are tied to vintage software running on hardware which, even if new, has a design blueprint older than most of the staff operating it.
But prior to assessing why banks need to change their technology to compete effectively, we must look at the current IT landscape to understand why this is necessary.
What is a legacy core banking system?
A legacy system is effectively any system with a base hardware or software design that predates the internet. So we’re talking pre-1980s here.
Typically, you find the following hardware systems in banks (with associated and suitably geriatric software):
- Mainframe Z/OS
- iSeries AS400
- HP Integrity/Superdome OpenVMS
These old systems have, in general, the following positive and negative attributes:
- Bulletproof and proven – often highly resilient with longstanding and well-understood processes. What they do, they do very well.
- Backwards compatibility – can still run C/C++, COBOL, Assembler, REXX, Fortran code from the 1960s right up to today.
- High cost – maintenance and support require very expensive, niche skills.
- Lock-in – the vendor of the platform controls the pace of innovation. If they don’t do it, you can’t have it.
- Tech-focused – everything is focused on the system, not the customer.
- Limitation of code compatibility – you can’t run the latest version of the software or exploit new capabilities.
- Perception of security versus reality – legacy systems rely on obscurity and to some degree, isolation to provide security. ‘The mainframe has never been hacked’ is often quoted but is not correct. Few people understand mainframe security. So this is essentially a detection problem and not a proof that the system is, in fact, secure.
- Design – the core design of these systems assumes that a castle and fortress surrounds them, unlike the interconnectedness by design approach of modern systems.
What is a legacy process?
A legacy process is designed to work around, or compensate for, the limitations of a system. A digital process, however, is designed to ensure that specific attributes (such as efficiency, customer experience, speed) are maximised without reference to the underlying system.
In short, a legacy process is made to fit the system, a digital process is made to fit the needs of the customer.
Why is a legacy system an innovation stopper?
Legacy systems limit the ability of banks to operate in an agile fashion, react to change effectively and meet the user experience expectations of a generation raised on rich, interactive, intuitive digital apps.
Legacy processes tend to be in place where you find legacy systems. They further limit the ability of banks to bring innovation to fruition.
It’s important to note that banks have no issues thinking up innovative ways to do things. The challenge lies in actually bringing these approaches to market and getting them in front of customers.
Legacy system constraints
These legacy system limitations are generally imposed by the following constraints:
- Process inertia – don’t change what works, even if it would benefit the customer
- Organisational inertia – changing things requires sign-off from everybody, even if the change is cosmetic
- Rule paralysis – changing something might have an impact on regulation, security, compliance, and thus requires analysis and agreement by all
- System constraints – ‘computer says no’. Can’t be done because the underlying IT won’t support the change or would cost too much time and effort to deliver, outweighing the advantage to the customer
What are the effects of a core banking migration?
While such a major transformation is taking place – and a programme of this nature would take anywhere from two to five years – the bank must continue operating as usual.
A massive transformation process running parallel to ‘normal’ operations has the following adverse effects:
1. permanent freeze on change
Changes to the existing core system are necessarily frozen for the entire duration of the project.
Innovation that in any way touches the core cannot be implemented. If any change takes place, it impacts the configuration of the new core, leading to cascading delays, potential disruption and instability. This means that the best time to compete with a traditional bank is during a core migration because it cannot respond for at least several years.
2. resource shortage
A core migration is so complex that any bank will have its ‘A’ team working on it, leaving no resources for anything else.
The cutover date shared with the regulator is irrevocable. Once you cut over, you cannot go back. As a result, any threat to the timeline will be dealt with by removing proposed products or features. So a newly delivered core is generally less capable in the short-term than the one it has just replaced. We call this feature poverty.
Considering these potential pitfalls, it begs the question: if bank transformations are so fraught with danger, then what are the alternatives?
Five alternative approaches to core banking migrations
There are five approaches banks can take to maximise their return on investment when it comes to innovation capability for IT. Core system migration is one, but there are other approaches as well:
1. The big switch
Build or buy a new (on-premise or cloud-based) system and cut over to it at a specified time in the future. For most banks, this means obtaining a newer system from the usual legacy suspects. It involves replacing a legacy system with a new and improved legacy system in-waiting.
2. Short-term fix
Middleware integration with no backend changes. Use a middleware solution to mask and ‘tidy-up’ the limitations of the legacy backend systems by carrying out integrations at the middleware layer via APIs. The results are then translated back to the legacy environment. This can be combined with option 3.
3. Lipstick on a pig
Put a nicer-looking front-end on the existing solution without changing or altering capabilities. In other words, a nicer mobile or desktop experience with no middleware or backend changes.
4. ostrich approach
Do nothing, but hope that your competitors do the same and that your customers remain loyal.
5. Greenfield parallel
Leave the legacy system as-is. Build or buy a cloud-native, non-legacy system that has minimal integration with existing IT. Innovate and integrate there. This offers the option to cut over (or not) when desired and with no disruption.
The approach that works best for an individual bank very much depends on its strategic imperatives. Once those are known, the most suitable path can be chosen.
Core banking migrations are incredibly painful and have a high rate of failure. Even success can be painful due to feature poverty in the new system.
However, doing nothing is not an option.
A new front-end will only fool your customers for a while until a newer, better challenger bank arrives offering features you can only dream about.
Going halfway by using a middleware solution merely kicks the can down the road, creating a bigger mess to unravel when core migration cannot be put off any longer.
At LEVERIS, we have imagined a better way.
If you are looking for a low-risk, long-term technology solution for a historic legacy problem, then a ‘greenfield parallel’ approach is the only option.
This balanced approach doesn’t stop the innovation clock. Instead, it builds a parallel low-cost core on which banks can innovate. They can keep their current legacy system as is and focus on doing new business on the new platform.
Over time, these banks can sunset the old and soft migrate customers to the new.
What they will get is a low-cost, highly flexible and adaptable core banking platform. One that allows a bank to innovate, integrate and use data to improve the lives of their customers in ways they can only imagine.