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
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?
-
For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?
-
What is the completion date for PCI DSS assessments documented in a Report on Compliance and its related Attestations of Compliance?
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
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?
-
For PCI DSS, can multi-factor authentication (MFA) implementations indicate the success of a factor prior to presentation of subsequent factors?
-
What is the completion date for PCI DSS assessments documented in a Report on Compliance and its related Attestations of Compliance?
-
What is the completion date for PCI DSS assessments documented in a Self-Assessment Questionnaire and its related Attestations of Compliance?
-
How does PCI DSS Requirement 6.4.3 apply to 3DS scripts called from a merchant check-out page as part of 3DS processing?
Most Recently Updated
-
How are third-party service providers (TPSPs) expected to demonstrate PCI DSS compliance for TPSP services that meet customers’ PCI DSS requirements or may impact the security of a customer’s cardholder data and/or sensitive authentication data?
-
Can SAQ eligibility criteria be used for determining applicability of PCI DSS requirements for assessments documented in a Report on Compliance?
-
What should an entity do if its PCI DSS assessment will not be complete prior to that standard's retirement date?
-
Where can I find the current version of PCI DSS?
-
When should an entity implement PCI DSS requirements noted as best practices until a future date?