Exemptions and Data Science: The European Way of Building 3DS

When to hedge fraud risk, and when not to, in the land of strict regulation.

Fraud management is the killer app of AI.

When auditors examine a company’s financial data, what do they do? They pick a random sample, and meticulously verify that it’s handled properly. Human auditors are precise, but unscalable; they can only do so much.

AI auditors are imprecise (they let some fraud in, and flag some legit transactions). But they don’t do sampling; each transaction is analyzed.

Last week, we looked at why US merchants use 3DS as long as it doesn’t involve explicit action from the customers. But notice that they rely on the issuer’s assessment of the risk. If you buy something online in the US, the company has made little to no effort to check if the transaction is fraudulent.

And that is a shame. Over the last 10 years, machine learning has become so much simpler. Over the last 5, stupidly simple.

Merchants aren’t incentivized to implement fraud engines. Because the authentication of the customer is optional in the US, the liability in case of chargeback falls on the merchant by default.

The customer’s bank decides whether to accept or not the risk. Which leaves merchants with very little to gain from becoming good at detecting fraudsters.

It is a matter of policy.

In Europe¹, regulators have accidentally created an incentive for merchants to get good at fraud busting. Here, the authentication of the customer is required. This, in practice, means that the issuer is liable for chargebacks by default.

European merchants are forced to decide if they accept the risk, with the approval of the issuer.

I’m Alvaro Duran, and this is The Payments Engineer Playbook. Social media is awash in content related to software design interviews that use payment systems. But it’s dry of practical insight on how to build this critical software for real users, and real money.

I know this because I’ve built and maintained payment systems for almost ten years, and I often come across some video on Youtube or some diagram on LinkedIn that’s just wrong. Throughout my career, I had seen all types of interesting conversations about what works and what doesn’t. But unfortunately, most of them have happened behind closed doors.

And then, at some point, I thought, “you know what? It’s time we have these conversations in public”.

In The Payments Engineer Playbook, we investigate the technology that transfers money. All to help you become a smarter, more skillful and more successful payments engineer. And we do that by cutting off one sliver of it and extract tactics from it. So let’s get into this article about how European merchants deal with 3DS, and make sure you click the subscribe button on your way down.

---

It’s pretty clear for everyone in the payments industry that 3DS in Europe  and in the US is done differently.

And yet, there’s very little out there that makes this divide explicitly. We’ve already looked at the 3DS authentication process from the point of view of US merchants, who avoid routing the customer through the challenge flow by simply canceling the authentication challenge.

European merchants can’t cancel 3DS. It is forced upon them by the regulators. What they can do though is request exemptions and exclusions.

An exclusion is something very simple: merchants flag transactions that are out of the scope of European regulation. For example, if the customer is not based in Europe, they don’t have to go through 3DS. Or if the customer is paying over the phone, they don’t have to do it either.

Exclusions are simple enough: they’re a somewhat fixed set of rules that you just follow blindly.

Exemptions are the tricky part.

The instability of asking for an exemption

When to ask for an exemption or not is not simply a matter of risk appetite. Online, every little friction added to the experience is an excuse for the customer not to buy.

It is as if your customers were traveling on a train, and took every slowdown as an opportunity to jump out. According to a study from Ravelin, adding this extra authentication step brings conversion down by 30%.

Exemptions are requests made by the merchant to the issuer so that the customer doesn’t go through the authentication step. What European merchants offer in exchange is that they accept to be liable for any chargeback.

Despite the accepted fraud risk, businesses that don’t request exemptions from time to time are effectively giving that 30% in sales to their competitors, which means that they have to get good at this very fast.

Yet, many exemptions are, for lack of a better word, unstable.

If you’ve been to Europe, you’ve probably noticed that sometimes, tapping your contactless card in the POS system sometimes asks you to enter your PIN. This is because in the offline world, PSD2 applies to contactless payments. Every time you’re not entering your PIN is because the merchant has obtained a Low Value Transaction exemption from your bank.

