PCI DSS 3.0 was just released and hoteliers around the globe are scrambling to determine what the new requirements are and what changes they need to make to stay (or become) compliant. While there are some significant changes in 3.0, I fear that many are overlooking a much larger change that they will have to make as the PCI Council implements its new standard for tokenization in the coming year.

Currently, tokenization to replace sensitive credit card data is governed by a PCI guideline. Remember that in PCI parlance a guideline is more of a “you ought to” whereas a standard is a “you have to.” What that means is when this new standard goes live (likely within the next 12 months), it will become a binding subsection of the PCI DSS that will apply to all merchants using any sort of tokenization solution.

The bright side: as part of this newly proposed tokenization standard, PCI will allow tokenization – when properly implemented – to reduce a merchant’s card data environment and therefore limit their PCI scope. (This means less time and money spent on PCI compliance efforts.)

Now, true to form for the PCI Council, they’ve gone about this process in a more broad (and somewhat confusing) manner than I would have liked, but – for once – I am actually happy with the end result. Here’s the gist:

PCI is aiming to vastly increase the breadth of what can be referred to as “tokenization,” including solutions much more closely related to encryption or hashing than to the original definition of tokenization that we brought to the industry in 2005. I could write a dozen pages on what a terrible idea this is (in fact my friend Steve already has, and you can find his scathing rant on the Shift4 blog) but, suffice it to say that they have officially bastardized something great in the name of making every company with a “tokenization” solution feel like a winner.

Thankfully, somewhere in their fuzzy logic they realized that in so doing, they had muddied the water so much that they had to come right out and admit that not all tokenization solutions are created equal and that those varied solutions would ultimately not all have the same effect on a merchant’s scope (or security).

In a discussion I had with PCI Council executives during their recent Community Meeting in Las Vegas, it was specifically confirmed that format-preserving (16-digit numeric tokens) will not allow for scope reduction under the new standard. While this technology (which I happen to hold multiple patents on – so don’t think I’m bashing on it for any sort of personal gain) may be sufficient to pass PCI DSS requirements, it is not enough to warrant a reduction in scope for merchants who use it. According to the proposed tokenization spec, merchants must be able to distinguish between a token value and an actual PAN – and you can’t do that with a format-preserving token.

It appears the Council has also finally realized that one-to-one tokens offer very little by way of security. Twice in the proposed new spec, the Council alludes to the fact that tokens that carry a one-to-one relationship with the original PAN may present risks to merchants. It makes sense; a token with a one-to-one relationship to the card almost always holds a mathematical relationship, which means it can be reversed. Worse yet, it doesn’t even have to be reversed to be dangerous. If a one-to-one token works at Hotel A, and a crook knows that Hotel B (likely of the same brand) uses the same processor, he can then use A’s tokens to illicitly book rooms and buy drinks at B’s property. The scariest part: because these pseudo-tokens aren’t considered card data, Hotel A doesn’t have to report them as lost or stolen. Imagine the legal question then of which property is liable for the breach (and the thief’s massive bar tab). It’s a mess! As I have told merchants for the better part of the last decade, “if you’re going to use garbage like that, you might as well just use the original PAN… and pray.”

Ultimately, there is one point hoteliers need to know: If you want to enjoy the benefits of reducing your PCI scope – both in time and dollar savings – you’ll need to get rid of format-preserving tokens and adopt a more secure solution. This will require development work on the PMS side and could require some changes to the way you’ve historically handled your tokens. However, a quick financial review makes it clear: in assessment costs alone, this investment will pay for itself in the first year.

Now many of you are considering what the implications of this are for your business. Candidly, it means the way that you have been doing things most likely will not allow you to qualify for a reduction in scope. It means that your current method of customer tracking and analytics could now come at the cost of putting you back in full PCI scope. Oh, and the way you’ve been sharing tokens with your brand partners may take you completely out of compliance. Looks like it may be time to start looking at doing things a bit differently.

Hospitality Upgrade made me promise I wouldn’t pitch any products on their blog, so I won’t. But I will offer you all some hope and just say that there are solutions currently available to allow you to maintain both analytics and token-sharing capabilities while meeting PCI’s newly proposed standard and gaining their promised – but elusive – scope reduction. Now it’s up to you to figure out where to find them. Good luck, and don’t say I didn’t warn you!