Quantcast StorefrontBacktalk » Blog Archive » PCI Human Train Wreck Coming Next Year For Level 2s
advertisement
advertisement

This is page 2 of:

PCI Human Train Wreck Coming Next Year For Level 2s

November 30th, 2009
Like this story? Share it
To share this story with people in your social network, please click on the network icons below.

The Polar Express Train Wreck.
According to Visa, there are nearly 900 Level 2 merchants today. Let’s say only half of them will also be Level 2 for MasterCard (per my example, above), based on their actual transaction volume. That translates to about 450 new merchants that need an onsite assessment. Currently, there are only 352 Level 1 merchants (again, per Visa), which means 2010 will see an increase of over 125 percent in the number of merchants needing an assessment. How will we deal with this extra demand? Although the Council is training QSAs, I don’t think the number has increased by anywhere near 125 percent.

It’s not just the demand; it’s also timing. My guess is that few Level 2 merchants will move before mid-year. There is no benefit to delaying (PCI compliance is renewed annually, so it should make no economic difference whether you do it in the beginning of the year or at the end). But I try not to bet against human nature and the desire to delay the unpleasant. Now let’s factor in time for vendor selection and assessment preparation (remember the assessor’s matrix and all the required documentation), and the fact that first-time assessments can take longer and involve more remediation. The result may be a major train wreck in the fourth quarter of 2010 as an unusually large number of merchants and their QSAs scramble to document compliance. And, of course, this clamor happens just in time for the holidays.

In this scenario, some Level 1 merchants will suffer collateral damage. The number of new clients will stretch their QSAs, and seemingly minor remediation issues may lead to delays in Level 1 merchants’ own ROCs. One last kicker: Because PCI validation is annual, this fourth quarter crunch is perpetuated.

The Law of Unintended Consequences holds that no good act goes unpunished. MasterCard wants Level 2 merchants to have an onsite assessment. The PCI Council wants to monitor the quality of QSAs’ work. Each organization thinks it is doing the right thing. But when we combine these requirements with human nature and the calendar, we are headed into a 2010 year-end situation that may be painful for merchants and QSAs alike.

Will acquirers cut their merchants and processors some slack if things get tight? Will enough Level 2 merchants plan ahead and validate early? Will some Level 1 merchants with fourth quarter renewals (shock!) validate early and avoid the crush?

I’d like to know what you think. If you are a Level 2 merchant, what are your plans for your first assessment? Are you a Level 1 with a fourth quarter renewal? Do you disagree with my scenario? Please let me know. Leave a comment or send me an E-mail: wconway@403labs.com.


advertisement

