MS
Uploaded byMadhuka De Silva
PPTX, PDF1,973 views

Tokenisation 2.0

This document discusses Payment Tokenisation 2.0 by EMVCo. It outlines the key concepts and roles in the payment tokenisation ecosystem, including token requestors, token service providers, and token vaults. It describes the processes for obtaining a token through a token request, issuing a token by performing token assurance, generation, and provisioning. It also covers token transaction processing flows, including token payment requests, domain restriction controls, de-tokenisation to PAN, authorization, and re-tokenisation.

Embed presentation

Downloaded 92 times
Tokenisation 2.0 By EMVCo
EMVCo ● Worldwide interoperability & acceptance of secure payment transactions ● 6 member organisations : American Express, Discover, JCB, Mastercard, UnionPay, and Visa ● Separate working group “Tokenisation Working Group”
Tokenisation Concept of replacing high-value data with low-value representation, While making it useful only for a transaction taking place in a specific domain
Tokenisation Concept of replacing high-value data with low-value representation, While making it useful only for a transaction taking place in a specific domain
Tokenisation Replacing the 16 digit account number, Primary Account Number (PAN) with a unique digital identifier called a TOKEN T
Payment Tokenisation 1.0 ● Tokenisation Ecosystem Environment ● Token Service Provider requirements ● Token Assurance ID&V Methods ● Payment Token processing ● Payment Token Transaction Flows
Payment Tokenisation 2.0 ● Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
Payment Tokenisation Ecosystem ● Cardholder ● Card Issuer ● Merchant ● Acquirer ● Payment System & Payment Network ● Token Requestor & Token User ● Token Service Provider
Token Service Provider Entities authorised to provide Payment Tokens to registered Token Requestors within a Token Programme T
Token Service Provider Ctd. ● Registering with EMVCo ● Registration and management of Token Requestors ● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance and Token Provisioning ● Maintenance of security and related controls ● Establishing Token Domain Restriction Controls ● Support and management of Token Processing, including De-Tokenisation T
Token Service Provider Ctd. ● Responsible for integrating into relevant Token Programmes ● Building and managing interfaces that integrate with Token Requestors and Card Issuers ● Operate a Token Vault in accordance with the policies and processes T
Payment Token Process 1 Obtaining a Token
Cardholder Merchant Token Requestor Token Service Provider Card Issuer PAN PAN Request Response Request Response T T T
Token Request
Token Requestors Provide Token Service Providers and Card Issuers with information that helps identify a number of elements that can be used within Token Provisioning to facilitate Token Issuance
Token Requestor Types ● Acquirer ● Card Issuer ● Merchant ● Third Party Wallet ● Payment Enabler ● Payment Intermediary ● Payment Manager
Acquirer [Token Requestor Type] Commercial relationship with the Merchant and with the Payment System Processes payment transactions through a Payment Network(s) on behalf of the Merchant. Behalf of the Merchant, ● Manages and stores PAN or Payment Token ● Initiate Token Payment Requests ● Stores payment-related data ● Directly involved in Token Processing but no direct relationship with the Consumer
Card Issuer [Token Requestor Type] ● Single issuer programme is enabled OR ● Financial institution offering a service directly to their Cardholders / clients. ● Single Card Issuer branded application Token Processing occurs directly with the Merchant. ● Services may be provided through home banking interface. ● Financial services provided directly to their Cardholders. ● No unique Merchant integration is required.
Merchant [Token Requestor Type] ● A Merchant that does business for itself and / or its subsidiaries. ● Provides Merchant-branded checkout experience. ● A direct relationship exists between the Cardholder and Merchant. ● Token Payment Request initiated by Merchant using a unique Payment Token assigned to the Merchant, not a Shared Payment Token
Third Party Wallet [Token Requestor Type] ● A digit wallet branded by a third party where multiple Card Issuer programmes co-exist. ● The digital wallet application is only provided directly to the Consumer and not through an Issuer.
Payment Enabler [Token Requestor Type] ● A non-Card Issuer third party where multiple Card Issuer programmes are enabled through a single consumer interface. Payment Enabler Card Issuer 1 Card Issuer 2 Card Issuer 3 singleconsumerinterface
Payment Intermediary [Token Requestor Type] ● An entity that provides Consumer authentication and passes payment credentials to a Merchant but is not directly involved in Token Processing.
Payment Manager [Token Requestor Type] ● An entity that does not interface directly with the Consumer but facilitates payments for the Merchant.
Payment Tokenisation 2.0 ● Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases T
Token Request Registered Token Requestor requests a Payment Token from the Token Service Provider. Token Requestor needs to provide a PAN or a Payment Token / Token Reference ID. 2 types of Token Requests: ● Token Request with PAN ● Token Request with Payment Token / Token Reference ID T
Token Request with PAN [Token Request Type] The Token Service Provider SHALL provide a common method that a registered Token Requestor can use to submit a request through. Fields for Token Request with PAN: PAN, PAN Expiry Date, Token Requestor ID, Token Assurance Method & Data, Token Location, Device Information (subjected to Conditions such as R – Required, C – Conditional, O – Optional) PAN
Token Request with Payment Token / Token Reference ID [Token Request Type] The Token Service Provider SHALL provide a common method that a registered Token Requestor can use to submit a request through. 2 possibilities: Token Requestor is the same as the Token Requestor associated with the input Payment Token, and not the same Fields for Token Request with a Payment Token / Token Reference ID: Token Expiry Date, Token Requestor ID, Token Request Authorisation, Payment Token, Token Reference ID, Token Assurance Method & Data, Token Location, Device Information (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T T
Issuance of Payment Tokens
Token Service Provider [TSP] ● Registering with EMVCo ● Registration and management of Token Requestors ● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance and Token Provisioning ● Maintenance of security and related controls ● Establishing Token Domain Restriction Controls ● Support and management of Token Processing, including De-Tokenisation T
Step 1: Token Assurance ● Performing ID&V prior to Token Issuance to verify that the Cardholder is the rightful user of the PAN. ● This binds the Payment Token to the underlying PAN and Cardholder. T
Step 1: Token Assurance Ctd Verification Methods Used ● Card Issuer Account Verification ● Interactive Cardholder Authentication – 1 Factor ● Interactive Cardholder Authentication – 2 Factor (Capable of supporting 3-D Secure) ● Risk Oriented Non-Interactive Cardholder Authentication ● Card Issuer Asserted Authentication T
Payment Tokenisation 2.0 ● Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
Step 2:Token Generation Process of creating a Payment Token and its associated Token Expiry Date for a specific underlying PAN for use by a specific Token Requestor and Token Domain(s), as identified the Token Requestor ID. ● The Token Service Provider SHALL provide the Token Vault with the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date. T
Step 3:Token Issuance ● Process of issuing a Payment Token and related data in preparation for Token Provisioning. ● Token Service Providers SHALL only issue Payment Tokens through the response to a Token Request from a registered Token Requestor with a valid Token Requestor ID. T
Step 4: Token Provisioning Process of delivering a Payment Token and related data to the Token Location. T
Token Response For any Token Request, the interfaces SHALL provide a response message Fields for Response to Token Request: Request Status, Reason Code, Token Expiry Date, Token Reference ID, Payment Token, Token Reference ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
Payment Token Process 2 Payment Token Transaction Processing
Cardholder Merchant Card Issuer Transaction Routing De-Tokenise/ Re-Tokenise Domain Restriction Controls Token Payment Request Token Authorisation Request PAN Authorisation Request T T T T PAN Authorisation Response Token Authorisation Response T TToken Service Provider Response Acquirer To Payment Network
Types of Transactions
Cardholder-Initiated Transaction Cardholder directly presents a payment credential. May use various authentication and verification features. T Mobile NFC at Point of Sale Mobile / Digital Wallet E-Commerce Card-On-File E- Commerce
Merchant-Initiated Transaction Always a result of a previous Cardholder interaction Types: ● Industry-specific authorisation practices extends the initial Cardholder-Initiated Transaction ● Standing instructions that provide express permission for additional purchases T
Token Payment Request Originates from the point of interaction between the Cardholder and the Merchant (such a Terminal, website or application) For the purposes of Token Processing, the fields and data included in Token Payment Requests are defined AND These are following existing message standards. Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference (subjected to Condtions such as R – Required, C – Conditional, O – Optional) T
Transaction Routing Routing and Account Range Tables: Need to clearly distinguish Token BINs and Token BIN Ranges from traditional PAN BINs and PAN BIN ranges in order to ensure the underlying integrity of payment processing. T
Transaction Routing Ctd. Payment Network The Payment Network may interface with the Token Service Provider in order to verify the state of the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date in the Token Vault for the affiliated Payment Token. The Payment Network SHOULD be aware that a Payment Token transaction may include a Token Cryptogram and authentication data.
Token Authorisation Request Includes the request between the Acquirer and the Payment Network ● Not including Token Domain Restriction Controls ● Not including De-Tokenisation ● Token Authorisation request process continues until De-Tokenisation has been completed
Token Authorisation Request Ctd. After receipt of the Token Payment Request, Acquirer ● Performs routine processing checks ● Pass the Token Processing related data and other relevant payment data to the Payment Network (including setting the Token Presentment Mode to indicate the specific method in which the Payment Token was input into the Terminal or other Merchant point of interaction)
Token Authorisation Request Ctd. For the purposes of Token Processing, the fields and data included in Token Authorisation are defined AND These are following existing message standards. Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
Token Domain Restriction Controls ● Optionally performed ● Validating the Payment Token against the established Token Domain Restriction Controls ● Processing may be performed independently of the De-Tokenisation function
Token Domain Restriction Controls Ctd. Controls depend upon the availability of specific Token Control Fields and Payment Token related data in Token Processing messages to restrict Payment Token use to the appropriate Token Domain(s). Token Service Providers and participating Payment Networks provide the Token Control Field. Types based on transactions: ● Cardholder-Initiated ● Merchant-Initiated
Cardholder-Initiated Transaction Cardholder-Initiated Transactions SHALL contain the relevant cryptography generated during the payment interaction and be validated. Token Control Fields: Token Cryptogram, POS Entry Mode, Merchant Identifiers (subjected to Condtions such as R – Required, C – Conditional, O – Optional)
Merchant-Initiated Transaction When the Merchant is the Token Requestor, Merchant-related fields in the existing ISO 8583 messages SHOULD be used to limit the use of a Payment Token. Token Control Fields: Token Cryptogram, POS Entry Mode, Original Transaction Reference, Merchant-Initiated Transaction Identifier (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
De-Tokenisation Converting a Payment Token and Token Expiry Date to an underlying PAN and PAN Expiry Date. May or may not include the application of Token Domain Restriction Controls. T PAN
De-Tokenisation Ctd. Fields Included in De-Tokenisation Requests: Payment Token, Token Expiry Date T
PAN Authorisation The Card Issuer completes the PAN-level and Account-level validation and the authorisation check, and returns the PAN in the authorisation response. PAN
PAN Authorisation Request Request to the Card Issuer. Contains the data necessary, including Token Processing related data, to determine the Card Issuer authorisation decision. For the purposes of Token Processing, the fields and data associated with PAN Authorisation requests are defined AND These are following existing message standards. Examples: Payment Token (PAN), PAN Expiry Date, POS Entry Mode, Token Requestor ID, Token Expiry Date, Token Assurance Method & data, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) PAN T
PAN Authorisation Response Corresponding response from the Card Issuer on the notification of the approve or decline decision. For the purposes of Token Processing, the fields and data associated with PAN Authorisation responses are defined AND These are following existing message standards. Examples: Payment Token (PAN), Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T PAN
Re-Tokenisation Includes the corresponding response process, PAN and PAN Expiry Date are tokenised back to the affiliated Payment Token and Token Expiry Date. TPAN
Re-Tokenisation Ctd. Fields Included in De-Tokenisation Responses: PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
Token Authorisation Response Response between the Payment Network and the Acquirer ● Not including Tokenisation & application of Token Domain Restriction Controls. ● Relevant response data comes from the PAN Authorisation response. T
Token Authorisation Response Ctd. For the purposes of Token Processing, the fields and data included in Token Authorisation are defined AND These are following existing message standards. Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
Token Payment Response Provides the results of the authorisation decision For the purposes of Token Processing, the fields and data included in Token Payment Response are defined AND These are following existing message standards. Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T T
Token Vault ● Storage and mechanism for Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date ● Storage of the association between a Payment Token and its assigned Token Domain Restriction Controls ● Strong physical and logical security measures
Token Vault Ctd. Additional ● Large issuers are developing their own token vaults with own databases that translates a PAN to a token ● Visa, MasterCard and American Express supplies for Tokenisation vault services ( Example: Apply pay uses these services)
Token Location ●The mode of storage for a Payment Token and related data ●The Token Location SHALL NOT change during the life of the Payment Token
Token Location Description 00 Not specified 01 Remote storage: e.g. a single Merchant’s card-on-file data store 02 EMVCo and Payment System type approved secure element / Integrated Circuit Card (ICC) 03 Local device storage: e.g. Payment Token and related data stored using the data storage mechanisms of a Cardholder device, such as when utilising Host Card Emulation (HCE) 04 Local hardware secured storage: e.g. using a Trusted Execution Environment (TEE) to ensure appropriately restricted access to data 05 Remote hardware secured storage: e.g. ISO 13491 compliant storage 06 Shared storage: e.g. e-commerce multi-merchant wallet accessing a card-on-file data store 07 Temporary storage: e.g. guest checkout 08 – 99 Reserved for future use
Token Service Provider Interfaces Common fields of any external interface that each Token Service Provider supports. Examples of the authenticated methods through which these interactions may occur: ● Web services ● ISO 8583 message exchange through an existing Payment Network interface ● File / batch
Token Service Provider Interfaces Ctd. The interfaces SHOULD be implemented and made available by the Token Service Provider to be used by all participating entities that interact with the Token Service Provider.
Token Service Provider Interfaces Ctd. Examples: ● Unlink Payment Token ● Suspend Payment Token ● Activate Payment Token ● Update Payment Token Attributes ● Update PAN Attributes
Payment Tokenisation 2.0 ● Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
Token Programme Comprised of the policies, processes and registration programmes facilitating: ● Generation and issuance of Payment Tokens. ● De-Tokenisation ● Token Domain Restriction Controls ● Token Vault
Payment Tokenisation Requirements Baseline requirements for Payment Tokenisation for: ● Token Service Provider ● Token Requestor ● Additional Stakeholders ● Token Vault ● Token Location
Payment Account Reference (PAR) Linkage mechanism of Token Processing transactions with transactions associated with the underlying PAN without the Full PAN being available Term “PAR” in this technical framework refers to the overall concept, rather than any specific component (for example,PAR Data, PAR Field).
PAN vs PAR Field Name Length Format PAN Variable (up to 19) Numeric PAR 29 Alphanumeric *Implementation of field formats is defined by each Token Service Providers’ interface. *Alphanumeric fields consist of uppercase Alphanumeric Roman characters.
T PAR T T
Payment Account Reference (PAR) Ctd. ● Implementation of PAR is outside of the scope of this technical framework and EMVCo. ● Payment Tokens affiliated with the same underlying PAN will consistently have the same PAR Data assigned. ● PAR Data is unique in its assignment to a given PAN and is not intended to be a PAN replacement or a consumer identifier.
PAR and EMV Terminal Processing ● EMVCo has defined EMV Tag ‘9F24’ for the identification of PAR data provisioned in an EMV based Card / Form Factor. ● The terminal SHOULD be able to support the EMV Tag without disruption to the terminal. ● The terminal SHOULD be capable of reading PAR data. ● The terminal SHOULD pass PAR data to the Merchant’s POS system. ● The terminal SHOULD pass PAR data with other EMV data to the Merchant’s Payment Processor or Acquirer.
Shared Payment Token (Use Case 4) Attribute Potential Considerations Token Domain Restriction Controls Token Domain Restriction Controls may include: Token Cryptogram POS Entry Mode Merchant Identifiers Note: POS Entry Mode is set to indicate an e-commerce transaction. Token Location The Token Location may include: 06 Shared Storage 07 Temporary Storage Cardholder Point of Interaction A Cardholder registers and interacts with either the Token Requestor or with each individual Merchant (Token User). A transaction is undertaken using the Shared Payment Token and may incorporate transaction specific Token Processing related data e.g. Token Cryptogram. Token User integration with the Token Requestor to enable a transaction may be required.
T PAR T T Merchant Merchant Merchant
Response/Request with Fields Type Fields Token Request with PAN PAN, PAN Expiry Date, Token Requestor ID, Token Assurance Method & Data, Token Location, Device Information Token Request with Payment Token / Token Reference ID Token Expiry Date, Token Requestor ID, Token Request Authorisation, Payment Token, Token Reference ID, Token Assurance Method & Data, Token Location, Device Information Token Response Request Status, Reason Code, Token Expiry Date, Token Reference ID, Payment Token, Token Reference ID, Token Assurance Method, Payment Account Reference Token Payment Request Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference
Response/Request with Fields Ctd. Type Fields Token Authorisation Request Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference Domain Restriction Controls for Cardholder-Initiated Token Cryptogram, POS Entry Mode, Merchant Identifiers Domain Restriction Controls for Merchant-Initiated Token Cryptogram, POS Entry Mode, Original Transaction Reference, Merchant-Initiated Transaction Identifier De-Tokenisation Request Payment Token, Token Expiry Date De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference
Response/Request with Fields Ctd. Type Fields PAN Authorisation Request Payment Token (PAN), PAN Expiry Date, POS Entry Mode, Token Requestor ID, Token Expiry Date, Token Assurance Method & data, Payment Account Reference PAN Authorisation Response Payment Token (PAN), Payment Account Reference Token Authorisation Response Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference Token Payment Response Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference
Field Name Length Format PAN Variable (up to 19) Numeric PAN Expiry Date 4 Numeric PAR 29 Alphanumeric Token Requestor ID 11 Numeric Token Assurance Method 2 Numeric Token Location 2 Numeric Token Assurance Data Variable Implementation Specific Device Information Variable Alphanumeric Data Fields
Field Name Length Format Token Request Authorisation Variable Implementation Specific Payment Token Variable (up to 19) Numeric Token Expiry Date 4 Numeric Token Reference ID Variable Implementation Specific Request Status 1 Numeric Reason Code Variable Alphanumeric Transaction Data Variable Implementation Specific Token Cryptogram Variable Implementation Specific Data Fields Ctd.
Thank you Update completed
References https://www.emvco.com/about/overview/ https://www.emvco.com/wp-content/uploads/2017/03/EMVCo-Website-Content-8.0-Operating- Principles-PDF_v1.1-1.pdf https://www.emvco.com/about/working-groups/ http://www.paymentscardsandmobile.com/emv-payment-tokenization-2-0/ https://www.emvco.com/wp- content/uploads/2017/09/EMV_Payment_Tokenisation_Technical_Framework_PR_FINAL.pdf https://www.pymnts.com/in-depth/2014/visas-next-big-business-tokens-and-data/ http://www.sequent.com/what-is-tokenization/ https://www.vantiv.com/about/newsroom/article-payments-networks-101
Additional for FAQ
Will Tokenisation replace EMV or provide another option? ●EMV as the security for a plastic card in a card-present transaction ●Tokenisation as the security for digital transactions, whether mobile or online. ●Still, BOTH helps to secure our payment system
Payment Account ●The unique financial relationship between account holder(s) and a financial institution for a specific financial funding source (e.g. credit, debit, commercial, prepaid) represented by one or more PANs.
Are tokens valid for one payment transaction only? No! ●The payments industry has moved away from single-use tokens due to the valid concern that we will quickly run out of unique tokens. ●As a solution one can use more of Shared Tokens! Example: In Apple Pay, a token (for a specific phone) does not change. It is the same token used for all transactions. What changes is a cryptogram, which is different for each transaction and ensures that a token cannot be duplicated and used elsewhere.
What does Tokenisation have to do with Host Card Emulation (HCE)? Host Card Emulation > placing card data in the cloud Why? ● To avoid all the technical and business complexities of card credentials stored on devices in secure elements, financial institutions are looking to move card credential data to the cloud. ● Reducing the number of actors and barriers to integration to existing systems Example: Android’s support for Host Card Emulation in the KitKat OS Tokenisation comes in? Passing encrypted card data every time a user wants to transact is simply not feasible from both a security and user experience point of view

More Related Content

PDF
What is a Token Service Provider?
byRambus Inc
 
PPTX
Payment Card System Overview
byNarudom Roongsiriwong, CISSP
 
PDF
Card payment evolution v1.0
byNugroho Gito
 
PDF
What is Payment Tokenization?
byRambus Inc
 
PPTX
ISO 8583 Financial Message Format
byMd. Hasan Basri (Angel)
 
PDF
EMV Overview
byKona Software Lab Limited.
 
PPTX
EMV chip cards
byDilip Kumar
 
PPTX
Payment gateway/payment service providers and future trends in mobile payment...
byDanail Yotov
 
What is a Token Service Provider?
byRambus Inc
 
Payment Card System Overview
byNarudom Roongsiriwong, CISSP
 
Card payment evolution v1.0
byNugroho Gito
 
What is Payment Tokenization?
byRambus Inc
 
ISO 8583 Financial Message Format
byMd. Hasan Basri (Angel)
 
EMV Overview
byKona Software Lab Limited.
 
EMV chip cards
byDilip Kumar
 
Payment gateway/payment service providers and future trends in mobile payment...
byDanail Yotov
 

What's hot

PPT
Introduction to Tokenization
byNabeel Yoosuf
 
PPTX
Introduction to Token Service Provider (TSP) Certification
byKimberly Simon MBA
 
PPT
Payment Gateway
byAshraf Bashir
 
PPTX
Blockchain Tokenization
byBellaj Badr
 
PPTX
Atm transaction
byKeerthi Reddy
 
PPTX
How an online payment gateway works
byIkajo International
 
PDF
An Overview of Stablecoin
by101 Blockchains
 
PDF
Crypto Wallet Types Explained
by101 Blockchains
 
PPTX
Payment Gateway
byAsif Hussain
 
PPTX
What is tokenization in blockchain?
byUlf Mattsson
 
PDF
Examples of Smart Contracts
by101 Blockchains
 
PPTX
EMV Card Migration: How the EMV Transaction Flow Works
byAnnMargaret Tutu (AMT)
 
PPTX
Cryptocurrency
byMZain17
 
PPTX
One Time Password - A two factor authentication system
bySwetha Kogatam
 
PDF
Introduction To Solidity
by101 Blockchains
 
PDF
PoW vs. PoS - Key Differences
by101 Blockchains
 
PPTX
Online Payment Gateway System
byMannu Khani
 
PPTX
Stablecoin
byHu Kenneth
 
PPTX
One time password(otp)
byAnjali Agrawal
 
PDF
Payments 101 - Visual Diagrams
byKapish Kaushal
 
Introduction to Tokenization
byNabeel Yoosuf
 
Introduction to Token Service Provider (TSP) Certification
byKimberly Simon MBA
 
Payment Gateway
byAshraf Bashir
 
Blockchain Tokenization
byBellaj Badr
 
Atm transaction
byKeerthi Reddy
 
How an online payment gateway works
byIkajo International
 
An Overview of Stablecoin
by101 Blockchains
 
Crypto Wallet Types Explained
by101 Blockchains
 
Payment Gateway
byAsif Hussain
 
What is tokenization in blockchain?
byUlf Mattsson
 
Examples of Smart Contracts
by101 Blockchains
 
EMV Card Migration: How the EMV Transaction Flow Works
byAnnMargaret Tutu (AMT)
 
Cryptocurrency
byMZain17
 
One Time Password - A two factor authentication system
bySwetha Kogatam
 
Introduction To Solidity
by101 Blockchains
 
PoW vs. PoS - Key Differences
by101 Blockchains
 
Online Payment Gateway System
byMannu Khani
 
Stablecoin
byHu Kenneth
 
One time password(otp)
byAnjali Agrawal
 
Payments 101 - Visual Diagrams
byKapish Kaushal
 

Similar to Tokenisation 2.0

PDF
v 1.0
byVinod Amarathunga
 
PPTX
Tim sloane preparing for rapid payments innovation
byCO-OPFinancialServices
 
PDF
Digital Payments - Netcetera Innovation Summit 2018
byNetcetera
 
PDF
Increase conversion, convenience and security in e-commerce checkouts - Silke...
byNetcetera
 
PPTX
CARTES2015 PEP Card - FINAL
byMilos Dunjic
 
PDF
The Future of Payments
byNetcetera
 
PDF
Merchant tokenization and EMV® Secure Remote Commerce
byNetcetera
 
PDF
Introduction to Token Service Provider (TSP) Certification
byControlCase
 
PDF
Digital Payment Quo Vadis
byNetcetera
 
PDF
Can security and convenience go hand in hand in e-commerce
byMercury Processing Services International
 
PDF
Digital Payment in 2020 - Kurt Schmid, Netcetera
byNetcetera
 
PDF
Payment trend scouting - Kurt Schmid, Netcetera
byNetcetera
 
PDF
Tokenization Payment Data Out Securing Payment Data Storage
by- Mark - Fullbright
 
PDF
key-trends-in-merchant-security
byKerri Lorch
 
PDF
electronic commerce payment systems
bytumetr1
 
PPTX
Unified payment interface and its security
byAkshay Dixit
 
PDF
Multiple tokenization schemes meet the merchant
byUlf Mattsson
 
PPTX
Class 11
byDr. Ajith Sundaram
 
PDF
Kanako Yokoi The Direct Infringement Of Method Claim Ppt
byKanako Yokoi
 
PPT
Pcitf iiw10
bySteve Sidner
 
v 1.0
byVinod Amarathunga
 
Tim sloane preparing for rapid payments innovation
byCO-OPFinancialServices
 
Digital Payments - Netcetera Innovation Summit 2018
byNetcetera
 
Increase conversion, convenience and security in e-commerce checkouts - Silke...
byNetcetera
 
CARTES2015 PEP Card - FINAL
byMilos Dunjic
 
The Future of Payments
byNetcetera
 
Merchant tokenization and EMV® Secure Remote Commerce
byNetcetera
 
Introduction to Token Service Provider (TSP) Certification
byControlCase
 
Digital Payment Quo Vadis
byNetcetera
 
Can security and convenience go hand in hand in e-commerce
byMercury Processing Services International
 
Digital Payment in 2020 - Kurt Schmid, Netcetera
byNetcetera
 
Payment trend scouting - Kurt Schmid, Netcetera
byNetcetera
 
Tokenization Payment Data Out Securing Payment Data Storage
by- Mark - Fullbright
 
key-trends-in-merchant-security
byKerri Lorch
 
electronic commerce payment systems
bytumetr1
 
Unified payment interface and its security
byAkshay Dixit
 
Multiple tokenization schemes meet the merchant
byUlf Mattsson
 
Class 11
byDr. Ajith Sundaram
 
Kanako Yokoi The Direct Infringement Of Method Claim Ppt
byKanako Yokoi
 
Pcitf iiw10
bySteve Sidner
 

Recently uploaded

PDF
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
PDF
What Is the Azure AI Foundry and Why Does It Matter for Enterprises?
byjohncarterjn
 
PDF
2026_01_28 - OpenMetadata Community Meeting.pdf
byOpenMetadata
 
PDF
Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]
byHaim Michael
 
