By Adam Atlas
Attorney at Law
Cyber-security concerns us all. If all participants in the payments ecosystem err on the side of safety, the payments system, and the nation as a whole, will be better for it. From a legal perspective, security is taking center stage because parties are becoming serious about designating responsibility for breaches and other cyber-security issues. Given the gravity of data security and the high cost to those found liable for breaches, I'll share some insights and identify legal issues related to cyber-security.
If you have not added two-factor authentication to your email and other key accounts, stop reading this article, and do it now. Two-factor authenticators require the person logging in to use the primary password and a second, usually changing, password generated by a phone app or a key fob, such as a Yubico. Doing this can substantially increase the security of your accounts ‒ at almost no cost.
Why is a lawyer recommending two-factor authentication? For starters, I have seen clients successfully avoid threats to their confidential information by utilizing two-factor authentication.
More formally, by way of example, regulated financial institutions, like money transmitters and virtual currency exchanges, are legally required to mandate two-factor authentication. This is due to new regulations adopted by the New York Department of Financial Services (see 23 NYCRR § 500). To be clear, those regulations would not likely apply to a typical ISO; however, it is helpful to learn about security practices and requirements from larger industry-leading entities and their regulators.
Larger ISOs that take part in processing data related to their merchant transactions should be familiar security requirements, especially those pertaining to cardholder data. Even smaller ISOs, however, deal in many forms of nonpublic personal information, such as Social Security numbers, tax returns and bank account statements.
The Payment Card Industry (PCI) Data Security Standard (DSS) is an industry-made, security standard devised to self-regulate the handling of cardholder data and other sensitive data. ISOs spend (and earn) money managing their merchants' PCI-compliance requirements. They should also consider whether their own businesses have unaddressed PCI issues and whether their vendors and vendors' merchants served must comply with one or more PCI DSS guidelines.
In layman's terms, PCI standards apply as a function of the quantity and quality of cardholder data that a provider holds. For example, an ISO that takes note of one cardholder number as part of a customer support ticket will not be held to the same standard as one who stores 1 million tokenized credit cards for a portfolio of merchants with recurring transactions.
Most ISOs know enough to stay clear of storing cardholder data. However, those ISOs should query their suppliers to see if the suppliers meet the necessary standard for handling data. With a flurry of new cloud-based platforms serving merchants, it is not always true that the platform meets all applicable PCI requirements. ISOs should grill new suppliers for their merchants to make sure the merchants will not be let down by inadequate PCI compliance on the part of one of their suppliers.
Here is where things get interesting. There is a lot of "passing the hot potato" going on in payments today, with one supplier pointing to another and that one pointing to a third on the subject of liability for breaches. ISOs need to understand precisely where they are positioned in the chain of responsibility for security breaches. If a breach occurs on an ISO's system, we naturally expect the ISO to take liability for the breach. However, if the breach occurs on a merchant's system or at a third-party supplier to the merchant, the allocation of liability becomes more complicated.
There isn't enough space in this article to fully dissect the issue, but consider the following scenario that is quite common in the ISO industry:
An ISO retains a gateway to provide gateway services to its merchants. The gateway's job is to carry and store encrypted cardholder and transaction data for the merchant between the merchant and its acquirer and the payment networks. For all intents and purposes, the merchant believes it is relieved of security problems because the ISO is providing the secure, gateway-supplied tokenization and communication platform. The gateway contracts with only the ISO and not with any of the merchants. The merchants believe that the ISO is providing the gateway service – it's even branded that way.
Everything goes well until a massive breach occurs at the gateway. Payment networks carry out an audit of the merchants affected and determine that their data was stored – and ultimately compromised – by the gateway. The merchants are fined large amounts and start looking for someone to blame. Their first stop is the ISO. After all, the merchants believed they were getting gateway services from the ISO – under the ISO's brand. However, the ISO never conceived of itself as the provider of gateway services.
At this time, the story can go well or not so well for the ISO. If the ISO thought ahead to put in place merchant-facing gateway supply terms with a suitable limitation of liability, the outcome might be acceptable. However, if the ISO did not put in place merchant-facing terms for the gateway service, there is a possibility that none exist. When this is the case, the supplier of a service loses some ability to limit its liability for failures.
Each ISO should know precisely how its liability is limited (or not) in the event of a breach by any of its suppliers.
In publishing The Green Sheet, neither the author nor the publisher is engaged in rendering legal, accounting or other professional services. If you require legal advice or other expert assistance, seek the services of a competent professional. For further information on this article, email Adam Atlas, Attorney at Law, at firstname.lastname@example.org or call him at 514-842-0886.
Notice to readers: These are archived articles. Contact names or information may be out of date. We regret any inconvenience.Prev Next