What I mean by unstable is this: the LVT exemption applies only if the amount is lower than 30 euros, and you’ve either done less than 5 payments without doing any authentication, or the amount since you last did is less than 100 euros. As you can imagine, that’s information that the merchant doesn’t have. This means that, every time, the merchant is requesting this exemption, and hoping for the best.

If you’re taking away one thing from this article, is this: exemptions are unstable, because the issuer is the ultimate decision maker.

This is why there are many similarities in the way European and American merchants perform 3DS, including sending as much data as they can through the 3DS Method URL. It is in their best interest to help the issuer assess the risk of the transaction. It’ll persuade them to approve the exemption.

What really matters about 3DS exemptions

LVTs are the simplest exemptions, but there are more. Subscription payments (called MIT or “merchant initiated transactions”) are exempted, as long as the customer performs an authentication on the first attempt (with caveats: Visa and Mastercard treat subscription authentications differently). Some cardholders can flag merchants as whitelisted, which are simply merchants they trust (although support for this exemption is not widespread). And there’s also something that’s pretty much exclusive for travel companies, which is the corporate payments exemption, which are cards issued to employees of big companies that are in possession of a travel agency that buys plane tickets for them.

Unlike LVTs, MIT, whitelisted merchant and corporate exemptions are somewhat niche.

The one that matters to most merchants is called TRA. TRA is the “trust me bro” of 3DS.

This exemption is requested when the merchant has assessed the transaction’s fraud risk to be low. This is one of the most useful and most widely supported exemptions.

It’s also the trickiest.

For a TRA to go through, both the merchant’s and the client’s banks have to give it a thumbs up. PSD2 is extremely explicit about the rate of fraud that acquirers have to comply with if they want to avoid fines, and naturally, they’re extremely vigilant with the merchants as a result.

If you think that TRA exemptions are just a free pass for your customers, think again.

Two exemption types

If you recall from last week, US merchants provided as much data as they could to the issuer, in the hopes of getting an “authentication approved” response, and not a “challenge”.

In Europe, because 3DS is mandatory, things work a little bit differently. But the goal is the same: to avoid showing customers the challenge process as much as possible.

There are two ways you can request an exemption: over the 3DS rails, and directly on the authorization request.

An exemption over the 3DS rails means that the request sent in the AReq contains a few exemption indicators that suggest that this transaction shouldn’t receive an ARes requesting a challenge (go back to last week’s article if you need to refresh what AReq or ARes mean). When you request an exemption over the 3DS rails, you leave the door open for the issuer to send a challenge anyway. But the advantage is that, if the issuer approves, the liability stays with the issuer, and not with you.

With an approved exemption over the 3DS rails, the transaction is labeled as "frictionless", the customer doesn’t perform a challenge, and in case of chargeback, the issuer is liable.

On the other hand, the merchant can simply avoid the 3DS step altogether, and streamline the process by requesting an exemption over the authorization request. The merchant includes the exemption details in the authorization, and doesn’t even ask for permission to avoid the authentication step; it goes around it.

An exemption over the authorization request is faster and simpler, but it’s risky because of two things. One, the liability goes to the merchant, not the issuer. And two, the issuer can still reject the payment altogether, requesting that the customer must go through 3DS after all. This is called a soft decline.

A soft decline could arrive when the customer is no longer at checkout, which means that the sale will be almost certainly lost. There are some approaches to mitigate this risk (sending an email explaining what’s going on is the industry standard), but the process has way more friction than it would have, had the customer simply go through the 3DS to begin with.

With an exemption over the authorization request, the transaction could be soft declined, there’s risk of cart abandonment, and the liability still falls with the merchant. But it’s fast, and if the merchant can build a strong machine learning model that’s on par with the issuer, the approval rate may be even better than over the 3DS rails.

For that reason, there is a cottage industry of tech companies offering what they call exemption engines. Systems that integrate with your online store to analyze your customers’ data and offer automated advice on which exemption, if any, to request. Larger companies have since the beginnings of PSD2 started to implement their own, in-house fraud detection systems, as the cost of these third party services are no longer worth to them.

