What’s new with SWIFT’s CSCF in 2021 and how best to tackle it?

Banks will no longer be able to self-assess their SWIFT controls although they can use an independent internal third party. Far better would be to seize the opportunity by working with an external adviser that understands the repercussions of adapting IT systems and knows the best vendors to work with, write Cheng Ie-Sun and Ho Siew Kei from Deloitte Malaysia.

Banks worldwide are grappling with changes to international payment platform SWIFT’s customer security controls framework (CSCF). While we can all be relieved that the deadline for implementing the new framework has been pushed back 12 months until 2021, there is still a lot to do to meet these complex and challenging changes and to set up regular, comprehensive reviews to ensure compliance is maintained even as systems are adapted.

SWIFT’s changes make additional controls mandatory and add some advisory ones – although in the medium term the latter may well become mandatory. All are designed to address better the evolving cyber threat landscape and make it harder for fraudsters to infiltrate the system following a number of high-profile frauds. SWIFT is also moving from self-assessment to independent assessment of compliance. These assessments can be done by an internal, independent team from, say, a bank’s Compliance or Internal Audit functions. But it would be far better to engage an external third party with broad experience of sector best practice. Here are some of the common challenges faced while performing these assessments.

Correct scoping

The first challenge is to correctly establish the scope of the assessment up front so that the assessors examine the technology, including firewalls, appropriately. For example, when assessing the SWIFT secure zone the team needs to look at access, both intended and actual.

One client had a general-purpose PC set up to be used for SWIFT operations and installed controls meant for dedicated operator PCs. During our assessment, the PC was interpreted as a dedicated operator PC and as such marked as non-compliant against some of the CSCF requirements. The client later clarified that the intention was for a general-purpose PC but with restrictive controls.

In another instance a client was unaware that some firewalls were part of the scope of assessment even though the CSCF states that any firewall protecting the secure zone is in scope.

Interpretating the CSCF controls

Another challenge is that successive assessment teams may come to different conclusions about the same SWIFT implementation. Each team may have their own interpretation of the CSCF controls and assessments are usually based only on a sample of the IT infrastructure. A subsequent review might look at a different sample and discover a non-compliance. In addition, it’s important to note that a finding not raised in a review is still valid in a subsequent review. Clients need to understand that one review sets no precedent for subsequent reviews.

A similar challenge arises with reviews of some mandatory and advisory controls. We have come across at least one bank that assumed some controls were the same. For example, when it met the mandatory controls for vulnerability assessments it assumed it had met the advisory controls for penetration testing as well. This is not the case. Vulnerability assessment and penetration testing are two different sets of controls. As external advisers, we were able to apply knowledge that we had accrued from working with many banks that is hard to find in-house to ensure the bank knows its position.

Complying to the CSCF

Banks’ IT Security functions need to realize how important their role is for CSCF compliance as well as for the security of the organization as whole. The CSCF should not be treated as a box-ticking exercise, but rather should be seen as an opportunity to improve the security position not only with regards to the critical SWIFT system but to the overall organization.

Importance of Fraud Detection

Strong fraud detection is vital for banks and is far broader than establishing security controls (for example, encryption, security hardening, privileged management, authentication, vulnerability management and penetration testing) to protect the SWIFT environment. Banks also need to think about preventive measures such as active monitoring.
While one particular IT control covers the importance of application backup and replication of business transactions to help during an investigation for fraudulent transaction, this is a post-incident activity. A far higher emphasis on preventive controls is needed, especially when it comes to business operations. Some advisory controls play to this yet we find banks still tend not to adopt them. This is a mistake on two fronts – as already mentioned, the advisory may well become compulsory and fraud burnishes a bank’s reputation. Let’s look at two: 2.9a and 2.11a.

Two advisory business controls

Both are advisory, but both are also best practice. Banks wanting to go the extra mile to protect themselves and their clients should be looking at and adopting best practice.

The CSCF has some implementation guidelines around this and we are starting to see that where clients have manual processes to detect fraud they are moving towards automation for fraud detection.

A software solution

In this vein, we advise banks on how to use the changes required by SWIFT to the benefit of the security of the whole organization – and indeed the banking chain - year after year. While SWIFT deals only with international transactions, by extending monitoring to include domestic transactions, where the risk of fraud is far higher, it is possible for a bank to have one active preventative system to cover all transactions. It is a logical, easy insurance policy and banks would do well to look at vendors that offer software that monitors both.

We work closely with fraud mitigation specialist NetGuardians, which supplies intelligent artificial intelligence-driven software that monitors every transaction through a bank. Alexandre Guidou, Business Development Manager at NetGuardians, explains that the software works by building detailed profiles of every user – bank employees and bank clients. “When a parameter linked to a transaction doesn’t fit the profile, the software raises an alarm so that the transaction can be investigated. This means that when organizations such as SWIFT change their controls, the bank’s fraud mitigation program is unaffected.”

For banks this is important. Next year the messaging systems used by SWIFT that govern the ways banks transfer funds are changing. But banks running NetGuardians fraud mitigation software can rest assured that they won’t be affected.

In addition, it is worth noting that this type of AI-driven software is far more affective at spotting and stopping fraud. Banks have found NetGuardians spots up to 18 percent more fraud compared to the traditional rule-based systems. It also raises fewer false alerts – up to 83 percent fewer. This means the bank can perform highly accurate fraud mitigation but still maintain a good customer experience whilst reducing the amount of investigation work that has to be done. Furthermore, NetGuardians’ software is proven to spot new fraud types and spot more fraud than rules-based engines alone, giving far better, more cost-effective fraud protection.

Banks have the opportunity to use the SWIFT changes to ramp up their fraud mitigation not just for international SWIFT transactions but across their whole business. By working with an experienced third party and a leading fraud-mitigation vendor, they can ensure they make the most of the opportunity.