Technical Discussions


Over the past year, the payments industry has been abuzz with news of Visa’s plan to encourage adoption of EMV technology.  While many in the payments industry have a clear understanding of what EMV is and how it might impact our business, for small merchants the term just adds on to the growing list of acronyms with which they must now be familiar.  PCI DSS, PA DSS, QSA, SAQ, and now EMV.   But what is EMV and what do small merchants need to know about it?

EMV itself is a standard begun by Europay, MasterCard International and Visa International. (Its current members are American Express, MasterCard, Visa, and JCB.)  The three companies joined together to form EMVco, whose purpose is “to manage, maintain and enhance the EMV™ Integrated Circuit Card Specifications for Payment Systems.”  In other words, the company was formed to promote the use of “smart cards.”  A “smart card” is essentially a payment card with an embedded micro-processor, or chip.  Because the chip can hold much more information than a magnetic stripe can, EMV enabled cards support multiple methods of authentication.  This ostensibly makes the process more secure for both the merchant and the consumer.   Since the chip can support dynamic and static authentication as well as online and offline authentication, the theory is that using EMV means that the risk of compromised card data being used fraudulently is significantly lower than with magnetic stripe data.  In other words, even if the data is compromised, it is less likely that it can be used to perpetrate fraudulent transactions.  As a result of its capabilities with respect to fraud prevention, Visa is strongly encouraging the US payments industry to move towards EMV.  So, what does this transition mean for merchants?

1) The requirement to comply with PCI DSS will remain - Visa’s program states that if a merchant can verify that at least 75% of its transactions are EMV, then the requirement to validate compliance with the PCI DSS can be waived.  It should be noted, though, that it is only the requirement to validate compliance that is being waived, not the obligation to comply itself.  Another important caveat to this validation waiver is that only Visa has so far extended this offer.  Merchants will still have to validate compliance as required with the other card brands.

2) EMV  does not replace data security – The use of EMV cards does not inherently provide protections against the unauthorized access or disclosure of the data itself.  Data thieves would still be able to compromise the data.  However, the utility of the data is significantly lessened as a result of the layering of authentication mechanisms employed by EMV cards.

3) Acquirers/ Processors have to transition by 2013 – As of April 1, 2013 acquirers and processors must be able to support EMV transactions.

4) Liability Shift means Acquirers likely to encourage adoption – Visa has announced plans to implement an liability shift for fraudulent purchases.  Currently, if a counterfiet purchase is made, it is largely left to the issuing bank (the bank that issued the card) to absorb.  Under the new rules, which would take effect on October1, 2015 counterfeit purchases that occur at a merchant location that has not adopted the EMV technology may become the liability of the acquiring bank.

As the deadlines come closer, the card brands will release more detail that will help guide merchants on the path to EMV.  Moving to EMV will be a challenge for an industry as fragmented as the US card processing ecosystem.  Although there will be the inevitable growing pains, though, the technology will serve to benefit all of the stakeholders – from merchant to the consumer.

Dr. Heather Mark, PhD; Sr. Vice President, Market Strategy

In August, the PCI SSC released an updated version of its Wireless Guidelines.  The updates were not drastic, rather they were designed to bring the Guidelines into accordance with the PCI DSS v. 2.0 and to provide updates for Bluetooth technology, which was not contemplated in the original document.  This guidance document is important for companies seeking to achieve compliance for a number of reasons. Primarily because there is some disagreement as to whether an organization can be compliant if it uses a wireless network.  The short answer is “Yes, it can.”  However there are some caveats.  Those caveats will be briefly discussed here.

The first thing that one should know about wireless networks is that they are inherently more difficult to secure.  Therefore, while compliance with the PCI DSS is possible with a wireless network, it is not necessarily easy.  For instance, the network must support encrypted communications.  Further, that encryption method cannot be WEP, which was proved insecure several years ago.  In fact, the PCI SSC specifically states that WEP “must not be used” and was prohibited as of June 30, 2010.  Organizations using wireless networks must use WPA (Wifi Protected Access).  The guideline document further details specific protocols for the WPA encryption method, depending on the environment (SOHO, enterprise, etc).

Additionally, there is a tendency on the part of organizations to overlook the physical security of wireless access points.  This is particularly true if a company is using a fairly common access point, such as those that can be purchased at office supply stores.  However, these access points usually have common default passwords and are easily reset.  If an access point is left unattended, it would be a trivial matter for a criminal to hit the reset button on the access point and use those default credentials to access the corporate wireless LAN.

