Strong Customer Authentication (SCA) Demystified: How Bank-Level Security Enables A2A Payments

Card fraud costs European businesses €1.8 billion annually. Merchants pay for fraud prevention tools, chargebacks, and false declines. Customers deal with stolen card numbers, unauthorized transactions, and blocked legitimate purchases.

Strong Customer Authentication (SCA) solves this differently. Instead of protecting card numbers (which can be stolen), SCA cryptographically proves the actual customer authorized the payment.

But most people don’t understand how SCA works, why it matters, or why it’s fundamental to account-to-account payments. They hear “SCA” and think “annoying extra security step” rather than “fundamentally better authentication.”

Here’s the complete breakdown of what SCA actually is, how it works, and why it transforms payment security.

What Strong Customer Authentication Actually Means

Strong Customer Authentication is a security standard requiring two independent factors from different categories to authenticate a payment or account access.

The three categories:

Knowledge - Something only the customer knows (password, PIN, security question answer)
Possession - Something only the customer has (phone, hardware token, smartcard)
Inherence - Something the customer is (fingerprint, facial recognition, voice pattern)

Traditional card payments:

Online: Card number + CVV + billing address (all “knowledge” - can be stolen)
In-person with chip: Card (possession) + PIN (knowledge) = SCA compliant
In-person contactless under €50: Card alone (possession only) = Not SCA, but allowed

A2A payments:

Phone (possession) + Biometric/PIN (inherence/knowledge) = Always SCA compliant
Authenticates through existing banking security infrastructure
No card data to steal because no card involved

The difference: Card details are static credentials that can be compromised and reused. SCA with A2A payments uses dynamic authentication that proves the actual customer approved this specific transaction.

How SCA Works in A2A Payment Flow

Let’s walk through a real transaction to see SCA in action:

Customer Initiates Payment (€150 purchase)

Customer scans QR code at checkout. Their banking app opens automatically with payment details visible:

Merchant name: “Gourmet Market Hamburg”
Amount: €150.00
Payment reference: Invoice #12845
Account to be debited: Current Account (…4721)

At this point, no money has moved. The customer is seeing a payment request, not an authorization.

First Authentication Factor: Possession

The banking app itself proves possession. The app:

Is cryptographically bound to the customer’s device
Contains secure credentials provisioned during account setup
Can only run on the specific device the bank authenticated

This isn’t just “having the app installed.” The app contains cryptographic keys that prove this device belongs to this customer. Those keys were issued during account setup when the customer proved their identity.

Why this matters: Stealing someone’s phone isn’t enough. The attacker would need to unlock the device (separate security) and then authenticate within the banking app (second factor).

Second Authentication Factor: Inherence or Knowledge

The banking app prompts for authentication:

Biometric (inherence): Fingerprint scan or facial recognition
PIN (knowledge): 4-6 digit PIN set during account setup
Multi-factor (knowledge + possession): SMS code sent to verified phone number

The customer uses whichever method they’ve configured for their banking app - the same method they use for transfers, bill payments, or checking balances.

What happens technically:

Customer provides biometric/PIN
Banking app validates locally (biometric) or sends to bank server (PIN)
If valid, app generates cryptographic signature proving: “Customer with account X, authenticated on authorized device Y, at timestamp Z, approved payment of €150 to merchant M”
Signature is unique to this transaction - can’t be replayed or reused

This signature is cryptographic proof of authorization. It’s mathematically verifiable that this specific customer approved this specific payment at this specific time.

Authorization and Settlement

Once authenticated:

Bank validates the signature and checks account balance
Bank locks funds (€150 reserved from customer’s account)
Payment authorization sent to merchant with cryptographic proof
Money transfers bank-to-bank via SEPA Instant (under 10 seconds)
Merchant receives settlement confirmation
Customer receives payment confirmation in banking app and via merchant receipt

The entire flow - from scan to settlement - completes in 10-15 seconds.

Security outcome:

Customer’s identity cryptographically verified (not just card number entered correctly)
Transaction authorization signed and timestamped (can’t be disputed)
No card data transmitted (nothing to steal)
No intermediaries storing authentication credentials (each party validates their piece)

Why SCA Makes Chargebacks Essentially Disappear

Card chargebacks happen because proving authorization is difficult:

Customer disputes card charge:

“I didn’t make this purchase”
“Someone used my card without permission”
“I don’t recognize this merchant”

Card network investigates:

