PCI Watch

Tracking changes across the Payment Card Industry

EMVCo White Paper on Payment Account Reference

v2.2 Whitepapers
Payment Tokenisation

countries. EMV® Payment Account Reference (PAR) White Paper Version 2.2 July 2026 EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.

Legal Notice

This document is subject to change by EMVCo at any time. This document does not create any binding obligations upon EMVCo or any third party regarding the subject matter of this document, which obligations will exist, if at all, only to the extent set forth in separate written agreements executed by EMVCo or such third parties. In the absence of such a written agreement, no product provider, test laboratory or any other third party should rely on this document, and EMVCo shall not be liable for any such reliance. No product provider, test laboratory or other third party may refer to a product, service or facility as EMVCo approved, in form or in substance, nor otherwise state or imply that EMVCo (or any agent of EMVCo) has in whole or part approved a product provider, test laboratory or other third party or its products, services, or facilities, except to the extent and subject to the terms, conditions and restrictions expressly set forth in a written agreement with EMVCo, or in an approval letter, compliance certificate or similar document issued by EMVCo. All other references to EMVCo approval are strictly prohibited by EMVCo. Under no circumstances should EMVCo approvals, when granted, be construed to imply any endorsement or warranty regarding the security, functionality, quality, or performance of any particular product or service, and no party shall state or imply anything to the contrary. EMVCo specifically disclaims any and all representations and warranties with respect to products that have received evaluations or approvals, and to the evaluation process generally, including, without limitation, any implied warranties of merchantability, fitness for purpose or non-infringement. All warranties, rights and remedies relating to products and services that have undergone evaluation by EMVCo are provided solely by the parties selling or otherwise providing such products or services, and not by EMVCo, and EMVCo will have no liability whatsoever in connection with such products and services. This document is provided "AS IS" without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in this document. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NON - INFRINGEMENT, AS TO THIS DOCUMENT. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to this document. EMVCo undertakes no responsibility to determine whether any implementation of this document may violate, infringe, or otherwise exercise the patent, copyright, trademark, trade secret, know-how, or other intellectual property rights of third parties, and thus any person who implements any part of this document should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, this document may provide for the use of public key encryption and other technology, which may be the subject matter of patents in several countries. Any party seeking to implement this document is solely responsible for determining whether its activities require a license to any such technology, including for patents on public key encryption technology. EMVCo shall not be liable under any theory for any party's infringement of any intellectual property rights in connection with this document. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Contents Legal Notice ii Contents iii Figures v Tables vi 1 Executive Summary 1 2 Purpose and Scope 2 2.1 Purpose 2 2.2 Scope 2 2.3 References 2 2.3.1 Normative References 2 2.3.2 Published EMVCo Documents 2 2.4 Definitions and Abbreviations 3 3 Payment Account Reference Overview 4 3.1 Usage of PAR 5 3.2 PAR Governance 5 3.3 PAR Management and Lifecycle 6 3.4 PAR Data Structure and Format 7 3.5 Availability of PAR 7 3.6 Token Provisioning and PAR 8 3.7 Token Processing and PAR 8 3.8 PAR Data Security and Privacy Considerations 9 4 Examples of PAR Usage 10 4.1 PAR in Transit 10 4.1.1 Same Payment Credential Presented in Different Forms 10 4.1.2 Different Transit Riders with the same PAN 11 4.2 PAR in Merchant Loyalty Schemes 12 4.2.1 Tracking Loyalty Points for Monthly Total 12 4.2.2 Different Customers with the same PAN 13 4.3 PAR For Virtual Card Numbers 14 4.3.1 Problem Statement 14 4.3.2 VCN as EMV Payment Tokens 15 4.3.3 VCN as non- EMV Payment Tokens 16 4.3.4 Illustration of PAR Data 17 4.4 PAR in Fraud Monitoring 19 4.4.1 Merchant Fraud Tracking 19 4.5 PAR in Anti-Money Laundering Tracking 19 EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.

4.5.1 Regulatory Authority AML Tracking 19 EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 Page v

countries. Figures Figure 1: PAR Data Structure and Format 7 Figure 2: Same Payment Credential Presented in Different Forms 11 Figure 3: Different Transit Riders with the same PAN 12 Figure 4: VCNs and PAR Data 15 Figure 5: VCNs as EMV Payment Tokens 16 Figure 6: Illustration of PAR Data 18 EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Tables Table 1: EMVCo References 3 Table 2: Availability of PAR 8 Table 3: Customer Spend and Loyalty Points 13 Table 4: Separate Customer Spend and Loyalty Points 14 EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. 1 Executive

