How 3DS Data Helps Issuers Detect Scams

A cardholder successfully completes a 3D Secure (3DS) challenge, confirming their identity through a one-time passcode or banking app. Yet the transaction may still be fraudulent.

In social-engineering scams, criminals persuade genuine cardholders to authenticate payments they would otherwise reject. The authentication mechanism works as intended, but the cardholder’s decision has been manipulated.

For issuers, 3DS scam detection requires looking beyond the authentication outcome. Device information, transaction context and challenge behaviour can provide useful signals, particularly when combined with issuer-held fraud intelligence.

Why Successful Authentication Does Not Always Mean a Safe Transaction

EMV 3D Secure helps issuers verify cardholders during online transactions. However, authentication cannot establish whether a customer is acting independently or following fraudulent instructions.

For example, a scammer impersonating a bank employee might convince a customer to approve a payment as part of a supposed security procedure. The customer completes a legitimate 3DS challenge, unknowingly authorising activity initiated by the criminal.

The growing sophistication of impersonation makes this distinction increasingly relevant. In October 2026, INTERPOL warned about scams involving AI-generated voices, faces and other synthetic media.

Issuers therefore need to distinguish between confirming a cardholder’s identity and assessing the legitimacy of the transaction.

Which 3DS Data Can Help Identify Potential Scams?

EMV 3DS provides information about the transaction and authentication environment. An Access Control Server (ACS) can use this information during risk assessment, while issuer systems may retain or combine relevant data for further investigation.

Data category	Available information	Potential risk indicator
Browser data	IP address, browser characteristics, language and time zone	Unusual or inconsistent checkout environment
App-based device data	Device and operating-system attributes collected through a 3DS SDK	An unfamiliar device associated with the transaction
Device channel	Browser, app or 3DS Requestor Initiated (3RI)	Authentication context differing from established patterns
Transaction details	Merchant, amount, currency and transaction context	Activity inconsistent with the cardholder’s history
Challenge outcome	Authentication status and relevant challenge information	Context for investigating a successfully authenticated transaction

The EMVCo 3DS technical guidance explains how browser and app-device information can support authentication risk assessment.

However, an unfamiliar device or unusual transaction does not independently establish fraud. Legitimate customers frequently change devices, locations and purchasing habits.

How Challenge Behaviour Can Strengthen Risk Assessment

Challenge behaviour may provide additional context when an issuer or its authentication systems record relevant interaction data.

For example, investigators might examine whether:

A challenge took considerably longer than comparable authentication attempts
Multiple authentication attempts occurred before success
An unusual authentication method was used
The event coincided with suspicious account activity

Such observations may help identify cases that warrant further investigation.

Challenge duration, retries and interaction patterns are not universally available as standard EMV 3DS message fields. Their availability depends on the ACS implementation and other issuer systems.

A delayed authentication might reflect poor connectivity rather than fraudulent instructions. Issuers should therefore assess combinations of reliable indicators rather than treating individual anomalies as proof of a scam.

Where Issuers Can Act After a Successful Challenge

The timing of a fraud alert determines what action is possible.

In a standard EMV 3DS challenge flow, the ACS manages the cardholder authentication process and communicates the resulting authentication status. Payment authorisation is a separate process.

There are three relevant decision points:

Before the final authentication result: Additional risk assessment may be possible if the issuer’s implementation supports it. This is not a universal ACS capability.
Before payment authorisation: Issuer fraud systems may assess the authentication result alongside transaction and account intelligence when making an authorisation decision.
After the transaction: Authentication records may support fraud investigations, customer protection measures and improvements to future detection rules.

A successful 3DS challenge does not automatically require the issuer to approve a subsequent authorisation request.

Equally, a fraud alert generated after authorisation cannot retrospectively prevent that authorisation.

What Issuers Should Consider When Evaluating Their ACS

Issuers seeking to improve scam detection should establish what information their ACS actually collects and which capabilities depend on external systems.

Key considerations include:

Data visibility: Which browser, device and authentication attributes are accessible?
Integration: Can relevant authentication records be linked with issuer fraud and authorisation systems?
Timing: At what point are risk signals available for decision-making?
Investigation: Can authentication events be matched with confirmed scam cases?
False positives: How will legitimate transactions be distinguished from suspicious behaviour?

GPayments’ ActiveAccess is an issuer-side ACS solution supporting EMV 3DS authentication. Issuers evaluating specialised scam detection should confirm which data, telemetry and integration capabilities are supported in their particular deployment.

Frequently Asked Questions

Can a 3DS transaction be fraudulent even after successful authentication?

Yes. A scammer may manipulate a genuine cardholder into completing a legitimate authentication challenge. Successful authentication does not, by itself, prove that the transaction is free from fraud.

Can an ACS detect social-engineering scams?

An ACS can use authentication and transaction data to assess risk. However, identifying social engineering may require additional information from issuer fraud systems. A dedicated scam-detection capability should not be assumed without verifying the implementation.

What 3DS data is useful for scam detection?

Browser and app-device attributes, device channel, transaction details and authentication outcomes may provide useful context. Their effectiveness depends on how the issuer combines these signals with historical activity and other fraud intelligence.

Can issuers decline a payment after a successful 3DS challenge?

Yes. Authentication and authorisation are separate processes. A successful challenge does not guarantee authorisation approval, and issuers may consider other fraud indicators when deciding whether to approve a transaction.

Looking Beyond Successful Authentication

EMV 3DS helps issuers establish whether cardholders have completed the required authentication process. Detecting social-engineering scams requires another layer of assessment because a genuine customer may authenticate a fraudulent transaction.

By combining available 3DS information with reliable issuer-held intelligence, payment providers can identify suspicious circumstances more effectively without treating authentication anomalies as conclusive evidence.

Explore ActiveAccess to learn more about GPayments’ issuer authentication solution, or contact a GPayments specialist to discuss your ACS requirements.