I have been getting a lot of inquiries lately about whether or not financial institutions are required to comply with the PCI standards. It fascinates me how certain groups seem to think that the rules apply to everyone else but their own. Page five of the PCI DSS states:
“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 do not see any exclusion for financial institutions in that definition and the use of the term ‘all’ seems pretty inclusive to me.
A few years back we started to get panicked phone calls from financial institutions that were being pressured by the various ATM networks to prove that the financial institution’s ATM network was PCI compliant. While most financial institutions in the United States outsource the management and networking for their ATMs to a third party, a small number of financial institutions still switch their own ATM networks. And it was those financial institutions that switched their own ATMs that were the target of the PCI compliance initiatives of the ATM networks. Some of those financial institutions did PCI Report On Compliance (ROC) for their ATM networks. Some financial institutions outsourced their ATM networks.
Most financial institutions in the United States and Europe outsource their credit card processing and issuance to third parties or wholly owned subsidiaries. As a result, the financial institution itself is typically not involved in the PCI compliance regarding the credit cards issued under their name.
Unfortunately, the same cannot be said about debit cards. While the issuance of debit cards is typically done by a third party, in order for the debit card to work, the financial institution must store the debit card primary account number (PAN) in their banking system so that the debit card can be linked to the customer’s account. As a result, the financial institution is storing cardholder data in their computer system(s) which means they must be PCI compliant. And that cardholder data must securely traverse the financial institution’s network.
Another area that catches financial institutions is statement preparation. While a lot of financial institutions outsource this as well, some have purchased software that accomplishes the combining of statement information from a variety of sources. Unfortunately, the firms that process their credit and debit card transactions put the full PAN on their statements. As a result, the statement prep software creates PDFs and other documents with the full PAN without the financial institution necessarily being aware of that fact.
What adds insult to injury to this situation is that most financial institutions purchase their software applications from third party development firms. As a result, the financial institutions are at the mercy of these third parties to ensure that cardholder data is processed, stored and transmitted per the PCI standards. To make matters even worse, with all of the regulatory changes going on in the financial institution industry over the past five years, these software firms have been focused on those regulatory changes and not PCI compliance.
The only piece of good news in all of this for financial institutions is that the card brands have not been pushing the issue of PCI compliance. The unofficial reason that financial institutions have not been pushed on PCI compliance to this point is that, in the scheme of things, they have not been where the breaches have occurred.
With merchants and service providers finally getting their acts together on PCI compliance, the focus is going to shift to the other entities named in that earlier definition. How soon financial institutions will start to be asked to document their PCI compliance is anyone’s guess. But I have to bet it will start occurring over the next two to three years. We are already hearing rumblings from some fairly large financial institutions that want to get PCI gap analyses done so that they can get started on remediation and stay ahead of the curve.
So, if you are one of those financial institutions with their head in the sand, you have been warned. It is not a question of ‘IF’ you will need to be PCI compliant; it is a question of ‘WHEN’. And knowing how quickly some of you move, it might behoove you to get started on your PCI compliance efforts now.
There is an issue in the UK with banks sending full PANs of all of the chargebacks to merchants by post. The sooner this is resolved the better.
Until recently, a lot of processors did the same thing in the US. Now most of the chargeback and dispute processing is done through secured Web applications keeping the unmasked PAN with the processor and not on paper.
PAN in the post is still universal practice for chargebacks, in my experience. The web front ends only end up handling the merchant’s response.
And on merchant statements, cardholder statements, meaning mailing houses are in scope.
In this country, a national, inter-bank bill paying system uses PAN as the reference number if you pay you card account from another bank. Consequence – PAN in the statement on both ends of that process.
Lending, including mortgages, collect card statements as part of credit history checks, then scan and save the images electronically.
Insurance claims processing can pay out a claim to a credit card.
All, or a subset of the above processes can be in the same FI. Complexity rules!
We are seeing more and more credit/debit card statements that truncate the PAN. It’s still only a few, but it seems to be a practice that is catching on, albeit slowly.
Totally agree with all of your potential places where the PAN can end up. This is why companies continue to find places where they have the PAN stored even after going through the PCI assessment process for years. It’s not that they were trying to hide something, it’s that cardholder data is so pervasive in documents we’re provided for various purposes that CHD has ended up all over the place.
The same can be said of social security numbers and drivers license numbers.
Outside the US, many banks operate their own merchant and ATM networks.
Working with Banks under the Visa member letter of 2009, these entities are now seeing their PCI compliance obligations turn into long, expensive projects. Merchants are feeling minutely happier, since their bankers were saying ‘get complaint or else” but now the shoe is on the other foot.
One complexity frequently observed here is the differentiation between Acquiring and Issuing activity – in this region the two activities are frequently co-mingled in the same systems, so there is only a very modest scope difference.
Cheers
Yes, it can get very messy overseas separating the processing of transactions from the issuing of cards. Unlike the US, in a lot of countries, the central bank or main banks of the country are exclusively charged with these tasks. As a result, there is little if any separation between transaction processing systems and the systems that issue cards. Not only that, these systems may also be tightly integrated with other banking applications and functions making limiting the scope of the PCI assessment virtually impossible.
Good points! I work with quite a few community banks and credit unions, and this is an area where many institutions just don’t know their PCI obligations, because it has not been well communicated to them. Many times their EFT contracts are years old, and so they only incorporate PCI through the Visa/MC network rules, which of course the institutions don’t review regularly.
One minor point, though. You indicate that most small institutions rely on third parties (e.g. FiServ or Fifth Third) for ATM switching, which is true. But, almost universally, these institutions still own their own ATM devices, and these ATMs still store/process/transmit cardholder data. In fact, even though the PIN may be encrypted, often times the PAN and other SAD is stored unencrypted on the hard disk of the ATM. And, of course, these devices run old, unpatched versions of Windows, do not have AntiVirus, have no logging, and may have default passwords still. It really is quite surprising that there have not been more breaches from this environment.
But with so much cardholder data in the banks’ legacy core system and other areas, the ATMs seem to be pretty far down on the priority list.
No way will any of these community banks or credit unions obtain a successful ROC when the time comes.
Good point about ATMs.
Although most of the FIs I deal with, the “care and feeding” of the ATMs also falls under the third party’s responsibility, not the FIs. I still do occasionally run into the odd FI that owns the ATM and is responsible for maintenance and updates.
Although EFT contracts may be old, you need to see the addendums issued over the years. Most FIs ignored these and filed them away. Typically around 2005 to 2007 is where you find the addendum to the contract mandating PCI compliance. So there is a contractual obligation there that the FIs picked up unbeknownst to them. The other place they picked up their legal obligation for PCI compliance is through their Acquiring Bank Operating Procedures from whatever card brand they are affiliated. Around the same timeframes they should ahve received and update to those indicating their PCI compliance obligations.
Oftentimes the smaller institutions I work with don’t understand the service contracts that they have. They will have an ATM EFT contract with someone like FiServ, to switch the ATM transactions. And they may have a contract with Diebold or NCR or a smaller regional firm to maintain the ATM hardware. But, the Diebolds & NCRs of the world generally are simply providing maintenance on behalf of the FI. The FI still has control over the ATM devices, and the ATM would be scoped into a CDE in any sort of ROC engagement.
I definitely agree with your observation about small FIs. But that is true for any small business. All they want is systems that work and sign whatever contracts necessary to make that happen. How it all comes together is the problems for the the outsourcers involved.
On your point about ATMs being driven by one third party and maintained by another and actually owned by the FI, we are actually seeing less and less of this. Most of the outsourcers such as Fiserv, Fidelity and Jack Henry take on the whole operation of the ATM, so the FI really has no skin in the game other than the physical ownership of the ATM itself. Everything else (i.e., maintenance, updates, vault cash, etc.) is done by the third party or their suppliers.