PSD2 and strong
customer authentication

The Revised Payment Services Directive (PSD2) is a set of laws and regulations for payment services in the European Union (EU) and the European Economic Area (EEA). It’s been around for a while - it was passed in 2015 - but the most important aspects for online payments come into effect on 14 September 2019.

Why is it necessary?

A lot has happened since PSD1 was passed in 2007. Apple have released 18 versions of the iPhone, scientists have cloned human cells... and Europe’s online payments have been rocked by market developments. Read more detail on the background here and read on for a summary of the major trends...

Strong customer authentication

Most online payments in the EEA will require strong customer authentication. This means two-factor authentication which meets the European Banking Authority (EBA) requirements - we’ll come back to this later.

Payment provider licensing

Any company providing payment services in the EU will require a payment license and be authorised and registered by the EBA.

Opens bank data to third parties

Opening up of bank data to make room for new players, including two new kinds of third party providers (TPPs):

Under PSD2, strong customer authentication is required on all payer-initiated transactions when both the card issuer and acquirer are within the EEA. If only one of the two is within the EEA, SCA is not required - so a business based in the US with a US bank would not be required to enforce strong authentication. This type of transaction is called 'one leg out'.

Map of global payment flows

Direct impact

PSD2 covers payment providers in all the EEA countries, so it will affect over 300 million ecommerce shoppers. It will be implemented in the UK despite Brexit as it was passed into law before the withdrawal.

This PSD2 requirement for strong customer authentication is likely to cause huge waves - when India implemented mandatory 3D Secure in 2014, some businesses reported a 25% drop in sales overnight due to the extra step in payments.

Similarly to the General Data Protection Regulation (GDPR), PSD2 will impact a business outside the EU if it provides payment services in the EEA, and it will need to have a payment license.

Indirect impact

This will still have indirect consequences for non-EEA businesses which have subsidiaries or branches within the EEA.

Burying your head in the sand is not going to work. Payment providers and banks are legally required to enforce PSD2. Online businesses who don’t fulfil the SCA requirements will start seeing their decline rates going up and conversion rate falling as customer banks reject non-authenticated payments.

Non-compliance puts both sellers and payment providers at risk of losing transaction volume. But for payment providers, non-compliance carries more serious consequences. National regulators have the power to impose fines and even revoke a payment provider’s license. Unlike GDPR, there are no fines specified, and as different members of the EEA are at different stages of implementation, the fine amounts may also vary.

Strong customer authentication demands multi-factor authentication on all payer-initiated payments including at least two of the below methods.

The EBA is strict about what’s considered compliant for inherence, possession & knowledge under SCA. We look closer at the new requirements for each element and how today’s widely used authentication methods compare.

The Strong Customer Authentication (SCA) regulatory technical standards (RTS) require two of three elements to be met in order for authentication to be successful. These three elements are inherence, possession, and knowledge. Or in other words, something the user is, something they have and something they know.

However, the EBA Opinion Paper is strict about what actually counts as inherence, possession, and knowledge under SCA. In this article, we take a closer look at the new requirements for each element and how this compares to widely-used methods today.

What counts as inherence?

Inherence is defined as ‘something the user is’. Article 8 of the technical standards refers to authentication elements that would be read by devices and software.

Depending on the implementation, these inherence elements are SCA compliant:

If a user memorizes a swiping path on their device, this does not count as an inherence element - but it does count as a knowledge element.

It’s important to note that user information sent via 3D Secure 2 (or EMV 3DS) is not considered SCA compliant - as none of the data relates to biological and behavioural biometrics - but this may change in the future.

Despite this not being compliant for SCA, this data is critical for Transaction Risk Analysis (TRA) and enabling exemptions.

What counts as possession?

The EBA states that this does not need to be something physical - for example, it could be an app, provided that there are reliable means to confirm possession. This can be confirmed through a One-Time Password (OTP) or a push notification. A QR code could also be used as evidence of possession.

Printed card details don’t count as possession. But dynamic card security codes can count, as long as they are changed regularly and are not printed on the card itself. This applies to some virtual cards too.

What counts as knowledge?

This is a non-exhaustive list of knowledge elements. It’s important to remember that the implementation approach will impact compliance.

Additional requirements for these elements

Dynamic linking

There must be at least two elements used to meet SCA compliance, and the elements must dynamically link the transaction to an amount and a payee specified by the payer when initiating the transaction. This means that at the time of the transaction, the value of the transaction and the identity of the recipient must be displayed. Dynamic linking is possible through the generation of authentication codes - there are strict security rules explained in more detail here.

Independence

The two elements must be independent of each other. One element cannot compromise the reliability of another.

Card reader eligibility

This scenario could constitute two elements in one - eg. in the typical use of a card reader, the PIN is first inserted to access the device, and then the OTP is generated.

Reusing elements

An element may be used twice within a session - for example to initiate a payment and perform another service that requires SCA eg. access an account.

A possible scenario is when a user performs SCA to save a new card to an account and then must also perform SCA to set up a payment. In this case, the device could be used as the possession element for both SCA instances.

For a payment provider, another example could be if a user accesses their account using a static password (knowledge) and OTP (possession) and then immediately initiates a payment.

Are today’s widely-used methods compliant?

Today, some SCA-compliant elements are already in use:

• E-wallets constitute the knowledge and/or inherence element, as the device is bound to an app.
• OTP combined with a knowledge element like a PIN, or an inherence element like a fingerprint.
• Some card readers would also be considered compliant.

There are also some non-compliant methods which are widely used today:

• Card details which are printed in full, and used in conjunction with an SMS OTP or 3DS2 communication protocol.
• SMS OTP and dynamic card security codes used in conjunction with each other, as they are both possession elements.

It's important to check the guidelines carefully!

The EBA is strict about what counts for each element behind SCA.

Possession must be something physical that the user has. A combination of QR codes, card readers or OTPs might be popular for those wishing to remain compliant.

Knowledge is about what the user knows - passcodes and PINs make this more familiar to everyday users - these are just two possible examples of something the user knows. Memorized swiping paths count as knowledge, not inherence.

The user data sent via 3DS currently does not count as the inherence element (something the user is). This may have come as a surprise to many businesses who believed the enhanced version of 3DS and its biometric capabilities provided salvation for those struggling to develop compliant solutions. This highlights how important it is to review guidelines carefully to ensure your authentication strategy is not taken by surprise.

When the EBA first floated the idea of strong customer authentication, they received a barrage of objections from the payments industry - remember this change in India in 2014 cost some businesses a quarter of their sales. Thankfully, the EBA consultation group worked through the feedback and outlined some exemptions to the strong customer authentication rule.

An online seller can’t apply for these exemptions itself, but a payment provider can apply on its behalf.

It’s important to remember that the cardholder’s bank has the final say on whether to grant or reject an exemption request.

The key exemptions to strong customer authentication are:

The EBA published Regulatory Technical Standards (RTS), which specify what payment providers’ need to take into account through real-time risk analysis. This covers:

• Previous spending patterns of the customer
• Payment history for all customers
• Location of the payer and the payee and if these are high-risk or abnormal
• Unusual payment patterns, spending or behavior of the customer
• Unusual information about the customer’s device/software access
• Malware infection in any session of the authentication procedure
• Known fraud scenarios

The EBA states that these factors must be combined and translated into a risk score for each payment, to determine whether a specific payment should be allowed without strong customer authen­tication.

Under PSD2, payment providers in the EEA will need to provide evidence of their transaction fraud rates to their national regulator every 90 days.

Using an exemption shifts the liability for fraud on to the payment provider, which is why it’s so important for payment providers to invest wisely in fraud protection.

Online sellers with a low fraud rate can choose to do the risk analysis

An online seller can contractually agree with its payment provider to take the risk of using this exemption and rely on its own risk management systems.

This means online sellers who have invested in fraud protection will have the upper hand when negotiating with payment providers who will be looking to keep their fraud rate low and share liability for fraud.

