SWIFT CSP: Customer Security Controls for Banks and Their Vendors

The SWIFT CSP, or Customer Security Programme, is how SWIFT requires the thousands of banks and institutions on its network to protect their local environments. It was launched in 2016 after attackers used compromised bank systems to send fraudulent payment instructions over SWIFT. Its core is the Customer Security Controls Framework (CSCF), a set of mandatory and advisory controls that every user must assess and attest to each year.

The framework is updated annually. CSCF v2026 made back office data flow security mandatory and brought customer connectors, such as API clients, middleware and file transfer components, into scope. That matters for software vendors who build payment hubs, integrations and back office systems for banks. This guide explains the framework, architecture types, attestation, the v2026 changes and what vendors must deliver.

What is the SWIFT Customer Security Programme?

SWIFT provides secure messaging used by banks worldwide for payments and securities. While SWIFT secures its own network, each user is responsible for securing its connection: the servers, software, operators and processes that create and send messages. In 2016, attackers compromised a central bank's local environment and attempted fraudulent transfers of around one billion US dollars, succeeding with tens of millions. In response, SWIFT launched the CSP to raise security across its community through mandatory controls, annual attestation and transparency between counterparties.

Who must comply?

• All SWIFT users: banks, broker-dealers, market infrastructures and corporates connected directly or through providers.
• Service bureaus and shared infrastructure providers, which have their own requirements and whose customers rely on them.
• Vendors of SWIFT-related software, middleware, connectors and back office systems, indirectly, because their products must support users' compliance.

Is it mandatory or voluntary?

Mandatory for SWIFT users under SWIFT's rules. Users must attest annually to their compliance with mandatory controls; advisory controls are recommended. There is no certificate, but attestations are visible to counterparties that request them, and SWIFT can report non-attesting or non-compliant users to their supervisors.

The framework structure

The CSCF is organised around three objectives and seven principles:

Objective	Principles
Secure your environment	Restrict internet access and protect critical systems from the general IT environment; reduce attack surface and vulnerabilities; physically secure the environment.
Know and limit access	Prevent compromise of credentials; manage identities and segregate privileges.
Detect and respond	Detect anomalous activity in systems or transaction records; plan for incident response and information sharing.

Controls are numbered within these principles. Advisory controls are marked with an "A" suffix. According to published analyses, CSCF v2026 contains 32 controls, most of them mandatory.

Examples of controls

• Environment protection: segregate the secure zone containing SWIFT-related components from the wider IT environment.
• Operating system privileged account control: restrict and monitor administrator accounts.
• Internal data flow security: protect confidentiality, integrity and authenticity of data flows between SWIFT-related components.
• Security updates: apply vendor patches within defined timeframes based on risk.
• System hardening: apply secure configurations.
• Back office data flow security: protect data flows between back office applications and SWIFT components, mandatory from v2026.
• Multi-factor authentication for interactive access to SWIFT-related applications and operating systems.
• Password policy and logical access control with least privilege and segregation of duties.
• Malware protection, software integrity checks and database integrity.
• Logging and monitoring to detect anomalies, and cyber incident response planning.
• Security training and awareness.

Designing the secure zone

A central idea in the CSCF is the secure zone: a segregated part of the network that contains SWIFT-related components, such as messaging and communication interfaces, connectors and the operator PCs or jump servers used to manage them. Access into the zone should be tightly controlled, internet access restricted, administrators should connect through hardened jump hosts with MFA, and systems in the zone should be hardened, patched and monitored. Good secure zone design reduces the attack surface and makes many other controls easier to demonstrate. For cloud-hosted components, the same principles apply through network segmentation, dedicated accounts and strict identity controls.

Transaction controls and fraud detection

Technical security is only part of the picture. The 2016 attacks showed that fraudsters with access to a bank's environment could send messages that looked legitimate and then hide evidence by tampering with confirmations and reports. The CSCF therefore includes business controls, such as restricting transaction activity to expected counterparties, times and amounts, reconciling sent messages with back office records, and reviewing unusual activity promptly. Database and software integrity controls help detect tampering with messages or records. Combining these with logging and anomaly detection gives banks a chance to stop fraudulent payments before funds disappear.

