Tech Talk

Recent posts

Enterprise System Pitfalls: Summary
Today I’m wrapping up a series of posts on the broad topic of Enterprise System Pitfalls. In this series, my hope was to help shed light on the primary problems that cause us to miss budgets, fall short on capabilities, or completely fail when implementing an enterprise system. 

The Year in Review
As 2019 comes to a close, it’s time to count our blessings. One of mine has been the privilege (and fun!) of being able to reach out to so many interesting companies and get them to tell me what they’re doing that’s different, disruptive, and game-changing. The list of things I have to write about in future columns has only gotten longer in the nine months since I started writing this column.

Sustainable Innovation
Sustainability can yield multiple benefits to hotels. Saving energy and water yields direct cost savings. Revenue can be generated by guests who prefer to deal with businesses that minimize their environmental impact. And many would argue that conserving scarce resources is simply the right thing to do.

Meetings Innovation
The sale and delivery of groups and meetings is perhaps the most significant and under-automated functions for many hotels. Even though groups often account for 30% to 60% of revenue, most group bookings are still handled manually for most if not all of steps, as they move from a meeting planner’s research to a confirmed booking.

The biggest enemy to any system is complexity. In a system of inputs and outputs, such as an enterprise system, more complexity means more parts are used in interaction with inputs to create the outputs. Every part that must be built and maintained costs time and money

want to read more articles like this?

want to read more articles like this?

Sign up to receive our twice-a-month Watercooler and Siegel Sez Newsletters and never miss another article or news story.


PCI: “Not All Tokens Reduce Scope”

by J. David Oder

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! 

About The Author
J. David Oder
President and CEO
Shift4 Corporation

J. David (Dave) Oder is the President/CEO of Shift4 Corporation. Dave is a hands-on manager who enjoys jumping into projects alongside his technical staff. An accomplished businessman, Dave has more than 35 years' experience in software development and accounting, spent mainly on overseeing software companies. Prior to founding Shift4, he was CEO of the Aerus Corporation, a pioneer of business accounting software, and owner of a successful consulting firm. Dave earned his Bachelor's degree in Business/Accounting and Master's degree in Computer Science as well as an MBA from University of California, Los Angeles.

Blog post currently doesn't have any comments.
Leave comment

 Security code