By David Mertz
Compliance Security Partners LLC
If cardholder data is supposed to be secure, how come so many card numbers are floating around? With all the focus on the Fair and Accurate Transactions Act of 2003 (FACTA), would merchants want to expose themselves to the potential legal liability?
Why, with FACTA having been passed, which prohibits merchants from printing full card numbers on receipts beginning Jan. 1, 2008, are card numbers still appearing on receipts?
Why, why, why?
I am tired of scratching out the card number on the merchant's copy of the receipt. The merchant is not entitled to my card number once the swipe has occurred, the transaction has been transmitted and the approval or denial of the transaction has been received by the merchant. Not on a receipt, in a database — not anywhere.
Failure to meet this basic requirement exposes merchants and acquirers to significantly greater risk than any chargeback. Sure there are exceptions (recurring transactions, or using the old imprint devices), but those exceptions require their own protections.
The merchants have everything they need from the signature: validation of identity by requesting secondary identification (a practice which is, thankfully, becoming increasingly common), a transaction ID, an expiration date, the last four digits of the card number and an authorization code. What else does the merchant need to prove the transaction occurred? Nothing, according to Visa Inc.
At the Midwest Acquirers Association in July 2007, I was asked to make a presentation on information security responsibilities in the acquirer's offices. And I addressed many of those. However, when I arrived in Cleveland for the conference, I encountered another troubling aspect of card data security failure.
I stopped in the gift shop of the hotel, picked up a few items and used my Visa-branded debit card to complete my transaction. And what should appear on the receipt - my full card number and the expiration date on my receipt as well as the merchant's receipt.
As force of habit, I started scratching out the card number. I informed the clerk that the shop needed to update its terminals because retailers are not allowed to print full card numbers on receipts. The clerk informed me that her manager didn't care, and to not bother scratching out the card number on the receipt because the manager was just going to reprint the receipt.
This is a merchant who has not been properly trained by the acquiring community. How could this happen?
Not to pick on my friends at the MWAA, but shouldn't the organization hosting the event ask the hotel if it is compliant with PCI and applicable federal laws before booking a reservation there?
How about the other regional acquirer association shows, or any show involving electronic payments? Shouldn't this be one of the qualifications when determining which hotel should host the convention?
Let's start by looking at the legal requirements - specifically FACTA. This law states receipts may not include more than the last five digits of the card numbers. No other data on the card or on the magnetic stripe - including expiration dates - may be printed on the receipt.
Under FACTA, if a receipt printer went into use before Jan. 1, 2005, you have until Jan. 1, 2008, to upgrade or replace it. If it went into effect after Jan. 1, 2005, it should have been fixed already.
The legislation does not say merchant receipts can have card numbers and consumers cannot. It says all receipts. Period. Neither the merchant nor the cardholder should have more than five digits of the card number displayed.
For those who think they need to have the full card number on the receipt in a case of chargebacks and other contested transactions, my response: horsefeathers. Visa's Data Security Brief, released Aug. 27, 2007, states, "Consult with their merchant bank to determine whether truncated card numbers are acceptable to facilitate business functions in order to eliminate the need to store this information."
It is obvious Visa does not expect merchants to store the full card number to respond to chargebacks and other contested transactions. The question becomes, if Visa doesn't believe a merchant needs the transaction, no one else in the chain should either. Further, requiring merchants to keep this data on receipts is a violation of federal law and complicates PCI compliance.
And, if these institutions are publicly traded - and what banks aren't publicly traded anymore - then they are in violation of their requirements to be in compliance with federal, state and local ordinances under the Public Company Accounting Reform and Investor Protection Act of 2002 (the Sarbanes-Oxley Act, also called SOX or Sarbox) and may need to report this violation in quarterly reports.
At the very least, it needs to be reported to the organization's Board of Directors and the committee with oversight of regulatory compliance and regulatory reporting.
In August 2007, The Recorder published an article about law firms trying to establish class action lawsuits against retailers who printed full card numbers on receipts. What is important about FACTA is this: No harm needs to be established by the plaintiffs to sue under legislation.
Two factors make merchants vulnerable to litigation under FACTA:
Penalties under FACTA range from $100 to $1,000 per receipt. Multiply that by the number of transactions since a merchant needed to be compliant, and you have the total liability a merchant faces for lack of compliance with FACTA.
Currently, more than 250 class action lawsuits have been filed under FACTA. They involve some of the leading retailers in the country. It begs the question: Why do I still keep getting receipts with full card numbers?
David Mertz is the founding partner of Compliance Security Partners LLC. He has spent the last four years working with merchants and service providers to meet Payment Industry Security Standard compliance. For more information, e-mail firstname.lastname@example.org.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next