Everything you need to know about the Updated SWIFT Customer Security Controls Framework

Fraud and Financial Crime

James Richardson

James Richardson

Oct 15, 2018

It’s been nearly 2 years since the launch of the original Customer Security Programme (CSP) and yet everything we thought we knew about it has changed, including the name, which is now the SWIFT Customer Security Controls Framework.

It’s not a surprise, really. Payment fraud is an ever-changing threat and it’s imperative that organisations keep pace if they’re to protect themselves. The industry understood from the beginning that this would be an organic initiative that changed as needs arose, so with that in mind, let’s take a look at what’s new...

To begin with, it’s good news that the foundation of the program is still the same, centered around the three key security objectives of “secure your environment,” “know and limit access” and “detect and respond.” It’s a practical approach to the challenge of defending against fraud and will make it easier for companies to organize their efforts to comply. It’s also very helpful, because according to SWIFT:

All users need to confirm full compliance with the mandatory security controls V1 by re-attesting before their current attestation expires on 31 December 2018.”

Yes, you read that correctly. You have to comply with the 2018 version of the program by 31 December of this year before you can move on to complying with the 2019 version (attestation deadline December 2019).

If you haven’t attested yet, now would be a good time to panic. The time to bury your head in the sand about this issue has run out. Find out where your organisation stands and put measures in place immediately to make sure you meet that first attestation deadline.

Now, back to the SWIFT Customer Security Controls Framework v2019. Here’s an overview of the most important things you need to know about the changes to the requirements.

Three of the previous advisory controls are now mandatory

(bringing the total number of mandatory controls to 19)

  1. Falling under "reduce attach surface and vulnerabilities," control 2.6 relates to operator session confidentiality and integrity and requires organisations to protect the confidentiality and integrity of interactive operator sessions that are connecting to the local SWIFT infrastructure 
  2. Also under that section is control 2.7 which refers to vulnerability scanning and imposes the requirement to identify known vulnerabilities within the local SWIFT environment by implementing a regular vulnerability scanning process. Organisations are also required to act upon the results of those scans. 
  3. Under the “manage identities and segregate privileges” section is control 5.4 related to physical and logical password storage. This control simply requires the protection of physically and logically stored passwords.

Two new advisory controls have been added

(making the total number of advisory controls 10)

  • Advisory control 1.3A relates to virtualisation platform protection. Basically, the virtualisation platform and virtual machines that host SWIFT related components must be secured to the same level as physical systems. 
  • Advisory control 2.10A, which refers to application hardening, requires organisations to reduce the attack surface of SWIFT-related components by performing application hardening on the SWIFT-certified messaging and communication interfaces and related applications.

Consequences of not attesting are no longer an idle threat

In the original CSP the language related to the consequences of not attesting was suggestive, stating that SWIFT “reserved the right” to report the names of organisations that were not in compliance. In the 2019 version of the requirements however, it’s clear that SWIFT are no longer messing around and the language used – “SWIFT will inform of non-compliance” – reflects that shift in approach.

On the surface, these changes represent just a small portion of the overall complexity the SWIFT Customer Security Controls Framework entails. That’s a relief for organisations that have met the previous attestation requirements. Regardless or your organisations’s status, however, there’s some basic guidance everyone can benefit from as December 2018 approaches and December 2019 looms large on the horizon.

How to prepare for the SWIFT Customer Security Controls Framework

  1. Don't delay  Meeting these requirements is not an option and the program isn’t going away so there’s no sense in putting it off. The time is now to put a comprehensive security strategy into place that not only meets SWIFT’s requirements but also protects your organisation from future payment fraud threats.
  2. Don't make compliance more complicated than it needs to be   Yes, the thought of meeting these 19 mandatory controls (as well as the 10 advisory ones if you’re doing the job properly) is daunting – even terrifying if you’re tackling it alone. But it doesn’t have to be that way. The best security solutions are simple to adopt and there are some readily available technology firms that can handle all of the heavy lifting of the attestation process for you – including translating it into plain English so you actually know what to do.
  3. Do think about security as a long term initiative   Sure there’s the immediate need to comply with the SWIFT Customer Security Controls Framework and there’s a hard deadline associated with that. But protecting your organisation against fraud is not something that can be dealt with once and crossed off a to-do list. True payment fraud protection is a marathon, not a sprint. Look to implement a solution that will insulate your organisation from change, offer the best fraud protection, and help you comply all at the same time. Things to consider as you evaluate solutions would include the ability to conduct real-time user and transaction monitoring, look holistically across multi-payment types and the ability to hold payments if something is wrong.

According to the 2018 AFP Payments Fraud and Control Survey Report, 78% of companies were targets of payment fraud last year –and that statistic is only getting worse. It’s time to face the fact that neither fraud nor the SWIFT Customer Security Controls Framework is going away. Put processes and solutions in place to protect your organization once and for all, while also setting yourself up to easily meet future SWIFT requirements.

James Richardson

Posted by

James Richardson

James Richardson has 15+ years’ experience in payments, working with FIs and Corporates to secure critical payments and reduce fraud risk. James is Head of Market Development, Risk & Fraud, for Bottomline Technologies.
Browse all posts
footer curve