Solutions overview
Harness the power of your data
Support and investigations
Support services for Ravelin
Online payment fraud
Account security
Policyabuse
Marketplace fraud
3DSecure
Resource Zone
Deep dives on fraud & payments topics
API & developer docs
APIs, glossary, guides, libraries and SDKs
Global Payment Regulation Map
Track PSD2 & more with a full report
Blog
The latest fraud & payments updates
Insights
In-depth guides to fraud, payments & security
About Ravelin
Discover the story about Ravelin
Careers
Join our dynamic team
Customers
Read more about our happy customers
Press
Get the latest Ravelin news
Support & investigations
Accept more payments securely
Protect your customer accounts
Policy abuse
Stop policy abuse to protect your bottom line
Ravelin for marketplace fraud
3D Secure
Ravelin 3DS & SDKs
Resource zone
Global Payment regulation map
Read more about our happy custmomers
Blog / News
Why ask your customers to jump through hoops to authenticate if you already have enough data to prove a level of risk? 3DS2 enables you to share more data with the issuer - here's how it works...
Share this article:
When the final PSD2 deadlines come into force, merchants will be expected to apply Strong Customer Authentication (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.
Using the most advanced form of 3D Secure (3DS) will give merchants the best chance of success - here's a reminder of the improvements behind 3DS2:
Although 3DS2 looks like it will be a big improvement on earlier versions, there are some signs that it may still cause problems. 3DS2 will be heavily dependent on mobile phone methods of authentication for many payments, which may cause issues for a customer without their phone or in areas with low signal
Ultimately, for 3DS to be really effective you have to be using it correctly, and importantly only using it when you have to.
The best approach is to use dynamic authentication across all your transactions. Why ask your customers to jump through hoops to authenticate if you already have enough data to prove a level of risk? Plus, despite the obvious improvements behind 3DS2, it’s still worth saving your business the extra cost of authentication and increased dropout risk on every transaction.
This is where authentication enrichment comes in.
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.
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:
It's important to remember 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.
Jessica Allen, Head of Content
Blog / Fraud Analytics
Fraud prevention is a delicate balance between stopping fraud and maintaining good customer experiences. But what is the most effective way to measure this outcome?
Ravelin Technology, Writer
Blog / Machine Learning
Online payment fraud is one of the biggest threats facing grocery merchants. And it’s only gotten worse. How are fraudsters using the cost of living crisis to take advantage of your business?
There’s a new fraud threat on the rise – and it’s your customers. First-party fraud is infamously tricky to catch and a huge revenue risk. How can you detect and deter criminal behavior in your customer base?