By Ken Musante
Eureka Payments LLC
This is the second of two articles on the increasingly common Payment Card Industry (PCI) Data Security Standard (DSS) compliance fee. The first article, "What does a merchant get for a PCI fee? - Part 1," was published in The Green Sheet, June 14, 2010, issue 10:06:01.
I had posted on GS Online's MLS Forum that I was a bit confused about what merchants get in return for this $5 to $15 monthly PCI fee. Seeking clarity, I asked Forum members the following:
STEVEN_PEISNER addressed some of the finer points of my questions. "1. Yes, PCI fees are about as common today as the daily conversations about the topic," he wrote. "When dealing with a retail merchant, it is something that I do not look forward to discussing because a lot of them just don't understand it.
Most retailers think that PCI DSS (although important) only has to do with e-commerce, Internet and MO/TO merchants all in the CNP [card not present] world.
"Now when you are talking to a large Internet retailer or MO/TO merchant processing thousands of transactions per month, they usually have someone at their company assigned to security, so it makes the job a lot easier. I have personally seen $4.95 per month to $19.95 per month [in PCI fees]."
"2. This is a security issue, and merchants must pay this fee. And if you are PCI DSS certified and there is a breach, you have safe harbor [that way you will not be fined, because you were PCI DSS compliant]. But wait. If there was a breach, you weren't PCI DSS compliant; so you weren't compliant, so you will pay. ... It is a little confusing; isn't it?"
"3. Yes, it's just another fee that we [the MLSs] have to explain in great detail. What merchants feel is that they are being fee'd to death. Look at a statement lately: monthly statement fees, online access fees, NABU fees, Visa network access fees, merchant club fees, international assessment fees, misuse authorization fees, chargeback fees, retrieval fees, AVS fees, and the fee I personally love the most, a 'reversal fee' (that is when a merchant wins a chargeback, the list processor charges them $7 to put money back in the merchant's account). Give me a break!"
"4. It will probably take a court decision to answer the breach question, and as everyone is probably aware, the insurance company is going to look for a reason not to pay as fast as they can. The irony of it is that the insurance company will not pay because the merchant or processor was not PCI compliant.
"Ultimately, as you are aware, it may be the member that will be held responsible, as they should have known what 'their' processor or MSP/ISO was doing. And if the breach is large enough, Congress points the finger at everyone, and everyone pays."
STEVEN_PEISNER concluded that PCI DSS fees and SAQs [Self-Assessment Questionnaires] are a joke. "Data security is very important, but realistically no merchant can ever be 100 percent PCI compliant unless they turn off their computers, unplug the terminal, smash the hard drives and stop taking credit cards," he stated.
"We build a 10-foot wall, and the hackers and data thieves build an 11-foot ladder. It's the old story of good versus evil, spy versus spy or the kid who stopped a dam from leaking with one finger."
IONPS articulated a perspective that was in several of the postings: "PCI is, in my humble opinion, just a big CYA policy for Visa," IONPS wrote. "When major credit card processors and large merchants get breached - and those guys all have full-time and very skilled technical security staffs - what real chance does the small to medium merchant have?
"Don't get me wrong, basic security is needed across the board. However, the vast majority of merchants do not have the time, technical expertise, money or knowledge of the credit card industry to be 100 percent safe 24/7.
For that matter, do you think the average MLS can rattle off even the 12 main PCI DSS requirements for a prioritized approach? What about the sub-requirements? How about the sub-sub-requirements?
"The ISOs out there like FASTTRANSACT that are really putting forward some value and offering the security the merchant needs - by all means charge the fee! You are doing them a great service.
"However, if it is just another fee that is dropped in your pocket, we need to be careful. When folks start throwing another fee into the mix, we wind up getting one step closer to government regulation. ... When I look at merchant account statements now, there are dozens ... of fees on some of these statements. ... A perfect example of this is on my desk right now: a merchant is being charged $12.95 per month for a paper replacement fee. However, he is a website business that uses Authorize.net."
To keep the discussion moving, I suggested valid reasons exist for the PCI fee: many acquirers provide insurance for merchants, scanning services, and assistance in passing the scans, filling out SAQs and in creating policies.
ALEXPHER disagreed, "Referring merchants to third-party certification vendors and ISOs profiting in referral commissions from third-party vendors (in addition to their PCI monthly/annual fee) is in no way 'value provided,'" he wrote.
To get a perspective from the compliance side of the business, I contacted Michael Johnson, President of Comply Guard Networks. He said that most banks and ISOs "offer a PCI service of one form or another. The better services offer SAQ, scan, policy, and merchant education, along with some level of management console for the bank.
"Even more interesting is the noncompliance fees being levied. Those run $20 to $50 per month for a Level 4 merchant. [One large acquirer] is on the street right now with a nasty-gram to Level 2 merchants that if they do not submit their required compliance documentation by a specific date, they will be assessed a large fine."
Regarding breach insurance, Johnson stated, "The early adopters of breach protection called it 'insurance,' and it went out to cover the merchants and processors. ... They require 'all in,' meaning the entire portfolio must be covered, as the policy is written to the acquirer/processor. Most of the programs I have seen have some serious limitations.
"The problem is this protection in no way provides compliance. ... Many merchants believed they did not have to complete PCI DSS requirements because they have this protection. It is a problem now to re-educate these people about what their obligations are. Some frankly do not care, as it is cheaper to have the breach protection than to become and maintain PCI compliance. They do so at their own peril."
Johnson noted that the purpose of breach protection, or an actual cyber insurance policy, is to offset the costs in the event of an incident. "There is already evidence that the liability will flow downward," he said. "Witness also that breaches such as Heartland and TJX yielded class actions that sought relief from those with the deepest pockets. "Everyone loses. Remember the contractual relationships involved. The card brands have the contract with the bank, who has the contract with the processor or gateway or ISO and/or merchant. It gets ugly real fast. The weakest in the chain may not survive. Therefore, it is in everyone's best interest to ... not seek quick-fix alternatives."
What makes this topic so polarizing is the magnitude of liability and the uncertainty as to who ultimately owns the liability. To wit, when an ISO or acquirer assesses a monthly PCI fee that includes insurance, who is liable if, after a breach, the insurer declines the claim?
Consider a large portfolio utilizing a common third party. If that third party fails, each merchant using said third party is at risk for compliance fines. If fines are assessed and the insurer then declines coverage, is the ISO or acquirer responsible for refunding all those monthly fees? I hope this theoretical situation never materializes, but the question remains.
Also, are sponsor banks being properly compensated for the additional risk brought to bear because of the "weak link" argument discussed by Johnson?
CLEARENT raised an additional concern and a fair last point to consider. "Many reps are 'helping' their merchants complete the SAQ," he wrote. "I don't want to attempt to advise you on how you handle this, but my guess is that this would be a really bad thing for you to do.
"Why? It was mentioned earlier that the potential is for a breached merchant to sue the processor over the fees. ... I would think that if a merchant is looking at thousands of dollars (or even tens of thousands or hundreds of thousands) of losses, they are going to go after everyone involved, especially if they were involved in the initial setup process and data sharing ... meaning those who 'help' could find their help not appreciated, and very expensive."
A number of legitimate frustrations exist surrounding the PCI fee, but I will concede one point to the card networks, the issuing banks and those that are working in the PCI field: until rules existed and monetary fines were levied in response to breaches, the industry was not doing a competent job protecting cardholder data.
Consider the consequences were the breaches to have continued along the same trajectory as before the addition of the PCI DSS and the awareness brought about by the scanning and validation companies.
I am very appreciative of all the responses I received. While I could neither post all of them nor fully address all the questions raised, I hope this discussion provided some new angles from which to view this issue and that we brought to light some concerns and liabilities that perhaps you had not previously considered.
Regardless, when in doubt, sell something!
Ken Musante is President of Eureka Payments LLC. Contact him by phone at 707-476-0573 or by e-mail at kenm@eurekapayments.com. For more information, visit www.eurekapayments.com.
The Green Sheet Inc. is now a proud affiliate of Bankcard Life, a premier community that provides industry-leading training and resources for payment professionals. Click here for more information.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.
Prev Next
