Minnesota makes PCI law
June 1st, 2007 Posted in Compliance, Government, Legislation, PCI DSS
This week Minnesota trumped Texas in being the first state to make PCI compliance a law. Minnesota is home to people like Garrison Keillor and the many Swedes that live there. It is also a great Midwestern state, eh?
The state’s Plastic Card Security Act would set the following:
The law says that any company that suffers a data breach and is shown to have stored prohibited card data will have to reimburse banks for the cost of blocking the exposed cards and issuing new ones.
Companies that handle fewer than 20,000 payment card transactions yearly are exempted.
The act outlaws the post-transaction storage of data prohibited by the PCI DSS, but PIN data can be stored for 48 hours for debit card transactions.
A Harvard law blog points out that:
The state already has a data breach notification law, similar to those now spreading through state legislatures like wildfire.
The law does not mention PCI, but is strongly based on it. You will note that this law now enables the cardholder to see direct damages against a company that improperly discloses their credit card data.
How will this change PCI? It will not. The merchant still has an obligation to their acquirer to validate compliance. This new law is simply a new avenue for consumers and consumer advocacy groups to pursue direct damages from the merchant. It greases the skids for future lawsuits.
![[del.icio.us]](http://images.del.icio.us/static/img/delicious.small.gif){kind=small}
13 Responses to “Minnesota makes PCI law”
By John Jacott on Jun 1, 2007
This should prove interesting… It means that TX and MA suites are guaranteed to pass.
I really hoped they would take a stronger standard… this one’s pretty loose.
I wonder if business will pick up on it now… I know that in today’s litigious society, many will be sued. I can see new courses developing now, in law schools everywhere!
By rybolov on Jun 1, 2007
It’s not going to change how many people get sued…. if you’re negligent under one standard, you’re negligent under a law-enforced subset of that standard, and that’s what a plaintiff has to prove–negligence.
I don’t see how this makes PCI compliance a law. Call me crazy, but delineating responsibilities and liability as a result of a breach does not equal complying with a standard consisting of a catalog of security controls.
All this law does is give the banks (not even the individual cardholders) the ability to hold the card processors responsible for the costs that they (banks) incur as a result of a breach.
Now the unintended consequences: it is to my advantage as a card processor not to become PCI certified. Why? Because now I’m obligated to pay for the cost of a breach regardless, so PCI does not give me the indemnity that Visa was offering as a carrot. In a strictly business sense, I chalk the cost for cleaning up after a breach as “the cost of doing business”.
Maybe I’m completely off-base here.
And yes, I know you all are happy to have me back commenting on your blog. I’m glad to be the gladfly. =)
By datasecurity on Jun 3, 2007
I think we need to define “card processors” as you have used it. A processor is an entity that acquirers outsource their transaction processing to. For example, First Data or Chase Paymentech would be processors.
This law would affect the company that illegally discloses the credit card data.
I think you are confusing the issue a little. You may be referring to the acceptance channel as the “card processor” and the card issuer as the “bank”. Let’s remember that there are usually two different banks, the issuer and the acquirer. To simply say that a ‘bank’ is looking to benefit is a bit vague.
Incentives do not exist for non-compliance.
By rybolov on Jun 4, 2007
The language of the law defines the following:
“Service provider” means a person or entity that stores, processes, or transmits access device data on behalf of another person or entity.
“Financial institution” means any office of a bank, bank and trust, trust company with banking powers, savings bank, industrial loan company, savings association, credit union, or regulated lender.
I’m tangentially right, but still wrong. =)
By datasecurity on Jun 4, 2007
Still appreciate the comments. I think clarity is often brought through example. Both positive and negative controls are good for scientific experimentation.
By archer on Jul 19, 2007
Hi -
I just stumbled on your site as I was looking for discussion around the new Act in Minnesota.
Upon reading the text of the new Act - I was curious how this legislation will change the role of middleware Service Providers that are currently filling the space between merchants and processors. As I read it - the Act states that the merchant will be in violation of the Act if the merchant’s service provider retains card information after authorization. Yet - in practice - I understood that processors and card associations require Service Providers to hold the data for a minimum period of time for the purpose chargebacks. Will service providers and processors ultimately be relieved of holding any data for any period of time? Or will they be stuck in the impossible situation of trying to comply with the law and also meeting card association retention requirements for chargebacks?
As a Canadian lawyer in the industry - I’d be curious of your insights on the future trends in that regard.
Jennifer Archer
By Michael Dahn on Jul 19, 2007
@archer : One of the areas of compliance is requirement 12.8 that requires the merchant to contractually require their service providers to safeguard and take responsibility for the handling of cardholder data.
By archer on Jul 19, 2007
Michael -
Not sure I understand the point your making. The Minnesota Act states:
“Subd. 2. Security or identification information; retention prohibited. No person or entity conducting business in Minnesota that accepts an access device in connection with a transaction shall retain the card security code data, the PIN verification code number, or the full contents of any track of magnetic stripe data, subsequent to the authorization of the transaction or in the case of a PIN debit transaction, subsequent to 48 hours after authorization of the transaction. A person or entity is in violation of this section if its service provider retains such data subsequent to the authorization of the transaction or in the case of a PIN debit transaction, subsequent to 48 hours after authorization of the transaction.”
Merchants would therefore want to ensure that their service providers comply with the law. Processor Merchant Agreements on the other hand typically require service providers to retain the data for chargeback purposes. How does a service provider reconcile these two competing requirements?
Cheers,
Jen
By Michael Dahn on Jul 19, 2007
@archer : You are learning the complexities of the payments industry and the terminology that goes along with it. (I am not a lawyer, but) the law that you quoted refers to the storage of PIN data, track data, and card verification value. These are classified as “sensitive authentication data” but they still may retain the PAN (card number) which is what is used for the chargeback process. If the PAN is retained, the PCI DSS states that it must be protected as per requirement 3.4 (”rendered unreadable”).
By archer on Jul 19, 2007
ah - gotcha
thank-you! Much appreciated.
By Bruce Sussman on Sep 13, 2007
Regarding the Minnesota law - perhaps I am missing something. It is strictly prohibited under all debit network rules to store pin block data. Most networks already “store and forward” processing of pin blocks. If my understanding of the law is correct, merchants retaining pin block data for any period of time post authorization, would violate ANSI standards and network rules.
By Bruce Sussman on Sep 13, 2007
Correction to the law post. The sentence should have read ” most networks already prohibit store and forward processing of pin blocks.”