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.
PCI Guru 
Apologies for the above post- it should be Australia instead of US.
We are based in Australia and more classed as issuer.
Dear PCI Guru,
great post – thank you!
I would like to find out what the PCI scope would be for an issuing bank (debit cards only), who outsources all the processing as well as the ATM network to a service provider and does not store any PAN/credit card holder data in electronic form at all?
The PAN gets linked to the bank’s account number upon issuing of the card via the service provider’s front end system which is connected via a dedicated link to the bank, includes SSL, proper RBAC, auditing etc.
All subsequent statements sent to the bank from the service provider do not display the PAN number.
Only authorized bank’s staff with access to the front end could view the PAN number for queries (only ever see one at a time).
With SAQ A and SAQ VT I’m confused now which sections do apply in this case.. I was initially under the impression only requ 9 and 12 would apply.. but now I’m not so sure any more.. (also need to fill out the full ROC but refer to the service provider for a lot of sections?)
highly appreciate your input or any comments..
many thanks!!
kind regards
It depends on what your card brand tells you. We have been told that financial institutions cannot submit a Self-Assessment Questionnaire (SAQ), they can only submit Reports On Compliance (ROC). HOwever, it is up to your card brand to tell you what they will allow you to file.
Based on your description, it sounds like the PAN is never stored on your systems, however, do you process or transmit cardholder data? That is, do you allow your customers to perform transactions through your bank systems within your branches using their debit card? I know of some institutions that can process transactions with a customer presenting their debit card to a teller. If that is the case, then your systems and network that are involved in those transactions would be in-scope for PCI assessment.
However, if your systems and network do not process, store or transmit cardholder data, then your systems and network would be out of scope for PCI compliance.
Hi PCI Guru
A great post that clarifies a lot for us out there. I would appreciate your thoughts on whether prior to the release of V2.0 that there was a requirement for an annual review of compliance to be performed by a QSA, and also whether prior to the release the fines were in place as they are today?
For the record we are a card issuer (visa), as such according to the posts below, I assume we would be classed as level 1, and would require annual review by a QSA and quarterly scan to be performed. We would need also to be fully compliant with V2.0 by September 30, 2010, or if not, to have a remediation plan in place for compliance.
We would appreciate your clarification, as I assume there are hundreds of FI’s in exactly the same boat as us!
Just to be clear. Just because you are an FI, does not mean that you are truly an issuer or an acquirer. Most FIs that issue credit cards do not physically issue or process them. These functions are almost always outsourced by FIs to third parties. In the case of debit cards, the FI usually does not issue these cards either, but because debit cards require a link to an actual bank account, the FI usually has the debit card number in their core system. As a result, most FIs are really no different than merchants. However, if your FI does not issue debit cards to its customers, then you should be able to only have to deal with sections 9 and 12 and mark the rest of the ROC as ‘Not Applicable’.
Some FIs are getting caught in the PCI compliance net due to the fact that they operate their own ATM network. Most FIs outsource their ATM network, but those that do not are being required by their ATM interchange network provider to file a ROC. Again, these FIs are treated like Level 1 merchants.
It is my understanding from the card brands that all FIs are to be treated similar to Level 1 merchants when complying with the PCI DSS. As a result, you need to conduct an annual PCI assessment and create a ROC as a result of that assessment. As part of your PCI compliance you are required to conduct at least quarterly external and internal vulnerability testing as well as at least an annual penetration test. All external vulnerability testing must be conducted by a certified ASV. You can go to the PCI SSC Web site to obtain a list of certified ASVs. In the US, a lot of the PCI compliance topics are required under the FFIEC and GLBA regulations, so these PCI requirements are just confirming that FIs are following best practices. Since you are outside the US, it is probably just good business to follow the PCI DSS whether it is required by your country’s regulations or not.
However, if your organization truly does issue physical credit/debit cards, then you really are an issuer. From my QSA training over the years, it was my understanding that issuers were also no different from Level 1 merchants. However, they will need to fill in those sections of the PCI DSS that are related to Service Providers in addition to the rest of the ROC since issuers are considered Service Providers.
Another reason is that almost all state breach laws exempt everyone who is in compliance with their federal regulator’s requirements. If you passed your last audit, you’re in compliance. Federal breach reporting laws effectively do not exist. Other than the FTC enforcing your Privacy policies, there’s no meat in federal enforcement. Many FI’s think PCI-DSS is the same. They answer to a higher authority.
It’s not so much that “no one asked them to” as much as it is “no one is forcing them to.” Throughout my career I’ve had many auditors tell me that any regulation they are not audited against gets put in the low priority bin. I guess it’s a form of risk management. A regulator can issue a cease-and-desist order and shut you down. The Council can’t do that. If they publicized penalties like the Business Software Alliance does they would have some credibility. But a half-decade after PCI came to life many Level 1’s and 2’s are still not complying and guess what? They still accept credit cards.
Quite frankly, one of the problems we’ve seen are QSA’s telling us we must be in compliance but never being able to point to anything other than “because”. Earlier this year I actually had one major QSA tell us that we did not have to comply with PCI-DSS because we issued debit cards and “PCI only deals with credit cards.” Try arguing your point with management after they just heard a high-dollar major “Qualified” Security Assessor tell them they are exempt. So far all of the QSA’s I’ve interviewed have almost zero credibility. Too many young kids barely out of college with zero real-world business experience. But I guess they work cheap.
Good post. I’m aware of several Financial Institutions that believe that PCI is not applicable. I bet there are individuals within these organizations who believe otherwise and are looking for ammunition to prove their point. Posts like this help (as does the corresponding update in PCI DSS v2.0: “PCI DSS applies to all entities involved in payment card processing – including merchants, processors, acquirers, issuers, and service providers, as well as all other entities that store, process or transmit cardholder data”).
I’ve heard from a leading QSA that Acquirers and Issuers are “expected to be compliant” (per their agreements with the Card Brands) but are not required to report compliance via a Report on Compliance or SAQ. This conflicts with previous comments associated with your post. Also, it is puzzling as these organizations may store, process and transmit large numbers of PANs and sensitive authentication data. Shouldn’t direction on this be clear by now? Come on Brands, SSC…it’s hard enough to achieve compliance! Why make organizations fish around for rulings on items like this! This falls into the “Ask 10 QSAs, get 10 different answers” bucket.
The only reason acquirers and issuers are not required to file a ROC is that the card brands are not asking them for one. However, if an acquirer or issuer goes through the effort to produce a ROC, the card brands do accept the ROC.
Most financial institutions believe that the reason they are exempt is because – wait for it – no one is asking them to be compliant either.
From the card brands’ perspective, financial institutions, acquirers and issuers are the least of their problems. However, as merchants and service providers have gotten their act together, the card brands have started to focus on these other parties. As a result, financial institutions, acquirers and issuers are now going to be scrutinized just like everyone else.
From a QSA training perspective, financial institutions, acquirers and issuers were always considered in scope. We were trained to understand the differences for compliance with acquirers and issuers. However, like the card brands, we basically were told to focus on merchants and service providers as they were the biggest problem to compliance to be addressed.
Thanks for the superb article but I’m wondering if it’s missing a key information point.
The part that I think is missing is how an issuer is ranked for PCI DSS. What metric is used to determine the level of compliance reporting that’s required? I’m writing this from the viewpoint of a small thrift that processes our own debit cards but uses the ATM network of a major FI. We are sponsored by the FI for our card brand as a member and we do have our own BIN.
Is it the total number of debit cards we issue that are still valid (i.e. exclude “hot” cards and expired cards)? Or is it the number of annual debit transactions we process for our customers, since most do not use the card often?
Are issuers considered a Merchant or a Service Provider? If an issuer does not accept payment cards for any of our transactions (such as filing fees) and an issuer does not perform processing for anybody but ourselves, then we are neither a merchant or a service provider. Right?
What if the contract doesn’t say? The one I saw a few months ago doesn’t mention compliance reporting at all. In fact, the major FI we contract with to use their ATM network isn’t PCI compliant, so there’s no way we can be PCI compliant. When I say “major” I mean it’s like the song: “Everyone knows their name”. Catch-22.
An issuer is an issuer. They are their own classification as they are not merchants or service providers. As far as I am aware, issuers are considered Level 1 by the card brands regardless of whether they issue one card or a billion. As such, issuers are always required to annually file a Report On Compliance (ROC) with the card brands they issue cards under.
You are a thrift that does not run your own ATM network but does issue debit cards to customers. I am assuming that your institution does not actually issue the debit cards but your institution obviously has to process the transactions. As a result, you are only responsible for the PCI DSS compliance for the debit card PANs you process, store and transmit with your systems. It depends on your acquiring bank, but experience is that most FIs are being required to conduct a full PCI assessment (i.e., ROC), not a self-assessment.
PCI compliance is not dependent on the PCI compliance of any third parties you may have as service providers. Your compliance with the PCI DSS depends only on your organization meeting the requirements of the PCI DSS.
The agreement with the FI likely references the card brand’s operating policies, standards and procedures. You will need to go out to the card brand’s Web site and download those to see that you need to be in compliance with the PCI standards.
We issue them, if by “issue” you mean we decide what number they are going to have (because we own the BIN), what the limits are, and the security code and expiration date. We do contract with the FI and we send them a file of what we want and they order the cards for us.
“As far as I am aware, issuers are considered Level 1 by the card brands regardless of whether they issue one card or a billion. As such, issuers are always required to annually file a Report On Compliance (ROC) with the card brands they issue cards under.”
Where would I find this? We issue MasterCard debit cards. I’ve never found anything and it’s difficult to get people to buy in to the need when there is nothing in black-and-white (that we can find). Especially since we’ve been doing this since the late 1990’s and have NEVER been asked about PCI compliance. We process around three million transactions a year.
“It depends on your acquiring bank, but experience is that most FIs are being required to conduct a full PCI assessment (i.e., ROC), not a self-assessment.”
We renewed the contract early this year and it still doesn’t say anything at all about reporting compliance. The only change was they required us to offer SecureCode to our customers.
“You will need to go out to the card brand’s Web site and download those to see that you need to be in compliance with the PCI standards.”
If anyone can lend a hand as to where to find these on MasterCard’s site, I would definitely appreciate it.
Thanks for the note on Visa, lyalc. We’re in the US but it’s still helpful to know what other card brands are requiring. Do you have any information on US issuer and acquirer compliance dates?
Issuers physically issue the cards. You have outsourced that so you are technically not the physical issuer even though you would ultimately be recognized as the ‘issuing bank’. You are the bank under which the cards are processed similar to an acquiring bank for merchants.
How many transaction you process does not matter as you are not a merchant, you are a financial institution. This is no different than service providers who, for the most part, are considered Level 1 unless they can meet some very narrowly proscribed criteria. All of the financial institutions we have dealt with are being asked for a ROC, not an SAQ. If there are criteria for financial institutions similar to merchants, that has not been shared by the card brands with the QSAs. So I can only go on what information I have been provided by the financial institutions I have interacted.
I have checked with some colleagues and they are telling me that you should have a hardcopy of the MasterCard Operations Guide (they believe that is what it is called). If not, MasterCard has a Web site for banks but you need to log onto it in order to gain access. It is there where you will find the Operations Guide in PDF form. Your MasterCard account representative should be able to get you access if your organization has never logged onto the site. The Operations Guide would be referenced in your contract with MasterCard and you are expected to abide by all of the items in that guide.
Visa mandates in Asia-Pacific have established deadlines for Issuer and Acquirer compliance.
By 30 September 2011, these entities must have a compliance plan and target dates established for PCI DSS compliance.
lyalc
Hi Iyalc
““You will need to go out to the card brand’s Web site and download those to see that you need to be in compliance with the PCI standards.”
Can you please point me to a direction where I would find the relevant downloads in APAC site. We are in the US and are more classed as Issuer. Any help would be greatly appreciated.
Start here http://www.visa-asia.com/ap/au/merchants/riskmgmt/ais.shtml
About the middle of the page is the links relevant to Service Providers which are the items relevant to your situation.