Frequently Asked Question

Is Payment Account Reference (PAR) as defined by EMVCo considered PCI Account Data?
Payment Account Reference (PAR) is a new data element introduced by EMVCo in Specification Bulletin No. 167 January, 2016. PAR is a new data element that is associated with the EMVÆ Payment Tokenisation Specification — Technical Framework. As detailed in the EMVCo Bulletins, PAR is a value that is intended to allow acquirers and merchants to link tokenized transactions to transactions that are based on the underlying PAN. PAR is generated and linked to a PAN (and successor PANs associated with the underlying issuer customer account) and will also be associated with all affiliated Payment Tokens when a PAN is tokenized.
PAR cannot be used to initiate transactions and no authorization, capture, clearing or settlement message can be initiated with PAR alone. The guidelines for PAR also indicate that a PAR value must be generated in such a way as to ensure that it cannot be reverse engineered to obtain a PAN or other PCI Account Data. The data structure of PAR is also intentionally designed to ensure that PAR cannot be confused for PAN, Payment Token or other PCI Account Data.
Based on the underlying EMVCo description of PAR and its intended functions including the underlying guidelines for PAR generation, PAR data is not considered to be PCI Account Data and on its own is not subject to the underlying requirements for protecting PCI Account Data as specified in PCI DSS. PCI DSS still applies anywhere PCI Account Data is stored, processed, or transmitted. If any system storing, processing, or transmitting PAR also stores, processes, or transmits Account Data (such as a PAN), or is connected to systems that store, process or transmit Account Data, those systems remain in scope for PCI DSS requirements.
PAR cannot be used to initiate transactions and no authorization, capture, clearing or settlement message can be initiated with PAR alone. The guidelines for PAR also indicate that a PAR value must be generated in such a way as to ensure that it cannot be reverse engineered to obtain a PAN or other PCI Account Data. The data structure of PAR is also intentionally designed to ensure that PAR cannot be confused for PAN, Payment Token or other PCI Account Data.
Based on the underlying EMVCo description of PAR and its intended functions including the underlying guidelines for PAR generation, PAR data is not considered to be PCI Account Data and on its own is not subject to the underlying requirements for protecting PCI Account Data as specified in PCI DSS. PCI DSS still applies anywhere PCI Account Data is stored, processed, or transmitted. If any system storing, processing, or transmitting PAR also stores, processes, or transmits Account Data (such as a PAN), or is connected to systems that store, process or transmit Account Data, those systems remain in scope for PCI DSS requirements.
January 2016
Article Number: 1374
Related
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
Featured FAQ Articles
Featured
-
Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?
-
Is the PCI DSS Attestation of Compliance intended to be shared?
-
How does an entity report the results of a PCI DSS assessment for new requirements that are noted in PCI DSS as best practices until a future date?
-
Where do I direct questions about complying with PCI standards?
-
Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for assessments documented in a Report on Compliance?
Most Popular
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?
Most Recently Updated
-
How should PCI DSS v4.x requirements noted as superseded by another requirement be reported after 31 March 2025?
-
Are providers of third-party scripts for e-commerce environments considered third-party service providers for PCI DSS Requirements 12.8 and 12.9?
-
Why do requirements 8.3.9 and 8.3.10.1 focus on passwords/passphrases used for single-factor authentication, when multi-factor authentication is required for all access into the CDE?
-
Do PCI DSS Requirements 8.3.9 and 8.3.10.1 apply to all system components?
-
Is the cardholder in scope for PCI DSS?