Addressing the shackles of legacy IT in banking
Disruption is everywhere in today’s financial services industry. Traditionally, banks and insurance firms have only been challenged from within the sector, by other similar firms.
However, in recent years, traditional banks and insurers have faced increasing competition from in Techs, cloud vendors and even retail partners that are entering the financial services market. Digital natives, unencumbered by legacy technology and traditional core systems, are leading the avant-garde of new entrants. Being digital by design gives them the ability to see market trends, adjust strategies, innovate, create new solutions, make tactical decisions and deploy resources more quickly.
They can introduce new services to delight customers at an astonishing pace.
While the perception is that digital natives are shaping the future of financial services, the incumbents are putting significant effort into accelerating digital transformation and developing modern technological platforms. For instance, DNB’s number one strategic priority is to increase its innovation power.i Banks now refer to themselves as technology firms first and financial institutions second.ii
However, these firms are often shackled by legacy systems within the core IT stack, which are limiting technological development. Now, the incumbents must ask themselves whether slow and steady innovation is fit for the future, or if the time is ripe for replacing the legacy core?
The brutal reality is that most financial firms rely on hardware and software that originates from the early ’60s, and was considered legacy even before the turn of the millennium.
Established players are weighed down by outdated components within aging technology stacks. Most notable is the traditional mainframe, the very backbone of the world economy in terms of IT infrastructure. This sixty-year-old technology still plays a critical role in nearly all major corporations. Mainframes handle around 70 per cent of all the world’s IT workload and 90 per cent of credit card transactions. As of 2019, mainframes were vital to 96 of the world’s 100 largest banks, nine of the world’s 10 largest insurance companies and 23 of the 25 largest retailers in the US.
Of course, mainframe technology today isn’t comparable to what it was in the ’60s. There have been significant improvements in terms of hardware, security and capacity. The technology is among the most reliable in terms of up-time and will, for example, withstand an 8.0 magnitude earthquake. So, the challenge doesn’t lie in their ability to continue to run existing applications, but rather in their ability to rapidly implement newer and more advanced applications that can improve customer experiences and meet ever-increasing demands.
They struggle with this new age of digital development because you have to write mainframe applications in COBOL, short for Common Business Oriented Language. The American Department of Defence developed the programming language in the ’50s and most computer manufacturers adopted it at the time. Despite the unprecedented development in computer science, the COBOL language is still alive. However, its early practitioners have faded away, and the generation of programmers who built systems towards the end of the predominant mainframe era in the ’70s and ’80s are largely near or past retirement age.
For the modern generation of programmers, COBOL is neither a common nor an attractive field of work. It’s not widely taught at universities and it doesn’t align with the career goals of modern developers. In a thread on Hacker News, a commenter had this pessimistic view of the career outlook of a COBOL developer: “You will most likely spend the rest of your career doing maintenance work rather than any greenfield development. There is nothing wrong with that but not everybody likes the fact they can’t create something new.” A harsher commenter replied: “swamped with technical debt…. modified, extended, updated, moved to new hardware over and over…. Documentation, if any, is hopelessly out of date.”
A shortage of skilled and motivated developers, combined with legacy systems, seriously hampers incumbents’ ability to innovate and compete. This situation is worsened by knowledgeable developers closing in on retirement, increasing the risk of missing core competency to operate the legacy platform or to initiate a potential transition. Eventually, FinTechs and digital natives will capture pockets of growth and outrun legacy institutions by rapidly adapting solutions to customer needs. The incumbents are deep in technical debt and must address the legacy shackles. But how?
Five avenues to breaking the legacy shackles
Most banks face complex and archaic IT infrastructure, whether it be master data management, customer onboarding or legacy code. The incumbents must break free from the shackles to be able to go from monolithic architectures to simpler, more customer-centric and configurable systems, and thus faster development cycles. Yet each business has arrived at its current state through its own unique IT development journey, so there’s no one-size-fits-all way to transform legacy infrastructure.
Approaches vary from a complete rewrite to buying in best-of-breed software from external providers. Below, we’ve outlined five avenues to achieving a successful, future-proof IT infrastructure.
Avenue 1 – Banking as a platform
Core banking capabilities are now available as Software-as-a-Service. This allows banks to customise their setup, easily plugging software features and capabilities into their core systems. Such a solution aims to achieve a modular, customisable experience, which banks can enhance in short development cycles.
Last year, Finnish IT software company TietoEVRY and Eika Alliance, one of Norway’s largest banking and insurance companies, entered into a five-year strategic agreement for the delivery of next-generation core banking and payment solutions, including card services and digital channels. And in 2019, three Finnish banks chose Swiss financial services software company Temenos to operate a banking-as-a-platform solution, using a third-party integrator to manage the process. This approach helps strengthen long-term competitiveness by reducing infrastructure costs, improving development capabilities and achieving greater strategic flexibility.
Banking-as-a-platform is often best suited to smaller banks, or ones that are struggling to implement new features into their existing technology stack and need to break free of the constraints that are preventing them from innovating at speed.
Avenue 2 - Build from scratch
A build from scratch approach optimises the infrastructure through a tailor-made technology platform. International payments provider Nets Norway chose to start from scratch and build a comprehensive, modern IT system to lead the payments market. This is like building your own Formula 1 race car, specifically tuned to one’s own requirements, and can lead to market-leading speed.
The drawbacks of this approach are the huge risk that exists during the migration of customer records and data into the new system. It can also be expensive and will require a substantial development workforce.
Avenue 3 – Choose a global service-oriented package solution
Another alternative is to purchase a global service-oriented package to replace the legacy systems and contract a third party system integrator to support the process. In 2015, Nordea announced that they had signed an agreement with Temenos to implement a new service-oriented core banking platform.
The new core banking platform for customer loans, deposits and transaction accounts was deployed by implementing a common architecture across all the Nordic countries, significantly reducing the number of IT systems in use. It also gave a real-time, customer-centric platform that allows highly personalised and interactive digital experiences.
Nordea aims to minimise the number of changes to the off the shelf system and instead adapt their processes to embrace the benefits of standardisation. The service-oriented architecture facilitates the use of services like APIs (Application Programming Interfaces) and opens the path for future enhancements and new products. The service-oriented approach requires a long timeline for the migration and sun-setting of the old systems, as well as a significant investment.
Avenue 4 – Keep the core, build an integration layer, then develop on top
By first slimming down core functionality, adding an integration layer, and then adding modern modular functionality on top,
it’s possible to keep the foundations and take advantage of cost-effective and fast development cycles for desired additional features.
DNB has taken this approach to increase innovation and build a sustainable technology platform. Instead of rewriting all applications from scratch, development teams are modernising applications by pulling data out into a modern database. This will reduce the risk of transition while buying time to do the necessary comprehensive updates.
However, this is primarily a way of treating the short-term symptoms of the legacy challenges, whilst ignoring the significant future downsides of maintaining a legacy core. Sooner or later, the incumbent banks will be forced to confront the real legacy issue and stop kicking the can down the road.
Avenue 5 – Migration to the cloud
Most accept the future of IT systems lies in the cloud. In 2020, HSBC announced a multi-year deal with AWS for cloud services, letting the bank migrate customer-facing apps onto the cloud. And Deutsche Bank has signed a letter of intent to kickstart a multi-year contract with Google Cloud.
HSBC believes migrating to the cloud will enable them to drive innovation, automate key processes, enhance operational efficiency and scale applications globally across a range of personal financial services. Yet getting there can present a huge challenge in terms of technical requirements and customer education. Even though the transition phase is likely to be costly, such an investment can generate cost savings over time. Cloud services offer the ability to dynamically scale capacity based on demand, lowering the requirements for a constant redundant capacity.
Banks will eventually need to go down one of these avenues to keep up with the shift towards open and digital banking, and to deliver on customer needs. Processing transactions in real-time, frequent releases of new features and allowing third-party applications will be necessary for future core systems. While all avenues address the shackles, the right avenue is a function of what is right for your organisation. To help understand what could work for your situation, ask yourself:
- How sustainable is your current platform?
- How complex is your data strategy?
- What is your business’ appetite for risk?
- What financial resources do you have available?
- Where is the greatest urgency to transform?
- What functionality are you struggling with and want to prioritise?
The answers to these questions will help you find the solution that minimises the risk inherent in such a transformation, while delivering maximum value in the time available.