Many businesses are still grappling with how best to satisfy Strong Customer Authentication (SCA) requirements under the EU Payment Services Directive (PSD2) without losing customers. Currently, merchants can choose to opt out lower risk transactions from SCA requirements, mostly in the form of 3DSecure, which shifts liability back to the card merchant. This will no longer be allowed under PSD2, creating a paradigm shift. Leveraging Transaction Risk Analysis will be vital for merchants to retain control over the buyer’s journey, but that will require close collaboration with payment processors.
Consumers are increasingly sensitive to any added friction and are voting with their feet. An estimated 70% of consumers abandon online forms due to a poor experience. So the question is, how do you balance risk and compliance without compromising the customer experience? I suggest by combining next-generation fraud prevention with risk-based consumer authentication, but more on that later.
There is good news!
Paragraph 21 of the European Banking Authority’s (EBA) Regulatory Technical Standards (RTS) document was a response to industry concerns, where they conceded that some exceptions should be allowed for risk-based SCA. The relevant section details:
21. [...] the EBA agrees with the view expressed by these respondents that a risk-based approach, including the ability to conduct detailed Transaction Risk Analysis and fraud monitoring, is essential to achieve the objective under PSD2 of reducing overall fraud.
Consequently the EBA arrived at the view that, in accordance with Article 98(2)(a) PSD2, an exemption based on such an analysis should be added in a new Article 16 RTS. The RTS also reiterate the importance of risk and fraud monitoring in general as a necessary complement to the principle of SCA laid out in PSD2 as stated in a new Article 2 RTS.
Transaction Risk Analysis
Essentially, the EBA has agreed that payment service providers (PSPs) and merchants should be able to request exemptions to SCA if they can attain target fraud rates. To be allowed the exemption based on Transaction Risk Analysis, the solution must operate in real-time and must verify a transaction against anomalies in user behavior. Checkpoints include the following:
- Previous spending patterns of the payer
- Payment transaction history of the payer
- Location of the payer and the payee at the time of the payment
- Previous use of the access device or the software provided to the payment service user for SCA
The table of exemptions is as follows:
|Exemption threshold value||Reference fraud rate % Remote card-based payments|
|€250||0.01 - 0.06|
|€100||0.06 - 0.13|
Reference fraud rate formula:
Reference Fraud Rate % =
Total value of successful fraudulent transactions
Total value of all successful transactions (including SCA and exempted)
Competitive Advantages to Achieving Lowest Reference Fraud Rate
PSPs and merchants will have to work much more collaboratively to reduce fraud in order to reach the highest exemption thresholds, but this could provide a major competitive advantage on a number of fronts:
- One click shopping: Being able to expedite payment processing for a higher volume of transactions, i.e. all transactions below €500 vs. only transactions below €30, which is the default exemption level.
- Cost savings: Reduce the overall number of transactions subject to higher cost SCA checks
- Reduced friction: Only step-up transactions above the exemption threshold or with risk signals to SCA
iovation is uniquely suited to help businesses drive down their fraud rates to maximize transaction risk analysis exemptions, while also providing an elegant, risk-based authentication solution to satisfy SCA requirements. Helping you strike the balance between compliance and customer experience.
We combine ClearKey, our lightweight and transparent customer authentication, with FraudForce, a real-time risk insight and fraud prevention solution, to confidently identify returning devices and check for risk signals that could signal fraud.
iovation’s deep device intelligence allows us to provide real-time data on the location of the payer and payee at time of payment, and to determine previous use of the access device provided to the payment service user for SCA. This intelligence coupled with your data on previous spending patterns of the payer will allow your business to confidently decide to accept, reject or review each transaction. This allows you to reduce your fraud rate, reduce the overall number of transactions subject to SCA, and increase customer satisfaction.
PSD2 requires that SCA must use two or more of the following independent factors:
- Knowledge: Something only the user knows (e.g., PIN, password)
- Possession: Something only the user possesses (e.g., smartphone, IoT device)
- Inherence: Something the user is (e.g., biometrics, voiceprint)
For those transactions that are subject to SCA, you can layer transparent authentication onto your existing authentication system to utilize the device (possession factor) as a second authentication factor. This allows you to satisfy SCA requirements without adding additional steps to the checkout process unnecessarily.
MFA for SCA, Hip Hip Hooray
- Out of band authentication: Deliver both independent authentication elements in one service, the user’s mobile device. Each element uses its own secure channel so that the compromise of one element does not compromise the other.
- Omnichannel consumer authentication: The lightweight SDK can be deployed through your own application, managing all digital and physical authentication processes across both online and offline platforms: online, mobile, call centers, kiosks, ATMs, IoT devices. All while maintaining your own brand identity.
- Configurable authentication methods: Such as biometrics, geofencing, pattern codes, and device proximity pairing.
- Platform-agnostic: Leverage LaunchKey with virtually any online service.
- Decentralized, anonymous architecture: Eliminate or reduce the most common attack vectors associated with password-based authentication.
- Dynamic Linking: SCA requires that authentication elements shall generate an authentication code to the payer’s PSP, specific to the amount and payee agreed by the payer when initiating the transaction. This is also known as dynamic linking. LaunchKey is able to facilitate dynamic linking.
Compliance doesn’t have to come at the cost of degrading the customer experience. To achieve market differentiation in the age of PSD2, PSPs and merchants will need to closely collaborate to optimize their fraud prevention strategies while also elegantly solving for SCA requirements. Learn how iovation’s solutions can help your business.