Posted inPCI DSS compliance
New EU regulations affecting electronic payments are about to impact UK consumers. But what will PSD2 and SCA mean for merchants — and what do they need to know?
Just when you thought GDPR was nicely bedded down, along comes another mammoth compliance regulation. PSD2, the EU's second Payment Services Directive, actually came into effect in January, but merchants and consumers will notice the biggest change in September.
The big idea behind PSD2 is to encourage greater competition and innovation — which is music to the ears of FinTech companies. An initiative called Access to Accounts (XS2A) will bring Account Information and Payment Initiation services under regulation and allow non-banks to offer payment services. This might lead to more accessible services, faster payments and lower costs.
There's a second reason for PSD2. The EU wants to improve security and reduce fraud by introducing Strong Consumer Authentication (SCA) for electronic payments. And it's this feature that was due to come into effect on 14 September 2019 but following the FCA's confirmation there will now be a phased introduction of SCA over the next year and half..
However, on 21st June 2019, the European Banking Authority (EBA) published an opinion on SCA. This opinion allows the FCA to give some first extra time to implement SCA.
The legal deadline for complying with the Regulatory Technical Standards on Strong Customer Authentication will be announced over the next eighteen months. However, the FCA recognises the challenges in meeting this deadline and has been working with the industry to develop a plan to migrate the industry to implement SCA for card payments in e-commerce as soon as possible after this. What this means is that issuers need to be able to demonstrate that they have a plan in place to meet SCA but the enforcement could possibly be delayed until 2020.
As these regulations have been adopted by the UK already, it's not anticipated that Brexit will prevent their full implementation.
Two-factor authentication as standard
The most common way organisations will comply with SCA for card payments, is to adopt the payment security process 3DS 2.0 (the latest version of 3D Secure). This provides more potential fraud signals, shares 135 data points and supports biometrics.
SCA will mean extra hoops for shoppers to jump through when making electronic payments. Customers will have to present two out of three factors from the following list:
- Something you are (eg. biometrics, such as a fingerprint)
- Something you have (eg. a pre-registered device or token generator)
- Something you know (eg. a password or PIN)
Many consumers are familiar already with authentication beyond passwords. They've got iPhones that recognise their touch, banking devices that generate security numbers — or codes that are sent to their mobile phones. But with SCA, this will become the norm, not the exception.
For retailers, this could sound like awful news (most global merchants will be affected if they have EU issued cards transacting via an EU acquirer). No retailer likes the idea of customers losing their nerve or running out of patience at the checkout because there's another obstacle in their way.
There's no avoiding it, SCA could present a very real problem when the deadline approaches for organisations receiving online payments — see our blog on Advice for merchants and how to save sales.
But SCA isn't a blanket change. There are some exemptions. These can include:
- Low value transactions — Those of €30 or less are not included within SCA. Regular payments of the same amount can be included, but must not accumulate to over €100 or SCA will be triggered
- Trusted listings — Consumers can ask the issuer for a merchant to be part of a ‘trusted payee’ list
- Low risk transactions — The highest value agreed would be €500 and the merchant must maintain a low average fraud rate to keep this
Also, certain transactions are out of scope, regardless of their value:
- Merchant Initiated Transactions (MIT) - Repeat payments
- Mail Order / Telephone Order (MOTO) - Telephone / contact centre payments
- One Leg Out (OLO) - Where the issuer or the acquirer is outside the EEA
Also, a ‘grandfathering’ rule is in place to remove the need to re-authenticate existing card-on-file customers. However, any change to that customer's registration with the merchant would trigger the need for re-authentication.
There are also other tools that can increase exemption levels, such as:
- Visa Transaction Advisor: This is a Cybersource tool used to identify the opportunity for an exemption
- Visa Trusted Listing: This allows customers to request that a merchant is added to the trusted listing as part of the 3DS transaction — to remember things for next time
However, sometimes a green light might still get a red light. That's because, despite all the possible exemptions, issuers may still decline them and force the extra authentication anyway.
So who's responsible for SCA?
The ultimate responsibility and the legal obligation lies with the issuers (typically banks). They are responsible for providing the authentication mechanism, adhering to the rules and are responsible for the consequences.
However, that responsibility is pushed down the chain — meaning that from September 14 issuers will no longer process transactions from acquirers (and therefore payment service providers, and therefore merchants) if they do not meet the requirements of SCA.
Merchants must support the ‘step up’ process as part of their eCommerce customer journeys and set transaction exemption flags.
Merchant Suppliers, such as Eckoh, will have 3DS v2 as part the eCommerce journey and set transaction exemption flags appropriately.
What about other sales scenarios?
PSD2 and SCA relates to electronic payments. But what about when the lines blur? After all, in our multi-channel world, transactions are made in many different ways. What fits within the scope of SCA and what's outside? Here are some quick answers to common questions:
Q: Do payments made over a phone-call require SCA?
A: No. Interactive Voice Response (IVR) payments and phone orders to agents (and for mail orders), known as Mail-Order-Telephone-Order (MOTO), are not covered — unless the call culminates in an e-commerce order, then that transaction needs SCA.
Q: What about payments made during a chat session with an agent?
A: If the payment processing is initiated by the agent, as in our ChatGuard solution, these transactions are considered to be MOTO transactions and therefore SCA is not required.
Q: How does SCA apply to pre-loaded e-Wallets?
A: It's required that merchants authenticate the load AND authenticate the transaction. However, it may be that exemptions are the solution here but this will take some time to iron out.
Q: What about 'split auth and settle' payments?
A: Here, the merchant must set the 3DS flags at the initial authentication request.
Specific advice for merchants
Merchants will be affected by SCA ... and forward-thinking businesses will look for opportunities to turn the change to their advantage.
Latest Blog Items
Monday, 18 November 2019 Stop sending our customers awayNot so long ago, we were excited about the amazing ROI that contact centres could expect from Web Chat. It hasn’t disappointed - the proof is out there. So what more can you expect once you can pay in chat too?
Tuesday, 12 November 2019 Don’t deny your customers the ability to paye-Wallet Payments mean you can offer every possible payment channel to your customers
Wednesday, 30 October 2019 Challenge #1: Your agents are swamped with basic questionsAre your contact centre agents getting swamped with repetitive low-value questions — preventing callers with bigger issues from getting through? If so, it's time to take action.