Community

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.

I like the concept. 

I would like to see it implemented as one of several choices that a consumer gets to identify themselves.  I.e. the end user should be able to decide for themselves what sort of key they lock their own stuff up with.

One anomaly here: 3 factor?  Lets count the factors:

  - Something you are: your heartbeat +1

  - Something you have: the bracelet +1

  - Something ELSE you have: your mobile-phone with app = +0 !

  - Something you know: ? = 0

I only count 2 factors.  Unless the app forces you to sign on with a password - but I thought they are "promising" to get rid of passwords.

If the phone is used as a 'token', the problem of authenticating the phone (an inherintly unsafe device) remains.  But there are other solutions to this problem.

"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).

There are some schools who use iPads for class matarial.  They insist that you use Apple to attend their school.

I don't consider this to be education.  This is brain washing.  I object to the idea that I have to use product X to do function Y.

If Apple has truly embraced the open NFC payment model via the card schemes (and to connect the merchants to the account holders they surely must do this) then it can only be a good thing.

At least now I understand the recent urgency of tokenisation being mandated by the card schemes.

So while the adoption of new payment methods by a popular brand is good, I hope Apple falls back into the niche market where it belongs.  Please stop brainwashing us that everything Apple is the only way to do things.

"deriding traditional payments as "broken" and reliant for security on oudated magentic stripes and vulnerable passwords" - as if Apple is the first to think of a solution for this.  Really!

I always thought it was a risk that the steel around the housing of the electronics is thinner than the safe.  The air-vents look particularly easy to cut into.

If this sort of thing continues, it is another nail in the coffin for cash.