GLOBAL PAYMENTS KNOWLEDGEISO 20022 / SWIFT / SEPA / MT / MX

SWIFT / Learning brief

The SWIFT Customer Security Programme (CSP)

Your notes

What this means in plain language

The SWIFT Customer Security Programme: mandatory and advisory controls that connected institutions implement and attest to each year, why it exists, and how attestations inform counterparty risk.

A network is only as safe as the machines connected to it. The SWIFT (Society for Worldwide Interbank Financial Telecommunication) Customer Security Programme, or CSP, addresses this by setting security expectations for every institution that connects. Its core is the CSCF (Customer Security Controls Framework), a published set of controls covering how an institution protects its local SWIFT environment, restricts access, and detects and responds to unusual activity. Some controls are mandatory and some are advisory. Each year, connected institutions assess themselves against the framework and submit an attestation stating which controls they have in place. That attestation is not just a compliance formality: an institution can request its counterparties' attestation data and use it to judge the security posture of the banks it exchanges messages with, making endpoint security a shared concern rather than a private one.

Understand the full idea, step by step

A shared office building can have a strong front entrance and still be robbed — if one tenant leaves a side door unlocked, the thief walks in through them. A messaging network has the same shape: the core can be well defended, yet an attacker who compromises one poorly secured member can send valid-looking instructions from it. The programme in this lesson exists to raise the floor for every tenant.

Why the programme exists

SWIFT (Society for Worldwide Interbank Financial Telecommunication) operates the messaging network, but the messages originate on systems owned and run by thousands of separate institutions. A well-defended core does not help if an attacker compromises a weak endpoint and sends instructions from it — and several high-profile frauds worked exactly that way: not the network breached, but the institution's local environment. The guiding idea is blunt: the network is only as safe as its weakest connected endpoint, so raising the baseline for everyone protects the whole community.

The Customer Security Programme (CSP)SWIFT's industry programme for endpoint security

The CSP is the structured, community-wide answer to that risk. Rather than assume every connected institution secures itself adequately, it sets a common baseline and asks each member to prove it meets that baseline. It does not replace an institution's wider security programme; it focuses specifically on the local environment used to create, approve, and send messages, and the people and processes around it. It turns endpoint security from a private choice into a shared expectation.

The CSCF (Customer Security Controls Framework)the published set of controls at the heart of the CSP

The CSCF groups security controls around clear objectives — secure the local environment, know and limit who has access, detect and respond to anomalous activity. Controls are split into mandatory and advisory. Mandatory controls set the baseline every connected institution is expected to meet; advisory controls describe good practices that strengthen posture and may become mandatory in later versions as the framework evolves.

Two kinds of control

Mandatory
The required baseline every connected institution is expected to meet and attest to
Advisory
Good practices that raise posture further; some become mandatory as the framework is revised
Attestation
An annual record of which controls are implemented, expected to be supported by independent assessment

The annual rhythm of attestation

Each year, institutions carry out a self-assessment against the current version of the framework and submit an attestation recording which controls they have implemented. To make that more than an unchecked self-declaration, attestations are expected to be supported by independent assessment. The framework is revised over time, so an institution reviews its environment against the latest version, closes gaps, and re-attests. This annual cadence keeps security current rather than a one-time project, and produces a comparable record across the whole membership.

COMMON CONFUSION

The CSP secures the SWIFT network, so a member's own systems are covered by it.

The CSP is aimed at the opposite end of the wire. The core network is SWIFT's own responsibility; the CSP exists precisely because the member's local environment — the systems that create, approve, and send messages — is where the community's risk concentrates. Attesting is how a member shows it has secured its own side, not a shield the network provides to it.

How attestations inform counterparty risk

Attestation data has a second life beyond a member's own compliance. An institution can request the attestation of the counterparties it exchanges messages with, and use it to judge how well those partners secure their environments — because a payment relationship links two endpoints, and a weak one affects the messages and money flowing between them. Before opening or continuing a correspondent relationship, a risk team can review whether a counterparty meets the mandatory controls and how far it has adopted the advisory ones, and record that alongside other due-diligence findings. A partner that has not attested, or reports gaps against mandatory controls, becomes a point for questions — not an automatic refusal, but a relationship to monitor or condition. This is the system working as intended: shared visibility lets each institution decide who it connects with.

