3-D Secure Authentication: What It Is, What Regulators Expect, and What Gets You Cited

What is 3-D Secure Authentication?

3-D Secure Authentication (3DS) is a payment security protocol that adds a real-time identity check between a cardholder, their issuing bank, and a merchant during an online card transaction. The "3 domains" refer to the acquirer domain (the merchant and their payment processor), the issuer domain (the cardholder's bank), and the interoperability domain (the card network, such as Visa or Mastercard).

Originally deployed as Verified by Visa and Mastercard SecureCode in the early 2000s, the protocol was rebuilt under EMVCo's 3DS 2.x specification to support mobile-native flows, richer data exchange, and risk-based authentication. Version 2.2 is the current operational standard for most major card schemes. Version 1.x was deprecated by Visa and Mastercard in October 2022 and should no longer appear in any compliant institution's payment stack.

The protocol works by passing a risk data bundle from the merchant to the issuer at checkout. The issuer evaluates that bundle, which can include device fingerprints, transaction history, and behavioral signals, and either authenticates the transaction silently (frictionless flow) or prompts the cardholder for a second factor. Challenge methods include one-time passwords, biometrics, and in-app push approvals.

For compliance teams, 3DS is both a fraud prevention control and an evidence-generating mechanism. Every 3DS transaction produces a structured authentication record: whether the transaction was challenged, what method was used, and how the issuer responded. That audit trail matters to examiners reviewing an institution's Strong Customer Authentication program.

Why is 3-D Secure Authentication required?

The primary regulatory driver in the EU is Article 97 of Payment Services Directive 2 (PSD2), which mandates Strong Customer Authentication for electronic payments. The European Banking Authority's Regulatory Technical Standards on SCA (Delegated Regulation 2018/389) require that authentication combine at least two of three factors: something the customer knows, something they have, and something they are. 3DS 2.x is the card industry's standard implementation of those requirements.

In the UK, the FCA adopted equivalent SCA rules in PS19/26, with full enforcement beginning March 2022. Banks that failed to implement 3DS for in-scope transactions by that date faced regulatory action. The FCA has been explicit that SCA is not a technical formality: it is a customer protection requirement with direct supervisory consequences for non-compliance.

PCI DSS v4.0, published by the PCI Security Standards Council in 2022 and required for compliance by March 2025, embeds authentication requirements throughout its framework. For card-not-present payment processing, 3DS is the standard-of-practice mechanism satisfying those authentication obligations.

The Financial Action Task Force's Guidance on Digital Identity (2020) identifies authentication as a core component of reliable identity verification. This connects 3DS to the broader compliance stack: a transaction authenticated via 3DS provides evidence of customer presence at the point of payment, complementing Customer Due Diligence (CDD) conducted at onboarding.

Carve-outs from the SCA requirement exist, including transaction risk analysis (TRA) exemptions, low-value transaction exemptions, and merchant-initiated transaction exemptions. Each carries its own documentation, governance, and fraud-rate monitoring burden. Institutions that treat exemptions as permanent defaults, rather than conditional permissions, consistently generate regulatory findings.

What do regulators expect to see?

When examiners review a 3DS compliance program, they're looking for documented, tested, and governed processes. These are the evidence categories that appear on exam checklists:

Policies and procedures. A written 3DS implementation policy covering scope (which transaction types, which card schemes, which channels), exemption usage, fallback handling when authentication is unavailable, and incident response. The policy must be dated, approved, and version-controlled. A policy that describes how 3DS should work is not sufficient without evidence of how the institution has actually configured it.

Configuration documentation. Evidence of how the issuer or acquirer has set up 3DS: which transaction categories route to frictionless flow, which trigger a challenge, what risk signals feed the authentication engine, and how thresholds are calibrated. This mirrors the governance expectation for Transaction Monitoring programs, where documented rule logic and calibration records are standard exam requirements.

Testing records. Pre-launch testing for scheme compliance via EMVCo certification, integration testing with acquirers and card networks, and regression testing when configuration changes are made. Examiners want dates, testers, outcomes, and sign-off from a responsible owner. Undocumented testing is treated the same as no testing.

Exemption governance. A log of which SCA exemptions the institution applies, the conditions triggering each, fraud rate monitoring against the permitted thresholds, and an identified reviewer. PSD2 allows TRA exemptions only while fraud rates stay below defined ceilings. If those rates breach the ceiling, the exemption must be suspended promptly. That suspension decision needs to be traceable.

Fraud performance data. Card-not-present fraud rates by channel, authentication success and failure rates, challenge abandonment rates, and chargeback ratios reviewed at a defined frequency, typically monthly at minimum.

Governance. Board or senior management sign-off on the 3DS program, periodic review of fraud metrics and exemption performance, and the program appearing in MLRO or Chief Risk Officer reporting. 3DS treated exclusively as an IT matter fails this test.

What does good 3-D Secure Authentication look like?

Best-practice 3DS implementation runs well ahead of minimum compliance. These are the indicators that internal auditors and second-line risk should look for:

1. EMVCo 3DS 2.2 or higher. Version 1 is deprecated. Any institution still routing transactions through 3DS 1.x is operating on an unsupported protocol and will fail scheme compliance checks. Migration to 2.x should be complete, documented, and signed off.

2. Rich data transmission. 3DS 2.x supports up to 150 data elements per authentication request. High-performing issuers send 80 or more data points: device fingerprint, behavioral signals, transaction history, location data. More data means higher frictionless authentication rates and fewer unnecessary step-up challenges that push customers to abandon checkout.

3. Dynamic risk-based authentication. The issuer's Access Control Server (ACS) should score each transaction in real time and route to frictionless or challenge based on that score. Programs that calibrate this engine only at launch and leave it static generate excessive friction for legitimate customers and miss emerging fraud patterns. The EBA's Opinion on SCA exemptions (EBA/Op/2022/02) is explicit that exemption usage requires continuous monitoring.

4. Documented exemption usage with fraud-rate governance. TRA exemptions require that the institution's card-not-present fraud rate stays below 0.13% for transactions up to €100, 0.06% up to €250, and 0.01% up to €500, per EBA RTS Article 18. Programs with automatic suspension logic and a named governance owner for exemption decisions score well with examiners.

5. Fallback and liability-shift awareness. When authentication is unavailable or fails, the institution needs a documented fallback procedure. Liability shift under scheme rules means that a 3DS-authenticated transaction generally shifts chargeback liability to the issuer. Legal and compliance teams must understand the liability consequences of each authentication outcome code.

6. Regular external testing. PCI DSS v4.0 Requirement 11 mandates penetration testing and vulnerability scanning. For 3DS-integrated systems, this should cover the ACS, the 3DS Server, and the Directory Server connection.

7. Integration with fraud detection. 3DS signals should feed the broader fraud stack. A transaction that authenticates successfully but generates anomalous signals in AI-Powered Fraud Detection systems warrants review, not automatic approval.

Sources: EBA Delegated Regulation 2018/389; EMVCo 3-D Secure Specification v2.2; PCI DSS v4.0, PCI Security Standards Council (2022).

Common audit findings and exam citations

Four patterns account for the bulk of 3DS-related citations.

Protocol version failures. Visa and Mastercard set October 2022 as the deadline to stop supporting 3DS 1.x. Institutions that missed the migration deadline, or that retained legacy 1.x flows for specific merchant integrations without documenting and time-bounding them, have faced scheme non-compliance findings. Examiners treat undocumented carve-outs as policy gaps, not reasonable exceptions.

Exemption threshold breaches. The TRA exemption under PSD2 Article 18 is conditional, not permanent. Regulators have cited institutions that continued applying TRA exemptions after their card-not-present fraud rates breached permitted ceilings. The EBA addressed this directly in its Q&A process (EBA Q&A 2019/2631): exceeding the fraud rate threshold and failing to suspend exemptions is a documented regulatory violation, not a judgment call. The fix is automatic suspension logic, not manual monitoring that can be overridden.

Inadequate challenge mechanisms. Institutions that defaulted to SMS one-time passwords as their sole challenge method have attracted criticism since regulators and security researchers flagged SIM-swap vulnerabilities. The FCA's post-2021 guidance noted that sole reliance on SMS without compensating controls is inadequate. Programs that offer app-based push authentication or biometrics as primary channels, with SMS as a fallback, are better positioned.

Absent governance documentation. Audit teams repeatedly find operational 3DS implementations with no board-level approval, no documented review cycle, and no named compliance owner. Where 3DS is treated as a payment technology product rather than a regulated compliance program, the governance trail is typically absent. This is a straightforward finding that requires policy, ownership, and periodic review evidence.

Failure to link authentication to fraud investigation. Where Authorized Push Payment Fraud or card-not-present fraud occurs on authenticated transactions, examiners expect institutions to investigate whether authentication was circumvented or misused. The absence of that feedback loop has appeared in supervisory letters from both the FCA and ECB-supervised national competent authorities.

Metrics and KPIs

A well-governed 3DS program tracks these metrics at minimum, reviewed on a monthly cadence:

Authentication rate. The percentage of eligible card-not-present transactions routed through 3DS. A drop here signals a merchant integration issue, a scheme connectivity problem, or a configuration change that inadvertently excluded transaction types.

Frictionless versus challenge split. In a well-tuned 3DS 2.x program, 85 to 95% of transactions should authenticate frictionlessly. Frictionless rates below 70% indicate the risk engine is over-flagging, adding unnecessary friction for legitimate customers and increasing abandonment.

Card-not-present fraud rate by channel. Tracked by transaction value and volume, segmented by exemption type. For TRA exemptions, this must stay within the thresholds in EBA RTS Article 18: below 0.13% for transactions up to €100, 0.06% up to €250, and 0.01% up to €500. Breaching a threshold without suspending the exemption is a direct regulatory violation.

Authentication decline rate. The percentage of transactions declined at the 3DS step. Rates above 5% warrant investigation. High declines can indicate issuer ACS misconfiguration, expired customer credentials, or active fraud targeting a specific merchant.

Chargeback ratio on authenticated transactions. Tracking chargebacks specifically on 3DS-authenticated transactions reveals whether authentication is being bypassed, manipulated, or exploited. A rising chargeback rate on authenticated flows is a signal that the authentication data is not feeding the fraud detection system effectively.

System availability. Scheme rules require near-100% uptime for ACS and 3DS Server components. Downtime events must be logged, root-caused, and reported. Availability falling below 99.9% per month should trigger a formal incident review.

Exemption utilisation by category. What share of transactions are processed under each exemption? This should be reviewed monthly by the payments compliance team and reported quarterly to senior governance. Unexplained shifts in exemption mix warrant investigation.

Step-up abandonment rate. The percentage of customers who abandon a transaction when presented with a challenge. High abandonment rates indicate friction problems, poor UX design, or customers who weren't enrolled in the required authentication method. Abandonment above 15% is a red flag worth escalating.

How 3-D Secure Authentication connects to other controls

3DS doesn't operate in isolation. It's one layer in a payment security and compliance stack, and its value depends on how well it connects to adjacent controls.

The tightest adjacency is Transaction Monitoring. Authentication outcomes, whether a transaction was challenged, completed in a normal timeframe, declined, or flagged, are behavioral signals that should feed into the monitoring system. A transaction that passes 3DS from an unrecognized device, in an unusual country, immediately after a password change, warrants a monitoring alert regardless of authentication outcome. Treating 3DS as a binary pass/fail gate misses the richer signal in the authentication metadata.

3DS also connects to Know Your Customer (KYC) through the identity layer. Authentication events on accounts with pending EDD reviews or recently changed mobile numbers should be correlated. Card networks share authentication metadata that compliance teams can use to check whether a customer's authentication behavior matches their onboarding profile.

Authorized Push Payment Fraud is a typology where 3DS helps and also falls short. For card-not-present fraud, 3DS is a strong line of defense. But APP fraud involves the real cardholder authenticating the payment themselves, typically under social engineering. 3DS passes legitimately while the transaction is fraudulent. Compliance teams should not treat a 3DS pass as evidence of a legitimate transaction.

Money Mule Networks also exploit authenticated cards. The signal is most useful when combined with behavioral analytics and Payment Gateway Security controls on receiving accounts. Authentication tells you the rightful cardholder was present; it doesn't tell you the cardholder is not a mule.

How FluxForce supports 3-D Secure Authentication

FluxForce's AI agents monitor authentication signals in real time, correlating 3DS outcomes with behavioral patterns, device history, and transaction context. Where authentication passes but surrounding signals are anomalous, the platform flags the event for review and captures the full evidence chain automatically. Audit-ready reports document authentication performance metrics, exemption usage, and governance trail without manual data extraction. For institutions looking to close the gap between authentication data and fraud detection, AI-Powered Fraud Detection and Payment Gateway Security capabilities integrate directly with existing 3DS infrastructure. Request a demo to see it in action.