Strong Customer Authentication (SCA) under PSD2 in 2026: 3-D Secure 2, Exemptions and the 30 EUR Rule, Explained

TL;DR

Strong Customer Authentication (SCA) is the EU-wide rule, in force since 14 September 2019, that requires payment service providers to authenticate you with at least two of three independent factors — knowledge, possession, inherence — for online logins, card payments and any other "remote" payment-related action. It is anchored in the PSD2 directive (2015/2366) and detailed in the Regulatory Technical Standards: Commission Delegated Regulation (EU) 2018/389. Enforcement is supervised by the European Banking Authority and national competent authorities (BaFin, ACPR, Bank of Italy, Banco de España, DNB, KNF, Central Bank of Ireland). For you as a consumer it explains why your bank app pings you on every login, why most card payments above 30 EUR pop a 3-D Secure 2 prompt, and why subscriptions and small transactions sometimes glide through silently.

Educational content, not legal, regulatory or fraud-prevention advice. SCA rules continue to evolve with PSD3 / PSR; verify with your national competent authority.

What changed: pre-SCA vs SCA vs PSD3

Pre-SCA (pre-September 2019): card payments online required a static card number, expiry, CVV — at most a clunky 3-D Secure 1 SMS one-time-password sent to your registered phone. Online-banking logins relied on a password plus optional SMS code. Fraud losses on card-not-present transactions grew double-digit percent year over year through the 2010s.

SCA (since September 2019, with 3-D Secure 2 enforcement ramped through 2020–2021): every "electronic payment" — including online banking access, card payments above 30 EUR, and any payment initiation by a third party — requires SCA. The clunky SMS OTPs have largely been replaced by in-app push notifications + biometrics (Face ID, fingerprint). E-commerce checkout flows now route through 3-D Secure 2 (3DS2), which is a richer protocol that can share device, behavioural and transaction context with the issuer to reduce friction.

Toward PSD3 / PSR (2026+): the European Commission's proposal COM(2023)366 reaffirms SCA, harmonises the patchy national interpretations into a directly applicable Payment Services Regulation, tightens fraud-liability rules (banks bear refund liability for IBAN/name mismatch and spoofed caller-ID scams), introduces clearer rules for accessibility (SCA must work for people with disabilities), and clarifies that inherence factors can include behavioural biometrics.

Stakeholders in the SCA flow

• Payment Service User (PSU) — you, the consumer or business
• ASPSP (Account Servicing Payment Service Provider) — your bank, operator of the SCA flow
• Card issuer — your bank again (or a separate issuer for prepaid/co-branded cards), operator of 3DS2
• Acquirer + merchant — the e-commerce store and its acquiring bank; both must support 3DS2
• AISP / PISP — when a third-party app reads your accounts or initiates a payment, it triggers SCA but the bank runs the flow
• Card scheme — Visa, Mastercard, Amex; operates the 3DS2 directory server (Visa Directory Server, Mastercard Identity Check)
• National CA — BaFin / ACPR / KNF / etc. supervise SCA compliance

Legal framework

Headline source: Directive (EU) 2015/2366 (PSD2) Articles 97–98, supplemented by Commission Delegated Regulation (EU) 2018/389 — the "RTS on SCA and common, secure open standards of communication", applicable from 14 September 2019. National transposition includes ZAG (Germany), Ordonnance 2017-1252 (France), D.lgs. 218/2017 (Italy), RDL 19/2018 (Spain), Wft amendment (Netherlands), Ustawa o usługach płatniczych (Poland). The EBA has issued more than 20 Opinions and Q&A documents clarifying SCA edge cases — most importantly EBA-Op-2019-06 on SCA elements and the March 2021 extension of the consent renewal period from 90 to 180 days.

API technical standards meeting SCA

SCA must be supported across all PSD2 channels:

• Online banking (browser or mobile app) — bank's own SCA implementation
• Card not-present — 3-D Secure 2 (EMV 3DS), a protocol authored by EMVCo; v2.1 mandatory from 2020, v2.2 widely deployed by 2022, v2.3 rolling out 2024–2026
• AISP/PISP API access — Berlin Group NextGenPSD2, STET, PolishAPI and OBIE each define their SCA hand-off model: typically OAuth2-style redirect to the bank's SCA endpoint, or "decoupled" push to the bank app
• In-store payments — Chip & PIN remains the canonical SCA combination

