The financial IT development market is vast, with each product or component capable of solving problems for various user categories. For over three years, the Levi9 team has been dedicated to developing the Backbase banking ecosystem in Ukraine, serving 80 countries. Our focus lies in the platform’s central system, ensuring the security and integrity of the banking environment, whether it’s through a mobile app or an online portal, enabling businesses and everyday users to efficiently manage their funds. 

In this article, Roman (BA/PO department manager at Levi9) and senior developer Dmytro Kovalchuk share their valuable experience on working with banking products and the process of developing a system that integrates seamlessly with Microsoft. 

Users need banking, not just banks 

The objective of modern banking developments is to deliver convenience, functionality, and speed. In recent years, the trend has been to provide banking users with more freedom and access to transactions. Self-service capabilities allow customers to manage their finances independently and resolve issues on their own. Waiting for hours in queues or being told that we are valuable to the company is no longer desirable. Instead, logging into an app and completing a transaction with a few clicks has become more convenient. This approach is advantageous for banks as well—more independent customers mean reduced costs for institutions and more resources available for product and service improvements. 

Backbase empowers the digitalization of banking operations, transforming traditional banks into innovative ones by offering users more opportunities. It provides a flexible ecosystem that clients can adapt to their specific needs, such as managing access levels to other accounts, setting payment limits, customizing monthly transactions, and personalizing the banking interface. To achieve this, the product needs to be seamlessly integrated into the existing core banking system and supplemented with additional functionalities. 

The project originated in the Netherlands in the early 2000s, with the Ukrainian team joining in 2014. Backend development is built on Java, which is a traditional language in the banking sector. Java is highly effective in diverse environments, capable of processing large volumes of data, and renowned for its robust security features. Thanks to its “write once, use anywhere” principle, Java consistently ranks among the top three programming languages in the fintech industry, occasionally trading places with Python. Additionally, Java is complemented by various tools.

Throughout our journey with Backbase, we have experienced numerous technological changes. For instance, we started building microservices on DropWizard and later transitioned to Spring. Similarly, in our data handling, we shifted from Application Servers to Kubernetes. We continuously update our tools and leverage the latest technologies to enhance system performance. Furthermore, with several auxiliary projects in frontend and DevOps, we also work with Scala, Groovy, and TypeScript, some of which are open-source solutions. 

Inside the project: Main principles

Internally, the project consists of two major departments: R&D, responsible for the product’s creation, development, improvement, and support; and the Customer Success Team (CST), accountable for integration, customization, and expanding functionality to meet client requirements. In Ukraine, more than 10 teams are actively involved in both directions, comprising a total of 107 professionals. We collaborate with colleagues in six countries worldwide, creating a miniature Babylon of sorts.

The Levi9 team in Ukraine is fully engaged in wealth management, investment operations, and loan operations. We also develop most client communication services. For example, if you need to view your correspondence history or receive push notifications on your phone, it is the Ukrainian team that handles these tasks. 

One of our key responsibilities is access management, determining who has access to what, to what extent, what actions they can perform, and what additional restrictions can be imposed. This function holds significant importance as it addresses several critical needs of users. These include: 

Let’s consider a scenario where you, either as a sole proprietor or a company with multiple accounts, wish to transfer these accounts to an accountant. Our service offers you the ability to grant the accountant access to view the first account and generate statements for reporting purposes. Additionally, from the second account, they can make payments within a specific payment system. You have the flexibility to determine which accounts can be used for payments, such as limiting transactions only to designated salary accounts for specific recipients. Moreover, you can establish a maximum transaction limit for these payments. An added benefit is the ability to assign another user the responsibility of approving or rejecting these transactions. 

Another important aspect of our work revolves around implementing transaction limits. These limits allow you to control the volume of transactions on a daily, monthly, or yearly basis. This feature aids in expense planning and safeguards against fraudulent activities. In comparison, Backbase offers even more extensive features, providing you with the ability to customize limits for different situations and users. For instance, if you order a card for your child, you can set a limit of no more than UAH 10,000 for computer game purchases. Furthermore, you can establish an amount threshold for a specific region, requiring additional confirmation for charges exceeding that limit. Additionally, certain transaction limits can only be managed by bank employees, granting them the authority to restrict and approve specific transactions. 

The key to success lies in conducting a clear assessment of the desired outcomes 

Banking developments are complex and must cater to the needs of various user groups, ranging from young families to large businesses with extensive teams. Any new or improved functionality should aim to solve real user problems or provide new opportunities for enhanced financial management. The goal is to create a sense of astonishment, where users think, “Wow, I didn’t know that was possible!” Otherwise, there would be little point in implementing such features. 

