Swift CSP testing requirements
The Swift Customer Security Programme (CSP) sets 32 controls in CSCF v2026, 26 of them mandatory, for every Swift user. Each Swift user attests annually in the KYC-SA application, backed by an independent assessment. Swift CSP testing verifies back-office flow protection, transaction limits, separation of duties, and multi-factor authentication. FintechAssuranceLabs produces the test evidence a Swift CSP assessor reviews.
- Jurisdiction
- Global (all Swift users)
- Primary source
- swift.com
Engineering interpretation of testing requirements, not compliance advice.
What Swift CSP and CSCF v2026 require
Swift started the Customer Security Programme in 2016, after cyber-attacks on Swift users. The controls sit in the Customer Security Controls Framework (CSCF). Swift publishes a new CSCF version every July, and users attest against the version from July of the next year. The Swift Customer Security Programme pages (checked on 2026-09-16) describe the attestation and assessment process. The CSCF v2026 detailed description (published 1 July 2025) applies to attestations submitted between July and December 2026.
CSCF v2026 holds 32 controls under three objectives and seven principles. 26 controls are mandatory and 6 are advisory. Advisory controls carry an "A" suffix, for example 7.3A Penetration Testing.
- Architecture type. Each user declares the most encompassing of five reference architectures: A1, A2, A3, A4, or B. The type decides which controls and components are in scope.
- Attestation. Each user submits a security attestation in the KYC-SA application between July and December. A new user attests before it goes live on the Swift network.
- Independent assessment. An independent assessment supports every attestation. Internal audit, another team independent from the first line of defence, or an external assessor can perform it.
- Reporting. Swift can report users with no valid attestation, with non-compliance on mandatory controls, or with no independent assessment. Supervisors see these reports in a dedicated application.
Two changes in v2026 move engineering work into scope:
- Control 2.4 Back Office Data Flow Security is mandatory. Flows through bridging servers, such as IBM MQ or sFTP servers, and new direct flows from a back-office first hop need confidentiality, integrity, and authentication. Legacy direct flows stay advisory, with CSCF v2028 as the tentative date to make them mandatory.
- Customer client connectors are mandatory in scope for 14 controls, including 2.2, 2.7, 4.2, 5.1, and 6.4. A customer client connector is an application that consumes Swift APIs, a middleware client, or a file transfer client that connects through a service provider. Some users who attested as architecture B must now attest as A4.
Test systems stay out of CSCF scope only when they are fully separated from production, use separate HSMs, and can carry test traffic only. A test environment that shares an HSM or can load live certificates takes the production controls.
What testing verifies in CSCF v2026
| Requirement | What we test | Evidence produced |
|---|---|---|
| 2.4 Back Office Data Flow Security | Each leg from the back-office first hop to the Swift interface rejects an altered or replayed message. | Flow inventory with the protection method and a negative test result per leg |
| 2.4 Back Office Data Flow Security | Each leg through a bridging server rejects a connection without a secure protocol, such as two-way TLS. | Protocol and cipher test log per bridging server |
| 2.9 Transaction Business Controls | The interface holds an outbound payment above the amount limit for its currency, correspondent, or message type. | Boundary test cases with the held or released result per channel |
| 2.9 Transaction Business Controls | Submissions outside business hours are blocked or flagged on the GUI, file, and API channels. | Out-of-hours test log per channel |
| 2.9 Transaction Business Controls | End-of-day reconciliation of sent messages against MT 940, MT 950, or camt.053 statements detects an injected mismatch. | Reconciliation test scenarios with the exception report |
| 5.1 Logical Access Control | One operator account cannot both create and approve the same payment. | Access control and authorisation test matrix |
| 4.2 Multi-Factor Authentication | Every login path to the messaging interface, connector GUI, jump server, and hosting systems asks for a second factor. | MFA coverage table per login path with bypass attempts |
| 2.6 Operator Session Confidentiality and Integrity | Operator sessions use an encrypted protocol and lock after the configured inactivity period. | Session test results with timestamps |
| 6.4 Logging and Monitoring | Failed logins, out-of-hours activity, and user group changes create a log entry and an alert. | Event-to-alert trace per test event |
| 7.3A Penetration Testing | Secure zone entry points, jump servers, and the data exchange layer resist the attack paths in the agreed scope. | Penetration test report with findings and retest results |
Testing stays inside the Swift Customer Testing Policy. CSCF v2026 excludes Swift-specific applications, Alliance Connect VPN boxes, and Swift central services such as FIN and FileAct from penetration tests, so the test plan excludes them too.
Artifacts a Swift CSP assessor requests
- Architecture type decision with the decision tree result and the reason it is the most encompassing type.
- Inventory of in-scope components, including customer client connectors, bridging servers, jump servers, and HSMs in live, backup, and disaster recovery environments.
- Back-office flow inventory for control 2.4, with the protection method per leg and a risk-based plan for unprotected legacy flows.
- Transaction business control configuration for control 2.9: amount limits, business hours, and reconciliation procedures, with test results.
- Operator role matrix and separation of duties test results for control 5.1.
- MFA coverage per login path for control 4.2.
- Vulnerability scan reports for control 2.7, with scan dates, scope, and remediation status.
- Penetration test report for control 7.3A with remediation tracking. The CSCF guidance sets testing at least every 2 years and a full test of all in-scope components every 4 years.
- Log sources and sample alerts for control 6.4.
- Proof that test systems are separated from production: separate HSMs and test-only certificates.
- Recent audits or assessments that the assessor may rely on under the Independent Assessment Framework.
Common Swift CSP findings
- Unprotected middleware leg. Payment instructions travel from the back office to the Swift interface over an MQ channel without TLS or LAU. A person in the middle can alter a beneficiary account. This breaks control 2.4.
- Connector left out of scope. An API client that submits pacs.008 messages through a service provider has no MFA and no vulnerability scan, because the user still declares architecture B. This breaks controls 4.2 and 2.7 in v2026.
- Limit bypass on a second channel. The GUI holds a payment above the currency limit, but the bulk file upload path releases the same payment. This breaks control 2.9.
- Reconciliation with no exception path. The end-of-day camt.053 match runs, but a missing or extra message produces no alert and no case. This breaks control 2.9.
- Maker and checker in one account. A role combination lets one operator create and approve the same payment. This breaks control 5.1.
- Stale scan profile. Scan profiles are updated more than one month before the scan, or the scan omits bridging servers. This breaks the control 2.7 guidance.
- Test system in scope by accident. A test interface shares the production HSM, so the CSCF scope rules pull it into scope without the production controls.
How we cover Swift CSP testing
Security testing covers the access, authentication, session, and penetration test rows of the table. That service delivers the "Web, API, and mobile penetration test report", "Findings with severity, reproduction steps, and retest results", and the "Access control and authorisation test matrix". Penetration test scope follows control 7.3A and the Swift Customer Testing Policy. The comparison of penetration testing and vulnerability scanning shows which method answers control 2.7 and which answers 7.3A.
Bank transfers and payment rails testing covers controls 2.4 and 2.9. That service delivers the "Payment file format validation suite (NACHA, ISO 20022 pain and camt, SWIFT MT and MX)", "Return, reject, and recall test cases", and "Bank file reconciliation checks". The message format checks overlap with ISO 20022 testing requirements. The guide to camt.053 reconciliation testing shows the statement matching we run for control 2.9.
We test Swift-connected flows for remittance providers, business banking products, BaaS platforms, neobanks, and AP/AR platforms that send bank payment files. For these products, a failed 2.9 limit or an unprotected 2.4 leg means an altered or unauthorised cross-border payment that the sender may not recover.
We do not perform the independent assessment and we do not submit the KYC-SA attestation. We plan the test cycle to finish before the July to December attestation window, and your internal or external assessor decides whether to rely on the test evidence.
Questions
What is Swift CSP?
What is Swift CSCF?
What is Swift CSP attestation?
Scope your testing
Send FintechAssuranceLabs your product, segment, money flows, and the standards that need evidence, and get a proposed test scope with its deliverables.
Scope your testing