6 Comments | Read PCI Human Train Wreck Coming Next Year For Level 2s

  1. John Bailey Says:

    This is retail, folks. Year end deadlines are really unacceptable and should be moved to mid-year…July 31st for example. If you’re like my company….nothing can happen in the last 6 weeks of the year as we lock down for the holidays. These people totally have their heads in the sand.

  2. Walt Conway Says:

    Thanks for the comment, John, and you raise a great point. I am regularly mystified by how particular dates get picked by the PCI Council and other bodies. For example, what’s special about June 30 for replacing WEP encryption (or the March 31, 2009 end date for new WEP applications) or October for the updated DSS? But these really pale compared to the year-end date chosen by MasterCard which conflicts with seasonal system freezes…including their own!

    Let’s hope someone there will catch this. I fear the only reasonable alternative might be for acquirers to cut merchants some slack, to the extent they can. At least we can hope!

    Your best bet is to fight human nature and get cracking on your on-site earlier in the year. This way it’s done. And as I pointed out, there is no economic benefit to waiting – you have to validate annually, so doing it earlier or later costs the same.

  3. Gray Taylor Says:

    Walt,
    This article has generated a lot of interest with retailers facing the dreaded MC L2 issue. Not surprisingly, some acquirers are questioning the veracity of the relaxation of “reciprocity”. Is there anything in the public domain from MC to substantiate this?

    To John’s comment, I have been constantly surprised at the lack of knowledge about retailing exhibited by those setting mandates (cost burdens to be added to timing issue). Acquirers are in the same boat as merchants – not knowing/understanding what is coming down the pipe next. Only recourse is to get involved in the process and get vocal!

    Thanks for the article!

  4. Walt Conway Says:

    I agree very much with your suggestion, Gray, that every large merchant should get involved in the PCI process. The good news is that I understand there are well over 300 Participating Organizations. Now all we need to do is make sure everyone is heard! The Council is listening, now we just need to work with the brands a little more.

    As for reciprocity, here is a link to MasterCard’s merchant definitions: http://www.mastercard.com/us/sdp/merchants/merchant_levels.html. If you read it carefully, you’ll note the reciprocity provision in the merchant level definitions (e.g., “or if you are considered a Level X by any of the other card brands”) is gone. You should also check out their FAQ (issued two months after the fact…) here: http://www.mastercard.com/us/sdp/assets/pdf/SDP%20Program%20Revisions%20FAQ.pdf

  5. Walt Conway Says:

    I have a follow-up to Gray’s questioning my statement on MasterCard’s reciprocity being relaxed. He’s right; I was wrong.

    I have been in contact with MasterCard and they corrected me: “we [MasterCard] never removed reciprocity from our rules. The language was simply changed from “competing brand” to “visa”. the “competing brand” lanugage has been in the rules since 2005 and this was meant to facilitate alignment between MasterCard and Visa.”

    I stand corrected. That means that not some but ALL L2 merchants will need an onsite. See the latest on these developments with some good news here: http://www.storefrontbacktalk.com/securityfraud/mastercard-blinks-drops-dec-31-level-2-pci-deadline/

  6. Robert Spivak Says:

    I wanted to comment on the dates. I agree that they seem to be timed poorly for certain retailers. while for others it fits well. Working with software vendors we find that depending on the industry, certain times of the year are good and other are not.

    For example, a college book seller will need to be locked down both in September and in January and the holidays are not as big a deal. While a Bridal shop will state that March through June nothing can change. Your standard Big box stores will tell you that Back to school and Holidays are locked down. Also depending on what region of the world you are in it can change. The US Thanksgiving is the biggest shopping day of the year for the US, while in Canada Boxing day is the big sales day.

    So we find that if you are involved with enough retailers, in different verticals, and different regions of the world, there is never a good time to implement changes.

    It has been my experience, however, that as long as there is a process to implement changes and the merchant can provide evidence that the process is followed, usually there can be some leniency given to the implementation of a mandate.

Leave a Reply

Newsletter

Quickly catch-up on the latest in E-Commerce and Retail Tech with our free weekly newsletter, with urgent bulletins as news merits.
advertisement

Most Recent Comments

Overpaying For PCI Compliance

One can always come up with a theoretical scenario that requires maintaining full card holder data. Heck, my company is a gateway provider and we've had instances where if we stored the full raw track information, it would have greatly helped in diagnosing and solving a problem -- the full PAN was not enough. Read more...
Consider that there are many other non-PCI data elements (name, date, email, amount, first 6 and last 4 digits of the PAN, etc.) available to track down these types of transactions. The organization should take a critical look at how often something like this actually happens, how often the PAN is *really* required for resolution, and how much (or how little) work/expense it might be to get help from the acquirer to research a transaction based on PAN. Read more...
Let's assume a kids subscription game. Dad looks at his credit card and sees a charge he's been ignoring for months. He has no idea which of 2 sons or 1 daughter signed up and further doesn't know which of the about 4 email addresses his kids used to sign up. How do you rely on anything but luck to find that TX? Further, you can't afford the risk of cancelling the wrong one. Read more...
In regard to tokenization, consider implementing your own tokenization (vs. outsourcing to your acquirer, gateway, or processor). You can still reduce scope by focusing your controls on the token vault environment (and the systems that call the tokenization solution) and maintain complete independence. You can also extend your tokenization platform to address other sensitive data like PII. Read more...
1) Use additional data like name, email address or physical address with the last four digit may be an option. 2) Use a processor/acquirer neutral gateway, but I'm abviously bias. Putting my bias aside, merchants change processors or banks much more than they change gateways -- unless the two are tied together as with a non-neutral gateway. Read more...
We tend to have to store full PAN for missing and incomplete transactions.... Read more...
How does Customer Service terminate an account when all they have is the PAN and a date? Most subscription services have 1 -3 price points so price doesn't give one much information. If a parent or the victim of card theft is calling in, the last 4 digits can easily match more than 1 transaction per day. Read more...
The #1 reason for this deafness: "We always did it this way", followed by "that would be too hard to change our procedures." More times than not, merchants can eliminate the storage of this data without much impact on their procedures but they need to shed the always "done it that way" shell. Yes there are exceptions, but with serious thought, the exceptions are just that, exceptions. Read more...

