SWIFT Architecture Types: A Clear Guide to All 5 Types

SWIFT architecture types decide how much of the Customer Security Controls Framework you have to implement. Get the classification right and your control set is settled for the year; get it wrong and you have either done work you never needed or attested to controls you were never assessed against.

This guide covers the five types, what determines yours, what changed for the 2026 framework, and how to document the decision so an assessor accepts it.

The five SWIFT architecture types

The five SWIFT architecture types are separated by one question: which components of the messaging chain sit inside your own secure zone, under your control, rather than at a service provider.

The control sets for A1, A2 and A3 are identical, so the practical distinction inside type A is smaller than the labels suggest. Fewer controls apply to A4, and fewer again to B — but the operator PC, the credentials and the local environment stay in scope for every type, which is where B users are most often surprised.

What actually decides your type

• Do you host a messaging interface? Alliance Access, Alliance Entry or an equivalent product on infrastructure you run.
• Do you host a communication interface? Alliance Gateway or equivalent.
• Is there a SWIFT connector on your side? Alliance Lite2 AutoClient, Direct Link, Microgateway or a comparable component.
• Is there any customer connector? Software you own that transmits transaction data to a service provider — middleware, a file transfer agent, a payment hub component.
• If none of those exist, you are type B, and your scope is the operators, their PCs and the credentials they use.

What changed for CSCF v2026

The framework is republished every July, and the 2026 version defines 32 controls: 26 mandatory and 6 advisory, across three objectives and seven principles. Two of the changes bear directly on SWIFT architecture types.

First, control 2.4 on back office data flow security moved from advisory to mandatory, so protecting the flow between back office applications and the SWIFT infrastructure is no longer optional.

Second, the treatment of customer connectors tightened. Organizations that considered themselves type B because nothing SWIFT-branded sits on their estate may find that a connector they already own puts them into A4 — a materially larger control set, and one that has to be assessed before the attestation window closes on 31 December.

The attestation itself runs annually through the KYC-SA application and must be supported by an independent assessment, which can be performed internally provided the assessors are independent of the operations they review. Our guide to the SWIFT CSCF covers that route in detail, and the attestation process covers the submission itself.

Documenting SWIFT architecture types so the classification holds

1. Draw the diagram. Every component from the back office application to the SWIFT network, marked with who owns and who operates each one. The diagram is the evidence for the classification, and an assessor will ask for it first.
2. List what sits in the secure zone. Interfaces, connectors, jump servers, the operator PCs and the management path into them.
3. Name the service providers. Which components they run, and what their own attestation covers — a provider’s compliance does not cover your side of the boundary.
4. Record the reasoning, not just the answer. A short note explaining why you are A4 rather than B is what protects the classification when the assessor disagrees.
5. Re-test the type annually. A new payment hub, a cloud migration or an outsourcing deal can move you between SWIFT architecture types without anybody noticing until attestation.

The misclassification that costs the most

Claiming type B while operating a customer connector. It removes a substantial block of controls from your assessment, which is exactly why it is scrutinised — and the correction lands in December, when there is no time left to implement what was skipped.

Frequently asked questions

How many SWIFT architecture types are there?
Five: A1, A2, A3, A4 and B. Types A1 to A3 share the same control set; A4 and B have progressively fewer applicable controls.

Who decides our architecture type?
You do, and you attest to it. The independent assessment tests whether the classification matches the environment.

Does using a service bureau make us type B?
Not automatically. If any connector transmitting transaction data sits on your side, you are likely type A4. Type B means no SWIFT-specific infrastructure of your own at all.

Do advisory controls have to be implemented?
No, but they are published in advance of becoming mandatory. Control 2.4 becoming mandatory in v2026 is the pattern: today’s advisory control is a reasonable prediction of tomorrow’s requirement.

Can our architecture type change mid-year?
Yes, and if it does you assess and attest against the environment as it is. Infrastructure changes are worth planning around the July-to-December attestation window rather than into it.

Where this leaves you

Settle which of the five SWIFT architecture types you are before you plan any CSCF work, because it determines the size of the job. Draw the component diagram, record who owns each piece, and write the reasoning down. Re-check the classification every year and after any change to connectors, hosting or providers — and treat the 2026 tightening around customer connectors as a prompt to test whether type B is still the honest answer.

References

• SWIFT Customer Security Programme — the framework, the attestation process and the published CSCF document.
• Swift — understand the controls — determining which controls apply to your setup.

More on SWIFT security

• SWIFT architecture types — you are here
• The SWIFT CSCF explained
• The SWIFT CSP attestation in five steps
• Defining a security scope

Architecture diagrams, scoping worksheets and the control evidence set are in the SWIFT CSP Compliance Toolkit, or start with the free ISO templates.