The three factors — and why "2 of 3" is harder than it sounds

SCA requires authentication with at least two of three independent factors, classified as:

• Knowledge — something you know: password, PIN, response to a secret question, pattern. Must be private — a published OTP or visible PIN no longer counts.
• Possession — something you have: registered smartphone with the banking app (the most common), hardware token (Yubikey-style), registered SIM card for SMS OTP (increasingly deprecated), registered desktop with cryptographic device-binding
• Inherence — something you are: fingerprint, Face ID / 3D facial recognition, voice biometric, behavioural biometric (typing rhythm, gait, swipe pattern)

The three factors must be independent — compromise of one must not lead to compromise of the others. A password (knowledge) typed into a phone (possession) does not count as 2-factor if the phone is also where the password manager autofills. SMS OTP, long the universal solution, has been increasingly criticised by EBA — SIM-swap fraud has driven adoption of in-app push + biometric as the safer "possession + inherence" pair.

In practice your modern bank app login is: open the app (proves possession of registered device with bank-bound cryptographic key), authenticate with Face ID or fingerprint (inherence). That is your SCA.

Where SCA fires — every place it touches your day

1. Online banking login — required at first session of the day and after a defined idle period (the EBA confirmed 5 minutes idle as the minimum acceptable session ceiling; many banks force re-SCA more often).
2. Initiating a payment — credit transfer, instant SEPA payment, bill payment.
3. Adding a new beneficiary — also requires SCA, distinct from making the first payment to them.
4. Card payment online above 30 EUR — triggers a 3DS2 step-up to your bank app for biometric confirmation.
5. AISP first connection — when you link an account-aggregation app to your bank.
6. AISP consent renewal — every 180 days (extended from 90 in March 2021), the AISP must redirect you back through SCA.
7. PISP payment initiation — every "pay by bank" instructed by a third party.
8. In-store contactless above 50 EUR — chip + PIN required, with cumulative caps that force PIN after 5 consecutive low-value taps or 150 EUR cumulative.

SCA exemptions — why some payments still glide through

The RTS define a closed list of exemptions. Within each, the issuing bank has discretion to apply or skip them. The most relevant in daily life:

Low-value transactions (Art. 16 RTS)

A single remote electronic payment ≤30 EUR can skip SCA, provided cumulative caps are not exceeded:

• Cumulative value of unauthenticated payments ≤100 EUR, OR
• Number of consecutive unauthenticated payments ≤5

When either cap is reached, the next payment must be SCA-authenticated, and the counters reset.

Recurring transactions (Art. 14 RTS)

A subscription of identical amount to the same beneficiary requires SCA only on the first instance — every subsequent automatic charge is exempt. This is what makes Netflix, Spotify, gym memberships and cloud bills flow without friction.

Trusted beneficiaries / "merchant whitelist" (Art. 13 RTS)

When you add a payee or merchant to your bank's trusted list (via an SCA-authenticated action), subsequent payments to that payee can be exempted. Adoption was slow at issuers in 2019–2021 but is now broadly available.

Transaction Risk Analysis — TRA (Art. 18 RTS)

The headline acquirer- or issuer-side exemption. A payment service provider with low fraud rates may skip SCA on a per-transaction basis based on its own real-time risk scoring — provided overall fraud stays below the reference fraud rate (RFR):

• For payments ≤100 EUR: RFR ≤ 0.13 %
• For payments 101–250 EUR: RFR ≤ 0.06 %
• For payments 251–500 EUR: RFR ≤ 0.01 %
• Above 500 EUR: no TRA exemption available — SCA mandatory.

If a PSP's fraud rate exceeds the threshold for one quarter, it loses TRA on that band the next quarter. Acquirers compete on TRA pass-through to merchants — a stronger fraud model means more checkouts gliding without 3DS2 friction.

Corporate payments (Art. 17 RTS)

Payments through dedicated secure corporate protocols (EBICS, SWIFT-style) can skip SCA — the assumption being that the corporate's own controls substitute.

Account information (Art. 10 RTS — modified)

