EMV 3DS 2.3.1: ACS Readiness Guide for Issuers

Preparing for EMV 3DS 2.3.x requires more than enabling a new message version. Issuers should assess ACS protocol support, authentication capabilities, integrations, infrastructure, operational controls, testing and rollout governance as one connected readiness programme.

That matters because the ACS is only one component inside a larger authentication environment. A specification change can affect risk engines, authentication services, issuer applications, testing requirements and day-to-day operating procedures.

EMVCo describes EMV 3DS as a common set of requirements for card-not-present authentication, and the 2.3 generation extends the protocol with additional data and flows. For issuer teams, the practical question is not only what changed in the specification, but whether the wider authentication environment is ready to support those changes reliably. For the feature-level overview, see what is new with EMV 3DS 2.3.

Start with the ACS, then work outward

The most effective readiness review starts with the ACS and then maps every connected dependency. A platform may technically support a new protocol version while a risk service, mobile experience, operational process or test environment is not yet ready.

If you need a GPayments-specific overview of the protocol evolution first, read our article on EMV 3DS 2.3.1 enhancements. The steps below focus on what issuer teams should do next.

Confirm ACS protocol and card scheme readiness

Start by establishing exactly what the ACS supports today. The issuer should know which EMV 3DS versions are supported, which card schemes are relevant to its portfolio and what certification or approval applies to the planned environment.

Useful questions include:

Which EMV 3DS versions does the ACS support today?
Which card schemes are supported in the issuer’s target markets?
What is the upgrade path when specification or scheme requirements change?
What approval, certification or testing is required for the planned environment?
Does the change affect interfaces, data fields, configuration or operating procedures?

EMVCo’s 3DS approval process covers the compliance testing and approval path for 3DS products such as the ACS. Issuers should still confirm the implementation requirements that apply to their own card schemes and markets.

Review authentication capabilities

A protocol update can expand the authentication scenarios available to issuers. The readiness review should therefore include the methods and decisioning capabilities connected to the ACS.

Depending on the issuer’s strategy, this may include risk-based authentication, one-time passcodes, out-of-band authentication, decoupled authentication and newer authentication approaches such as FIDO-based experiences or Secure Payment Confirmation where supported.

For a closer look at passwordless payment authentication, see our guide to Secure Payment Confirmation for issuers. The key question is not whether every method must be used. It is whether the ACS and connected services can support the authentication strategy the issuer intends to operate.

Map integration dependencies

The ACS rarely operates alone. Before introducing a new protocol version, map the systems and services that participate in authentication or consume authentication information.

Dependencies may include:

risk engines and third-party RBA services
out-of-band authentication services
OTP delivery services
mobile banking or issuer applications
HSM or key management infrastructure
cardholder and card management systems
APIs used by operations, reporting or downstream platforms

For each dependency, confirm whether new data, flows or behaviours need to be supported and whether regression testing is required.

Assess infrastructure readiness

Protocol readiness can expose wider platform issues. If an ACS upgrade also requires attention to an ageing runtime, application server, database dependency or deployment process, it can be useful to address those concerns as part of the same programme.

Infrastructure teams should consider the runtime lifecycle, deployment model, database strategy, high availability, configuration management and the organisation’s current approach to CI/CD and containerisation.

The objective is not to modernise infrastructure simply because a new specification exists. It is to make sure the authentication platform remains maintainable and supportable as protocol change continues.

Prepare operations and administration

A 3DS upgrade changes more than technical processing. Operational teams need to understand what they own, what can be configured, how issues will be investigated and how changes will be governed.

Review areas such as:

authentication and issuer configuration ownership
challenge experience management
reporting and dashboard access
security and access controls
change approval procedures
support escalation paths
documentation and operational runbooks

Where new authentication flows are introduced, operations and support teams should also understand what the cardholder may experience and how that behaviour appears in reporting.

Plan testing beyond the happy path

Testing should cover more than a successful authentication request. A 2.3.x readiness programme should validate the scenarios the issuer expects to support across the relevant schemes and channels.

A practical test plan may include:

protocol and message-level processing
frictionless and challenge flows
browser and app channels
3RI scenarios where applicable
risk and authentication integrations
error and exception handling
challenge content and cardholder journeys
reporting and operational visibility
regression testing for established 2.1 and 2.2 environments that remain in scope

A dedicated 3D Secure test environment can help teams validate these scenarios before production. GPayments TestLabs provides live 3DS components and configurable scenarios for connectivity, implementation and ongoing testing.

Questions to take to your ACS provider

Before finalising a 2.3.x plan, issuer teams should be able to answer the following questions with their ACS provider:

What versions and applicable card scheme requirements are supported?
What certification or approval applies to the ACS?
What changes are required in our integrations?
Which authentication methods and flows are available?
Does the change affect deployment or infrastructure?
How are challenge experiences and operational configuration managed?
What reporting is available to validate behaviour after rollout?
What test environments and test cases are available?
What is the production rollout and rollback approach?
How will future EMV 3DS and scheme changes be handled?

How ActiveAccess supports evolving 3D Secure environments

ActiveAccess is GPayments’ ACS for issuer-side 3D Secure authentication. The platform is designed around current EMV 3DS and applicable card scheme requirements, with a modernised architecture and administration environment intended to support continued protocol evolution.

ActiveAccess combines current specification support with configurable authentication capabilities, issuer administration, challenge experience management and interactive visibility into authentication activity.

For teams planning or validating 3DS change, TestLabs supports the testing side of the programme, while ActiveAccess provides the issuer-side ACS environment.

The most effective 2.3.x programmes treat readiness as an end-to-end issue. Protocol support is the starting point. Integration, operations, testing and governance are what turn that support into a production-ready authentication environment.

Frequently asked questions

What is EMV 3DS 2.3.1?

EMV 3DS 2.3.1 is part of the 2.3 generation of the EMV 3-D Secure specification. It builds on earlier versions with additional data and flows intended to support evolving card-not-present authentication use cases.

Does an issuer need a 2.3.x-ready ACS?

Issuers should ensure their ACS supports the EMV 3DS versions and card scheme requirements relevant to their portfolios. The exact implementation plan should be confirmed against the requirements that apply to the issuer’s markets and schemes.

What should be tested when moving to 3DS 2.3.x?

Testing should cover protocol processing, authentication flows, channels, integrations, errors, reporting, challenge experiences and regression scenarios that remain relevant to the issuer.

How does 2.3.x affect issuer authentication?

The 2.3 generation extends the data and flows available within EMV 3DS. Issuers should assess how those capabilities interact with their ACS, authentication methods, risk services, operations and testing.

Explore ActiveAccess for issuer-side 3D Secure authentication, or use TestLabs to support 3DS testing and readiness.