Did merchant follow proper procedures? (card present vs not present)
Was CVV provided? (not proof of authorization, just another number)
Does signature match? (rarely checked, easily forged)
IP address, device fingerprinting? (circumstantial evidence)

The card network often can’t definitively prove the customer authorized it. Merchant loses chargeback, eats the loss.

With SCA-authenticated A2A payments:

Customer disputes payment → Bank checks authentication log:

Device ID: Customer’s authorized device (provisioned during account setup)
Biometric authentication: Matched customer’s fingerprint at 14:23:18
Cryptographic signature: Valid, timestamped, matches transaction details
Location data: Consistent with customer’s typical patterns

Proof is cryptographic, not circumstantial. The customer’s own banking security authenticated this transaction. Unless the customer claims their entire banking access was compromised (different type of dispute), the authorization is indisputable.

This eliminates 60-70% of card chargebacks - the “I didn’t authorize this” category.

Chargebacks still exist for legitimate disputes:

“Product not delivered as described”
“Service was inadequate”
“Merchant charged wrong amount”

But “I didn’t make this purchase” disputes become nearly impossible when cryptographic proof shows the customer’s authenticated device and biometric approved it.

How SCA Differs From Card Security Measures

Let’s compare modern card security to SCA-based A2A payments:

Card Security: 3D Secure (Visa Secure, Mastercard Identity Check)

What it is: Additional authentication layer for online card payments where customer verifies identity through issuing bank.

How it works:

Customer enters card details at checkout
Redirect to issuing bank’s authentication page
Customer enters password, receives SMS code, or uses banking app to approve
Bank returns authorization token to merchant
Transaction proceeds if approved

Strengths:

Adds SCA-compliant authentication to card payments
Shifts fraud liability from merchant to issuing bank
Reduces unauthorized card use online

Limitations:

Only works online (not in-person contactless or chip without PIN)
Additional redirect interrupts checkout flow (friction)
Card details still transmitted and stored (PCI compliance required)
Doesn’t eliminate card number theft (just adds verification layer)
Not universally implemented (some banks/cards don’t support it)

Fraud outcome: Reduces online card fraud by 40-60%, but fraud still exists. Card details can still be stolen and used where 3D Secure isn’t enforced.

A2A Security: SCA Built Into Payment Flow

What it is: Authentication is the payment initiation method, not an additional layer.

How it works:

Customer initiates payment (scan, tap, click)
Banking app opens (already requires device authentication)
Customer authenticates within banking app (same security as mobile banking)
Payment authorized and settled bank-to-bank
No card data involved at any step

Strengths:

SCA is mandatory for every transaction (no exceptions)
Authentication happens in familiar, trusted environment (own banking app)
Nothing to steal (no card number, no static credentials)
Works identically online, in-person, mobile, all channels
Issuing bank already invested in authentication infrastructure

Limitations:

Requires customer has smartphone and uses mobile banking
Requires merchant supports A2A payment option
Currently domestic-only in most markets (cross-border instant payments still developing)

Fraud outcome: Reduces payment fraud by 95%+ compared to standard card payments. Fraud that does occur is typically account takeover (stolen device + compromised PIN/biometric), which banks’ fraud detection catches.

The Core Difference

Card security: Protecting static credentials (card number) that can be stolen and reused. Adding verification layers to catch unauthorized use.

A2A security: No static credentials exist. Every transaction requires real-time authentication from the customer’s device using bank-level security.

One approach tries to prevent credential theft. The other eliminates credentials entirely.

Real-World SCA Security Benefits

Let’s look at concrete fraud reduction examples:

Example 1: E-commerce Retailer (€20M annual volume)

Before A2A (cards only):

Card fraud losses: €80,000 annually (0.4% of volume)
Chargeback fees: €15,000 (€15 per chargeback × 1,000 disputes)
False decline losses: €40,000 (legitimate customers blocked by fraud filters)
Total fraud-related cost: €135,000

After adding A2A (25% adoption):

A2A fraud losses: €500 (0.01% of A2A volume - nearly zero)
Card fraud losses: €60,000 (remaining 75% card volume)
Chargeback fees: €9,000 (fewer disputes)
False decline losses: €25,000 (tighter card filters acceptable with A2A fallback option)
Total fraud-related cost: €94,500

Annual savings from fraud reduction alone: €40,500

This doesn’t even include the payment processing fee savings (€25K+) from A2A’s lower transaction costs.

Example 2: Subscription Business (€8M annual recurring revenue)

Before A2A (cards only):

