Swift CSP Mandatory Controls Explained: A Plain-English Guide for Bank Compliance Officers

After more than five years conducting Swift CSP assessments, the most common thing I hear from compliance officers is not "we don't care about this." It is "we care, but we don't fully understand what we're signing off on."

That is a reasonable problem. The CSCF is a technical document written for technical teams. But the attestation, the formal declaration of compliance submitted to Swift every year, is ultimately a governance decision signed off by compliance and management, not by IT.

This guide bridges that gap.

What the framework is actually trying to do

The Swift Customer Security Controls Framework (CSCF) v2026 exists because of one event: the 2016 Bangladesh Bank heist, in which attackers used legitimate Swift credentials to instruct fraudulent transfers of USD 81 million. The attackers did not break Swift's central network. They compromised the bank's local Swift environment — the computers, systems, and people that connect the bank to the global network.

Every mandatory control in the CSCF addresses one of three questions:

• Is your Swift environment properly isolated?
• Do only the right people have access to it?
• Would you know if something went wrong — and what would you do?

The framework consists of 32 security controls — 26 mandatory and 6 advisories — structured around key objectives to strengthen the security of Swift users' infrastructure. The mandatory controls are not optional. By the end of each year, users must attest compliance against the mandatory controls as documented in the CSCF effective at that time.

Objective 1 — Secure your environment

Think of this as the physical and logical "fence" around your Swift systems.

Your Swift infrastructure - the messaging software, hardware security modules, operator workstations, and network connections - must be separated from your general bank IT network. Not connected with extra security. Separated. A dedicated zone with controlled entry and exit.

Controls in this group govern: how that zone is built and maintained, how software is kept up to date, how systems are configured to reduce attack surface, and how data flowing between the Swift zone and your back-office systems is protected.

CSCF v2026 makes several previously advisory requirements mandatory. Control 2.4A (Back Office Data Flow Security) has moved from advisory to mandatory; this change significantly expands CSCF scope beyond the Secure Zone into middleware, integrations, file transfers, and operational systems.

The question for your IT team: Can you show me the network diagram of our Swift secure zone boundary, and walk me through what is and isn't permitted to cross it?

Objective 2 — Know and limit access

This is about who can touch your Swift environment, and whether you actually know.

Controls here govern: how users are created and removed, how passwords and multi-factor authentication work, how privileged accounts (administrators) are managed, how staff are screened before being given Swift access, and how physical access to Swift equipment is controlled.

The principle is simple: if someone does not need access to perform their job, they should not have it. And the access that does exist should be documented, reviewed, and revoked when it is no longer needed.

The question for your IT team: When did we last review the full list of people with access to our Swift environment, and when were leavers removed?

Objective 3 — Detect and respond

Controls are secured, and access is limited, but what happens when something goes wrong anyway?

These objectives cover: whether your Swift environment is monitored around the clock, whether logs are collected and reviewed, whether your team has a tested plan for responding to a Swift payment fraud incident, and whether staff with Swift access receive training specific to Swift threats.

Control 7.2, mandatory under CSCF v2026, requires annual Swift-specific security awareness training, covering Swift threat scenarios and, under the v2026 update, deepfake technology awareness.

The question for your IT team: When did we last simulate a Swift payment fraud scenario, and what did we learn?

What compliance officers actually need to do

You do not need to understand every technical sub-control. You do need to:

Ask whether every mandatory control has been independently assessed (not self-reviewed) by a qualified external assessor. Swift requires an independent review of at least all mandatory controls within the attestation process to ensure reliability, consistency, and accuracy in security assessments.

Verify that the person signing off on the assessment holds the right qualifications. Swift's IAF requires assessors to hold certifications covering both cybersecurity and audit competencies, not one or the other.

Confirm the evidence is current. An assessment from last year against last year's framework is not a valid basis for this year's attestation.

One number to remember

Your attestation, and every mandatory control it covers, is visible to every correspondent bank you transact with through the KYC-SA portal. Non-compliance is not an internal matter. It is visible to your counterparties and your regulator.

That is what you are signing off on.

DeshCyber conducts independent Swift CSP assessments worldwide. Our lead assessors are listed on Swift's official assessor directory and hold CISA, CISSP, CEH, and ISO 27001 Lead Auditor certifications.

→ Take our free CSCF v2026 self-assessment: deshcyber.com/self-assessment