Everyone is still picking over the new PSD2 RTS on strong customer authentication (SCA) from the EBA but the major talking point is around the introduction of an exemption on risk based transaction analysis. One of the major criticisms of the previous RTS was that it would force up to 70% of online transactions through SCA, introduce friction into the payment process and impact overall economic activity.
The new exemption allows banks to avoid the full friction-filled horror of two factor authentication on payments if they can keep fraud levels below certain designated limits. Note, however, that there’s no equivalent exemption for any of the non-payment use cases, and it’s not clear how edge cases such as e-mandates for direct debits will be treated.
The definition of “fraud” is interesting as well – it’s the total value of unauthorised or fraudulent transactions divided by the total value of all remote transactions over that channel. So potentially you could have a lot of small, fraudulent transactions and still meet the exemption: and the exemption for low value payments has been lifted from €10 to €30, and transit transactions are completely exempt.
The fraud limits are different for card-based payments and credit transfer (or PSD2 push payments, if you’d prefer) and are tiered by transaction value – so the lower the fraud rate the higher the transaction value permitted using risk based transaction analysis. The catch is that if these fraud rates are exceeded for two consecutive quarters then the PSP concerned loses the right to the exemption and needs to fall back to full two factor SCA.
Now that, of course, would be a disaster for the institution concerned – if you’re the only bank that has to make your customers apply SCA for online transactions then you’ll rapidly see them migrating to other banks. So the penalty for losing this exemption is likely to be severe.
The EBA has helpfully supplied a minimum list of things that PSPs have to do in order to meet the requirements for risk based transaction analysis (I quote from the RTS):
- no abnormal spending or behavioural pattern of the payer has been identified;
- no unusual information about the payer’s device/software access has been identified;
- no malware infection in any session of the authentication procedure has been identified;
- no known fraud scenario in the provision of payment services has been identified;
- the location of the payer is not abnormal;
- the location of the payee is not identified as high risk.
No doubt risk teams are currently looking at their current solutions and trying to figure out whether they’re compliant or not. Which we’re quite pleased about, as this type of analysis is a core part of our business.
And all of this will need to be audited, which will be a nice new earnings stream for audit firms. Quite how the compliance regime for this will work will no doubt emerge over the next eighteen months or so.
There are lots of other interesting features in the new RTS. It’s clarified, for instance, that SCA can be performed by either the payer’s PSP or the payee’s PSP but not by the merchant. So presumably large on-line retailers will be gearing up to become PSPs themselves. Also PSD2 is now only mandatory for transactions that start and finish in the EEA.
Oh, and, apparently, card-on-file transactions are outside of the scope of PSD2. Which is interesting, if a bit head-scratching.
We’ll be analysing this further and updating over the next few weeks. So either follow us here on Tomorrow’s Transactions or get yourself added to our mailing list. Or come and join us to discuss PSD2 and other issues in the future of digital transactions at the annual Tomorrow’s Transactions London Conference.
You say ‘it’s not clear how edge cases such as electronic direct debit initiation will be treated’. Well, the EBA’s analysis of Comment #80 says ‘With regards to direct debits, the EBA notes that they are out of the scope of the RTS as they are initiated by the payee.’ Seems pretty clear to me!
Hi Tom. Fair point – I actually meant an e-mandate for the direct debit rather than the initiation of each individual payment as noted in Comment #272. I’ll edit the article to clarify. Thanks! Tim
Hi Tom, thank you. You write “It’s clarified, for instance, that SCA can be performed by either the payer’s PSP or the payee’s PSP but not by the merchant.” but how can a PSP perform SCA when the authentication token is generated and verified by the ASPSP? I think you mean “trigger” here instead of “perform”.
Well, I was trying to provoke a reaction … but I can’t see anywhere that SCA is mandated on the ASPSP. It says the other PSPs may rely on the ASPSP’s SCA, but that’s not the same as saying they must.
If an intermediary PSP performed SCA – because, perhaps they had a direct relationship with the PSU (a merchant app maybe) I can’t see why that would be an issue in terms of authentication code, but presumably there’d need to be a contractual relationship with the ASPSP to allow this.
Or something? I’d be really interested in other opinions on this point.