SWIFT CSP: How Attestation and the Independent Assessment Work

SWIFT CSP, the Swift Customer Security Programme, requires every organisation connected to the Swift network to secure its local Swift environment against a defined set of controls and attest its compliance each year. The controls are set out in the Customer Security Controls Framework (CSCF). Version 2026, used for attestations made between July and 31 December 2026, has 32 controls: 26 mandatory and 6 advisory. Since 2021 every attestation has had to be supported by an independent assessment, carried out either by an internal function that is independent of the first line or by an external assessor.

This guide explains how the programme works, what the CSCF covers, how your architecture type changes the scope, who can carry out the independent assessment and where PCI DSS evidence overlaps. Swift publishes the CSCF and its Independent Assessment Framework through its Customer Security Programme pages, some of them behind a customer login. Both change every year, so always check the version you are attesting against. This guide was last reviewed in October 2026 against CSCF v2026 and the attestation window that closes on 31 December 2026.

What is the SWIFT Customer Security Programme?

Swift launched the CSP in 2016 after a series of frauds in which attackers compromised banks’ local Swift environments and used them to send fraudulent payment instructions. The weak point was the security of users’ own systems rather than the Swift network itself, so the programme makes each user responsible for its environment and makes its status visible to others.

The programme has four parts:

• The CSCF, a set of mandatory and advisory security controls, revised each year.
• Annual attestation in Swift’s KYC Security Attestation (KYC-SA) application.
• Independent assessment behind every attestation.
• Transparency. Counterparties can ask to see your attestation data to inform their own risk decisions, and Swift reserves the right to report users that do not attest, or do not meet the mandatory controls, to their supervisors.

The CSP applies to every Swift user, whatever its size: banks, market infrastructures, payment firms, brokers and corporates, whether they connect directly or through a service provider.

What is the SWIFT CSCF?

The Customer Security Controls Framework is the list of controls Swift users must implement and attest to. It is built on three objectives and seven principles.

Controls are numbered by principle, and advisory controls carry an “A” suffix, such as 7.3A Penetration Testing. Swift gives advance notice before an advisory control becomes mandatory. Back Office Data Flow Security is the latest example: advisory as 2.4A in earlier versions, it is mandatory in v2026 as control 2.4, extending expectations to the middleware, file transfer and back-office flows that feed Swift payments.

Swift publishes each new CSCF version in July for attestations in the following year’s window, so the next version, CSCF v2027, covers attestations from July 2027; read its changes before you plan next year’s cycle. Before you plan, confirm the version in force and which controls apply to your architecture type, because applicability varies by type.

What are the SWIFT CSP architecture types?

Your architecture type decides which controls apply. It depends on which Swift components sit in your own environment and which a service provider runs for you.

Swift refines these definitions from version to version, so recheck your type each year rather than copying last year’s answer. A user that once attested as type B, for example, may now need to attest as A4 if its own servers connect to a service provider through middleware, a file transfer server or an API client, and A4 brings more mandatory controls. Getting the type right is the first step of any assessment.

How does the annual attestation work?

Every Swift user must attest at least once a year in KYC-SA, between July and 31 December, against the CSCF version in force for that window. For each applicable control you declare whether you comply, and the attestation records how it was independently assessed.

An attestation that declares non-compliance with a mandatory control is still visible to counterparties who have been granted access. A late or incomplete attestation therefore has commercial consequences as well as supervisory ones, because correspondent banks and other counterparties use the data in their own due diligence.

Who can carry out a SWIFT CSP independent assessment?

Swift accepts internal, external or mixed teams, provided the work is independent. The assessment must cover the mandatory controls that apply to your architecture type; advisory controls are optional.

Swift’s expectations of assessors, including the certifications it looks for, are set out in the Independent Assessment Framework and can change between versions. Whichever route you take, read the framework for the year and check each assessor’s experience and certifications against it before you appoint them. Swift’s directory of assessment providers is a useful starting point, not an endorsement.

What happens during a SWIFT CSP independent assessment?

The assessor checks each mandatory control that applies to your architecture type and records whether you meet it, and your KYC-SA attestation then draws on that result. Most assessments follow the same broad path:

Leave time between findings and the 31 December deadline. Fixing a gap in a mandatory control after fieldwork is far easier than explaining a non-compliant control to counterparties for the next year.

Where does PCI DSS overlap with SWIFT CSP?

Many controls are close relatives, so a bank or payment firm that already complies with PCI DSS will have some of the processes and evidence the CSCF asks for. The scopes differ, though. PCI DSS covers the cardholder data environment, while the CSCF covers your Swift secure zone and connected back-office flows, and neither assessment counts for the other.

Reuse works best where one team and one toolset serve both scopes: a single patching process, MFA platform or log monitoring service. Show the assessor that the Swift systems are inside those processes, with Swift-specific records. The PCI DSS v4.0.1 standard is free from the PCI SSC document library, and our PCI DSS assessment page explains how QSA validation works.

How should you prepare for a SWIFT CSP assessment?

SWIFT CSP compliance is easiest to show when the evidence is ready before the assessor starts. Work through these six steps in order:

1. Confirm your architecture type against the current CSCF, especially if you use a service bureau, middleware or file transfer.
2. Map the secure zone and data flows, including back-office applications, jump servers and the connections now covered by control 2.4.
3. Give each applicable control an owner and list the evidence you hold for it.
4. Test before the assessor arrives: vulnerability scans, a firewall configuration review of the secure zone boundary and a penetration test of the Swift environment.
5. Appoint the assessor early, so fieldwork and any remediation finish well before the window closes on 31 December.
6. Attest in KYC-SA and note the advisory controls you plan to adopt, since some will become mandatory in later versions.

Where does Sovereign Secure fit?

SWIFT CSP sits alongside PCI DSS, PIN security and card production obligations for many banks and payment firms; our page on PCI compliance for banks covers that wider picture, and our guide to cyber security for financial services sets out every standard these firms commonly face. Our part in a CSP cycle is the testing and compliance evidence an assessment draws on. It does not replace your independent assessment or your attestation.

• Penetration testing of the Swift secure zone, jump servers, operator PCs and back-office connections, supporting 7.3A and showing whether segmentation holds. See network penetration testing.
• Vulnerability scanning across the year, as evidence for control 2.7.
• Firewall configuration reviews of the boundary between the secure zone and general IT.
• PCI DSS assessments as a PCI SSC-approved Qualified Security Assessor company, plus PIN security (QPA) and card production (CPSA) assessments, so shared processes such as patching, MFA and logging can be planned with both scopes in mind.
• ISO 27001 consultancy from a company that is ISO 27001 certified itself.

Sovereign Secure Ltd was incorporated in 2012 and is headquartered in Accrington, Lancashire, with offices in Los Angeles, Singapore, Dubai and Dhaka. We are a member of the PCI SSC Global Executive Assessor Roundtable for 2026 to 2028. For a structured review against a named benchmark, see our guide to a cyber security audit, and for the PRA and FCA rules that apply to UK banks alongside the CSP, see operational resilience.

What should you do next?

Confirm your architecture type and the CSCF version you will attest against, then list the controls where your evidence is missing or out of date. If testing is the gap, describe your Swift environment in our penetration testing quote form, use the enquiry form on this page or call +44 161 523 5276, and we will scope a test that reports before your assessor’s fieldwork.