Summary

Payment Account Reference (PAR) was introduced by EMVCo in 2016 to address the challenge of linking transactions carried out using a Primary Account Number (PAN) and / or its affiliated EMV Payment Tokens. Since then, the potential use of PAR as a linkage mechanism has grown to encompass a variety of use cases, including scenarios where no Payment Tokenisation has occurred. PAR acts as a persistent, non- sensitive reference whose use is reserved solely for linking a PAN and any affiliated Payment Tokens, enabling transaction history tracking and account identification without exposing the actual PAN. It can also be used to differentiate between different Cardholders who share the same PAN. PAR is unique to each PAN (or unique Cardholder, if multiple Cardholders share a PAN) and is associated with all affiliated Payment Tokens that are generated for that PAN / Cardholder. PAR cannot be used to initiate payment transactions and is not a substitute for PAN or Payment Tokens. As such, it is not a consumer identifier and is not considered PCI Account Data under PCI Standards. This white paper provides an overview of PAR and gives examples of PAR usage in a variety of use cases, illustrating how PAR can be used to solve a number of real-world problems. This includes differentiating between Cardholders who share the same PAN, but who need to be treated separately in cases such as transit and merchant loyalty. To realise the maximum benefit that PAR offers, its widespread adoption in the payment ecosystem, including for PANs which have not been tokenised, is essential. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. 2 Purpose and Scope 2.1

Purpose

The EMV® Payment Account Reference (PAR) White Paper (hereafter, the white paper) is a companion document to the EMV® Payment Tokenisation Specification – Technical Framework. It provides an overview of PAR and gives examples of PAR usage in a variety of use cases. 2.2

Scope

The white paper is intended to provide an overview of PAR, as well as examples of PAR Usage that can be adopted to meet the unique payment ecosystem requirements of international, regional, national or local implementations. The white paper is not designed to mandate, incentivise, or define commercial rules, requirements or policies for the implementation of PAR solutions by international, regional, national or local Payment Systems. PAR works alongside, or falls within, standards and specifications applicable to the payment ecosystem. Entities that choose to implement PAR should ensure that they adhere to applicable international, regional, national or local laws and regulations. 2.3

References

The latest version of any reference, including all published amendments, shall apply unless a publication date is explicitly stated.

2.3.1 Normative References For standards which may be associated with the white paper, refer to Table 1.1: Normative References in the Technical Framework.

2.3.2 Published EMVCo Documents The documents in Table 1 are related to or are associated with the white paper and are located at www.emvco.com. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. Table 1: EMVCo References Reference Publication Name Technical Framework EMV® Payment Tokenisation Specification – Technical Framework A Guide to Use Cases EMV® Payment Tokenisation – A Guide to Use Cases 2.4 Definitions and Abbreviations For the definition of the terms used in the white paper, refer to Table 1.3: Definitions in the Technical Framework. For the definition of the abbreviations used in the white paper, refer to Table 1.4: Abbreviations in the Technical Framework. Note: The defined terms Token Service Provider and Token Requestor ID are commonly referred to within the Payment Tokenisation ecosystem by the abbreviations TSP and TRID respectively. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. 3 Payment Account Reference Overview EMV Payment Tokenisation, as defined in the Technical Framework, established a framework for replacing a Cardholder’s PAN with secure EMV Payment Tokens. Payment Tokens reduce fraud risk and limit the exposure of sensitive data, such as the full PAN. However, EMV Payment Tokenisation introduced a key challenge: transactions may use either the underlying PAN or its affiliated Payment Tokens, making it difficult for Merchants and other ecosystem participants to link transaction histories and consistently identify the same payment account across interactions. To address this, PAR (Payment Account Reference) was introduced as a linkage mechanism between the underlying PAN and all affiliated Payment Tokens. Since then, the usage of PAR has been expanded to act as a linkage mechanism in other use cases, such as differentiating between Cardholders who share the same PAN. The term PAR is a general reference that encompasses the governance, by the Registered BIN Controller, of all the following components:

  • PAR Field
  • PAR Data
  • PAR Data generation method
  • PAR delivery mechanisms
  • PAR Enquiry Function The term PAR Data refers to a specific Payment Account Reference or References generated in the format specified in the Technical Framework. The term PAR Field refers to a field designated to carry PAR Data between the various entities within the payment ecosystem. The term PAR Enquiry Function refers to an implementation- specific method for the enquiry and distribution of PAR Data. Implementation of PAR is outside of the scope of EMVCo: it is the responsibility of each Registered BIN Controller to specify how PAR will be used within its payment ecosystem. The PAR Field and PAR Data may also be included in PAN-based transactions in which Payment Token(s) have been previously generated for the PAN. There is also inherent value in propagating PAR Data for PANs in situations where Payment Tokens have not yet been generated for such PANs. In order for PAR to have its full effect in the Payment ecosystem, PAR Data should be included with all transactions. This includes all PAN-based transactions, regardless of whether Payment Token( s) have been previously generated for the PAN, Making PAR Data available in advance of the generation of any Payment Tokens allows for the payment ecosystem to more rapidly adapt to business and technical processes and EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 countries.. solutions around the use of PAR Data. This enables the support of multiple use cases in advance of the implementation of Payment Tokenisation and avoids the need to develop redundant/non- interoperable solutions to address the same problem. If Payment Tokens for such PANs are subsequently generated, then the linkage between a PAN and its affiliated Payment Token(s) is readily supported since PAR has been fully enabled due to wide scale availability of PAR Data. Wide availability and adoption of PAR and PAR Data will provide an impetus to break the dependencies on Full PAN availability throughout the payment ecosystem. The following sections provide an overview of the value that PAR provides as a mechanism to link transactions and other activities involv ing the underlying PAN and affiliated Payment Token( s).

3.1 Usage of PAR For PAR to be most effective, PAR Data needs to be available throughout the payment ecosystem. Therefore, PAR Data should be present in all transactions which include either PANs or Payment Tokens. The inclusion of PAR Data in PAN-initiated transactions where the PAN does not have any affiliated Payment Tokens provides consistency and promotes widespread adoption. The presence and wide- scale adoption of PAR provides the rationale to reduce the exposure of Full PAN. PAR cannot be used to initiate a payment transaction including authorisation, capture, clearing or exception messages.

3.2 PAR Governance Registered BIN Controllers determine the governance of PAR and the process for ensuring PAR uniqueness covering the IINs (BINs) under their direct control. EMVCo assigns each Registered BIN Controller with a BIN Controller Identifier which ensures the uniqueness of PAR Data across different Registered BIN Controllers. BIN assignees or sub-licensees are not considered BIN Controllers and are expected to work under the principles for PAR governance that are determined by the ISO IIN Blockholder. PAR Data is unique in its assignment to a given underlying PAN and, in light of applicable privacy considerations, is not intended to be a consumer identifier.

  • For Payment Accounts that have multiple PANs issued, the BIN Controller shall ensure that:
  • Different PAR Data is generated for each PAN within the Payment Account
  • The PAR data for each PAN is associated with that PAN’s affiliated Payment Tokens EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 countries.
  • For BIN Controllers which support Card Issuers that issue cards where the same PAN is used by different Cardholders, the BIN Controller shall ensure that:
  • Card Issuers and Token Service Providers are able to differentiate each unique Cardholder via additional data associated with the C ardholder / card
  • Different PAR Data is generated for each unique Cardholder with the same PAN
  • The PAR Data is used for the Cardholder’s card and for all Payment Tokens affiliated with the PAN for that unique Cardholder Registered BIN Controllers will need to ensure that:
  • PAR Data is generated using a method that cannot be reverse engineered to determine the underlying PAN or Payment Token and will prevent unintended disclosure of the underlying PAN
  • PAR Data meets the data format defined by EMVCo for format consistency in the payment ecosystem
  • PAR Data cannot be used to initiate a payment transaction including authorisation, capture, clearing or exception messages
  • PAR Data assigned to each underlying PAN or unique Cardholder must be:
  • Unique across all PAR Data governed by any one R egistered BIN Controller to ensure no collision or conflict
  • Associated with all affiliated Payment Tokens to enable the linkage of transactions There is no expectation that PAR Data generation methods should be consistent between Registered BIN Controllers. However, an implementation will need to comply with the PAR criteria defined in the Technical Framework.

