Mobile App Authorization: Brand-New Approach to Banking App

We all live in a digitized world. We use dozens of different applications daily. Messaging apps, sport tracking apps, apps to manage daily tasks, audio and/or video providers, banking apps, and others.
When downloading an application from the App Store or Google Play, to start using the app, we usually need to register. During the registration process (signing up), we enter our identification data so the system can verify our personality. We can provide an email with a password, phone number, or biometrics, such as a fingerprint, face or voice recognition, or iris scan. All these options represent the same process, which is termed verification. When the data provided is verified, we can sign in. Each time when we enter the app, we pass authentication and authorization, providing one of the previously mentioned variants that are the most convenient for us to confirm identity.

The main difference between authentication and authorization is that authentication is the process of verifying a user’s details to identify and providing access to the system, while the authorization is the process of reviewing the authenticated user’s permissions and account privileges for accessing the resources of the system.

Usually, if we tried to log in to an application or any other system using the unexisting credentials, the system notifies that there is no real account registered with this login, and sends us to the registration screen.

And this is how we got used that there should always be a registration process, and only after that a log-in process.

One of the forerunners in the approach to combine signing-in and registration processes is an online publishing platform — Medium.

As you may know, the entrance to most of the systems includes two-factor authentication. It means that you can log in only if you provide something you know (a password, a PIN, code words) along with something you have (keys, smartcards, hand-held tokens_)_ or something identifying who you are (fingerprints, facial recognition, retina or iris scan, voice recognition). You may have never thought about this before, but each time you insert your card in the ATM — you pass two-factor authentication (Something you have — a credit card with something you know — a PIN).

Medium went the other way and simplified the process of reaching their platform. Their approach offers multiple ways to register or log-in to the online publishing platform. What is especially convenient is that even if the user is not registered, it is possible to skip the registration process.

Medium asks to specify the email address and sends there a magic link. And voilà, you can log in without registering. There are no complex passwords and puzzles anymore. They removed the 1st Factor “something you know” and left 2d Factor “something you have.” And this is the change to the essential criteria for authorization.

We, as a business, believe that the user should enter as minimum data as possible, and reach the required as quickly as possible, without wasting time on meaningless steps.

We started working with users bias. Would you guess how?

No secret that today’s world revolves around mobile phones. Business is based on well-designed applications. However, there is one problem.

Smartphone itself is not about typing. It has very poor designed manual text input.

On the other side, a mobile device is a slightly more secure, more instant, and more personalized channel of communication. Moreover, a smartphone is often more prioritized if compared to email. Plus, people pay more attention to phone notifications.

We are attached to this little interactive brick that is always with us, wherever we go, whatever we do.

The design of the majority of banking apps is not about usability with choice/select-menus and saving users time. It’s about long registrations, confusing forms, and the need for visiting branches for most of the operations.

What remains crucial when dealing with finances is security.

The level of security of a regular application may differ from the level of the required protection in a banking application with increasing risks and responsibilities.

When designing Dozens, a challenger banking app, we took everything into account and made a phone a primary ID.

The success flow of the majority of banking apps is arranged in such a way that the user should type and not scan. These unnecessary interactions distract the user from the initial aim of the action.

We came up with a single solution — reducing text typing frequency.

In Dozens app, we have two buttons: Open an Account and Log-in. But surprise, these two lead to a single scenario, to the same workflow.

Both Log-in and Register an Account check the same step of something you have.

We always ask the user to indicate the phone number (for both logging-in or registration process).

Using the phone verification, we check on what step the user is and help to reach the required.

We compare what a user has by the user’s input. This way, there are no seamless checks of users data. One presses “Open Account” or “Log in” and goes through all the steps and gets either into an existing account (if there is already one) or into the newly-created.

We can also check if the phone number belongs to any user within the system (of course if the user was ever registered). And if the user has access to the account, we can ask for the previous password entered on registration and check the 2d factor.

Why we chose this flow?

We consider that in such a way, there will be no mistakes. When a user occasionally tries to log in using a different phone number, not associated with the existing account, in fact, this user won’t receive an SMS. And therefore, there won’t be a possibility of logging into someone else’s account. When the primary key for user identification (verification by phone) is a second factor “what you have”, it doesn’t really matter whether the user is registered or not.

When verifying by phone, even if a stranger finds your phone, and receives the SMS, when logging to Dozens account the 2d “what-you-know” factor will be asked._

And here comes a business value.

Making your app easy-accessible by multiple variants, you make it easy to follow. Developing it user-friendly and keeping only the most essential features in the design-you decrease the exit rate.

We simplified authorization approach and made it easy for everyone.

By minimizing the initial requirements of manual text input and by adding everywhere tips and suggestions, we increased the usability of the Dozens app: a user goes through the pickup menu, scan documents, and all the data is pulled up automatically.

To everyone who reads us:
Apply tech wisely before going deep into the understanding of what you and your users need. When starting your journey to the depths of development, study the ground.