Architecture types

Controls apply according to how a user connects to SWIFT. SWIFT defines architecture types such as:

• A1: the user owns and operates both the messaging interface and the communication interface.
• A2: the user owns the messaging interface, while a service provider hosts the communication interface.
• A3: the user connects through a lightweight connector or API to a provider's or SWIFT's interface.
• A4: the user uses customer connectors, such as middleware or file transfer servers, to reach a service provider or shared infrastructure.
• B: no user-hosted SWIFT footprint, using a service provider or back office applications without local SWIFT-specific infrastructure.

Choosing the right architecture type determines which controls apply. Under v2026, institutions that previously classified themselves as type B may need to reclassify as A4 if they use customer connectors.

What changed in CSCF v2026

• Back office data flow security became mandatory, requiring protection of data flows between back office systems and SWIFT-related components, such as encryption, authentication and integrity checks.
• Customer connectors entered scope, including API clients, middleware and file transfer clients that connect, directly or indirectly, to SWIFT through a service provider or shared infrastructure.
• Fourteen controls apply to customer connectors, covering areas such as privileged account control, internal data flow security, security updates, system hardening, physical security, password policy, MFA, logical access, malware protection and logging.

Users needed to plan these changes for their 2026 attestation, typically submitted between July and the end of December.

Attestation and independent assessment

Each year, users must attest their compliance with the mandatory controls of the current CSCF version through SWIFT's KYC Security Attestation (KYC-SA) application. Since 2021, attestations must be supported by an independent assessment, conducted either by an internal function independent of the first line, such as internal audit, or by an external assessor. The assessment should test controls, not just review documents. Users can grant counterparties access to view their attestation, which helps in correspondent banking due diligence. Attestations generally must be renewed by 31 December each year against the version in force.

Preparing for the independent assessment

Independent assessors test whether controls are implemented as described. Preparation helps: keep an up-to-date inventory and architecture diagram, map each control to evidence, ensure configuration screenshots and system exports are current, demonstrate MFA and access controls live, show patching records against timelines, and provide logs and alerts that prove monitoring works. Assessors also look at compensating controls where a control cannot be met directly; these must be documented and genuinely reduce the risk. Starting preparation early in the year avoids a rush before the December deadline.

Consequences of non-compliance

SWIFT may report users that fail to attest, or attest non-compliance with mandatory controls, to their supervisors. Counterparties may restrict relationships or demand remediation. Non-compliance also leaves institutions more exposed to the fraud scenarios that prompted the programme.

What vendors and service providers must deliver

• Support for encryption, mutual authentication and integrity checks on back office and connector data flows.
• MFA for interactive access and role-based access with least privilege.
• Hardening guidance and secure default configurations.
• Timely security patches with clear severity information.
• Logging of security events and message activity that can feed monitoring.
• Software integrity mechanisms, such as signed releases.
• Documentation that maps product features to CSCF controls.

We build secure integrations, APIs and back office components with encryption, MFA, logging and documented data flows through our API integration and custom software development services.

Service bureaus and shared infrastructure

Many smaller institutions connect to SWIFT through service bureaus or other shared infrastructure providers rather than running their own interfaces. These providers have their own security requirements under SWIFT's shared infrastructure programme and are assessed separately. Users relying on them still need to secure their own side of the connection, such as operator access, connectors and back office flows, which is exactly why v2026 brought customer connectors into scope. Users should obtain assurance from their providers and understand which controls each party implements.

API connectivity and modern integration

SWIFT increasingly offers API-based services alongside traditional messaging, and many banks connect back office systems, treasury platforms and payment hubs through APIs and middleware. Each of these integration points is now a potential attack path and, under v2026, often in scope as a customer connector. Secure API design matters: mutual authentication, short-lived credentials stored in vaults, encryption in transit, message signing where supported, strict input validation, rate limiting and detailed logging. Treating every connector as part of the secure perimeter helps both security and attestation.

How to comply, step by step

