Merchant Levels

I get requests all of the time regarding how to determine an organization’s merchant level.  Even though the card brand Web sites have this information posted, the questions still persist.  But even with those tables and references such as this post, it is very important for all merchants to remember that the only entities that can definitively set a merchant’s level are the merchant’s processor(s), acquiring bank(s) or the card brands.

So, while what I am going to discuss in this post should provide the information necessary for most merchants to determine their merchant level, you cannot use this post as the definitive answer on this subject.  This is only my opinion.  Again, if you want a definitive answer, you need to get that from your processor(s), acquiring bank(s) or card brand(s).  Also, before I forget, I have not included a discussion regarding vulnerability scanning, penetration testing and other requirements, so you will need to reference the card brand tables for those other requirements.

One would think that this issue is simple to resolve.  After all, the card brands have this information posted on their Web sites.  So, you just go to their Web sites and figure it out.  Oh, if it were only that simple.

Card Brand Merchant Level Tables

The first problem most merchants run into is that Visa, MasterCard, Discover, American Express and JCB all have tables for merchant levels.  Which leads to the first question merchants typically have; “Whose table should I use?”

The answer is you use the tables for only those card brands for which you have a merchant agreement.  This sounds easy enough, but as we will see later on, might not be as simple as you might think.

Things can get even easier for some merchants.  While Visa, MasterCard and Discover have their own table of merchant levels, if you compare them, you will note that Visa, MasterCard and Discover have gotten together and decided to use the same criteria for determining merchant levels.  So, if the only credit cards you accept as a merchant are Visa, MasterCard and/or Discover, you only need to reference the Visa tables as their merchant level criteria are all the same.  But for those merchants that accept American Express and/or JCB in addition to the other card brands, do not fret.  The card brands have made things easy for you as well.  If you are a given merchant level for any other card brand, you are that merchant level for every card brand.  However, as we discuss the merchant level criteria, for merchants accepting American Express or JCB credit cards, smaller processing volumes of those cards can easily make you a Level 1 or 2 merchant.

With the exception of Merchant Level 3, transaction volumes are the total number of credit card transactions processed, regardless of whether those transactions are card present, card not present, e-Commerce, whatever.  Level 3 merchants introduces the concept of e-commerce only transactions, but we will discuss this a bit later.

The Big, Bad, Ugly Level 1 Merchant

Level 1 merchants are the easiest to define and the ones that must go through the full Security Assessment Procedures and produce a Report On Compliance (ROC).  If you are a merchant that meets any of the following annual transaction processing volumes, you are a Level 1 merchant to all of the card brands:

• Over six million Visa, MasterCard or Discover transactions
• Two and a half million or more American Express transactions
• Over one million JCB transactions

The first thing merchants that have big transaction volumes with American Express or JCB is that they can easily end up a Level 1 merchant with very few Visa, MasterCard or Discover transactions.

I Am A Level 2 Merchant, I Can Do A Self-Assessment Questionnaire

On the face of things, Level 2 merchants are also easy to define.  If your organization meets any of the following annual transaction processing volumes, you are a Level 2 merchant to all of the card brands.

• One to six million Visa, MasterCard or Discover transactions
• 50,000 to two and a half million American Express transactions
• Less than one million JCB transactions

Where things get complicated for merchants is in regards to the credit cards they have agreed to accept, particularly JCB cards.  It turns out that if you have agreed to accept Discover or Diners Club cards, you may also have inadvertently agreed to accept JCB cards.  In the United States and some of Europe, Discover processes Diners Club and JCB transactions and your merchant agreement with Discover may have included JCB.  Overseas, JCB processes for Discover and Diners Club in some countries.  As a result, you will need to review your merchant agreement with your processor to make sure that JCB cards are not included in your agreement.  If your merchant agreement does cover JCB cards, even if you have never processed a JCB transaction (mathematically zero is less than one million), technically you could be classified as a Level 2 merchant by your processor or acquiring bank.

For merchants that accept MasterCard, and that would be most merchants, things get further complicated regarding what you need to do for reporting.  A few years ago, MasterCard tried to get Level 2 merchants to do a ROC for compliance instead of an SAQ.  Thankfully after a lot of complaints, that requirement died a quick death.  However, as of June 30, 2012, MasterCard is requiring their Level 2 merchants to:

• Use an internal person certified as an Internal Security Assessor (ISA) by the PCI SSC to create their Self Assessment Questionnaire (SAQ); or
• Use a Qualified Security Assessor (QSA) conduct the PCI Security Assessment Procedures (SAP) and file a ROC.

So those of you Level 2 merchants that were looking forward to only doing an SAQ, you might want to clear that with your processor first.

And remember, if you are classified as a Level 2 merchant by one card brand, you are that level for all other card brands.  So, if you get caught in the JCB conundrum I described above, you will be a Level 2 merchant to MasterCard and you may have to do a ROC.

What Is A Level 3 Merchant Exactly?