Card update failures: 15% of renewals fail due to expired cards, billing address changes
Recovery cost: €120,000 annually (customer service, recovery campaigns, lost subscriptions)
Involuntary churn: €180,000 in lost revenue from customers who don’t update payment method

After adding A2A (40% of subscribers switch to bank-based payment):

A2A renewal failures: Near zero (bank accounts don’t expire)
Card update failures: 9% (only 60% of subscribers still using cards)
Recovery cost: €45,000 (fewer failures to recover)
Involuntary churn: €70,000 (significantly reduced)

Annual savings from payment method stability: €185,000

The authentication security (SCA) is just one part. The elimination of expiration-based failures is the other major benefit.

Example 3: Payment Institution Offering A2A to Merchants

Portfolio risk reduction:

200 merchant clients processing €500M annually
Average fraud rate: 0.35% (€1.75M fraud losses absorbed or passed to merchants)
Average chargeback disputes: 12,000 annually (staff time, processing costs)

After enabling A2A for merchants (15% average adoption across portfolio):

A2A fraud rate: 0.02% (€15K on €75M A2A volume)
Card fraud rate: 0.40% (€1.70M on €425M card volume - slightly higher as fraudsters avoid A2A)
Total fraud losses: €1.715M (€35K reduction)
Chargeback disputes: 9,500 annually (21% reduction)

Portfolio-level impact:

Reduced fraud losses
Lower dispute processing costs
Improved merchant satisfaction (merchants lose fewer sales to fraud)
Competitive differentiation (offering more secure payment method)

The benefits accumulate across entire merchant portfolios, not just individual merchants.

SCA Compliance and Regulation

Strong Customer Authentication became mandatory in Europe under PSD2 (Payment Services Directive 2) in 2021, with exemptions for low-risk transactions.

What businesses need to know:

For Merchants

If accepting card payments:

Must support 3D Secure for online transactions (SCA-compliant authentication)
Exemptions exist for: low-value transactions under €30, recurring payments after initial SCA, trusted beneficiaries
Fraud liability: If merchant doesn’t enforce SCA when required, merchant bears fraud liability

If accepting A2A payments:

SCA is built into payment flow (automatically compliant)
No exemptions needed (every transaction authenticated)
Fraud liability: Lower risk due to cryptographic authorization proof

For Payment Institutions

If offering card processing:

Must enable 3D Secure authentication
Must implement fraud monitoring and risk-based exemptions
Must maintain PCI DSS compliance (separate from SCA)

If offering A2A payments:

Must ensure authentication meets SCA requirements (two factors from different categories)
Must integrate with banks’ authentication infrastructure
PCI DSS not applicable (no card data handled)

Regulatory Evolution: PSD2 to PSD3

PSD2 established SCA requirements and open banking frameworks. PSD3 (proposed for 2025-2026 implementation) will likely:

Strengthen SCA requirements
Expand coverage to more transaction types
Improve fraud data sharing between banks
Enhance consumer protection in payment disputes

Impact on A2A payments: SCA requirements getting stronger favors authentication-first payment methods. A2A payments align with regulatory direction (strong authentication, consumer protection, fraud reduction).

Common SCA Questions and Misconceptions

”Doesn’t SCA make checkout slower and more annoying?”

It depends on implementation:

Bad SCA implementation (early 3D Secure):

Redirect customer away from merchant site
Load third-party authentication page (often slow)
Customer enters password they rarely use (friction)
Redirect back to merchant (more loading time)
Added 20-40 seconds to checkout, increased abandonment 10-15%

Good SCA implementation (modern A2A):

Banking app opens automatically (no redirect, no external page load)
Customer uses familiar authentication (same as mobile banking)
Biometric authentication takes 2-3 seconds
Entire flow completes in 10-15 seconds (comparable to card tap)
No added friction because authentication is built into initiation

The authentication requirement isn’t the problem. Poor user experience design is the problem.

”Can’t fraudsters just steal phones and use biometrics?”

Yes, but it’s exponentially harder than stealing card numbers:

To steal and use a card:

Obtain card number (data breach, phishing, physical theft)
Obtain CVV (same sources)
Obtain billing address (publicly available, data breach)
Use card online before victim notices and cancels
Success rate: High if acting quickly

To steal and use bank account via SCA:

Physically steal specific person’s phone (targeted, risky)
Unlock phone (requires victim’s device PIN/biometric)
Open banking app (requires separate banking authentication)
Authenticate payment (requires victim’s banking PIN or biometric)
Complete before victim notices phone stolen and freezes account
Success rate: Very low

