10
Apr
09

The ‘I Have To Keep The Data’ Myth

I started this blog to dispel myths and a big one came up at last week’s House hearings.

Michael Jones, CIO of Michael’s Stores, stated, “As a retail CIO, there is nothing better than to not store a single credit card number anywhere in our network of systems.  But that data has to be kept in case of disputed transactions.”  What?  But this is a myth that you hear a lot from merchants.

I hear it the most in large organizations from their fraud prevention departments.  And while I understand their need, I think the PCI DSS provides them with more than enough capability in the first 6, last 4 truncation rule on primary account numbers (PAN).  Even using the approved truncated PAN can do just as much for fraud detection and prevention than having the full PAN.  If they still complain, then I recommend using a salted hashing algorithm on the PAN.  Under this approach, the PAN is no longer considered cardholder data, but the same PAN will hash to the same value making full text searches still functional.

You also hear this myth from accounting and credit management personnel.  These people are driven by the need to have the data available just in case.  Remember, for most merchants, disputes are not a big percentage of their transactions, typically less than 1% of all transactions.  But, for a Level 1 merchant doing 7 million transactions a year with a 0.5% dispute rate, they have to handle 35,000 disputed transactions per year.  So the volume can be a problem.  To address this, the accounting types pushed for and got the credit card data stored on a system to research these disputes.  It was for convenience.  However, in today’s networked world, access to this sort of transaction data can be provided by the merchant’s acquirer.  After all, it went through their systems as well.  All a retailer needs to be able to provide is a transaction number, transaction date and time of other unique transaction identifier and the first six and/or last four digits of the PAN so that they can link up the transaction with the acquirer’s data.  In many instances, acquirers can provide merchants with online access to their transaction databases for transaction lookup just for this purpose.  Granted, only a select few people at a merchant will have such access, but it can be obtained.  For smaller merchants, acquirers will provide transaction details back by facsimile for research purposes.

So, get off this ‘I have to keep it’ bandwagon.  There is no reason that a merchant has to retain cardholder data.  In today’s world, there are many ways to get the job done without putting the data at risk.

Advertisements

0 Responses to “The ‘I Have To Keep The Data’ Myth”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


Announcements

If you are posting a comment, be patient, as the comments will not be published until they are approved.

If your organization has a PCI opportunity, is in need of assistance with a PCI issue or if you would like the PCI Guru to speak at your meeting, you can contact the PCI Guru at pciguru AT gmail DOT com.

I do allow vendors to post potential solutions in response to issues that I bring up in posts. However, the PCI Guru does not endorse any specific products, so "Caveat Emptor" - let the buyer beware. Also, if I feel that the response is too "sales-ee", I reserve the right to edit or not even authorize the response.

Calendar

April 2009
M T W T F S S
« Mar   May »
 12345
6789101112
13141516171819
20212223242526
27282930  

Enter your email address to subscribe to the PCI Guru blog and receive notifications of new posts by email.

Join 1,904 other followers


%d bloggers like this: