What is authentication enrichment and why should you do it?

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:

• More data, less friction - send much more risk analysis data to the issuing bank, so that they can use this to recognise the customer and avoid strong customer authentication.
• More flexible ways to authenticate to suit the customer - eg.facial scanning and one time passwords.
• Better user experience - mobile optimised with iOS and Android software development kits for native payment options.

Potential issues with 3D Secure 2

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.

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)

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.

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.