What is SCA? SCA regulation requires the payer to confirm their identity using at least two independent factors before a payment goes through. That’s it- no single password, no card number alone. SCA payment regulation applies across most UK card and bank payments today, and it directly affects checkout conversion, which is why product and compliance teams both need to understand it, not just legal.
This guide covers the three authentication factors, what triggers SCA regulation, the exemption categories, and why open banking payments meet it natively. For product and compliance teams at platforms, payment providers, and SaaS companies handling UK transactions, that last point matters most: knowing where SCA regulation adds friction and where it doesn’t.
Key Takeaways
- SCA regulation requires a payer to confirm their identity with at least two independent factors before a payment is authorised.
- The three factor categories are knowledge, possession and inherence. Most payments need two of the three.
- Exemptions exist for categories like low-value payments, recurring payments and trusted beneficiaries, but exact thresholds should always be checked against current FCA material, not assumed from older sources.
- Open banking payments satisfy SCA natively, since the payer authorises directly in their own banking app.
- Finexer’s payment initiation uses that same native bank authorisation, so SCA is completed in-app rather than bolted on as a separate step.
What Is SCA Regulation?
SCA authentication means proving who you are with two out of three possible factor types, not one. A password alone used to be enough online. SCA regulation changed that by requiring a second, independent factor from a different category.
What Are the Three SCA Factor Categories?
Understanding what is SCA at the mechanical level means understanding these three categories. Every method of SCA authentication falls into one of them:
| Category | What It Means | UK Example |
|---|---|---|
| Knowledge | Something the payer knows | A PIN or password |
| Possession | Something the payer has | A phone, card reader, or the banking app itself |
| Inherence | Something the payer is | Fingerprint or facial recognition |
A payment needs two factors from two different categories. A PIN plus a fingerprint satisfies strong customer authentication. A password plus a security question does not, because both come from the knowledge category.
When Does SCA Payment Regulation Apply
Part of understanding what is SCA in practice is knowing where it doesn’t apply. SCA payment regulation applies to most online card payments and bank-initiated payments where the payer is actively involved. It generally doesn’t apply where the payment is merchant-initiated, meaning the customer isn’t present to authenticate at that moment.
What are the SCA exemptions?
SCA exemptions exist across several recognised categories, without needing exact figures to understand how they work. These SCA exemptions are categories, not guarantees; a bank can still request full authentication even where a category applies:
- Low-value payments. Smaller transactions can sometimes skip full authentication, subject to limits set by the payer’s bank.
- Recurring payments. After the first payment in a series is authenticated, later ones in the same series may be exempt.
- Trusted beneficiary. A payer can mark a business as trusted through their bank, reducing repeat authentication for future payments to that business.
- Merchant-initiated transaction. A merchant-initiated transaction, such as a stored-card charge with no customer present, generally falls outside standard SCA scope, provided the original mandate was authenticated.
Specific thresholds and limits for these categories sit with each payer’s bank and current FCA rules, and they can change. Always check current FCA material rather than relying on older figures found online, since several widely shared numbers online are already out of date.
Does Open Banking Need SCA, and How Does It Work There?
Does open banking need SCA? Yes, but it’s built in from the start, not added afterward. In an open banking payment, the payer authorises directly inside their own bank’s app, using whatever authentication method that bank already requires, satisfying SCA regulation natively. There’s no separate authentication step layered on top of the payment, because the bank’s own login and approval process is the authentication.
This differs from a typical card flow, where 3D Secure sits as an extra step between checkout and completion, often redirecting the payer to a separate verification screen. A payer who has marked a business as a trusted beneficiary through their bank may skip some of that friction on repeat purchases, but does open banking need SCA in the same way regardless? Yes, it still satisfies the same underlying regulation, just through a different, native route.
Read more about how payment authentication generally works across different payment types beyond SCA specifically.
Why Does SCA Regulation Affect Checkout Conversion?
Friction shows up differently depending on the payment method. Card payments often add a visible 3D Secure redirect, asking the customer to leave the checkout page, verify, and return. Every extra screen is a chance for the payer to abandon the purchase.
Bank-authorised flows, by contrast, ask the payer to approve inside an app they already trust and already have open. The strong customer authentication step feels like part of the payment, not a separate hurdle bolted on afterward.
What platforms actually control? How clearly the authorisation journey is explained before the payer leaves the checkout page, and how gracefully a failed authentication is handled, with a clear retry path rather than a dead end.
What Must Platforms Do to Handle SCA Regulation Properly?
Three practical responsibilities, regardless of payment method:
- Make the authorisation journey clear before the payer is asked to authenticate, so nothing feels unexpected.
- Handle failed authorisation gracefully, with a clear next step rather than a silent failure.
- Keep an audit record of each authentication event, since this matters for dispute handling and regulatory review.
Where Does SCA Payment Regulation Come From Legally?
SCA payment regulation in the UK sits under the Payment Services Regulations 2017, which implemented the EU’s PSD2 requirements into UK law, and it’s overseen by the FCA. For the fuller regulatory picture beyond authentication specifically, our guide to open banking UKregulation covers the wider framework, and the legal basis itself is explained in our PSD2 regulation guide.
How Does Finexer Handle SCA Regulation?
Finexer’s payment initiation service uses the payer’s own bank authorisation to complete SCA regulation natively, rather than adding a separate verification layer on top of the payment. What that means in practice:
| Capability | Detail |
|---|---|
| Authentication | Completed inside the payer’s own banking app |
| Extra steps | None added on top of the bank’s existing login |
| Authorisation | FCA-authorised (FRN 925695) for AIS and PIS |
| Settlement | Instant via Faster Payments for UK domestic payouts |
| Audit trail | Authorisation events tracked for reconciliation and review |
Real-time payment initiation through this approach is available via Finexer’s payments API, built on the same regulated infrastructure covered throughout this guide.
Bottom Line
SCA regulation requires two independent identity factors before most online payments go through, drawn from knowledge, possession and inherence. Exemptions exist for low-value, recurring and trusted-beneficiary payments, but specific thresholds should always be checked against current FCA material rather than assumed.
Open banking payments meet this requirement natively, since the payer authenticates directly in their own banking app, without the extra redirect that card flows often need. Finexer’s payment initiation is built on that same native authentication, so platforms get SCA compliance without adding friction on top. This is informational guidance; confirm your specific obligations with your own compliance advisor.
What is SCA in payments?
What is SCA? It’s a requirement for two independent identity factors before a payment is authorised: something the payer knows, has, or is. That’s the full answer to what is SCA in one sentence. SCA regulation applies to most online card and bank-authorised payments in the UK.
What triggers SCA authentication?
Most customer-initiated online payments trigger SCA authentication, including card payments and bank-authorised transfers. Merchant-initiated payments where the customer isn’t actively present generally fall outside standard scope, subject to the original mandate being authenticated correctly.
What are the main SCA exemptions?
Recognised exemption categories include low-value payments, recurring payments after the first one, and trusted beneficiaries a payer has approved through their bank. Exact thresholds vary and should be confirmed against current FCA material rather than assumed.
Does SCA regulation eliminate fraud completely?
No. SCA regulation reduces certain types of fraud by requiring stronger identity confirmation, but it isn’t a complete solution on its own. Platforms still need their own fraud monitoring and clear authorisation handling alongside SCA compliance.
Is SCA payment regulation the same for open banking as for cards?
The requirement is the same, but the experience differs. Open banking payments satisfy SCA payment regulation natively through the payer’s own bank app. Card payments typically need an added step like 3D Secure to meet the same requirement.
Payment initiation that completes SCA regulation inside the payer’s own banking app, with no separate authentication step to build.
Explore with AI
About the Author
Clare Pearson
Clare Pearson is a senior payments professional with extensive experience across the global financial services and payments industry. She specialises in Open Banking, payment infrastructure, and financial technology transformation, with expertise spanning product delivery, operational strategy, regulatory compliance, and large-scale payments programmes. Clare currently serves as a Non-Executive Director at Finexer and a panel member for the Payment Systems Regulator (PSR), advising on the development of payment systems policy and innovation