Optimising Transaction Verification in Payment Flows

At this point, we are well-past all European PSD2 deadlines. The final curtain call came after the UK implemented their PSD2 Strong Customer Authentication for eCommerce back in March of this year. eCommerce SCA has been (for sure) the most complex case, more so than account-to-account payments and open banking journeys. But why? Because eCommerce SCA impacts all players in the chain: merchants, gateways, acquirers, issuers, and, most importantly, end-users.

What’s the best option for a frictionless eCommerce SCA process? To not require any stepped-up authentication for the end-user in order to verify the transaction. But, if there is no exemption, SCA or stepped-up authentication will be triggered.

To prevent this from happening, eMerchants should:

• Be ready for both 3DSv2 and accompanying SCA requirements. This includes understanding any SCA exemptions that may apply.

• Possibly be looking into delegated authentication to take care of the authentication process (this would be the case for a happy few, aka, those much larger merchants).  

• Be using an acquirer that manages exemptions above low cost, specifically TRA exemptions (Transaction Risk Analysis) with low fraud rates. In the UK, there is still a large percentage of merchants (especially SMEs) not ready for 3D Secure 2.0, which translates into payment declines. With 3D Secure 1 now being sunset (as of October 2022), this could have a serious impact. 

An authentication request means the end-user is informed that his/her transaction is being secured, which is not necessarily a bad thing per say. What becomes difficult is the actual authentication experience that is offered. While there are various ways to implement the required two-factor authentication, it is not always clear to end-users. As such, it is really important for the end-user’s bank to clearly inform them of what needs doing, especially when end-users are in an edge-case scenario.  

Not all methods are equal when it comes to the friction faced by users. Here are three different authentication processes being implemented by banks and financial institutions that reflect different levels of friction: 

1. Strong OTP by SMS: 

OTP by SMS alone is no longer accepted. Because the SMS only provides a possession factor, it has to be combined with a knowledge factor to be compliant. This can look like a password or PIN code, hence the “strong” OTP by SMS. In this case, an end-user will be asked to enter a password (or code) in a banking app and then enter the OTP that is received for the transaction. Obviously this can be a cumbersome experience, and from a security standpoint, OTP by SMS  is still a weak possession factor.

2. Mobile device + banking PIN: 

Simplifying the process of device + PIN allows for having the possession factor established without the interaction of the end-user. In this scenario, after clicking on a push notification, the end-user is directly prompted to the banking app UI requiring authentication. This means the possession factor (their smartphone) has already been checked in the background. The only action for the user is linked to the knowledge factor, such as entering a 4 or 6 digit code. This is a simplified experience with naturally less friction, but it should be used as a fallback scenario if the inherence factor (such as biometry) has not been implemented as an authentication method. 

3. Mobile device + biometry: 

Device + biometric factor uses the same possession factor check as we mentioned in example two, but this time the stepped-up authentication uses embedded or native biometric capability of the device (fingerprint, face, or iris recognition). Users authenticate many things with embedded biometry, ensuring good acceptance during the experience. This is by far the most frictionless experience of all three cases. 

Note: From a security perspective, examples two and three are typical “out of band” scenarios that prevent man-in-the-middle attacks while still offering a good experience. We have seen implementations of OTP by SMS together with behavioural biometry, but this does not match the same level of experience and security. 

Above all else, banks and FI’s should look to improve the overall user experience, particularly if they are still stuck on example one. For instance, implement biometry first. Then use PIN codes as a fallback, or a voice callback for edge cases. It’s critical to improve their messaging to end users before being prompted to complete authentication, as some users might be lost on what to do in the case of a call back or simply not trustful of any phone call.

In addition, banks and FI’s should provide better information on the transaction UI. The minimum is the amount and recipient. But what about adding the IBAN number for a transaction? Or, adding other useful information like “Beware: this is your first transfer to this person / IBAN / merchant.” 

Lastly, banks and FI’s should fine tune the amount of friction in their authentication processes. Since certain users will appreciate some friction as a token of security more than others (especially those dealing with larger amounts), they should take a stepped approach to their security making sure that the experience is smooth yet trustful.