Navigating the SWIFT Customer Security Controls Framework (CSCF) for 2026 requires more than simple "checkbox" compliance. As the threat landscape evolves and SWIFT updates its mandatory control guidance, financial institutions are increasingly facing complex questions regarding architecture classification, third-party dependency and the integration of emerging technologies.
At Foregenix, our SWIFT CSP certified assessors work with organisations ranging from regional banks to complex international payment processors. We frequently encounter the same technical hurdles during assessments. To help you streamline your compliance journey, we have compiled the 15 most critical technical questions we hear from the field.
Whether you are defining your architecture type, managing outsourced service providers, or preparing for the integration of post-quantum cryptography, the answers below provide the technical clarity needed to ensure your organisation stays secure and compliant.
The Customer Security Program Compliance CSCF is reviewed and updated regularly to reflect changes in the threat landscape, SWIFT services, technology and security expectations. A new version may:
The institution’s own environment may also have changed since the previous assessment through new services, connectors, infrastructure, outsourcing arrangements or data flows.
Institutions should therefore treat each assessment cycle as a revalidation exercise. This should include confirming the architecture type, component inventory, live, backup and disaster-recovery environments, secure zones, connectors, bridging servers, back-office first hops, service-provider dependencies and the controls applicable to each component. Previous assessment results should be used as a baseline but should not be carried forward without confirming that both the CSCF requirements and the assessed environment remain unchanged.
A SWIFT user’s CSP architecture type is determined primarily by the interfaces or connectors licensed or owned by the BIC and the method used to connect to SWIFT. The location of a component does not normally determine the architecture type. A component remains attributable to the BIC even where it is hosted or operated by an outsourcing agent.
The five reference architecture types are:
To determine the correct architecture type, an institution should identify:
Where more than one architecture type applies, the institution should declare the most comprehensive applicable architecture type and provide the relevant service-provider details. All in-scope components, connectors and endpoints must still be included in the CSP assessment.
Complex configurations should be validated against the latest SWIFT Customer Security Controls Framework, Architecture Type Decision Tree and CSP Components Sheet.
Architecture B applies where users access a SWIFT service or service-provider application through a graphical user interface (GUI) only, with no application-to-application transaction flow from the institution’s environment.
The institution may instead be classified as architecture A4 where a locally owned or operated server, client, middleware component, file-transfer solution or in-house application facilitates an application-to-application connection to:
The component must meet the CSCF definition of a customer connector. For example, this may include an MQ server or client, an SFTP server or client, middleware used for external connectivity, or an in-house API application that connects to SWIFT using the SWIFT SDK.
The presence of a local endpoint alone does not automatically make the institution architecture A4. Its technical function, connectivity method, transaction capabilities and use of credentials or entitlements must be assessed. If the component is a SWIFT connector rather than a customer connector, architecture A3 may apply instead.
The final classification should be confirmed against the latest CSCF definitions, SWIFT Architecture Type Decision Tree and CSP Components Sheet.
CSCF scoping documentation should provide a clear, current and traceable basis for determining the institution’s SWIFT architecture type, in-scope components, applicable controls and responsibility boundaries.
Depending on the institution’s environment, the documentation should include:
Architecture and data-flow diagrams should form part of the scoping documentation and should, where relevant, show the direction of flows, source and destination components, protocols, ports, encryption, authentication methods and trust boundaries crossed.
The documentation should also be supported by evidence that it reflects the deployed environment. This may include system inventories, configuration exports, firewall and routing rules, access-control records, service-provider responsibility matrices and approved change records.
Scoping documentation establishes the assessment boundary, but it does not replace the control-specific evidence required to demonstrate that each applicable CSCF control is appropriately designed, implemented and operating effectively.
SWIFT data-flow diagrams should provide enough detail to establish the assessment boundary, identify the components involved and demonstrate how data moves across security and responsibility boundaries.
For each relevant flow, the documentation should identify, where applicable:
The diagrams should be consistent with the component inventory and supported by current configuration evidence, such as firewall rules, routing tables, interface configurations and approved change records.
A data-flow diagram is not expected to reproduce every network configuration detail. Its purpose is to provide an accurate and traceable representation of the flows relevant to the SWIFT environment and the applicable CSCF controls.
Yes. Evidence supplied by an outsourcing agent or SWIFT connectivity provider may support a SWIFT CSP assessment where it is current, relevant, sufficiently detailed and applicable to the components and activities within the institution’s assessment scope.
However, provider evidence does not automatically demonstrate compliance across the institution’s complete SWIFT environment. The institution and its assessor should confirm:
Where a provider supplies an independent assessment report, certification or other assurance documentation, the institution’s assessor should evaluate its scope, recency, methodology and relevance before relying on it.
The SWIFT user remains responsible and accountable for identifying its complete architecture, assessing all applicable customer-managed responsibilities and submitting an accurate and complete KYC-SA attestation. Provider assurance can support this process, but it does not transfer the user’s accountability.
SWIFT publishes an updated version of the Customer Security Controls Framework annually, normally in July, approximately one year before it becomes applicable for attestation purposes.
Existing SWIFT users are normally required to submit their annual security attestation through the KYC-Security Attestation application between 1 July and 31 December. The attestation must report the institution’s compliance status against, at a minimum, all mandatory controls applicable to its SWIFT architecture and environment.
An independent assessment is also required annually to support the submitted attestation. The assessment may be performed by an appropriately independent internal function or by an external assessment provider, subject to the requirements of SWIFT’s Independent Assessment Framework. It should be completed sufficiently early to allow findings to be reviewed, remediation plans to be agreed and the attestation to be submitted by the applicable deadline.
Institutions should not wait until the attestation window opens to begin preparation. Scope validation, evidence collection, control testing and engagement with service providers should begin earlier in the year, particularly where the architecture or applicable CSCF requirements have changed.
Current deadlines and requirements should always be confirmed against the latest SWIFT Customer Security Controls Policy, Independent Assessment Framework and CSP communications.
Post-quantum cryptography should be treated as a multi-year cryptographic transformation programme rather than an immediate replacement of existing algorithms.
Institutions should manage PQC readiness through their broader cryptographic-risk management, technology lifecycle, procurement and operational-resilience processes, while also considering any specific requirements or guidance contained in the applicable CSCF version and official SWIFT product documentation.
A practical starting point is to:
NIST has published post-quantum standards including ML-KEM for key establishment and ML-DSA and SLH-DSA for digital signatures. Institutions should use these standards, applicable national guidance and supplier roadmaps to inform their planning rather than treating them as a requirement to modify production SWIFT environments immediately.
Cryptographic mechanisms embedded within supported SWIFT products should not be independently replaced or modified. Changes affecting SWIFT connectivity, authentication, certificates, HSMs or transaction-signing processes should follow official SWIFT and vendor guidance to protect interoperability, availability and product support.
A DLT platform, tokenisation solution or digital-asset application does not automatically fall within SWIFT CSP scope. Its classification depends on how it connects to SWIFT, the functions it performs and its relationship with other in-scope components.
A component may fall within CSCF scope where it:
The resulting architecture type will depend on the integration method. For example:
Even where a DLT or tokenised-asset component falls outside the formal CSCF boundary, it may still present material end-to-end payment and settlement risk. Institutions should therefore assess controls relating to:
The scope determination should be documented and validated against the latest CSCF definitions, the SWIFT Architecture Type Decision Tree and the CSP Components Sheet.
Emerging technologies should be assessed through the institution’s existing security governance, architecture, risk-management and change-management processes. They should not be introduced into a production SWIFT environment solely on the basis of a successful technical pilot.
The institution should first establish the purpose and expected business outcome of the technology, then assess:
For DLT and tokenised-asset integrations, the CSP scope determination should be based on the component’s function and connectivity rather than the technology label. A SWIFT connector, customer connector or in-house API endpoint may become part of the assessed environment, while a platform operating solely as a back-office application may remain outside direct CSCF scope, subject to the detailed implementation.
For post-quantum cryptography, institutions should prioritise cryptographic discovery, data-lifetime analysis, supplier engagement and crypto-agility planning. Production cryptographic mechanisms embedded within supported SWIFT products should not be independently replaced without official SWIFT and vendor guidance. NIST has published the first three PQC standards, while the UK NCSC describes PQC migration as a multi-year programme with discovery, prioritisation and migration phases.
Before production deployment, the institution should define:
SWIFT is actively exploring both post-quantum readiness and interoperability between established financial infrastructure and tokenised-asset platforms, making these appropriate areas for forward-looking security and architecture planning.
A pilot may affect CSP scope where it connects to production SWIFT services, uses production credentials or entitlements, manages SWIFT business transactions, shares infrastructure with an in-scope component, or introduces a SWIFT or customer connector.
The term “pilot” does not by itself make a component out of scope. The institution should assess the component according to its technical function, connectivity, hosting model and ability to affect production transactions. Test environments may remain outside CSCF scope only where they are fully segregated from production, use separate security components and cannot be configured to process live traffic.
No. The CSCF defines product-agnostic security controls and does not generally require institutions to implement a particular commercial product. Institutions may use SWIFT Payment Controls or an alternative solution where the implemented arrangements meet the applicable CSCF control objective and address the relevant transaction risks.
SWIFT Payment Controls can provide an additional layer of transaction monitoring and intervention, but using the product does not remove the institution’s responsibility to design, govern and operate appropriate transaction business controls.
Depending on the institution’s risk profile and implementation, assessment evidence may include:
The assessment should focus on whether the control objective is achieved and whether the arrangements operate effectively, rather than on the name of the product used.
ISO 20022 adoption is not a one-off message-format conversion. Institutions must continue to manage annual standards releases, evolving usage guidelines, data-quality requirements, counterparty implementation differences and changes to downstream payment-processing systems.
Common causes of operational issues include:
Institutions should operate ISO 20022 as an ongoing standards-management programme. This should include release-impact assessments, source-data ownership, mapping governance, regression testing, counterparty testing and monitoring of rejection, repair and straight-through-processing rates.
SWIFT publishes continuing annual standards releases and maintains a multi-year CBPR+ migration roadmap, confirming that ISO 20022 implementation continues beyond the initial end-of-coexistence milestone.
Institutions should treat ISO 20022 data quality as an end-to-end business and technology responsibility rather than solely as a messaging-interface issue.
Effective arrangements should include:
Where required data is unavailable or unreliable at source, institutions should remediate the originating customer, reference-data or back-office process rather than depending on downstream translation or manual repair.
SWIFT’s annual standards-release process and continuing CBPR+ roadmap mean that data and validation requirements must be managed as an ongoing capability.
Institutions should use a layered, risk-based fraud-control model rather than relying on a single monitoring rule or technology.
Depending on the institution’s payment profile, this may include:
Rules and analytical models should be subject to controlled testing, approval, monitoring and periodic tuning. Tuning should reduce unnecessary alerts without suppressing genuinely high-risk activity.
Useful performance indicators may include:
The objective is not simply to minimise alerts. It is to concentrate operational attention on activity presenting the greatest financial, customer and institutional risk.