Core banking software: Bridging the gap between monolith and microservice architecture
Jun 24, 2020 by Laurent Canetti and Grégoire Gallet
Jun 24, 2020 by Laurent Canetti and Grégoire Gallet
When it comes to the implementation and maintenance of core banking systems, two classic architectures appear to be competing with one another in various ways – monolith versus microservice, robust versus agile and in-house versus vendor. However, the fact is that there is no “best” solution. The optimal choice depends on your situation so let’s look at some of the deciding factors.
Throughout our 20 years of implementing core banking systems in the UK, DACH and APAC regions, Luxoft teams have advised each client to lean toward whichever solution suits them best. And, if you’re looking to transform your bank, a partner with this kind of deep industry experience can make all the difference.
The core banking system is the beating heart of a financial institution. It embraces all the services a bank provides for its clients and all of the business functionality necessary to carry out its business. This includes client and prospect management, payment and security transaction processing, regulatory reporting, risk evaluation, position keeping, e-banking interface, and so on. Plus, key platform requirements like robustness, availability, security (both authentication and authorization) and full auditability are also essential.
Monolith architectures encompass all core banking services in a single, fully integrated piece of software. Importantly, you don’t need to develop interfaces between services because, for example, things like the payment application and the position-keeping application are part of the same IT solution. And, as the object model is consistent across all components, there’s no need to invest in complicated mapping between the different areas.
Selecting a single software to carry out all of the bank’s functions ensures a privileged relationship with its vendor, enhancing their support. So, the entire platform is much more robust and resistant to single-point failure, especially during an upgrade.
Implementing a single software with a relatively standard configuration also opens the door to software as a service (SaaS) solutions. Indeed, SaaS banking software providers will almost certainly have a standard offering with a limited number of out-of-the-box extensions. Typically, going SaaS allows important cost savings on maintenance and upgrades, and can even enable full back-office outsourcing, keeping the business lean and focused on crucial areas such as client management.
Compared to monolithic architectures, a microservice application is comparatively easy to get to grips with. For instance, there’s safety in numbers. If one element fails, the team can implement another service without having to change the entire architecture, which makes for faster delivery. Scaling to satisfy the needs of a particular element is easier with small components, too. And because the application can run independently while undergoing changes, rapid and controlled upgrades can be implemented without having to slow or stop other components. Also, as microservice architecture is more flexible, the team can use whichever language or framework is right for the job, allowing them to carry out tasks like setting-up servers without interrupting inter-service communication.
Microservice architectures bring much-needed agility to a sector known for its relative inertia and resistance to change. New, targeted applications are being developed by small teams every day. And choosing the right architecture implementation will ensure that your core banking system reacts quickly to changes in regulations, best practices and customer needs.
Any new fintech application with a novel approach to the business can be integrated quickly, allowing synergistic development and exploitation. Microservice architectures also encourage the exploration of niche markets by making it quick, easy and affordable to integrate single-purpose software which can be targeted toward particular domains.
A decentralized architecture provides all the same services as a centralized bank, but without the middlemen. Smart contracts and P2P lending cut costs and guarantee security without affecting the quality of service. Also, implementing a wide range of services renders the likelihood of complete failure of the core banking system near-to-zero as the services are independent of one another.
That said, there’s no ideal approach. Different architectures offer different advantages in different contexts. For instance, a monolithic approach would be a good choice for back-office tasks. Whereas, for client-facing tools like e-banking and smartphone apps, a microservices approach would be good because it offers customers several options. Microservice applications are stripped down to their basic, independent components, so many negative issues can be addressed in isolation. This avoids the kind of IT outage suffered in the UK by TSB, where two million customers were locked out of their accounts between April and June 2018; a meltdown which cost the bank £330 million.
Both approaches can be aligned in an efficient banking system. Core banking data and back-office tasks can be integrated into a monolith system. Then data can be exposed to several microservices performing state-of-the-art tasks. One can do risk analysis and portfolio optimization while the other looks after e-banking.
The best way to decide which approach is the best fit for your situation, is to work with an implementation partner like Luxoft Financial Services that has extensive experience with the main core banking software: Avaloq, Temenos and IBIS3G, in addition to Murex and so on.
A collaborative and insightful partner that really knows the digital banking business.