SWIFT CSP questions, answered.

The Customer Security Programme (CSP) is SWIFT's programme to strengthen security across its user community. Its Customer Security Controls Framework (CSCF) sets the controls each user must implement and attest to every year. SWIFT updates the framework annually.

Thirty-two: 26 mandatory and 6 advisory. Which apply to you depends on your architecture type. For example, an A1 user has 25 mandatory controls in scope, while a B user has 16.

• Control 2.4 is mandatory. Back Office Data Flow Security moves from advisory, phased: bridging servers, flows between them and new direct flows are mandatory; long-standing direct flows stay advisory, with full coverage tentatively planned for 2028.
• Customer connectors in mandatory scope. Client-side endpoints such as API, middleware and file transfer clients are now in mandatory scope of many controls, so some former B users must attest as A4.
• Clarifications. Hardening guidance names WMI and PowerShell, privileged Alliance security officer accounts are expected to use MFA, containers are treated as co-hosted by default, and awareness training now cites AI-enabled threats such as deepfakes.

I cover these in more detail in SWIFT CSCF v2026: what has changed.

Mandatory controls must be implemented and are the baseline of your attestation. Advisory controls are good practice that you can choose to attest to; SWIFT often moves advisory controls to mandatory in later versions, as it has with 2.4.

• A1: you own the communication interface, usually with your own messaging interface.
• A2: you own a messaging interface, but the communication interface belongs to a service bureau, Group Hub or SWIFT.
• A3: no interface of your own; a SWIFT connector links you to a provider or SWIFT service.
• A4: no SWIFT-labelled software, but you run your own customer connector, such as middleware, file transfer or an API application.
• B: nothing SWIFT-related runs in your environment; staff use a browser or GUI hosted by a provider or SWIFT.

The scoping tool helps you identify yours.

Attest under the most comprehensive architecture type found across your environments, where A1 is the most comprehensive and B the least.

Only in narrow circumstances: it must be unable to create, submit, cancel or modify transactions, must not use business-signature functions, and must hold no credentials entitled to do so, all backed by a documented risk assessment. If it can touch payments, it is in scope.

Yes. Under SWIFT's Customer Security Controls Policy, your attestation must be supported by an independent assessment. It can be carried out by an independent internal function, such as internal audit, or by an external assessor.

The v2026 attestation window runs from July 2026 to 31 December 2026, through the KYC Security Attestation (KYC-SA) application. Starting the assessment early leaves time to fix gaps before you attest.

Your attestation status can be shared with counterparties through KYC-SA, and SWIFT can report users who fail to attest, or who are non-compliant, to their supervisors. An honest attestation with a remediation plan is far better than a late or inaccurate one.

Yes. Control 2.8 requires critical outsourced activities to be protected to CSCF standards, and a provider that hosts or operates your own SWIFT components is treated as an outsourcing agent. You remain accountable for your attestation.