4

Are the banks authorized to keep plain text hard copies of full credit card data (Primary account number, CVV, Expiry code, Cardholder name)

2

(Some assumptions here for the lack of references)

According to this Visa page, issuing and acquiring banks are subject to the PCI DSS:

All entities that store, process, or/and transmit cardholder data, such as merchants, service providers (e.g. payment gateways, IPSP, processors), issuers and acquirers, must comply with the PCI DSS

As such, they must keep copies of the PAN encrypted. They may store the expiration date and cardholder name unencrypted.

PCI DSS 3.1 Applicability Matrix

The DSS prohibits storage (encrypted or unencrypted) of the CVV; however, by definition the issuing bank must know the CVV in order to validate it. That means that either they store it, or they recalculate it (as per this excellent link that @WhiteWinterWolf provided in the comments). It would not surprise me if there was some exception to allow the issuing bank to store the CVV, probably encrypted (it's arguably more secure to store many derived values than it is to expose the key to constant use) but that's pure speculation.

Update: @dave_thompson_085 pointed out in the comments that the PCI DSS explicitly permits issuers to store the CVV as per DSS section 3.2:

It is permissible for issuers and companies that support issuing services to store sensitive authentication data if:

  • There is a business justification and
  • The data is stored securely.

On the other hand, I think it's fair to assume that the acquiring bank is not permitted to store the CVV of cards it processes. There is no business driver for it and it would be out of line with the DSS's otherwise draconian approach to CVV handling.

  • "by definition the issuing bank must know the CVV in order to validate it. So there must be some exception to allow the issuing bank to store the CVV": "to know" is not the same as "to store", I thought the CVV was calculated using a specific bank's private key and was never stored anywhere (when this system appear I remember there were quite intense discussions, and at the end disappointment that the banks finally chose to use calculated CVVs instead of random ones). – WhiteWinterWolf Jan 11 '16 at 14:04
  • @WhiteWinterWolf excellent point (although, arguably, security is improved by the issuer storing the CVVs and not exposing the CVKs to everyday processing). I'm going to update above to reference that possibility, but if you can find some documentation that states that's the way you should post your own answer and get the points :) – gowenfawr Jan 11 '16 at 14:12
  • 1
    The "Applicability" section up front says simply "don't store [fn: after authorization]" "per requirement 3.2" but the actual requirement 3.2 on page 37 of DSS 3.1 (35 of 3.0, 29 of 2.0) after saying "do not store" adds "It is permissible for issuers and companies that support issuing services to store sensitive authentication data if: (bullet) There is a business justification and (bullet) The data is stored securely." (Except 2.0 didn't have the colon and bullets.) – dave_thompson_085 Jan 11 '16 at 23:09
  • Given that CVV is three or four digits long, since the issue bank can do offline attack to their own database, if it knows how to validate it, it would not take much time to brute force the CVV. Thus it doesn't really matter whether they store encrypted random value or as a generated value. – Lie Ryan Jan 11 '16 at 23:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.