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.

Although there is a lot of talk about PSD2, we understand that the information contained in the directive can be, and indeed is, overwhelming. To understand the primary motivation behind the PSD2 regulation, we covered key points relevant to you and your business on a single page. 

PSD2 the second payment services directive, online payment security, credit card, user, wallet, wifi

What is PSD2?

As stated by the official summary of the PDS2 directive, the main goal of the regulation is to provide a legal foundation for the further development of electronic payments within the EU. It is a comprehensive set of rules aiming to make payments within the EU simple, efficient, and secure. Motivated by offering a broader set of choices and better prices for consumers, PSD2 advocates opening up payment markets to new participants in order to create more competition, leading to greater efficiency and strengthening consumer's trust.

The directive strives to enhance the existing set of EU rules regarding electronic payments, emphasizing innovative and emerging payment services, such as internet and mobile payments. Rules stated in the directive concern security requirements, i.e., safeguarding consumer's financial data, promising secure authentication, and reduction of online payment fraud rates. Transparency is another key point that PSD2 advocates in order to provide accurate and timely information about requirements regarding the payments services. PSD2 establishes the rights and obligations of participants involved in the online payment environment, the users, as well as providers of payment services.

Several notable suggestions regarding leveling the payments playing field are pointed out, and those are the following:

  1. Expanding the EU payments market – PSD2 advocates opening the payment market to new participants in an effort to decrease the monopoly banks have over the customer's accounts and payments services, promising increased efficiency without compromising the security of online payments,
  2. Empowering consumers – consumers have reduced liability for non-authorized payments, unconditional refund rights for a predefined period of time (8 weeks), eliminated surcharges for the use of a consumer credit/debit card,
  3. Restricted interchange fees – PSD2 limits interchange fees between banks for card-based transactions in an effort to reduce merchant costs for accepting credit/debit cards as a means of payment.

What happened to PSD?

The first payment services directive dates from 2007, and while it set out good practices and regulated guidance on rules regarding payment services, as of today, it is obsolete. With the rapid evolution of ''all things digital'', new e-commerce trends, authentication methods, and the overall innovative approach to payment markets, PSD was outdated and needed an upgrade. Now that we had a brief history lesson let's get back to our main topic.

PSD2 participants

With new regulation came new terminology, and below are the ones concerning PSD2:

AISPs (Account Information Service Providers) – Providers that can ask for permission to connect to a bank account using an API and use that bank account information in order to provide a service. Having access to such data implies a ''read-only'' approach, i.e., they can't move the fund from the account.

ASPSPs (Account Servicing Payment Service Providers) – A customer's issuing bank that provides and maintains payment accounts. They publish APIs so that the customers are able to share their account data with TPPs in case they want them to initiate payments on their behalf.

PISPs (Payment Initiation Service Providers) – Authorised PISPs are able to move funds on the customer's behalf upon connecting to the bank account. An example of a practical use case is the automatic transfer of funds to a customer's savings account.

TPPs (Third-Party Providers) – Third-Party Providers are either/both Payment Initiation Service Providers (PISPs) and/or Account Information Service Providers (AISPs).

PSUs (Payment Service Users) – Users of any of the above mentioned service providers.

What changes PSD2 brings?

As mentioned above, PSD couldn't foresee trends in the payment industry ten years in advance, and that is why PSD2 steps in. It brings a fresh set of rules in an effort to enable modern, innovative payment services to users and provides them with the highest level of security in terms of online payment fraud, which is constantly present. A comprehensive list of the most important payment threats published by the Europen Payments Council makes you think twice before entering your card data to process an online payment, and it should. Take a look.

The 2019 Payment Threats and Fraud Trends Report provides an overview of the most important threats in the payments landscape, including:

  1. social engineering,
  2. malware,
  3. advanced persistent threats (i.e. sophisticated targeted malicious attacks aimed at a specific individual, company, system, or software, based on some specific knowledge regarding the target),
  4. mobile device-related attacks,
  5. denial of service attacks,
  6. botnets (i.e. a network of private computers infected with malicious software and controlled as a group),
  7. threats related to cloud services and big data,
  8. threats related to the internet of things (IoT),
  9. threats related to virtual currencies

Strong Customer Authentication

