I don't store PCI data, I just issue cards as a small bank...

[zimted393]

Or, I sold off my credit card business....why am I subject to compliance? I am a small bank, I take credit card applications, but then forward them on to a 3rd party that manages the whole process. We don't store any PCI data.

Thoughts?

[wconway]

It is tough to tell, but based on your post I'm guessing you are storing old "sensitive cardholder data" as defined under PCI, e.g., the PANs for the accounts you have or are currently issuing. You may also have PIN info. What's interesting is that you - as a bank - don't seem to fit the traditional merchant model where you would be processing, transmitting, or storing tran data... :confused:

[jbhall56]

About three years ago, banks were notified by their regulatory bodies regarding a new standard that was being issued called RQM, QVR or something like that that was to address the credit card security issue. However, all of the banks I've spoken with (probably a 100+) over the last few years typically remember the letter, but have never seen a standard issued regarding PCI data.

In doing research, I have never been able to find anything more than the letter, so it's anyone's guess whatever happened to the people setting the standard.

Banks, Thrifts and Credit Unions issue (granted they use third parties for issuance) debit cards with PINs under the Visa and MasterCard logos. Their systems must maintain the PAN, name, PIN, etc. in order for their ATMs to work, statements to be generated, as well as to authenticate transactions from the cards issued.

As a result, in my humble opinion, it is likely in the best interest of any financial institution issuing/processing debit cards to abide by the PCI DSS regardless of whether or not the PCI SSC is asking for such compliance.

[cmark]

If you are a bank, you are still required to comply with the PCI DSS. As an issuer, you have a need for sensitive authentication data and as such can possess. The only time you would be requird to validate compliance is if you do processing as a VisaNet Processor or a MasterCard Third Party Processor.

With regard to the third party you use for outsourcing processing. They must be registered as a TPP or Agent with MasterCard and Visa, respectively.

If you would like any more info, please feel free to contact me directly.

Thanks

[nambiarenator]

I am conducting a gap assessment on an issuing bank which has outsourced few of its functions (for e.g. card embossing). As part of the gap assessment should I go around looking for the controls at the vendor's end or should I be asking if the vendor is PCI DSS compliant? .i.e. If not, it becomes a gap???

Any help on this front is appreciated.
Thanks in advance!

[ADail]

Chris,

I thought issuers were not in-scope for PCI unless they are in a rent-a-bin model or also acting in some other role in the payment process, such as Acquirer or TPP (which it sound as if this bank may be doing).

[lyalc]

Chris,

I thought issuers were not in-scope for PCI unless they are in a rent-a-bin model or also acting in some other role in the payment process, such as Acquirer or TPP (which it sound as if this bank may be doing).
Recent re-cert training indicated that issues and acquirers are now coming into card scheme focus.
Haven't seen any formal public announcements as yet, however.

lyalc

[ADail]

Recent re-cert training indicated that issues and acquirers are now coming into card scheme focus.
Haven't seen any formal public announcements as yet, however.

lyalc

Acquirers have always been in scope, but not issuers, to the best of my knowledge. The logic being the issuer ultimately foots the bill if he can't collect from anyone, so it's really his risk to manage. Of course that wouldn't apply in a closed model like AmEx.

[jbhall56]

I think where we are getting balled up is how financial institutions end up in-scope for PCI compliance and not whether they are an issuer/acquirer.

Most financial institutions do not physically issue their own credit cards, they are issued by a company like First Data, Bank of America Card Services or other third party. These financial institutions are still technically the issuer since they have their institution's logo on the card, but all customer service, billing and processing is done by the company that physically issued the card. As a result, the financial institution has none of the cardholder data for these credit cards on their systems.

Where financial institutions most often end up in-scope is with debit cards branded by one of the card brands. This is because the financial institution must retain the debit card number in their system(s) so that they can link the debit card to the customer's account. As a result, they have cardholder data stored on their system(s) and those system(s) are in-scope for PCI compliance.

As an aside, we are seeing a burst of PCI assessment and Report On Compliance (ROC) project requests from financial institutions that are driving their own ATM networks. There are a number of switch organizations that are pushing for these institutions to conduct PCI compliance testing of their ATM networks and switch software and obtain a PCI ROC.

[ADail]

From the perspective of managing retail compliance, ATM's are evil.