About SWIFT

Founded in the 1970s and headquartered in Belgium, SWIFT (Society for Worldwide Interbank Financial Telecommunication) emerged as an approach to revolutionise global financial communication. Its inception stemmed from the collaboration of 239 banks across 15 nations, united to tackle the challenge of cross-border payment communication. The original SWIFT services comprised a messaging platform, message validation and routing computer system, and standardised message formats. These standards facilitated universal comprehension across linguistic and system barriers, enabling seamless transmission, receipt, and processing of communications among users.

Need for Security

Many services require seamless operability, rapid responsiveness, and effective security measures. The SWIFT messaging system, in particular, necessitates protection against unauthorised alterations, sustained availability, confidentiality protocols, and the capacity for comprehensive activity tracking.

Regrettably, the SWIFT infrastructure fell victim to targeted attacks in 2015 (TPBank in Vietnam and Banco del Austro in Ecuador) and in 2016 (affecting entities like Akbank in Turkey and the Central Bank of Bangladesh), resulting in substantial financial losses. In response, SWIFT initiated concerted efforts to strengthen defences, implementing detection mechanisms and corrective actions to forestall future breaches.

In the wake of these incidents, SWIFT introduced the SWIFT Customer Security Controls Framework (CSCF) in 2017. This framework outlines a comprehensive suite of protocols to protect the SWIFT network against potential vulnerabilities. Notably, these protocols undergo periodic updates, ensuring their efficacy in the face of evolving threat landscapes and technological advancements. The rising tide of cyber-attacks targeting SWIFT users compelled SWIFT to respond to this growing problem. The answer was the launch of the Customer Security Programme in 2016.

What is SWIFT CSP?

The Customer Security Programme (CSP) is dedicated to maintaining cybersecurity hygiene among all its users, mitigating the risk of cyber-attacks, and minimising the financial fallout from fraudulent activities. Since its inception, the CSP has undergone continuous refinement, propelled by the relentless march of digital transformation and the escalating sophistication of cyber threats faced by SWIFT users.

The Modus Operandi, Tactics, Techniques, and Procedures (TTPs) employed by cyber adversaries have evolved with institutions' efforts to strengthen their security measures. While individual users are responsible for safeguarding their environments and SWIFT access points, the CSP acts as a vital resource, extending customer support and fostering collaborative efforts across the industry to combat cyber fraud.

The Customer Security Controls Framework (CSCF) is a centrepiece of the CSP which serves as a unified platform aimed at maintaining the security posture of customers and the integrity of the financial ecosystem. Embracing a blend of mandatory and advisory measures, the SWIFT CSCF draws upon esteemed industry standards like NIST, ISO 27000, and PCI-DSS.

The 2024 security controls are designed around three main objectives supported by eight key security principles. The three objectives are:

1. Secure Your Environment
2. Know and Limit Access
3. Detect and Respond

These objectives represent the top-level framework for ensuring security in the users’ environment. The principles clarify the primary areas of focus within each objective. The first two principles share common controls and are therefore grouped. These principles include:

1. Restrict internet access and segregate critical systems from the general IT environment.
2. Reduce attack surface and vulnerabilities.
3. Physically secure the environment.
4. Prevent compromise of credentials.
5. Manage identities and segregate privileges.
6. Detect anomalous activity in systems or transaction records.
7. Plan for incident response and information sharing.

The document outlines 32 security controls; 25 mandatory and 7 advisory controls, all in line with these objectives and principles. Mandatory controls form the basis of security, setting a non-negotiable baseline for all SWIFT infrastructure users. These controls are pivotal in defence against prevalent threats, ensuring a tangible enhancement in security readiness. Concurrently, advisory controls are rooted in industry best practices which serve as guiding principles that SWIFT recommends for implementation.

Given the constantly changing cyber-threat landscape, these controls are crucial for addressing specific cybersecurity vulnerabilities that SWIFT users face. Each security control is accompanied by documentation of the most common risks it aims to mitigate. By addressing these risks, the controls strive to prevent or reduce undesirable and potentially fraudulent business outcomes, such as:

1. Unauthorised sending or modification of financial transactions.
2. Processing of altered or unauthorised SWIFT inbound transactions (i.e., received transactions).
3. Business conducted with an unauthorised counterparty.
4. Breach of confidentiality (of business data, computer systems, or operator details).
5. Breach of integrity (of business data, computer systems, or operator details).

In the long run, enterprise-level risks such as financial, legal, regulatory, and reputational risks are brought up by possible outcomes. 

SWIFT’s Customer Security Controls Policy (CSCP)

