What’s this all about?
Read on if you…
- Are launching a digital bank
- Are considering modernising your core banking system
- Want to set your bank up for success
It’s hard to believe that the ATM was introduced over 50 years ago – at a London Barclays in 1967 as the story goes. One author describes it as “the dawn of contemporary digital banking”. Branch transformation was a key issue even then as the nature of work changed and cashiers became more focused on sales.
With the unstoppable rise of the smartphone, we’re now asking ourselves whether there’ll be a place for ATMs in the near future with the increase of contactless and mobile payments which are expected to triple to $6 trillion worldwide by 2024. Added to that, the COVID-19 pandemic is changing our attitudes to handling cash.
It goes without saying that the way we do banking is rapidly evolving. However, most traditional banks are bound to rigid legacy technology which, amongst a raft of limitations, curbs their ability to react to the market.
Many issues in banking come down to how the infrastructure has developed in the past decades. The elements that make up a legacy system are frequently bespoke, designed in different, outdated development languages and are not built to work together end-to-end.
Core migrations are a risky business – something we addressed in a previous post. Many banks are now looking at replacing their current systems or building new business units and brands from scratch. Indeed, Deloitte suggests that 2020 might be the year of ‘build and migrate’.
As we’ve seen with attempts like the now-defunct Bó, there’s much to consider in setting a challenger digital bank up for success. The technology must deliver the end goal and not leave banks with an inflexible mess much like the one they began with. So where to start? Here are nine guidelines for choosing a core banking system that will prevent you from swapping old legacy with shiny new legacy.
1. Choose customer over product
As a result of the motley approach to legacy architecture, customer data is locked in and scattered across silos. Banks’ attempts to link up and utilise this data include the use of Master Data Management (MDM) layers which are limited in their ability to create a coherent, full picture of customer data. They don’t create a Single Customer View (SCV).
As customers, we’ve all been on the receiving end of this issue. That time you opened up your banking app and realised you can’t manage your loan in the same place as your current account. To be truly customer-centric, it’s essential to avoid a system that doesn’t have a single source of truth of customer data and the capabilities to utilise it.
2. Choose open source over proprietary programming methods
The different subsystems that make up legacy banking technology are typically not built in the same development languages. They communicate and translate data to one another with no common method of communication.
The languages used are also often outdated. Many banks employ past employees as consultants at very high rates as often, they alone have the know-how to maintain legacy systems.
To get a sense of this, consider findings that show that 43 per cent of banking systems are built on COBOL, a language that was first developed in 1959. It’s little wonder, therefore, that acquiring this expertise is becoming ever more challenging. Steer clear of outdated programming methods and instead look for a system that is built in commonly deployed languages. That way, it can be maintained and extended without introducing legacy issues.
3. Choose automation over manual intervention
According to a KPMG survey, IT resources as a percentage of total staff increased from 22 per cent in 2015 to 25 per cent in 2017.
Legacy technology also leads to increasing costs over time for banks, because as they get more customers, infrastructure and environment costs increase too.
Avoid any system that overly relies on manual processes and requires niche skills to operate. Choose one built with ubiquitous automation, an environment that can fully exploit the natural efficiencies of the cloud and which can be operated with fewer resources.
4. Choose simplicity over complexity
As well as being costly to build and maintain, legacy systems are incredibly fragile environments. Making a change to one part has an adverse domino effect on many other seemingly unconnected elements. Consequently, change has come to mean ‘disruption’, ‘difficulty’ and ‘cost’, which in turn leads banks to choose what seems like the path of least resistance (in other words, do nothing).
Modern technological principles such as modularity reduce this complexity as all elements of the system are developed to be independent yet operate together seamlessly. This means updates and feature development can be conducted per element without affecting the rest of the platform.
5. Choose one over many
Let’s imagine building a traditional bank from scratch. We’ve established what the business will look like and are now developing the infrastructure that must be built to support it. It can typically take up to ten vendors to deliver a bank. Getting them to work together is very difficult – picture a circus ringmaster and you’re on the right track.
The resulting technology is inflexible and difficult to change. For example, a product must be rebuilt, integrated at every layer of the stack and coordinated with the numerous vendors. So we end up with a system that is slow to build and operate.
Our imaginary bank would have been much quicker to launch if the standard capabilities were pre-integrated and built-in from the start from a single vendor but with the capability, enabled by APIs, to swap partners as needed.
6. Choose open not closed technology
The functionality of closed-end legacy systems cannot be easily extended – they cannot readily consume and use capabilities that exist outside their infrastructure. To achieve this, a bank needs to introduce additional translation layers, adding even more complexity.
Avoid a system that cannot integrate efficiently with third parties and instead look for one that uses APIs universally, can connect to third parties agnostically and designs products with the core logic, middleware, and user experience layers separated. That way, third-party functionality can be integrated at any layer.
7. Choose cloud-native over cloud-ready
Traditionally, banking software has been delivered on-premise or moved from on-premise to the cloud. This brings with it the following issues:
- The technology is built for static environments.
- It will never function with the flexibility and efficiency of a system built specifically to take advantage of what the cloud has to offer.
If we’ve learned anything from COVID-19, it’s the benefits of being cloud-native, which allows environments to be rapidly spun up and shut down, and accessed remotely. To reduce costs, servers can be switched off if they’re not needed.
8. Choose standardised over bespoke
Traditional systems are typically made up of glued-together, bespoke elements. These solutions have the unfortunate shortcoming in that they are not typically designed to work with other parts of the system, nor meant to last indefinitely. They can also make the normal lifecycle upgrading process extremely cumbersome, frequently causing issues and outages.
Avoid making any element bespoke to the business and aim to be N-1 or 2.
9. Choose compliant-ready data architecture
This will become critical as the compliance and regulatory environment evolves. A solution should be capable, with the customer’s consent, of securely sharing data with accredited third parties in alignment with PSD2. But it should also meet a bank’s requirements for reporting frameworks such as MiFID and be able to automatically generate reports on-demand by pulling real-time, accurate data from the data warehouse.
So it’s essential to avoid any system that:
- Doesn’t prioritise regulatory and compliance audit functions
- Cannot aptly manage the intricacies of consent
- Doesn’t have strong customer authentication
- Cannot optimally integrate via APIs
- Cannot manage data in one place, with one view of the customer
There’s no telling what the next ‘big thing’ in banking will be, whether, in the next 50 years, we’ll be making trips to Mars on SpaceX spacecraft having just approved a Bitcoin payment with a quick retinal scan.
One thing is certain though: banks need to be able to operate nimbly, flexibly and deliver differentiated customer experiences. This all hinges on the technology they choose to underpin their processes.
Next-generation platforms which are highly automated, cloud-based and take a modular approach to architectural development help banks to avoid legacy problems like complexity, inflexibility, limited integration opportunities and operational inefficiency. These platforms are fast to build and cost-effective to maintain.
The core at the centre should be a data rather than transaction engine with the proper capabilities in place to ensure that the bank has a clear view of each customer and can readily comply with market requirements.
Just imagine the possibilities open to a bank built like that.