Digital Onboarding: What You Need to Know Before Getting Started
At Flux IT, we have been implementing different types of digital onboarding journeys for our clients across several industries. Both from the technical and the user experience perspective, working on this process entails several challenges and considerations. If you are thinking about this kind of solution, you will be interested in what comes next.
First Things First: What Is Digital Onboarding?
It is the identification process for a person to be able to use a particular service in a 100% digital way, without the need for physical presence. The difference, as regards any user registration, lays on the fact that digital onboarding seeks a higher authentication level according to the criticality of the service that is being offered.
The Question That Defines It All: What Are We Looking For?
When we build an application, we define its functionalities (each one with its own criticality level), both for the end user and the service provider. What we are looking for is a point of contact to ease both parties. In a digital onboarding process, there are also different elements that can be used to increase the user’s trust level.
Username and Password
It’s the basic authentication level. The client defines a username, an e-mail (which will be validated) and a password following a particular policy to enhance security. At this level, the same person may register more than once since there is no way to match that person with the virtual user.
Social Login
This authentication level is similar to the username and password one (with the same features), but it reduces the friction with the user to a minimum since it avoids the sign-up process or allows us to narrow it down.
SMS or Call Validation
It consists of a code sent through SMS or a phone call (the method used by WhatsApp and Telegram). It adds an additional authentication level since the created username can only be associated with one phone number. Although anyone can have more than one phone line, it’s not common between users with mobile devices.
Reference Codes
Reference codes can be used to start the registration to a service, and their security is linked to the way in which the code is obtained. For example, the possibility of linking tokens to a device is enabled when someone previously obtained a code through the ATM using a debit card; or the access link to a registration page with a predetermined address sent by a third party.
Personal Identification Analysis
When we need to have a single person per username (a usual case in financial services), in Argentina we often use, directly or indirectly, RENAPER (National Identity Registry) services. Users are requested to upload a photo of the front and back of their DNI (identity card), along with a selfie. Through the provided API, we can verify whether they are who they claim to be.
Biometrics with Proof of Life
The personal identification analysis doesn’t prevent anyone who has a selfie and ID card photos from registering pretending to be someone else. Biometrics uses Artificial Intelligence to request the user to make particular moves (such as winking or moving the head) using the cell phone’s front camera, thus confirming that the person who registered with the ID card is the one performing the operation.
Agility vs. security
It is clear that as we increase the authentication levels required for a service, the registration time also increases, as well as the failure possibilities, so do we really need all these levels?
Applications often come with varying functionalities, each one with a different level of criticality. A good approach when working on user experience is to require these enrolment levels in a staged and usually gamified way, with quick access to the app and then inviting users to unlock functionalities through other authentication levels.
At this stage, it is key that users feel they are using a secure system that is in charge of protecting their data and their own identity. However, they also expect the system to guide them properly and in the least bureaucratic way.
According to the business we are solving, a matching set of validations is often selected. The validations we’ve mentioned don’t always make sense. For example, a traditional bank usually has already identified the person and only needs, for example, a token (OTP) for transfers; whereas a company like Uber or WhatsApp is only interested in the match between a virtual person and a phone number.
Products: What Do They Offer?
There are several options when it comes to implementing these solutions, and, as usual, each one requires a time-to-market and costs analysis, to which I add the user experience customization.
We tend to over-dimension the implementation of these type of solutions, analyzing large products beforehand and falling into the trap of doing much more than what the business actually needs. I’m not saying that all the products are bad (quite the opposite), but it is really important to understand the business and the user flows we want to design for end customers.
If we talk about identity management solutions, Auth0 stands out: like SaaS, it is an easy to integrate solution which offers many of the most sought features and customizations. If we need an on-premise alternative, Keyclock is an excellent product with a higher learning curve.
When we talk about integral solutions, which include biometrics with proof of life (among many other functionalities), at Flux IT, we’ve had a good experience using VU Security and FacePhi. Both enable a great time-to-market, as long as we stick to predefined user flows and the visual and user experience they offer (if we want to customize it, we are bound to the possibilities offered by each product).
Another valid option, which has been adopted by many companies, has to do with managing security ad-hoc, integrating Oauth2 with a social login or directly with RENAPER’s API. At the end of the day, that depends on each company’s development strategy.
To sum up, I would also like to mention that, nowadays, we should analyze all these solutions in terms of infrastructure. More and more SaaS authentication and authorization services are being offered entirely on Cloud, which are not necessarily less secure. As I said before, Auth0 is an alternative, but there are other PaaS completely out-of-the-box options(such as Mati). We can also take other more specific AI services into account, such as Amazon Rekognition or IBM Watson, among others.
Digital transformation is packing the market with options, and it is quite important to prioritize and analyze what we are looking for before defining our solution’s architecture. Users are demanding to operate digitally more than ever, and the access to that world should be simple, secure and effective.
