Category: 3-D Secure

Authentication Request (AReq)

Also known as: AReq, Authentication Request Message

Simply put

An Authentication Request (AReq) is the first message sent in an EMV 3-D Secure transaction to ask the card issuer to authenticate the cardholder. It carries information about the transaction and the device being used so the issuer can judge how risky the transaction may be and decide how to handle it. It is part of the 3-D Secure authentication process and is separate from the payment authorization that happens over the card network.

Formal definition

In EMV 3-D Secure, the AReq is the initial authentication message in the authentication flow, typically originated by the 3DS Server toward the issuer's Access Control Server (ACS). It conveys transaction, cardholder, and device/browser data elements used by the ACS to assess risk and determine the appropriate authentication approach, which may result in a frictionless outcome or a challenge. The ACS returns its response in the corresponding Authentication Response (ARes). The AReq belongs to the EMVCo 3-D Secure specification and the PCI 3DS domain and should not be conflated with authorization, clearing, or settlement messages carried over the card network; 3-D Secure authentication is intended to help assess transaction risk and reduce card-not-present fraud but does not by itself guarantee prevention of fraud, and specific data elements and behavior vary by protocol version and implementation, which should be confirmed against the applicable EMVCo specification.

Why it matters

The Authentication Request is the message that opens an EMV 3-D Secure authentication flow, making it the point at which transaction, cardholder, and device or browser data are first passed to the issuer for a risk assessment. Because the quality and completeness of the data carried in the AReq directly influence how the issuer's Access Control Server evaluates risk, it plays a central role in whether a transaction proceeds without friction or triggers a challenge. Richer device data assists the ACS in assessing transaction risk, which is why the AReq is often the focus of data enrichment efforts by merchants and 3DS Servers.

For card-not-present transactions, the AReq is where authentication is requested before the separate payment authorization occurs over the card network. It is important to keep these two flows distinct: 3-D Secure authentication, initiated by the AReq, is intended to help assess transaction risk and reduce card-not-present fraud, but it does not by itself guarantee prevention of fraud. Treating a successful authentication as an absolute guarantee overstates what the mechanism provides, since risk assessment involves trade-offs and the behavior of the flow depends on the data supplied and the issuer's decisioning.

Because specific data elements and behaviors vary by protocol version and implementation, teams should confirm the exact fields and expected behavior against the applicable EMVCo 3-D Secure specification rather than assuming a fixed structure. Version negotiation matters as well, since a 3DS Server may initiate a request with a preferred version and fall back if that version is not supported by other 3-D Secure components.

Who it's relevant to

3DS Server operators and integrators

Teams building or operating a 3DS Server construct and send the AReq toward the issuer's ACS. They must understand which transaction, cardholder, and device or browser data elements to include, how version preference and fallback behave when a preferred protocol version is not supported by other components, and how the AReq relates to the ARes response. Exact fields vary by protocol version, so these should be confirmed against the applicable EMVCo specification.

Fraud analysts and merchant risk teams

Because richer device data in the AReq assists the ACS in assessing transaction risk, fraud and risk teams have an interest in data enrichment to improve the quality of information shared with the issuer. They should treat 3-D Secure authentication as a control intended to help reduce card-not-present fraud rather than one that guarantees prevention, and weigh the trade-offs between frictionless outcomes and challenges.

Issuers and ACS operators

Issuers receive the AReq at their Access Control Server and use its data elements to determine the appropriate authentication approach, including whether to permit a frictionless flow or issue a challenge, returning the decision in the ARes. Their decisioning logic depends on the data conveyed and the protocol version in use.

Compliance officers working within PCI 3DS

The AReq belongs to the EMVCo 3-D Secure specification and the PCI 3DS domain and should not be conflated with authorization, clearing, or settlement messages carried over the card network. Compliance staff should keep the authentication flow distinct from the payment authorization flow and confirm implementation details against the applicable EMVCo specification and relevant PCI 3DS requirements.

Inside AReq

Cardholder and Card Data Elements

The AReq carries data used by the issuer's Access Control Server (ACS) to assess the transaction, which may include a PAN or a payment token, expiration date, and cardholder account information. This data must be transmitted and handled under the protections defined by PCI DSS and, where applicable, PCI 3DS, and the message is subject to secure transmission controls.

Merchant and Transaction Context

Includes merchant identifiers, transaction amount, currency, and purchase details that the 3-D Secure flow uses to give the issuer context for its risk-based decision. This context supports the issuer's determination of whether to complete a frictionless authentication or invoke a challenge.

Device and Browser/App Data

Device channel information such as browser or app data and device parameters that support risk-based (frictionless) analysis. The specific fields and their formatting are defined by the EMV 3-D Secure specification and the PCI 3DS standard governs the security of the environment that processes them.

Message Routing Identifiers

Identifiers used to route the message between the 3DS Server, Directory Server (DS), and Access Control Server (ACS) so that the request reaches the correct issuer domain and the response (ARes) can be correlated back to the originating request.

Common questions

Answers to the questions practitioners most commonly ask about AReq.

