What the Directory Server Does in EMV 3DS

Diagrams of EMV 3D Secure usually show three boxes and two arrows. The merchant’s 3DS Server on one side, the issuer’s Access Control Server on the other, and something in the middle labelled Directory Server that everyone nods at and nobody explains.

That middle box is worth understanding properly, for one reason above all others. It is the only major component in the flow that neither you nor your counterparty operates. It is run by the card scheme. Everything it does is a constraint on your architecture rather than a choice within it.

What it actually does

The Directory Server sits in the interoperability domain and performs several distinct jobs that tend to get collapsed into the word routing.

It distributes card range data. The 3DS Server obtains, from the Directory Server, the card range data indicating the most recent protocol versions supported by the ACS for each range, optionally the Directory Server hosting that range, and where configured the ACS URL used for browser-channel data collection. That same data carries the ACS Information Indicator describing which features the ACS supports, and the message extensions it supports.

It decrypts device data. In app-based flows, the 3DS SDK encrypts the device information using the Directory Server public key. The 3DS Server forwards that payload without being able to read it. The Directory Server decrypts it and passes the device information on to the ACS.

It can verify authentication evidence. Where delegated authentication is used, the Directory Server may perform signature verification on the mechanism the cardholder used to authenticate at the merchant, and populates an element telling the ACS whether that verification was performed and whether it passed.

It can hold shared state. Both the trust list and device binding can optionally be managed at the Directory Server rather than at the ACS or the requestor, under an agreement with the ACS. In those models the DS maintains the status, can modify the authentication request on the way through, and reports status back to the acquiring side.

That last one surprises people. The Directory Server is not always a passive relay. In some configurations it is an active participant that changes the content of messages passing through it.

The part that matters for your architecture

Here is the framing worth taking away.

You do not run the Directory Server. You cannot configure it, monitor it in the way you monitor your own components, or change how it behaves. Its availability, its latency, and its version support are inputs to your system that you receive rather than decisions you make.

Three practical consequences follow.

Your latency budget is not entirely yours. Every authentication involves at least one round trip through a component you do not operate. When you set timeout values, you are setting them around a segment whose performance you can measure but not improve.

Your capability picture comes from somebody else’s data. Everything you know about what an issuer’s ACS supports arrives through the Directory Server as card range data. If that data is stale in your cache, your view of the world is wrong, and the failure will look like issuer behaviour rather than a caching problem.

Your version options are bounded per range. The protocol versions available for a given card range are supplied to you. You do not negotiate them transaction by transaction. This is why a mixed-version estate is a fact to be managed rather than a problem to be solved by upgrading your own components.

One Directory Server per scheme, not one for the ecosystem

A misconception worth clearing up early, because it shapes how teams think about testing and key management.

There is no single Directory Server. Each card scheme operates its own, which means the behaviours you rely on are scheme behaviours rather than protocol behaviours. Where two schemes handle something differently, that difference is real and your implementation has to accommodate it rather than assume a common answer.

This shows up concretely in key management. The Directory Server public key used to protect app-based device data must be obtained from each supported network. That process is governed by each network’s own programme rules and requires a valid EMVCo Letter of Approval. Supporting an additional scheme is not a configuration change. It is a separate approval and a separate key.

It shows up in testing too. Validating against one scheme’s environment tells you about that scheme. It does not tell you how another will behave.

What the Directory Server is not

Two confusions worth naming plainly, because both lead to real design errors.

It is NOT a payment gateway. The Directory Server carries authentication messages. It does not carry authorisation. Authentication and authorisation are separate processes running over separate infrastructure, and a successful authentication is not an approved payment. Teams that blur this end up building reporting that cannot explain why an authenticated transaction was declined.

It is NOT a fraud engine. The Directory Server does not decide whether a transaction is risky. Risk assessment happens at the ACS, using issuer policy and issuer data. The Directory Server’s job is to get the right information to the right ACS in a form it can use.

Where it fits against the other components

A simple way to hold the four roles in mind.

The 3DS Server sits on the acquiring side. It builds authentication requests, holds card range data, and interprets what comes back.

The 3DS SDK sits inside a merchant’s mobile app and collects device data natively for app-based flows.

The Directory Server sits between the domains, operated by the scheme. It distributes capability information, decrypts device data, routes messages and in some configurations holds shared state.

The Access Control Server sits on the issuing side. It performs risk assessment, decides whether to challenge, runs the challenge, and produces the authentication result.

The boundary that matters most is the one around the Directory Server, because it marks where your control ends and the scheme’s begins.

What to do with this

If you are designing or reviewing a 3DS implementation, three questions follow from the above and are worth asking early.

Where are our timeouts set, and do they reflect a segment we cannot optimise? Do we refresh card range data on a cadence we can evidence, and would we notice if it stopped? And which of our assumptions about behaviour are actually protocol behaviours, as opposed to the behaviour of the one scheme we happened to test against first?

None of those questions is difficult. They are just easy to skip when the middle box on the diagram never gets explained.

Frequently Asked Questions

Is there one Directory Server for the whole ecosystem?

No. Each card scheme operates its own, which means behaviours you rely on are scheme behaviours rather than protocol behaviours. This shows up concretely in key management, since the public key protecting app-based device data must be obtained from each supported network under that network’s own programme rules.

How should a 3DS Server route a co-badged card?

The specification allows issuers to enrol co-badged account ranges onto the Directory Server, and the 3DS Server obtains 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 Core Specification does not specify how, so the choice is implementation-specific and based on local market conditions.

Can the Directory Server respond on behalf of the ACS?

Yes, in defined circumstances. Where the Directory Server creates the authentication response on the ACS’s behalf, for example when returning an attempted-authentication outcome, it sets the ACS reference number equal to the Directory Server reference number and the ACS transaction ID equal to the Directory Server transaction ID. Version 2.3.1 and higher handle this through specific requirements.

Does the Directory Server assess fraud risk?

No. Risk assessment happens at the ACS using issuer policy and issuer data. The Directory Server’s job is to get the right information to the right ACS in a form it can use, and in some configurations to hold shared state such as a trust list or device binding record.

Designing a 3DS architecture? GPayments provides 3DS Server, Access Control Server, SDK and testing components. Speak with a 3DS specialist about your deployment.