SCA is required on first AISP connection and at least every 180 days (extended in March 2021 from 90). Within that window, the AISP can refresh data without SCA up to 4 calls per day under EBA Q&A guidance.

Unattended terminals (Art. 12 RTS)

Transport and parking terminals — bus tickets, motorway tolls — can skip SCA. This is why your contactless card works at the U-Bahn turnstile.

Mail-order / telephone-order (MOTO)

Payments where the cardholder is not present online (e.g. taking an order over the phone) sit outside SCA scope. This is a residual category, increasingly small.

3-D Secure 2 (3DS2) — the SCA layer over card payments

3DS2 is the EMVCo protocol that operationalises SCA for card-not-present transactions. The key flow:

1. You enter card details at checkout
2. The acquirer's 3DS2 server contacts the card scheme directory server
3. The directory routes to your issuer's ACS (Access Control Server)
4. The ACS evaluates ~150 device, behavioural and transaction-context data points sent in the request
5. The ACS decides: frictionless (no challenge, exemption applies — TRA, low-value, trusted beneficiary) or challenge (SCA required)
6. If challenge: redirect to your bank app or web page for biometric / OTP
7. ACS returns an authentication result + liability-shift token
8. Acquirer submits authorisation to the card network

3DS2 vs the old 3DS1: 3DS1 was a clumsy iframe SMS-OTP universal flow, with abandonment rates often ≥30 %. 3DS2 sends device fingerprinting and risk context upfront so most low-risk transactions become frictionless. Modern issuer ACSs grant a frictionless decision on ~70–80 % of 3DS2-eligible volume.

Liability shift

Two liability questions matter for SCA:

1. Unauthorised payment refund — under PSD2 Art. 73 your bank must refund any unauthorised payment by the end of the next business day, unless it can prove gross negligence on your part. Your maximum out-of-pocket exposure on a lost-card unauthorised use is 50 EUR.
2. Merchant/acquirer chargeback liability — when a payment is authenticated via 3DS2 SCA, liability for fraud shifts from the merchant to the issuer (the bank). When the merchant relies on a TRA exemption and a fraud occurs, the merchant typically retains liability. This is why merchant payment teams obsess over TRA pass-through rates.

PISP-initiated payments: the PISP bears liability for unauthorised initiation, with recourse against the ASPSP if the failure was at the bank API. AISPs (read-only) carry no payment liability but full GDPR Art. 6 / Art. 32 accountability for the data they process.

PSD3 / PSR — what changes for SCA

The Commission's proposals tighten SCA without dismantling it:

• Harmonised SCA via directly applicable PSR — no more national divergence on "knowledge / possession / inherence" interpretation
• Accessibility — explicit requirement that SCA must be accessible to elderly users and people with disabilities (no biometric-only flows that exclude users without a smartphone)
• Behavioural biometrics explicitly recognised as inherence
• IBAN / name matching mandatory on credit transfers; failure pushes liability to the bank
• Anti-spoofing — banks bear refund liability when their caller-ID was spoofed in a "vishing" scam
• Open finance / FIDA — SCA-like consent flows extended to mortgage, pension, insurance data access

PSD2 (EU) vs UK Open Banking SCA differences

For consumers — practical reading

1. Set up your bank app on a known device — that single device is your possession factor for almost everything.
2. Enable biometric (Face ID / fingerprint) — your inherence factor.
3. Do not rely on SMS OTP as the only possession factor; SIM-swap fraud is real. Use the bank's push-to-app where offered.
4. Add trusted beneficiaries for recurring payees — fewer SCA prompts.
5. Watch for vishing — your bank will never ask you to read out an SCA code received by SMS.
6. 180-day renewals — when your finance app prompts you to "reconnect", that is the PSD2 consent expiry, not a security incident.

Many users benefit from AISP-integrated personal finance apps that aggregate multi-bank balances and trigger SCA only at 180-day renewal; Freenance, an EU-native AISP-aligned personal finance and AI cashflow companion, is one example, built around a Financial Freedom Runway view.

For developers and merchants