At Level 3, things get a bit more complicated, mostly because at this point some of the card brands do not even have a Level 3 classification.  However, as I stated with Level 2, if you have JCB cards being processed, you will end up as a Level 2 merchant regardless,

Where Level 3 really confuses people seems to be the fact that the criteria now focuses on one particular type of sales delivery method, e-commerce.  If your organization meets any of the following criteria, you are a Level 3 merchant.

• 20,000 to one million Visa e-commerce transactions annually
• 20,000 combined MasterCard and Maestro e-commerce transactions annually but less than or equal to one million total combined MasterCard and Maestro e-commerce transactions annually
• 20,000 to one million Discover card-not-present only transactions annually
• Less than 50,000 American Express transactions

An additional trick with the Level 3 merchant classification is related to the e-commerce sales channel.  According to Visa, MasterCard and Discover, if your organization has 20,000 to one million e-commerce transactions, you can also have less than one million transactions through other sales channels such as physical stores, mail orders and telephone orders and still be a Level 3 merchant even though your total number of transactions technically exceeds one million transactions and is less than two million in total.

As with Level 2, if you are a Level 3 merchant for one card brand, you are a Level 3 merchant for all card brands.

Level 4, I Can Do Nothing

Level 4 merchants process less than 20,000 Visa e-commerce transactions annually and/or process up to 1 million transactions annually.  As with the other merchant levels, if you are classified as a Level 4 merchant, you are a level 4 merchant for all card brands.

As a Level 4 merchant, you are only recommended to attest to your organization’s PCI compliance.  This means that filing an SAQ with your processor or acquiring bank is not required by the card brands.  However, as I posted earlier, some processors are not only requiring that Level 4 merchants file an SAQ, they also require that a QSA sign off on your SAQ.  If you are a Level 4 merchant in Canada, Visa Canada is also requiring that a Level 4 merchant’s SAQ is signed off by a QSA. (As of October 2010, a QSA does not need to sign off on a Level 4 merchant’s SAQ.)

Clear as mud, right?  Well, there are some other issues that need to be considered before you can claim you are a particular merchant level.

Holding Companies And Legal Entities

What can bring the first twist into the merchant level setting process is how your organization is legally incorporated or structured.  If your organization is a holding company with multiple legal entities underneath it, then your multiple legal entities will have their own individual merchant level and require an individual PCI compliance report filing.  A good example of this is Yum! Brands and their A&W, Long John Silver’s, Pizza Hut, KFC and Taco Bell restaurants.  The restaurants are separate legal entities and therefore have their own merchant level and their own PCI ROC.

Sometimes you can negotiate with your processor or acquiring bank to get your multiple legal entities treated as a single entity and do one compliance filing, but they are not obligated to go along with this request.  The key is that you need to negotiate this change before you start your PCI compliance efforts, not after the fact.

Another fact that can complicate this holding company relationship is how the organization processes their transactions.  In some organizations, the individual entities all process their transactions separately under their own merchant numbers and even possibly with their own processor(s) and/or acquiring bank(s).  In other instances, the holding company aggregates transactions from all of the entities, but the transactions are still processed under individual merchant numbers and my be processed through different processors.  And in a third variation, the holding company aggregates the transactions and processes everything under one merchant number.  In the first two instances, typically each entity is going to be responsible for their individual PCI compliance and will report separately.  In the last instance, the holding company is usually held responsible for each entity’s PCI compliance.  However, any determination of what is correct is going to be up to the acquiring bank(s).

And one other thing that comes up regarding holding companies.  There are organizations that attempt to use their legal incorporation as a way to manipulate the level setting process.  They also have each legal entity process transactions through different processors so that their transactions volumes are not known between the processors.  While in the past this was a good strategy to keep your organization creating SAQs, processors have gotten wise to this game and are talking to one another as well as documenting the processors used in the reports.  So for those of you playing this game, it is only a matter of time before you will be found out and possibly have your merchant level changed.

Been Breached?

Take a close look at your merchant agreement regarding PCI compliance.  There should be a statement that says if you suffer a breach, your organization will automatically be classified as a Level 1 merchant for PCI compliance purposes, regardless of transaction volume.  All of the card brands added this to their merchant agreements a number of years ago.

Unless you are already a level 1 merchant, just the thought of not being able to file a SAQ should put the fear of God in you.  Conducting a full ROC, even for a small organization, will likely be extremely daunting and expensive.  So there is added incentive for you level 2 through 4 merchants to make sure that they truly are PCI compliant.

So that is merchant levels.  I hope this gives you the guidance you seek.  It definitely should give you the background you need to discuss the topic intelligently with your processors and acquiring banks.

UPDATE: I ran into a person from Yum! Brands at the 2011 PCI Community Meeting and they informed me that they file one ROC for all of their restaurant brands, however, technically they could file separately for each, but they do not.  I was only using them as an example and apologize for misrepresenting their filing status.

Advertisement

End-To-End Encryption – The Rest Of The Story

