Photo: Michael DaddinoAn investigative report from Reuters paints a disturbing picture of the Federal Reserve Bank of New York using antiquated security practices to handle interbank SWIFT payments. The report follows the February heist of $81 million heist from the central bank of Bangladesh's account at the New York Fed, via fraudulent SWIFT messages (see SWIFT Deduction: Assume You've Been Hacked ).
See Also: Achieving Advanced Threat Resilience: Best Practices for Protection, Detection and Correction
Brussels-based, bank-owned cooperative SWIFT, formally known as the Society for Worldwide Interbank Financial Telecommunication, maintains a messaging systems designed to guarantee that money-moving messages between banks are authentic. Some security experts believe the Fed relies too heavily on other institutions and organizations, such as SWIFT, to authenticate and verify interbank payments. But is it the Fed's responsibility to ensure the validity of interbank transactions it doesn't initiate?
No, says Avivah Litan, an analyst at consultancy Gartner.
"The liability is with the originating bank," she says. "So Bangladesh Bank should review its contract with SWIFT. If it plans to sue, I don't see the bank having a case."
But many experts say that U.S. banks have not paid enough attention to interbank transaction security. Some also argue that the Fed, in particular, needs to improve its related risk-management efforts.
Lessons from Account Takeovers of the Past
SWIFT is the interbank messaging system of choice for many banking institutions throughout the world to send back-end payment instructions to each other. Litan says most recipient banks don't re-authenticate or verify SWIFT transactions after they get received from the originating bank.
"There are a couple of recipient banks I know of that are now putting controls in, and then the originators are trying to strengthen their security, too," Litan says.
Litan likens the recent rash of fraudulent SWIFT payments - after attackers infected Bangladesh Bank and at least several other banks with malware - to the rash of corporate account takeover incidents that plagued small businesses seven to 10 years ago. Then, millions of dollars were fraudulently wired out of commercial accounts after online-banking login credentials were compromised via malware, such as Zeus, that included keylogging capabilities (see Banks, Regulators React to SWIFT Hack).
Those account takeover incidents spurred the Federal Financial Institutions Examination Council to update its authentication guidance for online payments and wire transfer verification, leading to stronger controls being put in place. Of course, the FFIEC could also issue new guidance in the wake of the SWIFT-enabled heists.
Heading to Courts
Related court cases may also set new precedents. Litan expects that heists linked to fraudulent SWIFT transactions will increase, thus leading to more cases involving banks going to court to attempt to recover funds from receiving banks or seeking related compensation. As the number of cases involving SWIFT and some of more of its 11,000 member banks increases, she predicts that the same types of legal arguments that cropped up in court in the wake of corporate account takeover cases will reappear.
Such cases often hinge on a seemingly simple question: "Is the security reasonable?" Litan asks. But in the Bangladesh Bank case at least, "based on the contracts, SWIFT and the Fed didn't do anything wrong," she says. "They may have been negligent. But what is the standard they're held by?"
Bank-to-Bank Security Boost Required
Cybersecurity attorney Chris Pierson, general counsel and CISO at invoicing and payments provider Viewpost, says U.S. banks have focused much more attention on ensuring the security of customer-to-bank payments rather than bank-to-bank payments.
"This needs to be re-examined," he says. "It is imperative for all banks to implement the same types of controls they have internally and externally with customers as they have between banks and the Fed."
But Al Pascual, head of fraud and security at Javelin Strategy & Research, says that relying on participating banks to prevent unauthorized transfers - given the many information security risks and attacks those banks face - is no longer a viable strategy. "This isn't lost on the Fed, and I'd expect them to implement more effective risk-management protocols throughout the system," he says. "Every point in the system is connected, and all of it will be tested."
The Fed has already taken some steps to mitigate immediate risks, such as implementing a 24/7 hotline for central bank customers to contact if they suspect fraud. That's notable because when $81 million was stolen from the central bank of Bangladesh via a fraudulent SWIFT payment in February, the Fed's hotline was only open during U.S. business hours from Monday through Friday, Reuters reports, and when Bangladesh Bank tried to report suspicious activity to the Fed on a Saturday, it received no response until two days later, after business had resumed on Monday. By that point, the Fed had already approved five of the fraudulent requests, transferring $101 million out of Bangladesh Bank's account. While $20 million was quickly recovered, most of the rest of the money remains missing.
Additional Regulatory Action Possible
As with the historical flurry of account-takeover cases, SWIFT-enabled heists could also lead to closer regulatory scrutiny of public and private banks, for example via the Uniform Commercial Code, Litan says (see Will SWIFT-Related Heists Trigger More Regulatory Oversight?).
"Article 4A of the UCC was the basis in the courts in the account takeover cases," she says (see A New Legal Perspective on ACH Fraud ). "I'm not sure if 4A applies here, but the situations are very similar."
Article 4A, which all 50 states have adopted, is an attempt to allocate risk between banks and their commercial customers when electronic fraud occurs (see Reasonable Security: Changing the Rules).
Article 4A was created in the 1980s to offer fraud protection to commercial customers. But in account takeover suits, banks used Article 4A to support claims that the security measures they offered were reasonable, even when accounts did get taken over and fraud resulted.
Litan says that a standard or code similar to 4A, which outlines expectations for "reasonable security," could soon be applied to compromised SWIFT transactions. Indeed, if originating banks such as Bangladesh Bank start filing related lawsuits in U.S. court, Litan says she wouldn't be surprised to see Article 4A - the standard used to determine responsibility for fraud in account takeover cases - soon being applied as well to SWIFT transactions.
Seeking SWIFT Help
Litan says SWIFT should also be doing more to help its member banks block future heists or at least better contain any related fallout (see SWIFT Promises Security Overhaul, Fraud Detection).
"I do think SWIFT needs to put some security measures in place to provide to its member banks to help banks that don't have time to do this on their own," she says. "And the receiving banks should do more. These large financial institutions have not had any fraud detection against SWIFT payments because they never needed to. Many are reluctant to put much in, because these are transactions that move almost in real time. There is big urgency to get the money moved, and the more fraud controls you put in place, the more you slow the transactions down."