STRICTLY SPEAKING

Strictly speaking, the exact control counts and requirements change between framework versions, so an institution always assesses against the current version rather than a remembered one — this lesson deliberately quotes no fixed number. How much weight a firm gives a counterparty's attestation alongside other factors also varies by institution and jurisdiction. The durable point is the mechanism: a common baseline, an annual attestation, and shared visibility that turns endpoint security into a community control.

FOR NOW, REMEMBER

  • The CSP exists because messages originate on members' own systems; the network is only as safe as its weakest connected endpoint.
  • The CSCF is the published set of controls, grouped by objective and split into mandatory (the baseline) and advisory (good practice that may later become mandatory).
  • Members self-assess yearly against the current version and submit an attestation, expected to be backed by independent assessment.
  • Counterparties can request each other's attestations, so endpoint security becomes shared, defensive information for correspondent-risk decisions.

TRY IT YOURSELF

Reviewing a possible correspondent relationship, Maya's risk colleagues see that Cassia Bank's latest attestation reports a gap against a mandatory control. What is the appropriate response?

Treat it as a point for questions — ask about the gap and any remediation, and monitor or condition the relationship accordingly.

Correct — Exactly. A gap against a mandatory control is a defensive signal to investigate and manage, not an automatic refusal. The attestation gives the risk team something concrete to raise and track.

Ignore the attestation entirely, since a counterparty's endpoint security is that counterparty's problem alone.

Not this one — A payment relationship links two endpoints, so a partner's weakness can affect the messages and money between them. Sharing attestations exists precisely so this can be weighed, not ignored.

Refuse the relationship outright the moment any gap appears, with no further discussion.

Not this one — The framework treats a gap as a reason for questions and conditions, not an automatic ban. An outright refusal with no inquiry throws away the nuance the attestation is meant to provide.

Securing the endpoint is one control every member needs. Screening payments against sanctions lists is another — and not every institution can afford to build it alone. Next: the shared, hosted compliance services that let smaller banks run the same control.

KEEP GOING

Three things to remember

  1. 01

    The CSP sets security controls for every institution connected to SWIFT.

  2. 02

    The CSCF defines mandatory and advisory controls that members attest to yearly.

  3. 03

    Attestations let institutions weigh the security posture of their counterparties.

Where you would use this

USE CASE 01

A security team maps its local SWIFT setup against the mandatory controls.

USE CASE 02

A compliance officer submits the annual attestation for the institution.

USE CASE 03

A correspondent-banking team reviews a counterparty's attestation before onboarding.

Put the idea into a real situation

Illustrative example: a fictional bank, Meridian Trust, completes its yearly CSP attestation against the CSCF, confirming it meets all mandatory controls and 8 of the advisory ones. Before extending a new correspondent relationship, a second fictional bank, Northgate Clearing, requests Meridian's attestation, sees the mandatory controls are met, and records the result in its counterparty risk file within a 4-week review window.

Evidence & review

REVIEWED 2026-07-13

SWIFT Customer Security Programme (CSP) and the Customer Security Controls Framework (CSCF), including annual attestation and its use in counterparty risk. Defensive framing only.

What this brief simplifies: Describes control objectives and the mandatory/advisory split without quoting version-specific control counts or requirements, which change between framework releases. Attestation and independent-assessment expectations are described at teaching depth.

Sources for this brief2
  1. Official requirement

    Customer Security Programme (CSP) and Customer Security Controls FrameworkSwift

    Sets the mandatory and advisory security controls and the annual self-attestation that Swift users must meet to secure their local messaging environments. · Checked 2026-07-13

    The full Customer Security Controls Framework and detailed control descriptions sit behind a swift.com login.

  2. Simplified educational illustration

    Payments Signal editorial teaching modelsPayments Signal

    This site's own simplified teaching models. · Checked 2026-07-12

    Used wherever diagrams, scenarios, figures, or example values are didactic constructions rather than sourced facts; every such use carries a simplifications disclosure. All people, companies, banks, and list entries in examples are fictional.

Learn this properly

Related briefs

View SWIFT archive

SWIFT MTs – Key Details

Explains the MT naming convention, message categories, three-digit identifiers, and other structural details used across SWIFT FIN messages.

READ BRIEF