PDF
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
PDF
When Drones Decide for Themselves_ Inside the Rise of Machine-Led Flight.pdf
byLyra Anderson
 
PDF
Post-Hackathon-Learnings-Maximizing-Impact-Beyond-the-Event.pdf
byishantyadav1111
 
PPTX
TechSprint WinterHack — Top 10 Teams Pitching Session we are excited for pit...
bybajpaitusharoffon678
 
PDF
EU regulations for the North American book supply chain - Tech Forum 2026
byBookNet Canada
 
PDF
Website Redesign Vs Website Refresh, What’s Right for You in 2026?
byAnuj Kumar Singh
 
PDF
OpenCharacter AI Reviews: Features, Plans, and Best Alternative
byOpenCharacter AI
 
PPTX
Introduction to Industrial-Arts Grade 8 ppt Lesson 1
byFSBTLEDNathanVince
 
PDF
Transcript: What Thema can do: Leveraging metadata to support the discoverabi...
byBookNet Canada
 
PPTX
Cyber security chapter 1 for learning and educating to the students who want ...
byGulMohammadi
 
PDF
CI CD Observability, Metrics and DORA - Shifting Left and Cleaning Up! - Febr...
byPeter Souter
 
PDF
Computer-Based Training (CBT) The Backbone of Modern Technical & Defence Trai...
bycomputerbasedtrainin1
 
