Our research shows that within the MEA region, the majority of transactions occur through the 3DS1 protocol; with SMS OTP authentication methods, which does not protect buyers to the same extent as the new authentication methods that support 3DS2. We found out that more than 60% of issuing banks have not yet migrated their cards to 3DS2.
3DS protocol is able to acquire ten times more data during the message flow, cca 300 information. This data is primarily obtained from the merchant's site and buyer's devices. It is further used to evaluate the risk level of the transaction taking place. Based on this risk evaluation, Strong Customer Authentication is necessary, or a Frictionless Transaction will take place. This data enables the financial institution, bank, or card issuer to get to know their customers and potentially release them of additional authentication steps through the frictionless transaction process.
Frictionless Transaction is the second big deal when it comes to 3DS2 over the original 3DS protocol. It is aligned with the PSD2 requirement and exempts SCA when the transaction is low risk.
As mentioned above, to evaluate the risk, banks will make behavioral analysis from acquired transaction data of their customer. Then, banks will identify deviations from regular transactions and buyer behavior. Another way a frictionless transaction takes place is when payments of a low amount (below 30 EUR) take place. They are also exempt from greater evaluations and made frictionless.
3DS2 supports technology to smoothly integrate 3D Secure flow with mobile in-app payment services and avoid HTTP redirections for authentication on mobile devices. One of the reasons many card issuers or banks had for abandoning 3DS transactions on mobile devices was HTTP redirection.
Static passwords are very weak in assuring authentication and not particularly user-friendly. Also, we tend to forget passwords. In this case, additional friction for the transaction process is necessary. Strong Customer Authentication (SCA) requires that two out of three secure elements – inherence, possession, and knowledge, are a part of the authentication process.
Inherence elements are something that a payee gives onto, say, a mobile device; i.e. fingerprint scan, face or voice recognition, or other biometric or behavioral data. Possession elements are what the buyer owns; such as s HW token, mobile phone containing a mobile token for generating a One Time Password. Note that the card also counts as a possession element, but only if it has been verified by a card reader, not by readable data printed on the card itself. Finally, the knowledge element is something that the user knows by heart, i.e. a PIN, password, or a secure question.
3DS2 relies on Strong Customer Authentication methods (SCA). The most acceptable method is bush with biometry, which contains both a top-notch user experience alongside the highest level of security using strong authentication methods. The push method exchanges transaction data from an eCommerce website to the buyer's mobile phone as well as the banking authentication application. This ensures the so-called Dynamic Linking and prevents man-in-the-middle attacks as well as potential changes done on the payee's account and/or charge amount by signing of critical data. Biometry associates the buyer with ''something that they are'', on a device they use, which is ''something they own''.
QR codes with biometry provide a similar user experience to push with biometry and work well with either biometry, fingerprint, or face recognition. However, face recognition is not as widely accepted as the fingerprint method.
For buyers who don't have mobile devices with fingerprint readers, PIN numbers or passwords can be used for buyer authentication, but to ensure SCA, it must be combined with OTP.
One of the widespread old authentication methods is HW and SW tokens used for generating OTP transaction signatures. However, nowadays, boyers demand a smooth, fast and frictionless user experience. This method requires manual transaction data entry into an HW/SW token and to retype the calculated OTP onto the webshop. This may cause prolonged checkout time and possible errors during the re-typing stages. Thus, this method should only be used as a fallback method when push/QRcode/biometry cannot be completed due to technical restrictions.