Target Decides Payment Method Incentives Work

Retailers are rightly concerned about interchange fees. Merchant’s are given a choice either accept cards, or not. Retailers can negotiate the Merchant Discount Rate, but not the interchange fee which is the largest part of the cost. Alternative Payment providers who create disintermediation offer payment programs that bring significant savings. Read more...
Now if TARGET figures out how to convince customers to grant access to their bank checking accounts and offers the in-store card as decoupled debit...look-out. Read more...
Rewarding behavior to choose lower cost payment enablers is smart business for Target. The math is pretty compelling and simple for Target. First, encouraging customers to use the house card means Target avoids bankcard interchant/merchant discounts - even with costs of running a private-label portfolio, it is less than 3rd-party bank card costs. Read more...
Target's provision of a 5% discount for consumers that use their payment card is a significant development that must be watched closely by banking card issuers, payments executives and merchants alike. The success or failure of new payment mechanisms can more accurately be determined by assessing the balance of value propositions between the three constituents (rather than the traditional approach of offering lopsided value to just one or two constituents, which results in failure). Keep your eyes on this one! Read more...

PCI Council And Passwords: Do As We Say, Not As We Do

Harry Maggiore, can i get this in writing ? Given they do not collect store or transmit card holder data, they are not subject to the specification. i have proven to my QSA that we do not collect any card holder data within our system except for the last four digits... and i am still required to implement all 12 PCI requirements throuhout the whole IT landscape and infrastructure. Yes, we are a retailer, and yes, we do a lot of credit card business... but we do not store card holer information other than the ccPAN masked, with only the last 4 digits visible. But that doesn't seem to be enough to be PCI compliant? Read more...
The document should be one that the PCIDSS has in their possession with their own security. I really don't see the purpose or the reason to password protect the document. If a level whatever credit card processor wants to make changes to the document and they compare the original with the one submitted this would in my view be fraud and subject to some very serious fines. Read more...
At least it appears that they've removed the spot for credit card information from their fax forms. Read more...
One of my pet peaves with passwords is the 90 day rule. That, more than anything else I would imagine, is the reason you find passwords written on the back of postit notes attached to monitors. Read more...
Irony? From the association that was created to inflict tissue-paper security protocols on the rest of the world, and whose mandate is to punish organizations that don't build a proper steel safe to guard their used tissues? Their foundations were built on irony. Why are you so surprised? Read more...
Compliance is not the issue. As we--and tons of others--have noted, PCI is not just for payment. Officially, of course, it is, but the guidance, guidelines and best practices contained in PCI is a good tool for anyone to use when needing to protect any kind of data. The irony here is that the PCI Council didn't opt to use its own advice. Read more...
Given they do not collect store or transmit card holder data, they are not subject to the specification. Read more...

Chip-And-PIN Hack Is So Scary Because It Surprised No One

