Visa begins tokenisation roll out

"will be made available to issuing financial institutions globally" - I'm a bit confused.

The way I understood it worked was such that the issuing financial institution does not need to know about the token.  They may, however, choose to be aware of it.

The tokens are created/requested by Merchants or device makers (indeed mobile handset makers) to protect the cardholder data.

It is liablity shift associated with EMV that will drive Merchants to want tokenisation to protect themselves.  This may also drive adoption of acceptance of new tokens (such as mobile phones).

I think the card number stays with issuers. What passes through the ecosystem ie mobile devices, nfc terminals , processors , acquirers and finally the issuers is just the token. The onus is on issuers to match tokens to card numbers.

Apple pay, I believe , has adopted this system and hence the need to partner with banks. Apple device does generate tokens but the matching happens at issuers. Otherwise how can apple process payments without storing card info on their servers as they have claimed.

Any comments are welcome.

The issuers need to sign up as they have to pay Visa or MasterCard for the Tokenization service. My understanding is that a PAN has to be enables for the service which drives the billing to the issuer.

That's also my understanding. The tokenization service itself is performed by the card schemes, but issuers have to register and pay for it. Roll-out means that issuers can start to register for the service.

The way I read it was Visa was offering this as a "on-behalf-of" service - and that Apple was using this with cooperation with Visa Inc. Whilst I agree that Tokens do increase security - it triggered a debate in the office with regards to how routing and acceptance rules/fees be applied if all a merchant can see is a token. I'd certainly like to understand the implications in more detail.

Does any one know how this tokenisation service works? My theory (based totally on guesswork) was that the token would be a dynamic or secondary PAN generated with the Issuer's BIN/IIN. The BIN would ensure that it was correctly routed by the Acquirer/scheme to the Issuer for translation back into the original account number. Is that right?

John, in principal you are right - the token is some kind of second PAN (or could be even a dynamic one-time PAN) generated woth the Issuers BIN/IIN. Translation can be done by everybody who knows how the token was generated - I guess that in the US for ApplePay the schemes do perform the genartion of tokens (tokenization service) and they will also offer to translate the token if the transactions will come along their switch - no need to change the issuer processing, but you the issuers have to pay for each translation. (But maybe someone , who is directly involved, can tell us if we are right or wrong.)

@Oliver: good to "talk" to you again!

So Orbiscom lives again eh? There's nothing new under the sun.

Leave the front digits of the PAN alone to enable BIN routing, leave the four digits of the PAN alone to ensure proper tracking for cardholder loyalty and rewards at the merchant, and adjust the... what, 2-3 digits in the middle?

Is all this just a way to dynamically change 2-3 digits?

Presumably an additional fee will be payable by the merchant for the provision of this service?

I wonder whether it'd be considered a circumvention of the card interchange fee?

If these tokens have a BIN and are in the required format to allow for routing over the existing rails, how is a hacker meant to tell the differnce.

Q: When is a card number not a card number?
A:  When it is a token!

The BIN of a token ensures that the token gets routed to the token provider (so while it is associated with the issuer, it is not the same bin as the bin of the card that has been tokenized).

The token provider may be Visa, but it may also be another party (large merchant, processor, bank, some other service provider or even a phone/device maker).

It is the token provider that adds an extra layer of protection to the card-holder.  They must therefore comply with a raft of security requirements before they are allowed into the scheme as a token provider.

A token is like a card - it is issued once and used many times.  Unlike a card, it is unique to a particular use-case (such as a phone at a merchant, but cannot be used on internet without the phone).  As such, it can be specifically disabled without re-issuing the original card.

I don't know who pays for this.  I do know that issuers must change their systems to recognize and correctly process detokenized messages (compliance changes) so this is more forced on them than that they seek to join up.  Although I am sure they appreciate the extra security.

There may be some use-cases where cardholders would be willing to pay for the service themselves, or the fee is built into another service offering (as an example, think of a wrist-band at a concert as a token).  It will be interesting to see how this gets used.