Banks to Retailers: Online Fraud? You’re On Your Own

Attorney Mark D. Rasch is the former head of the U.S. Justice Department's computer crime unit and today is a lawyer in Bethesda, Md., specializing in privacy and security law.

When a land title company in Missouri checked its bank account, it found it short by $440,000. Seems that someone had logged into its account at BancorpSouth and wire-transferred the funds to some strange entity’s bank account in the Republic of Cypress. Now the escrow and title company had never done a wire transfer like that. It had never done an international wire transfer. It had never wired money to Cypress, and had never done any business with the strange entity known simply as "Brolaw Services." The transaction was entirely fraudulent.

Someone had hacked the escrow company’s computers, installed a Trojan horse program, captured the login information, logged into the bank, and transferred the funds without the knowledge or authorization of anyone at the Missouri escrow company. When the Missouri escrow company called its bank to get the money back, the bank told the merchant to go pound sand.

In what has become a trend in this area of law, the federal Magistrate ruled that, when it came to bank fraud, the merchant was essentially on its own. The answer was for the merchant to have better security, not for the bank to have better alerting procedures.

The case involves the interplay between fraud, risk, loss, law and technology. Unfortunately, in this case, fraud wins.

Online banking is a boon for merchants, customers and banks alike. It’s easy, cheap, and usually effective. It saves the banks billions in not having to staff bricks-and-mortar banks with tellers, clerks or even people to answer the phones. The customers are responsible for data entry and quality control. With online banking, everybody’s computer (and iPad, Android phone, or Internet device) becomes a branch office or ATM.

The problem is that your computer, network, iPad, or phone simply lacks the security or authentication systems you would find in your average bank. Online banking systems are vulnerable to a host of attacks–many of them on the client (or merchant) side of the transaction. As a result, passwords, credentials or other authentication systems used by banks in online transactions can be stolen, forged, subjected to a "man in the middle" attack or otherwise compromised. Same is true for user IDs, passwords, or other ways used to validate the merchant to their bank. Nothing beats stopping by the branch office in Missouri and saying howdy to ’ol Mr. Watson at the bank, right? Online, nobody can tell the difference between Clayton, Mo., and Cypress.

For consumer transactions, we have something called "Reg E" and a federal statute, 15 USC 1693(g). With a few exceptions, the law provides that consumers are liable for unauthorized funds transfers only up to $50, and as a practical matter, banks usually waive the $50 fee. Of course they do. They want consumers to use online banking. They want consumers to use credit cards. They want consumers to use debit cards. This saves banks billions in bricks-and-mortar outlets. The more people feel comfortable doing online banking (even if there is occasional fraud), the more they will do it, and the better off the banks will be.

But for merchants, not so much. The law presumes that commercial entities (unlike moronic consumers) are smart and can protect themselves from online fraud. Thus, under the Uniform Commercial Code (UCC) adopted in almost every state, for commercial fraudulent transactions, the courts balance the liability between the commercial entity (merchant) and the bank. If the bank had "commercially reasonable" security (e.g., we did what many other banks do), then–for the most part–poof! That money in Cypress is YOUR problem, not theirs.

So what happened in the Missouri bank case was that the bank saw an upsurge of fraud, particularly the use of Trojan horse programs to steal passwords of its customers. It notified the escrow company, and suggested that the escrow company impose a "dual control" rule. Wire transfers could only be done if two agents of the company agreed and signed (digitally) the request. Sort of like nuclear missile silos – insert key, turn key, arm missile, launch.

Problem was, this was a small company, and the two people responsible were rarely in the same place at the same time. So the escrow company rejected this as unworkable for them. The court held that the bank’s procedures were "commercially reasonable" and that the merchant had accepted the risk of fraudulent transfers and had authorized the bank to make such transfers. The Magistrate noted that "the record is sufficient to establish that there are no genuine disputes with regard to the material facts as to whether BSB comported with industry or 'commercial' standards and whether those standards were reasonable standards intended to result in fair dealing. The parties and their respective experts are in agreement that the Federal Financial Institutions Examination Council’s 2005 Guidance (FFEIC 2005 Guidance) provides the applicable standards. The Court finds that BSB provided unrefuted evidence that it comported with industry standard as set forth in the FFEIC 2005 Guidelines, in particular as they relate to the use of multi-factor identification in providing for security procedures. Finally, although it is surely self-evident, the Court finds the standards included in the FFEIC 2005 Guidelines with regard to security procedures were reasonable standards intended to result in fair dealing."

The FFIEC is the banking industry group that sets out security standards for banks, much the same way the PCI Security Council sets them for credit card transactions. By following the FFIEC Guidelines for "multi-factor identification" the Court found, the bank acted reasonably, and had no liability. Bank wins. Merchant loses. Nuff said.

But the Magistrate failed to inquire further. The FFIEC guidelines recommend "multi-factor" authentication. Mostly, we authenticate people with a user ID (something a person knows) and a password (something else a person knows). That’s simply not multi-factor authentication. What’s worse, for ease of access or use (particularly for mobile banking) we often store one or both of these in the computer or device, meaning that we now have one factor or even zero factor authentication.

If someone can access our device (Trojan horse, break in, lost iPhone) they can access the banking application, or guess the password. Multi-factor authentication, which would be commercially reasonable, would typically mandate authentication by something you know (password, ID, etc.) AND something you are (biometric, fingerprint, retina scan) OR something you have (token, device, card, etc.) What the Missouri bank proposed was not multi-factor authentication, but multi-person authentication. In fact, by hacking the bank, the bad guys would have just as easily stolen one person’s user ID and password as two people – especially if they had to input the authentication at roughly the same time and/or in roughly the same place. It is the illusion of security.

The bank is right about one thing, though. This kind of "multi-factor" authentication, which is not really multi-factor authentication and is certainly not the kind of multi-factor authentication anticipated by the FFIEC, is the commercial standard. It is what every bank does. And that makes it "commercially reasonable" because, well 10,000 lemmings can’t possibly be wrong.

And as long as the banks don’t have any liability for the losses, they really have little reason to improve security, or adopt new enhanced security technologies, despite the fact that they–much more than the merchant customers–are aware of the risks associated with online banking and how to prevent them. True multi-factor authentication is too cumbersome and expensive, especially when it is the merchant who is screwed in the end.

That’s not to say that both merchants in general and the escrow company in particular could not have done more to prevent the unauthorized transfer. After all, the hacker initiated the transaction from the merchant’s computer, so the IP address matched what the bank was looking for. But when the bank representative saw a $440,000 transfer (after validating that the transferee was not on the terrorism watch list, or other "black lists" by the government, that the money wasn’t going to a prohibited country, and most important, that the merchant had money in their account) maybe the bank rep could have said, "Gee, that’s really weird." Brings new meaning to "don’t ask, don’t tell."

Security is a shared responsibility which should offer a shared risk of loss. What is "commercially reasonable" is in the eye of the beholder–especially if the beholder is a bank. Right now, the message from the banking community to the merchants is "Hey guys, you’re on your own. And hey, let’s be careful out there."

If you disagree with me, I'll see you in court, buddy. If you agree with me, however, I would love to hear from you.