Likewise, payment providers who have low fraud rates and can maximize the chance of payments being accepted will be top of the wish list for online sellers.

Although some leading online businesses have started preparing for the impact of PSD2, these are more likely to be larger companies with dedicated teams and resources. A recent survey from Mastercard found that 75% of online merchants in Europe are potentially unaware of the new standards coming in September and that 32% of merchants would rather hear about this from their payment provider than via the bank.

The importance of issuer intelligence

A payment provider has the advantage of processing much higher numbers of transactions than any one of their online sellers. This means it has far more information on how different issuing banks react to exemption requests and which versions of 3D Secure are supported by each bank.

At Ravelin, we collect this information across every transaction - we call it issuer intelligence. This helps us to determine the best path to payment acceptance on each transaction, based on the bank’s past behaviour and payment risk level. Learn more about how we use the data on banks, customers and transactions in this webinar.

More complexity for customers = fewer successful transactions

Adding any extra steps into the checkout carries the risk of customers forgetting their passwords, abandoning their purchase or changing their mind. Online sellers will attempt to use strong customer authentication as little as possible, but they won’t be able to avoid it completely. If a payment doesn’t qualify for an exemption, or if the customer bank doesn’t grant an exemption, then the customer will have to authenticate the payment through 3D Secure.

3D Secure (3DS) is an additional layer of security for online credit and debit card payments - the most well-known examples being Verified by Visa, Mastercard SecureCode and American Express SafeKey. At the final stage of checkout it asks the buyer for a password so the bank can authorise the payment.

If 3D Secure is used to authenticate a payment, the payment is seen as secure and the customer’s bank is liable for any fraud. Although this makes it a powerful tool for online sellers wishing to avoid losses from fraud, so far most sellers only use 3D Secure for the most risky transactions as it seriously damages conversion - we’ll explain just how much a bit later.

Problems with 3D Secure 1

Clunky user interface

3D Secure has been around since 1999, it was developed long before responsive design, and it’s certainly not optimised for mobile - which will account for nearly half of online sales by 2020.

3D Secure is a massive source of frustration for customers, with many people telling companies they are losing their business over it. On the far end of the scale, the jarring interface means 3DS looks suspicious and can make customers feel less secure when paying online - leading them to quit checkout.

Rarely used, rarely remembered passwords

Because most online sellers are only using 3DS for the most risky transactions, customers are only being asked for their passcode once every so often. Customers often forget their passcode and can’t authenticate the payment. Resetting the password is often tiresome and long winded - 26% of customers abandon transactions due to a complicated checkout process.

New data from the first three months of 2020 reveals a significant improvement in acceptance rates using 3D Secure (3DS) in most of Europe. Check out the full results and comparison with 2019 data in the map and download the full report here.

Businesses are using authentication more in 2020

In the run up to the original PSD2 deadline for implementing Strong Customer Authentication (SCA) in September 2019, many merchants were not using authentication on a large proportion of their transactions. In fact, most merchants were only sending the most risky transactions to 3DS due to the well known negative customer experience and dropout associated with 3DS1.

Fast forward to Q1 2020, and the original September 2019 deadline for SCA has been extended. Despite the extension, many merchants had already put in a significant amount of work to get ready to use 3DS2. Despite the delay in deadlines, many of the merchants in this analysis are currently already sending a larger proportion of their traffic to 3DS, including many more genuine customers. This can partially explain why more transactions are being authenticated successfully.

3DS2 could be as good as it’s promised to be

Many of the merchants in this analysis are using 3DS2 when the issuer can support this, and only reverting to 3DS1 as a last resort. Although a lot of transactions were still authenticated using 3DS1, we know that a greater proportion of transactions analysed in Q1 2020 were authenticated using 3DS2. In contrast, almost no transactions were authenticated using 3DS2 in Q2 2019, except when some forward-thinking challenger banks were using 3DS2-style authentication methods. We can expect the move to 3DS2 to continue.