Trusting strangers online

Fraud is a little bit like marketing: it’s seen as a senseless cost from the outside. But being clever in which fraud risk your company is willing to admit can be very lucrative. European merchants have adapted to a regulatory environment that demands them to be more savvy with fraud, and the technology keeps getting easier and easier to implement, even for smaller companies.

When I started doing research to complement my own experience with 3DS, I was a bit skeptical about what the outside world had published about it. And I was right! Content marketing on 3DS abounds (there’s vibrant competition for service providers, after all), but not enough insight that’s practical for engineers.

I must confess, I learned most of this stuff by asking around more experienced colleagues. Even the “trust me bro” is a quote from one of them.

Having looked at 3DS from the European and American angle has given me a new perspective on how the word “fraud” predisposes so many people negatively. We must have no fraudulent transactions is still a goal for some online merchants.

A better way to reframe this conversation is to start talking about trust. You trust certain people under certain circumstances.

That’s why trying to avoid fraud is a silly proposition. The only way to stop fraud completely is to not trust anyone under any circumstances.

The regulation may be different, but merchants in Europe, the US, and all over the world are balancing two conflicting but important goals: how to minimize the cost of fraudulent transactions, and how to improve the checkout experience.

This balancing act happens because their product decisions impact saints and sinners equally.

Never forgetting what the goal is makes these decisions easier.

This has been The Payments Engineer Playbook. I’ll see you next week.

---

PS: Last night, my wife told me that I was crazy.

She’d asked me how the Playbook was going, and I told her that a few pledges had come already. Enough to make Substack try to nudge me into start accepting payments immediately.

Don’t worry, I won’t do it. Not until the beginning of next year.

Anyway, she asked me a little bit about the pricing, and I told her that there was a monthly price ($15), and an annual price ($149).

And then, I told her about the Playbook guarantee: that I would refund the cost of the subscription for that period if I was requested to, no questions asked.

She knew that she was hearing it. But she couldn’t make herself believe it.

‘You shouldn’t have that guarantee’, she said. ‘You’ve written a lot in public. They already have an idea of what they’re buying’.

‘Maybe’, I said. ‘But it removes the fear of making a mistake. It’ll make them more willing to give the Playbook a chance’.

She shook her head, and moved on to another topic.

The Playbook guarantee, just like 3DS exemptions, is an effort on removing obstacles. You’re helicoptering around the “Pay” button, excited, but unsure. What if this, what if that.

Guaranteeing that, should you want a refund, you’re going to get it, puts you at ease.

But there may be some other reason that I’m not seeing. You recognize the value that The Payments Engineer Playbook will give you, and you want to give it a chance, but something gets in the way.

If you feel that way, can I ask you to answer this single question? It’ll only take a couple of seconds.

I write The Playbook in such a way that engineers building money software gain more than 10x in a salary increase what they pay for a subscription.

If you know somebody who can benefit from this newsletter, can I ask you to forward this email to them?

Even if they can’t afford it themselves, most companies have a training budget for their employees (ask your manager). These things move slowly though, so if you need approval from your company, better hurry up before the window closes.

And if someone you respect shared this article with you, do me a favor and subscribe. Every week I feel I’m getting better at this. That means that my best articles on how to build payment systems are probably yet to be written.

You can only find out if you subscribe to The Payments Engineer Playbook. I’ll see you around.

1. Europe is a very confusing term, even for Europeans. There’s the EU, but there’s also the EEA, the Schengen Area, and the Eurozone. These organizations’ members overlap substantially, but not completely. In this article, I’ll be using the term “Europe” to refer to those countries that have adopted PSD2, the regulation that enforces 3DS in the continent. This includes the EU, the non-EU members of the EEA (Iceland, Liechtenstein and Norway) and, with caveats, the UK. Despite Brexit, the UK has mirrored some of the European regulation into their national laws, including PSD2, just like they did with GDPR. For the purposes of 3DS, Brexit didn’t happen. Europe is a very confusing term.