What EMV 3DS Leaves Out of Scope

A standard is usually read as an answer sheet. If two products both implement it, the reasoning goes, they behave the same way, and the remaining differences are commercial.

EMV 3DS does not work like that, and the places where it does not are precisely the places where platforms differ most. A number of things people assume the specification defines are explicitly out of scope, left to each implementation. Approval confirms a product conforms to the specification. It cannot confirm anything about the decisions the specification never made.

This is a short tour of those gaps, because knowing where they are changes how you evaluate a vendor and where you should be asking harder questions.

How the ACS identifies a device

Device binding links a consumer device to a cardholder account, and the binding status then feeds the ACS risk assessment. It is one of the more valuable features available to an issuer.

The specification does not define how the ACS identifies the consumer device. That is outside the scope of the Core Specification, and the same applies where the Directory Server performs the identification.

This is the largest gap on the list. Two ACS platforms can both truthfully claim device binding support and deliver quite different outcomes, because the entire value of the feature rests on identification quality, and identification quality is unstandardised. A platform with weak device recognition produces bindings that fail to match on return visits, which looks to the issuer like a feature that does not work and to the cardholder like a bank that keeps forgetting them.

Ask how identification is performed, how it survives an operating system update or a cleared browser store, and how the platform distinguishes a genuinely returning device from one presenting similar characteristics.

How the SDK is verified as authentic

There is a requirement on the 3DS Server to ensure the 3DS SDK is authentic. How that is done, and who does what, depends on the integration model chosen for the components in the requestor environment, so the actual method of verifying authenticity is outside the scope of the Core Specification.

EMVCo describes one possible model, in which the 3DS Server outsources verification to the requestor, assuming it has a way to trust the requestor and the relationship between the requestor and the SDK. Other models are equally possible.

So the requirement exists and the mechanism does not. When a vendor says its SDK is authenticated, the useful follow-up is which model they use and what the trust actually rests on.

How a transaction is identified when something goes wrong

Error handling in the specification repeatedly conditions behaviour on whether a specific transaction can be identified. Which data elements are used to do that identification depends on the error situation and the implementation.

Sometimes one or more identification elements are recoverable. Sometimes an implementation-specific session identifier, created when the connection between two components is established, can be used instead, and that works even where the transaction identifiers in the messages are not recoverable. The Core Specification does not mandate a method.

The consequence for operations is direct. Two platforms facing the same malformed message can differ in whether they can attribute it to a transaction at all, and therefore in whether you get a diagnosable incident or an unexplained gap in your data.

How co-badged cards are routed

The specification allows issuers to enrol co-badged account ranges onto the Directory Server, and for the 3DS Server to obtain those ranges for authentication routing. Where a 3DS Server obtains multiple Directory Server URLs for the same account ranges, it can choose how to route the transaction.

How it chooses is not specified. The routing decision is implementation-specific, based on local market conditions.

For acquirers in co-badging markets this is a commercially material gap, because routing choice interacts with cost, with scheme relationships and with authentication outcomes. It is worth knowing whether your 3DS Server exposes that choice as configuration or makes it internally.

How delegated authentication is agreed

Delegated authentication requires an agreement between the merchant and the issuer or ACS, and the merchant must operate an authentication process meeting the issuer’s requirements.

How that agreement comes about sits outside the core specification. It is established through bilateral contracts or through services offered by payment systems.

This is why delegated authentication is not simply switched on. The protocol carries the evidence; it does not create the relationship that makes the evidence acceptable.

How out-of-band authentication is actually performed

Decoupled authentication allows an alternative method where a challenge is not possible, not available, or fails. The authentication method used is outside the scope of EMVCo’s guidance. Example approaches include a text message, an email, a phone call, or a push notification to a banking app that completes the authentication and sends the result to the ACS.

The protocol defines how the outcome is carried and how the flow behaves. What the cardholder actually does to prove who they are is the issuer’s design problem.

What this means for evaluation

Four things follow.

Approval answers a narrower question than people think. It confirms conformance to the specification. Every gap above is outside what conformance can speak to.

Feature parity lists are weak evidence. Where two platforms both tick device binding, the tick tells you they implement the data elements. It says nothing about the thing that determines whether the feature works.

The gaps are where the engineering is. These are not oversights. They are the areas EMVCo judged too implementation-dependent, too adversarial or too market-specific to standardise, which is another way of saying they are the hard parts.

Ask about the gaps specifically. Most vendor conversations cover the standardised surface, because that is what both sides can speak to confidently. The useful questions are the ones about the six areas above.

Frequently Asked Questions

Does EMVCo approval mean two products will behave the same way?

No. Approval confirms conformance to the specification. It cannot speak to behaviour in areas the specification leaves to the implementation, and several commercially important areas, including device identification and SDK authenticity verification, are explicitly out of scope.

Why would a standard deliberately leave things undefined?

Because some problems are too implementation-dependent, too adversarial or too market-specific to fix in a document with a multi-year revision cycle. Device identification is the clearest example: pinning a method in the specification would have dated quickly and constrained defences against an actively changing threat.

Which gap matters most when choosing an ACS?

Device identification, because the value of device binding depends entirely on it and it is completely unstandardised. Two platforms can both support the feature and deliver materially different results.

Is there a documented list of out-of-scope areas?

Not as a single list. The statements are distributed across the Core Specification, the white paper and EMVCo’s technical FAQs, which is part of why the gaps are easy to miss. This article gathers the ones with the clearest commercial consequences.

Evaluating a 3DS platform? GPayments provides 3DS Server, Access Control Server, SDK and testing components. Speak with a 3DS specialist about your evaluation criteria.