On the surface, it looks like 3DS2 could help deliver an improved user experience. Globally, the average time to authenticate has reduced from 42 seconds to 37 seconds, with the majority of the EEA countries seeing an even more dramatic improvement. Interestingly, the assumed percentage of frictionless payments (which take 5 seconds or less to authenticate) has also increased across many European countries.

This evidence of a better experience with 3DS2 is really encouraging for merchants who are currently sending or plan to send more transactions to authentication.

Consumers are more used to authentication

It’s also very likely that consumers are getting used to authenticating online more often, and have got better at doing it. This is supported by the widespread communications campaigns from issuing banks and merchants to consumers. We also saw coverage of PSD2 in the mainstream media at the end of 2019 during the peak shopping period around Christmas.

The current situation with the Covid-19 outbreak has also led to more people staying at home and a rise in ecommerce transactions. This could also mean consumers are getting more experience using different authentication methods. High demand and limited supply in some markets may also mean consumers are more invested in a purchase if they do not have the option to buy it in store or on another website, which can also improve authentication success.

We're also aware that this pressure on demand has led some merchants to restrict orders only allowing orders from low-risk regular customer accounts, and blocking or limiting orders from new accounts. This could also mean that a greater proportion of online transactions being authenticated were low risk - but as the restrictions ease up this is likely to change.

What does this mean for merchants?

The improvement in 3DS acceptance is great news for merchants!

This is especially true for merchants operating in Europe who have started the move or who have a solid strategy to move to 3DS2. It’s important to make sure that you are ready to use the most advanced 3DS2 versions as soon as possible, in order to optimise your payment authentication to get the best possible acceptance rate.

The acceptance rate for Australian-issued cards has also improved, likely as a result of the similar regulation changes. Interestingly, the 3DS acceptance rate for US-issued cards has decreased from 71% to 58%, meaning over two-fifths of payments sent to 3DS fail. This could be a result of the tightened measures elsewhere leading fraudsters to focus on the less secure US market.

It’s important to keep in mind that although the acceptance rates have improved, they are not at 100%. The global average acceptance rate of 87% means 13% (or 1 in 7) payments sent to 3DS are lost. Of course this will include some fraud, but there are also a number of factors which could be behind this other than fraud - such as customer drop off, server error, 3DS1 experience. The ultimate goal is to get as close to 100% acceptance as possible.

Even if it is a vast improvement, 3DS still carries a cost and applying it on every transaction will add up fast. Even with the improvements we’ve seen, leading merchants will benefit from using exemptions from authentication.

Next steps - keep tabs on issuers and prepare for exemptions

Issuing banks are going to be ready with the 3DS versions at different stages, and it’s critical to know what the issuer can support when sending the authentication request. For example, if you have enough data to prove a transaction is low-risk and the issuer is offering 3DS2, it’s far better to use an exemption and avoid authenticating. Likewise, if the issuer has a history of rejecting low-risk exemption requests, sending the transaction to 3DS will save you from incurring a soft-decline and speed up the checkout process.

It’s likely that exemptions will be the next big focus for leading merchants who want to optimise their authentication and derive the most benefit. It’s now common for card schemes to ask a consumer if they want to whitelist specific merchants after transactions - we expect to see more activity like this. At Ravelin, we’re busy collecting valuable issuer intelligence to inform our client’s decisions and support authentication requests with reliable data.

See the interactive map and download the full report here.

More data, less friction

3DS 2 enables payment providers to send much more risk analysis data to the customer’s bank, so that they can use this to recognise the customer and avoid strong customer authentication.

More ways to authenticate

In line with strong customer authentication requirements, 3DS 2 offers more flexible ways to authenticate that suit the customer, such as facial scanning and one time passwords. Again, this is still dependent on whether the cardholder’s bank offers it.

Better user experience

The seller can customize the challenge page, and 3D Secure 2 will be mobile optimised with iOS and Android software development kits for native payment options, rather than janky iframes, pop-ups or redirects.

Although 3D Secure 2 looks like it will be a big improvement on earlier versions, there are some signs that it may still cause problems. 3DS 2 will be heavily dependent on mobile phone methods of authentication for many payments, which will still cause issues for a customer not carrying their phone or in areas with low signal.

