I ran into a situation recently and wanted to voice my disgust over it.
I have a friend that runs a side business with their spouse and, of course, takes credit cards for payment. They signed up with a processor and obtained a logon to the processor’s Web site for processing card transactions. A couple of months ago, he called me because he had gotten a letter from his processor saying that they needed to be PCI compliant. He called me to find out exactly what PCI compliant meant. So, I listened to how his business operated and told him to fill out and file an SAQ A with the processor since the processor gave them no guidance.
They filed the SAQ A with the processor and then got a call from the processor asking for certification of the SAQ by a QSA. The processor explained that if they did not have a QSA, the processor would charge them $185 to have a QSA certify their SAQ. So, I get a second call from my friend asking about this latest twist of events. I explained to them that having a QSA review and certify an SAQ is not a PCI requirement. As a matter of fact, the filing of an SAQ by a Level 4 merchant is recommended, but not required by the card brands.
So, now I have a call with this card processor who is demanding that my friend pay them $185 to obtain a certificate from a QSAC certifying that he is PCI compliant. I speak with a customer service supervisor who explains to me that their company requires that all merchants they process are required to work with one of their recommended QSACs or any QSAC of their choosing.
I asked them to direct me to the PCI DSS or any PCI requirement that requires a QSAC to sign off on a Level 4 merchant’s SAQ. The supervisor stated that there was no PCI SSC requirement for this; it was their Firm’s requirement. They then listed off a number of recognized QSACs that could provide such a certificate for my friend. I was shocked at the number of big QSACs that this person listed off and was surprised that some of these QSACs would be willing partners in this organization’s PCI compliance program. Unfortunately, a couple of the QSACs this person named did not surprise me as I have always questioned their motives in the PCI compliance arena.
When I asked the supervisor if I could provide a PCI Attestation Of Compliance (AOC) as my friend’s proof of compliance with the PCI DSS, I was told that an AOC was not acceptable and that as an QSAC, my firm would be required to provide a certificate. When I asked what the certificate would look like, I got an indignant answer that as a QSAC; I would already have that information. I found this extremely interesting, since no such “certificate” has ever been defined by the PCI SSC. And near as I can tell, these “certificates” would not be worth the paper they are printed on. And if shown to any of the card brands, would likely be laughed at as “proof” of anyone’s’ “compliance” with the PCI standards.
Needless to say, this conversation did not go well nor did it last much longer.
But this conversation brings up an issue with the PCI compliance program that has existed from day one. How do you keep the program relevant to merchants and service providers when you have nonsense like this going on? These sorts of actions by organizations just add fuel to the fire for critics to use as another argument as to why the PCI compliance programs are pointless and organizations should not bother with complying with any of the PCI standards.
Another problem this situation points out is how uneducated merchants are to the PCI compliance programs and processes. Even though everything about these programs is documented on the PCI SSC Web site, there are vendors and service providers that abuse their position with these organizations and knowledge of the PCI compliance programs and processes all for their financial benefit.
I have submitted a question to the PCI SSC regarding this situation and hope to have an answer from them in the next few weeks as to whether it is legal or not. I also intend to bring this situation up at the Community Meeting as well. In my view, this situation is highly questionable and in my very humble opinion the processor should be forced through some sort of remediation program just like the QSACs face.
I got a good one! I get charged $150 a year for being PCI compliant. Have to take the test every year and get no certificate or any thing else except the charge! My processor tells me they don’t charge that. The charge comes from Security Metrics. And I sure the H.. not on any compliance list I can find.
SCAM!
I was told basically the same thing. I went to a site Security Metrics and took the survey, passed and was given a certificate to copy. For the past year Security Metrics has been telling me the q&a I took was no longer valid and I needed to take the updated one. My Processor said I was compliant so I think Security Metrics is a scam. They just want you to pay for the upgraded version which isn’t required. I wonder how many got sucked into paying this needless fee? You can take the q n a on line free. It takes about 15 min and is a bunch of bull. You could tell them what they wanted to hear and pass. No follow ups or proof your doing it by their standards. I recommended you take the test once for free, download the certificate and your compliant Listen to no one trying to sell you an upgraded system, it’s bull.
Would love to talk to you more about this. We see it all the time from many processors. The bottom line is that PCI is a profit center for these guys to make up for shrinking margins. The last thing they want or care about is the compliance status or security of their merchants, it is all about how much can they charge the merchant. Would like to do a podcast on this if you are up for it, contact me
Since the PCI compliance program is essentially an unfunded mandate from the card brands on the banks and processors, I don’t have a problem with processors charging their merchants a nominal “filing fee” or “PCI compliance fee” for managing their PCI compliance program. These organizations have to track the progress of their non-compliant merchants, review ROCs and SAQs, as well as report information back to the card brands, so recovering some of their costs should be expected.
However, for a processor to come up with $185 and then also demanding that a QSA sign off on the SAQ is just not right. These sorts of processors usually have arrangements with a few QSACs for handling these sign offs. And there is usually the requisite arrangement of spiffing the processor for every merchant that gets the QSAC to sign off on their SAQ, so the processor gets their fee as well as a spiff. But this is the first one I’ve run across that points their merchants at the PCI SSC Web site to find a QSAC. As a QSAC, I have issues being associated, even indirectly, with such an organization and what merchants would likely perceive as a scam. These organizations have to know that a QSA is also going to charge for signing off on the SAQ, just further infuriating the merchants. It just makes everyone look slimy and not above board. That is why, in my very humble opinion, this sort of practice must stop.
I see a few issues here really…
1) shame on the processor who has clearly taken advantage of the PCI standards lack of specific guidance for the purpose of making a bigger profit. They sound incredibly shadey and I wouldn’t want to do business with them or any of the QSAs that are on their approved list (as they should know it’s wrong too). The PCI SSC, I believe, has left some things undefined or open to the processor/aquierer/QSA to decide because there is no one fix for every merchant… the systems are different and they way they need to be handled is different. They haven’t given that right of power so that it can be abused for personal gain.
2) the PCI standards, unfortunately, have opened a shadey door that’s all about lining pockets with an extra profit. I think it started out with good intentions… yes – a lot of merchants needed better security. But merchants weren’t the only ones. They shouldn’t be required to dish out the amount of money that is required to be compliant. Compliance isn’t security and unfortunately compliance, in many cases, can cost more than simply being secure. Either because of required systems/applications or because of processor or QSAs that require un-needed certifications/applications/network changes/etc. I agree that we need better security – there is a real threat out there. But we need better security all the way around. With everyone being responsible and held accountable for their portion – not dumping all the blame on the merchants. This isn’t a one way street and the issues aren’t entirely the fault of the merchant. In fact, had better care been taken up the chain – the merchants wouldn’t have been able to create the problems they have. They should care for protecting their customer’s privacy, if for nothing more than their reputation and success… without that – even with the PCI requirements, all they’re going to do is check the box regardless of it being true or not and deal with a breach if and when it happens.
3) the PCI SSC and, ultimately, the card brands have opened this window for shadey business – they should be able to lock it down as much as possible. What – a processor is manipulating the system and forcing merchants to pay for something we don’t require? Well then they should be taking action against the processor – take away their rights, increase their costs, something – anything! They shouldn’t just turn a blind eye and say “well it’s their decision to manipulate our program to their own profit – not our problem”
As PIN Head mentioned – this really should be a matter of everyone actually working together to better the system and protect cardholder data… it shouldn’t be everyone working to line their pockets at the expense of the merchant who essentially has no say. Everyone isn’t working together – they’re working individually and still not toward the common good.
I had this same conversation with the PCI SSC last year. Their answer:
Many of the Processors are using QSA to help them get their merchants complaint. Many do not have the knowledge or the bandwith to handle the large endeavor it takes to get all these entities to validate compliance.
It is a business decision who they force their merchant to deal with or any fees they charge. This is out of the scope of PCI. Only their processor can tell you want SAQ they expect to receive from a merchant and or how they receive it.
Unfortunately you are at the merchant processors mercy.
I was not happy with the answer but that is the way it is.
The issue really stems from the PCICo written standard. The requirement for Level 4 merchants is that validation is at the discretion of the acquirer. With that said, the acquirer then has the power to require (read: demand) a certificate to validate compliance. In many cases, the managing person at the acquirer isn’t qualified to assess the SAQs — its merely a measure to protect themselves.
I understand that from the merchant’s perspective it seems unfair, but who is protecting the acquirers in this mess?
?
I think your friend have to do is changing of service provider/processor. Period.
FIs, PSPs and Merchants, all of them, have the responsability to comply with PCI-DSS.
PSPs and FIs are responsibles that all of their merchants are compliant, but I think it is not good marketing strategy to force merchants to pay for nothing.
What FIs and PSPs have to do is provide tools and procedures to the merchants so they are not worried about PCI compliance. An example of this could be adopting EMV standard. Ok, that is only a solution for Card-Present transactions but you can create more solutions for CNP scenarios.
My friend is already getting a new processor because of a lot of other issues with his original processor.
I have been in this industry long before the PCI SSC have existed and have watched the evolution of this program grow. The program is a sham, scam, whatever you want to call it, by the card brands and big issuers. It still amazes me that the card brands and issuers have convinced everyone that the merchants, acquirers and service providers have to front the cost of protecting cardholder “sensitive” data. Data that is stored in the clear on the payment product to begin with. The card itself is issued non-compliant to PCI DSS. Issuers store and transmit clear text magnetic stripe data using a distributed database known as the credit and debit card. I have several such clear text magnetic stripe data records in my wallet everyday. How anyone can think you can protect data that starts out in the clear is beyond me. And that it is the responsibility of the merchant to do so is a joke. I am all in favor of everyone working together to protect the data as we move on to a new, more secure payment product, but I don’t see that move happening anytime soon in the States.
One fix that I have suggested since the formation of the PCI SSC is that the council have a mediation body that resolve issues like this one. They created the requirements and then have no method to resolve issues based on interpretation of these requirements. The answer of “the QSAs are trained” is not the solution.
BTW, has Citibank been fined for their data breach yet?
Everyone in the payment stream has a responsibility to protect cardholder data, including the cardholder.
Merchants and service providers got sucked in because they were doing a poor job (if they were doing any job at all) of protecting cardholder data that they knowingly or unknowingly were retaining in their computer systems. Most had no idea that their computerized point-of-sale (POS) systems were storing credit card numbers because the software vendors weren’t telling them. Financial institutions are now starting to get sucked into the compliance process as we are now getting a lot of calls for PCI assessments from FIs.
Unfortunately, there is a lot of infrastructure in place using the current credit card configuration in the US which is what keeps Chip and PIN out of the US. However, Chip and PIN only works for stopping face-to-face fraud not the other frauds. And then there is the fact that the mag stripe and chips do nothing to protect that data. As I have stated before, what will be a game changer will be the advent of single use transaction codes generated at the time of the transaction. American Express did this with eCommerce transactions a number of years ago, however they pulled the plug on their trial and I never heard the reason why. In its present configuration, Chip and PIN could go a long way in securing online transactions, but no one has ever stepped forward to create a standard API that would make this possible.
We will probably never know if Citibank is fined and by what amount. Bankers like that sort of thing to be kept private.
If the issuing banks were charged back every time they authorized fraudulent transactions instead of declining them, then the problem of having to secure data that is inherently not secure (it’s imprinted on the front of the #$@$ card!) would get solved pretty much tomorrow, and the need for PCI DSS on the merchant end would become much less important as the processing network actually became smart enough to detect and prevent fraud.
It is 2011. If someone pays with a credit card, I should be able to call an API that transforms that to a unique hash and be able to issue authorizations, captures, and credits against that hash until the end of time or until the customer or bank revokes that permission. And it should be a standard. Some gateways kind of sort of do this–but it’s proprietary to the gateway, usually expensive (CyberSource), limited to a single auth & capture (AuthorizeNet), and not visible to the banks or the consumer (negating its use for tracking or for limiting damage in a data breach).
If I could stop storing card numbers tomorrow I would, but doing so means (1) lost conversions due to customers having to re-type card data on subsequent purchases; (2) lost fraud prevention tools since banks won’t do a manual AVS lookup without the full card number, which is useful if someone e-mails a corrected billing address; and (3) difficulty processing backorders and long term refunds.
> American Express did this with eCommerce transactions a number of years ago, however they pulled the plug on their trial and I never heard the reason why.
My guess would be that it had usability problems. Verified by Visa, for example, is a usability fiasco (“don’t ever give out your banking information–except you should do it right after this sketchy redirect!”) and is largely ignored by ecommerce merchants as a result–it’s better to take the risk than the loss in conversions. The banks have no incentive to make it better. Since the merchant is the one who’s often footing the bill when it comes to ecommerce fraud, what incentive is there for the banks or the networks to actually prevent it? To actually make AVS reliable?
Since the banks and the processors are so chummy, I think the only way that any of this would change is if some of the major retailers–I’m thinking Amazon, Walmart, and Target–got together and created an independent network that sidesteps the existing PCI, one that actually solved these problems.
My two cents. Great post.
Actually, there was nothing wrong with merchants keeping the card holder data like they were in the past because there was no value to the data. Two things changes our from under merchants and acquirers that have caused this data, that issuers at one time even printed in booklets, to become extremely valuable. 1) The increase in the use of this payment product for online (web) transactions with only the PAN data that was being printed on receipts and is embossed on the front of the card and 2) the use of PIN based debit as a signature based product, unfortunately referred to as “offline debit”. This product allows signature based and card not present based transaction to directly debit the card holder’s checking account. And when this occurred the banks did not accept the fact that fraud was possible so card holders were directly affected by fraud. It was not that big of concern when fraud hit a credit card because the card holder was not directly affected financially. Just charge the transaction back to the issuer.
Then comes the PIN debit attacks on top of this from skimming and all that where the banks can now claim “well, the transaction was PIN based so it HAD to be you Mr. Customer.” This wakes up the card holders and then the brands and issuers can point to the merchants and acquirers.
When you say “Everyone in the payment stream has a responsibility to protect cardholder data, including the cardholder” then everyone should work together. If we all worked together then we, and when I say we I mean the brands, issuers and the PCI SSC, would not immediately come out and throw PCI-DSS complaint merchants or acquirers under the bus. If everyone was really supposed to work together to protect this data then we would all together to improve the system.