Plus: Banks monitor for unusual patterns. Phone stolen in London, payment attempted in Manchester 30 minutes later? Flagged. Device suddenly making payments after being inactive? Flagged. New payee never seen before? Additional verification required.

It’s not impossible, but it’s 100x harder than card fraud.

”What if customer loses phone or it breaks?”

Banking app authentication is recoverable:

If phone is lost/stolen:

Customer contacts bank to freeze account access
Customer obtains new phone
Customer re-registers banking app on new device (identity verification required)
New device provisioned with new cryptographic keys
Old device’s keys invalidated (can’t be used even if found)

If phone breaks temporarily:

Customer can still make payments via bank website (with SCA authentication)
Customer can use backup authentication methods (SMS codes to verified number)
Customer can authenticate via other trusted devices if multi-device setup enabled

Card comparison: If card is lost, customer needs physical replacement card mailed (2-5 days). Banking app can be restored same day with identity verification.

”Does SCA work for recurring payments and subscriptions?”

Yes, but implementation differs:

Initial subscription setup:

Customer authenticates with full SCA (biometric/PIN in banking app)
Customer authorizes recurring payment mandate
Bank stores mandate (not payment details - the authorization to charge)

Subsequent recurring charges:

Merchant initiates charge based on mandate
Bank validates mandate is active and within authorized parameters (amount, frequency)
Payment completes without customer re-authentication (SCA exemption for recurring)
Customer receives notification of charge

If something changes (amount exceeds original mandate, frequency changes):

Full SCA authentication required again
Customer must explicitly approve the change

Customer control: Can revoke mandate anytime through banking app (not by calling merchant to cancel card on file).

This is actually more secure than card subscriptions where merchant stores card details and can charge indefinitely until customer notices and cancels.

How SCA Enables Seven A2A Payment Methods

Strong Customer Authentication is technology-agnostic. It specifies what must happen (two-factor authentication proving customer authorization), not how it must happen.

This enables payware’s seven initiation methods to all work with SCA:

1. QR Code Scanning

Customer scans code → Banking app opens → SCA authentication → Payment complete
SCA happens in banking app, regardless of how payment was initiated

2. NFC Contactless Tap

Customer taps phone → Banking app opens → SCA authentication → Payment complete
Same SCA process, different trigger

3. BLE Proximity Detection

Customer enters Bluetooth zone → Banking app opens automatically → SCA authentication → Payment complete
Hands-free initiation, but still requires explicit SCA approval

4. Payment Link Click

Customer clicks link in message/email → Banking app opens → SCA authentication → Payment complete
Works across channels (WhatsApp, SMS, email, social)

5. SMS Initiation

Customer sends text to initiate → Banking app opens → SCA authentication → Payment complete
No app required for initiation, but SCA still happens in banking app

6. Barcode Scanning

Merchant scans customer’s barcode → Banking app opens on customer’s phone → SCA authentication → Payment complete
Merchant triggers it, but customer still must authenticate

7. Soundbite Audio Signal

Customer initiate listing an audio signal (radio, event, TV) within the banking app → SCA authentication → Payment complete
Broadcast-triggered, individually authenticated

The pattern: Initiation method varies by context. SCA authentication is consistent. This is why A2A payments can serve so many different commerce scenarios while maintaining bank-level security.

SCA and the Future of Payment Security

Authentication technology continues evolving:

Current SCA methods:

Biometric (fingerprint, face recognition)
PIN/password
SMS codes
Hardware tokens

Emerging SCA methods:

Behavioral biometrics (typing patterns, device usage patterns)
Voice recognition
Liveness detection (video-based verification that person is physically present)
Multi-factor combinations (biometric + location + device + behavioral)

The direction: More seamless authentication that’s harder to fake. Security improving without adding friction.

For A2A payments: These improvements happen at the banking layer. As banks deploy better authentication, A2A payments automatically benefit. Merchants don’t need to implement security updates - they inherit them from banking infrastructure.

For card payments: Improvements require card network coordination, merchant implementation, customer enrollment. Slower rollout, more fragmented adoption.

This is why authentication-first payment methods (A2A) have structural advantages as security requirements increase.

Why payware Built SCA-First Payment Infrastructure

Most payment providers built card infrastructure first, then retrofitted security. payware built backward: authentication-first, payment second.