Recently the EU shifted some of the burden of proof back to the banks and this was done prior to this Cambridge report. If the system is so secure, why the shift? Read more...
This hack has been available for over 8 years now. I doubt this should be a surprise to anyone. Read more...
The fact that this particular hole went undiscovered for at least six years is actually pretty impressive. I'm willing to bet this particular issue can be resolved in the terminal code without having to reissue all the cards. This is a great example of the importance of ethical hacking. Hats off to the Cambridge team. Read more...
How do you equate the failure of a developed-in-secret, 14-year-old cryptographic protocol with the adoption of object oriented programming, the recognition of design patterns, or the maturity of software engineering as a discipline? There were no software failures here, no code crashes being exploited nor buffer overrun attacks smashing stacks. This was a failure in the design and creation of a *protocol* that fell prey to being spoofed. No objects failed, because no objects were transmitted. Read more...
Sure, you may hide all the cables but the setup will be obvious if you are wearing a T-Shirt. ;) EMV has to fix this. I don't know if the same issue has been raised in Canada. Read more...
I worked on EMV project in Canada. EMV is better than plain MSR card. No doubt. This is not marketing "gimmick". The Cambridge/BBC video shows a guy using a Netbook PC and an EMV "test card" hooked on a stolen EMV card. Sure, you may hide all the cables Read more...
This hack demonstrates a much larger vulnerability that goes way beyond payment authorization. Just as we are hearing more about cyber attacks from overseas, we are using software design techniques that make our systems more vulnerable. Better get a kerosene lamp. Read more...

Pizza Hut CIO Proving The Unprovable: Mobile ROI

Hats off to Pizza Hut! Their iPhone app has a very well designed user interface. It actually makes ordering a pizza on your cell phone fun. I'm generally not a huge fan of food companies creating apps because they offer me very little extra utility. Large scale brick and mortar retailers should focus on the location based aspects of mobile commerce, and not try to simply port their web strategy into mobile. Mobile requires its own strategy, as does other forms of app marketing (social apps and sharing, etc). Finally, should Pizza Hut be considering other app platforms as the platforms become more saturated? For example, car electronics. Read more...
Dave said: "Domino’s app is sub-standard to say the least (so is their website!)" Well, so is their pizza, but that's another issue. Read more...
At last someone has a decent grasp of what iPhone apps should include. A nice simple idea that uses the technology in an iPhone to maximize usability. Interesting use of technology for the payment processing as well. Too many brands are currently jumping on the app bandwagon and failing, Domino's app is sub-standard to say the least (so is their website!) Read more...
The Pizza Hut app is a great example because its useful, engaging, and leverages the capabilities of the phone. Yes its specific to the iPhone, but there's no better place to start. You certainly wouldn't criticize someone for releasing their software on Windows first and following-up with other operating systems once its proven. Read more...
Greg, Using the numbers you provided yourself, 42% of iPhone users are less than 34 years old! That's huge! I am not saying this is not a worthwhile demographic, in fact in the case of a pizza brand, that is precisely where you want to be. Read more...
I believe this is a terrific example for a couple of reasons: Remember the app was prominently featured in Apple iPhone commercials run nationally. I have heard estimates as to the value of that exposure. The number is large. We are still in the very early days of mobile commerce. Pizza Hut made a bold decision and I believe have been handsomely rewarded for their gutsy call. From a US perspective the iPhone user is the perfect demographic to experiment with. Read more...
Fabien, I have to respectfully disagree with you. First, you shouldn't look at the worldwide smart phone market when looking to deploy a US only mobile application. You have to look at the US trends. You can't doubt the popularity of the iPhone here in the US. Secondly, the iPhone is not for "young, urban professionals." Neilsen published numbers that show there are just as many iphone user 55+ years old as there are 13-24. Read more...
Creative use of technology, well suited to the likely audience: mostly young, students or urban professionals, many of whom with iPhones. However this particular use-case may not be portable to other industries and categories. Read more...

A CIO Do Not Call List

