Reverse engineering the mobile bank “Open Bank”
A case study on developing mobile banking for iOS
Bank 3.0- The banking industry revolution is in full swing.
The banking sector is currently under the influence of major IT structural changes. This process is called digital transformation. If IT was previously used to automate business processes which were formed in the distant pre-IT era in an attempt to squeeze as much efficiency as possible out of them, it is now possible that IT gives way to new business models, which were not there before. Mobility is the key here.
“Today’s bank is not a place where you go, but rather an activity that you do” — writes Brett King, the bestselling author of ‘Bank 3.0’. Those who think that a physical branch is the only thing that will bring happiness to the client have already lost the battle for today’s consumer. Just ten years ago, 50–60% of transactions were carried out over the counter at a bank branch. Now 95% of transactions carried out via the Internet, mobile phones, ATMs, and call centers. Customers would like to visit a bank branch no more than 1–2 times a year, but in general they are going to interact with the bank more frequently than ever before: 20–30 times a month via smartphone and 7–10 times using a tablet.
Mobile banking as a center of profit, not costs.
In Russia, 6.6 million people a month make at least one online payment using a mobile device. However, many banks still view mobile applications as an annoying need (and expense) to please the tastes of the too-advanced young audience. There is already an online bank — use that! But no, they certainly need a native app! OK, let it be. This approach was used to launch the first wave of a majority of mobile banking. As expected, they did not encourage business growth and laid on the expenses. Customers now have a certain skepticism with regard to mobility.
However, the role of mobile in the overall structure of banking has changed dramatically. Because the auxiliary mobile banking is becoming the main focus (according to various estimates, a client using mobile technology, brings the bank about five times more income). In addition, when choosing a bank, consumers began to consider the quality of the mobile banking application.
Almost half of clients (48%) believe the quality of mobile applications is an important factor when making a decision about changing banks.
When the customer knows what they want
The perfect client to develop an app for is a technologized company that understands the importance of IT in their business. Banks do not just understand this value, but they build their whole business on IT. Working groups involved in the project from the bank’s side (IT, security, marketing, customer service, etc.), do not need any explanations about any technology or about its business benefits.
(If the client lacks coherent strategy for the developing of multi-channel customer interaction, part of which is mobile banking, it should be considered as a serious risk for the project.)
“Open Bank” is a young team of mobile fans, who wanted to give their customers a cool service that meets their business needs, and therefore utilized the development of Redmadrobot.
For “Open Bank”, a mobile bank is part of a single integrated service system, available in different platforms and devices, not just on the iPhone. The Android version is already in operation (available on Google Play, this year), as well as the tablet version. The bank updates all interfaces beginning with the redesign of ATMs and electronic queues, in addition to payment terminals. The mobile app is part of this renovation concept.
“When developing an application we start with two major tasks: to meet the basic needs of the bank’s private clients and meet the business needs of the financial organization (to receive an additional channel for the sale of banking products and improve customer loyalty by translating the ideas of simplicity and convenience of banking services). For us, a mobile bank is another channel for the sale of services.
Ideally, we strive to ensure that all our customers have installed the mobile app. As of now, the smartphone market has reached such a level that devices are quite cheap. The main indicator which deserves attention is the number of successful registrations. That is, it is important to make the registration process is so obvious that no one has any questions like, “How do I register?” or “What do I press?””
Alexey Kruglov, senior vice president, director of marketing and customer service of the bank “Open Bank”
Design and security are the main advantages
Mobile app developers can not possibly influence the composition of banking products, which are a set of services formed by financial institution experts (in addition, these services are the same amongst banks: account information, payments, transfers, statements, currency conversion, etc.). Therefore it is necessary to focus not on WHAT to do, but HOW.
The “how” lies in UX and code quality. In the project “Open Bank”, design is seen as a competitive advantage of a mobile product. Particular attention was paid to security, in the sense that it does not interfere with work. Yes, exactly. On the one hand, security has to be perfect (a single loud incident is enough to compromise the entire system, and there’s no design that can help, as users would reject it), on the other, perfection cannot be achieved by simplifying the product and its features.
The path to good design lies through many iterations
Good design can not be done at the tip of a hat. This is true even when everything is clear in principle, such as the business requirements and brand-book … Ten variants of one screen does not limit the way to perfection. But even options accepted and approved by the client have to be changed.
(It is important to establish control of the versions in project management.)
“Open Bank”s brand book had to adapt a little to iOS- in accordance with the Apple guidelines and traditions, mobile interfaces were made brighter.
In some cases, a native prototype is a necessity, not a luxury
In most cases, you can do a simple HTML-service prototype to assess the design of the interface and logic transitions at the design stage,. However, this method does not allow for a full appreciation of the dynamics and a feel for the interactivity of future applications. If it was already decided that design would be important competitive advantage, such nuances could not be ignored, and so it was decided to use a native prototype. This is almost a real application, but without the real data and server to give those at the UX-testing step a full sense of the product.
It may seem like this is more expensive and more difficult, but in this case the end justifies the means. Of course, such an approach isn’t justified in just any project.
Usability testing on the side
If there is a risk in usability that the client and the developer will not come to a consensus about a convenient and intuitive interface, this will become a breeding ground for conflict. Subjective assessment can not be completely avoided, and the views of each of the parties about what makes a good as opposed to a poor interface solution can vary greatly. Most importantly, they can both be wrong, because users often have their own, very different preferences.
Therefore, the developer should welcome the case when the customer finds usability experts on the side, which can strengthen, rather than destroy their relationship. In this “triangle”, responsibility can be divided more rationally: the customer is engaged in the business requirements, the developer makes the design, and usability experts give feedback.
“Open Bank” chose the company Usethics as a partner for usability testing.
Test scenarios covered about 70% of the functionality of the first version of the product — registration, re-entry into the app, viewing account information, payment history, payment of services, and finding branches and ATMs. Respondents were selected from among iPhone users and online banking.
Designers monitored the testing and were concerned about users — are they finding the right button or not? Sometimes, it was found, so the interfaces were corrected and tested again.
According to the results of testing, the level of subjective satisfaction in using the application was 92.8%, and 98% of respondents gave an overall positive assessment of the mobile bank “Open Bank”.
This was good, but not a reason for euphoria; because usability is tested on simulated data and does not cover all types of users, any problems in the interface will be identified in the real work, which will have to be corrected.
An application needs “customizability”
The idea of making the “Pay” action into a slider, like the one that turns a smartphone on, was really liked by all the participants of the project. Moreover, as it is fully consistent with the Apple guidelines, there is to complain about.
However, the App Store returned this variant with the words “the application does not have enough customizability” — you could not use the system components in some of its use cases. That is, the application should look original and differ from the system screens. Alas, the payment slider had to be removed.
Uniformity and standardization are not always good
It was accepted to strive for uniformity in the interface, so that similar screens had similar functions. That being said, there are situations where this rule does not work.
To access the application, the user needs to enter the access code. But first you need to create the code, correct? To the developers, it seemed perfectly logical to make these screens identical in design. Of course, there was different writing on different screens — “Enter the code” and “Create Code.” Usability testing revealed that users got confused and did not understand what the system wanted from them when they were asked to create a code — an appearance similar to the input screen had them confused. It was therefore decided to make these screens visually different in addition to adding text notes.
(Don’t count on the attentiveness of users. If something can confuse them, they will be confused. Murphy’s Law.)
Copywriting application: “Do not save the file: Y / N?”
This is old joke about a file save dialog is still relevant. Most people are baffled by function names, the wording of questions, tips, and other text messages appearing in the application, although the designers think that all is clear.
The laconic comment “to create an access code” is simply not noticed by users. Therefore, in addition to changes in appearance, this screen had to give a fairly detailed explanatory text about what is required from the user.
Let there be some redundancy and wordiness, as this often turns into a plus rather than a minus. Users read the instructions only as a last resort when nothing happened, and the extra text can be easy to ignore once it is familiar.
Security must exist and be invisible
It is hardly news that a mobile application for a bank should be safe. All developers know this, and yet vulnerabilities exist, and not in isolated cases.
Banks often restrict the size of the transactions through mobile applications to minimize their risks, thereby limiting their scope and their potential income.
Is it possible to create truly secure mobile banking? To be absolutely invulnerable to any attack vectors is inaccurate. This is due to the methods of protection, as a rule, appearing in response to the events and identified incidents. And yet, it is possible to create a reliable application with protection against a majority of currently known threats. This can be done with a high degree of security through the correct code and competent interaction with the bank’s internal systems.
“In our work with banks ( “Open Bank” is not our first bank project), we have had to rethink our approaches to building secure applications. This was the case not so much from the practice of work, but, in fact, writing code — before the documentation and preliminary study architecture were all good. A bank’s security operates on the basis of threat models and requires a reasoned and clear answer as to how we respond to a particular threat. For example, what do you do with the threat of identity theft from a “man in the middle”? We say: “For this, we have provided so-and-so.” The result was two documents:
1) Formal demands for the app’s security- requirements to the code, architecture, and data storage.
2) Requirements for interaction with the server
In fact, every decision that was made in the project was consistent with safety requirements. At the start of the project, security work took up 25% of the time. Then, when the architectural decisions had been taken, we spent almost no time on issues of information security.”
Artur Sakharov, CTO Redmadrobot
Quality assurance from the early stages of the project
Redmadrobot’s QA-team joined the project at the analysis. This helped to avoid large-scale alterations during the development and testing stages. Test cases and test plans included not only functional and UI \ UX testing, but security testing.
The client used the same backend as their personal account, and by testing this part of mobile banking, defects were identified- their correction improved the work of “Open Bank’s” services.
HP Fortify — security checks on the highest level
The Hewlett-Packard Fortify Static Code Analyzer is one of the most important tools for testing Software Security Assurance (SSA) on the world market. Independent experts from HP Fortify checked 37,225 lines of source code of the mobile bank “Open Bank” — the Analyzer did not identify any critical security vulnerabilities.
The Analyzer scans source code for the application and server, and also defines the possible vectors of attack and defense scenarios from them, and then prioritizes results and provides detailed reports (down to the individual rows within the code). The greatest attention is paid to working with data — whether it is stored on a disk, not transferred there in unprotected form, or whether screenshots are masked in iOS.
A unique aspect: registering for a bank card within the application
Starting to use a mobile bank is often not so simple — users need to obtain a login and password in an office or another way, wait until the application registers, etc. The “Open Bank” project had the task of getting rid of all the wires and giving the customer the opportunity to simply be a mobile banking user.
We managed to find an original solution: once the customer registers the number of their bank card, no more logins and passwords are needed. Since the card number cannot be stored on the device for security reasons, it was necessary to devise an identification mechanism to use for registration. The application generates a new identifier and sends it to the server. The server sends an SMS with a verification code, which is all you need to use the mobile bank. Naturally, communication with the server is encrypted with the HTTPS protocol of iOS and standard libraries.
To further make life easier for the user, a recognition feature had been built into the app: it is sufficient to snap a bank card with the iPhone’s camera, and registration will take place automatically (if the card is embossed). Then you need to create a PIN-code and enter the application with it. It is safe enough, because it is possible to block the application in case the phone is lost. The identifier is marked as compromised and it can not enter the system- you must re-register.
And, yes — the input using Touch ID in iOS 8 is also supported. By the way, the mobile bank of “Open Bank” was the first in the Russian market to use fingerprint identification.
Communication with the server: API of the future
The client has a single point of entry to enter the server side from mobile — middleware developed by the bank which further integrates with all internal systems — CRM, payments, account cards, etc.
“Interaction with the application server is based on our RESTful API, which was made universal so that other services and the bank’s Web application can enjoy it. It was created in several iterations, starting from the data model, and was great for re-use and extensibility. This resulted in a fairly simple, very user-friendly, and scalable interface.
Now the API the first version covers 1.5–2x of the functionality of the application. The architecture in general is set up with the future in mind, so that when the application is developed, we do not have to change any fundamental things.”
Arthur Sakharov, CTO Redmadrobot
What has been done and what’s next
The first version of the mobile bank supports the standard set of features:
- Creating a personal access code for simple re-authorization;
- Detailed information about cards, loans, and deposits;
- Viewing statements;
- The ability to quickly refill cards;
- General History of payments made through mobile and online banking with the ability to repeat the operation;
- Mobile payment of television bills, utilities and much more;
- Transfer within the bank “Open Bank”;
- Currency conversion;
- Quickly find the nearest ATMs and offices;
- Getting in touch with the bank’s support hotline or email.
By the end of the year, the application will allow for transfers to other banks, online consultations, a revised statement (with filters and operations of categories) and much more. A release policy requires monthly updates to improve the stability of the application and to add new functionalities, tracking the degree of satisfaction regarding the customer’s business needs and the adjustment of the product development plan.
Following the iOS-version, there will be mobile banking for Android and tablets.
Editor’s note- the original article was published in November 2014. The full app can be seen at https://itunes.apple.com/ru/app/bank-otkrytie/id909649844?mt=8
