SWIFT CSP 2026: 15 Critical Technical FAQs for Your Compliance Journey

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.

1. Why can an institution that met the applicable CSCF requirements in one assessment cycle identify new gaps in the next?

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:

• Introduce new controls or change an advisory control to mandatory
• Expand or clarify the components considered in scope;
• Revise control applicability or implementation guidance; 
• Affect the institution’s architecture classification; or
• Require additional evidence to demonstrate control design and operation. 

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.

2. How do we determine our SWIFT CSP architecture type?

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:

• A1 – Communication interface: The BIC owns a communication interface, whether or not it also owns a messaging interface.
• A2 – Messaging interface: The BIC owns a messaging interface but does not own the communication interface. Connectivity is provided by SWIFT, a SWIFT connectivity provider or a Group Hub.
• A3 – SWIFT connector: The BIC owns a SWIFT connector that supports application-to-application communication with SWIFT or with an externally hosted interface. Examples include Alliance Cloud SIL, Alliance Lite2 AutoClient, Direct Link and SWIFT Microgateway.
• A4 – Customer connector: The BIC uses a customer-developed or third-party connector for application-to-application communication but does not own a SWIFT communication interface, messaging interface or SWIFT connector. Examples may include middleware, file-transfer servers or clients, and in-house API applications implementing the SWIFT SDK.
• B – GUI-only access: Users access a SWIFT service or service-provider application through a graphical user interface only. There are no local application-to-application transaction flows or connectors. 

To determine the correct architecture type, an institution should identify:

• All communication interfaces, messaging interfaces and connectors used by the BIC; 
• The licence or component owner; 
• How each back-office application connects to SWIFT; 
• Whether application-to-application flows exist; 
• Whether connectivity is provided through SWIFT, a service provider or a Group Hub; and 
• Any hosted, API, backup or disaster-recovery configurations. 

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.

3. When does a GUI-only architecture B become architecture A4?

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:

• A SWIFT connectivity provider;
• A remote Group Hub;
• An outsourcing agent; or
• A SWIFT service.  

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.

4. What should the CSCF scoping documentation include for a SWIFT CSP assessment?

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:

• The selected SWIFT CSP architecture type and the rationale for the classification;
• An inventory of communication interfaces, messaging interfaces, SWIFT connectors, customer connectors and other relevant components;
• Component and licence ownership, including any components hosted or operated by third parties;
• The SWIFT Secure Zone, customer secure zones and relevant trust boundaries;
• Bridging servers, middleware components, file-transfer solutions and back-office first hops;
• Application-to-application, user-to-application and administrative access flows;
• Connections to SWIFT, connectivity providers, Group Hubs and outsourcing agents;
• Live, backup, disaster-recovery and other production-capable environments;
• Responsibility boundaries between the institution and its service providers;
• Any components or services considered out of scope, together with the supporting rationale; and
• A mapping of in-scope components to the applicable CSCF controls.  

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.

5. How detailed should SWIFT data-flow diagrams be for a CSP assessment?

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 source and destination components;
• The direction and purpose of the flow;
• The protocol and port;
• The authentication method;
• Whether the data is encrypted in transit;
• Any secure-zone or trust boundary crossed;
• Middleware, file-transfer servers or other bridging components;
• The back-office first hop;
• External service providers, Group Hubs or outsourcing agents involved; and
• Whether the flow applies to the live, backup or disaster-recovery environment. 

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.

6. Can evidence from an outsourcing agent or SWIFT connectivity provider be used in a SWIFT CSP assessment?

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:

• Whether the third party is acting as an outsourcing agent, a SWIFT connectivity provider, or both;
• Which components, services and operational activities are covered;
• Component ownership and the division of responsibilities between the institution and the provider;
• Whether live, backup and disaster-recovery environments are included;
• The assessment or assurance period covered by the evidence;
• The CSCF controls assessed, or how other assurance reports and certifications map to the applicable requirements;
• Any exclusions, qualifications or complementary controls that remain the institution’s responsibility;
• Identified findings, exceptions and remediation status; and
• The institution’s contractual rights to obtain relevant assurance information and receive timely notification of security incidents affecting the outsourced scope. 

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.

7. What is the annual timeline for completing a SWIFT CSP assessment and submitting the KYC-SA attestation?

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.

8. What should institutions do now to prepare for post-quantum cryptography?

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:

• Inventory cryptographic services, certificates, protocols and technical dependencies;
• Identify data that may remain sensitive for long periods and could be exposed to “harvest now, decrypt later” risk;
• Assess dependencies on HSMs, PKI platforms, VPNs, APIs, middleware and security appliances;
• Engage SWIFT, cloud providers and technology suppliers on product-support and interoperability roadmaps;
• Improve cryptographic agility so algorithms, certificates and protocols can be changed without extensive system redesign;
• Incorporate PQC requirements into procurement and contract-renewal processes; and
• Develop migration, testing, rollback and business-continuity plans. 

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.

9. How should DLT or tokenised-asset integrations be assessed for SWIFT CSP scope?

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:

