PSD2/SCA has arrived and although it is in some ways a trial-by-error work-in-progress, it promises to help with safety and security of transactions in the European Union and European Economic Area. But it is well documented that SCA will also lead to a certain percentage of cart abandonment for eCommerce, travel, digital goods, etc. What can be done to safeguard sales and growth? Maximize use of SCA exemptions. We'll take a closer look at what will probably prove to be the most popular exemption: Transaction Risk Analysis.

Some industry analysts have predicted approximately 20% decreases in acceptance rates of transactions due to SCA. We’ve been talking to a number of our friends in the payments industry and some merchants have reported recent, drastic declines in acceptance rates (some even reporting dismal acceptance rates of 60%). Numbers like that keeps the bulk of the conversation around the second Payment Services Directive laser-focused on the impact that additional friction has on transactions.

What can be done? You might want to consider maximizing the use of PDS2’s SCA available exemptions.

There are several categories of transactions that are exempt from the SCA requirement, and we discussed them in a previous post. These include low-value transactions, certain recurring transactions, transactions with trusted (whitelisted) beneficiaries, and a category called Transaction Risk Analysis (“TRA”). We’ll focus on TRA in this post.

The European Bank defines Transaction Risk analysis as the following:

In the case of real-time transaction risk analysis that categorise a payment transaction as low risk, it is also appropriate to introduce an exemption for the payment service provider that intends not to apply strong customer authentication through the adoption of effective and risk-based requirements which ensure the safety of the payment service user's funds and personal data.

The European Banking Authority has tried to take into consideration the tools that are available to PSPs, acquirers, merchants and other participants in payments processing to avoid high-friction verification for transactions of low risk. Machine Learning tools are quite effective at performing connection analysis on a large volume of data in real-time, so why not put it to use in easing the transaction flow, where possible?

The TRA exemption is interesting for issuers because its availability is dependent upon the issuer’s ability to manage its CNP fraud using measures short of SCA. It’s also interesting for merchants, because the European Bank regulations allow for “outsourcing” of transaction risk analysis monitoring to a given merchant. The European Banking Authority stated that it would

...allow only certain predefined merchants to benefit from that PSP’s exemption (based on a contractually agreed low fraud rate), the fraud rate making a given PSP eligible for an exemption under Article 18 would still need to be calculated on the basis of the payee PSP’s executed or acquired transactions, rather than on the merchant’s transactions.

So TRA is a tool that is available to acquirers and issuers, but it can also be contractually outsourced to merchants and gateways.

The issuer or acquirer needs to meet the following requirements:

• RTS compliant TRA solution
• Fraud reporting capabilities which meet the requirements of your regulators
• A reference fraud rate below the threshold specified by the European Bank regs

Issuers and acquirers (and their merchant and gateway partners) can make use of the TRA exemption for a particular transaction by maintaining an overall quarterly fraud rate within the fraud rates set by the PSD2 regulations. The exemption fraud rates are tiered based on transaction value as set forth in the chart below.

Under PSD2, payment providers in the EU/European Economic Area will need to provide evidence of their transaction fraud rates to their national regulator every 90 days. RFR stands for REFERENCE FRAUD RATE.

• Is the spending/behavior pattern normal?
• Is the payer’s device/software known?
• Is there a hint of malware installation?
• Does the transaction match any known fraud scenarios?
• Is the payer location high risk?
• Is the payer location abnormal?

Nethone has been following the TRA exemption discussion very closely because analyzing the above -- malware installation, fraud scenarios, the user’s location, behaviour analysis, device fingerprinting, network context, etc. -- are tasks that are quite familiar to us, to say the least. We look at these attributes 24/7!

It’s worth noting that TRA applies to EU to EU transactions. While PSD2 requires that stakeholders apply their “best efforts” to transactions where one party is in the EU and one party outside, the regulation will only be strictly enforced when both the issuer and the acquirer are based in the European Union. So there will continue to be a significant number of payment transactions that do not fall under PSD2, even for Europe-based companies and users.

It’s also worth noting that TRA could prove to be the most popular exemption. As was pointed out in an excellent webinar hosted by the Merchant Risk Council, most transactions will qualify for this exemption, it does not rely on any shopper interaction, and there is no limit on the frequency of use.

Since PSD2/SCA went “live” for several countries in the EU/EEA in January, it’ll certainly continue to be a trial-by-error challenge in implementation for the rest of 2021. To learn more about maximizing TRA under PSD2, please feel free to contact us.

• Excellent presentation on TRA by Derek de Weert (Worldpay from FIS) and Natalie Dunne (Paddy Power Betfair): https://www.merchantriskcouncil.org/resource-center/presentations/2020/mrc-virtual/what-you-need-to-know-about-the-transaction-risk-analysis-exemption
• EBA’s regulations pertaining to TRA: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=uriserv:OJ.L_.2018.069.01.0023.01.ENG&toc=OJ:L:2018:069:TOC