How to Choose an ACS for 3D Secure: An Enterprise Evaluation Guide

The Access Control Server (ACS) is the issuer’s central decision-making engine in the 3D Secure protocol. It determines whether a transaction authenticates frictionlessly or requires a cardholder challenge, which authentication method to present, and whether the result qualifies for liability shift. For issuing banks and processors, the choice of ACS provider is not a commodity software decision — it directly affects fraud rates, approval rates, cardholder experience, regulatory compliance, and scheme relationships.

The majority of card issuers rely on third-party ACS providers rather than building and certifying their own — EMVCo’s approved products list shows a concentrated market of fewer than 20 certified ACS vendors serving the global issuing ecosystem. That makes the vendor selection decision one of the most consequential infrastructure choices an issuing institution makes for its e-commerce payments stack. GPayments, which has developed ACS technology since 1999 and currently provides ActiveAccess to over 100 issuers across 33 countries, has distilled the evaluation criteria that matter most at enterprise scale into the framework below.

ACS Evaluation Framework

The criteria below are organised by operational impact. An ACS that scores well on certification but poorly on RBA flexibility will authenticate transactions compliantly but with excessive friction. An ACS with a strong risk engine but limited scheme coverage will leave gaps in your card portfolio. The framework is designed to be used as a weighted scorecard by evaluation teams.

1. EMVCo Approval and Card Scheme Certification

This is the non-negotiable baseline. The ACS must hold a current EMVCo Letter of Approval (LOA) for the protocol version you need — 2.2.0 at minimum and 2.3.1 for new implementations. Beyond EMVCo approval, the ACS must be individually certified by each card scheme your institution supports: Visa Secure, Mastercard Identity Check, American Express SafeKey, JCB J/Secure, Discover ProtectBuy, and any local or regional schemes (eftpos in Australia, RuPay in India, and MIR in Russia). Each scheme has its own certification cycle, and lapsed certification means transactions on that scheme cannot be authenticated.

Key question for vendors: Which specific card scheme certifications does your ACS currently hold, and when does each expire? 

2. PCI Compliance: 3DS and DSS

ACS environments require compliance with two separate PCI standards: PCI 3DS (the security standard specific to 3DS data environments, covering both baseline security and 3DS-specific requirements) and PCI DSS 4.0 (the broader data security standard). For hosted ACS providers, the provider should hold both certifications, removing the compliance burden from the issuer. For on-premise deployments, the issuer bears the certification responsibility. The distinction matters: PCI 3DS and PCI DSS are separate standards with separate assessment processes. 

3. Risk-Based Authentication Engine

The RBA engine is the single most important differentiator between ACS solutions at the operational level. It determines your frictionless authentication rate — the percentage of transactions that authenticate without any cardholder interaction. A well-tuned RBA engine processing rich data signals should achieve frictionless rates above 90% for well-known cardholders on recognised devices. A weak engine forces more transactions to be challenged, increasing friction, reducing approval rates, and degrading the cardholder experience.

Evaluate the RBA engine on four dimensions: data inputs (how many transaction, device, and behavioural signals it ingests from the 3DS Server’s authentication request); rule flexibility (whether issuers can create, test, simulate, and modify authentication rules without requiring vendor intervention or custom development); response latency (the engine must score transactions in milliseconds; latency above 2–3 seconds risks checkout timeout); and analytics visibility (dashboards showing frictionless rates, challenge rates, challenge completion rates, and fraud rates segmented by BIN, geography, merchant category, and device type).

4. Authentication Method Support

A modern ACS should support multiple challenge methods: SMS OTP, email OTP, push notification to the issuer’s mobile banking app, biometric authentication (fingerprint, facial recognition), out-of-band (OOB) authentication, and decoupled authentication (EMV 3DS 2.2+). EMV 3DS 2.3 also introduces support for Secure Payment Confirmation (SPC) using WebAuthn/FIDO credentials – a phishing-resistant authentication method that is the direction of travel for the protocol. 

5. Deployment Model Flexibility