• Operates as a SWIFT connector;
• Operates as a customer connector, including an in-house API endpoint;
• Independently connects to SWIFT and submits, cancels, recalls, modifies or otherwise manages SWIFT business transactions;
• Is co-hosted with an in-scope SWIFT component;
• Shares credentials, roles or transaction-management entitlements with an in-scope component; or
• Forms part of a secure zone or technical service supporting an in-scope SWIFT environment.  

The resulting architecture type will depend on the integration method. For example:

• A SWIFT connector, such as SWIFT Microgateway, may result in architecture type A3;
• An in-house API application implementing the SWIFT SDK may qualify as a customer connector and result in architecture type A4; and
• A DLT application that only generates transaction instructions and connects through an existing messaging interface may remain a back-office application and outside direct CSCF scope, provided it is not co-hosted with an in-scope component and does not independently connect to or manage SWIFT transactions. 

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:

• Cryptographic key custody and HSM or KMS usage;
• Transaction signing and authorisation;
• Segregation of duties;
• Reconciliation between SWIFT messages and ledger records;
• Smart-contract and application change controls;
• Oracle, bridge and external dependency risks;
• Timeout, rollback and compensating-transaction handling;
• Platform availability and operational resilience; and
• Incident response across participating organisations. 

The scope determination should be documented and validated against the latest CSCF definitions, the SWIFT Architecture Type Decision Tree and the CSP Components Sheet.

10. How should institutions govern emerging technologies such as post-quantum cryptography, DLT and tokenised assets within their SWIFT environment?

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:

• How it will connect to SWIFT services, interfaces, connectors and back-office systems;
• Whether it changes the institution’s CSP architecture type or introduces new in-scope components;
• What data, credentials, cryptographic keys and transaction entitlements it will process;
• Whether responsibility is shared with technology providers, cloud providers or other third parties;
• What new fraud, cyber, operational-resilience and settlement risks arise;
• How transactions will be authorised, reconciled, monitored and recovered following failure;
• Whether existing security controls remain effective; and
• Whether the technology is supported by SWIFT and the relevant product vendors.  

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:

• Accountable business, technology and security owners;
• Documented architecture and data flows;
• A formal risk assessment and security design review;
• Pilot entry and exit criteria;
• Testing, rollback and incident-response arrangements;
• Third-party assurance and contractual responsibilities; and
• Ongoing monitoring, review and decommissioning requirements. 

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.

11. When can an emerging-technology pilot affect SWIFT CSP scope?

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.

12. Does the CSCF require SWIFT Payment Controls or another specific fraud-control product?

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:

• Documented fraud and transaction-risk scenarios;
• Transaction limits, thresholds and behavioural rules;
• Alert-only, hold, block and release decision logic;
• Governance and approval of rule changes;
• Alert investigation and escalation procedures;
• Reconciliation and confirmation controls;
• Evidence of alerts, cases and actions taken;
• False-positive analysis and rule-tuning records;
• Segregation of duties and privileged-access controls; and
• Management reporting and periodic control review. 

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.

13. Why do ISO 20022 operational issues continue after the initial migration?

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:

• Incomplete or incorrectly structured party and transaction data;
• Mapping errors between internal formats and ISO 20022 messages;
• Truncation or loss of information during translation;
• Inconsistent validation across payment channels and counterparties;
• Sanctions-screening and transaction-monitoring processes that are not fully aligned to the richer data model;
• Reconciliation processes that still depend on legacy MT fields; and
• Back-office applications that cannot consistently consume or preserve ISO 20022 information. 

 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.

14. How should institutions manage evolving ISO 20022 data-quality and validation requirements?

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:

• Defined ownership of customer, counterparty and payment data;
• Validation of mandatory and conditional data before message submission;
• Documented mappings between source systems and ISO 20022 elements;
• Controls to identify truncation, default values and inappropriate data enrichment;
• Assessment of each standards release and related usage-guideline changes;
• Regression testing across payment initiation, processing, screening, reporting and reconciliation;
• Testing with relevant correspondents, service providers and market infrastructures; and
• Monitoring of rejections, repairs, screening alerts and straight-through-processing performance.

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.

15. How can institutions strengthen cross-border payment fraud controls without creating unmanageable alert volumes?

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:

• Strong controls over payment creation, modification, approval and release;
• Segregation of duties and restriction of privileged access;
• Beneficiary, customer and counterparty governance;
• Transaction-value, velocity, geographic and behavioural risk scenarios;
• Additional verification for defined high-risk events;
• Timely payment confirmation and reconciliation;
• Prioritisation of alerts according to risk and payment cut-off times; and
• Documented investigation, escalation and decision-making processes.

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:

• Alert volumes and false-positive rates;
• Time to review and decision;
• Cases escalated for investigation;
• Transactions held, rejected or released following review;
• Confirmed fraud attempts and losses;
•  Recovery outcomes; and 
• Operational effort required to process alerts.

The objective is not simply to minimise alerts. It is to concentrate operational attention on activity presenting the greatest financial, customer and institutional risk.