October 10, 2014
A few days ago, LTP listed the Top 10 questions on tokenization (Top 10 Questions on Tokenization).
We collected feedback from industry insiders to come up with those questions and challenged experts to answer them. Today, we are releasing the first set of answers from the payment processing firm, Shift4.
Shift4 wanted to answer to LTP’s questions and highlight some differences between true tokenization PCI redefined tokenization, and how they both apply to the Apple Pay technology.
Brief history: The concept of tokenization existed long before the term, even long before computers. Tokenization is simply referring to data via an unrelated reference number – like a case number might refer to a criminal investigation, an invoice number might refer to one or more purchased items, or a record ID might refer to any arbitrary set of data.
Tokenization can be applied to secure any data. All the answers below refer to tokenization as it applies to securing payment cardholder data (CHD) and/or Apple Pay.
1. What is the primary purpose of tokenization?
As defined by Shift4, to secure data – specifically CHD – for merchants. In the Apple Pay model, the tokenization secures CHD stored on the device and hides the CHD from the merchants it interacts with for payment processing.
1a. Whose interests does it serve?
The whole goal of our releasing tokenization into the public domain back in 2005 was to simplify and secure payment processing for merchants. We realized that for tokenization to succeed, it would need broad-based support. Locking this technology to a single company (us in this case) would have hindered its acceptance.
Now, one thing to be aware of (and I assume the reason for this question) is that some vendors do lock you into their services using tokenization among other tightly coupled service offerings. We don’t do that. Within our contract, merchants are free to leave at any time and we will provide an encrypted file containing the tokens and the associated CHD. To the best of my knowledge, we are the only provider offering this.
More on Apple Pay’s interest below in question #4.
2. Does tokenization eliminate the need for CNP category of transactions?
No. Tokenization secures CHD and makes the data useless to steal. Tokenization in and of itself does not address card authenticity. CNP, for the most part, are anonymous transactions that are hand-keyed by an untrusted person and these factors will always have a higher risk than their card-present counterpart.
3. Exactly what benefits does it provide to the various parties involved? Merchants, processors, issuers, payment networks, acquirers, etc.? Does the value equation change as a result?
Merchants – it secures CHD by taking the princess out of the castle (removing the vulnerable data from the merchant environment). True tokenization makes any data stolen useless to hackers.
Processors, Gateways and Acquirers – a selling point and maybe a slight reduction in liability risk from breach lawsuits (we offer secure solutions; it’s not our fault the merchant chose not to use them).
Issuers and Payment Networks – less risk from fraud related to stolen CHD; less risk of black eyes from media exposure.
4. Who are the biggest beneficiaries of the currently proposed tokenization regime?
The biggest benefactor is Apple – they will sell more devices. Apple has a tendency to patent almost anything and everything, so look for some aggressive patent infringement lawsuits on Apple’s competitors that incorporate similar functionality.
5. Who are biggest losers as a result of the proposed tokenization approach?
I see three: 1) Hackers. But you should not feel sorry for them, I’m certain they will adjust and attack the low hanging fruit in other areas. 2) EMV. This technology is pretty much a direct competitor to EMV. While EMV is strong at stopping forged cards in a card-present environment, EMV does not secure CHD, whereas Apple Pay’s tokenization will secure the CHD. 3) Merchants that do recurring billing. It is not yet known whether Apple Pay supports a recurring billing model, but even if it does, this will most likely lock the merchant into the processor they are currently doing business with.
6. Does tokenization foster or impede innovation in payments? Does it fact perpetuate the status quo?
True tokenization, I believe, fosters innovation. The less effort that is focused on securing CHD, the more effort that can be focused in other areas. Depending on how Apple Pay defines the tokens (per PCI’s liberal expansion of the definition or more true to the original definition) will determine if the tokens are truly secure. Encryption or hashing solutions that try to wear a tokenization name badge – or as we like to call them, Tokenization In Name Only (TINO) – is not nearly as secure as true tokenization.
7. Exactly who can become a TSP (Token Service Provider) and when? Are the protocols set up for entities other than the 3 major networks to provide this service?
We’re still investigating.
8. Is the Apple Pay implementation of tokenization compliant with any industry standard or is it totally proprietary?
Here is a big grey area. Tokenization as Shift4 defined it replaces the CHD for a single transaction or series of related transactions for a merchant. Tokenization as defined by both PCI and EMVCo, for the most part, addresses the same – a single transaction or series of related transactions for a merchant. Here with Apple Pay, the tokenization is being applied to the CHD that would otherwise be stored on the device and transmitted to the merchant. The existing standard addresses the merchant scope that Apple Pay applies to the cardholder. It’s an entirely different scope that some analysts believe is related to the new card-brand based tokenization methodology from Visa and MasterCard, but until I’ve seen Visa’s standard firsthand, I cannot verify that. Ultimately, I believe how Apple patented the process and/or how freely they allow others to use the process will dictate whether this becomes a standard or remains proprietary. (As I mentioned before, they are notorious for aggressively defending their patented technologies.)
Does that approach help or hurt the cause?
There are too many variables at play here to answer this question. Are we talking about the cause of data security, or of merchant security, or of tokenization? In any case, I think the answer is to be determined as we see how adoption rates play out and whether the technology expands beyond Apple products.
9. Does tokenization (as proposed and implemented) take the industry a step forward or backward?
Depends on the proposal you are referring to. True tokenization – the original definition – is a simple method to secure CHD and I think this was a step forward. PCI tokenization, while it does not preclude true tokenization solutions from existing, liberally expanded what can be called a token and added a lot of to be determined by your acquirer or QSA to plug the holes they added. While they had the opportunity to take a step forward, I think they dropped the ball and didn’t advance security. Apple Pay tokenization, while there are quite a few unknowns, holds promise as a step forward. How big of a step is obviously dependent on the details.
10. Wait, did someone say this is an innovation?
Referring specifically to Apple Pay, while we’re still gathering information and the verdict is still out, we have not yet seen anything that precludes the innovation benefit I previously mentioned. For the application writers, the less effort that is focused on securing CHD, the more effort that can be focused in other areas.