In plain words
Think of a cash machine. To take money out you need your card, which you have, and your PIN, which you know. Either one on its own is not enough. Strong Customer Authentication (SCA) brings the same idea to online banking and payments: prove it is you with two different kinds of proof.
The three kinds are something you know (a password or PIN), something you have (your phone or a card), and something you are (a fingerprint or your face). SCA needs at least two, from different categories, and they must be independent, so that stealing one does not reveal the other. 1
SCA became a legal requirement across the EU and the UK under the Second Payment Services Directive, PSD2. Detailed technical standards, known as the RTS, set out how it must work and when firms can skip it. 2
How it works
How SCA works for a payment
A few taps for the customer. A specific approval behind it.
-
1
You start a payment
You send £250 to a new payee in your banking app, or pay online with your card.
-
2
The provider checks for an exemption
If the payment qualifies for one and the risk is low, it may go through without a challenge.
-
3
You approve with two factors
For example your phone plus your fingerprint. The approval is tied to this amount and this payee, so it cannot be reused for another payment.
-
4
The payment goes
The provider records how you were authenticated, which matters later if the payment is disputed.
Tying the approval to the amount and the payee is called dynamic linking. It means a criminal who intercepts a code cannot use it to send a different amount to a different account. 2
The three factors
| Category | Examples | Weak spot |
|---|---|---|
| Knowledge: something you know | Password, PIN, passcode | Can be phished or guessed |
| Possession: something you have | Registered phone, banking app, card reader, hardware key | Can be lost, stolen or, for SMS, intercepted |
| Inherence: something you are | Fingerprint, face recognition | Depends on the device’s sensor |
Two factors from the same category do not count. A password and a memorable word are both knowledge, so together they are still one factor.
When SCA applies, and the exemptions
SCA is required when a customer accesses their payment account online, starts an electronic payment, or does anything remotely that could carry a risk of fraud. 1 The rules then allow exemptions, so that customers are not challenged on every small or low-risk payment. 2
Main exemptions
- Low-value payments, within set limits
- Payees the customer has marked as trusted
- Recurring payments of the same amount to the same payee
- Low-risk payments, based on transaction risk analysis (TRA)
- Transfers between the customer’s own accounts at the same provider
What exemptions do not mean
- That the provider must skip SCA
- That the limits never reset: repeated small payments add up
- That any provider can use TRA: it depends on its fraud rates
- That the customer carries the loss if an exempt payment was fraud
Each exemption has detailed conditions. The provider that authenticates the customer, usually the bank or card issuer, decides whether to apply one. For online card payments, SCA is usually carried out through 3-D Secure.
What SCA means for your product
If you issue accounts or cards, or run a wallet that customers log in to, SCA is part of your product, not just your provider’s. A few design decisions matter most:
- Device binding. How a phone becomes a trusted possession factor, and how a customer moves to a new phone without opening a door for fraudsters.
- Recovery. What happens when the customer loses their phone, forgets their PIN or their fingerprint stops working. Recovery is often the weakest point.
- Card payments. For online card payments, SCA usually runs through the card issuer’s 3-D Secure service. Your app may host the approval screen.
- Exemption logic. Who decides when to skip SCA, using which data, and how that decision is logged.
- Records. Which factors were used, on which device, for which action. Disputes and regulators will ask.
For how consent and authentication records should be designed, read PSD2 consent flows that survive scrutiny.
SCA in the UK, EU and Gulf
| Market | Rules | What to know |
|---|---|---|
| European Union | PSD2 and the SCA RTS 1 2 | The proposed PSD3 and Payment Services Regulation would update the rules |
| United Kingdom | Payment Services Regulations 2017 and the FCA’s own version of the RTS 3 | Kept after Brexit, but the UK and EU have since made different changes, for example to open banking re-authentication |
| UAE and Saudi Arabia | Central bank rules on authentication and cyber security, such as the SAMA Cyber Security Framework | No PSD2, but multi-factor authentication for digital banking and payments is expected. Check the local wording, as exemptions differ |
Example: Leo pays a new supplier
Leo runs a small design agency and banks with a business account app.
- Log-in. He opens the app with his face. His phone is registered to the account, so the app has two factors: the device and his face.
- New payee. He sends £1,800 to a new printing supplier. The app shows the amount and the payee and asks him to confirm with his fingerprint.
- Trusted payee. He marks the supplier as trusted. Next month’s smaller invoice may go through without another challenge, at the provider’s choice.
- Coffee. He taps his card for a coffee. It is a low-value contactless payment, so he is not asked for a PIN, until enough small payments have added up.
Common misconceptions
“A password and a security question are two factors.”
Both are things you know, so they count as one. SCA needs two different categories.
“SCA stops all fraud.”
It stops someone using stolen details. It does not stop a customer being tricked into approving a payment themselves, which is why APP fraud rules exist.
“Exemptions are a loophole to avoid friction.”
They are part of the rules and come with conditions and monitoring. A provider whose fraud rates rise too high must stop using the risk-analysis exemption.
FAQ
What is Strong Customer Authentication?
Strong Customer Authentication, or SCA, is a rule that payment providers must check a customer's identity using at least two independent factors from different categories: something they know, something they have and something they are. It applies when customers log in to their account online and when they make most electronic payments.
When is SCA required?
Under PSD2 and the UK rules, SCA is required when a customer accesses their payment account online, starts an electronic payment, or does anything remotely that could carry a risk of fraud, unless an exemption applies.
Is an SMS code enough for SCA?
An SMS one-time code can count as a possession factor, because it proves you have the phone. It still has to be combined with a second factor from another category, such as a PIN or a fingerprint. Many providers now prefer approval inside an app, which is harder to intercept.
What are the SCA exemptions?
The main ones cover low-value payments, payments to beneficiaries the customer has marked as trusted, recurring payments of the same amount, and remote payments a provider judges low risk through transaction risk analysis. Each comes with conditions, and the provider can always choose to apply SCA anyway.
What is the difference between SCA and 3-D Secure?
SCA is the legal requirement. 3-D Secure is the card industry's technical protocol that card issuers use to carry out SCA for online card payments.
Does SCA apply outside Europe?
SCA as a legal term comes from the EU's PSD2 and the UK's version of it. Other regulators, including in the Gulf, have their own rules on strong authentication for digital banking, but they are not the same rulebook.
Sources
-
1
EL
EUR-Lex Directive (EU) 2015/2366 on payment services in the internal market (PSD2)
https://eur-lex.europa.eu/eli/dir/2015/2366/oj -
2
EL
EUR-Lex Commission Delegated Regulation (EU) 2018/389 on strong customer authentication and secure communication
https://eur-lex.europa.eu/eli/reg_del/2018/389/oj -
3
LG
legislation.gov.uk The Payment Services Regulations 2017
https://www.legislation.gov.uk/uksi/2017/752/contents
