What Is Strong Customer Authentication under PSD2?

SCA stands for Strong Customer Authentication, and it is one of the regulations under the Revised Payment Service Directive (PSD2). It states that a customer must verify their identity before payment information can be exchanged between a financial institution and a third-party provider (TPP).

According to the SCA regulation, the customer must verify their identity through two of the following conditions:

• Knowledge: Something they “know,” like a password or PIN

• Possession: Something they “own,” like a phone or smart card

• Inherence: Something they “are,” referring to biometrics like fingerprint or facial recognition

The two factors must be chosen from different categories, so the breach of one does not compromise the validity of the other. For example, if someone steals a customer’s phone, they will not be able to access any payment information without biometrics or a passcode. This method of verification was introduced to keep sensitive customer data secure and private.

Characteristics of the SCA regulation

SCA affects “two-leg transactions” within the EU or the European Economic Area (EEA). A two-leg transaction refers to one where the customer’s bank and the merchant’s bank are located in Europe. A small fraction of European banks must also apply SCA for “one leg out transactions,” where the customer is in Europe and the merchant is outside Europe.

A successful authentication using SCA should generate an authorization code that allows customers to make secure payments online. If two of the valid authentication categories are not fulfilled, the payment will not go through.

Dynamic linking

Remote payment transactions are the ones that are initiated over the internet. To futher secure them, SCA requires “dynamic linking” where TPPs link each transaction to the specified payment value and recipient. This is done through an authorization code or token generated by the TPP for the consumer. If changes are made to the recipient or the final amount due, the authorization code will be invalidated and a new one will be necessary to complete the transaction.

For example, if a customer is buying groceries online, the amount due for the items in their cart, including all taxes and fees, must be transparent. The consumer also needs to know which grocery store they are paying this money to. Once they have given this information, they can authorize the transaction with a code. If a change is made, the TPP will not be able to process the transaction without issuing another authorization code.

Ideally, every online transaction will have both SCA and this dynamic link to protect consumer data and prevent fraudulent charges.

SCA with 3D Secure 2.0

3D Secure (3DS) is the most common method for authenticating an online card payment, and many European cards support it.

3DS adds an extra step after the payment checkout where the customer’s bank asks the cardholder to provide extra information to complete the payment. For example, the bank requests its customer to enter a one-time password (OTP) that is sent to their mobile device to complete the payment through the banking app.

3D Secure 2.0 is the updated version introduced in 2019, and it complies to the new SCA requirements.

This new version provides a better customer experience because it doesn’t rely solely on OTPs for customer authentication but instead allows multiple SCA options, including biometrics. It even supports all payment methods—in-app, mobile, and digital wallets.

SCA in payment flow

Let’s see how SCA is implemented in a payment flow to create an ideal transaction.

There are three main phases involved in the SCA payment cycle: payment initiation and consent, authentication and authorisation, and payment execution.

 Let us assume that a customer buys online and wants to pay the merchant through direct bank transfer.

Payment initiation:

• The customer requests to use a payment initiation service provider (PISP) from the payments page of the online shopping website.

• The merchant or the online shopping website accepts the request and sends the payment details to the customer.

• The customer provides consent to the online shopping website to initiate payment through the PISP for the materials in the cart.

• The shopping website sends the payments details and the customer consent to a PISP.

• The PISP authenticates a payment setup to the customer’s bank.

• The bank confirms and directs the payment back to the PISP.

Authentication and authorisation:

• The PISP after receiving the confirmation, redirects the consumer’s browser to the bank website.

• Following this, the customer authenticates the payment with their bank using SCA.

• The bank then sends the payment details to the customer and prompts them to select the account from which the payment will be made.

• The bank then sends a confirmation to the customer’s browser in the form of an authorisation token.

Payment execution:

• Once the customer authorises the payment, the PISP completes the shopping process by verifying the SCA on behalf of the customer.

• PISP then uses an application programming interface (API) to send a request that the bank initiate a bank transfer. PISP also sends the confirmation token from the previous step as reference.

• Once the bank validates the token and matches the request from PISP, it initiates the funds transfer from the customer’s account to the PISP’s account.

• The PISP then credits the merchant bank with the desired payment.

Exemptions to SCA

There are several instances under PSD2 where a customer can be exempted from going through SCA. This extra authentication step may be lengthy and can cause customers to stop buying from certain businesses. Here’s where exemptions come into play to help some businesses retain their customers.

Payment service providers can request for these exemptions when they process customer transactions. Once the request is sent to the customer’s bank, it will assess the risks involved in the transaction and decide whether to approve the exemption or keep the authentication process.

The following are SCA exempt:

1. Remote low-risk transactions: As a part of PSD2, a payment provider can check the fraud rates of a customer’s bank and payment provider’s bank to decide whether to apply SCA to a transaction. The banks are expected to stay within exemption threshold values to avoid the extra step.

2. Low value transactions: If the transaction value is below €30, then it will be exempted from SCA. However, there are certain conditions. Banks will request authentication from the customer when:

• The exemption has been used by the card holder for five times since their last SCA authentication

• The total of previously exempted payments is more than €100

3. Recurring payments: SCA on fixed subscription payments can be avoided. For the initial transaction, the customer may be asked to verify their credentials using SCA. SCA can then be exempted for the following consecutive payments. 

4. Transactions initiated by merchant banks: Customers sometimes make transactions using saved cards. In such cases, these payments are voluntarily initiated by the merchant banks. The transactions which come under this category are exempted from SCA. To use merchant-initiated transactions, the customer must verify the card at least once while saving the card or while making their first payment. 

5. Whitelisted businesses: While making payments, the customers may have an option to whitelist trusted businesses to avoid the authentication step while making future purchases. In such cases, SCA can be skipped. 

6. Corporate payments: SCA exemption holds true for payments made via lodged cards. For example, an online travel agent using a corporate card to manage employee travel expenses will be SCA exempt. SCA can also be avoided when payments are made using virtual card numbers.

Conclusion

The introduction of SCA and PSD2 as a whole will change the European banking sector. It will secure transactions for customers who are a part of the EEA. 3DS 2.0 will streamline SCA processes by automatically incorporating the compliance standards and exemptions to provide a frictionless banking experience.