Choosing your SWIFT CSCF architecture type: the decision that sets your scope
Your architecture type determines which Customer Security Controls Framework controls apply and how much of your estate the independent assessor examines. The 2026 framework made that decision harder to get right, particularly for users with customer connectors.
- Published
- July 8, 2026
- Reading time
- 9 minutes
- Written by
- MarkTillson Payment Security Practice
Each year, every Swift user attests its compliance with the Customer Security Controls Framework (CSCF) through Swift’s KYC Security Attestation application, and that attestation must be supported by an independent assessment. Before any control is tested, one choice frames everything that follows: the user’s architecture type. It determines which controls apply, which components are in scope and therefore how much of the environment the assessor needs to examine.
Many institutions selected an architecture type years ago and have carried it forward ever since. The 2026 version of the framework is a good reason to revisit that choice, because it changed how one category of component is treated: the customer connector.
The five architecture types in brief
The CSCF describes reference architectures according to which Swift-related components the user hosts and operates. In simplified terms:
| Type | What the user hosts | Typical profile |
|---|---|---|
| A1 | Both the messaging interface and the communication interface | Larger institutions running their own Swift infrastructure |
| A2 | The messaging interface; the communication interface is hosted by a third party such as a service bureau | Institutions that keep messaging in-house but outsource connectivity |
| A3 | A Swift connector: software that connects back-office applications to a service provider’s or Swift’s hosted interface | Users of hosted interface services with an on-premises connector |
| A4 | A customer connector: the user’s own middleware or file-transfer server used to exchange data with a provider that hosts the interfaces | Users connecting through a service bureau with their own integration layer |
| B | No Swift-specific component; access is through a provider’s graphical interface or application | Smaller users relying fully on a service provider |
These descriptions are deliberately condensed. The framework document itself defines each type with diagrams and edge cases, and it is the authority when a real environment does not fit neatly.
Why the choice matters so much
The CSCF is organized into three objectives, seven principles and 32 controls. Whether each control applies, and whether it is mandatory or advisory, depends on the architecture type. A type A1 user is assessed against the broadest set of controls across its secure zone, messaging and communication interfaces, jump servers and operator workstations. A type B user has a much narrower footprint.
That creates a temptation to choose the lightest type that looks plausible. It is a false economy. If the declared type does not match the real environment, the attestation itself is inaccurate, and counterparties who rely on it through the KYC Security Attestation application are relying on something untrue. An independent assessor who examines the data flows will usually find the mismatch.
What changed in the 2026 framework
Swift publishes a new CSCF version each year. The v2026 changes most relevant to architecture choice were:
- Customer connectors brought firmly into scope. Endpoints that connect to Swift indirectly through shared service-provider resources are treated as customer connectors, and a set of controls now applies to them as mandatory. Some users that previously attested as type B, because they hosted no Swift software, may need to reclassify as type A4 if they run their own middleware or file-transfer layer to exchange data with a service bureau.
- Back-office data flow security made mandatory. The control covering the security of data flows between back-office applications and Swift-connected components moved from advisory to mandatory.
The framework for the following year is published in advance of its attestation window, so institutions should read each new version as soon as it appears and plan for its changes. Always confirm your obligations against the current CSCF document available to Swift users.
Trace how payment instructions travel from your core banking or treasury system to your service provider. If they pass through any server you operate (an integration platform, a managed file-transfer server, a message queue), examine whether that component is now a customer connector under the current framework.
How to decide properly
We approach architecture determination as a short piece of evidence-gathering, not a box-ticking exercise:
- Trace the flows. Follow each message type (payment instructions, statements, confirmations) from the originating back-office application to Swift and back. Record every hop and who operates it.
- Inventory the components. Identify messaging interfaces, communication interfaces, connectors, middleware, jump servers, hardware security modules and operator workstations, and where each is hosted.
- Read the contracts. Confirm what the service provider operates on your behalf and what remains yours. Provider responsibilities should be reflected in their own attestations.
- Match against the framework definitions. Choose the type that describes reality, and document the reasoning with a diagram.
- Consider simplification. If the environment has grown complicated, with multiple connectors or legacy paths no longer in use, decommissioning is often cheaper than securing.
Scope does not end at the architecture type
For the A types, the CSCF expects Swift-related components to sit within a secure zone, segregated from the general IT environment, with controlled access through jump servers or equivalent. The design of that zone (what is inside, how operators reach it, what flows cross its boundary) is where most findings arise. Common issues include operator workstations that are also used for email and browsing, administrative access paths that bypass the jump server, and back-office connections that are broader than the flows they serve.
The architecture type tells you which controls apply. The secure zone design tells you whether you can meet them.
Choosing an independent assessor
Since the 2021 framework, attestations must be supported by an independent assessment, performed either by an independent internal function such as internal audit or by an external organization. Swift’s assessment guidance sets expectations for the assessor’s independence and professional certifications. Whatever route you choose, ask the assessor to confirm the architecture type independently at the start of fieldwork rather than accepting the prior year’s declaration. It is the cheapest point at which to discover a problem.
Key takeaways
- The architecture type sets your scope. It must describe reality, not aspiration.
- Customer connectors changed the picture in 2026. Some type B users may now be type A4.
- Back-office data flow security is mandatory under the 2026 framework.
- Trace the flows before you choose, and document the reasoning.
- Read each new CSCF version as soon as it is published; the framework changes every year.
Sources
- Swift, Customer Security Controls Framework v2026 and accompanying independent assessment framework, available to Swift users.
- Swift, Customer Security Program documentation and KYC Security Attestation application guidance.
MarkTillson performs independent SWIFT CSCF assessments for every architecture type. Our assessments start by confirming your type from the evidence, so your attestation is right before your counterparties rely on it. Book your assessment well ahead of the attestation deadline.
