If your bank connects to the SWIFT network, compliance with its Customer Security Programme (CSP) is mandatory. In 2016, attackers stole $81 million from the Bangladesh Bank by sending fraudulent SWIFT payment messages. The weak point was the security at the connected institution rather than SWIFT's own network, and SWIFT responded by creating the CSP, which requires every connected institution worldwide, Rwandan banks included, to implement a set of security controls and attest to its compliance annually. Non-compliance can lead your correspondent banks to restrict or end their relationship with you.
This guide covers the CSP framework, the mandatory controls most relevant to Rwandan banks, and what security testing is required as part of the attestation process.
What is SWIFT CSP?
The SWIFT Customer Security Programme is a security framework that all SWIFT network participants must follow. It consists of:
- Mandatory controls: A security baseline that all institutions must implement. Non-compliance must be disclosed.
- Advisory controls: Best practices recommended by SWIFT but not mandatory.
- Annual attestation: All institutions must attest to their compliance via the SWIFT KYC Security Attestation application each year, and since 2021 that attestation must be supported by an independent assessment (internal or external).
The framework is updated annually; the Customer Security Controls Framework v2026 (CSCF) contains 32 controls, 26 mandatory and 6 advisory. Controls are organised around three objectives: Secure your Environment, Know and Limit Access, and Detect and Respond.
The key mandatory controls for Rwandan banks
1. SWIFT environment protection (1.1) and restriction of internet access (1.4)
Both controls sit under the framework's first principle, restricting internet access and protecting critical systems from the general IT environment. Your SWIFT environment must be segmented from the general IT network. Internet access to SWIFT systems must be restricted or eliminated. This typically requires network architecture changes, specifically a dedicated SWIFT demilitarised zone (DMZ) with strict firewall rules.
2. Operating system privileged account control (1.2)
Accounts with administrative access to SWIFT systems must be tightly controlled. Privileged accounts should not be used for general email and internet browsing. Multi-factor authentication (MFA) is required for all privileged access to SWIFT components.
3. Virtualisation or cloud platform protection (1.3)
If SWIFT components run on virtualised infrastructure, the hypervisor and host operating system must be secured and access controlled separately from the SWIFT software layer.
4. Security updates (2.2)
SWIFT components and the underlying operating systems must receive security updates within defined timeframes. The CSCF specifies risk-based patching requirements, with critical security updates expected to be applied promptly.
5. Back office data flow security (2.4)
Data flows between SWIFT components and back-office systems must be identified and secured with access controls and encryption where appropriate. This control was advisory (2.4A) until CSCF v2026 made it mandatory; legacy direct back-office flows remain advisory for now.
6. Operator session confidentiality and integrity (2.6)
Operator sessions to SWIFT systems must be protected against session hijacking, man-in-the-middle (MitM) attacks, and unauthorised access.
7. Malware protection (6.1)
SWIFT terminals and connected systems must have up-to-date malware protection. This must be validated as part of the assessment.
8. Logging and monitoring (6.4) and cyber incident response planning (7.1)
Logging and monitoring of SWIFT activity is mandatory under control 6.4. Unusual transaction patterns, such as the anomalous activity seen in the Bangladesh heist, must trigger alerts. Control 7.1 requires a defined and tested cyber incident response plan to reduce the impact of real incidents.
Scope: what systems need to be secured?
SWIFT defines a "Secure Zone" encompassing all components involved in the SWIFT message flow:
- SWIFT interface components (Alliance Gateway, Alliance Access, SWIFT Connector)
- Workstations used to operate SWIFT software
- Authentication systems used for SWIFT operator access
- Back-office systems that receive or send data to SWIFT components
- Data stores containing SWIFT-related message files or logs
Independent assessment for CSP attestation
Since 2021, SWIFT has required every attesting user to back its attestation with an independent assessment of the mandatory controls, rather than rely on a pure self-assessment. That assessment can be performed by a qualified internal function that is independent of the team operating the SWIFT environment, or by an external assessor. It validates that the controls you have attested to are in place.
Where the independent assessment is conducted externally, it tends to carry more weight with correspondent banks, surfaces gaps an internal review may overlook, and aligns with the National Bank of Rwanda's (BNR) broader expectation of independent security testing. The formal attestation itself, and any sign-off your CSP governance requires, remains with your qualified assessor and your institution.
This is where penetration testing fits. A penetration test of the SWIFT Secure Zone produces the hands-on technical evidence that several mandatory controls (segmentation, privileged-access protection, operator-session integrity) are working as attested, rather than merely documented on paper. That evidence feeds directly into your assessment and attestation, but the assessor's conclusion stays with the assessor.
Penetration testing in SWIFT environments
The framework lists penetration testing as an advisory control (7.3A): testing of the SWIFT Secure Zone validates that the mandatory controls are working as intended. In practice, correspondent banks increasingly ask for evidence of penetration testing before approving a new relationship.
Penetration testing of SWIFT environments requires specific expertise: understanding of the SWIFT message flows, the Alliance Access/Gateway architecture, and the risk of testing live payment infrastructure without disrupting operations. We conduct SWIFT environment testing with careful scoping and scheduling to minimise operational risk.
Common CSP gaps in banking environments
- Insufficient network segmentation between SWIFT Secure Zone and general corporate network
- SWIFT operator accounts used for general business tasks (email, internet browsing)
- Delayed patch application on SWIFT components and host operating systems
- Weak MFA implementation on SWIFT operator access
- Insufficient logging: transaction logs not retained for the required period
- Missing or untested anomaly detection for SWIFT transaction activity
- Back-office data flows not fully documented or secured
Attestation deadline: SWIFT CSP attestation must be completed annually before the end of each calendar year. Non-compliant institutions are flagged to their correspondent banks. Start your assessment at least three months before your deadline to allow time for remediation.
How we can help
IMIZI Cyber provides penetration testing of the SWIFT Secure Zone: hands-on testing of the segmentation, privileged-access, and operator-session controls that sit at the centre of the CSP framework, scoped and scheduled to avoid disrupting live payment operations. The output is technical evidence, with proof-of-concept findings and prioritised remediation guidance, that your assessor and CISO can use to support the annual attestation. The formal CSP attestation and any required sign-off remain with your qualified assessor; we supply the offensive-security evidence behind it. Combined with our broader penetration testing services, this work supports your wider BNR security testing obligations. See also our guide on BNR cybersecurity requirements.