1. Determine the architecture type and identify all SWIFT-related components, including customer connectors.
2. Define the secure zone and data flows, including back office flows.
3. Gap-assess against the current CSCF version.
4. Remediate: segregation, MFA, hardening, patching, data flow protection and logging.
5. Arrange independent assessment of all mandatory controls.
6. Submit the attestation in KYC-SA before the deadline.
7. Review the next CSCF version when published and plan changes.

Documentation you will need

• Architecture diagrams and inventory of SWIFT-related components.
• Data flow diagrams, including back office and connector flows.
• Policies and procedures for each control.
• Evidence of control operation: configurations, logs, access reviews, patch records.
• Independent assessment report.
• KYC-SA attestation records.

Timeline and cost considerations

The CSCF is published around the middle of each year for attestations in the following year, giving users time to prepare. Institutions should read each new version as soon as it appears, identify controls moving from advisory to mandatory, and budget engineering work early, because vendors and service providers may also need to change their products. Costs include engineering changes, assessment fees and ongoing operations such as monitoring. The v2026 changes required significant work for institutions using API connectors and middleware, particularly where back office flows lacked encryption or integrity protection.

Common mistakes

• Wrong architecture type, missing in-scope components.
• Back office flows sent in clear or without integrity checks.
• Shared admin accounts and missing MFA.
• Assessments that review policies without testing controls.
• Late attestations close to the December deadline.
• Ignoring connectors managed by IT outside the payments team.

How it relates to other frameworks

Framework	Relationship
ISO/IEC 27001	Broader ISMS; CSCF focuses on SWIFT-related components.
NIST CSF	CSCF controls map to CSF functions.
PCI DSS	Card data security; similar control themes for a different payment system.
DORA	EU financial resilience regulation covering ICT risk, including payment infrastructure.
RBI directions	Indian banks' broader technology risk rules alongside SWIFT requirements.

Real-world example

A regional bank uses a payment hub built by an Indian fintech vendor that sends payment files to its service bureau through an SFTP-based connector. Under CSCF v2026, the bank reclassifies from type B to A4 because of the connector. The vendor adds mutual TLS and message-level signing between the hub and the connector, enforces MFA for operators, provides a hardening guide, and forwards security logs to the bank's monitoring platform. Internal audit independently tests the 14 connector controls and the back office flow control before the bank submits its attestation in December.

Next steps

1. Confirm your architecture type under v2026.
2. Map back office and connector flows.
3. Close gaps in data flow protection and MFA.
4. Arrange independent assessment.
5. Attest before 31 December.

Frequently asked questions

What is the SWIFT CSP?

SWIFT's Customer Security Programme, requiring users to secure their local environments and attest compliance with the Customer Security Controls Framework annually.

Is SWIFT CSP mandatory?

Yes, for SWIFT users, who must attest compliance with mandatory controls each year.

What changed in CSCF v2026?

Back office data flow security became mandatory and customer connectors came into scope for many controls.

When is the attestation due?

Typically by 31 December each year, for the CSCF version in force, with the attestation window usually opening in July.

Is independent assessment required?

Yes. Attestations must be supported by an independent internal or external assessment of mandatory controls.

What are architecture types?

Categories such as A1, A2, A3, A4 and B describing how a user connects to SWIFT, which determine applicable controls.

Can counterparties see my attestation?

Yes, if you grant them access through the KYC Security Attestation application.

Do vendors need to attest?

Vendors do not attest for users, but their products must support users' compliance, and service bureaus have their own requirements.

What happens if a user does not comply?

SWIFT may report the user to its supervisor, and counterparties may restrict relationships.

Are advisory controls required?

No, but they are recommended and sometimes become mandatory in later versions.

What is a customer connector?

Software such as an API client, middleware or file transfer client that connects a user's systems to SWIFT through a service provider or shared infrastructure.

Who can perform the independent assessment?

An internal function independent of the first line, such as internal audit, or an external assessment firm with relevant expertise.

How often does the CSCF change?

SWIFT publishes a new version every year, usually around mid-year, for attestations in the following year.