Store and Forward PCI Compliance
Filed Under (PCI DSS) by Michael Dahn on May-7-2008

Many people ask about storage of data pre-authorization (that is before the authorization for the transaction has occurred) and what it means for PCI DSS compliance.  First, we should point out that PCI DSS does not address pre-authorization data storage, this is managed by the individual card brand Operating Regulations.

But we know that many merchants will use Store and Forward (SAF) for transactions, “typically ISO 400 messages with many of these containing field 35 (Track II Data)“.  This is where a merchant is offline either intentionally or not, and they queue up transactions that are stored locally.  Later when the merchant goes back online they send these transactions off to their acquirer (and transitively onto the issuer) for processing.  These transactions are also sometimes called “on us” transactions, because if the response from the issuer is ‘denied’ then the merchant must absorb the cost of the bad transaction.

Aside from all this, it’s important to point out that sooner or later the transaction will go through and be completed.  This means that any data stored in a pre-authorization style will eventually be authorized and this the responsibility of the merchant to protect.  If the cardholder data is ever compromised from the merchant and fraudulent transactions are traced back to the merchant, as the Common Point of Purchase (CPP), the responsibility still falls on the merchant.

This is why I advise merchants to protect cardholder data that is stored in pre-authorization transactions the same as they would for other cardholder data (i.e. PCI DSS Requirement 3.4).  Of course they should always check their card brand Operating Regulations for official statements.

The Payment Systems Blog points out:

On May 1st, a payment processor modified their message formats as a part of their PCI compliance to not send Field 35 in SAF Advice transactions and would just send the PAN in field 2 and Expiration Date in field 14, instead of DE 35.

AndrewJ also points out that:

Another update on this (if you are from Australia) - there is a change being made to AS2805.2 to change the track 2 field from mandatory to optional in 04×0 messages. This should be released sometime this month.

Popularity: 28% [?]

[Slashdot] [Digg] [Reddit] [del.icio.us] [Facebook] [Technorati] [Google] [StumbleUpon]
   Read More


Comments
Andrew on May 8th, 2008 at 1:05 pm #

Actually, ‘ISO 400′ messages (ie 04×0 messages used in ISO 8583, and other standards such as AS2805) are reversals. These messages are used to ‘cancel’ a financial advise message (02×0) that has been previously sent, but for some reason is in an unknown state. This is usually used when there is a communications error.

The use of track data in ISO 8583 04×0 messages is not required.

David Bergert on May 9th, 2008 at 5:09 am #

I would agree that it should not be required - but on an issuer implementation we were receiving reversals from a processor (which typically use a SAF mechanism), until this recent change.
Also: Opening up one of my specs to an endpoint for a acquirer implmentation- states the field 35 for debit and ebt - this field must match the original 0200

So it really depends on the endpoints/interface specs

Bruce Sussman on May 10th, 2008 at 5:38 pm #

I would suggest a somewhat different view about store and forward transactions. Store and forward are part of the authorization cycle because they emanate from a failed authorization attempt or “ISO 200″ message.The merchant’s purchase authorization (200 message) did not reach the card network or issuer (most often due to connectivity or application problems). Rather than lose the txn, the merchant willfully stores the card data and re submits it later on. I would suggest that card data retained under store and forward rightfully be considered as part of the DSS - hopefully, the next version of the DSS will make this clear. Also, under ANSI and ISO standards for pin security, it is not permissible to retain pin blocks. So proceed with extreme caution if you support store and forward

Ben d'Anvers on May 15th, 2008 at 2:32 am #

I’d just like to clarify further on Michael’s article: The scope of protecting data (a la requirement 3.4) is not restricted only to cardholder data post-auth. It applies to ALL stored cardholder data regardless of whether the TX has been authorised or not. This is not a recommendation as he suggests, it IS a PCI DSS requirement.

Pre (Op regs)& post auth (PCI DSS) issues are only applicable to requirement 3.2.x, not to requirement 3.4

Post a comment
Name: 
Email: 
URL: 
Comments: