SWIFT CSP 2026: Complete Guide for Bangladesh Banks

What is the SWIFT Customer Security Programme?

The SWIFT Customer Security Programme (CSP) was launched in 2017 as SWIFT's response to a series of high-profile cyberattacks targeting SWIFT-connected financial institutions. The programme establishes a common security baseline for all institutions using the SWIFT network, regardless of their size, geography, or architecture type.

At its core, CSP is built around the Customer Security Controls Framework (CSCF) — a set of mandatory and advisory controls that every SWIFT user must implement and attest to annually. The current version, CSCF v2025, defines 25 mandatory controls and 7 advisory controls, organised under three overarching security objectives: Secure Your Environment, Know and Limit Access, and Detect and Respond.

Every year, SWIFT-connected institutions must complete a self-attestation through the KYC Security Attestation (KYC-SA) application, confirming their compliance status against the mandatory controls. Since 2021, SWIFT has required that all attestations be supported by an independent assessment — either by an external assessor or an internal audit function that is independent of the first line of defence. This effectively means that most banks engage a qualified third-party assessor to validate their compliance.

For Bangladesh's banking sector, where over 60 banks maintain SWIFT connectivity for correspondent banking, trade finance, and treasury operations, CSP compliance is not optional. It is a condition of continued access to the SWIFT network and a regulatory expectation.

CSCF v2025 — What Changed for Bangladesh Banks

SWIFT updates the CSCF annually, typically publishing the new version in July for enforcement the following year. Each update may reclassify controls (moving advisory controls to mandatory status), refine implementation guidance, or introduce entirely new control areas in response to emerging threats.

CSCF v2025 maintains the established structure of 25 mandatory and 7 advisory controls but includes updated implementation guidance for several control areas, particularly around transaction screening, software integrity, and operator session management. The framework also continues to refine requirements based on architecture type.

Architecture Types and Applicability

SWIFT defines five architecture types — A1, A2, A3, A4, and B — based on how an institution connects to the SWIFT network and where SWIFT-related components are deployed. The architecture type determines which mandatory controls apply and, in some cases, the depth of implementation required.

Most Bangladesh correspondent banks operate under architecture types A1 (running SWIFT infrastructure on-premises with a local SWIFT Alliance interface) or A2 (using a shared infrastructure model). Understanding your architecture type is the first step in any SWIFT CSP assessment, as it directly determines your control scope.

For full details on the CSCF framework structure, refer to the official SWIFT Customer Security Programme documentation.

Bangladesh Bank's Expectations on SWIFT Security

Bangladesh Bank's ICT Security Guidelines for Banking and Financial Institutions reference SWIFT security as part of the broader information security governance framework. While Bangladesh Bank does not mandate a specific SWIFT CSP assessment methodology, it expects all supervised institutions to maintain current SWIFT CSP attestations and to demonstrate compliance during supervisory inspections.

The context for this expectation is well understood within the sector. The 2016 Bangladesh Bank cyber heist — in which attackers exploited the SWIFT messaging system to transfer $81 million from the central bank's account at the Federal Reserve Bank of New York — remains one of the most significant cyber incidents in global banking history. This event was a direct catalyst for SWIFT launching the CSP programme itself.

Bangladesh is not alone in treating SWIFT CSP compliance as a regulatory imperative. Across Asia-Pacific, central banks and financial regulators — including the Monetary Authority of Singapore (MAS), Bank Negara Malaysia (BNM), the State Bank of Vietnam (SBV), Bangko Sentral ng Pilipinas (BSP), Nepal Rastra Bank (NRB), and the Central Bank of Bahrain (CBB) — all expect or explicitly require SWIFT-connected institutions under their supervision to maintain current CSP attestations.

For Bangladesh banks with correspondent banking relationships, a current attestation is increasingly a prerequisite for maintaining those relationships. Counterparty banks — particularly those in Singapore, Europe, and the United States — routinely review SWIFT CSP attestation status as part of their due diligence process. To understand how SWIFT security requirements align with broader banking industry compliance obligations, see our industry guide.

The 25 Mandatory Controls — An Overview by Objective

The CSCF organises its 25 mandatory controls under three security objectives, each addressing a distinct layer of the institution's SWIFT environment security posture.

The first objective — Secure Your Environment — typically accounts for the largest share of remediation effort, as it covers network segmentation, patching, hardening, and data flow controls within the institution's SWIFT secure zone. For a detailed breakdown of every mandatory and advisory control with architecture-type applicability, refer to our companion article on SWIFT CSP mandatory vs advisory controls.

Many of the mandatory controls share conceptual overlap with ISO 27001 certification requirements — particularly around access control, logging, incident response, and asset management. Institutions that maintain an ISO 27001-certified ISMS often find they have a significant head start on SWIFT CSP compliance, though the SWIFT controls are more prescriptive in several areas.