Step right up folks.  I have something that will cure all of your problems with credit card processing.  It is called end-to-end encryption.  Yes, folks, it is the be all, to end all in security.  It will cure all that ails you, particularly those nasty data breaches.  Don’t be shy, just step right up and get your own version while supplies last.

Gee, when end-to-end encryption (E2EE) is put that way, it sounds great, almost too good to be true.  And you would be right; it is too good to be true.  But if you listen to the statements of the proponents of E2EE, they make it sound like once E2EE is in place, it is like the Ronco Showtime Oven, “Just set it and forget it.”

Now, do not get me wrong.  E2EE is not a bad thing, but it does have its own set of risks.  And it is those risks that do not get discussed that concern me.  The reason for my concern is that if you discuss E2EE with any merchant, most see it as this panacea, something that will get them out of the PCI compliance game altogether.  However, nothing could be further from the truth.  If anything, E2EE may make PCI compliance even more daunting than it is today.

The first thing everyone seems to forget is that E2EE only removes those systems and networks that are between the endpoints.  That is because the data stream between the endpoints is encrypted and, therefore, out of scope for PCI compliance.  However, for a merchant, that means that the device that accepts the credit card is still in-scope for PCI compliance.  Bring this fact up to most merchants and they start complaining like no tomorrow.

That device might be as “simple” as a credit card terminal or as complex as an integrated point-of-sale (POS) workstation on a network.  However, since this device is an endpoint, the merchant or the merchant’s QSA needs to ensure that the endpoint is properly secured and cannot end up being a breach point.  Depending on the complexity of that device, that assessment might be very straight forward or very time consuming.  The reason the endpoint needs to be assessed is that security is only as good as its weakest link.  In the case of E2EE, the weakest links are the endpoints at which the data is encrypted and decrypted.

The next thing that seems to slip people’s mind is that fact that since the merchant has an endpoint, that endpoint is still a target.  Worse yet, because it is an endpoint, the level of sophistication likely required to compromise that endpoint goes up exponentially, meaning that any successful attack will likely be beyond the average merchant’s capability to readily detect.  The PCI DSS addresses this threat fairly well by requiring network monitoring, daily log reviews, anti-virus, anti-malware, firewalls and the like.  However, I can tell you from personal experience that your average merchant is not going to be equipped to deal with this new threat.

And what is the new threat?  The new threat is tampered with hardware and software.  If you think this is farfetched, think again.  It has already happened on a limited scale.  The doctoring of hardware is fairly straight forward to both accomplish and to detect.  Detection only takes looking inside the device and noticing something that does not belong.  However, doctored software is another story.  The concept of doctored software has been a concern in the health care industry since the start of using computerization for heart pacemakers.  While the health care industry has developed rigorous testing and certification procedures, the rest of the software industry has said there is no need.  That is, until now.  As the world further automates, the need for reliable, safe and secure software only increases because of the reliance people and organizations apply to that software.

So what can an organization do to stem this new threat after implementing E2EE?  Here are some thoughts.

• Purchase your credit card processing equipment only from your acquiring bank or reputable vendor.  This is not a perfect solution to the problem, but doing this should be better than buying a used unit off of eBay or from Joe’s Guaranteed Card Equipment.  Yes, you may save a few bucks, but is that worth having every one of your customers that uses a credit card being compromised?  Probably not.

• Ask your supplier of terminals or POS workstations about what they do to test these systems to ensure that they operate as expected and are not routing cardholder data to Timbuktu as well as your bank.  Ask them to provide those procedures in writing and review them to ensure they appear adequate.
• Use serialized tamperproof tape on the seams and doors of your terminals and POS workstations.  Require that at every Manager shift change the new manager on duty is required to log their review of the devices, inventory the devices and notate if any have been tampered with.  If a device does appear to have been tampered with, it should be taken out of service until a new, secure device can replace it.
• If using self-checkout systems, make sure to have those systems under both video and employee monitoring.
• Upgrade your card processing devices to the latest devices.  Over the last few years, some of these devices have seen significant changes in their design that improves their tamper resistance.  This is particularly true of fuel pumps and certain types of terminals.
• Review video monitoring if any manager notates that a device may have been tampered with to determine if you can identify possible suspects that may have tampered with the device.
• Patch your devices as soon as possible to minimize their susceptibility to attack or compromise.
• If the vendor of the equipment will perform updates, make sure that you or someone in your organization schedules the updates.  If anyone shows up at a location to “update” your equipment and it was not scheduled by your organization, contact law enforcement.
• If updates will be done by the vendor remotely, make sure that someone from your organization initiates the remote access and they observe the remote update process.  At the end of the update process, the person should terminate the remote session of the vendor.

Even implementing these processes will not remove all of the risk.  Particularly the risk of having modified software introduced into your environment.  However, these processes will show a court that you attempted to conduct due diligence and tried to keep your equipment secure.

PCI Compliance Scam? You Tell Me

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.