Even though PSD2 progressively began entering into force between January 13, 2018, and September 14, 2019, there are still different understandings of the regulation in terms of regulatory compliance. One of those topics concerns SMS OTP (one-time-password) and whether it is recognized as an approved authentication method. Is it applicable for online payment verification? If yes, does it count as a possession or knowledge element under SCA? To find out, we did some research and provided answers. Keep reading!

SMS OTP PSD2 compliance online payments services directive

SMS OTP Authentication

SMS one-time-password (OTP) is a well-known, simple form of authentication. It enables users to authenticate themselves with a dynamic code that is sent to them via an SMS message. Often used for 2FA (two-factor authentication), SMS OTP is commonly used as a second factor necessary for gaining access to a particular network or service, usually combined with a static PIN/password. Although two passwords are better than one, SMS OTP is not considered the most reliable method for verifying identity. That is due to an array of risks revolving around the method, some of which include: SIM swapping, SIM hacking, intercepting the message, account takeover, etc.

SMS OTP within PSD2 & SCA

Until recently, SMS OTP was one of the most convenient ways of authenticating an online transaction or logging into a payment account. The user would simply enter the received OTP into their payment application and approve the transaction. In such cases, SMS OTP commonly contains additional information regarding the transaction, including the transaction amount and the payment beneficiary. To conduct 2FA, banks and payment service providers combine static PINs and SMS OTP, PIN being a knowledge element, and SMS OTP representing a possession factor.

The second payment services directive (PSD2) enforces Strong Customer Authentication, demanding online payments to be authenticated using two out of three security elements. Those elements include Knowledge (something you know, a PIN or a password), Possession (something you own, a smartphone, for instance), and Inherence (something you are, e.i. biometric authentication). By definition, SMS OTP, which is recognized as a possession element, combined with a static PIN/password, is an acceptable authentication method conforming to the PSD2 SCA requirement. SMS OTP alone is not considered a possession element but rather the SIM card that is associated with the respective mobile number.

EBA's opinion on the matter is as follows:

For a device to be considered possession, there needs to be a reliable means to confirm possession through the generation or receipt of a dynamic validation element on the device.

In this context, a one-time password sent via SMS would constitute a possession element and should therefore comply with the requirements under Article 7 of the Delegated Regulation, provided that its use is ‘subject to measures designed to prevent replication of the elements’, as required under Article 7(2) of this Delegated Regulation. The possession element would not be the SMS itself, but rather, typically, the SIM-card associated with the respective mobile number.

To conclude, SMS OTP is PSD2 compliant when combined with a static PIN/password or another authentication method considered as either knowledge or inherence security element.

However, SMS OTP is subject to a variety of security concerns. As mentioned earlier, a considerable amount of risk revolves around using SMS as a channel, primarily because of possible interception of the message and man-in-the-middle attacks. Further on, SIM swaps performed in order to receive the message originally sent to the victim, containing OTP, present a threat. Being a well-known authentication method, used in the past decades, fraudsters are equipped with more than enough knowledge necessary to crack the system.

EBA's Opinion

Although SMS OTP is PSD2 SCA compliant, EBA's opinion on the matter is a bit more complex. Another component introduced by PSD2 raised questions about SMS OTP compliance, that being Dynamic Linking. 

Dynamic linking aims to specifically link each transaction to its amount and the recipient of the payment. The end goal is to prevent man-in-the-middle and similar attacks by connecting the transaction amount or order details to the authentication code being sent to the user. If any of the information is altered, a new authentication code will be generated, and the fraudulent attempt would fail. One of the requirements of Dynamic Linking states that the payment information must be protected.

EBA's opinion on the matter is as follows:

In addition, regardless of whether a strong customer authentication element is possession, knowledge or inherence, Article 22(1) of the Delegated Regulation requires that “payment service providers shall ensure the confidentiality and integrity of the personalised security credentials of the payment service user, including authentication codes, during all phases of the authentication” and Article 22(4) of the Delegated Regulation states that “payment service providers shall ensure that the processing and routing of personalised security credentials and of the authentication codes generated in accordance with Chapter II take place in secure environments in accordance with strong and widely recognised industry standards”.

Since we are talking about an SS7 - telephony signaling protocol, which is not considered secure, any information regarding the transaction amount or the order details presented in the SMS would have to be encrypted. Decryption of the content would require a significant amount of effort on the user side, cause confusion, and in the end, create a lot of friction. The conclusion drawn from EBA's opinion is that SMS OTP for Dynamic Linking is not PSD2 compliant unless the content of the message is not protected with additional encryption or sent through a secure channel.

When to Use SMS OTP?

Although SMS OTP is a widely known authentication method, it should be used with caution and considered an alternative authentication method rather than a standard one. Enabling SMS OTP as a fallback method is considered good practice; if all else fails, you can rely on SMS OTP. Another tip is to consider delivering OTP through a more secure channel. Most banks have their own mobile applications which use secure TLS/HTTPS protocols to communicate with the server. Also, if the population is considered as less tech-savvy, i.e., the older population which is not used to smartphones, they will appreciate the option to use SMS OTP as one of their primary methods of authentication.  