PDF
Startup Formation Collapses While Acquisition Activity Hits New High!
byMemoori
 
PDF
Supercharge Your Copilot-Driven Collaboration with Microsoft 365 Agents SDK
byAntti Koskela
 
PDF
Bettersize | BeSEC Series Product Brochure
byBettersize Instruments
 
PDF
Chapter 4 Network Security in computer security
byGetnet Tigabie Askale -(GM)
 
"When every team does things "right", but together it turns into chaos", Yozh...
byFwdays
 
What Is the Azure AI Foundry and Why Does It Matter for Enterprises?
byjohncarterjn
 
2026_01_28 - OpenMetadata Community Meeting.pdf
byOpenMetadata
 
Getting Started with Apache Spark: Big Data Made Simple [Free Meetup]
byHaim Michael
 
Build Next-Gen Spatial & Sensor Workflows: Secure, Scalable Processing in Sno...
bySafe Software
 
When Drones Decide for Themselves_ Inside the Rise of Machine-Led Flight.pdf
byLyra Anderson
 
Post-Hackathon-Learnings-Maximizing-Impact-Beyond-the-Event.pdf
byishantyadav1111
 
TechSprint WinterHack — Top 10 Teams Pitching Session we are excited for pit...
bybajpaitusharoffon678
 
EU regulations for the North American book supply chain - Tech Forum 2026
byBookNet Canada
 