• Build for frictionless first — design checkout, request 3DS2 with full device data, hope for frictionless outcome
• Apply for TRA exemption with your acquirer if your fraud rates allow
• Tag MIT (Merchant Initiated Transactions) correctly — they sit outside SCA
• Handle fallback — if 3DS2 fails, do not silently downgrade to 3DS1 unless explicitly allowed
• Logging — keep complete 3DS2 transaction status traces for chargeback defence
• AISP/PISP flows — implement bank-redirect and decoupled SCA, never store credentials, never request SCA factors yourself

Worked example: 30-year-old's day with SCA

Anna, 30, in Warsaw, holds mBank PLN, Revolut EUR and N26 DE. A typical Tuesday:

• 08:00 — opens mBank app, Face ID. SCA (possession + inherence).
• 08:05 — pays 15 PLN BLIK at the bakery. Exempt (low-value cumulative under cap).
• 10:30 — Spotify Premium 19.99 PLN auto-debit. Exempt (recurring subscription, SCA was on first sign-up).
• 12:30 — buys lunch on Uber Eats, 42 PLN by card. Acquirer applies TRA → frictionless 3DS2.
• 15:00 — buys flights on a low-cost airline, 248 EUR. Above the 100 EUR cumulative cap and above the low-value threshold → 3DS2 challenge to her N26 app. Face ID.
• 19:00 — refreshes her personal finance app to check her runway. The aggregator pulls fresh balances without SCA (within 180-day window, fewer than 4 calls/day).
• 22:00 — adds a new beneficiary (her landlord's account). SCA in mBank app.
• 22:01 — sends first rent payment, 2,200 PLN. SCA again (separate from add-beneficiary action).

Roughly 4 SCA prompts on a busy day; the rest exempt.

Polish reader angle: SCA in Polish banks

Polish banks were among the fastest in the EU to move to in-app push + biometric SCA — driven by BLIK's mobile-first culture. By 2026:

• mBank, ING, PKO BP, Santander, Pekao, Millennium, Alior — push-to-app + biometric SCA on every login and every transfer above 30 EUR.
• BLIK itself is an SCA-compliant 6-digit one-time code combined with mobile-app confirmation.
• 3DS2 maturity — PolCard, eService and most large acquirers run mature TRA models; frictionless rates on Polish-issued cards are among the highest in the EEA.
• KNF supervises SCA compliance and has issued enforcement actions against banks lagging on biometric SCA rollouts.
• 180-day renewal is enforced — AISP-integrated apps prompt users to redo SCA in the bank app twice a year.

FAQ

Why does my bank ask SCA so often? PSD2 requires SCA on login (after a short idle period), on every payment above 30 EUR (subject to exemptions), and at 180-day AISP renewal. If you also frequently log out, change devices or trigger TRA-rejection patterns, prompts pile up.

Can I skip SCA on a recurring subscription? The first subscription payment requires SCA; subsequent identical-amount payments to the same merchant are exempt. If the merchant changes the amount or you change card, SCA fires again.

Is SMS OTP still allowed as SCA? Technically yes if combined with an independent second factor, but EBA opinions have warned of SIM-swap risk and banks have largely migrated to push + biometric. Pure SMS as the only factor is not compliant.

What happens if a transaction was SCA-authenticated but I still didn't authorise it? Under PSD2 Art. 73 the bank must refund immediately unless it can prove gross negligence. Successful SCA shifts the chargeback liability but does not eliminate your right to dispute.

Why does my finance app keep asking me to reconnect every six months? That is the PSD2 AISP consent renewal — 180 days since EBA's March 2021 extension. The app must redirect you to your bank for fresh SCA to keep the data flowing.

Will SCA become less painful? PSD3 aims to harmonise it and codify behavioural biometrics, which can deliver near-invisible authentication. TRA exemption rates also keep improving. Expect fewer prompts over time, not more.

Sources

• Directive (EU) 2015/2366 (PSD2)
• Commission Delegated Regulation (EU) 2018/389 (RTS on SCA)
• European Commission proposal COM(2023)366 (PSD3 / PSR)
• EBA Opinion EBA-Op-2019-06 on SCA elements
• EBA Opinion of March 2021 extending AIS consent renewal to 180 days
• EMVCo 3-D Secure protocol specifications v2.1 / v2.2 / v2.3
• National competent authorities: BaFin, ACPR, Bank of Italy, Banco de España, DNB, KNF, Central Bank of Ireland, FCA