This browser is not actively supported anymore. For the best passle experience, we strongly recommend you upgrade your browser.

Freshfields TQ

Technology quotient - the ability of an individual, team or organization to harness the power of technology

| 3 minutes read

Who pays for SWIFT hacks?

One aspect of the recent SWIFT hacks should have people talking: The attempt by some hacking victims to shift their losses to other players in the SWIFT system.

By way of reminder, recent SWIFT hacks went like this: The culprits (maybe North Korea? maybe China? accusations are flying) managed to hack into victims’ computers. Known victims include Bank Bangladesh, Vietnam’s Tien Phong Bank, Ecuador’s Banco del Austro, and a Philippine bank, but there are likely others. Once the culprits broke into the victims’ systems, they used the victims’ SWIFT credentials to send transfer orders to other banks who held the victims’ correspondent accounts. Those banks, which included the NY Fed and Wells Fargo, then went about authenticating the orders under an agreed protocol used by SWIFT members. In due course, the SWIFT messages were all deemed authentic—because they were. Although the orders may have been unauthorized, they were in fact real instructions sent from the victims’ accounts. It’s the difference between someone forging a check with your name and someone tricking you into signing a real check. So naturally the recipient banks honored the victims’ apparent wishes and transferred tens of millions of dollars out of the victims’ accounts, most of which has now disappeared into the ether.

Some victims are now looking to the banks that honored the instructions for recompense. Bank Bangladesh reportedly hired US counsel to sue the NY Fed. Banco del Austro has already sued Wells Fargo. The theory is that Wells Fargo shouldn’t have honored the SWIFT instructions because, under the Uniform Commercial Code, a bank can’t rely solely on SWIFT authentication to determine whether instructions are legit. It has to do more—maybe call the instructing bank to confirm, or something along those lines.

Banco del Austro’s view has almost certainly raised some eyebrows among SWIFT members. Most banks do rely on SWIFT authentication without follow-up. If Banco del Austro is right, then they’ll all have to change their ways, and it’s going to make SWIFT banking a lot slower.

But perhaps a more important implication of Banco del Austro’s view is that it could change who bears the risk of hacking. That is, Banco del Austro’s position would shift the costs of wire-transfer hacks from the banks who were hacked to the banks who weren’t. Remember, it was Bank Bangladesh and Banco del Austro who were hacked, not the NY Fed or Wells Fargo. According to reports, it was security flaws at the hacked institutions—reportedly the lack of a firewall and cheap routers in Bank Bangladesh’s case—that deserve blame. (Bank Bangladesh blames SWIFT for additional software vulnerabilities, but that’s a separate issue.) As a practical matter, shifting the costs of these failures to the banks who weren’t hacked means:

  • reducing the incentive of banks who issue instructions to take care of their own cybersecurity; and
  • placing the cybersecurity burden on the banks who receive instructions, even though there isn’t much that those institutions can do to solve the problem.

In other parts of the cyber world, the trend is the opposite. There, institutions are increasingly placing the costs of cyber security on the people who are closest to the vulnerability. After all, it’s those people who are best situated to prevent hacks.

One example is the well-known Target breach. There, remember, consumers had credit cards with banks; those banks had deals with Visa and Mastercard; Visa and Mastercard in turn provided payment systems to Target. After hackers stole consumer information from Target’s systems, consumers started finding fraudulent charges on their statements. Initially the cost fell on those consumers. But the costs quickly shifted to their banks, since most banks will credit a consumer’s account for fraudulent charges. Those banks, along with Visa and Mastercard, later sued Target, attempting to shift the costs of the breach further down the line. From a practical perspective, this put the burden of cybersecurity on the party closest to the hack.

Also consider a pending proposal in the UK to tweak the traditional rule that credit card issuers won’t hold credit card holders to fraudulent charges. The Financial Times reports that under the proposal, “[i]n the event that fraud is perpetrated on a customer with poor cyber security, a final step could involve the bank refusing to compensate any losses”. Although I can’t comment much without seeing a concrete proposal (which isn’t public yet), the point seems to be that the cyber security costs should be borne by the people who can actually do something about those risks.

SWIFT itself is addressing the question a different way: According to a separate Financial Times article this morning, SWIFT is considering cutting off services to banks that don’t meet minimum cyber security standards. By pushing out banks who fail to get their systems up to snuff, SWIFT could protect the rest of the system. That would shift the bulk of cyber security costs—or at least preventative costs—back onto the banks who are closest to the actual hacks. Which means that the outcome of Banco del Austro v. Wells Fargo might not matter that much.

Tags

banking, americas, insurtech, regulatory