3.3 PAR Management and Lifecycle There are a variety of business conditions and lifecycle events that may result in an original underlying PAN being replaced by a Card Issuer with a new underlying PAN for the same Payment Account. Conditions include a reissuance due to expiration of the original underlying PAN as well as replacement due to lost/stolen cards, a ccount data compromise, and other fraud-related events. The issuance of a new underlying PAN does not require new PAR Data to be generated. Instead, the Card Issuer informs the BIN Controller of the replacement of the existing underlying PAN, allowing the existing PAR Data to be assigned to the new PAN. This means that existing Payment Tokens that were previously affiliated with the original underlying PAN can be affiliated to the new underlying PAN, maintaining the current EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. associated PAR D ata. This also means that existing, provisioned PAR D ata may not have to be re-provisioned.

3.4 PAR Data Structure and Format PAR Data will be generated in accordance with the following format defined in the Technical Framework:

  • Fixed field length of 29 characters (uppercase Alphanumeric Roman)
  • PAR Data is comprised of a 4 -character BIN Controller Identifier assigned by EMVCo to R egistered BIN Controllers followed by a unique 25-character value The structure of the PAR Data is given in Figure 1: Figure 1: PAR Data Structure and Format Note: PAR Data does not have an associated expiry date. Note: Where PAR Data is not available, the PAR Field shall either be blank or have all 29 characters set to “0”.

3.5 Availability of PAR The Technical Framework defines a number of ways that the PAR Field and PAR Data may be introduced into transaction processing, which are summarised in Table 2. Depending on the need, PAR Data is available before, during or after the authorisation. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Table 2: Availability of PAR PAR Availability Method Source of PAR Data From an EMV Based Application EMV Tag ‘9F24’ From a non-EMV Based Application Implementation- specific field From the authorisation Returned in the authorisation response message in an ISO 8583 data field (see Technical Framework for details) PAR Enquiry – Payment Token or PAN PAR Enquiry Function – implementation- specific interface Note: EMV Tag ‘9F24’ is available for use with both PAN-based transactions and Payment Token based transactions. Its use is not dependent upon Payment Tokens having been generated for a PAN. Note: The inclusion of PAR in ISO 8583 messages is available for use with both PAN- based transactions and Payment Token based transactions. Its use is not dependent upon Payment Tokens having been generated for a PAN. PAR Data may be available through a PAR E nquiry Function as an implementation- specific interface that is designed to return PAR D ata in response to a request initiated with a Payment Token or PAN. The definition of the PAR E nquiry Function will be implementation specific and is outside of EMVCo scope.

3.6 Token Provisioning and PAR The Registered BIN Controller will define how a Registered Token Service Provider will facilitate PAR provisioning as part of the interaction and interface with the Token Requestor and the Card Issuer. The Registered Token Service Provider may need to source PAR Data from the Card Issuer and provide the provisioning response to the Token Requestor. The response to a Token Request will contain all of the related data inclusive of PAR.

3.7 Token Processing and PAR Transactions that are initiated by a Token Payment Request should include PAR D ata in the transaction message. The availability of PAR D ata in transaction messages will be determined by the Registered BIN Controller. The Payment Network shall make an ISO- defined field (the PAR Field) for PAR D ata available in their transaction message EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. specifications. If the PAR Data is unavailable in the transaction message, Merchants, Acquirers or Payment Processors may optionally use the PAR Enquiry Function. Based on the direction provided by BIN Controller governance programs, PAR Field and PAR Data support will be defined in the various message specifications associated with Token Processing including those defined by Payment Networks, Acquirers and Payment Processors, and Card Issuers. Other options for supporting PAR Data availability outside of traditional payment processing include the development of PAR Enquiry Functions based on proprietary implementation specific interfaces.

3.8 PAR Data Security and Privacy Considerations PAR Data is not a substitute for PAN or Payment Tokens. Therefore, it cannot be used to initiate a payment transaction including authorisation, capture, clearing or exception messages. One of the fundamental principles of PAR implementation is that PAR Data cannot be reverse engineered to determine the underlying PAN or affiliated Payment Tokens. The PCI SSC has published an FAQ on its website, www.pcisecuritystandards.org, in order to formally acknowledge PAR D ata is not associated with PCI Account Data as defined in PCI Standards. PAR Data is assigned directly to an underlying PAN and is not intended to be a consumer identifier. It does not represent the individual consumer or the overall relationship between the Payment Account and the Card Issuer, including when it is used to differentiate between different Cardholders who share the same PAN. The implementation of PAR must not conflict with any national, regional or local laws or regulations, including those concerning data security and privacy. Registered BIN Controllers must define appropriate rules governing the use of PAR D ata for all implementations within the payment ecosystem. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. 4 Examples of PAR Usage This Section provides examples for using PAR within the payment ecosystem under a variety of usage scenarios. In all cases, PAR Data is used to link transactions made by the same Cardholder using the same underlying PAN or its affiliated Payment Tokens. In the absence of PAR Data, these transactions would potentially be unable to be linked together. Note: in order to obtain the maximum benefit from PAR, PAR Data should be provisioned for all PANs, regardless of whether that PAN has been Tokenised, and should be made available throughout the entire payment ecosystem.