Our design principle: If authentication fails, payment never initiates. If authentication succeeds, payment is guaranteed.

This means:

For merchants:

No PCI compliance burden (no card data to protect)
No fraud prevention tooling needed (authentication is fraud prevention)
No chargeback management infrastructure (disputes are rare and provable)
Security inherited from banking layer (improves automatically as banks upgrade)

For payment institutions:

Lower fraud exposure across merchant portfolio
Reduced compliance overhead vs card processing
Stronger merchant retention (merchants value security and economics)
Competitive differentiation in security-conscious markets

For customers:

Bank-level security (same as mobile banking)
Familiar authentication (no new credentials to remember)
Protection against unauthorized charges (cryptographic proof required)
Control over payment mandates (can revoke directly through bank)

Authentication isn’t an added layer. It’s the foundation.

Real-World Security Case Study

Scenario: Mid-size e-commerce retailer (€15M annual volume) experiencing growing card fraud as they scale.

Initial state (cards only):

Monthly fraud losses: €4,500 (0.36% of volume)
Chargeback processing: 80 disputes/month (€1,200 in fees)
False declines: €2,800/month in lost legitimate sales
Fraud prevention tools: €800/month subscription
Staff time: 15 hours/month investigating disputes
Total monthly fraud cost: €9,300

After A2A implementation (30% adoption over 12 months):

Month 1-3 (8% A2A adoption):

A2A fraud losses: €15 (0.01% of A2A volume)
Card fraud losses: €4,200 (concentrated on remaining card volume)
Early impact: Minimal cost reduction, but proof of concept validated

Month 6 (18% A2A adoption):

A2A fraud losses: €30
Card fraud losses: €3,800
False declines: €2,200 (can tighten card fraud filters with A2A fallback)
Chargeback disputes: 62/month (€930 fees)
Monthly fraud cost: €7,760 (17% reduction)

Month 12 (30% A2A adoption):

A2A fraud losses: €50
Card fraud losses: €3,400 (70% of volume on cards)
False declines: €1,600 (offering A2A recovers customers who’d be declined on cards)
Chargeback disputes: 48/month (€720 fees)
Fraud prevention tools: €600/month (reduced tier with lower card volume)
Staff time: 9 hours/month (fewer disputes)
Monthly fraud cost: €6,370
Monthly savings: €2,930 (32% reduction)
Annual savings: €35,160

Plus: Payment processing fee savings from 30% A2A adoption at 0.5% vs 1.2% average card fees = €31,500 additional annual savings.

Total annual impact: €66,660 saved. Implementation cost: €8,000 (technical integration + staff time). ROI achieved in 44 days.

The Bottom Line on SCA and A2A Payments

Strong Customer Authentication isn’t a compliance checkbox. It’s the reason A2A payments can offer:

95% fraud reduction vs standard card payments
Near-zero “I didn’t authorize this” chargebacks
Bank-level security without merchant PCI burden
Automatic security improvements as banks upgrade authentication

The technology exists. The infrastructure is live. The authentication standards are proven.

The question isn’t whether SCA makes A2A payments secure enough. The question is whether card payments can remain competitive as authentication requirements increase and merchants realize they’re paying 2-3% partly to protect static credentials that can be stolen.

Next Steps

For merchants: Evaluate fraud costs (direct losses + chargebacks + false declines + prevention tools). Compare to A2A’s authentication-first security model. Calculate potential savings.

For payment institutions: Assess merchant churn risk from fraud concerns. Consider how offering SCA-compliant A2A payments reduces portfolio risk and differentiates your offering.

For both: Security requirements are increasing (PSD3, fraud regulation, consumer protection laws). Payment methods with authentication built in align with regulatory direction.

Want to explore SCA-compliant A2A payments?

payware provides authentication-first payment infrastructure with built-in Strong Customer Authentication, supporting seven payment initiation methods and settling instantly at 0.5% flat fees. We work with payment institutions to enable secure A2A payments for merchant portfolios.

Learn more: payware.eu
Contact: Get in touch

About payware

payware is the neutral universal interoperability standard for instant account-to-account (A2A) payments worldwide. The platform enables payment institutions, merchants, ISVs, and developers to join a network where every connection multiplies value for all participants. With 7 innovative payment initiation methods - QR code, NFC, BLE, soundbite, text, link, and barcode - payware delivers exceptional end-user experiences while offering fees as low as 0.5% and instant settlement. Founded in 2019, payware creates unprecedented value through universal domestic interoperability.

Related Posts