In the specification, the Token Service Provider already plays a role as an authorised party, managing issuance, security control and other functions related to the Payment Token. Could the Token Service Provider play other roles, such as a Payment Processor?
The Token Service Provider may be a wholly independent party from the Payment Network or Payment Processor or alternatively a Token Service Provider could be integrated with a Payment Network or Payment Processor.
In the specification Figure 2, the Payment Network initiates the de-tokenisation function. Does this mean that only the Payment Network could be a Token Service Provider?
No, Figure 2 is an example implementation where the Payment Network is the Token Service Provider. Other organisations, such as Card Issuers or third party service providers could act as a Token Service Provider.
Who can perform TSP services for a given BIN Range that allows token issuance?
The authorised user of the BIN.
Should Token Service Providers apply to ISO/IEC JTC1 SC17/WG5 for new IINs (BINs) since the Token Service Provider will manage the Token BIN and Token BIN Range?
The specification does not necessarily require new IINs beyond those already licensed from ISO. In general Token Service Providers will need to use existing IINs for Token Issuance so that the Payment Tokens can pass through the payment network without coding changes being required by each entity in the processing chain.
Why is Identification and Verification performed by the Card Issuer or Token Service Provider?
Identification and Verification is a method through which either the Token Service Provider or Card Issuer may validate the Cardholder and the Cardholder's account to establish the Token Assurance Level for the Payment Token. Since the Card Issuer is responsible for managing the Cardholder's account information, the Card Issuer will be able to evaluate this Token Assurance Level when a transaction occurs. The Token Service Provider can alternatively, or in conjunction with the Card Issuer, perform risk analysis with the information collected to help establish the Token Assurance Level.
In the specification Figure 1, the Token Service Provider connects to the Card Issuer for Token Assurance Identification and Verification. Does this mean that the connection is physical (i.e. directly to the Card Issuer) or logical (i.e. the Token Service Provider connects to the Payment Network first and then transfers the data through the Payment Network to the Card Issuer)?
In the specification Figure 1, the data flow connection between the Token Service Provider and Card Issuer could be physical or logical. There is no requirement or restriction and entities may determine what business and technical objectives work best for them, respectively.
In the specification, section 6 provides several examples of different Identification and Verification methods. This is a process within each use case combining risk mechanisms, account verification and Cardholder authentication together and may require cooperation by Card Issuers and Token Requestors. Does EMVCo have plans to further define Identification and Verification methods in more detail within the Payment Token Specification?
EMVCo will continue to assess industry need and where appropriate further define aspects of the EMV Payment Token Specification – Technical Framework v1.0.
Is there any plan for EMVCo to validate implementations according to the Payment Token Specification?
EMVCo will continue to assess industry need as regarding potential testing and evaluation programmes it might put in place for the EMV Payment Tokenisation Specification – Technical Framework v1.0.
I have ideas, concerns and questions to make sure this specification is implementable in my specific market, where can I download the specification and participate further?
As a global technical body, EMVCo ensures that its ISO-based specifications are open for use across different markets and in different environments, and can support a truly interoperable global payments framework. We encourage all industry stakeholders to engage in our work and contribute to the development of the EMV Specifications to enable smarter and more secure payments. The EMV® Payment Tokenisation Specification - Technical Framework v1.0 was published in March 2014 on our website www.emvco.com and can be downloaded by anyone without charge and implemented royalty-free. Our aim in publically sharing this specification framework is to promote transparency, maximise industry engagement and encourage market comments so that the document can evolve in line with commercial and technical market requirements. We have already witnessed significant interest and call on other parties to get involved through the EMVCo Associates Programme, a framework that allows stakeholders to play an active role in providing input to the technical and operational issues connected to the EMV Specifications and related processes. In addition to this, EMVCo also engages with other industry bodies, including many merchant groups globally, to understand and support individual sector requirements.