SWIFT CSP architecture types determine which controls apply to your institution, how you are assessed, and how much evidence you must produce, which makes getting your classification right the most consequential decision in the entire process. An institution that misjudges its type can either miss controls that apply to it or scope in controls that do not, and in both cases the attestation is inaccurate. This guide explains the five SWIFT CSP architecture types, how to determine which one fits your environment, and why the 2026 cycle is moving some institutions from one type to another.
What SWIFT CSP Architecture Types Are
SWIFT CSP architecture types are a classification of how your institution connects to and operates within the SWIFT network, based on which components you own and run. The classification exists because the security controls that make sense for an institution running its own messaging and communication interfaces are different from those for an institution that only accesses SWIFT through a provider. Your type sits at the foundation of your assessment, because it decides control applicability, assessment scope, and evidence expectations. For the wider context of where this fits, see the overview of the SWIFT CSP framework.
The Five SWIFT CSP Architecture Types
There are five SWIFT CSP architecture types, four in the A group and one B type. The A group covers institutions that operate some form of local SWIFT infrastructure, while Type B covers those that do not.
- Type A1: you own both the communication interface and the messaging interface. This is the broadest footprint and carries the most controls.
- Type A2: you own the messaging interface but not the communication interface.
- Type A3: you use a SWIFT connector for application-to-application communication.
- Type A4: application-to-application connectivity with service-provider hosting.
- Type B: no local SWIFT-specific infrastructure, with access through a GUI or application only.
Across all of the SWIFT CSP architecture types, the principle is consistent: the more SWIFT-related infrastructure you own and operate, the more controls apply and the more evidence you must produce.
How to Determine Your SWIFT CSP Architecture Type
Determining your type is not an administrative formality, and the most reliable approach is to map your environment rather than rely on a label from a prior year. The question to answer is which systems actually create, process, transfer, store, or route SWIFT-related messages or payment instructions.
That means reviewing your network and architecture diagrams, your SWIFT infrastructure components, any middleware and integration platforms, any APIs or file transfer mechanisms, your payment processing workflows, your service-provider connections, and the downstream systems that interact with SWIFT-related data. Trace how SWIFT messages actually move through the environment, including indirect pathways and operational dependencies. A surprising number of institutions operate under SWIFT CSP architecture types carried forward from prior years that no longer reflect how their environment actually works.
Why Architecture Type Determines Your Controls
SWIFT CSP architecture types matter because the framework does not apply every control to every institution. The set that applies, and whether each control is mandatory or advisory, depends on your type. A control can even be mandatory for one architecture and advisory for another. That is why two institutions can read the same framework and face different obligations, and why your assessment scope cannot be defined until your type is confirmed. The full breakdown of what each control requires is covered in the guide to the SWIFT CSP controls.
How 2026 Changes SWIFT CSP Architecture Types
The 2026 cycle introduces a shift that many institutions are not anticipating: some that attested as Type B may now need to reclassify to Type A4. The reason is that customer-client connectors and back-office data flows are now in scope. An institution that classified itself as Type B because its SWIFT infrastructure appeared isolated, but that runs standing batch file transfers, middleware servers, or automated scripts moving payment messages into downstream systems, may now have those connectors and flows considered part of its in-scope SWIFT-connected environment. That points to Type A4. The institution made no changes to its technology. The framework changed. The full set of 2026 changes is covered in the guide to SWIFT CSP 2026.
Not certain which type fits your environment? Book a SWIFT CSP gap review with one of Elevate Consult’s certified assessors and confirm your classification before you start.
The Cost of Getting Your Architecture Type Wrong
Misjudging your type is one of the most consequential mistakes in a SWIFT CSP assessment, and it cuts both ways. Under-scoping means you miss controls that apply to you, so your attestation is inaccurate and you carry risk you have not addressed. Over-scoping means you spend resources on controls that do not apply, creating confusion about what actually matters and burning time you do not have before the window closes. In both cases, the attestation does not reflect reality.
The deeper issue is that everything downstream depends on this one decision. If your type is wrong, your scope is wrong, your evidence requirements are wrong, and your remediation plan targets the wrong controls. That is why confirming your type is the first item on any preparation plan, and why it should be validated independently rather than assumed. The practical steps that follow are laid out in the SWIFT CSP audit checklist.
Common Architecture Classification Mistakes
A few patterns account for most mistakes in assigning SWIFT CSP architecture types. The first is relying on the label from last year’s attestation without re-examining the environment, even though new integrations, a vendor onboarded mid-year, or a change in how payments are processed can shift the type. The second is treating the SWIFT interface in isolation, classifying based on the hardened secure zone alone while overlooking the middleware, file transfers, and downstream systems that also handle SWIFT-related data. The third is assuming that because a provider operates part of the infrastructure, the institution sits in a lower type with a lighter scope, when in fact the connectors feeding that provider may pull it into Type A4. A fourth is confusing being a Type B institution with being out of scope entirely, when Type B still carries controls, just fewer of them. Each of these mistakes leads to the same place, an attestation that does not match the real environment, which is exactly what an assessor is trained to catch. The safeguard is simple in principle: classify from the data flows up, not from the label down, and validate the result independently before building the rest of your assessment on it.
How to Confirm Your SWIFT CSP Architecture Type
The most reliable way to confirm your classification is to validate it independently against current CSCF guidance and your actual transaction ecosystem, rather than starting from the assumption that last year’s type is still correct. This is exactly the exercise a qualified assessor runs at the start of an engagement, tracing how SWIFT messages move and identifying every system in scope before any control is assessed. Elevate Consult’s certified assessors provide this validation as part of a structured readiness review through the SWIFT CSP assessment services page.
Key Takeaways
- There are five SWIFT CSP architecture types: A1, A2, A3, A4, and B.
- The A types operate some local SWIFT infrastructure, while Type B has none and uses GUI or application access only.
- Your type determines which controls apply, your assessment scope, and your evidence requirements.
- For 2026, some Type B institutions may need to reclassify to Type A4 because connectors and back-office flows are now in scope.
- Getting the type wrong makes the attestation inaccurate, so confirm it independently before anything else.
Frequently Asked Questions
What are the SWIFT CSP architecture types?
There are five SWIFT CSP architecture types. Type A1 owns both the communication and messaging interfaces, Type A2 owns the messaging interface only, Type A3 uses a SWIFT connector for application-to-application communication, Type A4 uses application-to-application connectivity with service-provider hosting, and Type B has no local SWIFT-specific infrastructure and uses GUI or application access only.
How do I determine my SWIFT CSP architecture type?
Map your environment to identify which systems create, process, transfer, store, or route SWIFT-related messages, and trace how those messages actually move, including indirect pathways. Do not rely on a classification carried forward from a prior year, because it may no longer reflect your environment.
What is the difference between Type A and Type B?
Type A institutions operate some form of local SWIFT-specific infrastructure, such as a messaging or communication interface or a SWIFT connector. Type B institutions have no local SWIFT-specific infrastructure and access SWIFT through a GUI or application only, which means fewer controls apply.
Can my architecture type change for 2026?
Yes. Because customer-client connectors and back-office data flows are now in scope for 2026, an institution that attested as Type B but runs connectors, middleware, or automated flows touching SWIFT data may need to reclassify to Type A4, even though its technology has not changed.
Why does architecture type matter for a SWIFT CSP assessment?
Because it determines which controls apply, whether each is mandatory or advisory, the scope of the assessment, and the evidence you must produce. If the type is wrong, the scope, evidence requirements, and remediation plan are all built on the wrong foundation.