Understanding the CSP
Following the 2016 Bangladesh Bank heist, Swift introduced the CSP — not a one-time fix, but a cycle every Swift user repeats every year:
The annual CSP cycle* Step 01 alone is a recurring challenge, every cycle — see Scoping.
In 2016, the Central Bank of Bangladesh fell victim to a historic cyber-heist: attackers moved funds through the Swift network in an attempt to steal a sum that would become one of the largest cyber-heists in banking history. While a significant portion was recovered, a substantial amount could not be secured. As the funds were transferred through the financial network, Swift suddenly found itself in the spotlight — its reputation suffered significantly, and trust in the network was no longer unconditionally guaranteed.
The CSP mandates that every participant actively contributes to the security of the ecosystem and strengthens global trust in financial transactions. Consequently, every Swift user (BIC holder) wishing to send messages into the network must confirm through the CSP that minimum security requirements are met. Swift users who only receive messages — for example, bank statements — are equally required to perform an attestation.
All Swift users — and thus all participants in the Swift network — must perform an annual attestation. This is completed within the Swift KYC-SA portal. The basis for confirming compliance is the currently valid Customer Security Control Framework (CSCF).
Every Swift user is obligated to submit an attestation, regardless of the result or the architecture type. This is a contractual obligation derived from the Terms & Conditions that every Swift user agrees to when applying for a BIC.
The CSCF is typically published by Swift in July or August and comes into effect on January 1st of the following year. It describes the respective architecture types and the components and controls relevant for the assessment or audit. The document is comprehensive and accounts for many different configurations — supplemented by three additional documents.
The actual core of the CSP: a set of mandatory and advisory security controls for your Swift environment, revised annually. Every control is built around three objectives — secure your environment, know and limit access, detect and respond — and each one is defined by a control objective, the components it covers, and the specific risk it addresses.
Supporting documents
Describes all formalities an assessment must meet to be recognised as valid — timing, internal vs. external scope, assessor qualifications, and reporting obligations.
Covers which service providers are considered critical and in scope, how their audits must be conducted, and where administrative burden can be reduced.
Answers frequently asked questions and clarifies specific scenarios — a vital source, since the CSCF may already be several months old at assessment time.
Swift officially recognises three assessment types: Self-Assessment, Community-Standard Assessment, and Swift-Mandated External Assessment. Only the latter two are independent — Self-Assessment still exists as an option in KYC-SA, but leads straight to a non-compliant status.
Self-Assessment is performed by your own first line of defence, with no independent review. It's still selectable in KYC-SA — but it is automatically treated as non-compliant, visible to your counterparties.
Exception: BICs declared as "Receiving-only" — meaning they only receive messages, such as bank statements, and never send into the network — are considered compliant even without an independent assessment. A yearly attestation is still required.
An independent, qualified external assessor or auditor reviews the Swift user's setup.
An independent and qualified internal department — such as Internal Audit — conducts the assessment.
A combination of external and internal: led by an external CSP auditor, supported by the internal department, aimed at reducing effort and cost.
Swift reserves the right to mandate an external independent assessment for a randomly or risk-selected sample of users, regardless of what assessment type they previously used.
Swift offers its own certification, but this is expressly not a prerequisite. What Swift does require: recent, relevant cyber-security experience — a pure audit qualification, without cyber-security substance, is explicitly not sufficient on its own.
One more distinction Swift makes explicitly: the CSP calls for an assessment, not a full audit — a lighter, point-in-time review of control design and implementation, not a multi-month audit engagement with formal assurance sign-off.
There are various architecture types that can be determined using a Swift decision tree. An experienced CSP assessor can identify these relatively easily — it mainly requires information on how the technical connection to the Swift network is implemented. Identifying the individual components in scope, however, is considerably more complex, and is where most avoidable project effort is lost.
Swift also allows existing certifications — such as ISO 27001 — to be taken into account. Recognition is subject to certain conditions but can lead to a significant reduction in audit workload.
Your compliance status is displayed in the KYC-SA portal and is visible to all Swift partners. Should a user be non-compliant, Swift will not immediately disconnect them from the network — but reserves the right to report the status to the relevant regulatory authorities.
Banks are also obligated to check their counterparties for compliance. In case of doubt, this can lead to partner banks requesting explanations or questioning the business relationship altogether.
There are hundreds of pages of documentation to read and understand. Swift has written these documents for a wide variety of company types and Swift users — but for you, exactly one scenario applies. Errors in determining the architecture type or the components in scope lead to an incorrect project scope, and potentially unnecessary additional effort.
Swift's own published guidance estimates typical assessor effort at 17–23 person-days, depending on architecture type — that's specialist time, separate from the internal effort your own team spends supporting the assessment.
Feedback from customers who assess internally suggests effort of several weeks per year — and the wrong scope may still be set, because components were incorrectly included or the documentation was misunderstood.
Depends on assessor experience and organisational maturity. On average, our clients need only about 2–3 days of internal effort, as we work toward the result in a targeted, efficient way using a proven audit approach.