PCI Blog - Compliance Demystified

Do NOT store sensitive data after authorization

One person asked, “I have learned we are not storing sensitive authentication data subsequent to authorization and CLEARING. Sometime the clearing could take longer, up to 20 hours, letting the sensitive data stored during this time frame.“

Other people have asked, “When can I store sensitive authentication data? What if my systems are down?”

The number 1 thing a company can do, to reduce their risk due to credit card data theft, is to eliminate the storage of sensitive authentication data: Track Data, PIN block data, and CVV2/CVC2/CID information.

Many companies may store this information unknowingly in many different locations including: within the POS system, data warehousing systems, printed reports, or a variety of other locations that data passes through within the corporate environment.

Excuses For Storing Data

Companies will give reasons (or excuses) for why they need to store sensitive authentication data post-authorization. One of the common e-commerce reasons is for reoccurring transactions. Merchants such as utility companies, gym memberships, and other online merchants wish to lower their interchange rate by storing CVV2/CVC2 for transactions that reoccur each month. The reason this is not permitted is because it directly violates the Operating Regulations for every card brand/association, which can levy fees against this action. The proper approach is for the merchant to consult their acquirer and obtain a reoccurring transaction flag so they will obtain the same low interchange rate for repetitive transactions.

Other excuses are that the sensitive authentication information is necessary for clearing or settlement. This is entirely false. Authorization is the process of obtaining verification that the cardholder has the available credit to perform a transaction. The merchant submits the cardholder authentication information and receives an authorization code. The process of CLEARING involves sending the authorization code along with the PAN (card number) to the issuer (via the acquirer and transaction network.) This is the only information necessary to complete a transaction. None of the authentication information is necessary after authorization.

Exceptions to the Rule

There are minor exceptions to the rule of not storing sensitive authentication data post authorization. The exceptions are a short list includes store-and-forward transactions. These are sometimes called pre-authorization storage or stand-in transactions. Here the merchant is not disconnected from the acquirer for a period of time (not to exceed 5-9 days depending on the Operating Regulations) and will ’stand-in’ for the acquirer when accepting a transaction.

The merchant will provide the services and retain the authentication information, while continously trying to re-submit the transaction to the acquirer. In these situations, the merchant takes the entire risk for the transaction. When the merchant finally is reconnected and submits the transaction they hope to get paid, as the transaction could be fradulent.

Problem with Store-and-Forward

These types of transactions are part of the normal operations of some merchants. That being said, you should never expect to see sensitive authentication information retained at a merchant. This is a temporary storage of data and should be eliminated once the systems come back online (usually no longer than minutes later.)

The rule is that even though this data is retained only temporarily it must be encrypted when stored. This includes any Track Data, CVV2/CVC2/CID, and even the already encrypted PIN block.

The problem occurs when, for one reason or another, this data is retained for long periods of time. Some POS terminals will retain this information long beyond the expected retention period in debug files, log files, or other dark corners of the network.

Merchants should audit the storage of such information is verify there are processes in place to properly eliminate it.