Development of a mobile application for RosEvroBank: case
In the spring of 2017, we released a new mobile application, RosEvroBank. We are talking about the challenges that two teams, Redmadrobot and RosEvroBank, faced during the development, testing and implementation of the mobile product, in our next case study. So, "Mobile RosEvroBank: behind the scenes."
By the time RosEvroBank approached us, we had already made several mobile banking products: applications of Otkritie Bank , Life Financial Group, etc. And were well aware of the whole “kitchen” - processes, rules, needs of financial services operators therefore, we were able to start development very quickly.
Artem Grebnev, Product owner, RosEvroBank
“At the beginning of 2016, we put together an intrabank team to work on the project and began to experiment. By the middle of the year it became clear: to write a mobile version on the basis of existing solutions is irrational, everything needs to be redone from the very beginning, and this should be done by a competent, well-trained developer with banking software experience. We studied the market, invited several teams - there was an open offer, everyone could participate, but we had clear selection criteria: firstly, a dedicated development team, secondly, close cooperation until the “landing” development team directly to the bank office if it helps speed up the work. After reviewing all the proposals, we recognized that it was Redmadrobot that best met our expectations. ”
')
In August 2016, the bank gave us a detailed 64-page TK: it contained everything that the client wanted to see in the future application. These expectations from the product we had to jointly adjust. RosEvroBank's TZ, in essence, consisted of three functional blocks: a quality service for existing customers, an additional service such as an electronic wallet for non-customers and a payment aggregator for any operations. All blocks are correct, but their implementation is a huge amount of work and a very long time-to-market: at least a year or two of development, and during this time - the loss of an audience and a huge backlog of industry leaders. Therefore, we offered the bank an approach that is often used in the market of mobile applications and FinTech products: the release of the first version of the application with minimum functionality for 6-8 months, and then the systematic development of the product.
To determine the minimum functionality of the first release, we and the bank singled out the most critical problem for his business: a large number of corporate clients with payroll projects who prefer to divert their money to other banks or to the cache. This pain had to be worked out in the first place, and then we concentrated our efforts.
It was important from the very beginning to lay the foundation for the next six months in the logic of the application and middleware of the bank.
In addition to the standard set of functions that are required to be in a modern banking application, we decided to implement additional features that are not always met. Namely, auto payments and work with cards of other banks, as in a wallet.
Alisa Morozova, Project Manager, Redmadrobot
“Everything connected with banking products is collected on one screen - accounts, loans, cards of RosEvroBank and other banks. You can immediately understand what you have now with money, you can easily throw it back and forth. ”
An external linked card allows you to make payments, top up the balance of RosEvroBank cards for free and make transfers from it to any other cards. Between cards of other banks you can make transfers with a commission of only 1%. For operations with external linked cards, you only need to enter their CVV / CVC codes.
For payments, a separate tab is highlighted and several types of smart auto payments are implemented. The first one is regular: the amount and frequency of transfers are indicated, restrictions can be set up - to be executed until a certain date or a specified number of transfers.
The second type of payment is irregular transfers upon the occurrence of an event: payment of taxes, fines, utilities. Here you can set up a payment with the limit of each operation and the total limit per month (for example, to pay fines of up to 500 rubles automatically, but not more than five times per month).
The most interesting thing is the auto-subscription based on a template: let's say you entered the number of the vehicle registration certificate, found and paid the fine. It is enough that in the future the system itself would track your fines, notify about them and offer to pay. The same is true for paying taxes, fees, you can even connect automatic payment of bills of your relative - for example, school circles of a child.
By the way, the development of payments under the schemes was the most difficult task in terms of business logic. They can come in any form, but you need to display them beautifully and not let the user get confused. The set of banking operations is very similar from the user's point of view - payments, auto payments, invoices, payments on a template - and from the point of view of the banking system these are completely different entities.
System architecture
How does the architecture of the bank? There is a Business Process Enterprise Layer (BPEL), where you can quickly implement the business logic of processing all processes based on existing and developed services in the WSDL format. The mobile application looks at the middle layer, it looks at BPEL, and BPEL communicates with all banking systems via WSDL via the bus.
Middle-layer performs the function of CMS and simultaneously transforms JSON to WSDL, since all internal services work with WSDL, and the mobile application is adapted for working with JSON.
Plus, it also stores all the data for the content of the application: payment icons, logos, color schemes, etc. For example, we begin to add a Sberbank card, and after entering the first digits of the number, the background of the card changes to green. And when paying for MTS, the background will be highlighted in red. All these color schemes, logos and other content is stored just in the interlayer.
Middle-layer is a part of the out-of-the-box DMZ, which also includes the bank’s website and Virtual Office (Internet Bank). For the DMZ is the main network of the bank, where all other systems operate. It is there that the layer of business logic of the mobile application is located, which receives and processes requests exclusively from the layer.
All communication within the bank takes place via a data bus that provides web services for all systems. As a result, we have an application with good optimization capabilities. For example, the first version of the lists of service providers was not very fast - we loaded full schemes for all providers, and it took 15-20 seconds. Now we upload only the list of definitions, and hide the details in separate requests that not every client needs.
Alexey Shcherbakov, IT-head of Digital Bank, RosEvroBank
“Now we are reworking the web application for the same scheme with the content layer. Previously, it used its own content system and communicated via WSDL with BPEL. But on the mobile application, we successfully tried out the change of the architectural approach, and now the web and mobile applications will be synchronized both in terms of functionality and from an architectural point of view. Unification will simplify the further development of the bank: we can quickly bring any new product to all available digital channels - web, mob, sms, ussd, and so on. ”
Dmitry Korchmarek, team lead of development, RosEvroBank
“When we made a web application for the bank, it took a lot more time for it - it was a huge project with many requirements, many new systems were created for it. A few months took only preparatory processes for the implementation of the API of all systems and the beginning of integration, plus a few more months - the integration itself. But on the other hand, we managed to unite all these systems from the point of view of user logic, not banking logic. As a result, on the mobile version, the process of developing a new API and new functionality went at a very aggressive pace. It only took us a high-level business requirement for the mobile version, and with the help of Redmadrobot we prepared an API for it in just a few months. It turned out not so perfect, clean and transparent, as we would like (there are only 117 pages of specifications, of which 17 are changes history), but the architecture itself allows us to develop and implement new functions that do not affect the current implementation on the “combat” server right on the go. "
The iOS version of the application was written in Swift. We have many own libraries in Redmadrobot - for transport level, databases, and so on, which is a great time saver.
Olga Vorona, Redmadrobot iOS Developer
“We strive to work within all the company's projects in the same paradigm, and our main architect promotes layered architecture. Large layers - service level and UI. The service level includes transport, work with the database, and all this is divided into separate services. Details on the level of business logic can be found here . Once we used MVVM (Model, View, ViewModel), then MVPM (Model, View, PresentationModel), now for navigation we use Router. We try to keep as little as possible in the ViewController, we take out more in PresentationModel. Presentation takes models from the service level and creates a ViewModel from them. The View Controller uses these ViewModel to configure the View that the user sees on the screen. We use Router in ViewControllers to navigate between scripts or within a script. ”
To develop a mobile bank, you need test user accounts, test accounts, maps. In the test zone of the bank, not intersecting with the "battle", you can create a client with any parameters. But at the same time, you need to think in advance about all combinations of accounts, cards, and credits that may be needed. To do this, you need to understand well all banking products and their possible states, and this is a huge number of variations.
At the first stage, in the process of developing and testing the interlayer, many things arose in this connection. Due to the peculiarities of the banking API, the correct execution of certain actions by the bank may look like an error from the point of view of mobile developers. For example, the issuance of the application are identifiers of ten products, among which there are cards, and accounts. And with the help of cards it is prohibited to perform a number of operations that, according to the rules of the bank, can only be carried out from accounts. The developer inserts the card ID, calls the method for the account, and the API returns an error.
The bank was set up for a concise and light design, so we used a minimum of graphics, large fonts, simple color gamut.
Tatyana Guschina, designer, Redmadrobot
“To speed up the development, standard design elements were used to the maximum, diluted with interesting animations. Their task is to give the user feedback when performing slow operations, for example, loading large amounts of data. At first, we only had Refresh and Activity Indicator, blocking the entire screen. But because of the specifics of the requests - there may be several on one screen, and when scrolling it should be displayed - we also draw the Loader. Another issue arose with the main screen: since nothing is cached in the application for security reasons, the screen remained blank when loading. This violated user expectations, and we added a special intermediate screen imitating the main one on which the download process is taking place. ”
Vitaly Palchikov, product manager, RosEvroBank
“Inside the bank we have a comfortable ecosystem of interaction between the divisions: internal chat, internal file sharing, project management system. The complexity of this project consisted, firstly, in the work of a distributed team consisting, on the one hand, of administrators, managers, developers and testers on the bank side, on the other - the “external” team for the bank's ecosystem. Secondly, the short term for launching the project was a challenge for us. We did not reinvent the wheel - the chat in WhatsApp from 15-20 people was an extreme, but working solution :)
It was difficult: our “competence centers” developed on the fly, before the project we didn’t have an urgent need for QA, and at first we had to personally check the API of our developers for compliance with the specification; as part of testing a mobile application to “sniff” traffic; compare the response and the behavior of the application. And after the release of the application - independently process incoming customer requests, form the FAQ-base with pre-prepared scripts for transferring the functionality back to the first line, until the modifications have not yet been implemented. The load on project managers from both teams has increased significantly, but everyone did an excellent job with the difficulties. ”
Team communication in the chat allowed us to build effective communication on the project 24/7. As a result, the communication between the developers of the two teams was not limited to the project administrator, and a full, very close interaction was built between them.
At ten o'clock we could report that the method call failed, the bank promptly contacted the administrator on duty, found out that an urgent update was now unplanned, and immediately answered “wait 10 minutes and everything will work”. But not so that the method is not accepted, a bug is put in Jira, and the bank responds to it on the next working day. This significantly accelerated the development and allowed programmers to work at a convenient time for them.
By necessity, RosEvroBank connected specialists responsible for certain parts of the banking backend to the chat, we added testers, and all issues were resolved promptly. Even about the launch of the project, all team members learned from the chat :)
For us at Redmadrobot, the most important thing was to build the right job with the bank. No matter how advanced it is, it’s still a massive structure, and even for a separate digital bank, numerous approvals and checks are required. A serious achievement is that we have learned how to work with such customers and at the same time have taught them how to work with how we do architecture, design, write, check and test systems.
To date, we have closed approximately 90% of the functionality available in the backend of the bank, and the mobile application is already ahead of the bank’s web office. While we were writing the article, we have already implemented the possibility of opening accounts, registering non-residents, graphical reports on the use of funds on cards and managing card limits. From the plans for the near future - transfer to a bank client by phone number, connection of options - cashbacks, savings interest and SMS informing, conversion, chat with operators and much more.
By the time RosEvroBank approached us, we had already made several mobile banking products: applications of Otkritie Bank , Life Financial Group, etc. And were well aware of the whole “kitchen” - processes, rules, needs of financial services operators therefore, we were able to start development very quickly.
Artem Grebnev, Product owner, RosEvroBank“At the beginning of 2016, we put together an intrabank team to work on the project and began to experiment. By the middle of the year it became clear: to write a mobile version on the basis of existing solutions is irrational, everything needs to be redone from the very beginning, and this should be done by a competent, well-trained developer with banking software experience. We studied the market, invited several teams - there was an open offer, everyone could participate, but we had clear selection criteria: firstly, a dedicated development team, secondly, close cooperation until the “landing” development team directly to the bank office if it helps speed up the work. After reviewing all the proposals, we recognized that it was Redmadrobot that best met our expectations. ”
')
In August 2016, the bank gave us a detailed 64-page TK: it contained everything that the client wanted to see in the future application. These expectations from the product we had to jointly adjust. RosEvroBank's TZ, in essence, consisted of three functional blocks: a quality service for existing customers, an additional service such as an electronic wallet for non-customers and a payment aggregator for any operations. All blocks are correct, but their implementation is a huge amount of work and a very long time-to-market: at least a year or two of development, and during this time - the loss of an audience and a huge backlog of industry leaders. Therefore, we offered the bank an approach that is often used in the market of mobile applications and FinTech products: the release of the first version of the application with minimum functionality for 6-8 months, and then the systematic development of the product.
To determine the minimum functionality of the first release, we and the bank singled out the most critical problem for his business: a large number of corporate clients with payroll projects who prefer to divert their money to other banks or to the cache. This pain had to be worked out in the first place, and then we concentrated our efforts.
It was important from the very beginning to lay the foundation for the next six months in the logic of the application and middleware of the bank.
What can the application
In addition to the standard set of functions that are required to be in a modern banking application, we decided to implement additional features that are not always met. Namely, auto payments and work with cards of other banks, as in a wallet.
Alisa Morozova, Project Manager, Redmadrobot“Everything connected with banking products is collected on one screen - accounts, loans, cards of RosEvroBank and other banks. You can immediately understand what you have now with money, you can easily throw it back and forth. ”
An external linked card allows you to make payments, top up the balance of RosEvroBank cards for free and make transfers from it to any other cards. Between cards of other banks you can make transfers with a commission of only 1%. For operations with external linked cards, you only need to enter their CVV / CVC codes.
For payments, a separate tab is highlighted and several types of smart auto payments are implemented. The first one is regular: the amount and frequency of transfers are indicated, restrictions can be set up - to be executed until a certain date or a specified number of transfers.
The second type of payment is irregular transfers upon the occurrence of an event: payment of taxes, fines, utilities. Here you can set up a payment with the limit of each operation and the total limit per month (for example, to pay fines of up to 500 rubles automatically, but not more than five times per month).
The most interesting thing is the auto-subscription based on a template: let's say you entered the number of the vehicle registration certificate, found and paid the fine. It is enough that in the future the system itself would track your fines, notify about them and offer to pay. The same is true for paying taxes, fees, you can even connect automatic payment of bills of your relative - for example, school circles of a child.
By the way, the development of payments under the schemes was the most difficult task in terms of business logic. They can come in any form, but you need to display them beautifully and not let the user get confused. The set of banking operations is very similar from the user's point of view - payments, auto payments, invoices, payments on a template - and from the point of view of the banking system these are completely different entities.
System architecture
How does the architecture of the bank? There is a Business Process Enterprise Layer (BPEL), where you can quickly implement the business logic of processing all processes based on existing and developed services in the WSDL format. The mobile application looks at the middle layer, it looks at BPEL, and BPEL communicates with all banking systems via WSDL via the bus.
Middle-layer performs the function of CMS and simultaneously transforms JSON to WSDL, since all internal services work with WSDL, and the mobile application is adapted for working with JSON.
Plus, it also stores all the data for the content of the application: payment icons, logos, color schemes, etc. For example, we begin to add a Sberbank card, and after entering the first digits of the number, the background of the card changes to green. And when paying for MTS, the background will be highlighted in red. All these color schemes, logos and other content is stored just in the interlayer.
Middle-layer is a part of the out-of-the-box DMZ, which also includes the bank’s website and Virtual Office (Internet Bank). For the DMZ is the main network of the bank, where all other systems operate. It is there that the layer of business logic of the mobile application is located, which receives and processes requests exclusively from the layer.
All communication within the bank takes place via a data bus that provides web services for all systems. As a result, we have an application with good optimization capabilities. For example, the first version of the lists of service providers was not very fast - we loaded full schemes for all providers, and it took 15-20 seconds. Now we upload only the list of definitions, and hide the details in separate requests that not every client needs.
Alexey Shcherbakov, IT-head of Digital Bank, RosEvroBank“Now we are reworking the web application for the same scheme with the content layer. Previously, it used its own content system and communicated via WSDL with BPEL. But on the mobile application, we successfully tried out the change of the architectural approach, and now the web and mobile applications will be synchronized both in terms of functionality and from an architectural point of view. Unification will simplify the further development of the bank: we can quickly bring any new product to all available digital channels - web, mob, sms, ussd, and so on. ”
Dmitry Korchmarek, team lead of development, RosEvroBank“When we made a web application for the bank, it took a lot more time for it - it was a huge project with many requirements, many new systems were created for it. A few months took only preparatory processes for the implementation of the API of all systems and the beginning of integration, plus a few more months - the integration itself. But on the other hand, we managed to unite all these systems from the point of view of user logic, not banking logic. As a result, on the mobile version, the process of developing a new API and new functionality went at a very aggressive pace. It only took us a high-level business requirement for the mobile version, and with the help of Redmadrobot we prepared an API for it in just a few months. It turned out not so perfect, clean and transparent, as we would like (there are only 117 pages of specifications, of which 17 are changes history), but the architecture itself allows us to develop and implement new functions that do not affect the current implementation on the “combat” server right on the go. "
The iOS version of the application was written in Swift. We have many own libraries in Redmadrobot - for transport level, databases, and so on, which is a great time saver.
Olga Vorona, Redmadrobot iOS Developer“We strive to work within all the company's projects in the same paradigm, and our main architect promotes layered architecture. Large layers - service level and UI. The service level includes transport, work with the database, and all this is divided into separate services. Details on the level of business logic can be found here . Once we used MVVM (Model, View, ViewModel), then MVPM (Model, View, PresentationModel), now for navigation we use Router. We try to keep as little as possible in the ViewController, we take out more in PresentationModel. Presentation takes models from the service level and creates a ViewModel from them. The View Controller uses these ViewModel to configure the View that the user sees on the screen. We use Router in ViewControllers to navigate between scripts or within a script. ”
Banking nuances
To develop a mobile bank, you need test user accounts, test accounts, maps. In the test zone of the bank, not intersecting with the "battle", you can create a client with any parameters. But at the same time, you need to think in advance about all combinations of accounts, cards, and credits that may be needed. To do this, you need to understand well all banking products and their possible states, and this is a huge number of variations.
At the first stage, in the process of developing and testing the interlayer, many things arose in this connection. Due to the peculiarities of the banking API, the correct execution of certain actions by the bank may look like an error from the point of view of mobile developers. For example, the issuance of the application are identifiers of ten products, among which there are cards, and accounts. And with the help of cards it is prohibited to perform a number of operations that, according to the rules of the bank, can only be carried out from accounts. The developer inserts the card ID, calls the method for the account, and the API returns an error.
Design
The bank was set up for a concise and light design, so we used a minimum of graphics, large fonts, simple color gamut.
Tatyana Guschina, designer, Redmadrobot“To speed up the development, standard design elements were used to the maximum, diluted with interesting animations. Their task is to give the user feedback when performing slow operations, for example, loading large amounts of data. At first, we only had Refresh and Activity Indicator, blocking the entire screen. But because of the specifics of the requests - there may be several on one screen, and when scrolling it should be displayed - we also draw the Loader. Another issue arose with the main screen: since nothing is cached in the application for security reasons, the screen remained blank when loading. This violated user expectations, and we added a special intermediate screen imitating the main one on which the download process is taking place. ”
Communication in two teams
Vitaly Palchikov, product manager, RosEvroBank“Inside the bank we have a comfortable ecosystem of interaction between the divisions: internal chat, internal file sharing, project management system. The complexity of this project consisted, firstly, in the work of a distributed team consisting, on the one hand, of administrators, managers, developers and testers on the bank side, on the other - the “external” team for the bank's ecosystem. Secondly, the short term for launching the project was a challenge for us. We did not reinvent the wheel - the chat in WhatsApp from 15-20 people was an extreme, but working solution :)
It was difficult: our “competence centers” developed on the fly, before the project we didn’t have an urgent need for QA, and at first we had to personally check the API of our developers for compliance with the specification; as part of testing a mobile application to “sniff” traffic; compare the response and the behavior of the application. And after the release of the application - independently process incoming customer requests, form the FAQ-base with pre-prepared scripts for transferring the functionality back to the first line, until the modifications have not yet been implemented. The load on project managers from both teams has increased significantly, but everyone did an excellent job with the difficulties. ”
Team communication in the chat allowed us to build effective communication on the project 24/7. As a result, the communication between the developers of the two teams was not limited to the project administrator, and a full, very close interaction was built between them.
At ten o'clock we could report that the method call failed, the bank promptly contacted the administrator on duty, found out that an urgent update was now unplanned, and immediately answered “wait 10 minutes and everything will work”. But not so that the method is not accepted, a bug is put in Jira, and the bank responds to it on the next working day. This significantly accelerated the development and allowed programmers to work at a convenient time for them.
By necessity, RosEvroBank connected specialists responsible for certain parts of the banking backend to the chat, we added testers, and all issues were resolved promptly. Even about the launch of the project, all team members learned from the chat :)
What is the result
For us at Redmadrobot, the most important thing was to build the right job with the bank. No matter how advanced it is, it’s still a massive structure, and even for a separate digital bank, numerous approvals and checks are required. A serious achievement is that we have learned how to work with such customers and at the same time have taught them how to work with how we do architecture, design, write, check and test systems.
To date, we have closed approximately 90% of the functionality available in the backend of the bank, and the mobile application is already ahead of the bank’s web office. While we were writing the article, we have already implemented the possibility of opening accounts, registering non-residents, graphical reports on the use of funds on cards and managing card limits. From the plans for the near future - transfer to a bank client by phone number, connection of options - cashbacks, savings interest and SMS informing, conversion, chat with operators and much more.
Source: https://habr.com/ru/post/336704/
All Articles