What is PSD2?
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...
Increasing online payment fraud in Europe
The European Central Bank (ECB) recorded a 66% increase in card not present fraud (online payment fraud) between 2011-2016, which was the main reason behind why fraud overall increased by 35%. Online fraud now makes up 73% of fraud in Europe and this is steadily rising.
The rise of the API economy
Application Programming Interfaces (APIs) allow different systems to talk to each other. APIs are fundamental to the success of companies like Amazon, Google, Uber, Stripe, Braintree etc. and they’ve supported the creation of whole new business models, including fintechs. APIs will provide the means for banking and payments to become more open.
Unregulated new business models
Since PSD1 there has been growth and innovation in the digital payments market with a whole host of new fintech players. So far, these new business types have not been fully regulated and agreements have been somewhat ad-hoc. PSD2 will provide standards and structure and allow these new companies to access customer bank accounts.
The goals of PSD2
- Make the European payments market more integrated and efficient
- Improve the level playing field for payment service providers (including new players)
- Make payments safer and more secure
- Protect consumers from fraud
PSD2 is part of a wider legislation which has a whole range of implications for banks, payment providers, third party providers and consumers - more detail on far-reaching effects in this podcast. On this page we’ll focus on the changes to online payments and how they will affect online sellers and payment providers.
PSD2 aims to secure digital payments and expand the financial ecosystem
Key changes for online sellers and payment providers
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):
How and where will SCA have an impact?
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
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.
This will still have indirect consequences for non-EEA businesses which have subsidiaries or branches within the EEA.
What are the consequences for non-compliance?
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 explained
Strong customer authentication demands multi-factor authentication on all payer-initiated payments including at least two of the below methods.
Something you know
e.g. pin or password
Something you have
e.g. phone or device
Something you are
e.g. facial scan or fingerprint
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
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.
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.
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.
Exemptions to strong customer authentication
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:
A customer can whitelist their chosen online sellers as safe so they don’t have to authenticate each time they buy something. This has potential work well - but it relies on the customer taking action, so online sellers will need to work hard on communications for this to take off.
If a customer signs up to a subscription or recurring billing for exactly the same amount with the same online seller, they will only need to authenticate the first time they pay. This is a great exemption for sellers like Netflix, but it won’t cover repeat payments if the amounts differ (eg. a weekly online grocery shop) or if the value changes (eg. if Netflix increases their prices).
Low-value payments under €30
This exemption allows payment providers to avoid applying strong customer authentication for online payments under €30 up to a certain cumulative limit. The customer’s bank has the choice to either request strong customer authentication on every sixth payment under €30 or request strong customer authentication if the combined value of several payments goes above €100.
Although it may look attractive on the surface, this exemption is tricky for online sellers and payment providers. The cardholder’s bank decides which cumulative limit to use, so it’s hard to know whether the bank will choose to limit the number of transactions or total value.
For example, a customer could make five payments of €10 and be challenged on the sixth, or make up to 10 payments of €10 before they need to authenticate.
This exemption also doesn’t help online sellers with an average order value above €30.
This is likely to be the most commonly used exemption.
If a payment provider has low fraud rates within the prescribed PSD2 fraud limits, then it will be able to use real-time transaction risk analysis to apply for exemptions on behalf of its sellers for all low-risk payments up to €500. There are no low-risk exemptions for transactions over €500.
Real-time risk analysis technique
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 authentication.
Fraud rate limits for payment providers
Under PSD2, payment providers in the EEA will need to provide evidence of their transaction fraud rates to their national regulator every 90 days.
|Fraud transaction rate must be below||To apply for exemptions on payments up to|
So a payment provider with a fraud rate of:
- Between 0.13% and 0.06% can exempt all low-risk payments under €100
- Between 0.06% and 0.01% can exempt all low-risk payments under €250
- Below 0.01% can exempt all low-risk payments under €500 (this will be very rare)
If a payment provider uses an exemption, they will be liable for the payment in case of fraud
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.
Online sellers with low fraud rates will be in high demand from payment providers
The online seller’s wish list for payment providers under PSD2
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.
Low fraud rates
Low fraud rates across all online sellers allows payment providers to request SCA exemptions
High acceptance rates
Online sellers want to minimise friction and avoid SCA for their genuine customers
Guidance and support
Online sellers will look to payment providers for PSD2 expertise and help to manage the changes ahead
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.
of online sellers in the EU are unaware of SCA requirements
of EU banks missed the original PSD2 deadline
of online sellers in the EU will miss the September SCA deadline
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.
Strong customer authentication with 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 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.
How much does 3DS really impact online payments?
There's a range of data around how much 3DS affects payments. We've been analysing the impact since Q1 2019, here's what we've found so far...
In Q1 2019, we looked at millions of payments and found that 22% of payments sent to 3DS are lost - further analysis revealed:
- 3DS authentication took an average of 37 seconds
- 91% of payments cause friction taking over 5 seconds to authenticate
- Acceptance rates of the top 20 global banks by volume range from 68-92%
See the full results from all global payments in an infographic here.
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.
Why have 3D Secure acceptance rates improved?
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.
How 3D Secure 2 is different
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.
Potential issues with 3D Secure 2
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.
What is authentication enrichment and why should you do it?
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.
How is the AReq message sent?
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.
What new data can issuers receive under 3DS2?
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.
Why enriching the AReq builds trust with the issuer
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.