What’s this all about?
Read on if you:
- Have an interest in the issues with piecemeal core banking systems
- Want insights on the approach the neo-banks and challengers are taking
- Are keen to find out where end-to-end technology fits in
Transformation has long been on the table for established banks. The 70s and 80s, which saw the advent of the ATM, BACS and the development of the core systems that underpin much of today’s financial services, were a period of intense innovation but only the first of many waves.
These systems were built to last, but not to change and banks have largely chosen to build up layers of modifications, rather than replace the original monolithic designs. Indeed, today, many look to fintech partnerships to innovate and as big tech companies from Silicon Valley make a play for financial services, the prospect for banks to become dumb pipes of utility is significant.
The emergence of neo-banks and challengers has shown us what modern technology might do to progress banking. Yet, even new technology may come up against legacy issues.
Issues with piecemeal core banking systems
A traditional banking system is typically made-up of the following components: the origination system, loan system, accounts system, general ledger, reporting, mobile front-end, web banking, CRM, mid-office and back-office.
Each element is usually made by a different vendor and managing them can be somewhat like herding cats – cats which are, in many cases, competitors with a built-in incentive to see their rivals falter.
A second challenge relates to change and change control. Unless a change is confined to one element of the system, it requires high levels of corridor action in design, development, testing and launch. Indeed, the financial institution is change-controlling an ecosystem it, in many cases, doesn’t manage. Without a developer’s knowledge of the platform, there is little choice but to take the vendors’ word for it. If it’s not generic, a necessary feature is developed for the bank only. The result? A bespoke platform with no clear upgrade path.
Additionally, because each piece of the system has a different function, language, change cycle, development and release cycle, banks grapple with a high level of complexity. Often specialist skills are required to operate the system on expensive proprietary hardware.
These issues make the system both difficult to maintain and costly. Banks are also limited in multiple ways:
- They cannot do ‘joined-up’ thinking because they are a customer of the platform that runs their product.
- In order to differentiate, they must become bespoke.
- They cannot launch features and products quickly.
- The cost of the system and operations only goes up.
- They can only launch products supported in the vendors’ timeline (this is why almost every bank has very similar products).
Banks are also limited in what they can do with their data. Think of the applications that make up a banking system like Lego. If you splice Lego from ten different vendors, all of which were provided with different technical specifications and dimensions, the pieces would not fit together or join up. This would necessitate an eleventh application to glue them together (a service bus, or an API stack). As a result, there is no shared data model and no economies of scale because they all scale differently and the cost to scale differs.
As well as that, because the product subsystems don’t link up, an individual customer with ten products looks like ten separate customers to a bank. So, it needs a twelfth application from another vendor (Master Data Management or MDM) to make sense of it all. However, at the end of all that, the bank still doesn’t have a data model that allows it to be GDPR-compliant (due to changing customer data across the estate) without buying a thirteenth product.
The task of building in-house
In the last decade, the rapid rise of fintech has seen new players stepping into the gaps left by banks’ stagnancy to overhaul their infrastructure. A central strategic decision was: do we build or outsource?
In a report by Sifted, Professor of Entrepreneurship at Oxford University’s Saïd Business School, Pinar Ozcan, says that outsourcing infrastructure – particularly relying on third parties in the backend – can leave fintechs with less agency and flexibility in their product offerings down the line.
Ozcan argues that once fintechs reach a certain size, it’s incredibly expensive to leverage third parties and as such, many have been forced to build their own tech stacks after the fact. This is the path Monzo took, she says, forcing them to undergo a difficult migration onto their own system, a move which can expose it to vulnerabilities like fraud attacks. Indeed, Starling Bank, which has launched a renewed focus aiming to be profitable by 2021, and RBS’s now-defunct Bó are reportedly some of the only challenger banks known to have built their own stacks from the get-go.
What Monzo built
In a 2016 blog article, Oliver Beattie, now VP of Architecture, explains how Monzo built its backend using modern, open-source technology to meet key requirements including:
- Available 24/7
- Scalable to hundreds of millions globally
The neo-bank also wanted to avoid daily batch processing, single points of failure and maintenance windows that would not allow its customers always-on access to money.
To achieve this vision, Monzo took inspiration from big tech and steered clear of single monolithic codebases. Instead, it built an Amazon Web Services (AWS)-based microservices architecture. Today, it has 1,600 microservices, according to Monzo engineers Matt Heath and Suhail Patel who spoke at QCon London earlier in 2020.
A modular approach to banking technology works well due to the requirement to link many different systems such as BACS, CHAPS, Visa, Mastercard, Apple Pay and Google Pay. Heath says: “Adding those things as separate systems allows us to keep them simpler.”
Ultimately, Monzo decided early on that the long-term value of a distributed system was more advantageous than having a single, big resilient system with a complex failover. This would allow it to operate in multiple markets and adapt to unique requirements. Development would be distributed and decoupled, just like the software. Monzo seems to be advancing plans to achieve that vision having applied with the US Office of the Comptroller of the Currency to obtain a US banking licence in April 2020.
Upon announcing initial roll-out to the US in June, Monzo says it plans to build and own as much of its technology stack as possible, as it does in the UK. This would give it the flexibility to react to changes in user behaviour and demands and launch new functionality in a matter of hours and days, rather than weeks and months.
How did it affect the bottom line?
Although much of Monzo’s approach to technology has allowed it to build its business and attract millions of users, the neo-bank continues to wrestle with profitability challenges. Its most recent annual report (year ending 29 February 2020) detailed an annual post-tax loss of £113.8 million, up from £47.1 million last year. While it lent £143.9 million compared to £19.2 million previously, it expects credit losses to climb to £20.3 million with revenue significantly impacted by the pandemic.
The Sifted report concludes that the consensus remains that fintechs should opt for pre-made banking software until they’ve proven their business model and drawn in investors, especially as ‘fintech enablers’ improve their offerings. Indeed, learning from the mistakes of the first wave, the next generation of upstart challenger banks are reportedly focused on creating ‘good products at low cost’ rather than ‘growth at all costs’ and concentrating on a core niche.
Looking to ensure profitability, the new players are taking advantage of the arrival of ready-made, white-label banking technology or banking as a service (BaaS). This has allowed them to outsource their tech layer and launch quicker and less expensively than their predecessors.
What's the pay-off of an end-to-end banking platform?
An out-of-the-box platform gives new banking or lending propositions a foundation on which to build and launch quickly with the key capabilities needed to run a modern digital bank built-in from the start and some third parties pre-integrated.
As well as avoiding legacy issues, a financial institution underpinned by an end-to-end, modular, API-driven platform also has the following key strengths:
- It has complete control over its core tech infrastructure.
- It can pick and choose the modules needed.
- Ability to change and develop without creating bespoke cul de sacs because the code is the same for each subsystem, only the configuration differs.
- Flexibility and ability to evolve.
- Potential for massive scale and cost savings due to economies of scale.
- Joined-up data and real-time insights.
- API infrastructure allows the functionality to be extensible. Third parties can be integrated while still maintaining a joined-up view of customer data.
Additionally, because each subsystem is built from the same code base, a bank running on an end-to-end platform has complete control over its data. From the first moment of onboarding, an identity is created on the back-office so banks have a complete view of the customer lifecycle.
As the future becomes ever-more digital, ensuring optimal data structures is key to supporting contextual financial experiences. Head of Product Management, Paul Brennan has written an article explaining the LEVERIS take on data warehousing and why we believe data will be the key battleground in the years to come.
If the targeted approach by new neo-banks and push from big tech into banking are anything to go by, the battle is already underway.