Unbundling the core in the cloud: the perfect architecture for future-proof banks
The speed of innovation in the fintech space requires banks to break free from their core limitations and offer new products in months, not years.
Is your bank running on an operating system that is functionally unbundled, real-time, modular, cloud-native, and plug-and-play?
The burden of monolithic 30-year-old mainframe systems is dragging banks down from being able to play their new role in the fast-changing landscape of financial services. To perform and thrive, agility is the need of the hour for banks. The monolithic core needs to be unbundled into functional Lego blocks, to help banks assemble unique brands and services on the fly.
According to the World Economic Forum, maintenance of core IT systems in US banks accounts for 78% of all IT spending, and banks have realised that patching up these systems is no longer a viable option. With rising maintenance costs of increasingly fragmented systems, frustration from banks is understandable.
A recent Cornerstone Advisors report cites 56% of financial institutions are dissatisfied with the pace of new improvements offered by their core providers. The bundled legacy core is primarily the cause of frustration, imposing impediments to the speed of innovation.
In the past, it took several years to launch a new bank, but new plug-and-play technology accelerates the launch of a complete new digital bank in less than a day!
With the availability of readymade banking apps and complete connections to all payment rails that come out of the box, banks no longer need to worry about spiraling costs and delayed implementations. This requires banks to run on an operating system that is functionally unbundled, real-time, modular, cloud-native, and plug-and-play.
Unbundled by design: microservices-powered core on the cloud
Banking has three core functions – deposits, lending and payments, with all other banking services built around these pivotal capabilities. In legacy core systems, these major core capabilities are built together in a monolithic fashion, intertwined with each other, creating a deep dependency that makes changes ridiculously hard. This is the classic case of the medium and the distribution channel tangled in the product itself.
Microservices come to the rescue to solve this issue of twining.
The power of microservices
Most of the technology industry has moved away from the monolithic systems to microservices-based systems, with each microservice performing only one piece of function.
Microservices are independently deployable smaller components or services built on top of a data layer, offering APIs to create new data, retrieve, transform, enrich, and derive meaningful information.
Think of microservices as Lego blocks – with the flexibility to mix and match assorted sizes and shapes, banks have the freedom to build ingenious products using different functional microservices, giving them an unimaginable number of ways to piece their architecture together.
For example, a deposit microservice will have the following loosely-coupled application programming interfaces (APIs):
- open a new account;
- make a deposit;
- withdraw funds;
- calculate interest;
- get account details;
- close the account.
The first step to unbundle the core is to move the core functions of deposits, lending, and payments into their own services. But all these three core services perform, require, and use several common functions such as:
- Accounting
All financial transactions are balanced and accounted using a meticulous accounting method called double-entry accounting. When you debit an account, there is always another account credited. This method confirms money does not disappear from any one account, but ensures it always moves from one to another.
For example, when the business pays a bill, the accounting system credits the bank account (asset) and debits accounts payable. (Hang on a second! We are making a payment from the bank account – why are we crediting instead of debiting? Well, that’s a whole different lesson in accounting principles for another article!)
Typically, in legacy core modules, each module will have its own sub-ledger. In the microservices world, each service performs only the functions assigned to it and outsources other functions to a different web service.
- Document generation
For each account or transaction, the system is needed to generate a statement or notice. Instead of building such document generation capabilities in each microservice, the smartest approach is to centralise it in another microservice. This way, the three core modules can interface with one document service to create various statements or transaction notices.
- Communication service
Now that the document has been generated, it’s now time to communicate with the customer. Would each core module directly communicate with the customer? That’s how it happens in a monolithic system, but wouldn’t it be better to stand up a separate microservice just to handle user communications?
- Auditing user actions
History cannot be forgotten, especially in a banking system. It’s crucial to keep track of user activities as part of maintaining an audit trail. When something goes wrong, the system should be able to provide the details performed at a transaction level or across multiple transactions by a user or a group. A traceable, scalable, and consistent audit microservice would do exactly that.
- User management
Security of the core is controlled by who can do what, and how the users can access the system. Controlling the digital resources using login security, entitlements, limits, and multi-factor authentication is a critical component of the core and is required by all applications. This is another service that can be unbundled and kept in a separate microservice.
- Customer file
There is no transaction without customer information. All banking functions require customer information such as business registration, accounts details, know your customer (KYC) documents etc. Creating the customer file in one central module is pivotal to simplify the architecture. All banking modules refer to and use the customer file and this helps in managing the data in one common place, enabling business intelligence, data enrichments, smart reporting, and auditing.
The added power of micro UX
Specialised microservices are APIs that only developers understand, and so might not be of much help to lay bankers, operators, and tellers in the running of their day-to-day banking operations. This calls for user experience components for each microservice. The user experience (UX) together with the microservice creates a micro-app. Bundling these apps together creates an operating system for banks.
Developers are the new customers
In the digital economy, the primary customers of any system are the developers. Any digital system must be developer-friendly, with APIs and SDKs that allow developers to build around them, extending the capabilities of, and embedding new functionalities into their products.
Fintechs and bank developers can create new micro-apps, on top of the already existing banking micro-apps in the bank operating system. This way, fintech entrepreneurs can complement, extend and improve banking services in an agile, cost-effective manner, offering unique experiences. They can now focus on differentiation rather than building the same banking function that is available elsewhere.
Open operating system for banks, treasuries and fintechs
Banks need an operating system that allows them to innovate with ease and speed, effortlessly allowing the addition of new products and services in a simple “install, run and launch” model using plug-and-play components. This way, financial institutions can focus on growth and adapt to the constant mutation without being suffocated by the limitations of the legacy core.
That is why Finzly built an operating system, Finzly OS, to enable the building of any financial services. Whether you want to launch a digital bank, run a parallel core, launch a fintech, or run an in-house bank within the treasury, you need an operating system that has pre-built banking micro-apps, that allows you to develop your own custom experiences and workflows.
Interested to find out more? Contact us
Dear Finzly team,
first of all thank you for this analysis. Somehow it does not completely convience me. Is the banking world as simple as you say? Plug-and-play of some components and we have a new service, or even a new bank within a day?
I am now more than 28 years in this business. The idea of lego pieces, or microservices, or however you want to call it, is minimum as old as i my experience there. I support it, no doubts, but i know also the reality and that a bank is not only “deposits, lending and payments”, even a bank, which would not have any other services as those. As we all know behind those 3 “simple” core functions (as you call it) is a big chain of others, which may not be visible to the general public (but the experts know it) exists. Even for a digital bank – believe me, i know what i am talking about.
Yes, we all should go towards the future and force innovations, and cloud is for sure one of it, but we have to keep the balance between innovation and the overall business processing. You are right, lay bankers, operators, and tellers do not need to understand microservices and APIs, but at the end of the day in front of their customers (and their money) and the regulators they are responsible for that exactly these microservices and APIs are doing what they have to do and that they do not damage anything. I saw too many times, what happenes, if developers “take over the rudder”. Knowing that developers “entitled to a say” i would not trust this bank at all. The business has to know its customers and their needs, and the business needs to drive the development, and delevopment needs to support the business with innovations, not the other way round.
Again, we need innovation and transformation, no doubts, but it has to follow a balanced business-technology approach and has to be team work between business people and developers.
And btw, mainframes are not monolitics, and their technology evolution didn’t stop 30 years ago – a closer look might bring sometimes new interesting insights. 😉
Seems to me that this is legacy core reinvented in new technology, which for me is only half the answer to a modern core. Big tick in the box for your composable services. However the FULL STACK CORE is becoming a thing of the past. Most banks have multiple cores and it will be a long time before banks may (if they do ever) get to a single core. So separating front office (customer management) in a way that is “core agnostic” is other half to a new architecture for banks. Most tier one banks separated customer management a couple of decades ago, it is only vendor led solutions that advocate a full stack. Todays modern core now has a DIGITAL BANKING ENGAGEMENT PLATFORM in front of it’s cores, with API’s both in the DBEP and new core.