← Payment Reference GuidesAuthentication Reference

3D Secure / EMV 3DS

The cardholder authentication protocol for card-not-present transactions. 3DS2 adds frictionless, decoupled, and challenge flows while enabling SCA compliance under PSD2 and reducing CNP fraud liability.

3DS Architecture

EMV 3DS defines three server-side components — the 3DS Server, Directory Server, and Access Control Server — that together form the authentication infrastructure across merchant, scheme, and issuer domains.

Merchant / 3DSS
Acquirer Domain
→
Directory Server
Scheme Domain
→
ACS
Issuer Domain
1

3DS Server (3DSS)

Merchant-side component. Responsible for:

  • Collecting browser/device fingerprinting data (user agent, screen size, color depth, timezone, Java enabled)
  • Compiling the Authentication Request (AReq) with 100+ data fields
  • Sending AReq to the Directory Server and receiving ARes
  • Managing the challenge window if ARes indicates challenge required
  • Receiving the final RReq (Results Request) with authentication outcome
2

Directory Server (DS)

Scheme-operated routing hub. Responsible for:

  • Validating card ranges — determines which ACS handles this card number
  • Routing the AReq to the correct ACS based on BIN
  • Managing 3DS protocol version negotiation
  • Validating digital signatures on AReq/ARes to prevent tampering
  • Does NOT store authentication data — pure routing function

Operators: Visa Verified / VPT, Mastercard Identity Check, Amex SafeKey, Discover ProtectBuy

3

Access Control Server (ACS)

Issuer-operated authentication engine. Responsible for:

  • Receiving AReq and applying the issuer's risk-scoring model
  • Deciding frictionless (Y/A) or challenge (C/D) outcome
  • Rendering the challenge UI (OTP, biometric, knowledge-based)
  • Generating the CAVV / authentication value on successful authentication
  • Sending the final RReq (Results Request) to the 3DSS after challenge