Skip to main content
Commerce Security Authority
Category: 3-D Secure

Universal Cardholder Authentication Field

Also known as:
Simply put

The Universal Cardholder Authentication Field (UCAF) is a data field used in Mastercard online purchases to carry a security value proving a card-not-present transaction was authenticated. This value is generated as part of Mastercard's SecureCode / Identity Check process when a shopper's identity is checked during checkout. Merchants that collect and pass this value may qualify for different interchange treatment.

Formal definition

UCAF is a standardized Mastercard field that transports a cryptographic value associated with card-not-present authentication under Mastercard SecureCode / Identity Check (3-D Secure). The UCAF value is issuer- or cardholder-generated and is populated when a UCAF-enabled merchant has collected the authentication result, providing evidence of an authenticated transaction to be carried through the authorization message. Related indicators, such as the UCAF Collection Downgrade Indicator, are returned by Mastercard when an Identity Check (3DS) transaction is downgraded to a non-authenticated state. UCAF is specific to Mastercard's network implementation and is distinct from PCI DSS controls; it is one component of authentication and does not by itself eliminate card-not-present fraud, and its effect on interchange qualification is governed by Mastercard network rules, which vary by region and change over time. Confirm current field formats, codes, and rules against Mastercard's published documentation.

Why it matters

For card-not-present transactions, merchants and acquirers need a reliable way to carry proof that a shopper's identity was checked during checkout. UCAF serves this purpose within Mastercard's network by transporting a cryptographic value produced through the SecureCode / Identity Check (3-D Secure) process. Without a standardized field to convey this authentication result, the evidence of an authenticated transaction would not travel consistently through the authorization message, and issuers and merchants would lack a common signal to distinguish authenticated from non-authenticated online purchases.

UCAF also has commercial consequences. Merchants that collect and pass the UCAF value may qualify for different interchange treatment, since the presence of an authenticated transaction can influence how a transaction is priced and how liability is allocated under Mastercard rules. When an Identity Check transaction is downgraded to a non-authenticated state, Mastercard returns a UCAF Collection Downgrade Indicator, which signals to the parties that the expected authentication was not fully carried through. Understanding these signals matters for both fraud posture and cost management.

At the same time, UCAF should be understood as one component of authentication rather than a complete defense. It is intended to convey the result of an identity check, but it does not by itself eliminate card-not-present fraud, and its effect on interchange qualification is governed by Mastercard network rules that vary by region and change over time. Teams should confirm current field formats, codes, and rules against Mastercard's published documentation rather than assuming fixed behavior.

Who it's relevant to

Merchants and e-commerce teams
Online merchants that support Mastercard SecureCode / Identity Check need to collect and pass the UCAF value to convey that a card-not-present transaction was authenticated. Merchants that do so may qualify for different interchange treatment, though this depends on Mastercard network rules that vary by region and change over time. Teams should treat UCAF as one part of their authentication and fraud strategy rather than a standalone control against card-not-present fraud.
Acquirers and payment processors
Acquirers and processors are responsible for carrying the UCAF value through the authorization message and for handling related signals such as the UCAF Collection Downgrade Indicator, which Mastercard returns when an Identity Check (3DS) transaction is downgraded to a non-authenticated state. Accurate handling of these fields affects both authentication evidence and interchange qualification under Mastercard rules.
Fraud and risk analysts
Analysts assessing card-not-present transactions can use the presence or absence of a valid UCAF value, and the downgrade indicator, as one input into risk decisions. UCAF conveys the result of an identity check but does not by itself eliminate card-not-present fraud, so it should be combined with other detection and authentication signals rather than relied on in isolation.
Integration and engineering teams
Developers integrating Mastercard authorization flows must implement UCAF field formats and related codes correctly, including the UCAF Collection Downgrade Indicator. Because these formats, codes, and rules are specific to Mastercard's network and can change over time and vary by region, teams should confirm current requirements against Mastercard's published documentation before implementation.

Inside UCAF

Authentication Data Field
UCAF is a standardized data field defined by Mastercard for carrying cardholder authentication information within an authorization message. It provides a common structure for transporting the results of an authentication process, such as a cryptogram, from the merchant environment through the acquirer to the issuer.
3-D Secure Cryptogram Transport
In card-not-present transactions, UCAF is commonly used to convey the authentication value produced during a 3-D Secure authentication (for example, the accountholder authentication value or equivalent cryptogram). It is a transport mechanism, not the authentication protocol itself, and its content originates from the associated authentication flow.
Indicator of Authentication Status
UCAF-related data elements are generally accompanied by indicators that describe whether and how authentication was attempted or completed. These indicators help the issuer and acquirer interpret the authentication outcome, but the specific formats and code values are governed by card brand and network rules that vary and change over time.
Network- and Brand-Specific Scope
UCAF is a Mastercard-defined construct. Other card networks use their own fields and terminology for conveying authentication results, so UCAF should not be treated as a universal cross-brand field despite its name.

Common questions

Answers to the questions practitioners most commonly ask about UCAF.

