Exemptions to SCA

Are merchant-initiated transactions exempt from SCA?

Merchant-initiated transactions are classed as out of scope of SCA requirements, so do not need to be 'exempted'. A merchant-initiated transaction is a payment that is taken on an agreed upon date with the payer’s consent, and, as the name suggests, is initiated by the merchant collecting the payment.

If a transaction is merchant initiated, both fixed and variable payments will be exempt from SCA.

Unlike most transactions initiated by end customers, the payment flows of merchant-initiated transactions are frequently not instant. The end customer’s details are collected at one point in time and submitted to the end customer’s bank at another point in time. As such, the communication between the end customer, bank and payment provider does not happen in real-time. In SCA parlance, this is known as an asynchronous transaction. It would be impractical, and in some cases, impossible for SCA to be applied to these transactions.

However, note that for most merchant-initiated transactions, such as recurring card transactions, SCA will still need to be applied to the first payment if that is done with the involvement of the payer’s PSP (e.g.a card issuer).

Does that include Electronic ‘paperless’ Direct Debit mandates?

One type of merchant-initiated transactions are electronic ‘paperless’ Direct Debits. In order to collect direct debits, a ‘mandate’ must be provided by the end customer from whom payments will be collected, to the merchant/PSP collecting those payments.

There has been a great deal of confusion as to whether SCA is required at the point of setup of the mandate by the payer - specifically, whether the action of setting up the mandate is an “action through a remote channel which may imply a risk of payment fraud or other abuses”.

On 7 June 2019, the EBA confirmed via its Q&A tool that Strong Customer Authentication (‘SCA’) is not required for the set up of electronic ‘paperless’ Direct Debit mandates provided in favour of merchant payees, so long as the end customer’s PSP (e.g. their bank) is not directly involved in that setup.

Specifically, the EBA confirmed:

“Mandates given by the payer to the payee set up without the direct involvement of the payer’s PSP are not subject to SCA.”

SCA exemptions

While merchant-initiated transactions are considered out of scope for SCA, there are a number of other exemptions that may be relevant to your business.

SCA exemptions only apply to payment service providers. They relate to payment transaction amount, risk of the payment, recurrence of the payment transaction and the payment channel used for the execution of the payment. They include:

Fixed recurring transactions and subscriptions

When using a payer-initiated payment method, such as standing orders, only the first payment of a fixed subscription will require SCA. As long as the amount paid stays the same, further transactions will not require SCA.

However, should the amount change, which many usage-based subscriptions do, SCA will be required again for each and every change.

Contactless payments (GBP)

Contactless payments that meet either of the following conditions will be exempt from the application of SCA:

• Individual contactless payments below £100; or

• Cumulative payments totalling less than £300

The exemption is specific to each card used, so for joint accounts, the exemption applies for each card associated with the account.

Transactions below €30

Similar to contactless payments (but with a lower value), payments below €30 will also be exempt from strong customer authentication.

However, SCA will be required if an end customer makes:

• Five or more payments below €30; or

• If a combination of multiple low value payments totals more than €100

These thresholds are not merchant specific, i.e. those five transactions that add up to €100 or more could be payments to different companies.

Trusted beneficiaries (whitelisting)

Customers will have the option to assign well-known businesses to a list of ‘Trusted Beneficiaries’.

This list will be updated and maintained by the ASPSP (Account Servicing Payment Service Provider), who also has authority to remove trusted beneficiaries. A merchant’s PSP may build mechanisms to ‘suggest’ trusted beneficiaries to the ASPSP on behalf of the end customer.

For example, Mastercard hints that as a customer goes through an online checkout flow, at the point of payment setup, there may be a checkbox that requests that the end customer adds the merchant to their ASPSP’s trusted beneficiary list. This request will be passed to the ASPSP, who will then require the end customer to go through SCA in order to approve the trusted beneficiary listing. The end customer will also be able to manage their list of trusted beneficiaries direct with their ASPSP.

Note that ASPSPs do not necessarily need to provide the trusted beneficiary list themselves - they can outsource this, and companies such as Visa are developing products as a result.

If a business is on an end customer’s ‘whitelist’ then SCA will not be required, regardless of the amount, frequency or variation of any purchases.

While an appealing way of potentially navigating SCA, uptake of the process by banks has so far been irregular, and there are still many questions as to exactly how it will work in practice. It is suspected that whitelisting won’t become a viable tactic until well after SCA first comes into force.

It’s important to note that in addition to whenever a trusted beneficiary is added to an exemption list, SCA must be applied if there are changes made to a trusted beneficiary or if removal of a listing is requested by a merchant’s PSP.

3D Secure 2 (version 2.2) will provide whitelisting as an available option to merchants.

Corporate payments

Payments made directly between two corporate companies will be exempt from SCA, but only if the payment method used is a dedicated B2B method e.g. access-controlled corporate travel management or corporate purchasing system.

Article 17 of the RTS lays out that SCA is not required for secure corporate payments as long as the below conditions are met:

• Dedicated payment processes or protocols are used

• The dedicated processes or protocols are only made available to payers who are not consumers;

• National competent authorities are satisfied that dedicated corporate processes and protocols are sufficiently secure.

Low risk transaction exemptions

Assuming SCA would normally apply to a transaction, payment providers will have the authority to evaluate transactions and choose not to apply SCA protocols to those deemed as a ‘low risk’ of fraud.

Payment service providers will be subject to strict thresholds to be granted the ability to evaluate risk rates of transactions in real-time. The payment provider’s fraud rates (as a whole - not just for a specific merchant) must be lower than the following thresholds for the specific payment type being used and value of transaction being processed:

*Fraud Rate must be no greater than these amounts, for the exemption to be applied

Both the payee’s PSP and the end customer’s PSP (e.g. a card issuer) may apply this exemption (based upon their own overall fraud rates for that payment type). However, the ASPSP may decide whether or not to accept the application of that exemption. So, for example, a card acquirer (the merchant’s PSP) may apply the exemption, but the card issuer may overrule that exemption.

In practice, we expect the merchant’s PSP’s request to stand, as liability for any resulting fraudulent payment will rest with the PSP that applied the exemption.

Unattended transport and parking terminals

Payment for transport fares or parking fees at an unattended terminal do not require SCA.

Payment account information

Where an end customer uses a TPP providing account information services to access their payment account data, SCA must be applied where that customer is both:

• Accessing the balance of a payment account for the first time

• Accessing more sensitive information, such as details of all transactions processed on an account for the first time

However, SCA does not then need to be applied:

• Where the account balance is accessed again; or

• Where the historical transaction data is accessed within 90 days of the last application of SCA

Credit Transfers

For transfers made between (for example) a current account to a savings account, where both accounts are held at the same bank, by the same person, SCA does not need to be applied.

Implementing SCA exemptions

These SCA exemptions will be important in minimising (or even eliminating) the friction caused by the additional authorisation process. But how do you go about making sure these exemptions are actually triggered when a customer is making a purchase?

To begin with, it will require PSPs and ASPSPs to work together and to look to utilise common standards e.g. 3DS2.

What if an exemption fails?

While the list of exemptions is now quite clear, the end customer’s bank will ultimately decide whether an exemption is valid. If an exemption is not granted, the payment will trigger a decline code. The payment will need to be resubmitted and authorised using Strong Customer Authentication protocols.