EMV Payment Tokenisation Specification - Technical Framework v2.4 DRAFT: Disposition of Comments

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: TWG Document: EMV Payment Tokenisation Specification Technical Framework DRAFT 2.4 Date: 07- May-2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 07-Jul-2026 Page 1 of 4 EA ge Background: “PAR has historically represented the underlying funding account, which is ultimately what drives authorization and risk decisions. If multiple instruments are linked to that account, distinguishing between individual users doesn’t change the funding outcome. At the same time, evolving PAR toward an instrument- or rider-level identifier introduces a risk of semantic drift, where a construct that has been consistently used at the account level begins to take on multiple meanings depending on context. It may be worth considering whether rider- level differentiation is better handled through a separate construct, while preserving PAR’s role as a stable reference to the funding account.” It may be worth considering whether the requirements of transit and similar environments could be addressed through a separate construct, rather than modifying the semantics of PAR. For example: • A distinct identifier associated with a specific instrument, rider, or journey context • Scoped to environments requiring per- user or per-session differentiation • While preserving PAR as a stable reference to the underlying funding account This approach would allow: • Transit use cases to achieve per-rider distinction and concurrency handling • The broader ecosystem to retain a consistent account-level identifier tied to funding Acknowle dged It should be noted that in the general case, i.e. for most payment networks this isn’t the case, and even for those few payment networks impacted only then for a limited number of specific Issuers’ products will multiple same PAN cards be issued simultaneously. In the general case, multiple cardholders on the same funding account are issued different PANs, with their own PAR and underlying set of tokens. This enables better customer service, including the segregation of one card/PAR where only one card/credential has been stolen/compromised and needs to be managed for potential fraud, card/token replacement, etc. Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: TWG Document: EMV Payment Tokenisation Specification Technical Framework DRAFT 2.4 Date: 07- May-2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 07-Jul-2026 Page 2 of 4 Subject: Feedback on PAR Evolution and Use Case Scope We appreciate the need to support transit use cases where multiple individuals may transact concurrently using instruments linked to the same underlying account. It is understood that in these environments, distinguishing between individual riders is important to support accurate journey tracking, fare calculation, and concurrency handling. However, the proposed evolution of Payment Account Reference (PAR) toward an instrument- or cardholder-level identifier represents a shift from its original intent. As defined, PAR is a Payment Account Reference — its purpose has been to consistently identify the underlying funding account, independent of the specific It was noted during Associate/Industry Engagement, including the PAR SIM, that this edge case impacted not only Transit, but other Industry uses of PAR, including merchant loyalty and co-badge cards (including the SRC Use Case). On which basis it was determined that enhancing PAR’s definition to remove the edge case was the most efficient and least impactful way forward. Alternative mechanisms were examined during the course of the PAR analysis, but industry feedback saw no net value in defining another similar EMVCo mechanism that would need to be implemented across all EMV Technologies, and potentially Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: TWG Document: EMV Payment Tokenisation Specification Technical Framework DRAFT 2.4 Date: 07- May-2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 07-Jul-2026 Page 3 of 4 instrument or user interacting with it. This distinction is important, as the funding relationship ultimately governs authorization, risk, and lifecycle continuity. PAR has been widely used across the ecosystem as a stable account-level identifier, enabling: • Cross-instrument linkage • Fraud detection and behavioral analysis • Token and PAN lifecycle continuity Introducing multiple PAR values for the same underlying funding account may reduce the effectiveness of these use cases and introduce fragmentation in account-level reasoning. Additionally, in scenarios where multiple individuals transact against the same funding source (e.g., family or shared involve requirements on third parties outside of EMVCo standards/Payment Network mandates. Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: TWG Document: EMV Payment Tokenisation Specification Technical Framework DRAFT 2.4 Date: 07- May-2026 EMVCo Use Only EA/Sub 1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of com- ment 2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2 -3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 07-Jul-2026 Page 4 of 4 accounts), treating those transactions as belonging to separate identities may obscure the underlying financial relationship that is relevant for authorization and risk decisions. Summary There is support for enabling new use cases such as transit. However, it is important to preserve the original role of PAR as a reference to the underlying funding account, and to maintain clear separation between account-level and actor-level identifiers in order to preserve interoperability, risk integrity, and existing ecosystem value.