How EMV 3DS Version Management Actually Works

Teams new to EMV 3DS usually assume there is a specification, that it has a version number, and that being on that version means being current. All three assumptions are wrong in ways that cause real planning failures.

There is a family of documents. They move on different cycles for different reasons. And a version number attached to one of them tells you very little about the others.

Understanding EMV 3DS version management is not academic. It determines what triggers a retest, what your vendor is actually promising when they quote a version, and why a component can be fully current on the protocol and simultaneously out of date on something that matters more.

What is actually published

EMVCo publishes a set of documents in support of EMV 3DS rather than a single specification. The Protocol and Core Functions Specification is the one people mean when they say the specification. Alongside it sit the SDK Specification, the SDK Device Information specification, the SDK Technical Guide, the Split-SDK Specification, the white paper, the approval administrative process, message samples, cryptographic worked samples, and a set of message extensions.

On top of those, EMVCo issues specification bulletins. These carry updates, clarifications, errata and key features for particular versions, and there are a great many of them. A bulletin is not optional reading: several bulletins introduce or modify behaviour that a plain reading of the base specification would not tell you about.

The design decision behind all of this

One bulletin explains the rest. Specification Bulletin 255 documents EMVCo’s version management approach, and its stated aim is to provide more independence between the specifications and the bulletins, and to remove the need to update every EMV 3DS specification or issue new bulletins whenever one document changes.

That bulletin also carries the live status of the Core Specification, the device information versions, and the list of message extensions. In practical terms it functions as the index of what is currently active, which makes it the single most useful document for anyone trying to establish where things stand.

The reason the independence matters is best shown by an example EMVCo gives itself. The device information update cycle is linked to operating system updates from Android and iOS, not to the EMV 3DS specification release cycle. Other examples include releasing or updating a message extension, or sunsetting testing support for a particular protocol version.

The version number that does not mean what it looks like

Here is the specific trap.

The device information version format used to indicate the EMV 3DS specification version number. EMVCo changed it to indicate the most recent data version number instead. The change reaffirms that the most recent data version is backwards compatible with previous specification versions.

So a device information version and a protocol version are different numbering systems describing different things, and aligning them is a mistake. If your internal documentation or your vendor conversations treat them as one, you will draw wrong conclusions about what is current.

There is an accompanying obligation on the issuing side. ACS providers are urged to support all announced data version numbers to help avoid step-up authentication, and the ACS must return the highest data version number it supports. EMVCo expects ACSs to upgrade as quickly as possible after a new device information version and bulletin are released.

That is the clearest single reason for issuers to treat device information updates as a standing maintenance obligation rather than an occasional project. Falling behind does not produce an outage. It produces challenges you did not need to issue.

Why mixed-version estates are normal

Because the documents move independently and counterparties upgrade on their own schedules, a mixed-version estate is the steady state rather than a transitional embarrassment.

The specification accommodates this in places. One example: in version 2.2.0 the elements carrying end protocol versions are only constrained as to data type and length, with no specific values defined, so it is acceptable for Directory Servers to set higher protocol versions as values and 3DS Servers must not respond in error. Another: with version 2.3.1, references to a fixed table of active protocol versions were replaced with references to the version management bulletin, precisely to allow flexibility as future versions are released.

Both are small technical details with the same message behind them. The protocol is designed to let different parties sit on different versions without breaking, and your implementation should be tolerant in the same way.

What this means for planning

Four practical consequences.

Track documents, not a version. Your inventory should record which version of the Core Specification, the SDK Specification and the device information each component implements, plus which bulletins apply. A single version number in a vendor contract does not capture this.

Expect at least one device information change a year. Operating systems release at least one major version annually, and the device information cycle follows them. Build a planned slot for it rather than treating each as an incident.

Use the version management bulletin as your reference point. It carries the current status of the core specification, the device information versions and the message extensions. Checking it periodically is a five-minute task that prevents most version confusion.

Distinguish protocol capability from feature availability. Being on a current protocol version does not mean a feature is available to you, because features also depend on what the counterparty’s component supports for a given card range, and on which message extensions are supported along the path.

Frequently Asked Questions

Does the device information version have to match our protocol version?

No. EMVCo changed the device information version format to indicate the data version number rather than the specification version, and the most recent data version is backwards compatible with previous specification versions. They are separate numbering systems.

How do we find out which versions are currently active?

Specification Bulletin 255 carries the status of the Core Specification, the device information versions and the list of message extensions. It exists precisely so that the active state can be found in one place rather than inferred from a set of documents.

Why do bulletins matter if we have the specification?

Because bulletins carry updates, clarifications, errata and key features for particular versions, and several introduce behaviour a plain reading of the base document would not reveal. Treating the base specification as complete is a common source of implementation gaps.

Is it a problem if a Directory Server reports a protocol version higher than ours?

No, and your 3DS Server must not respond in error. In version 2.2.0 the end protocol version elements are constrained only by data type and length, with no specific values defined, so higher values are acceptable. Version 2.3.1 replaced the fixed version table with a reference to the version management bulletin for the same reason.

Planning a version upgrade? GPayments supports acquiring and issuing 3DS deployments across mixed-version estates. Speak with a 3DS specialist about migration sequencing.