The Card Payment Authentication Gap: Why SCA Solved the Door and Left the Session Open

Strong Customer Authentication was a significant step forward for the payments industry. PSD2 mandated it. Card issuers, acquirers, and payment platforms invested heavily in getting the authentication moment right — multi-factor, biometric, device-bound. The door to the session became genuinely harder to force open.

But the session that follows that authentication is still running on trust.

And trust, in a fraud environment shaped by AI-enabled impersonation, authorised push payment schemes, and account takeover at industrial scale, is not a control.

What SCA Was Designed to Do

Strong Customer Authentication was designed to solve a specific and well-understood problem: reducing card-not-present fraud by ensuring that the person initiating an online transaction could be verified as the legitimate account holder at the point of entry.

It works on three principles — something you know, something you have, something you are — applied at login or at the point of triggering a transaction. The authentication event is the control. Pass it, and the session begins.

This was the right solution to the problem it was designed for. Stolen credentials are significantly less useful when authentication also requires a device or a biometric. Fraud rates for card-not-present transactions improved materially as SCA penetration increased.

What SCA was never designed to address is what happens in the session after the authentication event has occurred. That was not an oversight. It was a scope decision. The regulation solved the entry point. The room beyond it was assumed to be safe.

That assumption no longer holds.

The Session Layer: Where Fraud Has Moved

The fraud landscape has shifted in ways that SCA's architecture was not built to detect.

The fastest-growing category of payment fraud does not involve a fraudster attempting to authenticate as someone they are not. It involves a fraudster entering a session after a legitimate user has already authenticated — or manipulating the legitimate user during their authenticated session into approving transactions they did not intend to authorise.

Authorised push payment fraud — where a victim is socially engineered into transferring funds while logged into their own account — has become the dominant fraud vector for UK banking. The FPS reported over £500 million in APP fraud losses in 2024. In almost every case, the user authenticated legitimately. The fraud happened inside the session.

Account takeover via session hijacking operates similarly. The attacker does not need to defeat the login. They capture a valid session token — through malware, man-in-the-browser attack, or network interception — and operate within the authenticated session without ever triggering the authentication check.

The common thread: the authentication event was genuine. The session was compromised afterward.

SCA has no mechanism to detect this. It is not designed to. It verified the entry. What happens inside is outside its scope.

Four Scenarios Where the Session Gap Becomes Fraud

Account takeover after clean authentication. A cardholder authenticates legitimately on a device that is carrying session-hijacking malware. The attacker waits. The authentication event passes. The session token is captured. High-value transactions are initiated from inside an authenticated session, attributed to the legitimate account holder, with no authentication failure to trigger a fraud signal.

Authorised push payment fraud. A cardholder receives a call from a convincing voice — a bank, a regulator, a building society. They are coached, while logged into their account, to transfer funds to a "safe account." They authorise every step. The platform sees a legitimate user making legitimate payments. The authentication was real. The authorisation was coerced.

Shared device access. A cardholder authenticates, then passes their device to a family member, colleague, or partner. The session persists. Transactions are executed by someone other than the verified account holder. The platform has no mechanism to detect the handover. All actions are attributed to the authenticated user.

Compromised session via delegated access. A small business user authenticates into a payment portal, then steps away from their desk. A colleague — or an unauthorised individual — executes transactions from the still-active session. The business discovers the discrepancy in reconciliation. The platform's log shows all actions originating from a legitimate authenticated session.

In each scenario, the authentication was not defeated. The session was. And the platform's audit trail recorded a legitimate user making legitimate decisions — because it had no mechanism to verify that the legitimate user was still present.

What Closing the Gap Requires

The gap between authentication and continuous presence verification is a technical one, but the solution does not require replacing existing authentication infrastructure. It requires extending it.

Closing the session layer gap requires three things working together.

Continuous identity verification. Confirmation that the authenticated user remains the active user throughout the session — not an assumption, a verification. Passive, on-device biometric checking that runs throughout the session without introducing friction for the legitimate user, and triggers a policy response if the biometric match fails.

Verification at the transaction layer, not just at login. For card payment platforms, this means confirming cardholder presence at the point each transaction is executed — not just at the start of the session. The verification event attaches to the transaction, not to the session as a whole.

A session assurance record. A verifiable record, attached to each transaction and each session, that evidences the verified account holder was present at the point of the action. Not an access log. A verified identity record that can withstand scrutiny in a dispute, a regulatory review, or a fraud investigation.

The YEO Continuous Facial Recognition SDK provides exactly this layer. It integrates at the application level into existing card issuing apps, merchant portals, and institutional account interfaces — embedding passive, on-device biometric verification that runs continuously throughout the session. No biometric data is transmitted or stored externally. No disruption to existing KYC or login infrastructure. Functional within days of integration.

The Regulatory Direction

PSD3 is moving the authentication conversation forward. The European Commission's proposals tighten SCA requirements and place stronger obligations on payment service providers to demonstrate that their fraud controls are proportionate to the risk — at the transaction level, not just at login.

FFIEC guidance in the United States has for several years expected layered authentication controls for high-risk transactions, with explicit provision for re-verification when risk signals are detected mid-session. The regulatory expectation that authentication extends beyond the login event is already present in the framework — it is increasingly being applied.

The direction is consistent. Platforms that have built session-layer verification now are not getting ahead of the regulation. They are meeting an obligation that is already arriving.

What This Means for Card Payment Platforms

For card issuers, acquirers, and payment platform providers, the practical question is this: at what point in the session does your platform verify that the right person is still there?

If the answer is only at login — or only when a fraud model raises a flag — there is a window. That window is where APP fraud enters. Where account takeover operates. Where device handover goes undetected. Where session-layer fraud occurs inside a perfectly legitimate authentication.

The technology to close that window is available now. It integrates without displacing existing controls. It provides the session-layer identity assurance that PSD2's SCA mandate was never designed to deliver.

The authentication moment has been solved. The session is the next problem — and in 2026, it is already the primary fraud surface.

To understand what continuous session verification looks like in practice for your card payment platform, book a technical integration call or read the CFR SDK documentation at yeomessaging.com/sdk.