I am in. I completely empathize with Todd. I also do not answer my office telephone and am bomparded by repeated, irrelevant, and more often than not arrogant emails, to the point that I am now starting to set them up in my junkmail filter. Read more...
Don't answer your phone but on your voice mail provide a "if you have a product or svc you want me to consider email me at" and then provide an email address like vendor@. Then when you are looking for a solution you can search that box based on key word and see if anything is helpful to you. Read more...
Take it from me, most CIOs have too much on their plate already. The last thing that they need is someone solving a problem that is not on their Top Priority list. It may be a great system/solution that will save or make the company money, but if it's not part of the current burning-platform, there simply are no cycles to think about it right now. Read more...
I've been dealing with a pesky sales rep from a leading firm that offers log monitoring / management capabilities who just can't accept we are not interested in her product line. For some reason, even though several managers, including myself (security and risk), our auditors, our vendor relations manager, our CIO, the PCI business owner, etc. have all told her we are not interested, she insists on sending each of us e-mails or making calls every month or so. Read more...
Todd P. Michaud you will always have a pass on my DNC list. Call me any time. Just please don't call my wife--that would be awkward. Read more...
Todd L. Michaud has written a brilliant article about common sense professionalism, says Todd P. Michaud, CEO of one of those "darned I/T services providers!" I am certain that I would at least pronounce his name correctly. Read more...
Amen Brother Todd!! This is so annoying and 99% of these callers took zero time to understand who I am or what my company's needs might be. I used to hate being rude, but I'm over it. Sign me up as a charter member. Read more...
Sitting on the consulting side, I am amazed by the number of retailers that send out RFP's to companies, or request additional information, and then don't have the courtesy to say 'Thanks' in an e-mail reply, or 'We'll get back to you if we're interested". This after contacting you and requesting infomation/a proposal ASAP, which takes time and money to prepare. Read more...
Welcome to the real world of capitalism. This is the US, not China. Read more...
Made my day. I know all vendors (including my company) deal with this double edged sword - how to acquire new leads but not annoy folks. My favorite was the young woman who called me, would not take a breath so I could question her and then yelled at me because I said her solution was way out of my budget. Read more...
I'm in. Let's get started. Read more...
This list and process is needed. You left off one thing, the cold caller that gets someone in the business to transfer the call to get past caller id... automatic on the list. Read more...

What’s The Rush For New PCI Call Center Requirements?

And I have not heard anyone mention the impact on companies who provide quality improvement services. Many merchants hire quality improvement companies to review their audio recordings to provide guidance on how to improve their sales staff’s effectiveness in customer service and sales retention. PCI Council needs to rethink this requirement until there is a widely available commercially viable solution. Read more...
Another ridiculous decision where regulators don't think critically enough about the unintended consequences of their decision. This will be a huge problem for the credit and collections industry. We have to keep all recorded calls for other reasons not related to cc information. We can't purge all of our calls and we don't have the technology to not record part of the conversation. Even if we did, I am not sure we could afford it. Read more...
This "clarification" is causing a lot of panic with large FS clients who now appear to be non-compliant after spending 7 figure sums on their compliance programs. The only alternative to call recording would now appear to be some sort of IVR/push button type interrupt to take card data away from the contact centre. The council is a position to force that sort of process and technology change and this may backfire on them and the vendors that lobbied hard for this clarification. Read more...
PCI council has made a one-sided decision; They should have done a much more in-depth research that could have provided more insight on what regards to the implications of such decision. Read more...

Will Old OS Cause PCI Violation? No, But Marketing Still Says So

