Adding a custom functionality module to a new cloud-based boxed software solution of the banking ecosystem
As an international platform, Multitude (formerly Ferratum Bank) is changing its core banking system for a new boxed cloud-based solution. However, as is often the case with boxed solutions, the new system doesn’t provide all the functionalities the client requires. Another issue is that switching to a new system caused problems with data integration to surrounding solutions.
Collection Module – the process of collecting claims from bank clients that we created for our client, had specific requirements from the client’s side, and had to adhere to the law and the regulator’s strict rules.
Due to the specific requirements for the process the bank wanted to have at its disposal, the resulting system was extensive, built on microservices, and had many integrations.
During the project, we tackled numerous challenges in optimizing the solution from the speed and processes standpoint to maintain the previously set high level of security and fulfill the client’s rigorous criteria. We completed the task to the client’s full satisfaction, and today, our module is part of the new banking ecosystem.
Change of the banking ecosystem
Collection system module
Springboot, Camunda, ELR, Microservices, Rest API, MySQL
Analyst, Backend developer, Automated Tester
project duration (ongoing)
6 team members
from DGT factory
of Kafka type messages
Ferratum bank is an international bank that operates branches in multiple countries across Europe. It focuses mainly on short-term loans.
The bank is in the process of transformation from its old-fashioned core banking ecosystem built on integrated monolith solutions to modern microservice-driven architecture. That will ensure a better experience for end users and improve the time to market of the new products.
The change in the banking ecosystem is a vast transformation activity that needs to be designed carefully, considering the optimization of business processes and alignment of numerous teams participating in solution design, development, and testing.
In the beginning, the Ferratum development team searched the market for available development resources to support the internal team in increasing its development capacity. By coincidence, DGT factory had an available team at the time. After a successful interview with the head of development, we established a small team of three developers who already had experience working together. That enabled us to show our efficiency, and the team consequently received more challenging tasks to deliver.
As the DGT factory team became more and more focused on the collection domain in banking, the need to create a tighter relationship with the business owner for this domain increased. We strengthened our capabilities by including an analyst from DGT factory in our team. The role of this analyst is not only to decrease the load on the business owner but also to help deliver straightforward business processes aligned with the other teams developing solutions in a different banking area.
Today, the DGT factory team successfully delivers soft and hard collection functionalities in microservice architecture integrated with the boxed software solution and cloud-based core banking system.
The DGT factory team changes its capacity according to the project’s needs. Therefore, we are able to have fixed team members who are creating the core delivery capability supported by flexible team members who can boost our performance when needed.
It is an advantage that the knowledge always stays internally in the bank and with the members of the DGT factory team. This way, flexible team members can be reallocated to the project whenever needed.
Appropriate structure of the team is crucial for the team to be efficient and for all team members to have a proper workload, including the ones focusing on business.
In the DGT factory team, we are able to find the most appropriate candidates to help businesses succeed by forming business ideas and designing and delivering solutions.