Description of “Token Service Provider” (TSP). Eligibility and steps to become a TSP. Scope and implementation. Review of TSP Standard.

1. Token Service Provider (TSP)
An Introduction to Certification
Biju John, PCI QSA, PA-QSA, PCI P2PE, PCI PA-QSA(P2PE), P2PE, 3DS
VP ControlCase

2. Agenda
1
 What is Tokenization?
 What is a Token Service Provider or TSP?
 Who can become a TSP
 Benefits of being TSP
 Business Flow for Payment tokens
 Scope – Token Data Environment
 TSP Requirements
 Assessment and Certification

3. 2
The process of replacing sensitive data (Card Data) with
surrogate values that remove risk but preserve value to the
business.
What is Tokenization
 The tokenization is an added layer of protection in
payment processing ecosystem
 Minimize the fraud exposure of data compromise
 No changes to existing payment ecosystem

4. 3
Different type of Tokens
 Acquiring Tokens
Acquiring tokens are created by the acquirer, merchant, or a merchant’s service provider
after the cardholder presents their PAN and/or other payment credentials. It is not based
on an industry-standard and cannot be used for new authorizations.
 Issuer Tokens
Issuer tokens, also known as virtual card numbers, are created by issuers and provide the
means to reduce risk in specific use cases, including commercial card applications, as
well as consumer-oriented services.
 Payment Tokens
Payment tokens are created by TSPs that are registered with EMVCo. Payment Tokens
are issued to a cardholder in lieu of a PAN, and the cardholder presents the Payment
Token to the merchant when making a purchase. During a Payment Token transaction, the
merchant and acquirer do not receive or have access to the corresponding PAN.

5. 4
Sample Payment Token
6203011150123456789
▪ 620301 - BIN
▪ 11 - Card identifier
▪ 5 - Token identifier (0 - production physical card identifier; 99 - test
physical card identifier)
▪ 012345678 - random numbers
▪ 9 - Luhn digit
Complies with PAN format supporting interoperability
within the existing payment processes
 13 – 19 Digits
 Supports ISO 8583 message format

6. 5
Any Service provider within the payments ecosystem that
is able to provide token requestors for ‘Card Data’ with
‘Surrogate' PAN values…
What is a Token Service Provider or TSP?
 Generates and Manages Payment Token
 A wholly independent party from the payment network
or payment processor.
 Can be integrated with a payment network or payment
processor.

7. 6
Token Payment Flow – High-level

8. 7
Sample Steps - Registration

9. 8
Who can become a TSP?
 Generate and issue EMV ‘Payment Tokens’
 Must be a valid PCI DSS certified entity
 Must have registered with EMVCo as Token Service
Provider
Any Service provider within the payments ecosystem such
as Issuers, Acquirers and Merchants that wish to offer
mobile and/or digital payments to customers can become
a TSP.

10. 9
Enables them to reduce long term costs, maintain
independence and increase flexibility to establish an edge
over their competitors.
Benefits of being a TSP – Self Assist
 Provides full control over the tokenization process: creation, storage, issuance
and management
 Full control of digital payments by issuing tokens directly without third party
intervention.
 Reduce long term costs: no additional TSP fees from the payment schemes.
 Save on transaction fees On-us transactions when you are the issuing as well
as the acquiring bank.
 Banks retain their privacy because data and roadmaps do not have to be
shared with the schemes.
 Keep track of customer payment behavior to gain valuable insight and be able
to offer personalized services.

11. 10
Comply with set of controls defined based on EMVCo
Payment Tokenization Specification Technical
Framework and are additional to those in PCI DSS.
How to become a TSP
 Defined as physical and logical security requirements
and assessment procedures
 Requirements developed by PCI SSC and managed by
Payment brands
 Any queries about validating compliance should be
directed to the appropriate Payment Brand(s)
 Not listed by PCI SSC

12. 11
Scope: Token Data Environment (TDE)
The TDE is a dedicated, secure area within the TSP, where
one or more of the following services are performed:
❑Token generation, issuing, and mapping processes (Eg: Token vault)
❑Assignment of token usage parameters (Eg: APIs)
❑Token lifecycle management (Eg: Token vault)
❑Processes to map or re-map tokens, or perform de-tokenization (Eg:
Token vault)
❑Cryptographic processes to support tokenization functions (Eg: HSM)
❑Maintenance of underlying token security and related processing
controls, such as domain restrictions during transaction processing.

13. 12
Token Data Environment (TDE)
Example of TDE Implementation
TDE as a subnet of CDE
Combined CDE and TDE

14. 13
TSP Requirements
 8 Requirements spread across 12 PCI DSS Requirements
 These are in addition to PCI Requirements
