Originally posted on http://www.vmware.com by Pankaj Arora
This is the first part in a series of articles on how legacy banking architecture needs to evolve to keep pace with the increasing customer expectations, as well as competition from FinTech and Big Tech. It provides an approach of how to leverage modern application platform so that the technology teams in the bank can focus on core business features that are critical for growth and driving innovation in banking. This part specifically talks about the challenges and the competition faced by banks.
Banks have been serving customers for several decades, and over time the heritage systems have become very complex. FinTech and Big Tech are starting from greenfield and using it to their advantage by using modern technologies. They are eating into bank’s wallet share and revenue causing disruption.
Banking haven’t traditionally moved at the modernization velocity of Big Tech and have focused on delivering incremental value. They have been handling complexity across many generations and leveraging it to boost revenues. But is this enough going forward? Banking of 2025 and beyond will need to look very different so that advantage is back with the banks. For this to occur, banks need to do bold transformation for some of the systems, while doing minimal non-invasive repair for the rest, and repeat this cycle.
Challenges from FinTech
In 2021, global investments in FinTech hit $210 Billion. These are FinTech players which typically operate in a narrow space and provide delightful customer solutions and keep nudging away at the customers of traditional banks. Whether its Lending, Payments, Personal Finance, Equity Financing, Insurance, Consumer Banking and the list goes on – there are niche players in each of these segments, gradually eating the wallet share from traditional banks.
Traditional banks have a few advantages that can protect them from the FinTech threat: the trust from the customers, government regulation, branch networks. But that advantage is rapidly diminishing.
Challenges from BigTech
Banks are also facing threat from Big Tech like Apple, Amazon, Alibaba, Facebook – technology companies with modern platforms and workforce. They can lead a frontal assault as opposed to attacking niches. Apple Pay is on pace to account for 10% of all global card transactions.
In Asia, Big Tech is already ahead, and banks are now trying to catch-up to Big Tech. Alipay and WeChat Pay have become leaders in peer-to-peer payments and almost half of domestic payments now flow through third-party platforms.
Payments conducted through e-wallets continue to surge. At the height of COVID crisis, during several weeks of shutdown, several residents found that the Alipay and WeChat Pay were enough even though the banks were closed.
“Banking is necessary, banks are not”Bill Gates, 1994
Factors Impeding Transformation
Over the several decades, several acquisitions, diversifications in the banks, changing priorities, and need to keep building on heritage technology platforms have created substantial complexity in banking architecture. Solutions rely on reliable hardware but not so nimble software. Mainframe systems, NonStop hardware and languages of 60s like COBOL are slowing down the innovation – both in terms of providing a modern efficient platform as well as availability of talent.
Running the bank, keeping the lights on, having systems up and running is non-negotiable. But the architecture and infrastructure of the previous century takes up substantial cost and energy and often the banks use upto 70% of their IT budget for run-the-bank. This leaves very little for driving innovation and build-the-bank. Further, every time there are additional gaps identified in controls, the run-the-bank efforts bump up, slowing the innovation further.
CIOs in Banks are grappling with how to ramp-up the feature velocity so that business objectives are achieved. All this, while juggling technical debt spanning end-of-support-technology risks, security-challenges, insufficient observability, lack of end-to-end automation etc. It is a balancing act to ensure that hygiene, availability and controls are adequate while launching new features.
Some of the factors impeding the transformation are:
Having a fixed hardware to run the systems causes the banks to size up for peak. This has resulted in almost 20 times more infrastructure provisioned.
For typical banking workloads, peak usage is about three times the average requirement. If there are 10 units required to handle average volume, handling the peak volume needs additional 20 units. To accommodate for occasional short bursts another 20 units are kept as buffer.
To ensure no single point of failure, this entire footprint is doubled to give 100 units in the primary datacenter. And, if you consider the replica in the disaster recovery the total footprint grows to 200 units.
Paying for 200 units when the bank only needs 10 on an average is a flashing red sign calling for improvement. The information silos between development and platform teams, no clear agreement on service level objectives and associated error budget further contributes to every team building a safety buffer and leading to significant excess spend.
Software Development Cost
Current Enterprise software stack is comprised of varying technologies, and the provisioning of these products and tools for developers and the servers is significantly manual and error prone. Inconsistent and mutable environments require significant resources to troubleshoot the environment nuances and hygiene rather than the focus on developing code that drives business value.
Large development teams support home grown frameworks. This takes up cycles outside the core business value to be delivered from applications.
Use of old languages, products and frameworks exert cost pressures without translating to revenue growth.
Efforts incurred to setup, operate the infrastructure and moving the application code from one environment to another isn’t directly related to the business objectives. Workforce who are working on manual and receptive tasks will better serve the organization goals by automating the platform creation and working on features that drive differentiation for business.
Most of the existing applications are architected as monolithic applications. It causes efficiency drag during requirements, design, development, testing as well as deployment. A lot of checkboxes need to be checked, and significant orchestration is needed to move the changes across multiple systems from one stage to another. Current convoluted architecture can lend itself for minor enhancements every few weeks, but noteworthy changes take multi-months of planning and delivery.
Velocity of changes from non-banks often seems like a quantum leap ahead. They can deliver user experience changes, new channels and new functions continuously.
“By 2025, two-thirds of enterprises will be prolific software producers with code deployed daily”DC FutureScape 2020
Security & Controls
Banks invest in dozens of products to secure the environment. But these products are siloed and typically get bolted-on, often resulting in insufficient controls. For e.g., banks invest a ton of money to set up the DMZ to scrub the traffic coming from the internet, but once the request reaches the application server the onus of securing falls almost totally on application code.
In summary, there is a huge opportunity to transform and accelerate the velocity of change in a bank. In the next part of this series, we will talk about how banking can be reimagined and mitigate a lot of these challenges.
- KPMG, 2019 – Pulse of Fintech H2 2019, https://home.kpmg/xx/en/home/campaigns/2020/02/pulse-of-fintech-h2-2019.html
- Rene Stulz, 2019 – FinTech, BigTech, and the Future of Banks, https://papers.ssrn.com/sol3/papers.cfm?abstract_id=3455297
- Unbundling Bank, 2015, https://www.cbinsights.com/research/disrupting-banking-fintech-startups/
- Banking in 2019, 2019, https://www.worldfinance.com/banking-guide-2019/
- Martin Fowler, 2014 – Microservice Prerequisites, https://martinfowler.com/bliki/MicroservicePrerequisites.html