ACS Capacity Planning for Issuers Before Peak Trading

Black Friday falls on 27 November 2026 and Cyber Monday on 30 November. For card issuers, ACS capacity planning is the part of peak preparation that is easiest to get wrong, because the Access Control Server (ACS) is rarely the first thing to run out. The ACS answers every EMV 3D Secure (EMV 3DS) authentication request for the issuer’s card ranges, but it depends on services it does not control: the provider that sends one-time passcodes, the push service behind banking-app approvals, the risk engine, cryptographic hardware and the network path to each card scheme’s Directory Server. Plan capacity for each of those, not just for the ACS servers.

We covered merchant-side preparation in How to Prepare Your 3D Secure Authentication for Peak Trading. This article is the issuer counterpart.

What ACS capacity planning has to cover

An ACS does not handle one kind of request. In EMV 3DS it receives authentication requests (AReq) from the Directory Server and returns authentication responses (ARes). In browser flows it may also receive the 3DS Method call that collects browser data before authentication. When it decides to challenge, it runs the challenge exchange (CReq and CRes) with the cardholder’s browser or app, and it reports the final outcome to the Directory Server in a results request (RReq).

These requests cost very different amounts to serve. A frictionless authentication is one request and one risk decision. A challenge adds several round trips, a message to the cardholder and state that has to be held until the cardholder responds. A small rise in the share of transactions you challenge can therefore raise load more than a large rise in frictionless volume. Model the two separately.

Request type	What drives the cost	Capacity question
AReq / ARes	Risk evaluation, rule execution, generating the authentication value	Can the risk engine answer within your time budget at peak volume?
3DS Method (browser)	Receiving and storing browser data before the AReq arrives	Is the method endpoint sized for every browser transaction, not just challenged ones?
Challenge (CReq / CRes)	Rendering, holding session state, waiting for the cardholder	How many open challenge sessions can you hold at once?
Out-of-band and OTP delivery	Push notifications and SMS sends through third parties	What are your providers’ send limits and queue behaviour?
RReq / RRes	Reporting the challenge outcome to the Directory Server	Does a slow DS connection back up your challenge workers?

Where load concentrates during peak trading

Peak load is uneven. Volume tends to arrive in bursts when promotions open, and those bursts hit every issuer at once because they come from the same merchants. The hourly profile from last year’s peak is a better planning input than the daily total, because the daily total hides the minutes that matter.

Two less obvious sources of load also rise at peak. Card-testing attempts are harder to separate from genuine traffic when checkouts are busy, and any that reach your ACS consume risk evaluations and, if you challenge them, passcode sends to genuine cardholders. Rule changes add load too: tightening rules before peak raises the challenge share, which moves load onto the most expensive request type. If you plan to change rules, include the expected challenge share in the capacity model rather than treating rules and capacity as separate decisions.

Dependencies that run out before the ACS does

Most ACS incidents during peak trading start in a dependency. The table below lists the usual candidates and what to confirm with each owner.

Dependency	What happens when it saturates	What to confirm before peak
SMS passcode provider	Passcodes arrive late or not at all, challenges time out and cardholders abandon	Contracted send rate, burst limits, queueing behaviour, fallback route
Banking-app push service	Approval requests are delayed, so out-of-band challenges expire	Notification throughput, behaviour when the app is not running, fallback challenge method
Risk engine and fraud scoring	AReq responses slow down across all transactions, not just risky ones	Response time at peak load, what the ACS does if scoring times out
Cryptographic hardware	Authentication value generation and, in app flows, signed content queue up	Operations per second available, headroom, failover
Session and challenge state store	Open challenges cannot be resumed, so cardholders see errors	Maximum concurrent sessions, expiry handling
Connectivity to Directory Servers	Requests fail before reaching the ACS or results cannot be reported	Network capacity per scheme, certificate validity through the peak period

Certificate expiry deserves its own check. An expired certificate on a Directory Server connection stops authentication for that scheme regardless of how much capacity you have. Our guide to certificate and key management in EMV 3DS covers what to check.

How to build the capacity plan

Start from last year’s peak, by hour and by request type. Separate frictionless authentications, challenges by method and 3DS Method calls.
Project this year’s volume and challenge share. Use your own portfolio growth and the rules you expect to run in November, not industry averages.
Agree headroom with each dependency owner. Each provider in the table above needs a stated limit, and you need to know what happens when it is exceeded.
Load test the whole path. Test through to passcode delivery and push approval where your providers offer a test route. A test that stops at the ACS proves only that the ACS servers are sized.
Decide your degraded-mode behaviour in advance. If passcode delivery slows, will you switch method, extend timeouts within scheme rules or change risk rules? Write the decision down before the day.
Freeze changes. Agree a change freeze window around peak for the ACS, its rules and its dependencies, with an emergency route that names who can approve exceptions.
Staff the monitoring. Make sure someone is watching authentication outcomes, challenge completion and dependency latency in real time, with a route to the scheme if something fails.

What happens if the ACS is still overwhelmed

If an ACS stops responding, card schemes can answer authentication requests on the issuer’s behalf through Directory Server stand-in, under each scheme’s own rules. Stand-in keeps checkouts moving, but the issuer loses its own authentication decision for those transactions, and the outcome and liability treatment depend on the scheme. We explain the details in What Happens to 3DS When an Issuer’s ACS Is Unavailable. Stand-in is a safety net for an outage. It is not a capacity plan.

Reviewing ACS capacity planning after the peak

Capture the hourly data while it is fresh: request volumes by type, challenge completion by method, dependency latency and any time the ACS or a provider hit its limit. Compare it with your forecast so next year’s plan starts from what happened, not what you expected. Our article on what issuers should measure across 3D Secure authentication suggests which measures to keep.

Where ActiveAccess fits

ActiveAccess is GPayments’ Access Control Server for issuers and issuer processors. If you are reviewing how your ACS handles peak volumes, or planning a move to a different ACS deployment, speak with a 3DS specialist.

Frequently asked questions

When should issuers start ACS capacity planning for peak trading?

Start early enough to load test and fix what you find before your change freeze. The deciding factor is usually how long your dependency providers need to raise limits, so ask them first.

Does a higher challenge rate need more ACS capacity than higher volume?

Often, yes. A challenge involves more requests, a message to the cardholder and session state held until the cardholder responds, so each challenged transaction costs more to serve than a frictionless one.

Should issuers relax risk rules during peak to protect capacity?

Not as a capacity measure. Rules should reflect fraud risk. If capacity is the concern, fix the capacity. If you do change rules for peak, model the effect on challenge share before you deploy them.

Can a card-testing attack affect an issuer’s ACS during peak?

Yes, where the testing merchant uses 3DS. Each attempt that reaches the ACS uses a risk evaluation, and challenged attempts can send passcodes to genuine cardholders who did not start a purchase.

Who should be on the issuer’s peak-trading incident call?

The ACS operator, the risk and fraud team, whoever manages the passcode and push providers, the authorisation team and someone who can contact the card schemes. Agree the list and contact details before the peak.