Our analysis on 3DS payments found that even banks with 3DS 2 level authentication, such as app-based authentication and one-time passwords, still lost 19% of payments.

This is why it’s important for online sellers and payment providers to prepare for PSD2, even those outside of Europe. Leading companies will have a strong fraud toolkit with a strategy for maximising the use of exemptions to give genuine customers a smooth journey. Visit this page to learn more about how Ravelin Accept delivers on strong customer authentication requirements.

When the final PSD2 deadlines come into force, merchants will be expected to apply SCA on millions more payer-initiated transactions. This will certainly impact the overall acceptance rate, with an expected spike in soft declines. The size of the impact isn't yet certain, so merchants need to prepare to get the best possible outcome for each transaction under the new rules.

3DS2 will help reduce the negative effects, for example, it’s less likely to result in false declines up to a certain point. But for 3DS to be effective all-round you have to be using it correctly, and importantly only using it when you have to.

The ultimate goal is to use dynamic authentication across all your transactions. Why ask your customers to jump through authentication hoops if you already have enough data to do it yourself? Additionally, despite the obvious improvements behind 3DS2, it’s still worth saving your business the cost of authentication and increased risk of dropout on every transaction.

What is authentication enrichment?

Authentication enrichment is adding rich merchant and fraud data to an Authentication Request (AReq). An AReq is essentially a message to the issuer requesting authentication on a transaction. The AReq can also be used to share data with the issuer, to allow them to make a more informed decision.

Why should you enrich your AReq?

Adding the extra data will help secure a frictionless checkout experience. Put simply, the more data the issuer has, the better able they are to grant exemptions from authentication. Imagine trying to hire a car without any evidence that you’ve passed your driving test - you’d look like a big risk!

If you’re providing the absolute minimum on your authentication requests and not using data enrichment to complete key fields, you’re not giving the issuer what they need to enable frictionless authentication. Without all the data, it’s more likely that the issuer will apply 3DS on all transactions, even those which are low-risk and would qualify for an exemption.

The 3DS server forms the AReq and there is only one per authentication. The 3DS Server generates the AReq, which is sent to the issuer’s Access Control Server via the card schemes’ Directory Servers. This is how the issuers can receive all the enriched data to enable them to approve an exemption request or apply frictionless authentication.

With 3DS2, merchants can send over 100 data points to the issuer - compared to less than 10 using 3DS1. The AReq is made up of four different groups of fields, with some classed as ‘Recommended’ and some ‘Optional’. The four groups are:

1) Cardholder Account Information (eg: Cardholder Account Change Indicator, Number of Provisioning Attempts per Day, Payment Account Age and Shipping Address Usage).

2) Merchant Risk Indicator (eg: Delivery Email Address, Gift Card Amount, Pre-Order Date, Shipping Indicator (the shipping method, such as billing address, store pick-up, etc))

3) 3DS Requestor Information (eg: 3DS Requestor Authentication Method, 3DS Requestor Authentication Timestamp)

4) 3DS Requestor Prior Transaction Authentication Information (eg: 3DS Requestor Prior Transaction Authentication Method, 3DS Requestor Prior Transaction Authentication Reference)

What’s important to remember is that different organizations place different emphasis on these fields. EMV Co and the card schemes all have different preferences about what is Recommended/Optional. For example:

• ‘3DS Requester Challenge Indicator’

EMV Co class this field as Optional, but for Visa this field is always required.

• Address Match Indicator

This is optional for EMVCo & Mastercard, but required if available for Visa.

Issuers don’t get access to all the customer-centric information that merchants and Ravelin can draw insights from. This can include device data, login data or whether a user’s details appear in our breached credentials database.

We can help you share these insights with the issuer, enabling you to show evidence that you are applying robust risk analysis on your transactions. This allows you to build trust with every enriched AReq sent and successful authentication or authorization.

Download our in-depth guide to authentication enrichment here. Learn more about what data can be shared, why it this is important and how Ravelin can help your business optimise your authentication strategy.