Individual Card Brand Operating Regulations - SAD retention pre authorisation

[Silly Simon]

Hello to all here at the SPSP,

I wonder if anyone can assist with the subject of SAD (Sensitive Authentication Data) retention timescales pre-authorisation?

As far as I have been able to work out, pre-authorisation SAD retention is allowed as far as the PCI DSS is concerned, although it must be protected.

Fair enough. But just how long can an entity store this SAD pre-authorisation? I'm led to believe that each card brand, Visa, Mastercard, JCB, Discovery and Amex have different timescales and these can be found in the Operating Regulations for each brand. I've done a quick scout of the Visa US Op Regs and didn't find the permitted timescale.

Has anyone found these timescales for each brand and if so, would you enlighten me (and the rest of us who are unaware).

Many thanks in advance for your assistance,

Simon :)

[jonassono]

I have also tried to find a specific retention period that is allowable for storage of cardholder data for payment pre-authorization, i.e. Cardholder Name, PAN, and Expiration Date.

From everything I have gleaned the answer appears to be "the retention time is limited to that which is required for business, legal and/or regulatory purposes" - PCI-DSS Requirement 3.1(a)

As an example, if the cardholder data is needed for 1 year for monthly payment pre-authorizations, that is allowed. In other words, if a merchant sells a product or service with 12 equal monthly payments on the customer's credit card, that is the business requirement, and the data may be stored for up to 12 months. Presumably, it could be for 12, 24 or 36 months, i.e. the term of the payment plan. Following that interval, however, the cardholder data must be deleted - Requirement 3.1(b)

What appears not to be allowed is the storage and retention of the card verification code (CVC) used for card-not-present transactions. As well, the PIN and encrypted PIN block are not to be stored.

This would imply that only card present transactions fall under this rule, since most card-not-present transaction not only require the CVC, they also require the complete address of the cardholder for authorization.

Beyond that, there seems to be very little guidance from either the PCI-DSS or the various card brands.

[wconway]

A couple of thoughts.

I agree that there isn't a hard rule (that I know of) for how long pre-auth data can be retained. It depends on business needs. But I think we are going into a different area with the recurring transactions analogy.

As an example, if the cardholder data is needed for 1 year for monthly payment pre-authorizations, that is allowed.

What appears not to be allowed is the storage and retention of the card verification code (CVC) used for card-not-present transactions. As well, the PIN and encrypted PIN block are not to be stored.

This would imply that only card present transactions fall under this rule, since most card-not-present transaction not only require the CVC, they also require the complete address of the cardholder for authorization.

The idea behind pre-auth data (and the Council's SIG) is to address those times when there is a gap between card presentment and final amount (think automated gas pumps, parking lots) or when there is a system outage (you can't ask merchants to stop taking sales because the phone is down). They, too, are wrestling with the "how long" issue from what I can tell.

Recurring transactions can be handled by your acquirer better than retaining the PAN (which is what I interpret you to be saying).

As for the security codes and address verification, they are very different animals, and they are *not* required. They may be encouraged by your acquirer, but neither is required. Address verification is recommended because it lowers your interchange rate and, hopefully, merchant fee. The CVV2/CVC2 (I assume that's what was meant above) have no impact on interchange; their value is that they give the merchant a representment right in case of a chargeback. Different actions, different effects.

[jonassono]

I don't follow your reference to an 'acquirer'. Perhaps you should re-read the original reference by Silly Simon in which he/she refers an entity or merchant and not an acquirer.

Recurring transactions can be handled by your acquirer....we must be working on different planets. Acquirers in Canada do exclusively that they "Acquire" - they do not process customer payments, that is a service that payment processors offer.

Anyone who conducts business over the Internet and makes a purchase using a credit card, name, address, postal code, PAN, expiry date is always mandatory. About 50% of the merchants also have a mandatory requirement for the CVC.

Once again, I have no idea what your reference is to an acquirer in this thread.

Maybe its just Friday the 13th..

[lyalc]

But just how long can an entity store this SAD pre-authorisation?
I've always understood a good rule of thumb is 1 week for pre-authdata and SAD.
If the initial payment authorisation can't be completed within a week, then there is a serious systems problem, or an opportunity to better design the surrounding business process, imho.

Recurring payment don't need SAD as there has been an successful authorisation, in my understanding - but regional habits may be different.

As for the security codes and address verification, they are very different animals, and they are *not* required. They may be encouraged by your acquirer, but neither is required.

Outside North America, address verification is almost never available. In Asia-Pacific, only about 20% of sites in my on-line shopping experiences capture CVV2 - and some of those discard CVV2 before processing to simplify their PCI compliance.

[wconway]

I don't follow your reference to an 'acquirer'. Perhaps you should re-read the original reference by Silly Simon in which he/she refers an entity or merchant and not an acquirer.

Recurring transactions can be handled by your acquirer....we must be working on different planets. Acquirers in Canada do exclusively that they "Acquire" - they do not process customer payments, that is a service that payment processors offer.

Maybe its just Friday the 13th..

Yeah, maybe it is just the 13th. What I meant to say is that a merchant can work with their acquirer/processor to set up a recurring payment. The merchant does not need to keep the PAN, only a reference code after the first auth. Perhaps this is a US thing...I'm not a Canada expert.

As for CVV2 and Address Verification, I agree that many/most merchants take advantage of them. I was only pointing out that they are not required.

[lyalc]

The merchant does not need to keep the PAN, only a reference code after the first auth.

This transaction flow model is growing in Asia-Pacific as well.

lyalc