Swift CSP

What is the Swift CSP?

Swift runs the messaging network that banks and other financial institutions use to send payment instructions to one another. After a series of attacks in which criminals used compromised local systems to send fraudulent payment messages, Swift launched the Customer Security Programme (CSP) in 2016. It is mandatory for every institution that connects to the network.

At its heart is the Customer Security Controls Framework (CSCF), the security baseline every Swift user must meet for its own Swift-related infrastructure. Swift secures its own network; the CSP is about the part each user runs.

How are the controls organised?

The CSCF has mandatory controls, which every user in scope must implement, and advisory controls, which are recommended good practice and may become mandatory later. They sit under three objectives:

• Secure your environment: restrict internet access and separate critical systems from general IT, reduce the attack surface and vulnerabilities, and physically secure the environment.
• Know and limit access: prevent credentials being compromised, manage identities and separate privileges.
• Detect and respond: detect unusual activity in systems and transaction records, and plan for incident response and information sharing.

Swift aligns each control with recognised standards such as ISO/IEC 27002, PCI DSS, SOC 2 and the NIST Cybersecurity Framework.

Which controls apply to you?

That depends on how you connect. The CSCF defines five architecture types, from institutions that run their own Swift messaging interface on site to those that rely on a service bureau or a provider’s cloud connection. Swift provides a decision tree to identify yours, and product-specific security guidance for its own interfaces.

How does attestation work?

The CSP runs on a yearly cycle:

1. Each July, Swift publishes a new CSCF version, a year before it takes effect. New controls usually start as advisory, giving users up to 18 months to prepare.
2. Users implement the controls and have them checked by an independent assessment. This can be done internally by a second or third line of defence, such as risk, compliance or internal audit, or externally by an independent assessor.
3. Between 1 July and 31 December, users submit their attestation in Swift’s KYC Security Attestation (KYC-SA) application, stating their compliance with each applicable control and a remediation date for any gap. New joiners must attest before they go live.

What if you don’t comply?

Swift can report users that have no valid attestation, aren’t compliant with the mandatory controls, haven’t had an independent assessment, connect through a non-compliant service provider, or haven’t completed an external assessment Swift has asked for. Non-compliance is visible to the user’s supervisor. Counterparties can also ask to see an institution’s attestation through KYC-SA, and many use it in their own third-party risk checks before doing business.

Where does it fit?

For a bank, the CSP is one layer among several: national supervisors’ cyber rules, payments standards such as PCI DSS, and frameworks such as ISO/IEC 27001 or NIST CSF. Because the CSCF maps to those standards, evidence gathered for them can often support the Swift assessment, but the attestation itself must address each CSCF control as Swift defines it.