For more information, contact our team at [email protected] to get a free, zero-obligation consultation or try our DEMO to see 3D Secure in action.

When discussing PSD2, most stakeholders will have Strong Customer Authentication (SCA) in mind. SCA involves authentication methods that are more advanced than the old-fashioned static PINs and passwords. But this comes with a cost. SCA implementation is much more complex for payment service providers, as well as for the end-user. It requires additional actions on their side, such as a downloaded mobile token, supported biometrics, retyping OTPs, and more.

Yes, PSD2 advocates Strong Customer Authentication, but what does that really mean for the stakeholders? SCA demands authorization which involves two out of three secure elements, namely: possession, knowledge, and inherence. Regardless of the methods chosen, PSD2 brought another tool to increase security measures as well as improve the end-user experience: Risk-Based Authentication. PSD2 makes it clear that the strength of authentication should correspond to the level of risk for a given transaction.

Utilize predefined PSD2 and RTS exemptions

Having this in mind, PSD2 and corresponding Regulatory Technical Standards on Strong Customer Authentication specified that SCA exemptions can be applied. The prerequisite to apply any of the exempted scenarios is to conduct transaction risk analysis, deeming a transaction either high, medium, or low risk. Such analysis can be as simple as a Low-Value Payment which presumes that transactions below 30 EUR, even in cases of fraud, pose a low risk and low financial impact.

For non-low-value payment transactions, a more sophisticated risk scoring needs to be done on the issuer side. Mentioned risk analysis should consider the usual end-user behavior, their habits, channels and devices they use, common geolocation, known delivery addresses, and more. On the other hand, issuers also need to track relevant merchants, meaning their fraud rate, blacklists, risky currencies, etc. As expected, sophisticated risk analysis requires advanced risk scoring solutions.

Move liability to acquirer and merchant

The main issuer's concerns are fraud costs and chargeback liability. With 3D Secure 2, acquirers and merchants were granted a liability shift to the issuer side. Therefore, issuing banks favor SCA for apparent reasons. It protects them and the cardholders from a wide range of fraudulent online payment activities.

Since merchants are much more fond of frictionless transactions than issuers, PSD2 and the recent 3D Secure protocol enable merchants and acquirers to communicate their authentication preferences in the 3DS transaction flow. However, this does not mean that the user is not authenticated. Merchants who opt for this approach trust that the buyer can be trusted if they sign in to the merchant's web or mobile shop, i.e. the buyer is authenticated during login to the web or mobile shop. This is not considered Strong Customer Authentication. Still, taking into account transaction amount, common delivery address, type of purchased goods or services, used card data (which is usually stored in the webshop, hopefully following the PCI DSS rules), merchants can be quite sure that the buyer is known and can be trusted. Demanding additional authentication by the issuer usually makes end-users irritated and unsatisfied with the lengthy transaction authentication process.

Additionally, if the issuer approves an SCA transaction based on the merchant exemption, in case of fraud, merchant is the one that takes the liability for chargeback costs.

Give the buyer a choice

Different regions, merchants, and goods and services result in different buyer preferences when it comes to SCA or SCA exemption. The best option is to let the buyers decide for themselves. With the introduction of Merchant Whitelist in 3D Secure 2.1, which is additionally enhanced in 3D Secure 2.2, buyers are able to choose trusted merchants in order to avoid SCA. Prior, issuing bank analyzed eligible merchants and listed them to be included in the SCA exemption. Contrary to Merchant exemption preference, liability shift for fraud costs and chargebacks is moved to the issuer side. To minimize this risk, Merchant Whitelist eligible candidates also need to be assessed from the risk perspective, using advanced risk scoring solutions regarding the merchant fraud rate.

No exemption? Use biometrics

Biometry is the most applicable, most user-friendly, and the most secure authentication method when talking about 3D Secure authentication in online payments. This is recognized by card schemes, as MC and VISA introduced KPIs for issuers to measure biometry authentication rates. As Juniper research states, already in 2019, facial recognition software was deployed on around 96 million mobiles, forecasting that biometric facial recognition will be present in 90% of smartphones by 2024, making biometric authentication widely applicable. Implementation of biometry solves Dynamic linking as required by PSD2. In the end, applying biometrics is extremely fast and straightforward when combined with push notification during online payment authentication.

For more information, contact our team at [email protected] to get a free, zero-obligation consultation or try our DEMO to see 3D Secure in action.

Interested in TriDES2?

Subscribe to our newsletter
© Asseco South Eastern Europe 2021. All rights reserved
download linkedin facebook pinterest youtube rss twitter instagram facebook-blank rss-blank linkedin-blank pinterest youtube twitter instagram