Issuers have different infrastructure requirements based on regulatory constraints, data residency obligations, internal security policies, and operational maturity. The ACS should be available in at least two deployment models: hosted (SaaS), where the provider manages infrastructure, certifications, and upgrades; and on-premise, where the issuer deploys on its own infrastructure with full control. Some providers also offer hybrid models (hosted infrastructure with issuer-managed configuration) or client-hosted options (the issuer’s cloud, managed by the provider). Evaluate whether the vendor charges differently across models and what the migration path looks like if you need to change.

6. Multi-Tenancy and Processor Support

If you are an issuer, processor or programme manager serving multiple issuing institutions, the ACS must support multi-tenancy: logically distinct entities with separate configurations, branding, authentication rules, and reporting — managed either individually or as a group. Without native multi-tenancy, processors must deploy separate ACS instances per issuer, which multiplies infrastructure and compliance costs. Evaluate whether the ACS administration portal supports role-based access with granular permissions for different issuer administrators.

7. Testing Infrastructure

Before going live, issuers need to validate their ACS configuration against realistic transaction scenarios — not basic simulators. The evaluation should ask whether the vendor provides a test environment with fully developed 3DS Server and Directory Server components, not just ACS-side test stubs. End-to-end testing across the full 3DS flow (3DS Server → Directory Server → ACS → challenge → result) is essential for identifying integration issues that unit testing misses. GPayments’ TestLabs provides exactly this: a full-stack test environment with certified 3DS Server, Directory Server, and ACS components.

8. Vendor Independence and Full-Stack Capability

Most ACS vendors are single-component providers — they supply the ACS only, and the issuer sources the 3DS Server, Directory Server, and SDK from other vendors. This creates integration complexity and multi-vendor coordination overhead. A smaller number of providers offer a full-stack 3DS capability: ACS, 3DS Server, mobile SDK, and testing infrastructure from a single vendor, with integrated support and a shared certification timeline.

Full-stack capability matters most for processors and large issuers who also operate on the acquiring side. GPayments is one of the few providers that offers both ActiveAccess (ACS) and ActiveServer (3DS Server), along with ActiveSDK (mobile SDK) and TestLabs — covering both the issuing and acquiring domains of 3D Secure from a single vendor. This reduces integration risk, simplifies certification management, and provides a single point of accountability. 

9. Regulatory Readiness

In regulated markets (EEA under PSD2/PSR, UK under FCA PS20/6), the ACS must support SCA-compliant authentication, TRA exemption handling, and trusted beneficiary whitelisting. With PSD3 and the Payment Services Regulation (PSR) agreed in November 2025 and enforcement expected from late 2026, evaluate whether the vendor is tracking the regulatory timeline and has a roadmap for PSR compliance. In Australia, the ACS should support AusPayNet’s CNP Fraud Mitigation Framework requirements. Ask vendors how they handle multi-jurisdictional compliance when the issuer operates across multiple regulatory regimes. 

 

Evaluation Criteria Summary

Criterion	What to Verify
EMVCo Approval	Current LOA for 2.2.0 or 2.3.1; verify on the EMVCO.com approved products list
Card Scheme Certifications	Individual certifications per scheme; confirm expiry dates and renewal status
PCI 3DS + PCI DSS 4.0	Both standards; confirm whether provider or issuer bears the certification burden
RBA Engine	Data inputs, rule flexibility (self-service?), latency, analytics dashboards
Authentication Methods	OTP, push, biometric, OOB, decoupled, SPC/FIDO roadmap
Deployment Models	Hosted, on-premise, hybrid; migration path between models
Multi-Tenancy	Separate configs per issuer; role-based admin; group management
Testing Infrastructure	Full-stack test environment (3DS Server + DS + ACS); not just simulators
Full-Stack Capability	ACS + 3DS Server + SDK + testing from one vendor; single certification timeline
Regulatory Readiness	PSD2/PSR, FCA PS20/6, AusPayNet; multi-jurisdictional compliance support

 

Frequently Asked Questions

What is an Access Control Server (ACS) in 3D Secure?

An Access Control Server (ACS) is the issuer-side component of the 3D Secure protocol. It receives authentication requests from the 3DS Server (via the Directory Server), evaluates transaction risk using the issuer’s fraud models and cardholder data, and determines whether to approve the transaction frictionlessly or present a challenge to the cardholder. The ACS is responsible for risk-based authentication, challenge method selection (OTP, biometric, push notification), liability shift signalling, and SCA compliance in regulated markets.