Does an Authentication Request (AReq) mean the transaction has been authorized?

No. The AReq is a 3-D Secure message exchanged during the authentication phase of a card-not-present transaction and is separate from payment authorization. It is initiated toward the card brand's directory server and issuer Access Control Server (ACS) to assess whether and how the cardholder should be authenticated. Authorization is a distinct process handled through the acquirer, network, and issuer authorization systems. A completed authentication does not guarantee that a subsequent authorization will be approved, and the two flows should not be conflated.

Is the AReq part of PCI DSS, or does it belong to a different standard?

The AReq is defined within the EMV 3-D Secure specifications, which are addressed by the PCI 3DS standard rather than by PCI DSS itself. PCI DSS governs the protection of cardholder data in the broader environment, while PCI 3DS focuses on security requirements for 3DS components such as the ACS and directory server. A given environment may be in scope for both, but the standards are separate and should not be treated as interchangeable. Confirm applicability against the current published standards.

What data fields are typically carried in an AReq, and how should sensitive elements be handled?

An AReq generally carries transaction, cardholder, device, and merchant data elements used to support risk-based authentication decisions. Any cardholder data or account identifiers included must be handled under the applicable data protection controls, and implementers should avoid including data elements not required by the specification. Sensitive authentication data such as full track data, card verification values, or PINs is not a purpose of the AReq flow and should not be introduced into it. Consult the current EMV 3-D Secure and PCI 3DS documentation for the authoritative field list and handling expectations.

How do frictionless and challenge flows relate to the AReq?

The AReq is sent to the issuer's ACS, which evaluates the supplied data and returns an Authentication Response (ARes). Based on that evaluation, the flow may proceed frictionlessly, where the cardholder is not actively challenged, or may move to a challenge flow requiring additional cardholder interaction. The path taken depends on issuer risk assessment and configuration, not on the merchant alone. Neither path should be assumed to eliminate fraud; each represents a different balance between customer friction and authentication assurance.

What data quality practices help the AReq support accurate authentication decisions?

Providing complete, accurate, and consistent data elements in the AReq is intended to help the issuer's ACS make a more informed risk assessment, which may increase the likelihood of a frictionless outcome. Missing or malformed fields can lead to unnecessary challenges or declined authentications. Implementers should validate field formatting against the current specification, avoid populating fields with placeholder or inaccurate values, and confirm that any optional data elements they send are permitted and appropriate for the transaction context.

What should implementers consider regarding logging and retention of AReq messages?

AReq messages may contain data elements subject to protection requirements, so logging, storage, and retention should follow the organization's data handling policies and the applicable standards. Implementers should limit retention to what is operationally and contractually necessary, restrict access, and avoid persisting data elements that are not needed. Because requirements and permitted retention differ across standards and card brand rules, and vary by region, teams should verify their approach against the current published PCI 3DS requirements and relevant network rules rather than assuming a fixed retention period.

Common misconceptions

The Authentication Request (AReq) is part of PCI DSS and its handling is governed by PCI DSS requirements.

The AReq is a message defined within EMV 3-D Secure, and the security of the environment that generates and processes 3DS messages is addressed by the separate PCI 3DS standard. PCI DSS still applies to how underlying cardholder data is protected, but 3-D Secure messaging is a distinct standard from PCI DSS and should not be conflated with it. Confirm applicable requirements against the current published standards rather than assuming a fixed requirement number.

Completing a successful AReq/ARes authentication prevents fraud on the transaction.

3-D Secure authentication via the AReq is intended to help reduce card-not-present fraud and may support a liability shift, but it does not eliminate fraud. It addresses one point in the transaction and does not by itself mitigate account takeover, friendly or first-party fraud, or synthetic identity fraud. Liability shift and related rules are governed by card brand and network rules, which vary by region and change over time.

Because a token may appear in the AReq instead of a PAN, the data in the message is out of PCI scope.

Whether tokenization affects PCI DSS scope depends on the implementation and validation of the tokenization approach, not on the presence of a token label alone. The AReq may still carry cardholder data elements that require protection under applicable standards, so scope must be assessed against how the data is actually handled.

Best practices

Treat the systems that generate, transmit, and process AReq messages as subject to the PCI 3DS standard where applicable, and confirm current requirements against the published standard rather than relying on a fixed requirement number.

Protect any cardholder data carried in the AReq using secure transmission controls, and where a PAN is present ensure handling aligns with applicable PCI DSS controls; never retain sensitive authentication data after authorization.

Validate the scope impact of any tokenization used in the AReq flow based on the specific implementation and validation, rather than assuming a token label removes data from scope.

Do not rely on 3-D Secure authentication alone to manage fraud; combine it with layered controls that address account takeover, first-party fraud, and synthetic identity fraud, and monitor for false-positive and false-negative trade-offs.

Ensure message routing identifiers correctly correlate the AReq with its corresponding ARes to maintain integrity of the authentication flow between the 3DS Server, Directory Server, and Access Control Server.

Track card brand and network rule changes governing liability shift and challenge behavior, since these vary by region and evolve over time, and adjust risk-based versus challenge handling accordingly.