SWIFT’s Customer Security Controls Policy (CSCP) mandates that users' Business Identifier Codes (BICs) may be requested to ensure accuracy in their KYC-SA attestations. This involves independent external assessment to verify compliance with controls. Failure to undergo assessment violates the CSCP, leading to potential reporting to relevant authorities. Users notified for assessment can communicate valid reasons for non-compliance to SWIFT.

Architecture Types in SWIFT CSCF

Assessments are based on architecture types. SWIFT has five user architectures: A1, A2, A3, A4, and B.

1. Architecture A1: In this architecture, users retain ownership of the communication interface which encompasses the messaging aspect as well. Even those users who solely possess a communication interface without a messaging one fall under Architecture A1.
2. Architecture A2: Users hold ownership of the messaging interface while the license for the communication interface lies with a service provider, be it a service bureau, SWIFT6, or a Group Hub.
3. Architecture A3: Employs a SWIFT connector situated within the user environment. Its purpose is to streamline application-to-application communication either with an interface at a service provider or SWIFT services like Alliance Cloud or Alliance Lite2, devoid of any specific interface, be it messaging or communication.
4. Architecture A4: Known as the Customer Connector, this architecture comes into play when a user lacks a SWIFT footprint but utilises a server within their environment, running a software application such as a file transfer solution or middleware server. This setup facilitates external application-to-application connections with SWIFT-related applications or solutions at service providers like service bureaus, Business Connect providers, Lite2 Business Application providers, or Group Hubs.
5. Architecture B: Architecture B involves setups where there's no local presence of SWIFT-specific infrastructure components. Users either access SWIFT messaging services through a service provider's GUI application (user-to-application), or their back-office application communicates directly with the service provider using APIs, middleware clients, or secure file transfer clients independently, without transmitting transactions to SWIFT services.

SWIFT CSP Assessment and Compliance

SWIFT requires external assessments to cover all mandatory controls for the user's architecture type by the end of the year. They inform chosen parties in the first quarter, with assessments due by December 31st, unless stated otherwise. This verification must be done annually, between July and December each year. Any differences in compliance status from the latest attestation require a new submission within three months of the assessment report.

New members must complete their attestation before joining the SWIFT network. To increase the accuracy of their attestations, all SWIFT users are required by the SWIFT Independent Assessment Framework (IAF) to conduct a Community Standard Assessment. Additionally, these attestations must pass an independent examination mandated by SWIFT.

SWIFT CSPv2024 Changes and Updates

SWIFT Customer Security Programme (CSP) aim to enhance defences against financial attacks and fraudulent activities. Below is an overview of the timeline and key changes introduced over the years, with the latest updates in SWIFT’s Customer Security Controls Framework (CSCF) version 2024:

Introduction of New Mandatory Control

• 2.8 Outsourced Critical Activity Protection: This set of controls, previously advisory, is now mandatory. It focuses on preventing new vulnerabilities when outsourcing critical activities to third parties or service providers.

Expansion of Advisory Controls

• 2.4A Back Office Data Flow Security: The control of this scope has been expanded to facilitate a phased promotion to mandatory status. It now requires identifying:
  • Servers that bridge the back office and the user’s secure zone.
  • Mechanisms that secure data flow exchanges, either through end-to-end data protection or by securing each flow segment, including the bridging servers.
  • Although 2.4A is still advisory, SWIFT encourages early identification and assessment of these flows and assesses their security posture.

Additional Mandatory Scope Changes

• 2.3 System Hardening: This control includes comprehensive guidance on USB port protection and moves the optional application which allows listing from controls 1.1, 1.5, and 6.2 to control 2.3.
• 2.9 Transaction Business Controls: This control now explicitly states that business controls can be performed outside the secure zone.
• 3.1 Physical Security: The scope of this control has been expanded to include recommendations on the sanitisation of disposed or reassigned equipment and aligns token supervision and secure storage guidelines with controls 3.1 and 5.2.
• 7.4 Scenario-based Risk Assessment: Now explicitly allows reliance on existing Information Security Risk Management processes.

Consistency Updates and Clarifications

Several controls have been updated for clarity and consistency, including:

• 2.1 Internal Data Flow Security
• 2.2 Security Updates
• 2.4 Back Office Data Flow Security
• 3.1 Physical Security
• 5.2 Token Management
• 5.4 Password Repository Protection
• 6.2 Software Integrity
• 6.4 Logging and Monitoring

Additionally, updates were made to Appendices D, E, and F.

These changes reflect SWIFT’s commitment to continually enhancing security measures and ensuring protection against evolving threats in the financial sector.


Prajeeta Parajuli

‍