The Annual Attestation Process: Step by Step

The SWIFT CSP attestation follows a structured annual cycle. Understanding each stage helps institutions plan their assessment engagement and avoid the last-minute compression that leads to incomplete submissions.

The Five-Stage Attestation Cycle

Stage 1 — Framework Release: SWIFT publishes the updated CSCF (typically in July) for the following year's attestation cycle. This gives institutions approximately five months to review changes before the assessment window opens.

Stage 2 — Scoping and Gap Assessment: The institution (or its external assessor) determines the architecture type, identifies the applicable mandatory controls, and conducts a gap assessment against current implementations.

Stage 3 — Remediation: Any identified gaps are remediated. This may involve configuration changes, network segmentation adjustments, policy updates, or technology deployments.

Stage 4 — Independent Assessment: A qualified assessor validates compliance against all applicable mandatory controls. The assessor produces a detailed report documenting the assessment scope, methodology, findings, and compliance status for each control.

Stage 5 — KYC-SA Submission: The institution submits its attestation through the SWIFT KYC-SA application before the 31 December deadline. The attestation records the compliance status for each mandatory control and is visible to counterparty institutions.

EIC's 7-Step Assessment Methodology

EIC's methodology expands on this five-stage cycle with additional rigour at the scoping and validation stages. Our seven steps are: (1) Architecture Type Determination, (2) Control Scope Mapping, (3) Documentation Review, (4) Technical Evidence Collection, (5) Control Validation and Testing, (6) Findings Report and Remediation Guidance, and (7) Attestation Support and KYC-SA Submission Assistance.

This methodology typically completes in 8-12 weeks from engagement to KYC-SA submission. For institutions beginning their first independent assessment, we recommend starting the engagement no later than August to allow adequate time for remediation. Learn more about our SWIFT CSP assessment service.

Consequences of Non-Compliance or Late Attestation

SWIFT's enforcement mechanism operates primarily through transparency. Every institution's attestation status — including whether they attested on time, which controls were marked as compliant, and which were flagged as non-compliant — is visible to their counterparty institutions through the KYC-SA application.

This means that a bank's correspondent banking partners can see whether the institution has submitted its attestation, whether it was submitted on time, and whether any mandatory controls were marked as non-compliant. In practice, this visibility creates significant commercial pressure.

Correspondent banks — particularly those in tightly regulated jurisdictions such as Singapore, the UK, and the United States — are required by their own regulators to conduct ongoing due diligence on counterparty risk. A missing or late SWIFT CSP attestation, or one that shows non-compliance with mandatory controls, may trigger enhanced due diligence, restricted messaging limits, or — in severe cases — suspension of correspondent banking relationships.

SWIFT itself may also report persistent non-compliance to the institution's local financial regulator. For Bangladesh banks, this means Bangladesh Bank would be notified — a development that no institution wants to trigger during routine supervisory engagement.

The practical consequence is straightforward: a current, compliant attestation protects the institution's access to international correspondent banking networks. A missing or non-compliant attestation introduces risk to those relationships — risk that is entirely avoidable through timely assessment and remediation.

How Long Does a SWIFT CSP Assessment Take?

Based on EIC's experience across 15+ SWIFT CSP assessments in Bangladesh, Singapore, Malaysia, Vietnam, Philippines, Bahrain, and Nepal, a typical assessment engagement takes 8-12 weeks from kickoff to KYC-SA submission readiness.

Phase Breakdown

Weeks 1-2: Scoping and architecture type determination. This includes identifying all SWIFT-related infrastructure components, confirming the architecture type, and mapping the applicable control set.

Weeks 3-4: Documentation review and gap assessment. The assessor reviews existing policies, procedures, network diagrams, and configuration documentation against each applicable control.

Weeks 5-8: Technical validation and evidence collection. This is the most intensive phase, involving on-site or remote review of system configurations, access controls, network segmentation, logging infrastructure, and incident response capabilities.

Weeks 9-10: Findings report and remediation guidance. The assessor delivers a detailed report documenting the compliance status of each control, any gaps identified, and recommended remediation actions.

Weeks 10-12: Remediation validation and attestation support. After the institution addresses any identified gaps, the assessor validates the remediation and supports the KYC-SA submission process.

Institutions with mature security environments and prior-year assessments often complete the process in 8 weeks. First-time assessments, or those with significant remediation requirements, may extend to 12 weeks or slightly beyond. The key variable is the institution's remediation capacity — the assessment itself is well-defined, but remediation timelines depend on the institution's internal resources and change management processes.

To discuss your institution's specific timeline requirements, learn more about our SWIFT CSP assessment service or contact us directly to schedule a scoping call.