While comprehending the client’s needs, it is crucial to consider the requirements of a high-quality end product. These requirements encompass factors such as robust security measures, responsiveness, user-friendly design, accessibility in accordance with the ADA, and the ability to modify and scale the system. Most of these requirements are established through negotiation before the development process commences, although the list can be expanded and revised as needed throughout the project. 

Security is a fundamental aspect that should be ingrained in the system’s design. This means conducting thorough checks for bugs, viruses, and vulnerabilities before each release and update. The system should adhere to approved data protection checklists to safeguard user information. An interesting consideration arises regarding the right to forget user data under the GDPR. For instance, deleting a customer’s transaction history from the banking system would result in data inconsistencies and potential system malfunctions. Consequently, the developer’s task becomes finding ways to anonymize user information while preserving transaction history.

Easy to use, challenging to develop

Instead of requiring users to perform ten steps to achieve a desired outcome, it is preferable to streamline the process to just three steps. Customers express a strong interest in simplifying both external and internal interfaces. In fact, approximately 80% of improvement requests for already integrated products revolve around enhancing user experience. 

However, there is a drawback to seemingly simple systems—they can be complex to develop, leading to additional professional challenges during the improvement and implementation stages. Each time we enhance a customer application or a bank employee’s account with new features, we must envision the user’s journey during the setup and usage process. This iterative approach allows us to gather valuable insights about the product’s functionality from integrators. Surprisingly, seemingly straightforward data operations can become complex when implemented within specific banking systems. 

Pleasing everyone is a road to nowhere

It is impossible to create a universal banking product – each institution makes payments, reports, and communicates within the team in its own way. It is also important to take into account regional differences. For example, Ireland has quite specific laws, while Africa requires more control over users, and some functions familiar to the European market are prohibited there. That is why we follow the Lego principle in our project: we create a basic configuration that solves the main tasks of modern banking and string the rest of the functions on it depending on the desires, needs, and specifics of the business. 

One of the areas is the moderation of banking transactions. Let’s say you are a bank employee and you need to check and confirm changes in the settings after analyzing transactions on several accounts. If you switch between 10 screens, you could make a mistake, so to reduce risks, it’s better to see everything on one screen.  

Users love limits, and developers puzzle over them. This is primarily due to working with large amounts of data and “moving” analysis periods. Let’s say you set a limit on expenses for the year. When you pay online, the system should analyze the transactions for the period, summarize them, and show whether you are still within the limit. At the same time, it should be borne in mind that most banks have a rolling limit, meaning that the year is counted from the current moment. And we have to give the result in 5 seconds and cannot postpone it, calculate it later, and send the report in a few hours. We do everything quickly, safely, and accurately.  

Banking products are also complex because they cannot be created without an understanding of the financial and related fields. You don’t need a certification, as you do when working with medical IT developments, but it is important to know the basic financial algorithms, the regulation of these operations, and the rules for processing data. And the challenge for developers is to keep a balance. Even if you are working on an ancillary operating segment, it must fit into the larger context of the entire banking system. Minor changes in one part of the system can be significant for the operation of others.

When multifunctionality is not a plus  

When working on multi-layered projects, IT professionals need to know the status of several processes at once. At the same time, a mistake can be noticed even after several months of work on a task.  

Sometimes we face a “game of chicken” situation when clients develop some functionality in their own way. It’s a great way to speed up the product release and share the effort, but misunderstandings happen – this feature already exists or the solution is incompatible with the main product, which affects performance. In the end, we can lose several months to identify the cause. 

There are also technical failures. And here we should note the calm behavior and feedback culture in Dutch companies. They work on mistakes, determine the cause, and find solutions to prevent them from happening again. By the way, both Levi9 and Backbase were born in the Netherlands.

It’s also worth mentioning continuous renovation of financial technologies.  Banking is a rather conservative industry. Usually, products that have scaled rapidly and gained a reputation in the market stop developing technologically and stick to a certain chosen direction. Instead, we don’t stand still on the project, we are constantly trying something new and strive to share our experience with the market.

We love technology too much. And our clients remember it too. As a result, when Microsoft was looking for banking solutions for their cloud environment, they chose Backbase. At first, they were interested in the engagement option, which allows them to get banking services, such as opening a card or account and taking out loans, in a few steps. Overall, they found the solution to be convenient, so they decided to use it as a basis and supplement it with their own developments as needed. So, Microsoft is responsible for providing customers with cloud banking tools and provides tools for analysis and forecasting, while Backbase makes the system convenient, fast, and functional.