When looking at SCA compliance requirements in Europe, there is one viewpoint that gets the most attention. That is the regulatory “top-down” viewpoint, where the EU, through the European Banking Authority (EBA) and the National Competent Authorities (NCAs), issue requirements for anyone making payments.

A couple of months ago, the EBA issued their opinion on the matter of banks and PSPs who haven't implemented compliant SCA, stating that NCAs should take supervisory actions to ensure Account Servicing Payment Service Providers (ASPSP) are compliant. The due date? No later than April 30th, 2021.

But what does this mean exactly? Essentially, any national organisation that regulates banking in their country - such as the FCA in the UK or BaFin in Germany - should start issuing instructions/warnings to their banks and issuers regarding the SCA requirements.

Suppose the deadlines given in these instructions are not met. In that case, the EBA expects NCAs to use whatever supervisory methods necessary to ensure lawful compliance. Such methods include but are not limited to: “the revocation of the exemptions from the contingency mechanism under Article 33(6) of the RTS on SCA&CSC already granted to ASPSPs and/or the imposition of fines”.

If you’re a regulated entity, such as a bank or an issuer, your compliance officer has probably already clarified the importance of following this kind of regulation. If you choose not to, and your local authority comes knocking on your door, it may mean that your company has to shut down.

However, there is a second viewpoint regarding SCA compliance in Europe. This is the “bottom-up” viewpoint, which deals with the changes in consumer protection rights that come with the PSD2. The purpose of these rights is to make “safe payment solutions where risks are monitored and mitigated effectively.” 

One change regards a liability shift, defined in Article 74 of the PSD2. It states: 

“Where the payer’s payment service provider does not require strong customer authentication, the payer shall not bear any financial losses unless the payer has acted fraudulently. Where the payee or the payment service provider of the payee fails to accept strong customer authentication, it shall refund the financial damage caused to the payer’s payment service provider.”

This means that the burden of proof for fraud now rests on the PSP side, and that any non-compliant PSP must refund any fraudulent claim by the user with no questions asked. Of course, the PSD2 foresees payers claiming complete reimbursements from their PSPs when the lack of SCA measures leads to unauthorised payments, as well as if the payer did not act fraudulently.

Before the PSD2, it was customary for banks to tell their customers claiming to be victims of fraud that it was their own fault, and that the bank would not be responsible for reimbursing the loss. This changes with the PSD2, and the customer authentication aspect is central to how this change works. Without a sufficiently strong SCA for payments, the PSPs’ legal security net becomes much weaker than before.

So, what are you as a payment provider to do? The first point of action is to make sure that there is a compliant SCA solution in place. The second is to make sure that the SCA solution you provide also has traceability, as required by Article 29 of the RTS on SCA.

If there are any questions around potential fraud, the PSP has to prove that the payer’s claim is fraudulent. This can only be done by putting into place an SCA solution that, besides follows PSD2 SCA requirements, also allows for previous transaction authorisations to be properly inspected.

Stayed tuned for the third and final post in this series, where we’ll look more closely at how to prove SCA compliance, at our own process towards compliance, and at how the Okay platform can help.

————————————

This is part 2 of 3 of a series on PSD2 RTS SCA Compliance. Part 1 of the series focuses on compliance, while Part 3 focuses on how Okay can help you meet compliance standards.