If your bank connects to the SWIFT network, the Customer Security Programme (CSP) is not optional. In 2016, attackers stole $81 million from the Bangladesh Bank by sending fraudulent SWIFT payment messages, a case that exposed that SWIFT itself was not the vulnerability; the security controls at connected institutions were. In direct response, SWIFT created the Customer Security Programme and mandated that all connected institutions worldwide, including Rwandan banks, must implement a set of security controls and attest to their compliance annually. Non-compliance can result in your correspondent banks restricting or terminating your SWIFT connectivity.
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: 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. 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. Restrict internet access and protect critical systems from general IT environment (1.1)
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 DMZ with strict firewall rules.
2. 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 is required for all privileged access to SWIFT components.
3. Virtualisation platform security (1.3)
If SWIFT components run on virtualised infrastructure, the hypervisor and host OS 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. Backoffice data flow security (2.4A)
Data flows between SWIFT components and back-office systems must be identified and secured with access controls and encryption where appropriate.
6. Operator session confidentiality and integrity (2.6)
Operator sessions to SWIFT systems must be protected against session hijacking, 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 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 actually 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 BNR's 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
SWIFT CSP best practices recommend penetration testing of the SWIFT Secure Zone to validate that mandatory controls are working as intended. In practice, any serious correspondent bank will expect 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.
CSP gaps common in our banking-sector engagements
- 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 3 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.