A 3-D Secure (3DS) authentication value is not the same data element as a card verification code. The distinction matters when a payment platform decides what to store after authorization—and it does not mean that every 3DS field should be retained.
For an operator, processor or supplier integrating 3DS, the practical decision is to map each value to a named purpose, a system and role that need it, and a retention rule that can be reviewed. PCI DSS classification is one input to that design, not a complete storage policy.
PCI SSC separates 3DS values from PCI DSS sensitive authentication data
PCI SSC’s FAQ 1603, published in September 2026, says that 3DS authentication values are not sensitive authentication data (SAD) for PCI DSS. The FAQ identifies PCI DSS SAD as full magnetic-stripe data, card verification codes or values, and PINs or PIN blocks; PCI DSS prohibits storing SAD after authorization. It also says PCI DSS does not prohibit storing 3DS data after the authorization process is complete. See the PCI SSC FAQ on 3DS authentication values for the full wording.
That is a narrow classification statement. “Does not prohibit” is not “must store,” “safe to store indefinitely,” or approval for a particular merchant’s assessment. It does not relax the separate prohibition on storing SAD after authorization, and it does not settle privacy, contract, payment-brand or other security obligations that may apply to a specific data element or flow.
Retain a value only for a defined payment flow
A documented future use can justify retaining selected 3DS data. EMVCo’s guidance for recurring and instalment transactions describes a 3DS Requestor keeping the Directory Server (DS) Transaction ID and/or Access Control Server (ACS) Transaction ID, together with the Authentication Value, for a later 3RI authentication. The EMVCo technical flow is a scoped example; it is not a rule to retain those fields for every payment or every customer.
For each stored field, record the next operation that will use it and which component owns that operation. Keep the authentication reference separate from the payment authorization, settlement record and wallet posting. The payment orchestration guide explains why those are separate states in a platform integration.
Define the data, access and deletion boundary
A useful engineering record is a field-to-purpose map. It should let a reviewer answer these questions without relying on a vague label such as “3DS data”:
| Decision | What to record |
|---|---|
| Data element | The specific value or identifier, its source and its format—not a catch-all 3DS payload. |
| Purpose | The authentication flow that needs it, such as a defined subsequent 3RI request, and the service that consumes it. |
| Roles and copies | Which merchant, 3DS Requestor, processor or 3DS component stores or receives it; include replicas, support exports and backups. Do not assume every operator performs ACS, DS or 3DSS functions. |
| Access | The staff and services that can read or export it, and the operational reason for each access path. |
| Retention and deletion | The business purpose, review or expiry trigger, owner, and how the value is removed from active stores and downstream copies. Do not invent a universal retention period. |
| Applicability | The payment-brand, provider, contract, privacy and assessment questions that still need an accountable answer. |
If the organization performs or provides ACS, DS or 3DS Server (3DSS) functions, PCI SSC says to confirm with the relevant payment brands whether the PCI 3DS Core Security Standard applies. The standard is intended for environments where those functions are performed; its scope is not automatically the same as every operator’s PCI DSS scope.
Keep raw authentication values out of routine telemetry
Treat a value that may be retained for a defined flow as controlled payment data, even though PCI SSC does not classify it as PCI DSS SAD. A conservative design keeps the raw value out of ordinary application logs, traces, analytics and support tickets unless a reviewed operational need requires it. Use a limited correlation reference where that is enough to connect events, and restrict any system that holds the original value to the services and people that need it.
This is an engineering recommendation, not a new PCI DSS requirement. The security logging and audit evidence guide covers how to preserve useful investigation records without copying sensitive payloads into general logs.
Test the lifecycle, not only the 3DS response
Acceptance should exercise the complete retention path. For example, test that a recurring-flow implementation supplies only the fields required by its documented next authentication; a one-time flow does not accumulate values without a follow-on purpose; a provider field change cannot silently map the wrong value; routine logs and exports do not expose the raw payload; and an expired purpose triggers the agreed review and deletion process.
Also test who can retrieve the stored field, how access is recorded, and whether the payment record still distinguishes authentication from authorization and settlement. These checks make the platform’s data decision reviewable; they do not certify a system or determine a merchant’s compliance status.
If you are defining a scoped platform or payment integration, contact Wizards with the systems and flow you need to connect.
Frequently asked questions
Are 3DS authentication values PCI DSS sensitive authentication data?
No. PCI SSC FAQ 1603 says 3DS authentication values are not PCI DSS sensitive authentication data. PCI DSS SAD includes full magnetic-stripe data, card verification codes or values, and PINs or PIN blocks; PCI DSS prohibits storing SAD after authorization.
Does PCI DSS require storing a 3DS authentication value?
No. PCI SSC says PCI DSS does not prohibit storing 3DS data after authorization, but that is not a requirement to retain it. Define a specific purpose, access boundary and review or deletion rule before keeping a value.
When can a 3DS value support a later authentication?
EMVCo describes a recurring or instalment 3RI flow in which a 3DS Requestor keeps the DS Transaction ID and/or ACS Transaction ID and the Authentication Value for future authentication. That example is specific to the defined flow and should not be generalized to unrelated payments.
Does the PCI 3DS Core Security Standard apply to every iGaming operator?
Not automatically. PCI SSC describes the standard for environments performing ACS, DS or 3DS Server functions and advises those entities to confirm applicability with the relevant payment brands. An operator should not infer its scope from a general article.
