Strong Customer Authentication (SCA)- Your Security BFF
Ever heard of the three musketeers of payment security?
· Something they know!
· Something they own!
· Something they are!
Well, that’s none other than the requirements of the Strong Customer Authentication (SCA)!
Let’s know more about the rockstar of online and contactless offline payments in Europe!
SCA — The Essential Information
Strong Customer Authentication (SCA) is a regulatory mandate by the European Union (EU) to enhance the security of online and contactless offline payments by mitigating fraud risks in Europe. This regulatory requirement was introduced under the Payment Services Directive (PSD2) and it applies to both the payment service provider of the business and the bank/ card provider of the payer operating within the European Economic Area (EEA).
In other words, European shoppers are required to undergo additional layers of authentication when making payments.
Even though the SCA requirements were officially introduced in September 2019, the implementation deadline was extended until December 31, 2020, due to industry readiness concerns.
To comply with SCA and facilitate secure transactions, additional authentication steps are necessary during the checkout process. Consequently, banks were also required to conduct supplementary verification checks to confirm customer's identity.
The authentication process entails customers providing two out of the following three elements:
- Something they know (Eg: Password, PIN, Secret fact, etc)
- Something they own (Eg: Cell phone, Wearable devices, Smart card, etc)
- Something they are (Eg: Fingerprint, Facial features, Voice pattern, etc)
Examples of SCA:
SCA opens avenues for diverse authentication methods beyond the ‘something they know’ approach. For instance:
- Facial recognition or fingerprint verification (something they are) coupled with their smartphone (something they own).
- A code transmitted to their smartphone (something they own) alongside their personal password (something they know).
An additional example of SCA involves combining a fingerprint or a one-time authentication code sent to a smartphone with the account login.
When is SCA Mandatory?
SCA is mandatory in the following scenarios:
- Accessing a payment account online.
- Initiating an electronic payment transaction.
- Performing any action through a remote channel that poses a risk of payment fraud or abuse.
The primary impact of SCA is predominantly on card payments and bank transfers due to their instant nature and initiation by end-customers, introducing a potential risk that SCA helps mitigate.
Applicability and Key Features:
The PSD2 SCA regulations pertain to banks rather than merchants. Banks that approve transactions that do not adhere to the compliance standards set forth are in breach of the laws governing their respective home countries.
Key Features
· A successful SCA authentication should result in the generation of an authorization code, enabling customers to make secure online payments. If two valid authentication categories are not met, the payment will be declined.
· SCA specifically impacts “two-leg transactions” (refers to transactions where both the customer’s bank and the merchant’s bank are situated in Europe within the EU or the EEA).
· Additionally, a subset of European banks must adhere to SCA for “one leg out transactions” (denoting transactions where the customer is in Europe, and the merchant is located outside of Europe)
SCA in Payment Flow — The Real-Time Scenario
SCA is integrated into the payment flow, comprising three key phases:
- Payment initiation and consent,
- Authentication and authorization, and
- Payment execution.
Let’s illustrate this process with the example of a customer making an online purchase!
Payment Initiation and Consent:
Sarah, an online shopper, adds a laptop to her cart and proceeds to check out in an e-commerce website. ,
- Upon selecting the option for direct bank transfer, Sarah selects a trusted Payment Initiation Service Provider (PISP) from the list provided by the website.
- Based on the choice chosen, the e-commerce platform, acting as the merchant, shares the payment details, including the purchase amount and recipient, with Sarah.
- Sarah consents to the transaction by authorizing the PISP to initiate the payment for the laptop in her cart.
- The e-commerce platform sends the payment details and Sarah’s consent to the chosen PISP.
Authentication and Authorization:
The PISP takes charge of authenticating the payment setup with Sarah’s bank and ensuring a secure transaction.
- Upon receiving confirmation, the PISP redirects Saraha’s browser to the bank’s website.
- Subsequently, she undergoes payment authentication with her bank using SCA.
- The bank proceeds to transmit payment details to Sarah.
- Finally, the bank issues a confirmation to Saraha’s browser in the form of an authorization token.
Payment Execution:
With authentication completion, the PISP proceeds to execute the payment, ensuring a seamless and secure transfer of funds.
- The PISP, armed with the authorization token, redirects Sarah’s browser to its interface.
- Sarah’s final approval triggers the PISP to use an Application Programming Interface (API) to send a request to her bank, initiating a bank transfer for the laptop purchase.
- Sarah’s bank, upon validating the token and matching the request, transfers the funds from her account to the PISP’s account.
- The PISP, having received the funds, credits the merchant’s bank with the approved payment for the laptop.
This real-time scenario demonstrates the integral role of SCA in ensuring a secure, authenticated, and successful payment transaction from initiation to execution.
Dynamic Linking
Dynamic linking is like a secret code for each purchase, ensuring it’s you and what you agreed to.
Remote payment transactions, initiated over the internet, are fortified by SCA through ‘dynamic linking’. Here, the Third-Party Providers (TPPs) connect each transaction to the specified payment value and recipient using an authorization code or token generated for the customer. If alterations occur in the recipient or the final amount, the authorization code becomes invalid, necessitating a new one for transaction completion.
For instance, when a customer buys groceries online, the total amount, including taxes and fees, must be transparent, and the customer must identify the specific grocery store. Authorization is then granted with a code, which becomes obsolete if any changes are made, requiring the issuance of a new authorization code.
Ideally, every online transaction should incorporate both SCA and dynamic linking, providing an additional layer of authentication beyond mandated guidelines, safeguarding customer data, and thwarting fraudulent charges.
Exemptions to SCA
We saw that SCA is required for online and contactless offline payments in EEA. However, there are some transactions exempt from SCA or out of the PSD2 SCA scope. While SCA enhances payment security, it can also add friction to the payment process. To address this, certain types of transactions are exempt from SCA requirements.
Remote Low-Risk Transactions
Low-risk transactions are considered to have a lower probability of fraud and may be exempted from SCA. These transactions typically involve small amounts or merchants with a proven track record of security.
Example: A customer makes a €10 payment for a digital subscription using their saved card details.
Low-Value Transactions
Transactions below a certain threshold, typically €30, are exempt from SCA. This exemption aims to balance security with convenience for low-value purchases.
Example: A customer purchases a coffee for €2.50 using contactless payment.
Recurring Payments
Recurring payments, where the customer has previously authorized the merchant to collect payments regularly, are exempt from SCA for subsequent payments. This exemption reduces friction for repeat purchases.
Example: A customer’s monthly gym membership fee of €50 is automatically deducted from their account.
Transactions Initiated by Merchant Banks
Transactions initiated by merchant banks, such as direct debits or card-on-file payments, are exempt from SCA. This is because the merchant has already obtained the customer’s consent for these transactions.
Example: A customer’s utility bill is paid automatically through a direct debit arrangement with the utility provider.
Whitelisted Businesses
Merchants with a proven history of security and low fraud rates may be whitelisted by the customer’s bank, exempting SCA for transactions at those merchants. This exemption is based on trust and risk assessment.
Example: A customer makes a purchase from a well-established online retailer with a strong reputation for security.
Corporate Payments
Corporate payments, where both the payer and the payee are businesses, are exempt from SCA. This is because corporate transactions are typically subject to additional controls and risk mitigation measures.
Example: A company pays an invoice to another company using a bank-to-bank transfer.
These exemptions aim to balance security with convenience, ensuring that SCA is applied effectively while minimizing friction for low-risk transactions.
Conclusion:
In a nutshell, navigating the landscape of online transactions and security measures is crucial in today’s digital age. SCA stands as a formidable shield against unauthorized access and fraudulent activities, ensuring a safer and more trustworthy online experience for both merchants and customers alike.
As we bid adieu to the exploration of SCA, the journey doesn’t end here!
Brace yourselves for our next blog, where we unravel the intricacies of 3 Domain Secure (3DS), a powerful ally in the realm of online security.