4.1 PAR in Transit The use of open loop payments allows transit riders to use their own existing payment credentials to enter and exit t ransit systems. T ransit operators can then calculate the correct aggregate fare for multiple journeys, based on their own fare rules. The presence of PAR Data enables:

  • A transit rider using the same payment credential but presented in different forms (e.g. card, NFC digital wallet, wearable) to be aggregated for fare calculation (Section 4.1.1)
  • Different transit riders using different payment credentials with the same PAN to be charged separately for their individual travel (Section 4.1.2) 4.1.1 Same Payment Credential Presented in Different Forms Scenario A transit r ider uses their NFC digital wallet to enter the transit system and exits using the payment card. Problem Statement The transit operator sees the EMV Payment Token presented by the NFC digital wallet and its underlying PAN (captured from the payment card) as two separate PANs and is unable to match them. As a result, the transit operator charges the transit rider for two separate journeys instead of a single journey. PAR Opportunity By using the PAR Data associated with both the EMV Payment Token and the underlying PAN, the transit operator can correctly match the transit rider’s entry and exit. As a result, the transit rider will be correctly charged for a single journey. Note: there are multiple variants to this problem statement, while there are also multiple methods for the transit operator to obtain the associated PAR Data. These are covered in more detail in A Guide to Use Cases. This is illustrated in Figure 2. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 countries.. Figure 2: Same Payment Credential Presented in Different Forms 4.1.2 Different Transit Riders with the same PAN Two transit riders share a family card. In some cases, the Card Issuer issues each family card with a different PAN. However, some Card Issuers issue the cards with the same PAN. In this second scenario each transit rider has a separate, physical payment card and are therefore separate Cardholders, but they share the same PAN. There are multiple potential scenarios, only one of which is presented here to illustrate the problem statement and the opportunity for PAR to resolve it. Note that in this scenario, both transit riders use their physical payment cards to enter and exit the transit system. Scenario The first transit rider enters the transit system at Point A and afterwards the second transit rider enters at Point B. The second transit rider then leaves at Point C and afterwards the first transit rider leaves at Point D. Problem Statement The transit operator cannot differentiate between two transit riders since both present the same PAN on entry and exit. This could lead to multiple issues. For example, the first transit rider could be incorrectly charged for the journey from A to C, while the second transit rider is incorrectly charged for a journey from B to D. Alternatively, one or other of the transit riders may be denied entry or exit from the transit system. PAR Opportunity While both transit riders have the same PAN, each Cardholder will have a separate PAR, allowing the transit operator to differentiate between the two and thus calculate the correct fare. This is illustrated in Figure 3. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 countries. Figure 3: Different Transit Riders with the same PAN 4.2 PAR in Merchant Loyalty Schemes Merchants typically implement loyalty schemes to support customer retention, often using the Cardholder’s payment credential to track of spending across different channels. The presence of PAR Data enables:
  • A customer using the same payment credential but presented in different forms (e.g. card, NFC digital wallet, Merchant card -on-file e-commerce) to have all their spending tracked and properly aggregated for loyalty rewards (Section 4.2.1)
  • Different customers using different payment credentials with the same PAN to be tracked separately for their own individual loyalty rewards (Section 4.2.2) 4.2.1 Tracking Loyalty Points for Monthly Total Scenario A customer shops online and in- store using the same payment credential, but presented in different forms, with the expectation that their total spending will be aggregated across the month to earn loyalty rewards. Problem Statement The Merchant is unable to link the various Payment Tokens to the customer’s underlying PAN. Therefore, the only spending which is recognised for the monthly total is that undertaken with the customer’s physical payment card, resulting in the customer receiving fewer rewards than expected. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2 countries.. PAR Opportunity The Merchant is able to use the PAR from the various Payment Tokens to link the customer’s spending to their underlying PAN, allowing the correct calculation of the customer’s loyalty points. This is illustrated in Table 3. Table 3: Customer Spend and Loyalty Points When Where What Amount Payment Method PAN/ Token Total Points Day 2 Online Purchase $150.00 Card-on-File Token 1 150 Day 9 In-store Purchase $120.00 Payment Card PAN 270 Day 12 In-store Purchase $70.00 NFC Digital Wallet Token 2 340 Day 15 In-store Return $50.00 Payment Card PAN 290 Day 20 Store Café Purchase $15.00 Wearable Device Token 3 305 Note: In this example, the customer receives one loyalty point for each dollar spent. The presence of PAR Data enables the Merchant to successfully link all the transactions made using the underlying PAN, Payment Token 1, Payment Token 2 and Payment Token 3.