Website Redesign Vs Website Refresh, What’s Right for You in 2026?
byAnuj Kumar Singh
 
OpenCharacter AI Reviews: Features, Plans, and Best Alternative
byOpenCharacter AI
 
Introduction to Industrial-Arts Grade 8 ppt Lesson 1
byFSBTLEDNathanVince
 
Transcript: What Thema can do: Leveraging metadata to support the discoverabi...
byBookNet Canada
 
Cyber security chapter 1 for learning and educating to the students who want ...
byGulMohammadi
 
CI CD Observability, Metrics and DORA - Shifting Left and Cleaning Up! - Febr...
byPeter Souter
 
Computer-Based Training (CBT) The Backbone of Modern Technical & Defence Trai...
bycomputerbasedtrainin1
 
Startup Formation Collapses While Acquisition Activity Hits New High!
byMemoori
 
Supercharge Your Copilot-Driven Collaboration with Microsoft 365 Agents SDK
byAntti Koskela
 
Bettersize | BeSEC Series Product Brochure
byBettersize Instruments
 
Chapter 4 Network Security in computer security
byGetnet Tigabie Askale -(GM)
 

Tokenisation 2.0

  • 1.
  • 2.
    EMVCo ● Worldwide interoperability& acceptance of secure payment transactions ● 6 member organisations : American Express, Discover, JCB, Mastercard, UnionPay, and Visa ● Separate working group “Tokenisation Working Group”
  • 3.
    Tokenisation Concept of replacinghigh-value data with low-value representation, While making it useful only for a transaction taking place in a specific domain
  • 4.
    Tokenisation Concept of replacinghigh-value data with low-value representation, While making it useful only for a transaction taking place in a specific domain
  • 5.
    Tokenisation Replacing the 16digit account number, Primary Account Number (PAN) with a unique digital identifier called a TOKEN T
  • 6.
    Payment Tokenisation 1.0 ●Tokenisation Ecosystem Environment ● Token Service Provider requirements ● Token Assurance ID&V Methods ● Payment Token processing ● Payment Token Transaction Flows
  • 7.
    Payment Tokenisation 2.0 ●Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
  • 8.
    Payment Tokenisation Ecosystem ●Cardholder ● Card Issuer ● Merchant ● Acquirer ● Payment System & Payment Network ● Token Requestor & Token User ● Token Service Provider
  • 9.
    Token Service Provider Entitiesauthorised to provide Payment Tokens to registered Token Requestors within a Token Programme T
  • 10.
    Token Service ProviderCtd. ● Registering with EMVCo ● Registration and management of Token Requestors ● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance and Token Provisioning ● Maintenance of security and related controls ● Establishing Token Domain Restriction Controls ● Support and management of Token Processing, including De-Tokenisation T
  • 11.
    Token Service ProviderCtd. ● Responsible for integrating into relevant Token Programmes ● Building and managing interfaces that integrate with Token Requestors and Card Issuers ● Operate a Token Vault in accordance with the policies and processes T
  • 12.
  • 13.
    Cardholder Merchant Token Requestor Token ServiceProvider Card Issuer PAN PAN Request Response Request Response T T T
  • 14.
  • 15.
    Token Requestors Provide TokenService Providers and Card Issuers with information that helps identify a number of elements that can be used within Token Provisioning to facilitate Token Issuance
  • 16.
    Token Requestor Types ●Acquirer ● Card Issuer ● Merchant ● Third Party Wallet ● Payment Enabler ● Payment Intermediary ● Payment Manager
  • 17.
    Acquirer [Token RequestorType] Commercial relationship with the Merchant and with the Payment System Processes payment transactions through a Payment Network(s) on behalf of the Merchant. Behalf of the Merchant, ● Manages and stores PAN or Payment Token ● Initiate Token Payment Requests ● Stores payment-related data ● Directly involved in Token Processing but no direct relationship with the Consumer
  • 18.
    Card Issuer [TokenRequestor Type] ● Single issuer programme is enabled OR ● Financial institution offering a service directly to their Cardholders / clients. ● Single Card Issuer branded application Token Processing occurs directly with the Merchant. ● Services may be provided through home banking interface. ● Financial services provided directly to their Cardholders. ● No unique Merchant integration is required.
  • 19.
    Merchant [Token RequestorType] ● A Merchant that does business for itself and / or its subsidiaries. ● Provides Merchant-branded checkout experience. ● A direct relationship exists between the Cardholder and Merchant. ● Token Payment Request initiated by Merchant using a unique Payment Token assigned to the Merchant, not a Shared Payment Token
  • 20.
    Third Party Wallet[Token Requestor Type] ● A digit wallet branded by a third party where multiple Card Issuer programmes co-exist. ● The digital wallet application is only provided directly to the Consumer and not through an Issuer.
  • 21.
    Payment Enabler [TokenRequestor Type] ● A non-Card Issuer third party where multiple Card Issuer programmes are enabled through a single consumer interface. Payment Enabler Card Issuer 1 Card Issuer 2 Card Issuer 3 singleconsumerinterface
  • 22.
    Payment Intermediary [TokenRequestor Type] ● An entity that provides Consumer authentication and passes payment credentials to a Merchant but is not directly involved in Token Processing.
  • 23.
    Payment Manager [TokenRequestor Type] ● An entity that does not interface directly with the Consumer but facilitates payments for the Merchant.
  • 24.
    Payment Tokenisation 2.0 ●Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases T
  • 25.
    Token Request Registered TokenRequestor requests a Payment Token from the Token Service Provider. Token Requestor needs to provide a PAN or a Payment Token / Token Reference ID. 2 types of Token Requests: ● Token Request with PAN ● Token Request with Payment Token / Token Reference ID T
  • 26.
    Token Request withPAN [Token Request Type] The Token Service Provider SHALL provide a common method that a registered Token Requestor can use to submit a request through. Fields for Token Request with PAN: PAN, PAN Expiry Date, Token Requestor ID, Token Assurance Method & Data, Token Location, Device Information (subjected to Conditions such as R – Required, C – Conditional, O – Optional) PAN
  • 27.
    Token Request withPayment Token / Token Reference ID [Token Request Type] The Token Service Provider SHALL provide a common method that a registered Token Requestor can use to submit a request through. 2 possibilities: Token Requestor is the same as the Token Requestor associated with the input Payment Token, and not the same Fields for Token Request with a Payment Token / Token Reference ID: Token Expiry Date, Token Requestor ID, Token Request Authorisation, Payment Token, Token Reference ID, Token Assurance Method & Data, Token Location, Device Information (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T T
  • 28.
  • 29.
    Token Service Provider[TSP] ● Registering with EMVCo ● Registration and management of Token Requestors ● Issuance of Payment Tokens, including Token Assurance, Token Generation, Token Issuance and Token Provisioning ● Maintenance of security and related controls ● Establishing Token Domain Restriction Controls ● Support and management of Token Processing, including De-Tokenisation T
  • 30.
    Step 1: TokenAssurance ● Performing ID&V prior to Token Issuance to verify that the Cardholder is the rightful user of the PAN. ● This binds the Payment Token to the underlying PAN and Cardholder. T
  • 31.
    Step 1: TokenAssurance Ctd Verification Methods Used ● Card Issuer Account Verification ● Interactive Cardholder Authentication – 1 Factor ● Interactive Cardholder Authentication – 2 Factor (Capable of supporting 3-D Secure) ● Risk Oriented Non-Interactive Cardholder Authentication ● Card Issuer Asserted Authentication T
  • 32.
    Payment Tokenisation 2.0 ●Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
  • 33.
    Step 2:Token Generation Processof creating a Payment Token and its associated Token Expiry Date for a specific underlying PAN for use by a specific Token Requestor and Token Domain(s), as identified the Token Requestor ID. ● The Token Service Provider SHALL provide the Token Vault with the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date. T
  • 34.
    Step 3:Token Issuance ●Process of issuing a Payment Token and related data in preparation for Token Provisioning. ● Token Service Providers SHALL only issue Payment Tokens through the response to a Token Request from a registered Token Requestor with a valid Token Requestor ID. T
  • 35.
    Step 4: TokenProvisioning Process of delivering a Payment Token and related data to the Token Location. T
  • 36.
    Token Response For anyToken Request, the interfaces SHALL provide a response message Fields for Response to Token Request: Request Status, Reason Code, Token Expiry Date, Token Reference ID, Payment Token, Token Reference ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
  • 37.
    Payment Token Process 2 PaymentToken Transaction Processing
  • 38.
    Cardholder Merchant Card Issuer TransactionRouting De-Tokenise/ Re-Tokenise Domain Restriction Controls Token Payment Request Token Authorisation Request PAN Authorisation Request T T T T PAN Authorisation Response Token Authorisation Response T TToken Service Provider Response Acquirer To Payment Network
  • 39.
  • 40.
    Cardholder-Initiated Transaction Cardholder directlypresents a payment credential. May use various authentication and verification features. T Mobile NFC at Point of Sale Mobile / Digital Wallet E-Commerce Card-On-File E- Commerce
  • 41.
    Merchant-Initiated Transaction Always aresult of a previous Cardholder interaction Types: ● Industry-specific authorisation practices extends the initial Cardholder-Initiated Transaction ● Standing instructions that provide express permission for additional purchases T
  • 42.
    Token Payment Request Originatesfrom the point of interaction between the Cardholder and the Merchant (such a Terminal, website or application) For the purposes of Token Processing, the fields and data included in Token Payment Requests are defined AND These are following existing message standards. Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference (subjected to Condtions such as R – Required, C – Conditional, O – Optional) T
  • 43.
    Transaction Routing Routing andAccount Range Tables: Need to clearly distinguish Token BINs and Token BIN Ranges from traditional PAN BINs and PAN BIN ranges in order to ensure the underlying integrity of payment processing. T
  • 44.
    Transaction Routing Ctd. PaymentNetwork The Payment Network may interface with the Token Service Provider in order to verify the state of the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date in the Token Vault for the affiliated Payment Token. The Payment Network SHOULD be aware that a Payment Token transaction may include a Token Cryptogram and authentication data.
  • 45.
    Token Authorisation Request Includesthe request between the Acquirer and the Payment Network ● Not including Token Domain Restriction Controls ● Not including De-Tokenisation ● Token Authorisation request process continues until De-Tokenisation has been completed
  • 46.
    Token Authorisation RequestCtd. After receipt of the Token Payment Request, Acquirer ● Performs routine processing checks ● Pass the Token Processing related data and other relevant payment data to the Payment Network (including setting the Token Presentment Mode to indicate the specific method in which the Payment Token was input into the Terminal or other Merchant point of interaction)
  • 47.
    Token Authorisation RequestCtd. For the purposes of Token Processing, the fields and data included in Token Authorisation are defined AND These are following existing message standards. Examples: Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
  • 48.
    Token Domain RestrictionControls ● Optionally performed ● Validating the Payment Token against the established Token Domain Restriction Controls ● Processing may be performed independently of the De-Tokenisation function
  • 49.
    Token Domain RestrictionControls Ctd. Controls depend upon the availability of specific Token Control Fields and Payment Token related data in Token Processing messages to restrict Payment Token use to the appropriate Token Domain(s). Token Service Providers and participating Payment Networks provide the Token Control Field. Types based on transactions: ● Cardholder-Initiated ● Merchant-Initiated
  • 50.
    Cardholder-Initiated Transaction Cardholder-Initiated TransactionsSHALL contain the relevant cryptography generated during the payment interaction and be validated. Token Control Fields: Token Cryptogram, POS Entry Mode, Merchant Identifiers (subjected to Condtions such as R – Required, C – Conditional, O – Optional)
  • 51.
    Merchant-Initiated Transaction When theMerchant is the Token Requestor, Merchant-related fields in the existing ISO 8583 messages SHOULD be used to limit the use of a Payment Token. Token Control Fields: Token Cryptogram, POS Entry Mode, Original Transaction Reference, Merchant-Initiated Transaction Identifier (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
  • 52.
    De-Tokenisation Converting a PaymentToken and Token Expiry Date to an underlying PAN and PAN Expiry Date. May or may not include the application of Token Domain Restriction Controls. T PAN
  • 53.
    De-Tokenisation Ctd. Fields Includedin De-Tokenisation Requests: Payment Token, Token Expiry Date T
  • 54.
    PAN Authorisation The CardIssuer completes the PAN-level and Account-level validation and the authorisation check, and returns the PAN in the authorisation response. PAN
  • 55.
    PAN Authorisation Request Requestto the Card Issuer. Contains the data necessary, including Token Processing related data, to determine the Card Issuer authorisation decision. For the purposes of Token Processing, the fields and data associated with PAN Authorisation requests are defined AND These are following existing message standards. Examples: Payment Token (PAN), PAN Expiry Date, POS Entry Mode, Token Requestor ID, Token Expiry Date, Token Assurance Method & data, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) PAN T
  • 56.
    PAN Authorisation Response Correspondingresponse from the Card Issuer on the notification of the approve or decline decision. For the purposes of Token Processing, the fields and data associated with PAN Authorisation responses are defined AND These are following existing message standards. Examples: Payment Token (PAN), Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T PAN
  • 57.
    Re-Tokenisation Includes the correspondingresponse process, PAN and PAN Expiry Date are tokenised back to the affiliated Payment Token and Token Expiry Date. TPAN
  • 58.
    Re-Tokenisation Ctd. Fields Includedin De-Tokenisation Responses: PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
  • 59.
    Token Authorisation Response Responsebetween the Payment Network and the Acquirer ● Not including Tokenisation & application of Token Domain Restriction Controls. ● Relevant response data comes from the PAN Authorisation response. T
  • 60.
    Token Authorisation ResponseCtd. For the purposes of Token Processing, the fields and data included in Token Authorisation are defined AND These are following existing message standards. Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T
  • 61.
    Token Payment Response Providesthe results of the authorisation decision For the purposes of Token Processing, the fields and data included in Token Payment Response are defined AND These are following existing message standards. Examples: Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference (subjected to Conditions such as R – Required, C – Conditional, O – Optional) T T
  • 62.
    Token Vault ● Storageand mechanism for Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date ● Storage of the association between a Payment Token and its assigned Token Domain Restriction Controls ● Strong physical and logical security measures
  • 63.
    Token Vault Ctd. Additional ●Large issuers are developing their own token vaults with own databases that translates a PAN to a token ● Visa, MasterCard and American Express supplies for Tokenisation vault services ( Example: Apply pay uses these services)
  • 64.
    Token Location ●The modeof storage for a Payment Token and related data ●The Token Location SHALL NOT change during the life of the Payment Token
  • 65.
    Token Location Description 00Not specified 01 Remote storage: e.g. a single Merchant’s card-on-file data store 02 EMVCo and Payment System type approved secure element / Integrated Circuit Card (ICC) 03 Local device storage: e.g. Payment Token and related data stored using the data storage mechanisms of a Cardholder device, such as when utilising Host Card Emulation (HCE) 04 Local hardware secured storage: e.g. using a Trusted Execution Environment (TEE) to ensure appropriately restricted access to data 05 Remote hardware secured storage: e.g. ISO 13491 compliant storage 06 Shared storage: e.g. e-commerce multi-merchant wallet accessing a card-on-file data store 07 Temporary storage: e.g. guest checkout 08 – 99 Reserved for future use
  • 66.
    Token Service ProviderInterfaces Common fields of any external interface that each Token Service Provider supports. Examples of the authenticated methods through which these interactions may occur: ● Web services ● ISO 8583 message exchange through an existing Payment Network interface ● File / batch
  • 67.
    Token Service ProviderInterfaces Ctd. The interfaces SHOULD be implemented and made available by the Token Service Provider to be used by all participating entities that interact with the Token Service Provider.
  • 68.
    Token Service ProviderInterfaces Ctd. Examples: ● Unlink Payment Token ● Suspend Payment Token ● Activate Payment Token ● Update Payment Token Attributes ● Update PAN Attributes
  • 69.
    Payment Tokenisation 2.0 ●Range of Token Requestor Types ● Payment Token Assurance Method ● Payment Token Programme ● Clarified roles, responsibilities and minimum requirements ● Payment Account Reference (PAR) ● Expansion of e commerce use cases
  • 70.
    Token Programme Comprised ofthe policies, processes and registration programmes facilitating: ● Generation and issuance of Payment Tokens. ● De-Tokenisation ● Token Domain Restriction Controls ● Token Vault
  • 71.
    Payment Tokenisation Requirements Baselinerequirements for Payment Tokenisation for: ● Token Service Provider ● Token Requestor ● Additional Stakeholders ● Token Vault ● Token Location
  • 72.
    Payment Account Reference(PAR) Linkage mechanism of Token Processing transactions with transactions associated with the underlying PAN without the Full PAN being available Term “PAR” in this technical framework refers to the overall concept, rather than any specific component (for example,PAR Data, PAR Field).
  • 73.
    PAN vs PAR FieldName Length Format PAN Variable (up to 19) Numeric PAR 29 Alphanumeric *Implementation of field formats is defined by each Token Service Providers’ interface. *Alphanumeric fields consist of uppercase Alphanumeric Roman characters.
  • 74.
  • 75.
    Payment Account Reference(PAR) Ctd. ● Implementation of PAR is outside of the scope of this technical framework and EMVCo. ● Payment Tokens affiliated with the same underlying PAN will consistently have the same PAR Data assigned. ● PAR Data is unique in its assignment to a given PAN and is not intended to be a PAN replacement or a consumer identifier.
  • 76.
    PAR and EMVTerminal Processing ● EMVCo has defined EMV Tag ‘9F24’ for the identification of PAR data provisioned in an EMV based Card / Form Factor. ● The terminal SHOULD be able to support the EMV Tag without disruption to the terminal. ● The terminal SHOULD be capable of reading PAR data. ● The terminal SHOULD pass PAR data to the Merchant’s POS system. ● The terminal SHOULD pass PAR data with other EMV data to the Merchant’s Payment Processor or Acquirer.
  • 77.
    Shared Payment Token(Use Case 4) Attribute Potential Considerations Token Domain Restriction Controls Token Domain Restriction Controls may include: Token Cryptogram POS Entry Mode Merchant Identifiers Note: POS Entry Mode is set to indicate an e-commerce transaction. Token Location The Token Location may include: 06 Shared Storage 07 Temporary Storage Cardholder Point of Interaction A Cardholder registers and interacts with either the Token Requestor or with each individual Merchant (Token User). A transaction is undertaken using the Shared Payment Token and may incorporate transaction specific Token Processing related data e.g. Token Cryptogram. Token User integration with the Token Requestor to enable a transaction may be required.
  • 78.
  • 79.
    Response/Request with Fields TypeFields Token Request with PAN PAN, PAN Expiry Date, Token Requestor ID, Token Assurance Method & Data, Token Location, Device Information Token Request with Payment Token / Token Reference ID Token Expiry Date, Token Requestor ID, Token Request Authorisation, Payment Token, Token Reference ID, Token Assurance Method & Data, Token Location, Device Information Token Response Request Status, Reason Code, Token Expiry Date, Token Reference ID, Payment Token, Token Reference ID, Token Assurance Method, Payment Account Reference Token Payment Request Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference
  • 80.
    Response/Request with FieldsCtd. Type Fields Token Authorisation Request Payment Token (PAN), Token Expiry Date, POS Entry Mode, Token Cryptogram, Token Requestor ID, Merchant Identifiers, Payment Account Reference Domain Restriction Controls for Cardholder-Initiated Token Cryptogram, POS Entry Mode, Merchant Identifiers Domain Restriction Controls for Merchant-Initiated Token Cryptogram, POS Entry Mode, Original Transaction Reference, Merchant-Initiated Transaction Identifier De-Tokenisation Request Payment Token, Token Expiry Date De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference
  • 81.
    Response/Request with FieldsCtd. Type Fields PAN Authorisation Request Payment Token (PAN), PAN Expiry Date, POS Entry Mode, Token Requestor ID, Token Expiry Date, Token Assurance Method & data, Payment Account Reference PAN Authorisation Response Payment Token (PAN), Payment Account Reference Token Authorisation Response Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference Token Payment Response Payment Token (PAN), Last 4 Digits of PAN, PAN Product ID, Token Assurance Method, Payment Account Reference De-Tokenisation Response PAN, PAN Expiry Date, Token Requestor ID, Payment Token, Token Expiry Date, Token Assurance Method, Token Assurance Data, Payment Account Reference
  • 82.
    Field Name LengthFormat PAN Variable (up to 19) Numeric PAN Expiry Date 4 Numeric PAR 29 Alphanumeric Token Requestor ID 11 Numeric Token Assurance Method 2 Numeric Token Location 2 Numeric Token Assurance Data Variable Implementation Specific Device Information Variable Alphanumeric Data Fields
  • 83.
    Field Name LengthFormat Token Request Authorisation Variable Implementation Specific Payment Token Variable (up to 19) Numeric Token Expiry Date 4 Numeric Token Reference ID Variable Implementation Specific Request Status 1 Numeric Reason Code Variable Alphanumeric Transaction Data Variable Implementation Specific Token Cryptogram Variable Implementation Specific Data Fields Ctd.
  • 84.
  • 85.
  • 86.
  • 87.
    Will Tokenisation replaceEMV or provide another option? ●EMV as the security for a plastic card in a card-present transaction ●Tokenisation as the security for digital transactions, whether mobile or online. ●Still, BOTH helps to secure our payment system
  • 88.
    Payment Account ●The uniquefinancial relationship between account holder(s) and a financial institution for a specific financial funding source (e.g. credit, debit, commercial, prepaid) represented by one or more PANs.
  • 89.
    Are tokens validfor one payment transaction only? No! ●The payments industry has moved away from single-use tokens due to the valid concern that we will quickly run out of unique tokens. ●As a solution one can use more of Shared Tokens! Example: In Apple Pay, a token (for a specific phone) does not change. It is the same token used for all transactions. What changes is a cryptogram, which is different for each transaction and ensures that a token cannot be duplicated and used elsewhere.
  • 90.
    What does Tokenisationhave to do with Host Card Emulation (HCE)? Host Card Emulation > placing card data in the cloud Why? ● To avoid all the technical and business complexities of card credentials stored on devices in secure elements, financial institutions are looking to move card credential data to the cloud. ● Reducing the number of actors and barriers to integration to existing systems Example: Android’s support for Host Card Emulation in the KitKat OS Tokenisation comes in? Passing encrypted card data every time a user wants to transact is simply not feasible from both a security and user experience point of view

Editor's Notes

  • #3 Specifications for contact contactless mobile 3dsecure qr codes and now tokenisation
  • #4 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.
  • #5 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.
  • #6 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.
  • #7 Expansion of e commerce use cases eCommerce using a mobile/digital wallet Shared payment token
  • #8 Expansion of e commerce use cases eCommerce using a mobile/digital wallet Shared payment token
  • #10 A role within the Payment Tokenisation ecosystem that provides branding guidelines, assigns IINs/BINs, defines rules and guidelines for payment ecosystem participants, and develops products and respective product requirements that are derived from a variety of technologies. Eg: BIN Controller
  • #11 Typically, a network will support two primary transaction sets – ATM transactions and POS transactions. As the intermediary, a network makes sure that, regardless of whether the card is used at a merchant or an ATM, the authorization and funds movement are properly directed to ensure money is appropriately distributed. 
  • #12 The Token Service Provider is a role within the Payment Tokenisation ecosystem that is carried out by entities authorised to provide Payment Tokens to registered Token Requestors within a Token Programme.
  • #14 A Token Service Provider SHALL operate a Token Vault in accordance with the policies and processes.
  • #18 Token Requestor Types provide Token Service Providers and Card Issuers with information that helps identify a number of elements that can be used within Token Provisioning to facilitate Token Issuance.
  • #20 Behalf of the Merchant, Manages and stores PAN or Payment Token Initiate Token Payment Requests Directly involved in Token Processing but no direct relationship with the Consumer
  • #21 Single issuer offering a service directly to their Cardholders and No unique Merchant integration is required
  • #22 A Merchant that does business for itself and / or its subsidiaries and Token Payment Request initiated by Merchant using a unique Payment Token assigned to the Merchant
  • #23 A digit by a third party with multiple card issuers joined in But digital wallet application is only provided directly to the Consumer and not through an Issuer
  • #25 An entity that provides Consumer authentication and passes payment credentials to a Merchant but is not directly involved in Token Processing
  • #27 Expansion of e commerce use cases eCommerce using a mobile/digital wallet Shared payment token
  • #28 In order to request a Payment Token, the Token Requestor needs to provide a PAN or a Payment Token / Token Reference ID.
  • #34 (An example of an existing payment ecosystem method capable of supporting 2 Factor authentication is 3-D Secure)
  • #35 Expansion of e commerce use cases eCommerce using a mobile/digital wallet Shared payment token
  • #36 Token Generation is the process of creating a Payment Token and its associated Token Expiry Date for a specific underlying PAN, for use by a specific Token Requestor and Token Domain(s), as identified the Token Requestor ID. The Token Service Provider SHALL provide the Token Vault with the Payment Token / Token Expiry Date mapping to the underlying PAN / PAN Expiry Date.
  • #37 Token Issuance is the process of issuing a Payment Token and related data in preparation for Token Provisioning. Token Service Providers SHALL only issue Payment Tokens through the response to a Token Request from a registered Token Requestor with a valid Token Requestor ID.
  • #43  For each Cardholder , an e-commerce Merchant that has Payment Token and related data stored in a Merchant platform
  • #48 Includes the request between the Acquirer and the Payment Network up to but not including De-Tokenisation and the application of Token Domain Restriction Controls.
  • #49 After receipt of the Token Payment Request, Acquirer will perform routine processing checks and pass the Token Processing related data and other relevant payment data to the Payment Network, including setting the Token Presentment Mode to indicate the specific method in which the Payment Token was input into the Terminal or other Merchant point of interaction.
  • #51 optionally performed and involves validating the Payment Token against the established Token Domain Restriction Controls. Processing may be performed independently of the De-Tokenisation function
  • #65 Token Vaults need to maintain all Payment Token(s)/ Token Expiry Date(s) that are mapped to a given PAN / PAN Expiry Date throughout the lifecycle of both the underlying PAN and the Payment Token(s). Be protected by strong physical and logical security measures per industry standards and compliance validation processes
  • #67 Token Provisioning> The process whereby a Payment Token and related data is delivered to the Token Location The Token Requestor registry > functions as a repository of information about the supported Token Locations, Token Domains and corresponding Token Domain Restriction Controls that apply to each Token Requestor TEE > Trusted Execution Environment
  • #68 Framework has given example usecases with token locations specified but it clearly states that, use cases presented are illustrative examples only and not required to be supported within a Token Programme Within each Token Programme the inherent flexibility of the technical framework may introduce variations to the example use cases provided
  • #69 Common fields of any external interface that each Token Service Provider supports. The Token Service Provider SHALL implement one or more secure methods of interaction with participating entities using the Payment Token service, including implementing appropriate access security controls. The following are examples of the authenticated methods through which these interactions may occur: Web services ISO 8583 message exchange through an existing Payment Network interface File / batch
  • #72 Expansion of e commerce use cases eCommerce using a mobile/digital wallet Shared payment token
  • #73 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. De-Tokenisation Token Domain Restriction Controls Token Vault
  • #75 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 (for example, PAR Data, PAR Field). linkage mechanism of Token Processing transactions with transactions associated with the underlying PAN without the Full PAN being available.
  • #77 Shared Payment Token: A Payment Token is considered a Shared Payment Token when used by one or more Token Users in relevant application based commerce and e-commerce scenarios. There is a direct relationship between the Token Users and the Token Requestor. The use of a Shared Payment Token is limited by its Token Domain Restriction Controls. Cardholders may have many EMV Payment Tokens affiliated with the same underlying PAN since each EMV Payment Token may have its own Token Domain Restriction Controls that are unique to its environment, device or Token Requestor.
  • #78 Responsibility of each Registered BIN Controller to communicate and specify how PAR will be used within its payment ecosystem.
  • #79 EMV Tag ‘9F25’ Last 4 Digits of PAN EMV Tag ‘9F19’ Token Requestor ID
  • #80 Shared Payment Token: A Payment Token is considered a Shared Payment Token when used by one or more Token Users in relevant application based commerce and e-commerce scenarios. There is a direct relationship between the Token Users and the Token Requestor. The use of a Shared Payment Token is limited by its Token Domain Restriction Controls.
  • #81 Shared Payment Token: A Payment Token is considered a Shared Payment Token when used by one or more Token Users in relevant application based commerce and e-commerce scenarios. There is a direct relationship between the Token Users and the Token Requestor. The use of a Shared Payment Token is limited by its Token Domain Restriction Controls. Cardholders may have many EMV Payment Tokens affiliated with the same underlying PAN since each EMV Payment Token may have its own Token Domain Restriction Controls that are unique to its environment, device or Token Requestor.