A SWIFT architecture type is a classification, defined by SWIFT under its Customer Security Controls Framework (CSCF), that describes how an institution technically connects to the SWIFT network — specifically, which components (messaging interface, communication interface, connectors) the institution owns and operates versus which are managed by a service provider. Every SWIFT user must self-identify their architecture type as part of their annual CSP attestation, because the type selected determines exactly which of the framework’s mandatory and advisory security controls apply. Learn more about the 2026 SWIFT CSP changes here.
The core logic is straightforward: the more SWIFT-related infrastructure an institution owns and operates directly, the larger its attack surface, and the more controls it must implement and evidence. Institutions that rely heavily on service providers for their connectivity carry a narrower footprint of in-scope systems, but they inherit a different responsibility — verifying that those providers meet their own security obligations.
SWIFT currently defines five architecture types: A1, A2, A3, A4, and B. The “A” types all involve some degree of local SWIFT-related infrastructure, while Type B involves none.
In Architecture A1, the institution owns the communication interface and, in most cases, the messaging interface as well. This is the most infrastructure-heavy classification and carries the broadest set of mandatory controls, since the institution is directly responsible for securing the systems that physically connect to SWIFT.
Under Architecture A2, the institution owns and operates its messaging interface, but the communication interface license is held and managed by a service provider — commonly a service bureau or a Group Hub. This is a common setup for mid-sized institutions that want some control over message handling without operating the full connectivity stack themselves.
Architecture A3 applies where a SWIFT connector sits inside the institution’s own environment to enable application-to-application communication with an interface hosted at a service provider or through SWIFT-hosted services such as Alliance Cloud or Alliance Lite2. This setup can optionally be combined with a GUI-based access solution, in which case controls relevant to that graphical interface must also be applied.
Architecture A4, sometimes called the Customer Connector architecture, covers institutions that use a middleware or file transfer server within their own environment to establish external application-to-application connections with a service bureau, Group Hub, or SWIFT services, using a middleware or file-transfer server (or a customer connector) rather than a SWIFT connector. Fewer controls apply here than to A1, A2, or A3, though back-office systems generating the underlying transactions are still strongly encouraged to follow strong security practices even where they sit outside the strict CSCF boundary.
Architecture B applies to institutions with no local SWIFT-specific infrastructure at all. Access happens purely through a browser-based GUI or hosted application, typically exposed via Alliance Cloud or Alliance Lite2. Because there is no locally-owned messaging or communication interface, users under Architecture B are not required to comply with the controls that apply specifically to Architecture types A1 through A4 — though the operator PCs used to access these services must still be protected as general-purpose endpoints.
Correctly identifying an architecture type is not an administrative checkbox; it requires mapping how SWIFT-related messages actually move through the environment. This means tracing every system that creates, processes, transmits, stores, or routes SWIFT messages or payment instructions, and identifying which components are owned versus outsourced. Institutions should be cautious about assuming last year’s classification still holds, since infrastructure changes, service provider migrations, or new connectivity methods can shift an institution from one architecture type to another. SWIFT’s own Customer Security Controls Framework documentation, along with its decision tree resources, is the definitive reference point for this exercise, and many institutions choose to validate their self-assessment against an independent review before attestation.
Still confused? Book a free consultation to verify your architecture type and CSP requirements.
Architecture type is not simply a box to check for SWIFT’s annual attestation cycle; it is fundamentally a statement about where risk sits inside an institution’s payment infrastructure. An accurate classification ensures security investment is directed at the systems that genuinely carry SWIFT-related risk — the messaging interfaces, connectors, and operator endpoints that, if compromised, could enable exactly the kind of fraudulent instruction flow seen in past high-profile incidents. Misclassifying architecture type, whether by underestimating owned infrastructure or overlooking a service provider dependency, creates blind spots that can persist for an entire attestation cycle before they are discovered.
SWIFT architecture types exist to answer one deceptively simple question: who owns and operates the infrastructure that connects your institution to the world’s financial messaging backbone? Whether an institution falls under A1’s full ownership model, the service-provider-dependent A2 and A4 models, A3’s connector-based setup, or Architecture B’s browser-only access, the classification is the foundation on which the entire Customer Security Controls Framework is built. Financial institutions that treat this classification as a genuine architectural review — rather than a label carried over from the previous year — put themselves in a far stronger position to scope their controls accurately, pass independent assessment, and close the same gaps that have been exploited in real-world SWIFT-related fraud. Getting the classification right is the first and most consequential step toward a defensible, well-scoped SWIFT security posture.
This FAQ seeks to answer some of the most common questions and confusions about this topic.
There are five: A1, A2, A3, A4, and B, each defined by how much SWIFT-related infrastructure the institution owns versus outsources to a service provider.
Yes. Larger institutions with multiple connectivity setups across business units or entities can have a combination of architecture types, each assessed against its applicable controls.
Architecture A1 generally carries the broadest set of mandatory controls, since the institution owns and operates the communication interface directly.
Architecture B users are exempt from controls specific to A1-A4 infrastructure, but they still must secure the operator PCs and endpoints used to access SWIFT services.
Ideally every attestation cycle, and immediately after any infrastructure, connectivity, or service provider change that could shift ownership of SWIFT-related components.
Misclassification can leave critical systems outside the assessed security scope, creating compliance gaps and increasing exposure to the kind of fraud seen in past SWIFT-related incidents.
Rakesh Asthana is the founder of World Informatix Cyber Security and a veteran technology and security leader with over 30 years of experience safeguarding complex global institutions. As a former Senior IT Director and CIO for the World Bank, he led large-scale IT and cybersecurity transformations, strengthening resilience across highly regulated environments. Notably, he played a pivotal role in the incident response and digital forensics during the Bangladesh Bank cyber heist. This experience continues to shape his pragmatic, risk-driven approach to securing financial systems worldwide.