4.2.2 Different Customers with the same PAN Two customers share a family card

This has the same PAN, but each customer has a separate, physical payment card and are therefore separate Cardholders. In this example, the two customers are treated separately by the merchant for purposes of determining monthly loyalty rewards. Scenario The two customers shop online and in- store using their separate cards, with the expectation that their individual spending will be aggregated across the month to earn loyalty rewards. Problem Statement The Merchant cannot differentiate between two customers since both present the same PAN when shopping. Therefore, all the spending will be counted towards a single customer when determining the monthly loyalty rewards. PAR Opportunity While both customers have the same PAN, each customer, as an individual Cardholder, will have a separate PAR, allowing the Merchant to differentiate between the two and thus calculate the correct monthly rewards. This is illustrated in Table 4. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Table 4: Separate Customer Spend and Loyalty Points When Where What Amount Customer PAR Data Total Points Day 3 Online Purchase $150.00 Customer 1 PAR Data 1 150 / 0 Day 7 In-store Purchase $55.00 Customer 2 PAR Data 2 150 / 55 Day 16 Store Café Purchase $30.00 Customer 1 PAR Data 1 180 / 55 Day 16 In-store Return $75.00 Customer 1 PAR Data 1 105 / 55 Day 20 Online Purchase $115.00 Customer 2 PAR Data 2 105 / 170 Note: In this example, the customer receives one loyalty point for each dollar spent. For simplicity, it is assumed that each customer only uses their physical payment card, although the example can also apply to other payment methods (e.g. card-on-file, NFC Digital Wallet). The presence of PAR Data enables the Merchant to successfully differentiate between the different customers even though the underlying PAN is the same.

4.3 PAR For Virtual Card Numbers The terms “virtual card” and “virtual card number” are widely used within the payment ecosystem to describe a variety of different products. For the purposes for the white paper, a Virtual Card Number (VCN) is an alternate, Card Issuer-created digital credential for the same Cardholder that is linked to an underlying PAN. VCNs are used for online or remote transactions to avoid exposing the underlying PAN in card-not-present environments. A VCN protects the underlying PAN by using this alternate digital credential that can support single- use, limited- use, or channel -specific controls aiming to enhance security and budgeting for consumers. In this way, VCNs are similar to EMV Payment Tokens, except that they are Card Issuer- created and are generated from the Card Issuer’s BIN range. As VCN adoption grows among Card I ssuers and M erchants, the payment ecosystem needs consistent best practices, especially around lifecycle management, security, interoperability, tokenisation, fraud mitigation, and PAR integration.

4.3.1 Problem Statement When a VCN is generated using the Card Issuer’s PAN BIN range, it is treated as a separate PAN by the payment ecosystem. Any transaction undertaken using such a VCN cannot be linked to the underlying PAN except by the Card Issuer. If EMV Payment EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. Tokenisation occurs, the underlying PAN and the VCN will also be treated as separate PANs by the Token Service Provider and BIN Controller, resulting different PAR Data being assigned. This is illustrated in Figure 4. Since the underlying PAN and VCN 1 are treated as separate PANs, when EMV Payment Tokenisation occurs, the resulting EMV Payment Tokens (EMV Payment Token 1 and EMV Payment Token 2) will have different PAR Data, despite being associated with the same underlying PAN. Furthermore, VCN 2, which is never tokenised, has no PAR Data. This means that PAR can only be used as a partial linkage mechanism in the payment ecosystem. Figure 4: VCNs and PAR Data 4.3.2 VCN as EMV Payment Tokens EMVCo recommends that VCNs for the same Cardholder are generated from the Card Issuer’s assigned Token BIN ranges, rather than the Card Issuer’s PAN BIN range. In this case, VCNs are de- facto EMV Payment Tokens and benefit from all the advantages associated with EMV Payment Tokenisation (e.g. Token Domain Restriction Controls). This includes the assignment of PAR, meaning that at the point of creation, any VCN will be assigned the same PAR Data as its underlying PAN. Furthermore, any EMV Payment Tokens which are subsequently generated using this VCN will also be assigned the same PAR Data. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. This is illustrated in Figure 5, where both VCNs, regardless of whether they are tokenised, and all linked EMV Payment Tokens, regardless of how they were generated, all share the same PAR Data. Figure 5: VCNs as EMV Payment Tokens Adopting this solution ensures that a VCN (EMV Payment Token) will always fall under the Technical Framework for PAR governance and will therefore always have the same PAR Data as the underlying PAN. This means that PAR Data can be used to link all transactions to the same underlying PAN, regardless of the VCN or EMV Payment Token used for the transaction, and without requiring any changes to BIN Controllers’ existing policies and processes.