This is an interesting issue, because there's more to it than what's apparent on the surface. PA-DSS requires supported and patched operating systems and other software components (e.g., databases, libraries, Java, etc.) per PA-DSS 7.1.b and 8.1, and the option for compensating controls simply isn't there. Merchants can make use of compensating controls for most PCI DSS requirements, but only when legitimate constraints exist and only in ways that meet the intent and rigor of the requirement and go above and beyond the other PCI DSS requirements. Read more...
Why would one automatically upgrade to a "new" OS -- some of the older versions of certain OS-es are more stable and more robust than the crap being peddled today. This is yet another clear example of PCI SSC being out of touch with reality. Rather than requiring a "current" OS, the requirement should be to demonstrate the OS in use is stable and robust, and is adequately hardened against threats. Read more...
There are compensating controls that encrypt the swipe at the driver level as it enter the PC, there are hardware encrypting card swipes so the cardholder data is already encrypted before it comes to the PC -- either of these, especially the second, would remove the OS entirely from a cardholder data risk profile. Read more...
In my opinion, the only thing the vendor did wrong was they didn’t know of that FAQ entry. Even if they did, it changes nothing about the need for merchants to update software that no longer receives updates. Read more...

MasterCard Blinks, Drops Dec. 31 Level 2 PCI Deadline

Reciprocity between MasterCard and Visa was always been a factor in Acquirer merchant level assignments. The brief removal of reciprocity generated a great deal of interest in being able to be classified at a lower level in MasterCard's world. Nevertheless the return of the reciprocity language in the December changes did not effectively create any new Level 2 merchants, but it DID dash the hopes of a lot of them.... :-( Read more...
Let's given them credit??? For being idiotic in the first place? Not on your life! Everyone has just had to scramble and include the costs of the previously announced M/C requirement in their 2010 budgets, and start negotiating with the QSAs for the additional services. All for naught! Read more...
"A bunch of Level 3 and Level 4 merchants just became Level 2s". Is this an accurate statement? MasterCard & Visa have historically included the caveat "or is a Level X in another brand" in their level setting criteria. MasterCard appeared to back way from this in the June pronouncement, and have simply returned to the status quo. Have Acquirers have been tracking and reporting merchants at separate levels by brand? Read more...
I stick by my comment (quoted in the column) about a bunch of L3 and L4 merchants becoming L2s and requiring an onsite. To me, what made MasterCard's original requirement for an onsite assessment for L2s palatable was that they took away their reciprocity provision. That is, they seemed to focus on larger merchants with over a million MasterCard trans/year. With reciprocity in place, a lot of smaller merchants are pulled into the onsite requirement. Rather than causing confusion, I think reciprocity will lead to additional work for processors and acquirers. Read more...

Retailers Sue POS Vendor, Questions Raised Where PCI Duties Stop

