Visa mandates EMV Co Tokenisation for Cloud Based Payment implementations

8th March 2016

Cloud Based Payments so far

There has been a rapid increase in the number of mobile payment solutions based on Cloud Based Payment (CBP) standards from Visa and MasterCard utilising Host Card Emulation (HCE) capability in Android phones.

A key driver is that CBP with HCE technology puts card issuers in control and enables them to add mobile payment capability to new and existing mobile applications. They can do this independently, without any reliance on the mobile operators, third party providers or handset manufacturers.

To protect cardholder credentials from fraud attacks, CBP utilises a range of security features and requirements; one of which is that the 16 digit primary account number (PAN) of the digitised card on the mobile cannot be the same as the consumer’s card PAN. By replacing the card PAN with a separate mobile-specific card number, the consumer is protected if the mobile account details were ever intercepted as they could not be used for card payments through another channel.

Until now almost all CBP solutions have used an ‘Alternate PAN’ mechanism for the mobile card number. An Alternate PAN is a 16 digit number created within the issuer’s card management system using the same BIN (Bank ID Number) or another of the issuer’s existing BINs.


Tokenisation is quickly becoming the ‘next big thing’ in the payments industry and extends the use of surrogate numbers representing payment accounts into other use cases beyond mobile payments. In 2014 EMVCo published the ‘EMV Payment Tokenisation Specification – Technical Framework’ which established a common approach for Tokenisation to protect card details for mobile payment, e-commerce and in-app m-commerce.

The EMVCo framework defines an overall ‘ecosystem’ for Tokenisation, including registration and verification procedures, participant roles, APIs and processing. Importantly, Tokenisation can be provided by a third party or can be undertaken by the card issuer themselves with an in-house Token Server solution.

Visa and MasterCard provide network-based tokenisation services, VTS and MDES, and third party Token Service Providers (TSPs) are appearing. Some banks are investigating deploying their own in-house tokenisation services.

Visa CBP changes

Visa has recently changed the CBP requirements mandating issuers to migrate to EMVCo-compliant Tokenisation, removing the option of using of Alternate PANs and mandating the use of Tokens generated within specially-designated Token BIN ranges which must be flagged in “all appropriate BIN tables”.

Visa allows three options for tokenisation; VTS (Visa’s own service), a third party TSP or an issuer in-house solution.

Card Issuer challenges and opportunities

The introduction of CBP put issuers in control of their mobile payment solutions. The new requirements from Visa could be met by using tokenisation services from Visa or a third party TSP, but they also could be met by implementing an in-house tokenisation solution – enabling the issuer to maintain control and reduce cost. Of course these third party and in-house options would rely on the availability of designated Token BINs being made available by card schemes. Although, for fully independent CBP implementations, it is unclear why the network needs to know whether or not a transaction is using a Token PAN, as long as the BIN can be used in the network to apply the appropriate interchange rate.

The payments world is evolving rapidly. Enabling in-store payments with mobile phones using CBP is just one aspect of this evolution.  Tokenisation is undoubtedly a key component of a range of payment solutions including on-line ecommerce and in-app m-commerce.  Implementing an in-house tokenisation solution now for CBP will simplify the deployment of other tokenised payments services in the future.


Rob Macmillan, VP of Marketing, Proxama