Microservices architecture has become a popular approach for developing complex software systems. The use of microservices enables organizations to create software systems that are scalable, resilient, and easy to maintain. Does microservice architecture also work in financial institutions? And how microservices can prove themselves in IT solutions for fintechs and neo-banks?
This is another article from the BOS Inside series, in which we present the architecture of our flexible core banking software.
What is MSA?
The microservices architecture, also known as microservices, involves developing computer applications as a collection of loosely coupled services that operate independently of each other. Each service performs a specific function and communicates with other services using lightweight communication protocols. Microservices are autonomous in their development, deployment and maintenance, meaning that they can be developed independently of the rest of the system.
Microservices in core banking
One of the examples of IT systems based on microservices is BOS – a transactional system dedicated for modern fintechs and digital banks. The BOS system consists of tens of product microservices. The product microservice allows you to handle all phases of the product, starting from initiation, through product processing in the system, and ending with product closure. The rationale behind the choice of such an architecture for BOS was primarily business scalability (selection of expected business lines with the possibility of future expansion) and technological (performance).
The product microservice allows you to handle all phases of the product, starting from initiation, through product processing in the system, ending with product closure.
How does the idea of microservices relate to the banking system in practice?
Let’s imagine a transaction. What is most important, apart from the security of its implementation, is the processing time. Many things are checked as the banking system processes transactions. Financial conditions ranging from available funds through various types of limits to exchange rates. The client is also important. Do we need detailed customer data to process transactions in the context of high performance requirements? No, basic identification and descriptive information is usually sufficient. Taking this into account, from the point of view of transactional processing, a well-prepared customer database containing only the necessary information, such as identification data or residence qualifier, is sufficient. Everything is done quickly and efficiently. But from the point of view of the marketing department, things look different. It is necessary to have extensive knowledge about the client, its history, documents, connections, etc. Other types of information are necessary from the point of view of the credit assessment department.
In practice, the scenarios given here involve several independent and completely different scaled databases and supporting applications. From a transaction engine focused on instant transaction processing, to a limits database, to replicated customer knowledge placed in another database containing hundreds of customer information, to an independent database storing data on interpenetrating relationships between individual customer records. This is what microservices provide.
Not only technically, completely differently tuned environments, but by separating individual applications from each other, the possibility of independent development on the CIS (Customer Information System), CRS (Customer Relationships System) or Core (Transactional engine) modules.
This loosely coupled architecture allows to easily introduce adapters with very narrow functionality, such as SEPA adapter or SWIFT adapter which are used to connect to payment networks, meeting their standards, MT and ISO 20022 respectively.
Microservices in finance
Other example… Financial institutions generally recognize the advantages of developing more contemporary systems, but what if they wish to explore a novel functionality that customers are beginning to request? How can they conduct real-world testing without the risk of disrupting a well-functioning system? This is where the concept of microservices comes into play. By conceptualizing each fundamental element as an independent microservice, institutions can effectively evaluate and incorporate new features. For instance, if there is a new feature related to payment processing, they can integrate a dedicated payment service capable of seamlessly exchanging data with existing applications. If the new feature necessitates Know Your Customer (KYC) compliance, they can introduce the corresponding service gradually, gradually constructing a novel feature, application, or even an entire organization, while ensuring seamless communication between all components.
What if the customers wish to explore a novel functionality that customers are beginning to request? How can they conduct real-world testing without the risk of disrupting a well-functioning system? This is where the concept of microservices comes into play.
Now let’s see in which areas of financial activity, microservice architecture is particularly applicable.
Fraud Detection:
Financial institutions heavily rely on fraud detection systems to protect their customers and mitigate risks. Microservices architecture allows for the development of specialized microservices dedicated to fraud detection algorithms, anomaly detection, and pattern recognition. These microservices can work in tandem to analyze large volumes of data and identify potential fraudulent activities in real-time.
Customer Relationship Management (CRM):
Microservices architecture can enhance CRM systems in the financial sector. Each microservice can handle specific aspects of customer interactions, such as customer onboarding, personalized offers, transaction history, and customer support. This modular approach enables banks to deliver tailored services and experiences to their customers while maintaining a high level of scalability and flexibility.
Risk Management:
Microservices architecture can be utilized to develop risk management systems for financial institutions. Different microservices can be responsible for data collection, risk assessment, compliance monitoring, and reporting. This distributed architecture allows for better risk analysis, faster response times, and easier integration with external data sources or regulatory systems.
Payment Processing:
Microservices architecture enables financial institutions to build robust and scalable payment processing systems. Each microservice can handle a specific aspect of the payment process, such as authentication, transaction validation, fraud detection, and settlement. This modular approach allows for flexibility and easier maintenance of the system.
Of course, microservices are not a cure-all. So far, there is no architecture that would be free of defects, and at the same time would be suitable for any type of application. It is no different with microservices.
If you are considering implementing a microservices architecture, the key question you should ask yourself is not “Do?”, but “How?”, because incorrect development of technical requirements and structure, or lack of thoughtful handling of traffic between servers, can ultimately do more harm than good. good. Neglecting these issues at the planning stage may result in throwing the baby out with the bathwater, and as a result, it will most likely turn out that the architecture, which was supposed to make many things easier, in fact gives sleepless nights to all interested parties. Then it is worth considering the support of a technical partner who has experience in creating solutions based on microservices. Thanks to this, you will avoid many difficulties related to implementation and at the same time you will be sure that you will have an efficient release and a system that can be modified flexibly to adapt to rapidly changing business requirements on an ongoing basis.
ABOUT THE AUTHOR:
Michał Mazur is the Chief Analyst at INCAT Sp. z o.o. – the provider of BOS Core banking system.
In his over 20-year career, he has been involved in financial and IT sector projects. He has extensive experience in project management, analysis, business development, system architecture, and quality assurance. Michał is a graduate of AGH University of Science and Technology.
Contact an author: michal.mazur@incat.com.pl