About the Client
The client is a large European bank with a representative office in Russia. It’s one of the banks making up the framework of Russian banking. Unfortunately, we can’t specify the name due to the terms of NDA.
We had to create a mobile app and help the bank move beyond an out-of-the-box solution
The bank had already had a mobile app for natural persons, but it was based on an out-of-the-box solution. This solution kept the bank from tailoring the app to its specific needs, hugely limiting their ability to upgrade and add new options to the app.
Therefore, the bank chose to create its own app so that it could eventually leave the out-of-the-box solution behind and get a much more flexible tool for further growth.
Here’s what the bank wanted us to do:
- Create its own mobile app from scratch, integrating it with the existing backend. The first version should have had at least as many functionalities as the out-of-the-box solution.
- Leave the out-of-the-box solution behind and get a flexible tool the bank could use to upgrade the app.
- Migrate users from the old app and into the new one.
- Implement new client features, integrating them with Faster Payments, a Public information system for regional and local payments in Russia (GIS GMP), and Know Your Customer (KYC).
- Implement user analytics to get a better understanding of customer needs and use them to its benefit.
- Update the design, making it more flexible and intuitive.
- Improve the security of the app.
To take up these challenges, all the stages of development had to be lined up properly, including analytics, elaboration of the requirements, and integrating the backend team with our mobile developers.
We provided the bank with native iOS and Android apps that have a modern design and a user-friendly interface. Now the bank is not limited by the capabilities of the out-of-the-box product. It can upgrade the app and adjust it to its business processes — not the other way around.
The users have access to all the standard banking activities: they can set up an account and close it, make payments, and apply for a loan. The bank has also implemented Fast Payments and integrated the app with GIS GMP.
Thanks to user analytics, the bank can now analyze their key sources of income — loan applications, plastic cards, and Fast Payment transfers — and make adjustments if clients seem to have difficulties at a certain stage. In addition to that, the new app provides the bank with summarized anonymous data on each client: which city they come from and which products they have open.
Development and Design
We inherited the UI design from another contractor. It had already been approved by the European headquarters and complied with the brand book — a globally accepted design concept of the banking app.
We suggested our concept which was appreciated by the client’s team in Russia. However, it wasn’t implemented just then: it was decided not to waste resources on design revision for the first release. We focused on the app development thus addressing the main challenge: leaving the out-of-the-box solution behind.
Designing such a complex product is an ongoing process that goes hand in hand with development and undergoes constant improvement. This way it gradually evolves from a mere set of screens into a complex design system. Over the two years of development, we’ve upgraded and improved the initial design and addressed some pain points and previously unaddressed use cases. We’ve also created some complex features from scratch — Fast Payments, GIS GMP, and KYC — and implemented them in the app.
We’ve got a big team (21 people) working on this project. We’ve created native apps using Swift for iOS and Kotlin for Android. The architecture we used was standard: SurfMVP for iOS, MVI and MVP for Android. This is what Surf uses in all projects. Our approaches are well documented, which makes it easy to engage new developers in the project or turn it into an in-house project.
Analytics is Crucial to the Development of a Banking App
Our business analysts went over the backend capabilities and confirmed it was possible to implement the design.
This step is quite important: designers, developers, and business analysts work in close contact to consider all the nuances and capabilities. You can’t always make a pretty picture real — sometimes you have to tweak the API or adjust the design to the backend capabilities.
We put together the technical specifications describing the app’s behavior in detail where the design and the API docs didn’t make it clear enough. Writing it down saves the developers plenty of time.
Code reliability and safety are crucial for any app, but even more so for banking apps. In order to produce a high-quality solution, we carry out a thorough quality assessment.
The code of this banking app is 100% covered by tests. We’ve managed to do so thanks to autotests: testing would take too much time without them.
The project is covered by 1850 tests with the full cycle taking a total of 36 hours. 65% of tests are automated, while the other 35% are manual because some of the services used are third-party.
Smoke Tests. 550 tests take about 8 hours. If you use autotests most productively, they can cover about 80% of all smoke tests. Thanks to that the time spent on manual smoke testing can be reduced by 6 hours with the review of test results included.
Sanity Tests. A total of 1100 tests would take 18 hours. However, 700 test cases, which is 75%, are automated. With the help of auto testing, the time spent on testing goes down from 18 to 6 hours with the review of test results included.
Automated testing enables us to cover 100% of the app by tests, saving us massive amounts of time and boosting the quality of the finished product.
We write all autotest in plain language, i.e. in the Russian dialect of Gherkin. Using Gherkin is a good call if the client is planning to switch to in-house development. It’s easy to engage any QA in such tests even if they’re not originally familiar with this technology.
As usual, we implemented user analytics with AppMetrica and Firebase. In order not to get lost in the amounts of events and data, we started off tracking the main events: launching the app and opening screens. We’ve also analyzed the start and endpoints of the key funnels providing income: loan applications, plastic cards, money transfers via Fast Payments. To make the audience segmentation easier, we’ve collected anonymous client data: what city they come from and what products they use.
All of this is a standard set of analytics for a bank, which helps avoid any mental clutter. If users find any of the funnels challenging, you can add events to that specific funnel and get to the root of the problem.
It wasn’t hard to implement the same functionality that the old out-of-the-box solution had. But as we developed the app, its functionality expanded and the Central Bank of Russia set new requirements we had to meet.
Here’s what we’ve implemented:
- Integration of the app with the GIS GMP system.
- Fast Payments.
- Know Your Customer (KYC).
GIS GMP. Integration with the GIS GMP (Public information system for regional and local payments in Russia) is a pretty popular functionality. Thanks to that users can learn about their tax liabilities and make quick and easy payments via the banking app. We’ve integrated it using the web API. As a result, you can open the “Bills” tab and learn about the fines and taxes they need to pay. In addition to that, you can either enter all the payment details yourself or use a QR code scanner.
Fast Payments. Thanks to Fast Payments, you can make swift transfers to any bank account using only the recipient’s phone number.