Cyber robbery of BB could be a scenario for replay

In 2016, the nation of Bangladesh was financially robbed in a cyber attack that could have affected food supply, health care, education, and there was nothing they could do about it. A repeat of the scenario is inevitable, unless the Bangladesh authorities demand explanations and compensation from those who compromised the banking services and the SWIFT messaging service. Cyber-heist (cyber robbery) is spreading faster in developing countries, while ICT laws are weak.

Many policymakers and legislators are unaware of the impact of digital (ICT) commerce as it is complex and relatively new, so digital commerce laws in developing countries need to be improved. These conditions create opportunities for technologically advanced countries to reap the benefits without explaining their wrong actions.

On 5 February 2016, Bangladesh Bank (BB) was on the verge of losing $951 million but accidentally lost $81 million. It was the biggest cyber robbery news in the world. Some said it was the work of highly skilled hackers, while Bangladesh is trying to find the real answer.

Well, I am an ICT expert and have led and managed the most advanced enterprise ICT systems with billions of records in Australia. This cyber-heist presents an interesting case in terms of what has been achieved and what the dangers of digital banking are if money laundering is not eradicated. Based on the information available to me about the cyber robbery of BB, I could not conclude that the above mentioned cyber-heist was just the result of malware. Below are some of the reasons:

As in most countries, BB maintains an account with the Federal Reserve Bank of New York (FRBNY), where Bangladesh holds US dollars.

SWIFT messages were assumed to have been generated in a highly secure “dealing room ” at BB, instructing the FRBNY to transfer $951 million to the Philippines. These were financial transactions between the FRBNY and Philippine banks using SWIFT messaging systems, so it is expected that the FRBNY and SWIFT would have identified any problems.

Databases for storing financial records both at 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 similar relational database systems. They are very reliable and almost impossible to hack as the data processing applications check multiple levels of authority to gain access to the database.

The database system makes backup copies 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 on the record. Each record stored in the database contains a 24-digit timestamp in a format containing year, month, day, hour, minutes, seconds, and milliseconds. This means that transaction data gives a clear picture of any movement in any millisecond.

The FRBNY has received instructions from SWIFT to complete the transfer of funds. These instructions must go through extreme checkpoints, and if an unusual attempt occurs, they will trigger warning messages that are monitored around the clock 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.

A similar technology and principle applies to the SWIFT financial messaging system in Brussels. When a fund transfer message is generated on a dedicated SWIFT machine anywhere in the world, that 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 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 (countries), dedicated SWIFT machines use Alliance Access software, which allows banks to connect to the SWIFT network. Apparently BB is using Alliance Access software. The use of any third-party software and special equipment for the SWIFT service is beyond the purview of BB.

One might think that the malware at BB was directing all traffic and tricks to carry out the cyber robberies in the SWIFT system, but 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, e.g. HSBC bank provides this device to any customer). 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 in BB? If this was an automated process, then the system for money transactions must have passed the extreme checkpoints and then created the printing instruction. Alternatively, it was 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 manual intervention has occurred, FRBNY should clarify.

No malware can gain control of the Federal Reserve's transaction system from the computer of BB, 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 FRBNY. 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. BB has been a client of the FRBNY for many years, the FRBNY is well aware of the business activities of BB. In this way, the FRBNY will identify requests for fraudulent or suspicious transactions. Moreover, according to good business practice, the FRBNY must send an email to BB for "Payment Confirmation" and receive response from the client (Central Bank of Bangladesh) before sending money to the Philippines. Otherwise, the FRBNY 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 FRBNY 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 fault in the system.

Bangladesh must be vigilant and develop smart ICT strategies to ensure its own security, as a monopoly in digital commerce could lead to financial disaster.

The writer is Senior Consultant at Enterprise Data Integration