I would add a couple more questions: "did the breach involve the use of the default passwords?" (The story doesn't say.) And "were the default passwords used by Computer World to remotely administer the store systems?" "where is the PCI auditor in all this?" Did the restaurant group think they didn't need an audit because Radiant was (mis)representing Aloha as PCI compliant? How is a retailer or even a PCI auditor to know otherwise? A PCI auditor is not necessarily a qualified computer forensic investigator capable of finding the card data on the hard drives. They can only base a decision on information given to them by others. Read more...
There are so many holes in the process it will be difficult to pin blame on just one constituent. It is ridiculous that the technology exists to better secure these transactions (PIN, EMV, etc) yet banks won't use them. Only the banks or government can force this change, and retailers will suffer until then. Read more...
A major issue in this case will be if the restaurants had any support agreements in place with Computer World and if so what those agreements say. In my experience many single unit/small operators choose to skip the support agreements in favor of a "pay as you go" arrangement. In this scenario I can't imagine how the POS VAR can be held responsible for a system they don't own nor exclusively manage. Read more...
There is a big difference in having the POS installation guide say "make sure you set this password because the security of your CHD depends on this" vs. a POS application not storing the CHD in the first place. Traditionally only the merchant was liable for breaches and PCI related fees (fines). Maybe dragging some of the vendors into the liability mud fight will open the eyes of some of these vendors. Read more...

Should Credit Card Transactions Be Free? There May Be A Way

Here in the Netherlands, where the population is notoriously penny-pinching, credit card acceptance is amazingly low. It's both a result of the consumer not wanting to pay interest on everyday purchases as well as merchants not giving up a slice of the action. It is both legal and common to pass the processing fee onto the customer as a surcharge. Now things are moving to leave the credit cards behind: mobile phone payments are becoming more and more common here, and the transaction fees are minimal. Parking and entertainment (movie/concert tickets, nightclubs) have been amongst the first, and it's rapidly gaining momentum because the market has been hungry for the convenience at a price it is willing to pay. Read more...
"Free" is an illusion. Don't charge one person but charge double to someone else. I am very skeptical on anyone who says that advertising will create valid cashflow. Just look at the advertising struggles in a TiVo world. And if you sell your customers data, just be warned that the one group that might have issue with that are you customers (which to me is very important to cashflow. Read more...
Another factor not mentioned here is the impending costs that the processors and issuers are going to incur when someone decides on an end-to-end encryption method, and it then becomes government mandated. I can guarantee that this is a when question and not an if question. The back-end networks are pretty antiquated right now, and it's going to cost billions to replace everything. The cost of tech may be going down, but the cost of replacing millions of servers and hardware, and creating new, proprietary, software is still really expensive. Read more...
Accepting credit cards are not "risk-free" for merchants, contrary to Jim's comments above. Chargebacks are an expense - both in terms of actual transaction reversals and costs associated with managing the process. Chargeback rules and expenses can be everything from a thorny issue to an onerous expense for some merchants, especially for convenience stores that allow customers to pay for gasoline at the pump, or other retailers that allow in-store self-checkout options. Read more...
I've wondered for years why the price of transactions has been so high. Phone companies long ago started offering unlimited calling for flat rates because they understood that in many cases it cost more to report on the transactions (calls) than it did to fulfill them. Read more...
If a home-owner defaults on the mortgage, who is taking the risk? The bank making the loan to the consumer or the person selling the house? It is obviously the bank that takes this risk and is rewarded for that risk through interest rate charges. In my mind, we have mixed together two distinct and unrelated transactions. Read more...
The one big factor not mentioned in this article is who will take over the risk ? Taking credit cards is risk free to merchants and the issuing Banks take the risk if a customer defaults on the payments ! If you had a "interchange free" payment system will the merchants assume the risk ? Also, if there isn't enough profit for the issuing banks they will stop issuing credit cards which will in turn kill our economy. Read more...

The Dangerous Out-Of-Scope PCI Charade

If tokens are ever deemed in-scope, then where does the line stop? I ask this because it would mean that all timestamps, sequential number, random numbers or any other piece of information that may or may not be used to generate a token is within scope -- all data a POS uses and stores, not just payment data. Read more...
Having the ability to do both Tokenization and End to End Encryption (not mere point to point) can have tremendous scope and risk reduction benefits and agility to adapt to change in this fast moving compliance landscape. Being able to have both on tap from a single platform is a solid approach to avoiding the pitfalls. Read more...
But the consumer walks into a particular retail chain, gives their payment card to someone wearing that chain's uniform and the card is swiped. If, six months later, there's a breach and that card was misused, it's the retailer who will in the spotlight. They're the deep pocket and, therefore, the target. If the consumer is angry and wants to cut off business, it will hit the retailer. Therefore, if the retailer is going to end up being blamed no matter what, they have to stay involved. Read more...
True, that someone may be storing a token-to-PAN cross reference. But that would be the bank, not the retailer. If the bank is not sure they can keep their data secure, then there are bigger problems to be addressed than bringing tokens into scope. Read more...
Good general point, Steve, but for the record, not all tokenization is done the same way. Many tokens are associated with lookup lists that allow for them to re-matched to the card data if it's needed, such as for a chargeback. A token doesn't have to be decryptable (is that a word?) for there to be a way to access the original data. Read more...
The out-of-scope argument is very valid but in reference to tokens, the premise of temporarily out-of-scope or abruptly deemed in-scope is flawed. Conway was quoted “anything that could be made unreadable can, in various ways, be made readable again,” this statement is true when talking about encryption technologies (all encryption technologies) but not so with true tokens. True tokens are in no way related to the original data other than as a reference key. Read more...