Which SWIFT CSCF architecture type applies to your organization
The architecture type is set by which party owns the Swift communication interface, the messaging interface and the associated licences. Before you scope anything for CSCF v2026, walk through Swift's architecture decision tree for each way your organization connects to Swift, and record who owns each component. The answer decides which of the five reference types, A1, A2, A3, A4 or B, applies, and therefore which controls you must implement and attest to. Confirm the result against the current decision tree on the Swift CSP Understand controls page rather than relying on a type from a previous cycle.
One group can fall into different types for different connections. A treasury team connecting through a bank-hosted service may sit in one type, while a payments platform that runs its own interface in-house may sit in another. Map each Swift-connected environment separately, including test and disaster recovery environments, and list the component owner, the licence holder and any connectivity provider or group hub involved. Where the owner changes, for example when a connector moves from a vendor-managed setup to your own data center, the type can change too, so treat a new connection or a changed deployment as a trigger to repeat the check.
The type determines the scope of your work. CSCF v2026 states that the controls applicable to A1, A2 and A3 are identical, that fewer apply to A4, and that fewer still apply to B. Control 1.5 applies only to A4, so an A4 customer carries a control that the other types do not. Before you start a gap analysis, write down the architecture type for each connection and the controls that follow from it, and confirm that the list matches the scope your independent assessor expects to test. A wrong type at this stage propagates into the implementation plan and the attestation.
What each of the five CSCF architecture types means
The five CSCF architecture types differ by who owns the Swift interfaces and licences in the user's environment. That ownership split decides how much of the framework applies, so the cards below compare each type by its component owner and typical setup.
A1: user owns the interfaces
In A1 the user owns the communication interface and generally the messaging interface, so the user runs both Swift-facing components inside its own environment. Because the user holds the communication interface, it carries the broadest set of controls among the connected types. Check first whether your organization holds the communication interface licence itself, since that single fact points toward A1 and away from A2.
A2: user owns messaging only
In A2 the user owns the messaging interface, while a connectivity provider, group hub or Swift owns the communication interface licence. The user's footprint is therefore narrower than in A1, but the messaging interface still sits inside its environment. Confirm in writing which party holds the communication licence, because that determines whether the provider's audit covers the components you rely on.
A3: Swift connector in environment
In A3 a Swift connector runs in the user's environment and supports application-to-application communication with an interface hosted at a connectivity provider, a group hub or Swift services. The connector is the component you must inventory, harden and keep patched. Ask your team which software performs this role, since a connector installed by a vendor still counts toward your footprint.
A4: no Swift interfaces
In A4 the user has no Swift interfaces but runs software such as a file transfer solution or customer connector in its environment. The Swift-specific exposure is smaller, yet the software that moves Swift traffic is still in scope. This is the only architecture type where Control 1.5 Customer Environment Protection applies, so confirm that the supporting file transfer or connector software really is the sole Swift touchpoint.
B: no Swift infrastructure
In B no Swift-specific infrastructure component is used in the user's environment. Fewer controls apply than in any connected type, because nothing Swift-specific is deployed locally. Before choosing B, confirm that no connector, gateway or file transfer product in your estate touches Swift traffic, since any such component would move you to A4 or A3.
Why component and licence ownership decides the type
Component and licence ownership, not organization size or message volume, is the key differentiator between CSCF architecture types. A large bank with heavy traffic can sit in A4 or B, and a small institution can sit in A1. What matters is who owns each Swift-related component in the chain, because the party that owns a component is the party whose controls you must implement and evidence in your own assessment.
If you own both the communication interface and the messaging interface, you carry the controls for both, which is the situation that points toward A1. If you own the messaging interface but rely on a connectivity provider, a group hub or Swift for the communication interface licence, you are typically in A2: your footprint is narrower, but the messaging side remains fully yours. A3 adds a Swift connector in your own environment for application-to-application traffic, so the connector itself enters your scope. Each of these choices changes which controls apply, so write down, for every interface, who holds the licence and who operates the software before you read any control list.
Confirm the final decision against the current CSCF v2026 text and Swift's architecture decision tree rather than relying on a summary, including this one. Ask your connectivity provider, group hub or Swift which components they own and which they expect you to evidence, and record the answer in your assessment file. An implementation partner can prepare the inventory and the configuration evidence for your components, but the decision on architecture type and the attestation remain your responsibility.
How the architecture type changes the controls in scope
A1, A2 and A3 share an identical set of applicable controls under CSCF v2026, so the type you pick among these three does not change the control list. What changes is who owns which component. In A1 the user owns the communication interface and generally the messaging interface. In A2 the user owns the messaging interface, while a connectivity provider, group hub or Swift owns the communication interface licence. In A3 a Swift connector in the user's environment supports application-to-application communication with an interface at a provider, group hub or Swift services.
- Same control list: Because the applicable controls match across A1, A2 and A3, a team that moves between these types keeps the same starting list.
- A1 ownership: The user holds the communication interface and generally the messaging interface, which puts the widest set of interface responsibilities in its hands.
- A2 ownership: The user runs the messaging interface, while the communication interface licence sits with a third party.
- A3 connector: The connector host, its configuration and its access paths fall inside the environment the assessor reviews.
- Illustrative example: A bank that moves its messaging interface to a provider may switch from A1 to A2 with no change to the applicable control list, yet its evidence for ownership and licence terms changes.
Confirm in writing which party owns each component before assuming the control list carries over.
In A4 the user has no Swift interfaces but runs software such as a file transfer solution or customer connector in its environment. Fewer controls apply to A4 than to A1, A2 and A3. The type is defined by its supporting software rather than by a Swift interface, and control 1.5 Customer Environment Protection applies only to A4, so it is the control that marks this type most clearly.
- No Swift interface: The user does not own a Swift interface, so controls that only address interface operation drop out of scope.
- Supporting software in scope: A file transfer solution or customer connector running in the environment keeps the attestation scope in place.
- Control 1.5: Customer Environment Protection applies only to A4, so the team must show how the environment hosting this software is protected.
- Smaller set than A1 to A3: The applicable set is smaller, but each remaining control still needs evidence tied to the software you run.
- Illustrative example: A company that sends files through a file transfer tool to a service provider, and runs no Swift interface itself, may fall under A4 if its software meets the CSCF definition.
Ask your independent assessor to confirm whether control 1.5 and each remaining control apply to the exact software set in your environment.
In architecture B no Swift-specific infrastructure component is used in the user's environment. B has the fewest applicable controls of the five types. Because the scope is so small, the main work is proving that no Swift component sits in your environment, and documenting how you reached that conclusion. An assessor will test the absence as carefully as the presence of components in the other types.
- No Swift components: No Swift-specific infrastructure component runs in the user's environment, so interface and connector controls do not apply.
- Fewest controls: B carries the smallest applicable set of the five types, which lowers the assessment scope compared with the others.
- Proving the absence: Keep an inventory of hosts, connectors and file transfer tools that shows no Swift component is present.
- Provider footprint: If you connect through a connectivity provider, controls apply only to your own footprint, because the provider is covered by a specific Swift audit.
- Decision tree: Use Swift's architecture decision tree and keep its output as evidence of how the type was chosen.
Re-check the type whenever a new interface, connector or file transfer tool enters the environment, since any of these can move you out of B.
Do not treat the control count for your architecture type as the answer. Open the CSCF v2026 document and read the applicability column for each control against your type. Counts change between versions and can hide controls that apply to your type only. The applicability column is the authoritative mapping for your architecture, so build your control list from it and record each decision.
- Read every control: Go through all 32 controls and mark each one as applicable or not applicable to your type.
- Applicability and status are separate: A control can apply to your type and still be advisory, so check the mandatory or advisory status as well.
- Record the reasoning: For each control marked out of scope, note the ownership decision that removes it.
- Re-check on each version: A new CSCF version can change the applicability column, and Swift publishes each version a year before it applies.
- Confirm with the assessor: Ask your independent assessor to review the mapping before you submit the attestation.
Keep the signed-off applicability matrix with your attestation evidence, so the scope can be explained to an auditor or counterparty later. The framework is available in the CSCF v2026 document, which requires a Swift login.
What changes if you connect through a service bureau
If you connect to Swift through a connectivity provider such as a service bureau or a Business Connect provider, you implement the CSCF controls only for your own footprint. The provider is covered by a specific Swift audit, so the controls that sit inside its infrastructure are not yours to implement or re-test. That does not remove your obligations. You still need to determine your architecture type from the components you own, because the provider's coverage does not decide which architecture applies to your environment. Start by listing every Swift-related component you run, including any messaging interface, connector, file transfer software or customer-side connection, and noting who holds the licence for each one.
The practical work is to draw a clear line between what the provider covers and what remains with you. Ask the provider in writing which Swift audit covers its services, which CSCF controls that audit addresses, and what it expects its customers to implement on their side. Request the scope of the provider's assessment so you can confirm that the controls it covers match the interfaces you actually use. If the provider's answer leaves a gap, such as access management for your users or the configuration of a customer connector, that gap becomes your responsibility and belongs in your gap analysis and independent assessment scope.
Confirm the provider's coverage directly with the provider rather than relying on general statements about its Swift status. Ask for the current version of the coverage statement, the date it applies to, and a named contact who can answer questions for your assessor. Your independent assessor will expect evidence that you understand the boundary, so keep the provider's written answer with your assessment records. Where you use a product-specific Security Guidance document for a Swift interface you run, check that your configuration follows its minimum settings, since those settings sit inside your footprint.
How to determine your architecture type step by step
This sequence turns the question of which CSCF architecture applies into a documented decision that the independent assessor can test before fieldwork begins. Each step produces a record that shows who owns each Swift component and why that ownership points to one architecture type.
Inventory every Swift interface and licence
Start by listing every Swift-related component in use across the organization, including the communication interface, the messaging interface, any Swift connector, file transfer or customer connector software, and any Swift-provided services. Include test and disaster recovery environments, since they can change the picture. Record the BIC, the product name, the version, the environment and the business owner for each item. Ask the operations team and the Swift administrator to confirm the list, because licences are often held by a different team from the one that runs the software. The step is complete when the inventory covers every connection to Swift and each item has a named owner who has confirmed it.
Map ownership of each component
For each inventoried item, establish who owns the software licence, who operates the component and who holds the interface relationship with Swift. Separate the communication interface from the messaging interface, because CSCF architecture types are decided by which party owns each one. Note where a connectivity provider, group hub or Swift holds the communication interface licence and where the user holds it. Confirm the answers against contracts, licence certificates and the Swift connectivity agreement, not against memory or old diagrams. The output is an ownership register that lists each component, its owner, the owner of its licence and the source document that proves it.
Run Swift's architecture decision tree
Use the architecture decision tree that Swift provides on its controls guidance to work from the ownership register to one architecture type, A1, A2, A3, A4 or B. Answer each question using the register rather than assumptions about the product. Where the answers point to more than one possible path, stop and identify which component causes the ambiguity, because a single mixed footprint can need a closer reading of the CSCF definitions. Ask the Swift CSP contact or the assessor to confirm any answer that depends on a contract term. The step is complete when the tree gives one result for each distinct footprint and the path taken through the tree is written down.
Record the architecture decision with supporting evidence
Write a short architecture decision record that states the chosen type, the date, the people who approved it, the decision path through the tree and the ownership register it relies on. Attach the evidence for each ownership claim, such as licence agreements, connectivity contracts and interface configuration exports. If the organization connects through a service bureau or connectivity provider, record which footprint remains the user's responsibility, because the provider is covered by its own Swift audit. Store the record in the same location as the attestation evidence and set a review point for any change in interfaces or licences. The output is a signed architecture decision with its evidence file.
Derive the controls in scope for that architecture
With the architecture type fixed, list the CSCF v2026 controls that apply to it. Controls apply in full for A1, A2 and A3, fewer apply to A4, and fewer still apply to B. Control 1.5 Customer Environment Protection applies only to A4, so an A4 user must add it to the scope while other types drop it. Mark each control as in scope or out of scope with a short reason that cites the architecture decision record. Also note any product-specific Security Guidance that applies to the interfaces in use. The output is a scoped control list that links each in-scope control to the component it protects.
Confirm the scope with the independent assessor
Before the independent assessment begins, send the architecture decision record, the ownership register and the scoped control list to the assessor and ask for written agreement. The assessor may be an internal function such as risk, compliance or internal audit, or an external firm, and the reader should confirm which applies to their organization. Ask the assessor to test whether the ownership evidence supports the chosen type and whether any control has been wrongly included or excluded. Resolve any disagreement before fieldwork starts, and record the assessor's confirmation in the file. The step is complete when the assessor has agreed the scope in writing and that agreement is filed with the other attestation evidence.
Who owns the architecture decision
The architecture type follows from who owns each Swift interface and licence, so the decision sits with the organization. An implementation partner can prepare the evidence behind that decision, and an independent assessor tests the result, but neither can make the choice or issue an attestation on the organization's behalf.
The organization decides and owns the controls
The Swift user decides which architecture type applies by checking who owns the communication interface, the messaging interface and any Swift connector in its environment. It owns the controls in scope for that type, signs the KYC-SA attestation, and answers to its supervisors for the result. Before settling the type, confirm with the connectivity provider or group hub which licences and components the organization actually holds.
Implementation partner prepares the inventory
An implementation partner such as DeployOpen can map Swift components, hosts, software and licences across the organization's environment, then document the architecture the organization has chosen. It can also collect configuration evidence and draft the architecture documentation that the assessor will read. Scope, deliverables and timelines are agreed in writing before work starts, and the organization keeps final sign-off on the decision.
Connectivity provider's footprint
Users who connect through a service bureau or Business Connect provider need to confirm which part of the architecture belongs to the provider and which belongs to them. The provider is covered by its own Swift audit, so the organization implements controls only for its own footprint. Ask the provider for written confirmation of the boundary before the architecture type is recorded.
Independent assessor tests the choice
The independent assessor, whether internal, from a second or third line function, or external, tests whether the chosen architecture type matches the actual setup and whether the in-scope controls are met. The assessor reviews the inventory and evidence, then reports its findings to the organization. Swift's CSP Assessor Certification is optional, and the assessor issues no certificate of its own.
DeployOpen does not attest
DeployOpen does not issue audit reports, attestations or certifications, and it does not decide the architecture type for a client. Its role is limited to preparing systems, configuration evidence and documentation for the organization and its independent assessor. Ask any partner, including DeployOpen, to state in writing which parts of the work it performs and which parts remain with the organization and the assessor.
Questions about SWIFT CSCF architecture types
Can a Swift user change its architecture type during the year?
Yes, if the way it connects to Swift changes, its architecture type can change too, and the controls in scope change with it. The type follows component and licence ownership, so a move such as taking on a messaging interface itself, or handing its communication interface to a provider, is the kind of change that can shift the type. Confirm the current type against the Swift architecture decision tree before any change goes live, and record the reason and date in your attestation file. Ask your implementation partner or assessor to review the change before you attest, because an attestation filed under the wrong type can be challenged later.
Does using a service bureau change my architecture type?
Using a Swift connectivity provider such as a service bureau or Business Connect provider can affect which interfaces you own, and therefore your type, so you need to check it rather than assume. If the provider holds the communication interface licence and you own only the messaging interface, the analysis usually points to A2. Your obligations then cover only your own footprint, because the provider is covered by a specific Swift audit. Confirm with the provider in writing which components it operates and which licences sit with whom, and keep that record with your scoping evidence.
How long does it take to determine my architecture type?
The time depends on how many interfaces, licences and connectivity arrangements you have, and on how well documented they are. Determining the type is mostly an inventory and ownership exercise: listing each Swift component in your environment, identifying who holds each licence, and then walking Swift's architecture decision tree. Organizations with a single, well-documented connection usually finish this quickly, while those with several entities, group hubs or legacy integrations need more time to reconcile contracts and configurations. No duration is fixed by Swift for this step, so ask your assessor or partner to state the effort in a written scope before work starts.
Which product security guidance applies to my architecture?
Product-specific Security Guidance documents complement the CSCF with minimum configuration for Swift's interfaces, so the relevant guidance follows the Swift products you actually run. Identify each interface and connector in your environment, then download the guidance that matches those products from the Swift Customer Security Programme pages. The guidance does not change your architecture type, but it sets the configuration baseline your controls must meet. Confirm the current document version for each product on the Swift site at the time you implement, since guidance is updated alongside CSCF releases.
What does architecture type A4 change compared with A1 or A2?
A4 applies to users with no Swift interfaces who run software such as a file transfer solution or customer connector in their own environment. Because the controls applicable to A1, A2 and A3 are identical, and fewer apply to A4, the A4 scope is narrower, but it adds control 1.5 Customer Environment Protection, which applies only to A4. Users in this position should not assume a smaller scope means less work, since the customer connector and the systems around it still need to be protected and evidenced. Confirm your scope with the Swift CSCF v2026 document and have an independent assessor test the connector boundary.
Can an implementation partner decide my architecture type for me?
A partner can prepare the analysis and document it, but the decision and the attestation remain your responsibility. Your organization owns its controls and the choice of architecture type, while an implementation partner prepares systems, inventories components and gathers evidence for the assessment. Only an independent assessor, internal or external according to your setup, can give an assessment result, and Swift does not issue a verdict on your type in advance. Ask the partner to show the ownership analysis, the decision tree steps and the source documents, and have your own risk or compliance owner sign off before you attest.
What should I ask a provider to confirm before scoping my architecture?
Ask for a written statement of which Swift interfaces and licences the provider holds, which ones you hold, and where the boundary between your environment and theirs sits. Request the scope of the provider's specific Swift audit so you know which of its controls you can rely on. Also ask who maintains the connector or interface software, who applies patches, and how changes are communicated to you, because these determine what you must still implement yourself. Keep the answers with your architecture record, since they are the basis for any change in type later.
How DeployOpen supports the architecture decision
DeployOpen helps a Swift user turn its architecture decision into documented, reviewable evidence. The organization owns the decision of which CSCF architecture type applies, and it owns every control that follows from that decision. DeployOpen's role is to map the Swift interface components in the client's own environment, record who owns each component and each licence, and prepare the architecture and configuration records that show why a given type was chosen. Where the Swift architecture decision tree (published on the Swift CSP Understand controls page, linked from the Swift CSP pillar) points to more than one answer, the documentation should show which facts drove the result, such as whether the user runs its own communication interface or relies on a connectivity provider, group hub or Swift for it.
The practical output is a package the independent assessor can test against. Typically this includes an inventory of Swift-related software and infrastructure, a diagram of data flows between the user's environment and Swift, a register of licence and component ownership, and configuration records for in-scope components, including any product-specific Security Guidance applied. Confirm with your assessor which artifacts they expect and in what format, because an assessment that cannot trace a control to a system component will stall regardless of how sound the underlying setup is. Ask the implementation partner to show how each artifact maps to a specific architecture type and control set before the work starts.
DeployOpen does not issue attestations, reports or certificates. Only the independent assessor (internal, second or third line, or external) reaches a conclusion on compliance, and the attestation itself is submitted by the Swift user in the KYC-SA application. Engagements are fixed-scope: the systems covered, the deliverables and the timeline are agreed in writing before work begins. Ask for that written scope to state which components are in and out of the architecture review, who confirms the ownership findings on the client side, and what happens if the architecture decision changes after a Swift release or a change in connectivity provider.
