Mizanur Rahman: In February 2016, the central bank of Bangladesh was robbed in a cyberattack that could paralyse food supply, medical services, technology purchases, expert recruitment and consulting, and there was nothing we could do about it. A repeat of the scenario is likely as cyber robbery spreads faster in developing countries, ICT laws are weak and the consequences of negligence can be a great risk to our nation.

Many politicians and legislators are unaware of the impact of digital commerce because it is complex and relatively new, and digital commerce laws in developing countries need to be improved. The current conditions create opportunities for technologically advanced countries to reap the rewards without explaining their wrongdoings.

On Feb 5, 2016, the Bangladesh Bank was on the verge of losing $951 million but finally lost $81 million. It was the biggest cyber heist news in the world. Some say it’s the work of highly skilled hackers, while Bangladesh is trying to find the real answer. It’s been six years and still, there is no answer. That is the point of this work.

As an ICT expert, I led one of the largest corporate ICT systems in Australia with billions of records. The Bangladesh Bank cyber heist is an interesting case, in terms of what has been achieved and what are the dangers of digital banking if money laundering is not rooted out. Based on the information I have about the Bangladesh Bank cyber heist, I could not conclude that the incident was simply the result of malware. Below are some of the reasons:

As in most countries, the central bank of Bangladesh maintains an account with the Federal Reserve Bank of New York, where Bangladesh keeps US dollars.

The SWIFT messages were supposed to have been generated in a highly secure “dealing room” at the Bangladesh Bank directing the New York Fed to transfer $951 million to the Philippines. These were financial transactions between the New York Fed and Filipino banks using the SWIFT messaging system, so the New York Fed and SWIFT are expected to identify any issues.

The financial record databases at both the US Federal Reserve and SWIFT headquarters in Brussels can be described as the most advanced database systems. They use IBM-DB2, Oracle, TeraData or relevant database systems. They are very secure and almost impossible to hack because data processing applications check multiple levels of authority to gain access to the database.

The database system makes backups periodically, automatically on a daily basis and does not delete records for many years. Even if someone deletes the data for a good reason, the database backup system will have a timestamp on the deleted record and store it. No one, no bot (robot) can act faster to avoid any activity without a timestamp in the record. Each entry stored in the database contains a 24-character timestamp in a format containing year, month, day, hour, minute, second, and millisecond. This means that transaction data gives a clear view of any movement in any millisecond.

When the New York Fed receives instructions from SWIFT to complete a funds transfer, those instructions must pass through the extreme checkpoints and if an unusual attempt occurs, they will trigger warning messages that are monitored 24 hours a day by qualified DBAs (database administrators). These are shift workers who perform various actions depending on the tasks and make decisions as needed. I made this technical effort to explain that one cannot trick the data processing system by deleting a record from the databases without leaving a copy of the record in the transaction system of the Federal Reserve Bank.

Similar technology and principle apply to the SWIFT financial messaging system in Brussels. When a fund transfer message is created on a dedicated SWIFT machine anywhere in the world, the message goes through an extreme verification process in Brussels. It uses business intelligence and compliance services such as KYC (Know Your Customer) verification and also checks customer accounts for suspicious and illegal activity. SWIFT also uses AML (Anti-Money Laundering), which refers to laws, regulations and procedures designed to prevent criminals from trying to disguise illicit funds as legitimate income. SWIFT generates an admission code if it is not fraudulent. Only then is the verified message pushed through the channels to reach the addressee. SWIFT does not hold any funds or securities and does not manage client accounts.

In some regions and countries, dedicated SWIFT machines use Alliance Access software, which allows banks to connect to the SWIFT network. Apparently, the Bangladesh Bank is using Alliance Access software. The use of any third-party software and special equipment for the SWIFT service is beyond the purview of the central bank of Bangladesh.

One would think that the malware at the Bangladesh Bank was channelling all the traffic and subterfuge to perform cyber robberies on the SWIFT system, although I have some reservations about this. When someone logs into a SWIFT account on a dedicated SWIFT computer at the central bank, the person has to provide a login ID, a password, and then another identification number, which is usually generated on a separate device (it is the size of a credit card). This device never connects to any ICT device. So how, without such steps, were fraudulent orders created and pushed through the system? However, if such steps were not taken by SWIFT, then they compromised their services in Bangladesh.

How were the printing instructions forwarded by the Federal Reserve Bank that produced hard copies of the transfer requests on a printer at the Bangladesh Bank? If this were an automated process, then the system for money transactions must have passed the extreme checkpoints and then created the printing instruction. Alternatively, it was a manual intervention using a DBA password. In this case, it is necessary to clarify which of the means was used. If automatic processing was used, then the verification process failed due to a lack of business intelligence knowledge. If the manual intervention has occurred, the New York Fed should clarify.

No malware can gain control of the Federal Reserve’s transaction system from the computer of the Bangladesh Bank, as the process involves many steps. Moreover, there was no suspicious information about any malware in the SWIFT messaging system. Therefore, it is necessary to determine what triggered the sending of the message from Brussels to the New York Fed. How the message instructions went through the verification process.

Both SWIFT and the Federal Reserve Bank use Business Intelligence software to know their customers’ behaviour, transaction patterns, maximum transaction amounts, and more. The Bangladesh Bank has been a client of the New York Fed for many years, so the Federal Reserve Bank is well aware of the business activities of the Bangladesh Bank. In this way, the New York Fed should identify requests for fraudulent or suspicious transactions. Moreover, according to good business practice, the New York Fed must send an email to the Bangladesh Bank for “Payment Confirmation” and receive a response from the client (central bank of Bangladesh) before sending money to the Philippines. Otherwise, the New York Fed compromised its service obligations.

SWIFT must explain the reason for the service failure that generated messages from their dedicated computer, either in Bangladesh or Brussels, which ordered the New York Fed to transfer money to banks in the Philippines. To uncover the truth, it has to thoroughly analyse the data with timestamps in the SWIFT database to determine how, when and which authority created the SWIFT message. It can all be revealed if SWIFT has the intention for the discovery of a fault in the system. Bangladesh deserves explanations and compensation from those who compromised banking services and the SWIFT messaging service.

SWIFT is a monopoly that can easily escape accountability, it’s hideaway and inaction could lead to mistrust. Bangladesh must be vigilant and develop smart ICT strategies to ensure its own security as the digital economy is here to stay.