In the ever-evolving landscape of modern banking, today’s core banking systems are designed to offer a comprehensive suite of cutting-edge solutions. Market leaders most often use microservice architecture, offer the possibility of installation on any cloud and integration via API, they also use open-source solutions, which allows for cost optimization.
However, amidst this myriad of technological advancements, one architectural paradigm stands out as a transformative force: Event-Driven Architecture (EDA). In the following article, we will look at the use of event – driven architecture in the BOS system.

What is EDA and what are its characteristics?

Event-driven architecture (EDA) is a design pattern that emphasizes the flow of events or messages between various components of a system. In the context of core banking systems, EDA allows banks to process transactions and customer interactions in real time, as opposed to the traditional batch processing model. The key characteristics of EDA in core banking systems are:

 Flexibility
Core banking systems using EDA can respond quickly to regulatory changes and market demands. Components can be updated independently, reducing downtime and risk.

 Scalability
EDA facilitates easy scalability by decoupling components. New services can be added without disrupting the existing architecture, making it more adaptable to changing business needs.

Asynchronous Communication
EDA enables asynchronous communication between different components of the system. Events are generated and sent to specific handlers when an action or state change occurs, allowing for real-time processing without waiting for a response.

EDA in BOS system – what does it mean?

In BOS, communication between system components is based on events related to the customer’s activity and events generated by business components. In other words, every activity is an event. Every card transaction, every bank transfer (initiated or received by a customer), every loan application submitted is an event. An event is also any activity initiated by the system, such as collecting a fee or generating a monthly statement.
And that’s not all, as events reach beyond financials: every time a mobile app is open also constitutes an event. So does logging in to your online banking system.

And what does it look like in practice? Imagine that your customer has just paid over $2000 in a consumer electronics store with your card. Ask them straight away if they want to split it into installments, or automatically “re-route” the amount to your buy-now-pay-later product.

Another example. It’s your customer’s third day abroad and his currency account is running low? Send a display notification suggesting currency exchange – or even process one automatically if the customer has chosen such an option earlier. 

The central element of BOS’s event architecture is the Event Driven Orchestrator. 

Event-Driven Orchestrator (EDO) is a component that allows you to manage communication between solution components in a distributed environment, based on events while maintaining the transactionality of financial operations. The basic task of the Event-Driven Orchestrator is to organize the distribution of messages using the Event BUS. A message should be understood as events with a defined information scope, allowing for their interpretation by the receiving systems. 

There were three basic assumptions underlying the design of the Event-Driven Orchestrator, i.e.:
Certainty of delivery of the event to recipients
Possibility to design message distribution paths
Information about how the message was processed by event recipients

Based on the above requirements, the solution architecture presented below was adopted:

 

Main architecture components:

Event Orchestrator – a component enabling the implementation of event distribution processes along with the definition of dependencies between generated events.

Event Bus – a set of queues based on Kafka technology, allowing for asynchronous exchange of messages.

Event Buffer – a component built into business microservices that ensures transactional message exchange and allows managing business event processing in the business microservice. When connecting external loads, this component is not required.

EDA – functional advantages

The adopted event communication allows you to build internal data flow processes, manage the information content of transmitted events in the system and allows for easy integration of processes taking place in the system with external systems. Basing communication on events initiated externally or by internal system components allows the Bank to easily build interactions with the Customer when using the product in the system, including the Customer in the decision-making and information process.

Event product processing in the system allows for the decomposition of a monolithic product processing model. As a result, the product processing process was divided into defined permissible business events on the product. This allows for clear observation of the processing of individual events, allows for easy definition of new events without affecting other tasks, and also allows for modeling the product processing process based on defined business functionalities.

The introduction of event-based product processing allowed for the free creation of financial products based on a predefined set of available events or on the basis of self-implemented events.
The concept based on the Event Driven Product Engine with a predefined set of events (tasks) allows the use of a uniform mechanism for defining and processing financial products for all product lines, such as:

 Loans

 Deposits

 Current Accounts

 

Another important feature of the solution is the autonomy and independence of the components, as a result, the modules supporting the representation of a client, account, client group, limit, product, transaction, fees and commissions, loans, deposits, accounting, affiliate programs, etc., are completely independent modules and may also be independently as part of processes based on other Core solutions. The physical separation of components and ease of integration allows for their independent development, testing, as well as replacing them with currently used business solutions.

 

Use of EDA by famous brands

Event- driven architecture is also often used in other industries. Let’s look at selected examples of its use in industries such as e-commerce or media.

X (ex-Twitter)


X (ex-Twitter) uses an event architecture to send messages between users. Each message is represented by an event that is forwarded to all interested systems, such as message processing systems, data analysis systems and notification systems.

 

Netflix

Netflix uses event architecture to manage video content. Each event, such as the start of a video or the end of a video, is communicated to all interested systems such as playback systems, recommendation systems, and analytics systems.

 

Amazon

Amazon uses event architecture to manage its supply chain. Each event, such as accepting an order or sending a shipment, is transmitted to all interested systems, such as accounting systems, logistics systems and customer service systems.

 

 

If you are interested in EDA and want to see how it is used in the banking system in practice, schedule a call with our expert.