Cash and Liquidity Management App for Banks and Financial Institutes
Cash and Liquidity Management App for Banks and Financial Institutes
Information
Region:
The United Kingdom
Industry:
Financial Services and Banking
Type:
Web
Engagement model:
Time and materials
Duration:
~1 year
Staff:
Solution architect, 3 senior developers, 4 mid-level developers, a senior DevOps engineer, a senior business analyst, a project manager, 2 senior QA specialists, 1 mid-level QA specialist
Technologies used
Java
Spring
Azure Kubernetes
Prometheus
Angular
MongoDB
PostgreSQL

Client

A British fintech company commissioned Elinext to develop a web application for managing cash and liquidity.

Challenge

In 2019, with Brexit fast approaching, banks were bracing up for disruptions in operations. Some of their clients would be stopping payments to reorganize their debt, and that would start a chain reaction. As a result, the banks themselves would risk being unable to meet their financial obligations toward other clients.

One British fintech company envisioned a tool for calculating whether a bank could pay its obligations should a client stop payments as of the closing bell. The company had previously worked with Elinext and knew we had experience in fintech, so they reached out to us for help.

Process

The client only provided us with high-level documentation containing purely financial specifications. Our business analysts worked with the client’s experts to translate that into technical specs that developers could use.

Meanwhile, our DevOps engineer and developers started to prepare the development environment and the skeleton of the prospective product. And once the technology was in place and specifications had been clarified, the development took off. In one month, we built a minimum viable product (MVP).

The first stretch had to be completed within six months. The first onsite fintech conference after lockdown was in the making, and our client planned to present the product at that time. Although Brexit had been done, a solution like the one we were commissioned to build was still in high demand.

We successfully delivered a stable, fully functional version of the product before the conference took place. And the next three months were spent polishing and improving the application.

Product

The system we built allows banks and other financial organizations to manage and monitor intraday and short-term funding requirements based on transaction history. And this is from the highest level down to individual transactions.

First of all, the organizations using the application can consolidate siloed infrastructures, capturing transactions from any internal or external source. As a result, a single, global view of balances is created across all currencies and accounts.

Furthermore, it takes minutes to run a comprehensive stress scenario within the system.

The ultimate result is highly accurate analytics, facilitating informed decision-making and allowing intraday liquidity reporting requirements to be met more effectively. The solution also helps banks to comply with the BCBS 248 intraday liquidity management framework implemented by various regulators across the globe.

Deployment

We paired Kubernetes with microservices and Angular to implement the GUI. The microservice-based architecture was chosen because it enables the system to be fault-tolerant — the top priority for our client.

Moreover, the system processes a lot of calculations and huge amounts of data, which requires autoscaling, and Kubernetes is good for that.

For system health checks, alert management, and traceability metrics, we set up the open-source monitoring system Prometheus. Our team configured it with the help of its official support team, Grafana.

Microservices

The system runs on seven microservices:

  1. The storing of static bank data like BIC, accounts, currencies, etc., enabled using PostgreSQL
  2. The storing of dynamic data like transactions and FX rates, enabled using MongoDB.
  3. Calculations based on algorithms and operations with static and dynamic data.
  4. The import of dynamic and static data.
  5. Security mapping for users (who have access to each item).
  6. Custom oAuth2 identity provider
  7. The reporter feature for providing and comparing data before and after calculations

The microservices are synchronized with each other using Redis. And the same technology is responsible for the local cache.

Results

We completed the project on time and within the set budget. Around five million items are processed within the system daily by up to 75 banks and other financial organizations.

1-110
2-99
3-81
4-62
5-54
6-34
Do you want the same project?
Got A Project Idea? Lets Discuss It With Us
Contact Us