Store and Forward PCI Compliance
May 7th, 2008 by admin Posted in PCI DSSMany 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.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
7 Responses to “Store and Forward PCI Compliance”
By Andrew on May 8, 2008
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.
By David Bergert on May 9, 2008
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
By Bruce Sussman on May 10, 2008
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
By Ben d'Anvers on May 15, 2008
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
By Nirav Shah on Aug 4, 2009
What about business area that store credit card number and cardholder name for not payment processes. For example, business provides a service in which we monitor call centers accepting credit/debit cards to assess customer service performance. As part of this service we receive recorded call center conversations which include credit/debit card information. Are we in-scope for PCI?
By Bruce Sussman, CPA, CISSA CISSP on Aug 4, 2009
The DSS does not distinguish as to the business purpose. While holding the card data for customer service, marketing,forensic or value added activity is a legitimate function, the card data must still be fully protected and managed in accordance with the DSS. The VRU or VRU and surrounding infrastucture that is part of your card holder network segment should be consider in scope.
By Raoul on Aug 11, 2009
Consider the following example:
Charity organizations engage with third party service providers to collect donations on their behalf, including credit card donations. The CHD might be stored in a database at the service provider’s office for weeks, dumped into a CSV file, purged from their database and transferred to the charity organization who then processes the transactions. As I understand it, the service provider would technically have no obligations under PCI DSS, since they are only collecting data pre-authorization and passing it on. Is this correct? It really doesn’t make sense that that should be the case.
Of course, I’m not saying this service provider should not be adhering to the PCI DSS regardless, but it does seem a bit off that they should be excluded, and have to answer to the card brand’s operating regulations when any other service provider processing CHD post-authorization has PCI DSS obligations.