SWIFT Customer Security Controls Framework (CSCF)

Why does it matter?

The CSCF is the control baseline behind Swift messaging, and the attestation is visible to the institutions that exchange messages with you. Swift's Customer Security Controls Policy requires each attestation to be independently assessed, and a failure to perform the assessment can be reported to supervisors and is shown to counterparties in KYC-SA. A bank, corporate or service bureau that cannot show the mandatory controls and an independent assessment of them therefore has a visible gap with every counterparty.

Key benefits include:

• One baseline for every user

CSCF v2026 sets 32 controls, 26 mandatory and 6 advisory, under three objectives and seven principles.

• Scope that fits the setup

Architecture types A1, A2, A3, A4 and B decide which controls are mandatory for a given user.

• Independent assurance

Attestations are assessed internally, externally or by a mix of both, and an assessor with the CSP Certified Assessor status earns a distinct label in KYC-SA.

• Counterparty visibility

Published attestations are visible to counterparties once the user grants access, so the result is a trust signal as well as a requirement.

• Predictable change

A new version appears each July, and new mandatory controls normally start as advisory, which gives users time to prepare.

How does it work?

Start by choosing the architecture type that matches the Swift setup. A1 users own the communication interface, A2 users own the messaging interface but not the communication interface, A3 users run a Swift connector such as Alliance Cloud, A4 users have no Swift footprint but run a customer connector such as middleware or file transfer, and B users have no local Swift infrastructure and reach messaging through a service provider's interface. The attestation covers all in-scope components in live, back-up and disaster recovery environments.

Assess the setup against every mandatory control for that architecture type. Advisory controls are optional to attest, and some controls are mandatory for one type and advisory for another. Under the Customer Security Controls Policy the assessment must be independent: carried out by a function independent of the CISO organization, by an external assessor, or by both.

Attest in KYC-SA between July and December. The user must attest compliance with all mandatory controls and may also attest advisory controls. Users with the receiving-only profile are treated as compliant without an independent assessment but still attest every year.

Key Elements

• Three objectives

Secure your Environment, Know and Limit Access, and Detect and Respond.

• Seven principles

Restrict internet access and protect critical systems from the general IT environment; reduce attack surface and vulnerabilities; physically secure the environment; prevent compromise of credentials; manage identities and separate privileges; detect anomalous activity to systems or transaction records; plan for incident response and information sharing.

• Mandatory and advisory controls

32 controls in v2026: 26 mandatory and 6 advisory, with advisory controls marked by an A after the number.

• Architecture types

A1, A2, A3, A4 and B, chosen to match how the user connects to Swift.

• Control 2.4, Back Office Data Flow Security

Mandatory in v2026; legacy direct data exchanges stay advisory, with 2028 as a tentative date to make them mandatory.

• Customer client connectors

API endpoints, middleware and file transfer clients are in scope of controls 1.2, 1.3, 1.4, 2.2, 2.3, 2.6, 2.7, 3.1, 4.1, 4.2, 5.1, 5.4, 6.1 and 6.4.

• KYC-SA attestation and independent assessment

The annual submission in Swift's KYC Security Attestation application, supported by an independent assessment.

What does it cover?

The CSCF applies to every user of Swift's messaging services, including banks, financial institutions, corporates and service providers that connect through their own infrastructure, a connectivity provider or a Swift connector. The user attests for the components it operates in its live, back-up and disaster recovery environments, and the architecture type it selects determines which controls are mandatory. Swift provides a CSP architecture decision tree for choosing the type. The framework covers the user's Swift-related environment, not Swift's own network.

What are its objectives?

The CSCF is built to raise the security of every user's Swift environment through three objectives.

Secure your Environment: restrict internet access and segregate critical systems from the general IT environment, reduce the attack surface and vulnerabilities, and physically secure the environment.

Know and Limit Access: prevent compromise of credentials, and manage identities and separate privileges.

Detect and Respond: detect anomalous activity to systems or transaction records, and plan for incident response and information sharing.

Make the result visible: the attestation, supported by an independent assessment, is what counterparties and supervisors rely on.

Framework in Context

Swift describes the CSCF as built on industry frameworks such as NIST, ISO 27000 and PCI DSS, so evidence collected for those frameworks can support the same controls. It is governed by Swift's Customer Security Controls Policy, which sets attestation and consequences, and by the Independent Assessment Framework, which describes how assessments are performed. Swift publishes the framework each July, about a year before it applies, and the Controls Policy gives users up to 18 months from publication to prepare for changes. The CSCF is a Swift requirement for its users, not a law, although supervisors can receive reports of non-compliance.

Common Framework Mappings

Organizations map the CSCF controls to the frameworks below so that one set of evidence serves the annual attestation, supervisors and other assessments.

Mapped frameworks include:

CIS Controls v8.1

EU DORA

ISO 27001:2022

ISO 27002:2022

NIST CSF 2.0

NIST 800-53 Rev.5

PCI DSS 4.0.1

SOC 2