EMV credential authentication and EMV 3DS device-data scope

1. EMV at the rail

EMV’s credential-authentication primitive is the Authorization Request Cryptogram (ARQC), specified in EMV Book 2 [1] (Security and Key Management) and applied through the application protocol described in Book 3 [2]. On contact and contactless card-present transactions the ARQC is generated by the chip. On tokenised mobile flows the cryptogram is generated using a network-issued Limited-Use Key (LUK) — a tokenisation construct issued by the Token Service Provider (Visa VTS, Mastercard MDES). Where the LUK is held depends on the device and wallet: Apple Pay binds it to the per-device Secure Element holding the device account number (DPAN); on Android, Google Pay holds the LUK under Host Card Emulation, and the underlying key material may be backed by StrongBox / TEE-backed Keystore on devices that expose a hardware-backed signer, or by software-backed Keystore on devices that do not. The cryptogram is computed over a defined set of inputs supplied through the protocol — driven by the card’s CDOL1 (Card Data Object List 1) — including the amount, currency, transaction date, unpredictable number, application transaction counter, terminal verification results, and the additional fields the card-issuer profile specifies.

The cryptogram is verified by the issuer using a key shared with the card or the tokenisation service. When the issuer accepts the ARQC, two assertions are settled at the rail layer:

• The credential is genuine — it was produced by the chip or secure element bound to the registered card or token.
• The transaction inputs supplied through the protocol have not been altered between the chip and the issuer.

EMV at the rail is exactly this. It is robust, well-understood, and the foundation of card-present and tokenised card-not-present payments at scheme scale.

2. EMV 3DS at authentication initiation

EMV 3DS 2.x extends the rail-layer story to remote-channel transactions [3]. The protocol introduces a second boundary, earlier in the flow: at authentication initiation — the moment the cardholder begins a remote transaction — the 3DS SDK (in an app context) or the browser (in a web context) collects a structured set of device-environment fields and forwards them to the issuer’s Access Control Server (ACS).

The collected data is defined in the 3DS specification [3, Annex A] and the SDK Technical Specification [4]. The fields cover browser characteristics, SDK-collected device attributes, network environment, transaction context, and (where applicable) cardholder metadata. The ACS evaluates the data against the issuer’s risk policy and decides among the standardised flow outcomes: frictionless (proceed without challenge), challenge (require cardholder verification), or decline.

The 3DS data is descriptive. It is collected once at initiation, forwarded to the ACS, and evaluated there. It is not a runtime trajectory; it is a snapshot.

3. How the two boundaries compose

The two EMV-family boundaries cover distinct scopes:

Dimension	EMV (rail)	EMV 3DS 2.x
When	At authorisation, on every transaction	Once, at authentication initiation
What is signed	Credential authenticity + the CDOL1-included transaction inputs (cryptogram by issuer-shared key)	No on-device transaction-body cryptogram; AReq integrity-protected in transit between SDK / browser, Directory Server, and ACS; CAVV is generated by the ACS post-challenge
Who verifies	Issuer	Issuer’s ACS (then optionally the issuer’s authorisation system)
Failure mode	Decline at rail; chargeback path follows	Step-up to challenge or decline at auth-init

Together, the two answer the rail-layer question — can this credential authorise this transaction? — and the authentication-initiation question — does the cardholder’s device environment look as expected? They are designed to compose: the descriptive 3DS snapshot informs the issuer’s risk decision before the ARQC is ever generated.

4. The boundary the EMV family does not draw

Both EMV and EMV 3DS draw their boundaries explicitly. Neither covers the device-side execution flow that produced the inputs to either boundary:

• The PAN entered, the amount confirmed in the UI, the consent acquired — these are events on the device, before the chip generates an ARQC and before the 3DS SDK collects its snapshot.
• The runtime trajectory between 3DS data collection and the ARQC submission — the assembly of the payload, any retry, the network swap — is not part of either standard.

This is not a deficiency of EMV. The architecture decided long ago that the rail signs the credential; that decision is correct, and the EMV family discharges it well. EMV 3DS adds the authentication-initiation snapshot for remote channels because the rail-only model does not give the issuer a view into the remote-channel device. The remaining boundary — the device-side runtime flow — is the layer Execution Evidence Infrastructure (EEI) — the device-identity infrastructure layer for banking and payments — is designed to sign, alongside the existing EMV layers, not in place of them. The relationship is documented at /architecture/runtime-coherence#emv-3ds-and-eei--where-one-stops-and-the-other-begins.

5. Cross-references

• Sibling articles in this theme: play-integrity, fido2-and-passkeys, hardware-attestation
• Theme 1: the-emv-execution-gap, the-sca-settlement-gap
• Architecture: /architecture/runtime-coherence
• Glossary: /glossary — Evidence Token, Trusted Runtime Primitive

6. External references

[1] EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems, Book 2 — Security and Key Management, v4.4. www.emvco.com/specifications/. Cited 2025-11-12.

[2] EMVCo. EMV Integrated Circuit Card Specifications for Payment Systems, Book 3 — Application Specification, v4.4. www.emvco.com/specifications/. Cited 2025-11-12.

[3] EMVCo. EMV 3-D Secure Protocol and Core Functions Specification, v2.3.1. www.emvco.com/specifications/. Cited 2025-11-12.

[4] EMVCo. EMV 3-D Secure SDK Technical Specification, v2.3.1. www.emvco.com/specifications/. Cited 2025-11-12.