PCI DSS for Issuers and Financial Institutions

Thursday, December 02, 2010

PCI Guru

Fc152e73692bc3c934d248f639d9e963

The applicability of the PCI DSS to issuers and financial institutions in general has been a topic of discussion with QSAs as well as the entities involved.  Over the years, I have fielded a lot of questions regarding the applicability of the PCI DSS to such organizations.

A lot of issuers feel that they are not within the purview of the PCI DSS and point to the fact that the PCI DSS is for merchants and service providers.  Financial institutions for the most part outsource their credit card processing so they also feel that they do not fall under the requirements of the PCI DSS. 

However, with the release of PCI DSS v2.0, the PCI SSC has burst these organizations’ bubbles and let them know that the PCI DSS is for any organization that processes stores or transmits cardholder data.

Just so we are clear on terminology, an issuer is defined by the PCI SSC as an, “Entity that issues payment cards or performs, facilitates, or supports issuing services including but not limited to issuing banks and issuing processors.  Also referred to as ‘issuing bank’ or ‘issuing financial institution’.” 

The PCI SSC does not define a financial institution, however for the sake of this post, a financial institution is defined as; state or federally chartered banks, thrifts (aka savings & loans) or credit unions, insurance companies, brokers, securities dealers or investment funds.  These are terms familiar to US QSAs, but they would also apply to any similar financial institutions around the world.

Issuers are the ‘Fort Knox’ for carders.  This is because an issuer stores all of the cardholder data that is contained on the magnetic stripe and chips of all credit and debit cards created for their customer financial institutions. 

For a variety of business and legal reasons, issuers need to retain this cardholder data.  Obviously, if an issuer were ever to be breached, it would cause serious problems for all of the financial institutions that the issuer serviced.

Issuers always pointed to requirement 3.2 in the PCI DSS that does not allow the storage of sensitive cardholder data as to why the PCI DSS did not apply to them.  With the release of v2.0, the PCI DSS, the PCI SSC has modified the standard to clarify how the PCI DSS requirements apply to issuers. 

These clarifications had been in place for years and discussed at some QSA training sessions, but were not always widely understood by the QSA community, let alone a lot of the issuing banks.  As a result of the clarifications in v2.0, QSAs will be able to apply the PCI DSS to issuers without any of the previous questions regarding applicability.

Financial institutions are a more problematic group.  Since most, if not all, of these types of organizations are regulated under state and/or federal laws, they feel that they have enough to deal with let alone the PCI DSS. 

Until recently, the card brands have agreed with the financial institutions’ assessment and have left them alone.  The rationale has been that a lot of those regulations require these financial institutions to meet a majority of the PCI DSS requirements. 

However, in the view of the PCI SSC and the card brands, these regulatory requirements are not the complete PCI DSS requirements. 

Over the last two years, we have started to receive more and more requests from somewhat shocked financial institutions that are being asked by their service providers to provide them with a Report On Compliance (ROC) regarding the ATM networks that these financial institutions operate.

Where all financial institutions are beginning to feel the PCI compliance heat is over their debit cards or check cards.  Debit cards are similar to credit cards in that they are branded by one of the card brands. 

However, unlike credit cards, debit cards are tied directly to a checking or savings account at a financial institution.  If you do not have enough money in the linked account, then a purchase with a debit card will not be approved. 

Debit cards also can function as a customer’s ATM card and requires a four digit PIN to obtain cash at an ATM.  Some merchants will also process debit card transactions using a PIN and not require a customer’s signature on a receipt similar to a Chip and PIN card in Europe.

Unlike credit cards where the financial institutions have totally outsourced their processes, debit cards create a PCI compliance issue because they require that a financial institution have the primary account number (PAN) of the debit card stored on their system in order to link the debit card to the customer’s checking or savings account. 

As a result, financial institutions providing debit cards to their customers have cardholder data stored on their computer systems.  And that act does come under the purview of the PCI DSS.

Financial institutions argue like issuers that the PCI DSS is a merchant and service provider program.  You will also hear them argue that the fact that they are state or federally regulated also puts them outside complying with the PCI DSS. 

All of this is a smoke screen.  If any of these financial institutions went back and reviewed their contracts with the card brand, they would see that they too are required to comply with all of the relevant PCI standards.

The bottom line is that even issuers and financial institutions are in-scope for complying with the PCI standards.  If they think otherwise, they should have their legal counsel review their card brand contract and amendments.  They will find out otherwise.

Cross-posted from PCI Guru

Possibly Related Articles:
18370
PCI DSS
PCI DSS Compliance Regulation Data Loss Prevention Financial
Post Rating I Like this!
The views expressed in this post are the opinions of the Infosec Island member that posted this content. Infosec Island is not responsible for the content or messaging of this post.

Unauthorized reproduction of this article (in part or in whole) is prohibited without the express written permission of Infosec Island and the Infosec Island member that posted this content--this includes using our RSS feed for any purpose other than personal use.