Verification The Use of One-time Password/PIN (OTP) and two-factor authentication (2FA)
Phone verification involves sending a one-time PIN/password (OTP) to a phone number and requesting the user to recite the OTP to prove that she owns/possesses the phone. It serves as a form of two-factor authentication (2FA). However phone 2FA is unique because:
- Besides authentication, it ensures you have a proven way to contact the user, which is critical to ensure timely communication
- Phone 2FA is a form of identity universally accessible to people in different walks of life without requiring the user to download and operate other complex procedures
Both universal identity and timely communication are critical to build trustworthy communities, and offer great user experience respectively, which are the foundation of disruptive companies in sharing economy, collaborative consumption (marketplace), fintech (micro lending, cryptocurrency, financial inclusion).
The Misconception About Voice & SMS OTP Delivery Reliability
To implement phone verification, it is easy to make the mistake of assuming that a company can just integrate with any phone verification service or voice/SMS verification API and be done.
There are many other hidden pitfalls, one of which is assuming that the phone verification API can always deliver OTPs reliably. At RingCaptcha, we do not assume that as we are obsessed with reliable OTP deliverability which is why web build a reliability layer packed with features such as integrating with major global and regional phone verification APIs, e.g., Twilio, Infobip, Nexmo, MessageBird, etc., to provide multiple fallback routes, sending auto-followup OTP through alternative route & alternative medium (missed-call, SMS, voice), providing a dashboard for unconverted OTPs, etc. You can read more here. If you send your OTP through RingCaptcha’s phone verification API, you make a ‘true’ single API call, and all these happen behind the scene for you to ensure highly reliable OTP delivery.
Empirical Data On Importance of Multiple SMS OTP Routes, Alternative voice OTP, and auto-followup OTPs
To help you understand the importance of alternative OTP fallback routes and alternative OTP medium (voice OTP), we share data from a recent incident.
We compare two periods:
- The period of incident: 3 Dec 2018 – 9 Dec 2018 (inclusive)
- The same period before the incident: 26 Nov 2018 – 2 Dec 2018 (inclusive).
We look for:
- The number of OTP requests with ‘FAILED’ status to understand the severity of the incident
- How RingCaptcha handles these ‘FAILED’ OTP requests transparently for our customers
The data we share is from our logs, and it contains various fields, which we will briefly describe below. We use the term ‘convert’ and ‘conversion’ to describe OTPs requested that are used.
- provider_name: The provider we send OTP request through. RingCaptcha is integrated with major global and regional providers
- operator_name: The operator of the phone number that requested OTP
- service_id: ‘2’ indicates SMS OTP, ‘3’ indicates voice OTP
- status: The report from provider about the OTP transmission
- requested_20181126: OTPs requested in the period before incident
- requested_20181203: OTPs requested in the period of incident
- verified_20181126: OTPs converted in the period before incident
- verified_20181203: OTPs converted in the period of incident
- rate_20181126: ratio of verified vs. requested in the period before incident
- rate_20181203: ratio of verified vs. requested in the period of incident
- diff_requested: The difference in the OTP request count between the 2 periods
- diff_verified: The difference in the OTP verified count between the 2 periods
- diff_rate: The difference in the OTP conversion rate between the 2 periods
The number of OTP requests with ‘FAILED’ status indicates severity of the incident
On the highlighted line, the ‘diff_requested’ is hugely positive: 15959, which means there is an excessive increase in failures for requested OTPs sent to Mobily (‘operator_name’) phone numbers through Infobip (‘provider_name’) in the incident period, i.e., requested_20181203 compared to the period before, i.e., requested_20181126. The provider was suffering from some delivery issues.
For the record, all providers suffer from OTP delivery issues periodically due to a mix of technical difficulties, and traffic congestion. In this particular example, it is Infobip but Infobip is a very reliable provider otherwise, which emphasizes the importance of having multiple provider routes even more.
If you were not sending OTPs through RingCaptcha, the number of failures will make you panic, but with RingCaptcha, it merely means that RingCaptcha will send the OTP requests through an alternative path, and possibly alternative medium, e.g., voice instead of SMS.
How RingCaptcha handles these ‘FAILED’ OTP requests transparently for companies
On the highlighted line, you can see that there is a surge in second attempts, i.e., attempt ‘1’ (NOTE: attempt ‘0’ is first attempt); there is a sharp increase in 3 statistics – ‘SUCCESS’ OTP requests (‘diff_requested’): 6317, OTP verified (‘diff_verified’): 4282, also OTP conversion rate (‘diff_rate’): 0.19, i.e., 19%.
This is an indication that ‘troubled’ Mobily phone users are proactively requesting second OTPs, resulting in the high ‘diff_requested’ of 6317, which were transmitted over ‘voice’ (service_id ‘3’) through ‘Nexmo’ (provider_name), and they are successfully converting, indicated by the high ‘diff_verified’ of 4282. Without this alternative provider (‘Nexmo’) and alternative channel (‘voice’) approximately 4282 users would not be able to receive OTPs to sign-up resulting in loss of potential users, or not be able to perform critical transactions that needed OTP resulting in loss of existing customers.
This shows the importance of sending follow-up OTP through fallback providers and medium to ensure that OTPs are delivered reliably when the main provider and medium fails. At RingCaptcha this happens transparently when you make a single call to send OTP using our API. No additional code needed!
