That question is the foundation of the SWIFT Customer Security Controls Framework (CSCF), because the controls that apply to a bank, financial institution, or other SWIFT user depend heavily on the way its messaging infrastructure is deployed and operated.

This is where SWIFT architecture types come into the picture. SWIFT categorizes users into five primary architecture types: A1, A2, A3, A4 and B. Although these labels can appear deceptively technical, they are essentially a way of describing the institution's connectivity model — what SWIFT-related infrastructure exists within the institution's environment, what is operated by a third party, and how messages or transactions move between internal systems and SWIFT services.

Getting this classification right is more important than it may initially seem. Architecture type influences the scope of the CSCF, the controls an institution needs to address, the systems that fall within the assessment boundary, and ultimately the evidence that must support the institution's SWIFT security posture. The better question institutions should be asking isn't "do we use SWIFT on-premises?" — it's: how does your institution actually connect to SWIFT, and which components are under your control?

Why SWIFT Architecture Classification Matters

Architecture classification is sometimes treated as an administrative step near the beginning of the annual SWIFT CSP attestation process. In practice, it is much closer to an architectural and cybersecurity decision — because the architecture determines the technology potentially exposed to SWIFT-related risk, and therefore helps establish which security controls are relevant.

An institution that operates its own messaging and communication interfaces has security responsibility that extends into infrastructure it directly manages — network segmentation, operating system security, privileged access, and vulnerability management all become central concerns. Compare that with an institution with no SWIFT-specific infrastructure locally, accessing SWIFT services through a provider. Its technical footprint is different, and so is the set of controls that directly apply. That doesn't mean the institution has no cybersecurity responsibility — rather, some of that responsibility shifts toward understanding and managing the dependency on the service provider.

SWIFT's architecture model is therefore not simply a measure of how "advanced" or "secure" an institution is. It is a way of establishing where security responsibility sits — a distinction that matters most during an independent assessment, when a classification that looked convenient on paper can become problematic once an assessor begins tracing actual systems, interfaces, data flows and ownership arrangements.

The Five SWIFT Architecture Types, In Detail

The five types can be understood as a progression from environments with substantial locally managed SWIFT infrastructure to environments with little or none of their own. The real classification, though, depends on the precise implementation, not just where an institution sits on that spectrum.

Where Does Your Institution Fit?

Knowing that a service bureau is used, or that some services have moved to the cloud, doesn't by itself determine architecture type. The classification needs to follow the actual connectivity model — which means mapping the journey of a SWIFT-related transaction rather than choosing the label that matches a preferred operating model.

This is why architecture assessment should ideally involve more than the compliance team. Network architects, infrastructure teams, application owners, payment operations, and cybersecurity personnel may each hold a piece of the answer.

Architecture Classification Isn't Permanent — and Isn't a Ranking

One common misconception is that an institution's architecture type is a fixed characteristic. It is not. Migrating infrastructure to a hosted environment, replacing a service bureau, introducing middleware, or moving from a locally operated interface to a cloud service can all change the classification. An institution should not simply copy the previous year's selection because the infrastructure "hasn't changed much" — architecture should be reassessed whenever the connectivity model changes, not merely when the compliance calendar says it's time.

It's also tempting to look at A1 through B as a ladder, with A1 as the "best" architecture and B as the "least secure." That interpretation is misleading. The types describe different technical arrangements, not a security maturity ranking. An A1 institution has extensive infrastructure to secure directly; a Type B institution depends heavily on the security and operational maturity of its service provider. In both cases, security depends on how effectively responsibilities are understood and implemented.

What Happens If an Institution Gets Its Architecture Type Wrong?

This is why architecture classification should be evidence-based — network diagrams, application inventories, system ownership records, service-provider documentation, and data-flow diagrams all help establish the actual architecture, rather than the one that's most convenient to claim.

Final Thoughts

The most useful way to approach SWIFT architecture types is not as five labels to memorize, but as five different ways of understanding responsibility. A1, A2, A3, A4 and B describe different technology and connectivity arrangements, helping establish which parts of the SWIFT environment are locally operated, which are provided by others, and which security controls need to be considered.

Ultimately, the question is not whether your institution wants to be A1, A2, A3, A4 or B — it's which architecture accurately describes the way your institution connects to SWIFT today. Once that answer is clear, the rest of the SWIFT CSP assessment becomes considerably easier to understand.

Frequently Asked Questions