In order to combat fraud, PSD2 introduced Strong Customer Authentication (SCA). PSD2's weapon of choice protects customers by demanding them to authenticate with two out of three authentication elements, namely:

  1. something the user knows (PINs and passwords, for instance)
  2. something the user owns (a token or a mobile phone)
  3. Something the user is (biometric authentication including fingerprint, face recognition, voice scan)
Strong customer authentication SCA security elements possession, knowledge, inherence

Initially, this put pressure on issuers and merchants because they were wary of the effects it will have on the overall traffic because of added authentication steps that could potentially drive away the customer from their purchase. But there is a cure for this disease, and it comes in the form of SCA exemptions within the scope of the SCA mandate.

SCA exemptions include various scenarios where SCA is not necessary, and the customer is not asked for an additional authentication step during the processing of a payment. SCA exemptions are the following:

  1. Low-risk transactions – within other innovative approaches in the payments industry, shared information about customer's account data-enabled risk scoring or the so-called Risk-Based Authentication. It enables risk assessment of an individual transaction, deeming a transaction either high, medium, or low risk. In case a transaction is classified as low risk based on predefined parameters, additional authentication is not needed.
  2. LVP (Low-Value Payment) – transactions less than or equal to 30EUR are considered low-value transactions and do not require additional authentication. This rule is applicable for up to five consecutive payments equal to or less than 30EUR and in cases when the cumulative value since the previous SCA is equal to or less than 100EUR.
  3. Merchant Whitelist – The cardholder is able to whitelist a merchant (if they are eligible for whitelisting, this is managed by the issuing bank) and avoid additional authentication because they believe that the merchant is known and can be trusted.
  4. Corporate payments – When processing payments with a card that belongs to an entity rather than an individual, additional authentication is not necessary.
  5. Recurring payments – Subscriptions, loans, and similar payments with a fixed amount require SCA only for the first payment. In cases where the amount changes, SCA is required for each individual change.

There are other scenarios that are out of the scope of the SCA requirement but are not classified as SCA exemptions.

  1. Merchant-initiated transactions – payments initiated by the merchant on the customer's behalf based on an agreement.
  2. Mail order/Telephone order – commonly known as MOTO transactions, they are out of the scope of the SCA requirement.
  3. One leg out transactions – Cases where either the card issuer or acquirer (or both) are outside the EEA.
  4. Anonymous transaction – Cases where a gift card is issued to a customer without identifiable cardholder credentials.

3D Secure 2.0

3D Secure is a protocol that enables Strong Customer Authentication and protects online payments by adding an additional layer of security. It is the main determinant for PSD2 compliance and enables both payment service providers and merchants to achieve alignment. You can get more insight on the latest version of the 3D Secure protocol in our blog post. 

How to achieve PSD2 compliance?

If you're a merchant or a PSP, main question of the day is: Am I PSD2 compliant? If not, how do i become PSD2 compliant?

Merchants need to decide between two options. One option suggests that they pick a PSD2 compliant PSP. This relieves them from all the administrative aspects of compliance and enables them to focus on their primary business. The second option advises merchants to integrate authentication into their checkout process. This requires more effort financially and time-wise but enables them to be PSD2 compliant and in charge of the customer's checkout experience.

If you're an issuing ar an account-holding institution, you want to follow the following steps: create APIs in order to enable transactional payment data access, provide access to accounts to TPPs, make sure you have a Consumer Identity and Access Management solution set up in place, and finally implement the network and API security infrastructure.

Lastly, Third-Party Providers must take care of their PISP or AISP license, establish a trust framework with banks and financial institutions, develop secure apps including user consent and fraud monitoring, and lastly, implement a consumer IAM solution.

Key takeaways

Although PSD2 is causing a stir in the online payments industry by demanding fast onboarding and regulatory compliance, it brings an array of new opportunities for new players in the payments environment. Increased competition most definitely increases efficiency and boosts customer trust. By introducing innovative approaches in regards to online payment security, it reduces payment card fraud, as well as opens doors for further improvement in the risk assessment department enabled by extensive data sharing. Even though PSD2 enforces strict rules and binds the participants to comply, it is done in an effort to assure more quality services that do not compromise on security.

Need help with 3D Secure? Contact us 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