What certifications should an ACS have?

At minimum, an ACS should hold EMVCo 3DS approval (confirming compliance with the EMV 3DS specification) and PCI 3DS certification (confirming the security of the 3DS data environment). Beyond these, the ACS must be individually certified by each card scheme the issuer supports — Visa Secure, Mastercard Identity Check, Amex SafeKey, JCB J/Secure, Discover ProtectBuy, and any local or regional schemes. PCI DSS 4.0 compliance is also required for hosted ACS providers. Each certification has its own renewal cycle, so issuers should confirm that their ACS provider maintains current certifications across all applicable schemes.

Should I choose a hosted or on-premise ACS?

The choice depends on your institution’s regulatory constraints, internal infrastructure capabilities, and operational preferences. A hosted (SaaS) ACS reduces the burden of PCI certification, card scheme compliance, infrastructure management, and version upgrades — the provider handles these. On-premise deployment gives the issuer full control over data residency, customisation, and integration with internal systems but requires dedicated teams for maintenance, certification, and upgrades. Some providers offer both models, and hybrid approaches (hosted infrastructure with issuer-managed configuration) are increasingly common.

What authentication methods should a modern ACS support?

A modern ACS should support multiple authentication methods, including one-time passwords (SMS and email), push notifications to the issuer’s mobile banking app, biometric authentication (fingerprint and facial recognition), device-based cryptographic authentication, out-of-band (OOB) authentication, and decoupled authentication flows. EMV 3DS 2.3 also introduces support for Secure Payment Confirmation (SPC) using WebAuthn/FIDO credentials, which provides phishing-resistant authentication. The ACS should allow issuers to configure authentication method selection rules based on risk level, transaction value, and cardholder device capabilities.

How do I evaluate the risk-based authentication (RBA) capabilities of an ACS?

Evaluate the RBA engine on four dimensions: data inputs (how many transaction, device, and behavioural signals it can ingest), rule flexibility (whether issuers can create, test, and modify rules without vendor intervention); response latency (the engine must score transactions in milliseconds to avoid checkout timeout); and analytics visibility (whether the ACS provides dashboards showing frictionless rates, challenge rates, challenge completion rates, and fraud rates by BIN range, geography, and merchant category). A capable RBA engine is the single biggest driver of frictionless authentication rates, which directly impact cardholder experience and issuer approval rates.

How does GPayments’ ActiveAccess compare as an ACS solution?

GPayments’ ActiveAccess is an EMVCo-certified ACS supporting all major global card schemes, available as a hosted service or for on-premise deployment. ActiveAccess 20X, released in March 2025, is built on a pure Java implementation with no database-specific dependencies or external web server requirements, simplifying deployment and reducing security surface area. It includes a built-in RBA engine with configurable rules, adapter-based APIs for third-party RBA integration, multi-tenancy for processor environments, cardholder whitelisting, decoupled authentication, and OOB support. GPayments also provides ActiveServer (3DS Server) and TestLabs, making it one of the few providers offering both sides of the 3DS protocol plus end-to-end testing infrastructure.

Making the Decision

Choosing an ACS is an infrastructure decision with a long operational tail. The certification cycles, card scheme relationships, integration dependencies, and cardholder experience implications mean that switching ACS providers is expensive and disruptive. Getting the evaluation right the first time matters more than finding the cheapest option.

The practical next step is to assemble your evaluation team (payments architecture, information security, compliance, and procurement), weight the nine criteria above based on your institution’s priorities; and issue a structured RFI to your shortlisted vendors. Ask for specific, verifiable evidence against each criterion — certification numbers, latency benchmarks, client references in your region, and a live demonstration of the RBA rule builder and analytics dashboard.

 

Evaluating ACS Providers? GPayments’ ActiveAccess is an EMVCo-certified ACS used by over 100 issuers globally, available as a hosted service or on-premise. We also provide ActiveServer (3DS Server), ActiveSDK, and TestLabs — one of the few full-stack 3DS providers in the market. Request a technical demonstration or evaluation pack. Contact our team: gpayments.com/contact