Is UCAF the same thing as 3-D Secure, or does using UCAF mean I've implemented 3-D Secure?
No. UCAF is a data-transport mechanism, not an authentication protocol. It is a standardized field used to carry authentication data (such as a cryptogram or accountholder authentication value) from the authentication process through the authorization message. The authentication itself is performed by a protocol such as 3-D Secure. Populating the UCAF field is a way to convey the result of that authentication to the issuer; it does not by itself perform any authentication. Treat UCAF as the container and 3-D Secure as the process that generates what goes in it.
Does passing data in the UCAF field guarantee a liability shift or prevent chargebacks?
No. Whether a liability shift applies and how chargebacks are handled are governed by card brand and network rules, which vary by region and change over time. Successfully carrying authentication data in the UCAF field may support a claim to a liability shift under the applicable rules, but it does not guarantee one, and it does not prevent fraud or eliminate all chargebacks. First-party or friendly fraud, disputes on other grounds, and rule changes can all still result in chargebacks. Confirm the current, region-specific network rules rather than assuming an automatic outcome.
What kind of data actually goes into the UCAF field?
The UCAF field carries authentication-related data produced by the authentication process, typically an encoded authentication value or cryptogram generated during an authentication such as 3-D Secure. The exact format and permitted contents are defined by the applicable card brand and message specifications. The field is intended to transport an authentication result, not primary account data; you should not treat it as a place for sensitive authentication data such as CVV2/CVC2/CAV2, full track data, or PIN blocks, which have their own storage and handling restrictions.
Where in the transaction flow is the UCAF field populated and read?
In a card-not-present flow, the authentication step runs first (for example, a 3-D Secure exchange), producing an authentication value. That value is then formatted and placed into the UCAF field within the authorization request that the merchant or its processor sends onward. The issuer reads and validates the field as part of authorization decisioning. Because the field spans the authentication and authorization stages, both your authentication integration and your authorization message formatting must agree on how the field is populated. Confirm the required message elements against the current card brand specifications.
How does UCAF relate to PCI DSS scope for my systems?
PCI DSS scope is driven by where cardholder data and sensitive authentication data are stored, processed, or transmitted, and by systems connected to that environment. The UCAF field carries authentication result data rather than the PAN, so its presence alone does not define scope; the surrounding systems that handle the authorization message and any cardholder data still fall under the applicable requirements. Requirement numbering and wording differ between PCI DSS versions, so validate specific controls against the current published standard rather than assuming a fixed requirement number.
What should I check if issuers are not honoring the authentication data I send in the UCAF field?
Common areas to review include whether the field is being populated in the exact format required by the applicable card brand and message specification, whether the authentication step actually completed successfully and returned a usable value, and whether your processor or acquirer is forwarding the field unaltered in the authorization message. Also confirm that the authentication indicators accompanying the field correctly reflect the authentication outcome. Because acceptance and any associated liability treatment depend on current network rules that vary by region, coordinate with your acquirer or processor and verify against the current specifications rather than assuming prior behavior still applies.

Common misconceptions

UCAF is an authentication method that verifies the cardholder.
UCAF is a data field used to transport authentication information within authorization messages; it does not perform authentication. The authentication itself is performed by a separate process, commonly 3-D Secure, and UCAF simply carries the resulting value. It is intended to communicate an authentication outcome, not to establish one.
The 'Universal' in UCAF means it works across all card brands and networks.
UCAF is defined by Mastercard and is specific to its environment. Other networks use their own equivalent fields and rules. The presence and interpretation of authentication data depend on brand and network specifications, which vary by region and change over time.
Populating UCAF guarantees a liability shift or eliminates fraud.
UCAF carries authentication data that may support a liability shift, but liability shift and chargeback outcomes are governed by card brand and network rules that vary by region and change over time. Conveying authentication data may help reduce certain card-not-present fraud risk but does not by itself guarantee any liability outcome or eliminate fraud.

Best practices

Treat UCAF strictly as a transport field for authentication results and validate that the underlying authentication process, such as 3-D Secure, is correctly implemented and produces the values being carried.
Confirm the current UCAF field formats, indicator values, and usage rules against the applicable Mastercard specifications, and verify equivalent handling for other networks using their own fields, since these rules vary by brand and region and change over time.
Do not rely on UCAF population alone to determine liability; verify liability shift and chargeback treatment against the current card brand and network rules that apply to your region and transaction type.
Ensure authentication data conveyed in UCAF is handled consistent with your data classification; note that this authentication value is distinct from sensitive authentication data such as full track data, CAV2/CVC2/CVV2/CID, and PINs, which must not be stored after authorization.
Reconcile UCAF-related authentication indicators between the authentication step and the authorization message to detect mismatches, and monitor for false-positive and false-negative outcomes in downstream fraud decisioning that consumes this data.
Document how UCAF fits within your card-not-present transaction flow and confirm any related storage, logging, or scoping implications against the current published PCI DSS rather than assuming fixed requirement numbers or wording.