It may be easy, then, to subscribe to the notion that simply not using a wireless network is the easiest way to achieve compliance, and that may be true.  In fact the PCI DSS itself states, “Before wireless technology is implemented, an entity should carefully evaluate the need for the technology against the risk. Consider deploying wireless technology only for non-sensitive data transmission.”  It should be noted, however, that an organization should still be aware of the possibility of the “rogue access point.”  These are defined by the PCI SSC as those devices that do not have proper authorization.  According to the document, “A rogue AP could be added by inserting a WLAN into a back office server, attaching an unknown WLAN router to the network, adding a Bluetooth base, or by various other means.”  For that reason, PCI DSS Requirement 11.1 mandates that organizations scan for the presence of wireless access points on a quarterly basis.  This way, even companies that may not be running a wireless network can detect unauthorized devices that may impact the security of their network.

In short, companies should carefully evaluate the need for a wireless network in their environment.  In making this decision, it is highly suggested that the Wireless Guidelines be used to help determine the right forward for each individual company.

Dr. Heather Mark, PhD.  SVP, Market Strategy

It’s been a busy month for the Payment Card Industry Security Standards Council (PCI SSC).  In August the PCI SSC, the organization charged with managing and disseminating security standards related to cardholder data, released two new guidance documents.  One of the documents provided guidance on selecting or building tokenization solutions while the other was concerned with wireless networking security.  While the wireless guidelines document is an updated version of the existing document, the industry has been awaiting the tokenization guidelines for some time.  In this post, the PCI DSS Tokenization Guidelines will be discussed.  The Wireless Guidelines will be discussed in a subsequent post.

Since its introduction to the payments industry, tokenization has been heralded as one of the most effective ways to meet compliance with the PCI DSS.  This has led to a long debate among security professionals about the proper implementation of tokenization solutions for the purpose of achieving and maintaining compliance.  Without the voice of the PCI SSC, there was some trepidation about just how much reduction of the compliance effort could be achieved with tokenization solutions.

The new guidance document for tokenization offers “Key Considerations for Tokenization Operations.”  Among these considerations is the ability to retrieve cardholder account numbers from the Primary Account Number (PAN). If the organization still has the ability to recreate the PAN using the token then no benefit with respect to reduction of PCI scope will be achieved.

Another important clarification introduced in the guidance documents is that there must be a way to distinguish between the token and an actual card number.  This is particularly important as an increasing number of tokenization providers offer tokens that are virtually indistinguishable from card numbers.  They are 16 digits and will bass the Luhn test, which is a signifier of valid card number.  The PCI SSC offers several reasons for this guidance.  According to the document, “Without the ability to distinguish between a PAN and a token, the merchant or service provider may not realize that the tokenization system isn’t functioning as intended.  Additionally, PANs could be mistakenly identified as tokens, which can lead to mis-scoping of the CDE [cardholder data environment] and the possibility that the PANs are left unprotected and open to compromise.”

The document further outlines the differences between an “on-premises” solution and an outsourced solution.  An on-premises solution is one in which the merchant maintains control over the entire tokenization solution, including the system that creates the tokens.  The responsibility in this case rests solely on the merchant to maintain the security and compliance of the system, as the tokenization system, and the systems connected to it, are always in scope for PCI DSS.  An outsourced solution, on the other hand, significantly reduces the merchant’s scope.  The document then goes on to detail the responsibilities of the various parties relative to the tokenization system.

The tokenization document should prove extremely helpful for merchants that are in process of evaluating a tokenization solution.  It will allow merchants to develop their own metrics for determining the correct solution for their environment and for their abilities and resources.

Dr. Heather Mark, PhD; SVP of Market Strategy

A recent article on MSNBC detailed a “security issue” at two major banks.  The vulnerability in question related specifically to the use of the banks’ phone system.  Generally, when a caller uses the automated account system via telephone, the system verifies the number from which the person is calling.  If the number matches the number on the account, the verification process is streamlined.  That means that instead of entering an entire account number, the caller can simply enter the last four digits of the number.  They would then be able to access the limited information available through the automated phone system.  Typically, that would include information such as credit limit, account balance, date and amount of the last payment and similar information.  The caller would not be able to access other accounts or to retrieve the account number.  The article expressed concern that someone could easily obtain a consumers phone number and the last four digits of the card number.  By “spoofing” the consumer’s number and entering the last four digits, an ill-intentioned individual could “hack” the system.