❑TSP 1 – Document and validate PCI DSS scope
❑TSP 2 – Secure TDE Systems and Network
❑TSP 3 – Protect and manage cryptographic keys
❑TSP 4 – Restrict access to TDE by business need to know
❑TSP 5 – Identify and authenticate all access to TDE systems
❑TSP 6 – Restrict physical access to the TDE
❑TSP 7 – Monitor all access to TDE
❑TSP 8 – Maintain an Information Security Policy

15. 14
TSP – PCI Mapping
PCI DSS Requirement Additional Applicability for TSPs
1. Install and maintain a firewall configurationto
protect cardholder data
▪ Firewall controls in PCI DSS Requirement 1 also apply to internal firewalls usedto separate TDE
from non-TDE networks.
▪ The current network and data flow diagrams (PCI DSS Requirements 11.2 and 1.1.3) must also
include all connections between the TDE and other networks,and all flows of Payment Tokens
across systems and networks in the TDE.
2. Do not use vendor-supplied defaults forsystem
passwords and other security parameters
▪ PCI DSS Requirement 2 applies to all system components in the TDE.
▪ Wireless environments are not permitted to be connected to the TDE.
3. Protect stored cardholder data ▪ Data retention and disposal policies, procedures and processes (PCI DSS Requirement
3.1) also apply to Payment Token Data.
▪ Payment Tokens must also be masked when displayed such that only personnel with a
legitimate business need can see the full Payment Token (PCI DSS Requirement 3.3), and
rendered unreadable wherever they are stored (PCI DSS Requirement 3.4) in the TDE.
▪ The key-management requirements in this document are in addition to thosein PCI DSS
Requirements 3.5 – 3.6

16. 15
TSP – PCI Mapping
PCI DSS Requirement Additional Applicability for TSPs
4. Encrypt transmission of cardholder data across open,
public networks
▪ Wireless environments are not permitted to be connected to the TDE.
5. Protect all systems against malware and regularly update
anti-virus software or programs
▪ PCI DSS Requirement 5 applies to all system components in the TDE.
6. Develop and maintain secure systems and
applications
▪ PCI DSS Requirement 6 applies to all system components in the TDE.
▪ All changes made to system components in the TDE must be in accordancewith PCI DSS
Requirement 6.4.5.
7. Restrict access to cardholder data bybusiness need to
know
▪ Access to Payment Token Data in the TDE must also be restricted according to principles of need-
to-know and least privilege.
8. Identify and authenticate access to system
components
▪ Strong authentication controls are required for all accounts used to access Payment Tokens
or to access systems in the TDE.
9. Restrict physical access to cardholder data ▪ Physical security controls also apply to secure access to Payment Token Datain the TDE.
10. Track and monitor all access to network resources and
cardholder data
▪ Audit log requirements include all individual user access to Payment Token Datain the TDE (PCI DSS
Requirement 10.2.1).
11. Regularly test security systems and processes ▪ Internal vulnerability scans, penetration tests (for example, to verifysegmentation controls),
intrusion detection, and change detection apply to the TDE.
12. Maintain a policy that addresses information security for all
personnel
▪ PCI DSS Requirement 12 also applies to personnel with access to the TDE.
TSP PCI
TSP1 Scope
TSP2 1, 2
TSP3 3
TSP4 7
TSP5 8
TSP6 9
TSP7 10
TSP8 12

17. 16
TSP – Encryption
 All Key-management process must be conducted within
HSM which is FIPS 140-2 Level 3 certified or PCI PTS
HSM approved
 Approved algorithms

18. 17
Assessment and Certification
 Assessment must be performed by P2PE QSA
 TDE must be PCI DSS certified
▪ PCI DSS requirements not applied may be assessed along with
TSP engagement and issue a partial ROC
 All applicable TSP controls must be applied to TDE
▪ Compensating controls can be considered if necessary
 TSP ROC or T-ROC must be completed as per
Reporting Template for PCI DSS v3
 Submit T-ROC and T-AOC to brands
▪ Client may do it directly with applicable payment brand

19. 18
Why ControlCase?
 Global Reach
▪ Serving more than 400 clients in 40 countries and rapidly growing
 Certified Resources
▪ PCI DSS Qualified Security Assessor (QSA)
▪ PA DSS (PA DSS)
▪ QSA for Point-to-Point Encryption (QSA P2PE)
▪ QSA for TSP
▪ QSA for 3DS
▪ Certified ASV vendor

20. www.controlcase.com
+ +1.703.483.6383 (US)
+91.9820293399 (India)
sales@controlcase.com
19
To Learn More About PCI TSP Compliance

21. Discussion forum
20
QA

22. Thank You for Your Time
21