SWIFT’s new Customer Security Program (CSP), designed to protect the integrity of the global banking messaging system, must be causing headaches for many at the moment, with its end of June deadline looming. But banks might just end up thanking SWIFT for pushing them towards taking important anti-fraud steps earlier than originally planned.
Banks are being forced to tighten up their efforts to stop fraud by SWIFT or risk sanctions from the international bank messaging co-operative, which could ultimately prove a death sentence for that bank or financial institution.
At the beginning of last year, a new type of bank fraud was detected. Criminals used a correspondent bank – namely the US Federal Reserve – to try to steal $950m from the Bank of Bangladesh. A correspondent bank is one involved in a transaction, but which is neither its ultimate source nor destination. In the event, the criminals got away with $81m. The sum has not been recovered and no one has been prosecuted yet. Since then, banks have subsequently become more vigilant and two similar hacking attempts of other banks were foiled in other countries.
But the incidents brought into question the security of SWIFT – not the network itself, but the interface software and the processes banks use when connecting to it. This prompted SWIFT to review its terms and conditions and in May 2016 it announced its CSP – aimed at improving security before banks connect to its network. In the autumn, the co-op revealed 16 mandatory and 11 recommended controls and imposed the June 2017 deadline for banks to have reviewed their practices. Compliance is from 1st January 2018. The controls are self-certified, but SWIFT can challenge or audit a bank’s submission.
Compliance is easier for some than others. Not only does it seem that many banks, particularly smaller tier 3 and 4 banks, have had their heads in the sand – according to the Global Trade Review, none of the trade finance heads it spoke to in October 2016 had heard of it – but there is also a shortage of resources to contend with. This is a problem both internally at the banks themselves, in terms of finance for new software and manpower to audit and review, and externally among consultants who will be asked to report on and certify banks’ claims. And the consequences of non-compliance, as already mentioned, could be catastrophic: without access to SWIFT, banks cannot participate in the global financial system and may go out of business.
SWIFT has three main elements to its program. Banks must secure and protect their environment, prevent and detect fraud in commercial relationships and continuously share information and collaborate to better prepare for future cyber attacks.
For me, the solution is obvious. SWIFT’s demands should be looked at alongside any other efforts a bank is making at fraud prevention. Admittedly, the SWIFT time-frames mean a bank must look sooner rather than later – but that can only be a good thing in terms of its future, reputation and medium to long-term profitability.
In this light, compliance for larger banks will be a box-ticking exercise – they will simply need to audit their current procedures and verify they meet SWIFT’s controls. For example, they will already have cyber-incident response plans and security training and awareness programs – both mandatory controls. But for smaller banks, it may mean introducing new systems and procedures.
Many tier 3 and 4 banks, for example, don’t have procedures to the level SWIFT expects, particularly those in emerging markets. Putting procedures such as training and incident-response plans in place could demand massive upheaval. And that’s assuming the banks will be able to identify the right areas – many have significant knowledge gaps and a shortage of specialist consultants.
But if banks turn to technology to address the new requirements they stand a much better chance of meeting both the deadline and SWIFT’s expectations. Not only that, by choosing the right technology they will also be able to address other concerns with regard to fraud – both internal and external.
Technology is the only way banks can maximize their prevent and detect capabilities. Relying on manual processes means the only way to scale up is to add manpower, and whenever humans are involved there will always be an element of risk – either as a result of mistakes or criminal activity. The stats are clear: some 90 percent of fraud can be traced back to phishing exercises and of the 10 percent balance, much of that is down to social engineering, where a fraudster tries to trick someone into giving them access credentials, for example.
A solution that captures and correlates data on behavior is especially effective against fraud as it can spot anomalies and irregularities in real time, learning as it goes along. It can also make sure that processes are completed – checks followed up, incidents escalated in line with regulations and controls followed. All the while, technology can log activity – something that SWIFT wants to see.
So by introducing the right technology to the process, banks can kill two birds with one stone. They can prepare for SWIFT’s new regulations and controls, and also improve their anti-fraud profiles. Out-of-the-box solutions such as NetGuardians’ FraudGuardian can almost be plug and play – particularly when a bank is already running on one of the supported digital platforms. But even for banks working with legacy systems, implementation is not overly onerous.
When the cost of non-compliance might well be going out of business, the return on investment in this area is incalculable. The reality of such a solution is cheap insurance against maximum risk. And the speed of implementation will allow banks to make the deadlines. But most important of all, being trusted or not by their peers could be the difference between in business and out of business.