Strong Customer Authentication, or SCA, is a new regulatory requirement for banks, payment service providers and merchants when it comes to taking payments both online and in person. SCA is a European piece of legislation that affects the EU and EEA, and has been implemented by the UK as well.
All merchants taking payments from customers in the EEA and UK need to have SCA in place before starting operations. In order to accept payments and meet the requirements of SCA legislation, merchants or payment providers must add multi-factor authentication measures into their payment processes.
Payment authentication is the process of confirming that a cardholder’s card number or other personal data isn’t being used to make payments without their knowledge. In order to be considered SCA compliant, electronic payments need to be authenticated by customers using at least two of the following three methods:
- Knowledge – this is something that only the customer knows, such as a password or PIN number.
- Possession – this is something that only the customer has, such as their phone/mobile device, a card reader or a device evidenced by using a one-time passcode (OTP)
- Inherence – this is something that only the customer is, and is growing in popularity as an authentication factor. Inherence is arguably the most secure way of authenticating users. Inherence includes biometric authentication, such as with a fingerprint or facial recognition authorisation.
In-person payments have been using this system for many years now with the proliferation of Chip (something the customer has) and PIN (something the customer knows) payments. However, online payments and in-person contactless payments now need to utilise this two-factor authentication as well in order to be SCA compliant.
Why is Strong Customer Authentication needed?
As financial crime is on the rise, governments, banks, payment providers, payment gateways and card merchants are looking increasingly to update and optimise their security policies around online transactions. SCA is just one of many changes that have been put in place in recent years to improve online transaction safety and security, for users, merchants and banks alike.
SCA helps to prevent fraudulent transactions by ensuring that all card payments are being made by real, valid cards and their real, valid users before the payment is authorised and processed.
This means considerably fewer chargebacks and disputes for merchants, resulting in higher success rates for payments and more money in your accounts! SCA also helps to reduce the amount of time and resources that merchants spend on dispute management and admin related to payment chargebacks.
Is SCA required?
Yes, in the EU and EEA, SCA has been required since 31st December 2020, and in the UK SCA has been required since March 31st 2022 (the original deadline of 14th September for UK payments providers was pushed back).
Any service that takes payments from users in the EU, EEA, or the UK needs to be SCA compliant, and any new entrants into the market must also be SCA compliant before being approved by the Financial Conduct Authority. Now SCA has been legally implemented, banks must decline payments that require SCA and don’t meet the required authentication criteria. This means that businesses not working within SCA rules will have the vast majority of their payments declined by banks.
Ready to learn more?
3DS2 & SCA: What’s the difference?
3DS2 (3D Secure 2) and SCA are very closely linked, but they are not exactly the same thing. SCA is the regulation which requires that transactions utilise an extra layer of security, while 3DS2 and its predecessor 3DS are the technologies that can be used to implement this extra layer.
SCA is a legal requirement for all payments made in the UK and EEA, but it does not have to be done through 3DS2. However, 3DS2 is one of the most popular technical standards when it comes to implementing SCA requirements into the payment process, as it offers a high level of protection for users, but also a smooth, frictionless checkout experience.
3DS and 3DS2 have been developed by Visa and MasterCard – other card networks and third parties will have their own SCA-compliant 3D secure transaction tools, but they will generally all perform in a very similar way.
3DS is the predecessor of 3DS2 and will be phased out throughout 2022. 3DS is also SCA-compliant and was a popular option for early adopters of improved authentication and payment security strategies. However, 3DS can be slow, difficult to navigate for users, and often results in higher abandonment rates for merchants. 3DS also doesn’t support payments through smart watches and gaming consoles. 3DS2 aims to negate this by reducing friction for users during the payment process and improving the overall payment experience while continuing to offer a high level of security and SCA compliance.
3DS2 allows merchants to send not just standard payment information, but also contextual information, about a transaction. This gives banks more information to assess when it comes to the risk of transactions. When verifying through 3DS2, information passed on can include:
- Billing address
- Geolocation
- Device ID
- Transaction amount
- Transaction history
3DS2 uses a risk-based authentication system. This means that if there is enough information for banks to be able to confidently assess and confirm the identity of the customer, no other data is needed and the transaction proceeds. If not, the customer is sent through a “challenge payment flow”, where more information and extra steps are required to reduce the risk of fraud. Users will be asked to verify their identity through email, text message, or phone call. If this passes successfully, then the transaction will complete successfully.
Other ways of authenticating transactions under SCA
While 3DS2 is quickly becoming the industry standard under SCA, payment authentication can be carried out using other methods. In line with SCA requirements, at least two of the three factors (knowledge, possession, and inherence) must be met, but this does not have to be done using 3DS2, although this is the preferred method for most merchants.
However, some organisations and sectors will use other verification methods. These may include:
Address Verification Systems (AVS)
When using AVS, the cardholder’s billing address on file with their bank is compared with the information submitted by the user during the payment process – this is a method of knowledge verification.
Most merchants already use this as one step of their verification process when the billing address is entered during checkout alongside the shipping address. When the address information is submitted, the bank will respond back with a full match, partial match or no match. Depending on the bank’s response, merchants can cancel, investigate, or approve the transaction.
Geolocation
International card-non-present (CNP) transactions are generally a higher fraud risk than domestic transactions or card transactions, which is where geolocation can be useful.
Geolocation uses wifi signals to estimate the approximate location of a device. If the card is registered in a different country to the one it is being used in, there is a higher fraud risk and the transaction is more likely to be declined. Cardholders will generally have to make their issuing bank aware if they are going to use their card abroad, although many challenger banks and online banks are able to carry out these checks automatically.
Geolocation doesn’t actually verify user identity, just their location, and the technology can be inaccurate. However, it is a valuable additional safety measure to protect against international fraud in some cases.
Behavioural Analytics
Using behavioural analytics to flag potentially dangerous transactions is a relatively recent option, as the technology required is very new. Data-driven behavioural analytics allow payment processors, card issuers, and issuing banks to flag when a transaction may be fraudulent or unauthorised.
Using data from payment processors and credit card networks, including regular spending habits, browsing behaviour, product preferences, mouse movement & dynamics and more, behavioural analytics systems can make a transaction risk analysis to identify suspicious transactions. This is based on both large group data and individual buyer behaviour.
Card Verification Value (CVV)
CVV is another standard method of authentication for CNP transactions. Like AVS, CVV is required for the vast majority of transactions made using the 16-digit credit or debit card number. CVV authentication is an authentication method that requires possession of a card, so no transactions can be made by anyone other than someone with the physical card.
CVV always needs to be carried out in conjunction with another authentication method in line with SCA, in case the physical card has been lost or stolen.
Payments that may be exempt from SCA
While all payment providers are required to be SCA compliant, there are instances in which they can decide not to apply SCA to a transaction. This can be done in real-time when users are making a payment, and can only be done if both the payment prover and the bank’s overall fraud rates are below a certain threshold. This threshold also gets smaller for larger transactions to prevent bigger payments from being submitted fraudulently. If the payment provider is below the fraud rate threshold but the bank is not, or vice versa, the bank will decline the exemption request from the payment provider and SCA will still be required.
Some of the most common SCA payment exemptions include:
Low-value payments
After a range of raises at the start of the COVID-19 pandemic to encourage increased use of contactless for low-risk payments, the limit for a single contactless transaction to require SCA is £100. This means that when using contactless, SCA won’t be required for payments less than this as standard. This doesn’t apply to online transactions or transactions made with Apple Pay, Android Pay and Google pay.
If a user carries out five or more transactions under £100 using contactless, or the cumulative cost of any payments reaches £300 or more, then SCA requirements will be triggered. This is to prevent fraud, as anyone using a lost or stolen card will not be able to pass through SCA.
If you’re using your phone to pay with contactless, this threshold doesn’t apply, as simply by paying with a mobile device you’re already offering another kind of authentication. Your bank is also required to keep track of SCA exemption requests and when they have been granted, so they can flag any suspicious or potentially dangerous payments.
Fixed-amount subscriptions
This is an exemption that can be applied when customers make recurring payments from the same account to the same business, and for the same amount. If your customers are making regular payments from a credit or debit card using a manual or automatic subscription-based model, there is a higher likelihood that these payments will be SCA exempt, saving your customers from going through SCA every time.
SCA will be required for the first payment, and often the second or third payment too. However, once the pattern is picked up by payment providers and customers’ banks, the payments are likely to become SCA exempt the majority of the time.
At Acquired, we offer support for automated recurring payments and can liaise with Mastercard Automatic Billing Updater and Visa Account Updater services to update card details for recurring payments, as well as provide additional information to increase the acceptance rate for recurring payments on behalf of our customers.
Merchant-initiated transactions and off-session payments
Payments that have been made using saved payment methods that the customer doesn’t manually authorise can be SCA exempt, as they are considered merchant-initiated transactions, rather than user-triggered payments. Technically merchant-initiated transactions are not covered by the scope of SCA legislations. However, they can sometimes be picked up for SCA by banks depending on the kind of activity logged in the user’s account previously. Most banks will log these transactions as merchant-initiated, at which point it goes through a very similar process to requesting an SCA exemption. While technically not required, banks will have the final say on whether a merchant-initiated payment requires additional authentication measures.
Merchant-initiated payments are an important payment method for business models that charge varying amounts for subscription services, add-ons, or rely on delayed payments, as all of these will not be classified as fixed-amount subscriptions.
Trusted beneficiaries/whitelisted merchants
Under SCA, customers have the option to whitelist merchants that they deem to be trustworthy, which then means that after the first authentication is completed, subsequent payments to the merchant will not likely need to be re-authenticated. Customers can request to have trusted merchants added to their record, however, this is never a guarantee. The option to require additional authentication always lies with banks and issuers which means that if a customer, merchant, or transaction is thought to be at higher risk for fraud, then the exemption request will be rejected and SCA will be required.
Secured corporate payment exemption
In cases where a legal person (e.g. a company) initiates the transaction rather than a consumer, and the transaction is processed through a secure, dedicated payment protocol, the Commission is satisfied that no separate authentication is necessary. In this context, virtual cards and B2B cards should be included as secure virtual payments.
