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
-
What evidence is a TPSP expected to provide to customers to demonstrate PCI DSS compliance?
-
Does PCI SSC consider guidance from other standards organizations when making updates to PCI standards?
-
If an organization provides software or functionality that runs on a consumer's device (for example, smartphones, tablets, or laptops) and is used to accept payment account data, can the organization store card verification codes for those consumers?
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
-
What evidence is a TPSP expected to provide to customers to demonstrate PCI DSS compliance?
-
Does PCI SSC consider guidance from other standards organizations when making updates to PCI standards?
-
If an organization provides software or functionality that runs on a consumer's device (for example, smartphones, tablets, or laptops) and is used to accept payment account data, can the organization store card verification codes for those consumers?
-
Do PCI DSS requirements for keyed cryptographic hashing apply to previously hashed PANs?
-
Can a compensating control be used for requirements with a periodic or defined frequency, where an entity did not perform the activity within the required timeframe?
Most Recently Updated
-
Are Mobile Payments on COTS (MPoC) solutions, Software-based PIN Entry on COTS (SPoC)™ solutions, or Contactless Payments on COTS (CPoC™) solutions eligible for a P2PE Solution approval?
-
How can an entity meet PCI DSS requirements for PAN masking and truncation if it has migrated to 8-digit BINs?
-
Can a compensating control be used for requirements with a periodic or defined frequency, where an entity did not perform the activity within the required timeframe?
-
How does encrypted cardholder data impact PCI DSS scope for third-party service providers?
-
Does PCI SSC provide a list of PCI DSS-compliant third-party service providers?