EMV Payment Tokenisation Specification - Technical Framework v2.4 DRAFT: Comment Period ends 1 May 2026

EMV® Payment Tokenisation Specification Technical Framework Version 2.4 DRAFT April 2026 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Legal Notice Page i / ix The EMV® Specifications are provided “AS IS” without warranties of any kind, and EMVCo neither assumes nor accepts any liability for any errors or omissions contained in these Specifications. EMVCO DISCLAIMS ALL REPRESENTATIONS AND WARRANTIES, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT, AS TO THESE SPECIFICATIONS. EMVCo makes no representations or warranties with respect to intellectual property rights of any third parties in or in relation to the Specifications. EMVCo undertakes no responsibility to determine whether any implementation of the EMV® Specifications 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 the EMV® Specifications should consult an intellectual property attorney before any such implementation. Without limiting the foregoing, the Specifications 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 these Specifications 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 the EMV® Specifications. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page ii / ix Revision Log – Version 2.4 DRAFT The following changes have been made to the document since the publication of version 2.3: • Minor editorial changes • References to PAR have been moved from Section 2 Constraints of the Ecosystem to Section 7.2 Creation and Assignment • Roles, responsibilities and requirements with reference to PAR have been revised in the following Sections: o Section 3 Payment Tokenisation Ecosystem o Section 4 Token Programme o Section 5 Payment Tokenisation Requirements • The following changes have been made in Section 7 Payment Account Reference: o The introduction has been revised to include additional use cases supported by PAR, with some original material moved to 7.2 Creation and Assignment o A new Section 7.1 Definitions has been created, which includes much of the material contained in the original introduction o Sections 7.1 Creation and Assignment to 7.6 Data Security Considerations have been renumbered accordingly (to Sections 7.2 to 7.7) o Section 7.2 Creation and Assignment has been updated with material that was originally in Section 2 Constraints of the Ecosystem and the introduction to Section 7 Payment Account Reference o Section 7.3 BIN Controller has been updated to account for the use case where the same PAN is used by different Cardholders o Sections 7.4 to 7.7 have had revisions to roles, responsibilities and requirements with reference to PAR to ensure consistency with revisions elsewhere in the document © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page iii / ix Contents Legal Notice ............................................................................................................. i Revision Log – Version 2.4 DRAFT........................................................................ ii Contents ................................................................................................................. iii Figures.................................................................................................................. viii Tables ..................................................................................................................... ix 1 Introduction ....................................................................................................... 1 1.1 Scope ........................................................................................................ 1 1.2 Overview ................................................................................................... 2 1.3 Audience ................................................................................................... 4 1.4 References ................................................................................................ 4 1.4.1 Normative References .................................................................... 4 1.4.2 Published EMVCo Documents ........................................................ 5 1.5 Definitions.................................................................................................. 6 1.6 Notational Conventions............................................................................ 13 1.6.1 Abbreviations ................................................................................ 13 1.6.2 Terminology and Conventions....................................................... 14 1.7 Further Information .................................................................................. 14 2 Constraints of the Ecosystem ........................................................................ 15 3 Payment Tokenisation Ecosystem................................................................. 16 3.1 Cardholder............................................................................................... 16 3.2 Card Issuer.............................................................................................. 16 3.3 Merchant ................................................................................................. 17 3.4 Acquirer ................................................................................................... 17 3.5 Payment System ..................................................................................... 17 3.6 Payment Network .................................................................................... 18 3.7 Token Service Provider ........................................................................... 18 3.8 Token Requestor ..................................................................................... 19 3.9 Token User.............................................................................................. 19 3.10 Payment Tokenisation Aggregator........................................................... 19 3.11 BIN Controller .......................................................................................... 20 3.12 Illustrative Payment Token Process Overviews ....................................... 21 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page iv / ix 4 Token Programme........................................................................................... 24 4.1 Numeric Management ............................................................................. 25 4.2 Issuance of Payment Tokens .................................................................. 26 4.2.1 4.2.2 4.2.3 4.2.4 Token Assurance .......................................................................... 26 Token Generation ......................................................................... 26 Token Issuance ............................................................................ 26 Token Provisioning ....................................................................... 27 4.3 Token Vault ............................................................................................. 27 4.4 Payment Tokenisation Aggregators ......................................................... 28 4.5 Security and Related Controls ................................................................. 28 4.6 Token Requestor Registry Functions....................................................... 28 4.6.1 Token Requestor ID...................................................................... 29 4.7 Token Domain Restriction Controls ......................................................... 29 4.8 Token Processing.................................................................................... 30 4.9 Payment Tokenisation Lifecycle Management ......................................... 31 4.10 Interfaces ................................................................................................ 31 4.11 Reporting................................................................................................. 32 4.12 Authorised Entities................................................................................... 32 5 Payment Tokenisation Requirements............................................................ 33 5.1 Token Service Provider ........................................................................... 33 5.1.1 5.1.2 5.1.3 5.1.4 5.1.5 5.1.6 Token Service Provider Registration ............................................. 33 Registration and Management of Token Requestors .................... 34 Issuance of Payment Tokens ........................................................ 35 Security and Related Controls....................................................... 36 Token Domain Restriction Controls............................................... 36 Token Processing ......................................................................... 37 5.2 Token Requestor ..................................................................................... 37 5.2.1 Token Requestor ID...................................................................... 38 5.3 Token User.............................................................................................. 38 5.4 Payment Tokenisation Aggregator........................................................... 38 5.4.1 Token Requestor Aggregator ........................................................ 38 5.4.2 Card Issuer Aggregator................................................................. 39 5.5 Additional Stakeholders ........................................................................... 39 5.5.1 Payment Networks........................................................................ 39 5.5.2 Acquirers ...................................................................................... 40 5.5.3 Card Issuers ................................................................................. 40 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page v / ix 5.6 Token Vault ............................................................................................. 40 5.7 Token Location ........................................................................................ 41 6 Token Assurance Method............................................................................... 43 6.1 Token Assurance Concepts..................................................................... 43 6.1.1 6.1.2 6.1.3 6.1.4 Setting the Token Assurance Method ........................................... 43 Token Assurance Data.................................................................. 44 Communicating the Token Assurance Method .............................. 45 Updating the Token Assurance Method ........................................ 45 6.2 Default Token Assurance Method Categories.......................................... 45 6.3 Token Assurance Method Structure......................................................... 45 6.4 Common Token Assurance Method Category Range .............................. 46 6.5 ID&V Method Assignment to Recognised Token Assurance Method Categories ............................................................................................... 47 6.5.1 6.5.2 6.5.3 6.5.4 6.5.5 Card Issuer Account Verification ................................................... 48 Interactive Cardholder Authentication – 1 Factor .......................... 48 Interactive Cardholder Authentication – 2 Factor .......................... 48 Risk Oriented Non-Interactive Cardholder Authentication ............. 49 Card Issuer Asserted Authentication ............................................. 49 7 Payment Account Reference .......................................................................... 50 7.1 Definitions................................................................................................ 51 7.2 Creation and Assignment ........................................................................ 51 7.3 BIN Controller .......................................................................................... 52 7.4 Token Service Provider ........................................................................... 53 7.5 Token Requestors ................................................................................... 53 7.6 Transaction Processing ........................................................................... 54 7.6.1 7.6.2 7.6.3 7.6.4 7.6.5 EMV Terminal Processing............................................................. 54 Merchant Processing .................................................................... 55 Acquiring Processing .................................................................... 55 Card Issuer Processing................................................................. 56 Other Processing .......................................................................... 56 7.7 Data Security Considerations .................................................................. 56 8 Token Service Provider Interfaces ................................................................. 57 8.1 Token Request and Issuance .................................................................. 57 8.1.1 Input Fields ................................................................................... 58 8.1.2 Output Fields ................................................................................ 62 8.2 Token Assurance Method Update ........................................................... 63 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page vi / ix 8.2.1 Input Fields ................................................................................... 63 8.2.2 Output Fields ................................................................................ 64 8.3 De-Tokenisation without Verification........................................................ 65 8.3.1 Input Fields ................................................................................... 65 8.3.2 Output Fields ................................................................................ 66 8.4 De-Tokenisation with Verification............................................................. 67 8.4.1 Input Fields ................................................................................... 67 8.4.2 Output Fields ................................................................................ 68 8.5 Token Cryptogram Request..................................................................... 69 8.5.1 Input Fields ................................................................................... 69 8.5.2 Output Fields ................................................................................ 70 8.6 Payment Tokenisation Lifecycle Management ......................................... 71 9 Payment Token Fields Used in ISO 8583 and 20022 ATICA Messages ....... 74 9.1 ISO-specific Fields................................................................................... 74 9.2 Field Considerations ................................................................................ 78 10 Token Processing ........................................................................................... 81 10.1 EMV Based Application Tags .................................................................. 81 10.2 Authorisation Overview............................................................................ 82 10.3 Routing and Account Range Tables ........................................................ 84 10.4 Transaction Processing Considerations................................................... 84 10.4.1 Payment Network.......................................................................... 84 10.4.2 Types of Transaction .................................................................... 84 10.5 Token Payment Request ......................................................................... 85 10.6 Token Authorisation Processing .............................................................. 88 10.7 Token Domain Restriction Controls ......................................................... 90 10.7.1 Token Cryptogram ........................................................................ 91 10.7.2 POS Entry Mode ........................................................................... 91 10.7.3 Merchant Identifiers ...................................................................... 91 10.7.4 Original Transaction Reference..................................................... 91 10.7.5 Merchant-Initiated Transaction Identifier ....................................... 91 10.7.6 Application of Token Domain Restriction Controls......................... 91 10.8 De-Tokenise ............................................................................................ 93 10.9 Tokenise.................................................................................................. 94 10.10 PAN Authorisation ................................................................................... 94 10.11 Capture Processing ................................................................................. 96 10.12 Clearing ................................................................................................... 96 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page vii / ix 10.13 Exception Processing .............................................................................. 97 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page viii / ix Figures Figure 3.1: Token Request Overview ...................................................................... 22 Figure 3.2: Payment Token Transaction Overview .................................................. 23 Figure 10.1: Illustrative Payment Token Processing Flow for Authorisations ........... 83 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page ix / ix Tables Table 1.1: Normative References.............................................................................. 4 Table 1.2: EMVCo References.................................................................................. 5 Table 1.3: Definitions ................................................................................................ 6 Table 1.4: Abbreviations ......................................................................................... 13 Table 5.1: Token Locations ..................................................................................... 41 Table 6.1: Default Token Assurance Method Categories ........................................ 45 Table 6.2: Token Assurance Method Structure ....................................................... 45 Table 6.3: Non-Card Issuer Token Assurance Method Categories.......................... 47 Table 6.4: Card Issuer Token Assurance Method Categories ................................. 47 Table 8.1: Fields for Token Request with PAN ........................................................ 58 Table 8.2: Fields for Token Request with a Payment Token / Token Reference ID . 60 Table 8.3: Fields for Response to Token Request................................................... 62 Table 8.4: Fields for Token Assurance Method Update Request............................. 63 Table 8.5: Fields for Response to Token Assurance Method Update Request ........ 64 Table 8.6: Fields for De-Tokenisation without Verification Request ......................... 65 Table 8.7: Fields for Response to De-Tokenisation without Verification Request .... 66 Table 8.8: Fields for De-Tokenisation with Verification Request .............................. 67 Table 8.9: Fields for Response to De-Tokenisation with Verification Request ......... 68 Table 8.10: Fields for Token Cryptogram Request .................................................. 70 Table 8.11: Fields for Response to Token Cryptogram Request ............................. 71 Table 8.12: Lifecycle Management Events.............................................................. 72 Table 9.1: ISO-specific Payment Token Fields........................................................ 74 Table 9.2: Token Processing Fields ........................................................................ 78 Table 10.1: Fields Included in Token Payment Requests ........................................ 86 Table 10.2: Fields Included in Token Payment Responses ..................................... 87 Table 10.3: Fields Included in Token Authorisation Requests ................................. 88 Table 10.4: Fields Included in Token Authorisation Responses .............................. 89 Table 10.5: Token Control Fields for Cardholder-Initiated Transactions .................. 92 Table 10.6: Token Control Fields for Merchant-Initiated Transactions..................... 92 Table 10.7: Fields Included in De-Tokenisation Requests ....................................... 93 Table 10.8: Fields Included in De-Tokenisation Responses .................................... 93 Table 10.9: Fields Included in PAN Authorisation Requests.................................... 95 Table 10.10: Fields Included in PAN Authorisation Responses ............................... 96 © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 1 / 98 1 Introduction The purpose of this technical framework is to define a basis for Payment Tokenisation by providing a level of commonality across the payment ecosystem to support adoption, while enabling levels of differentiation that promotes innovation. This technical framework aims to bring benefit to ecosystem stakeholders by describing a global Payment Tokenisation ecosystem that overlays and interoperates with existing payment ecosystems to support digital commerce and new methods of payment. This technical framework: • Describes the Payment Tokenisation ecosystem • Describes existing payment ecosystem entities that maintain their roles in support of Payment Tokenisation and identifies potential impacts • Describes specific functions that can be used to enable Payment Tokenisation • Describes a level of common definition, concepts, controls and flexibility, supporting Payment Tokenisation in differing ecosystem models • Specifies the required, conditional and optional fields associated with Token Requests, Token Generation, Token Issuance, Token Provisioning and Token Processing • Identifies the necessary and common interfaces that support the Payment Tokenisation ecosystem Note that the terminology and definitions used in this technical framework are intended to support a global understanding of the payment ecosystem or Payment Tokenisation ecosystem functions within it. Regional, national or local market differences in terminology and definitions may exist and are not reflected in this technical framework. 1.1 Scope This technical framework is intended to create a common baseline set of functions for Payment Tokenisation that can be adopted to meet the unique payment ecosystem requirements of international, regional, national or local implementations. The technical framework is not designed to mandate, incentivise, or define commercial rules, requirements or policies for the implementation of Payment Tokenisation solutions by international, regional, national or local Payment Systems. Payment Tokenisation works alongside, or falls within, standards and specifications applicable to the payment ecosystem. Entities that choose to implement this technical framework should ensure that they adhere to applicable international, regional, national or local laws and regulations. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 2 / 98 EMVCo operates registration processes for Token Service Providers and BIN Controllers, and maintains a list of assigned Token Service Provider Codes and BIN Controller Identifiers to aid global interoperability of Payment Tokenisation. EMVCo does not develop, operate, maintain, service, test, evaluate, approve or otherwise endorse Token Programmes, Token Service Providers or BIN Controllers. 1.2 Overview The payment ecosystem is evolving to support payment form factors that provide increased protection against counterfeit, account misuse, and other forms of fraud. While EMV chip cards can provide substantial protection for card-present transactions, a similar need exists to minimise the risk of unauthorised use of Primary Account Number (PAN) and to reduce crosschannel and intra-channel fraud for card-not-present and emerging transaction environments that combine elements of card-present and card-not-present transactions. Payment Tokenisation systems hold substantial promise to address these needs. This technical framework describes the baseline requirements for the use of Payment Tokens within the existing payment ecosystem through the establishment of a Token Programme. Payment Tokens are surrogate values that replace the PAN in the payment ecosystem. Payment Tokens are designed to provide transparency to payment ecosystem stakeholders when accepting and processing Payment Tokens. Other forms of tokenisation exist in the ecosystem which are not addressed in this technical framework. They are commonly referred to as acquirer / merchant / issuer tokens and are used by a variety of entities and serve a number of different purposes, including data protection. They focus on enhanced data protection for PAN-based transactions and can reduce the size and scope of the Payment Card Industry (PCI) Cardholder Data Environment. This technical framework does not preclude or seek to restrict their use. Payment Tokens may be used with Cardholder Verification Methods (CVMs) for EMV Based Applications and remain implementation specific. Approaches to CVMs may include signature, PIN, Consumer Device CVM (CD-CVM) or no CVM. This technical framework does not define the usage of, or additional requirements relating to, CVM implementation for Payment Token usage scenarios. CVMs requirements are defined by existing entities in the payment ecosystem and should be observed accordingly. A Payment Token provides improved protection when its use is constrained to a specific domain(s), such as a Merchant, Consumer Device or Token Presentment Mode (represented by the POS Entry Mode). These underlying usage controls, known as the Token Domain Restriction Controls, are a fundamental benefit of Payment Tokens and an important security differentiator in contrast to PANs. Token Domain Restriction Controls allow for the creation of specific constraints for the use of a Payment Token and are applied during Token Processing. An example is the prevention of the successful use of a Payment Token outside of a specific © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 3 / 98 usage scenario or Token Presentment Mode (for example, whether the Cardholder is physically present at a Merchant location to perform Token Presentment). The document EMV® Payment Tokenisation – A Guide to Use Cases (“A Guide to Use Cases”) describes common use cases for Payment Tokens that are in part defined by the specific Token Domain Restriction Controls applied to each Payment Token. Each use case example illustrates how various Token Domain Restriction Controls can be used to constrain the usage of a Payment Token. Steps may be taken to ensure that the Payment Token, as a surrogate value, is replacing a PAN that was issued by the Card Issuer to the legitimate Cardholder, interacting with the Token Requestor. This process is known as Identification and Verification (ID&V) and results in the setting of the Token Assurance Method. Payment Tokens provide benefits for all stakeholders in the payment ecosystem. Examples include: • Card Issuers and Cardholders may benefit from new and more secure ways to pay, improved transaction approval levels, and reduced risk of subsequent fraud in the event of a data breach in which Payment Tokens are exposed instead of PANs • Acquirers and Merchants may experience a reduced threat of online attacks and data breaches, as Payment Token data stores will be less appealing targets given the limitation of Payment Tokens to a specific domain(s). Acquirers and Merchants may also benefit from the Token Domain Restriction Controls that Payment Tokens offer This technical framework introduced the Payment Account Reference (PAR) as a means to minimise the need to receive or store Full PAN. More specifically, in order to achieve the benefits of Payment Tokenisation and minimise the fraud impact of account data compromise, it is critical that Merchants and the broader acceptance community not receive the Full PAN in the authorisation response messages. Dependency on ubiquitous availability of Full PAN extends into many other solutions that facilitate fraud and risk analysis solutions for Merchants, and broader requirements of local law. Payment Tokenisation can create new challenges for entities within the acceptance community that rely on Full PAN to drive payment processing and value added services. Cardholders may have many Payment Tokens affiliated with the same underlying PAN since each Payment Token may have its own Token Domain Restriction Controls that are unique to its environment, Consumer Device or Token Requestor. This means that entities within the acceptance community can perform or process transactions with multiple Payment Tokens for the same underlying PAN without an easy way to determine a linkage between these transactions or to those performed on the underlying PAN. The transition from a dependency on ubiquitous availability of Full PAN can be accomplished by providing PAR as an alternative mechanism that meets the needs of Merchants and the broader acceptance community. It enables the ability to link tokenised transactions with transactions associated with the underlying PAN. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 4 / 98 EMV® Payment Tokenisation – A Guide to Use Cases is an informational supplement that is intended to be read in conjunction with this technical framework. It describes relationship models and use case examples common to Payment Tokenisation. Payment Tokenisation is interoperable generically across EMV technologies. The use of Payment Tokenisation does not preclude the use of other EMV technologies. 1.3 Audience This technical framework is intended for use by all participants in the payment ecosystem, such as Card Issuers, Merchants, Acquirers, Payment Systems, Payment Networks, Payment Processors, BIN Controllers and Third Party Service Providers. 1.4 References The latest version of any reference, including all published amendments, applies unless a publication date is explicitly stated. 1.4.1 Normative References The standards in Table 1.1 contain provisions that are referenced in this technical framework. Reference Table 1.1: Normative References Publication Name ISO/IEC 7812-1:2017, ISO/IEC 7812-2:2017 Identification cards — Identification of issuers: Part 1: Numbering system Part 2: Application and registration procedures ISO 8583 Financial transaction card originated messages — Interchange message specifications (1987, 1993, 2003 and other variants where appropriate) ISO 9564-1 Financial services -- Personal Identification Number (PIN) management and security -- Part 1: Basic principles and requirements for PINs in card-based systems ISO 13491 Banking — Secure cryptographic devices, all parts © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 5 / 98 Reference ISO 20022 ATICA PCI DSS Publication Name Acquirer to Issuer Card Messages - Version 2 Message Definition Report - Part 2 Payment Card Industry Data Security Standard 1.4.2 Published EMVCo Documents The documents in Table 1.2 are related to or are associated with Payment Tokenisation. Reference Table 1.2: EMVCo References Publication Name Transaction Types EMV® Best Practices Document – Recommendations for EMV Processing for Industry-Specific Transaction Types EMV® 3-D Secure EMV® 3-D Secure – Protocol and Core Functions Specification SB-178 SB-178: Tokenisation Data Objects – Payment Account Reference (PAR) SB-197 SB-197: Tokenisation Data Objects – Token Requestor ID and Last 4 Digits of PAN A Guide to Use Cases EMV® Payment Tokenisation – A Guide to Use Cases FAQ EMV® Payment Tokenisation FAQ SRC EMV® Secure Remote Commerce Specification Use Case Submission EMV® Payment Tokenisation – Use Case Submission Template Template (requires an EMVCo Associate membership) PAR White Paper EMV® White Paper on Payment Account Reference For further information, including registration procedures, please refer to www.emvco.com. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 6 / 98 1.5 Definitions The following terms are used in this technical framework. They apply only to the context of this technical framework and are not representative of other uses outside of the scope of this technical framework. Term Table 1.3: Definitions Definition Bank Identification BINs are assigned to ISO IIN Blockholders and ISO IIN Card Issuers. Number (BIN) BIN is a term for an IIN that is consistent with ISO/IEC 7812. BIN Controller Determines the rules for use of the IINs under their control. See Section 3.11 BIN Controller for further details. BIN Controller Identifier A unique identifier consisting of four uppercase Alphanumeric Roman characters assigned by EMVCo to Registered BIN Controllers. Cardholder Any individual where a Card Issuer provides a Payment Account that is represented by one or more PANs, with each PAN typically provisioned to a card. CardholderInitiated Transaction Any transaction where the Cardholder is present and provides their payment credential. This can be through a Terminal in store or online through a checkout experience. A Cardholder-Initiated Transaction contains verification that a Cardholder was involved in the transaction. Card Issuer A financial institution or its Third Party Service Provider that provides Cardholders with a Payment Account represented by one or more PANs. Card Issuer Aggregator A specific Payment Tokenisation Aggregator role that facilitates some or all Payment Token related activities by acting as a service provider on behalf of one or more Card Issuers. Card Verification Number A security number used to authenticate the presence of the card. Examples include CAV2 / CVC2 / CVV2 / CID / CVN2. Co-Badged Card A card which has a PAN used by two or more Payment Systems. Consumer Any individual that enters a relationship with an entity where validated account credentials are used to access services. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 7 / 98 Term Definition Consumer Device Any Consumer-operated device such as a smartphone, laptop, personal computer or tablet that the Consumer uses to conduct payment activities. De-Tokenisation The process of converting a Payment Token and Token Expiry Date to its underlying PAN and PAN Expiry Date based on the Payment Token / Token Expiry Date affiliation with the underlying PAN / PAN Expiry Date stored in the Token Vault. EMV Based Application An application that uses EMV contact or contactless technology and techniques as a foundation of transaction processing. Non-EMV Based Application An application that uses a different technology than EMV contact or contactless technology and techniques as a foundation of transaction processing. ID&V The process to ensure that the legitimate Cardholder that was issued the PAN by the Card Issuer is interacting with the Token Requestor during the request of a Payment Token. This involves the verification of the previously-established identity of the Cardholder. ID&V Actor The entity performing the ID&V Method(s) as part of ID&V. ID&V Method An individual action through which an ID&V Actor may verify a previously established identity as part of ID&V. ISO IIN Blockholder A “card scheme blockholder” as defined in ISO/IEC 7812-2:2017. Card scheme blockholders represent a group of card issuers. These blockholders are assigned a block of IINs (BINs), for assignment to members of the card scheme for the purpose of issuing Primary Account Numbers (PANs). If a card issuer relinquishes membership of that scheme, the IIN reverts back to the card scheme blockholder. ISO IIN Card Issuer A “card issuer” as defined in ISO/IEC 7812-2:2017. A card issuer which will be the issuer of the cards and has applied for and been assigned by the ISO Registration Authority one or more IINs (BINs) for the purpose of issuing Primary Account Numbers (PANs). Merchant-Initiated Transaction An authorisation request that relates to a previous Cardholder-Initiated Transaction but conducted without the Cardholder present, and without any Cardholder validation performed. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 8 / 98 Term Definition PAN Authorisation The process following De-Tokenisation whereby the underlying PAN is made available to the Card Issuer for authorisation. The authorisation request message may include the Payment Token and other related data. Payment Account A representation of the unique financial relationship between account holders and a financial institution for a specific financial funding source represented by one or more PANs assigned to Cardholders. Payment Account Reference (PAR) A non-financial reference assigned to each unique PAN and used to link a Payment Account represented by that PAN to affiliated Payment Tokens. The use of the term “PAR” in this technical framework refers to the overall concept, rather than any specific component, e.g. PAR Data, PAR Field. PAR Data Refers to a specific Payment Account Reference value generated in the format specified in Table 9.1. PAR Enquiry Function A function that supports the enquiry and distribution of PAR Data using a real-time or batch process. PAR Field A message field that contains PAR Data. Payment Network A role within the Payment Tokenisation ecosystem that operates an electronic system for payment transaction processing, including operating a network switch for purposes of completing authorisation, clearing, and settlement for one or more Payment Systems. Payment Processor An existing entity in the payment ecosystem that provides payment processing services for Acquirers and / or Card Issuers. A Payment Processor may, in addition to processing, provide operational, reporting and other services for the Acquirer or Card Issuer. Payment System A role within the Payment Tokenisation ecosystem that maintains a consumer-facing brand and provides branding guidelines, inclusive of branding requirements for issuers and merchant acceptance environments, may distribute IINs / BINs, defines rules and guidelines for payment system participants, and develops products and respective product requirements for payment system participants that are derived from a variety of technologies. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 9 / 98 Term Definition Payment Token A surrogate value for a PAN that is a variable length, ISO/IEC 7812compliant numeric issued from a designated Token BIN or Token BIN Range and flagged accordingly in all appropriate BIN tables. A Payment Token must pass basic validation rules of a PAN, including the Luhn check digit. Payment Tokens must not collide or conflict with a PAN. Payment Tokenisation A specific form of tokenisation whereby Payment Tokens are requested, generated, issued, provisioned, and processed as a surrogate for PANs as described by the processes defined in this technical framework. Payment Tokenisation Aggregator A role within the Payment Tokenisation ecosystem that facilitates some or all Payment Token related activities by acting as a service provider on behalf of one or more Payment Tokenisation roles. Primary Account Number (PAN) A variable length, ISO/IEC 7812-compliant account number that is generated within account ranges associated with a BIN by a Card Issuer. Registered BIN Controller A BIN Controller that has successfully registered with EMVCo and is in receipt of an assigned BIN Controller Identifier. Registered Token A Token Service Provider that has successfully registered with EMVCo Service Provider and is in receipt of an assigned Token Service Provider Code. Third Party Service Provider An authorised entity that provides a service, capability or function, to, or on behalf of, a stakeholder in the payment ecosystem. Token Authorisation The process within Token Processing whereby a Payment Token and related data are used to facilitate a subsequent PAN Authorisation. Token Assurance The performance of ID&V within Payment Tokenisation. Token Assurance Supporting information for the Token Assurance Method. Data Token Assurance Method An updatable value that allows the Token Service Provider to communicate the ID&V performed. It is determined or updated as a result of the ID&V Method(s) and ID&V Actor. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 10 / 98 Term Definition Token Assurance Method Category A group of ID&V Method(s) with similar characteristics enabling a consistent categorisation by Token Service Providers as part of setting the Token Assurance Method. Token BIN A specific BIN that has been designated only for the purpose of issuing Payment Tokens and is flagged accordingly in BIN tables. Token BIN Range A specific BIN Range that has been designated only for the purpose of issuing Payment Tokens and is flagged accordingly in BIN tables. Token Control Fields Fields containing data that may be used to restrict Payment Token use to the appropriate Token Domains using Token Domain Restriction Controls. Token Cryptogram A cryptogram, containing a transaction-unique value, typically generated using the Payment Token, Payment Token related data and transaction data. Cryptogram derivation methods may vary by scenario and may be Payment System-specific. Token Domain The usage environment of a Payment Token. Token Domain Restriction Controls A set of parameters that are applied during Token Processing to constrain a Payment Token to the permitted usage scenarios. Token Expiry Date The expiration date of the Payment Token that is generated by and maintained in the Token Vault and is passed in the PAN Expiry Date field during Token Processing to ensure interoperability and minimise the impact of Payment Tokenisation. The Token Expiry Date is a 4-digit numeric value that is consistent with the ISO 8583 format. Token Generation The process whereby a Payment Token is generated and is assigned a value associated with a Token BIN or Token BIN Range. Token Issuance The process whereby a Payment Token and related data is issued in preparation for Token Provisioning. Token Location The mode of storage for a Payment Token and related data. Token Payment Request / Response The process within Token Processing whereby a Payment Token and related data is used to facilitate a subsequent Token Authorisation. The Token Payment Response will include results of the Token Authorisation. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 11 / 98 Term Definition Token Presentment The interaction of the Cardholder and Merchant which leads to the Payment Token being presented for payment through Token Processing. Token Presentment Mode The mode through which a Payment Token is presented to the Merchant during Token Presentment. This information resolves to an existing field called Point of Sale (POS) Entry Mode as defined in ISO 8583 messages. Each Payment Network will define and publish any new POS Entry Mode values as part of its existing message specifications and customer notification procedures. Token Processing The process whereby a Payment Token and related data is used to enable payments with PAN. Token Processing may span payment processes that include authorisation, capture, clearing, and exception processing. Token Processing is comprised of the elements: • Token Payment Request / Response • Token Authorisation • Application of Token Domain Restriction Controls • De-Tokenise / Tokenise • PAN Authorisation Token Programme A Token Programme is comprised of the policies, processes and registration programmes associated with the oversight of Token Service Providers and Token Requestors within a Payment System. Token Provisioning The process whereby a Payment Token and related data are delivered to the Token Location. Token Reference A substitute for the Payment Token that does not expose information ID about the Payment Token or the underlying PAN. Token Request The process whereby a Token Requestor requests a Payment Token from the Token Service Provider. Token Request Indicator A value used to indicate that an authentication / verification message is related to a Token Request. It is optionally passed to the Card Issuer as part of the Identification and Verification (ID&V) process to inform the Card Issuer of the reason that the account status check is being performed. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 12 / 98 Term Definition Token Requestor A role within the Payment Tokenisation ecosystem that initiates Token Requests. Each Token Requestor will be registered and identified uniquely in accordance with the policies and processes of the Token Programme. Token Requestor Aggregator A specific Payment Tokenisation Aggregator role that facilitates some or all Payment Token related activities by acting as a service provider on behalf of one or more Token Requestors. Token Requestor ID An 11-digit numeric value that identifies each unique combination of Token Requestor and Token Domain(s) for a given Token Service Provider. Token Service Provider A role within the Payment Tokenisation ecosystem that is authorised by a Token Programme to provide Payment Tokens to registered Token Requestors. Token Service Provider Code A unique three-digit value, assigned by EMVCo, to a Registered Token Service Provider. Token User A role within the Payment Tokenisation ecosystem performed by a Merchant or an entity acting on the Merchant’s behalf that initiates a Token Payment Request using a Payment Token provided by a Token Requestor. Token Vault A repository that maintains the established Payment Token / Token Expiry Date affiliation with the underlying PAN / PAN Expiry Date and includes Payment Token related data. The Token Vault may also maintain other attributes of the Token Requestor that are determined at the time of registration and that may be used to apply Token Domain Restriction Controls. Tokenisation The process within Payment Tokenisation by which the Primary Account Number (PAN) and the PAN Expiry Date are replaced with surrogate values called Payment Token and Token Expiry Date. During Token Processing, a Payment Token / Token Expiry Date may be detokenised to the underlying PAN / PAN Expiry Date and subsequently tokenised from the underlying PAN / PAN Expiry Date back to that affiliated Payment Token / Token Expiry Date. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 13 / 98 1.6 Notational Conventions 1.6.1 Abbreviations The abbreviations listed in Table 1.4 are used in this technical framework. Abbreviation AML BIN CD-CVM CDE CVM EMV 3DS HCE ICC ID&V IEC IIN ISO NFC OTP PAN PAR PCI PCI SSC Table 1.4: Abbreviations Description Anti-Money Laundering Bank Identification Number (term for IIN as defined in ISO/IEC 7812) Consumer Device CVM Cardholder Data Environment Cardholder Verification Method EMV® 3-D Secure Host Card Emulation Integrated Circuit Card Identification and Verification International Electrotechnical Commission Issuer Identification Number International Organization for Standardization Near Field Communication One-Time Password Primary Account Number Payment Account Reference Payment Card Industry Payment Card Industry Security Standards Council © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Abbreviation POS TEE Description Point Of Sale Trusted Execution Environment Page 14 / 98 1.6.2 Terminology and Conventions The following words are used often in this technical framework and have a specific meaning: SHALL / SHALL NOT Indicates mandatory requirements of this technical framework. SHOULD / SHOULD NOT Indicates guidelines recommended by this technical framework. 1.7 Further Information Additional Payment Token information can be found at www.emvco.com. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 15 / 98 2 Constraints of the Ecosystem This technical framework is designed to work within a number of constraints of the payment ecosystem, including roles of various entities, transaction flows and data definitions. The constraints include the following: • This technical framework is not intended to supersede or interfere with any international, regional, national, or local laws and regulations • Payment Tokens must preserve all product attributes of the PAN including product type, e.g. debit or credit • Token BIN or Token BIN Ranges will be made available to the parties participating in Token Processing to support routing decisions • Token BINs or Token BIN Ranges are managed distinctly from traditional BINs or BIN ranges to provide ecosystem transparency and to avoid collision or conflict between PANs and Payment Tokens • Ongoing changes to Payment Token / Token Expiry Date affiliation with the underlying PAN / PAN Expiry Date due to lifecycle management events, such as underlying PAN updates, lost or stolen devices, and deactivation of the Payment Token, are accommodated • The policies and processes of a Token Programme should minimise the impact on the existing payment processing environment in which Payment Tokenisation will be provided, e.g. Card Issuer portfolio conversions, Merchant conversions, and local network / on-us transaction routing • Merchant-Initiated Transactions only occur after an original Cardholder-Initiated Transaction © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 16 / 98 3 Payment Tokenisation Ecosystem The implementation of Payment Tokenisation as outlined by this technical framework, and in a manner consistent with this technical framework itself, involves a number of roles within the Payment Tokenisation ecosystem. Some are existing roles within the traditional payment ecosystem, and others are Payment Tokenisation specific roles defined by this technical framework. Payment Tokenisation specific roles may be performed by existing entities within the payment ecosystem or by newly-emerging entities. Entities may perform one or more Payment Tokenisation roles. Each of the Payment Tokenisation roles are described in more detail in the subsequent subsections. 3.1 Cardholder Cardholders will continue in their current role. Payment Tokenisation does not impact the existing Cardholder and Card Issuer relationship. Cardholders will continue to be issued PANs representing the Payment Account. In most cases, a Cardholder is not expected to know that a Payment Token has been issued to represent an underlying PAN of the Payment Account. Optionally, the Token Requestor or Card Issuer may choose to make a Cardholder aware of the Payment Token. As part of establishing Token Assurance, Cardholders may be required to participate in ID&V. Cardholders will generally be unaware of PAR Data. This will not adversely impact the ability of Cardholders to transact. 3.2 Card Issuer Card Issuers will continue in their current role in terms of owning the Payment Account relationship with the Cardholder(s), authorisation and ongoing risk management in the Payment Tokenisation ecosystem. Card Issuers need to coordinate with their Registered BIN Controllers to understand the applicability and the governance of the PAR Field and PAR Data as implemented by the Payment Networks. The Card Issuer SHOULD ensure that PAR Data is made available to all entities within the ecosystem. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 17 / 98 3.3 Merchant Merchants will continue in their current role processing transactions, including Payment Token based transactions. This includes authorisation, capture and exception processing. Merchants will need to implement any Merchant requirements defined by the Merchant’s Acquirer or Payment Processor, including the support of Payment Tokenisation specific fields and interfaces. Merchants may receive a Payment Token and related data, including the Token Expiry Date, during Token Presentment in any of the following scenarios: • From the Cardholder using the Cardholder’s Consumer Device • As a Token Requestor either directly or via an intermediary • As a Token User via the Token Requestor’s interfaces A Payment Token is constrained by its Token Domain Restriction Controls. Examples include constraining the use of a Payment Token: • To a single Merchant • To a specific Token Presentment Mode • For a single Cardholder-Initiated Transaction and subsequent Merchant-Initiated Transactions Merchants may implement the PAR Field and PAR Data in their payment processing environment based on requirements established by the Merchant’s Acquirer or Payment Processor. Implementation of PAR can help with the tracking of customer transactions. 3.4 Acquirer Acquirers will continue in their current role, processing all transactions, including Payment Token based transactions. This includes authorisation, capture, clearing, and exception processing. Additional Payment Tokenisation specific fields may be used to support Token Processing as defined in the interfaces governed by the Payment Networks or Acquirer. Acquirers SHOULD implement the PAR Field and PAR Data in their payment processing environment as defined by the Payment Networks the Acquirer supports. 3.5 Payment System Payment Systems will continue in their current role and SHOULD support Payment Tokenisation in accordance with this technical framework. Payment Systems that support © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 18 / 98 Payment Tokenisation are responsible for defining the policies, processes and registration programmes that comprise their Token Programme. Payment Systems need to consider the business, technical and processing implications and communicate their requirements to all appropriate stakeholders. Payment Systems that are Registered BIN Controllers define the governance of the PAR Field and PAR Data within Payment Networks, including supporting the PAR Field and PAR Data. Payment Systems that are not Registered BIN Controllers need to coordinate with their Registered BIN Controllers to understand the applicability and the governance of the PAR Field and PAR Data as implemented by the Payment Networks. Payment Systems SHOULD include PAR Data with all transactions that they process. 3.6 Payment Network Payment Networks will continue in their current role and SHOULD support the implementation of Token Processing functions within a Token Programme. Payment Networks are responsible for defining and publishing the authorisation, clearing, and exception processing message interfaces and Payment Tokenisation specific fields that impact Token Processing in various Payment Tokenisation scenarios. Payment Networks are responsible for supporting the implementation of the PAR Field in their message specification in accordance with Registered BIN Controllers. Payment Networks SHOULD support the communication of PAR Data for all transactions that they process. 3.7 Token Service Provider The Token Service Provider is a Payment Tokenisation specific role. Token Service Providers are responsible for a number of discrete functions which may include, but are not limited to: • Maintenance and operation of a Token Vault • Token Generation • Application of security and related controls • Token Issuance and Token Provisioning, including the facilitation of PAR Field and PAR Data in provisioning requests • Token Requestor registry functions • De-Tokenisation and Tokenisation © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 19 / 98 • Application of Token Domain Restriction Controls during Token Processing Token Service Providers may engage with a variety of types of Token Requestor as part of their ongoing participation in a Token Programme. 3.8 Token Requestor The Token Requestor is a Payment Tokenisation specific role. Token Requestors register with one or more Token Service Providers in order to request Payment Tokens. Token Requestor registration is managed in accordance with the policies and processes of each Token Programme. Token Requestors vary in nature and may support a variety of usage scenarios. Upon registering with a Token Service Provider, Token Requestors will be assigned one or more unique Token Requestor IDs. Multiple Token Requestor IDs can be assigned to a Token Requestor to support different usage scenarios. Token Requestors are responsible for using the appropriate Token Requestor ID when requesting Payment Tokens. Token Requestors can request Payment Tokens for their own use or for use by one or more Token Users. Usage of Payment Tokens is constrained by their Token Domain Restriction Controls. Token Requestors are responsible for managing both Payment Tokens and any Token Users they support. When providing a Payment Token to a Token User, the Token Requestor SHOULD provide the PAR Data associated with that Payment Token. 3.9 Token User The Token User is a Payment Tokenisation specific role. Token Users initiate Token Payment Requests with Payment Tokens which have been received from Token Requestors. The Token User will have a relationship with one or more Token Requestors. Token Requestors may define requirements for the use of Payment Tokens which they provide to Token Users. The use of each Payment Token is constrained by its Token Domain Restriction Controls. 3.10 Payment Tokenisation Aggregator The Payment Tokenisation Aggregator is a Payment Tokenisation specific role. Payment Tokenisation Aggregators integrate with one or more Token Service Providers in order to facilitate some or all Payment Token related activities, including the communication of PAR Data, by acting as a service provider on behalf of one or more Payment Tokenisation roles or existing ecosystem entities. Payment Tokenisation Aggregator registration is managed in accordance with the policies and processes of each Token Programme. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 20 / 98 This technical framework identifies the following specific types of Payment Tokenisation Aggregator: • Token Requestor Aggregator • Card Issuer Aggregator 3.11 BIN Controller BIN Controllers will continue in their current role, determining the rules for use of the IINs (commonly referred to as BINs) under their control from which PANs are generated. A BIN Controller is either an: • ISO IIN Blockholder • ISO IIN Card Issuer For the purpose of clarity, Card Issuers who have been assigned BIN(s) by an ISO IIN Blockholder are not BIN Controllers for the BINs assigned by an ISO IIN Blockholder. BIN Controllers which support PAR as a linkage mechanism must register with EMVCo to receive a BIN Controller Identifier. Registered BIN Controllers determine the governance of the PAR Field and PAR Data for the BINs under their jurisdiction. Registered BIN Controllers define how the unique characters of PAR Data are generated and communicate to their constituents the generation method for PAR Data along with the specific usage for PAR Data for Payment Tokens and underlying PANs. BIN Controllers which support Card Issuers that issue cards where the same PAN is used by different Cardholders SHALL ensure that: • Different PAR Data is allocated for each unique Cardholder • 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 SHOULD determine the requirements for PAR Data as it relates to PAN and the presence on PAN-related messages. Card Issuers who have been assigned BIN(s) by an ISO IIN Blockholder must follow the PAR Field and PAR Data governance and requirements of the ISO IIN Blockholder that is also the Registered BIN Controller for those BINs assigned by the ISO IIN Blockholder. There is no expectation that PAR Data generation methods will be consistent across Registered BIN Controllers. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 21 / 98 3.12 Illustrative Payment Token Process Overviews The following diagrams (Figure 3.1 and Figure 3.2) provide high-level overviews of two of the processes involved in the Payment Tokenisation ecosystem. There are many different implementations for the various processes. Each diagram only shows one potential implementation, which is not intended to be definitive. © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 22 / 98 Figure 3.1 gives an example flow for Token Request where the Merchant is performing the role of the Token Requestor, with optional ID&V carried out by the Card Issuer in conjunction with the Token Service Provider. Figure 3.1: Token Request Overview Cardholder PAN Token Requestor Merchant PAN Payment Token Token Service Provider Card Issuer Legend Existing Payment Ecosystem Interaction Token Service Provider Interfaces (Section 8) Optional ID&V Interaction © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 23 / 98 Figure 3.2 gives an example of how a Payment Token transaction might occur. The figure only includes those roles that are specific to Payment Tokenisation. All existing transaction processing roles continue as normal. Figure 3.2: Payment Token Transaction Overview Token Presentment Cardholder Token Processing Merchant Token Payment Request Transaction Routing Token Authorisation De-Tokenise / Tokenise Application of Token Domain Restriction Controls PAN Authorisation Card Issuer © 2014-2026 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. EMV Payment Tokenisation Specification Technical Framework v2.4 DRAFT Page 24 / 98 4 Token Programme A Token Programme is comprised of the: • Policies, processes and registration programmes that facilitate generation and issuance of Payment Tokens by Token Service Providers to registered Token Requestors using designated Token BIN or Token BIN Ranges • Policies and processes for De-Tokenisation, and the application of Token Domain Restriction Controls during Token Processing • Policies and processes for the enforcement of the Registered BIN Controller’s PAR governance requirements An entity introducing Payment Tokenisation to an existing payment ecosystem is responsible for defining the policies, processes and registration programmes that comprises its Token Programme. Authorised entities, including Token Service Providers and Token Requestors, will need to adhere to the relevant policies, processes, and registration programmes when operating within a Token Programme. The following minimum policies should be considered in order to establish and maintain a Token Programme: • Affiliation of Payment Tokens / Token Expiry Dates with underlying PANs / PAN Expiry Dates for use in Token Processing • Registration and approval of Token Requestors, Token Service Providers and other authorised entities • Determination of Token Assurance Methods to indicate the ID&V performed • Security requirements and controls related to the Token Vault, Token Provisioning and Token Processing • Permissible Token Domain Restriction Controls • Requirements for Payment Tokenisation and PAN lifecycle management • Requirements for PAR Data and PAR Field The following minimum processes should be considered in order to support Payment Tokenisation within a Token Programme: • Numeric management of PANs and Payment Tokens • Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance, Token Location an