Introduction

The European regulation about Payment Services is going to be changed with the PSD2.

One of the new PSD2 rules impacting most on trade is the SCA requirement (Strong Customer Authentication, or reinforced authentication), demanding the authentication of all European e-commerce transactions, to be henceforth processed as 3DSecure.

Its effective date is on 14th September 2019, but according to the Bank of Spain, Spanish payment systems will not apply the SCA on that date. The effective date is pending, and it is expected to be on December 30, 2020.

The SCA will mainly affect the authentication of purchasers, requiring that all European e-commerce transactions be authenticated with 2 of the 3 following factors:





  1. Exemptions
  2. Exceptions

To comply with the new regulations, the card issuing banks are adapting protocols so that their users know and have the double factor available.

The SCA will apply to all payment environments (e-commerce, face-to-face payments, tokenization, transfers, etc.) of any payment system (bank cards, financial accounts, X-Pay and other alternative payment platforms, etc.) carried out within the European Economic Area.

Given the enormous breadth of the types of trade and companies that receive payment, the Regulator has further defined the scope of action, along with certain exemptions from and exceptions to SCA application:

Exemptions

  • Payments made with cards issued outside the European Economic Area. The United Kingdom has accepted the SCA standard.
  • Operations in which the payment has been initiated by phone, mail, or e-mail.
  • Payments made via Anonymous Prepaid Cards.
  • MITs (Merchant Initiated Transactions): may be used in transactions initiated only by the merchant (the payer is “absent” at the time of payment), provided that an agreement pre-exists between the merchant and buyer. SCA authentication is required for the initial payment on the first purchase.

    MITs can be considered repetitive payments, initiated by an enterprise in ‘batch’-type processes and those in which the amount is variable, in digital subscriptions of un-fixed amount (e.g., use of a card in the payment of SEM campaigns), or in extra charges, such as in the rental of vehicles, etc.

Exceptions

Unlike exemptions, exceptions can be sent only by way of a Secure Purchase (3DSecure) channel. Faced with this option, the recipient (the issuer of the payment) can accept, deny, or require the authentication of a client before responding.

  • Transactions ≤ € 30.

    However, within this exception, the issuing entity is also regulated and will only accept a client without authentication if, since the most recent authentication, the cumulative amount exempted in previous purchases is ≤ € 100, or the number of exempted transactions is ≤ 5.

  • Recurring transactions.

    Periodic operations of the same amount, payment system, periodicity, and beneficiary. Authentication required in the first transaction. For recurring operations initiated before the date to be defined by Banco de España, the Regulator has allowed authentication not to be applied on the first subscription payment.

  • Exception for TRA (Transaction Risk Analysis)

    Transactions with an obvious low risk of fraud can be sent under the TRA exemption, so long as the overall fraud ratio of the Payment Entity processing the payment (the bank or platform owning the Virtual POS) is delimited and verified by the Regulator.

    The amounts of operations covered by this exception must adjust according to the global fraud level of the Payment Entity:

    • Operations < € 500 if ratio < 0.01%
    • Operations < € 250 if ratio < 0.06%
    • Operations < € 100 if ratio < 0.13%

    It must be taken into account that, to date, the Regulator has not published a specific protocol or indicated a channel by which a Payment Entity (e.g., PAYCOMET) may adhere to this exception.

  • Beneficiary whitelist

    This is the only exception that cannot be requested by the merchant. It affects only entities that issue payment systems and that have enabled protocols by which customers have identified “trusted merchants” and authorized them not to apply authentication when purchasing from them.