4.3.3 VCN as non-EMV Payment Tokens EMVCo acknowledges that Card Issuers may choose to use their own PAN BIN ranges to issue VCNs for the same Cardholder. In this case, in order to enable PAR Data to be used as a linkage mechanism, the same PAR Data that is assigned to the underlying PAN needs to be assigned to the VCN at the point of its creation. In this way, the underlying PAN, VCN and any Payment Tokens generated from both the underlying PAN and the VCN will share the same PAR Data. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries.. Note: this approach relies on the underlying PAN already having PAR Data assigned to it. In the case where the underlying PAN does not have PAR Data, this will need to be created and assigned to both the PAN and the VCN when the VCN is issued. This approach falls outside of the Technical Framework for PAR governance. To enable this solution, the Card Issuer will need to work in conjunction with the relevant BIN Controller, which may need to change its existing policies and processes.

4.3.4 Illustration of PAR Data Figure 6 illustrates the various possible relationships between PAN, PAR Data and any VCNs and EMV Payment Tokens. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Figure 6: Illustration of PAR Data EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries..

4.4 PAR in Fraud Monitoring PAR can be used by a variety of entities within the payment ecosystem to help track fraud by linking activity across multiple accounts or transactions to a single underlying PAN.

4.4.1 Merchant Fraud Tracking In this example, a single Merchant with an online store offers customers the ability to create an account and store a payment credential (card-on-file) which is immediately tokenised by the Merchant, resulting in a Payment Token being stored on file by the Merchant for each account. Scenario A fraudulent actor creates multiple accounts with the merchant, each using the same physical card, but with different names / contact details. Problem Statement When the merchant detects fraud on one of the accounts, it flags all other accounts for potential fraud. However, since the merchant only has the Payment Token for each account, it cannot link the account with the others created by the fraudulent actor. PAR Opportunity By using the PAR Data associated with the EMV Payment Tokens created for each of the fraudulent actor’s accounts, the Merchant is able to correctly link all of the fraudulent actor’s accounts and flag them for potential fraud.

4.5 PAR in Anti-Money Laundering Tracking PAR can be used by a variety of entities within the payment ecosystem to help authorities with anti-money laundering (AML) activities by linking payments across multiple accounts or transactions to a single underlying PAN.

4.5.1 Regulatory Authority AML Tracking In this example, a regulatory authority is tracking a group of bad actors who are suspected of engaging in illegal money laundering by creating multiple prepaid cards which are then used for transactions with a range of fraudulent Merchants (e.g. who receive payment for goods or services that are never delivered). Payments may be made using a variety of methods, including ones where the PAN is tokenised. Scenario A bad actor creates a prepaid card which is then used with a range of potentially fraudulent Merchants, either using the physical card (PAN) or a variety of tokenised payment forms. EMV® Payment Account Reference (PAR) White Paper July 2026 v2.2

countries. Problem Statement When the regulatory authority detects suspected money laundering activity at one of the fraudulent Merchants, it looks for other activity by the same Cardholder at other Merchants, for example, to identify other potentially fraudulent Merchants. However, in the case where another Merchant only has a Payment Token rather than the PAN, the regulatory authority cannot link the these payments with others created by the same Cardholder. PAR Opportunity By using the PAR Data associated with the EMV Payment Tokens created for the Cardholder’s PAN, the regulatory authority is able to correctly link all of the Cardholder’s payments with each Merchant and flag them as potentially being engaged in money laundering.