The author expresses outrage that such a vulnerability could exist.  Other banks, he insists, require that users enter a complete account number.  He makes no argument about the increased security that may offer to the transaction.  The article goes on to detail exactly how one could hack the system, then call the consumer posing as the bank to use that ill-gotten information to coax more information out of the user that could be used to facilitate identity theft, or even to blackmail users based on their transaction history.

Data security and privacy should be top priorities for any companies that deal with consumer information.  However, those businesses must also maintain operations.  Convenience and security will always be at odds and companies are tasked with striking just the right balance – making their services easy to access while still protecting consumers and their data.  Most companies seek to achieve this balance with the judicious use of risk analyses.  During the risk analysis, the company identifies the potential vulnerability and analyzes what the impact would be if that vulnerability were exploited.  High impact events, whether that impact is in terms of frequency or in monetary damage, are addressed and steps taken to mitigate the risk.  While this author has no direct knowledge of the businesses practices of the banks in questions, it is unlikely that the bank would have adopted such a practice if the impact to its customers or to the bank was intolerable.

In security, one must balance the theoretical with the practical.  In theory, data is never safe.  There is no way to categorically prevent data theft.  The risk can be transferred (as with insurance policies or third-party service providers) or it can be mitigated by implementing increasingly strong protections, but it cannot be entirely removed.  Security professionals must be able to recognize when a theoretical threat becomes a real one and how to most efficiently allocate resources to address the nature of threat.

Dr. Heather Mark, PhD; SVP of Market Strategy

On June 29th the Federal Reserve Board issued its final debit card regulations.  Thank goodness it’s over! Two months after they were due under the Dodd-Frank Act and about three weeks before they were supposed to go into effect, the Federal Reserve announced the final rules for regulating the debit card industry. Mercifully, the Fed staff will now get to take a well-deserved vacation having spent late nights and weekends presumably pouring over the 11,000 or so comments they got and figuring out what to do. Now everyone else is left to figure out the implications.

The Federal Reserve staff had recommended a cap on the amount of interchange or compensation that an issuer of a debt card could receive from a payment network at 12 cents or a 7 cent safe harbor (and effective cap for most transaction volume).  However, the Board agreed to a cap of 21 cents and .05% (5 basis points) on a debit card transaction.  This works out to approximately 23 cents on a $38 debit card transaction.  The Board also adopted an interim measure of 1 cent per transaction for fraud prevention.  However, this extra allowable cost cannot be paid to issuers until the Fed determines, at some later date, what fraud prevention measures an issuer must implement in order to be entitled to the 1 cent kicker.

So, as a merchant will you win or lose?  This regulation which was to be effective July 21st has been delayed until October 1, 2011, so until then you will see no change in debit card interchange.  Now for reality!  The regulation has caped what portion of the interchange on a debit card transaction an issuer can receive from a payment network (i.e. Visa or MasterCard).  The regulations also specifically exempt three-party networks such an American Express.  Acquiring banks, those providing you as a merchant with a merchant account, typically mark up the interchange paid to a payment network and charge the merchant a discount rate and transaction fee.  There is no regulation by the Fed of the discount rate that your acquiring bank can charge a merchant on a debit card transaction.

The initial result will be that after October 1st your acquiring bank will retain a larger portion of the interchange paid to a payment network on a debit card transaction with no requirement to lower the discount rate you pay to the acquiring bank as a merchant.  What would drive the acquiring bank to share this additional revenue with its merchants?  There are three possibilities.  One, the merchant has negotiated a cost plus discount rate with it’s acquirer and the payment networks lower interchange on debt card transactions.  Two, the merchant, due to its debit card processing volume could threaten to leave it’s acquirer and move its account to an acquirer offering a lower discount rate unless the acquirer lowers it’s discount rate to the merchant.  Three, over time, due to competition between acquiring banks for merchant volume, acquirers decide to compete on price and thus lower their discount rate.  Unless, one of these apply to you as a merchant there will be no change in the amount you pay on a debit card transaction.

As one commentator has written, “Congress and the political process is a big loser in all of this. The Board of Governors for all intents and purposes unanimously said that they were forced to implement a flawed law. One refused to vote for the proposal altogether, but four Governors qualified their votes by saying, more or less, that the staff proposal was the least bad thing they could do given the language of the Durbin Amendment. The Governors were variously worried about the impact on small banks and credit unions, on consumers, on innovation and on the unintended consequences of imposing price regulation.”

Tony Allen

Next Page »