by Robert Smith
Originally Published - Jul 05, 2016
In March, news broke that hackers stole $81 million from the Bank of Bangladesh out of their account with the Federal Reserve Bank of New York. It seems the New York Fed was largely diligent on their end at first glance, if not perfectly. The failure occurred within the SWIFT system, not its own. Further, they were alert in catching a simple typo and stopping all further transfers, preventing what would have been a loss that was over ten times larger. The issue coming more and more to the forefront now, however, is the possibility they were, at least in part, negligent.
In fairness, situations like this can and do happen, even if they rarely ever reach this size and scope. Every proper and reasonable precaution is taken – security systems are implemented, policies and procedures are developed, and employees are trained to them – and yet something manages to slip past all the safeguards. Of course, when it comes to securing assets and information, we have to put some gates in the walls. I once jokingly told a colleague that, as a compliance professional, my ideal situation is one in which no one can access anything; that way I know nothing can go wrong with it. Of course, in that scenario, all transactions would cease and we would go out of business. There has to be some reasonable access.
The question in the case with the New York Fed is what was really being reasonable, and what was simply not being careful? One of their earliest replies should raise some questions about protocol. They state the transactions were approved by the SWIFT system. All well and good, except that the SWIFT system does not exist in a bubble inside of the New York Fed; it is a system of communication between it and other banks. The problem there is no amount of security on one end will stop problems on the other end.
Simply assuming that everything is fine when communication between two parties is involved is absolutely opening yourself to trouble. Many feel a bit incredulous toward the idea that a communication from a trusted source over a trusted channel could be fraudulent, but it is that very trust in familiarity that criminals such as these use to get what they want. SWIFT is a computer system. It is a strong first line of defense, but it should never have been the only line. Further, the heist was pulled across the weekend in both time zones. The Fed could not reach Bangladesh as it occurred, and Bangladesh could not reach the Fed offices when they discovered the problem. A major transfer occurring when the requester cannot be reached probably should have raised some red flags.
Since the news first broke, new developments have called the New York Fed’s security measures into further question. The requests that allowed the hackers to transfer $81 million were part of a second attempt. The first time they had formatted the requests incorrectly and the SWIFT system rejected them. Further, the hackers did not have the names of the correspondent banks to which wired funds usually went, and instead were paid to individual recipients. This is rarely done. Further, the individuals’ names appeared repeatedly across the 35 requests.
There is still a lot to learn about what happened, and Congress seems eager to do so, but without assuming too much on the mindset of the New York Fed employees there are still vital lessons all lenders should take away from this. First, there should always be strong protections in place to catch anything out of the ordinary. Second, nothing really takes the place of having someone actually look at a request to move funds. I sincerely doubt Congress will happily accept the explanation that SWIFT indicated everything was okay and this was not caught immediately, and I am equally doubtful any lender could successfully defend itself that way if deposits were lost in such a fashion.
There were a number of reasons for someone to put a halt on everything until the Bank of Bangladesh could be reached, but they were all overlooked. Only after $81 million was already sent did someone realize they had to put the brakes on those requests. It is true that, sometimes, even the best and most diligent efforts made within reason are insufficient. The problem here is that there is a very strong possibility that there were many reasonable options that could have been employed here with relatively little inconvenience. Perhaps those small inconveniences can add up over time, or perhaps they are significant when security protocols are new or updated, but was it really worth forgoing them for something like this to occur? When weighing the risks facing your own institution, and the efforts they involve, ask yourself how much the time and effort really cost compared to what you can lose in funds and in reputation. It could very easily make all the difference.