Automation of
Back Office Deposit
Operations

 

The engineers helped our partner to build a huge banking system for deposit operations handling and bank account processing.

CUSTOMER:

The end customer is one of the biggest CIS (Commonwealth of Independent States) state-owned financial companies. It operates in several European and post-Soviet countries. From 2014 the customer is the largest bank in Eastern Europe.

End customer chose our partner, an international software integrator, to roll out a new version of the existing internal banking system. The old version was out-of-date, lacked several critical features, and required major design and architecture updates.

As every banking application is usually being built for years, it is impossible to get into development quickly, as the project requires lasting knowledge transfer. For that reason, end customer split the whole product development among many small teams: 7-9 developers each.

Such an approach helped the customer to avoid complete knowledge transfer, as every team knew only about small and very specific part of the project. Several software-integrators held the recruitment process, one of these integrators was our partner.

The partner involved Azati in this project, as our developers had already created several applications for the financial companies. Our team is also familiar with the industry workflow and had proved its knowledge and expertise while developing other products.

OBJECTIVE:

Our primary responsibility was to help the in-house team to roll out a new version of the system responsible for deposit operations handling and bank account processing.

When we are creating an application for the financial domain, the software is heavily tested both by quality assurance engineers and by the internal security department to avoid data losses and thefts.

There were no technical difficulties, but the challenges related to data security. Let’s have a closer look.

#1

CHALLENGE #1:

 

Our team addressed the very first challenge to intellectual property (IP) protection. As we were developing software for one of the biggest financial institutes of the post-Soviet region, it is essential not to disclose any technical details that can compromise the end customer and its clients.

For example, every developer worked on two PCs simultaneously. The first PC was hooked up to the internal bank network through a secure VPN without any access to the Internet. It means that if the developer wants to check some external resources, like framework documentation, it was nearly impossible.

For that reason, every remote developer used two computers: a desktop computer for code-writing, and a laptop for other tasks. Even bank corporate messenger refused to work correctly on a desktop computer, as all external ports were closed.

Also, it was not allowed to connect any third-party devices to a desktop, except a hardware key that unlocked access to some internal bank services.

Such an approach to data protection helped a customer eliminate data leaks, but increased the amount of time required to complete the project.

CHALLENGE #2:

 

From time to time, our team faced issues related to access restrictions. As all banking software is built around complex infrastructure which contains proprietary technologies, but once it is essential to learn how this infrastructure works under the hood.

Unfortunately, every time the developer wanted to dig deeper, he faced access restrictions. To overcome these restrictions, our specialists had to create a ticket for a bank security department. Sometimes, it took several weeks to get any response.

#2

PROCESS:

From the very beginning, our partner invited Azati to try this project, as there was a lack of talented developers. We created several demos and participated in the exhibition held by the end customer in Minsk. He was truly impressed by the way we solve his problems, and several weeks after, the team was introduced to the in-house developers.

The project documentation was brilliant, as the system had been developing by many distributed teams. It was essential not only to write clean code but also create extensive documentation that described all architectural patterns and decisions the team made.

About 90% of all code was covered by functional, unit, integration, code clarity, and security tests. It was nearly impossible to commit low quality or suspicious code. Also, all commits that decreased the overall code coverage were rejected.

All project workflow was created according to recent agile methodologies (SCRUM). The project development was split into the milestones. According to these milestones, project managers planned weekly sprints and general workload. Also, every two weeks the team presented a demo to the end customer.

Our engineers communicated with the in-house team and did a code review on an everyday basis. Such an approach helped the team both to share knowledge and show better performance.

SOLUTION:

Unfortunately, we cannot provide much information about the technical side of the project, as there are strict non-disclosure agreements, as well as information obtained by the third party from this document can be used to harm millions of users worldwide.

The solution consisted of several parts

Load
balancer

Our customer cared about usability and user experience, so he wanted to make sure that all services work smoothly, and the uptime is as close to 100% as possible. For that reason, he acquired an independent development company, which created one of the most widely used load balancers in the enterprise sector.

Cloud
Orchestrator

This module is responsible for application scaling, if it finds an overload or bottleneck in the system, it automatically starts additional services or containers, as well as provides the required information to load balancer.

Java Cloud
Services

Applications launched and controlled by Cloud Orchestrator. Some of these apps are relatively small, like microservices or cloud functions, while others are colossal. These services do all the job. Our engineers developed one of them from scratch and later helped other teams to design and develop their services.

Front-end
API

While developing any solutions for finance and banking, the front-end (client-side) of the application is considered being always compromised (truthy). It means that the back-end of the application should check any data coming from the client twice.

The team helped front-end engineers to build separate API’s to protect sensitive data of the clients. All requests coming from the client-side are stored, processed, analyzed, and logged to prevent potential fraudulent activities.

TECHNOLOGIES:

 
 
 
 
 
 
 

SCREENSHOTS:

Results:

Our engineers successfully built a module that automates general withdraw/deposit operations.

In cooperation with our partner, we implemented several essential features:

 
  • Open/Close Deposit
  • Issue/Reissue Credit Card
  • Define Legal Restrictions
  • Deposit Prolongation
  • Show Account Statement
  • Show Credit Card History
  • Set Credit Card Limits
  • Cash Withdraw
  • etc.

After our engineers finished their job, our partner successfully integrated this module into the existing ecosystem. We should note that there were no additional expenses spent on this integration, as before building a module, we learned the application architecture to create a fully pluggable solution.

NOW:

After we completed the first module, the customer signed a service-level agreement (SLA) with our partner, so our team committed to long-term maintenance and bug fixing. But the team not only maintained the existing code but also helped other teams to deliver their modules.

Recently, the end customer severed business relationships with our partner. Even as the customer was fully satisfied with our services and code quality, we could not continue our cooperation due to legal restrictions.