Last Update date: July 2020

Decision tree to guide SWIFT users to determine

their CSP Architecture Type

Version date: 08 JULY 2020

Key changes since previous version (21 January 2019)

Section Change Date

Decision Tree Adding additional SWIFT 21 January 2019
products considered as A3
Decision Tree Clarified Middleware and 21 January 2020
Connector – rollback to v2019
Decision Tree Removed reference to SWIFT 08 July 2020
products as covered in the TIP
5024040

Purpose
This document proposes a decision tree to guide SWIFT users to determine their CSP Architecture
type. It is provided for information and illustrative purposes. While designed to provide useful
guidance to SWIFT users to determine their CSP Architecture Type, nothing in this document shall be
interpreted or construed as replacing or otherwise amending the Customer Security Controls
Framework and Customer Security Controls Policy. General principles (or Architecture Types) are not
given any restrictive meaning when they are illustrated with examples.
Audience
This document targets: (i) SWIFT users that need to determine their Architecture Type, (ii) firms
selected by SWIFT users to assist them in this exercise and, (iii) service bureaux that support their
customers in the determination of the Architecture Type.
Sections contents
# Section Contents
Guides the SWIFT user of FIN service (potentially with other
1 FIN Users services) to determine the Architecture Type use in their local
SWIFT Infrastructure.
Guides the SWIFT users of non-FIN messaging services (i.e.
Non FIN Users (i.e. SWIFTNet
2 InterAct, FileAct, or WebAccess (Browse)) to determine the
Users)
Architecture Type for their local SWIFT infrastructure.
SWIFT products & Architecture Replaced by Reference to the TIP 5024040
3
Types
Architecture Types for CREST Guides CREST users to determine their Architecture Type.
4
BICs
Provide Guidance to determine users’ Architecture Type for some
5 Exceptions
exceptional set ups.
Provide examples of Architecture Types for SWIFT users using a
6 Examples of Architecture Types (i), a group hub, (ii) service bureau, (iii) web service or (iv) shared
ARG

Ownership of Messaging and Communication Interface

The graphics below refer to the concept ownership of a Messaging or Communication interface. This
notion refers to the fact that there is always one (and only one) BIC code that owns the license of the
Messaging and Communication Interface software. In the rare cases when there is no notion of BIC
owner of the messaging Interface, SWIFT recommends that the user who owns (or the one operating)
the communication interface to self-attest as A1 while the other BIC codes attest as A2.
Multiple Architecture Types
• On some occasions, users can have a separate Architecture for FIN and for SWIFTNet
messaging service services (i.e. InterAct, FileAct, or WebAccess (Browse)). In this case,
SWIFT users need to complete their Architecture Type and/or service provider details for their
FIN infrastructure. Regardless of the above, the scope of the security controls need to cover
all in-scope components as set out in the CSCF, covering both the FIN and SWIFTNet local
infrastructure.
• Users who alternate between service providers need to complete their Architecture Type
and/or service provider details for their main infrastructure. For example, where the user
connects through different infrastructures located in different countries and traffic is swapped
on a regular basis, or where a switch is made to another infrastructure for disaster recovery
purposes.
• Also relevant in this context, the scope of the security controls covers all in-scope
components as set out in the CSCF, including all operational and any online backup or
disaster recovery infrastructures.
Recommendations on scope of applicability of the controls
Although not mandatory for the purposes of the attestation process, the security controls reflect good
security practice and it is appropriate to implement them beyond the in-scope environment into the
broader end-to-end transaction chain.
Categorising Middleware and API as Architecture Type B is in line with the scope of the security
controls which excludes user back office and middleware applications. SWIFT, however, strongly
recommends implementing the Architecture Type A3 controls on these middleware and API
applications.
AU-NPP and GLI users are not SWIFT users and consequently not in the scope of the CSP program.
Customer applications and Messaging and Communication Interfaces
Certified Messaging and communication interfaces are listed on swift.com. For SWIFT customers, the
most common Communication Interface is “SWIFT Alliance Gateway” and the most common
Messaging Interfaces are “SWIFT Alliance Access (SAA)” and “SWIFT Alliance Messaging Hub
(AMH)”
The following table determines cases when a customer application connecting to SWIFTNet Link or a
communication interface needs to be considered as a Messaging Interface (MI) or a Communication
Interface (CI): Customer applications using RAHA in relax or strict mode are subject to mandated
SWIFTNet protocol constraints, these applications are subsequently considered as Messaging
Interface.
 Start

1. FIN USERS
Go to Section Non
Fin User No
FIN Users

Yes

Owner of the CI Owner of the

No Yes A2
? MI ?
Yes

No

Application-to-application flow
Yes
from BO?

Using a
yes A3
No (user to application flow) connector

A1

B
No
(Using Middleware or API)

B
 Start

2. NON FIN
USERS FIN users Yes
Go to Section FIN
Users

No

Owner of the CI Is the application connecting

A1 Yes No No (BO to CI Flow)
? to the CI a MI ? (*)

Yes

Owner of the
No
MI ?
Use
connector?
Application-to-application flow
from BO ?
Yes
No
Yes

Using a
yes A3
connector

Yes B

No
(Using Middleware or API)
No
(user-to-application flow)

A2
B

A3
(*) See Introduction to determine cases when a BO connecting to a MI is
to be considered as a CI
3. SWIFT Products & Architecture Types

Consult Tip 5024040

4. Architecture Types for CREST
BICs

Start

CREST BIC shares the SAA

No Instance with another service Yes B
BIC (e.g. FIN)?
For the Architecture
Type of the BIC code
related to the non
Is this BIC Owner CREST service and
of the SAG sharing the same
yes
instance – please refer
No to the FIN or Non Fin
users Section

A2 A1
 5. Exceptions
- In the rare cases when customers own only the Communication Interface and not the
Messaging Interface, controls A1 apply to the components in scope
(including the Communication Interface and the GUI as appropriate).

- Users having a SWIFTNet infrastructure of Architecture Type A and a FIN Architecture

Type B, will select the A type in their self-attestation.

- Users of a messaging interface with no notion of owner BIC of the license, need to
define the BIC owner of the communication Interface as A1 while the other BIC codes
defined on the same messaging Interface need to attest as A2
- Shared ARG customers, i.e. using the Access owned by an ARG customer must select
the A3 or B architecture type.
6. Examples of Architecture Types
1. Group Hub Set ups
Architecture Type A1

Owner of Alliance Access and Alliance Gateway =

XXXXBEBB (Architecture Type A1)

Scope of security controls

Alliance Web Platform

Alliance Access

Alliance Gateway

SWIFT network
SWIFTNet Link

HSM PKI

Examples of Architecture Types

 BIC connecting to a central SWIFT Group hub infrastructure – Architecture Type A2

BIC Group Hub XXXXBEBB (Architecture

(Architecture Type A2) Type A1)

Scope of security controls for

General XXXX BEBB
Enterprise IT End User
Environment

(*)
Scope of security controls Alliance Web Platform

Alliance Access

Alliance Gateway
Alliance Access
SWIFT network
SWIFTNet Link

Admin HSM PKI

Examples of Architecture Types

(*) The Alliance Webplatform could be on the BIC or group hub side
BIC connecting to central SWIFT hub infrastructure – Architecture Type A3

BIC Group Hub XXXXBEBB (Architecture

General (Architecture Type A3) Type A1)
Enterprise IT
Environment Scope of security controls

End User

Alliance Access Alliance Web Platform

Back Connector
Office Data exchange
(e.g. FTP)
Application
Alliance Gateway

SWIFT network
SWIFTNet Link

Admin HSM PKI

Scope of security controls

Examples of Architecture Types

BIC connecting to central SWIFT hub infrastructure – Architecture Type B

BIC Scope of security controls Group Hub XXXXBEBB (Architecture

Type A1)

Scope of security controls of

XXXXBEBB
End User

Alliance Access Alliance Web Platform

Alliance Gateway

SWIFT network
SWIFTNet Link
General
Enterprise IT
Environment
HSM PKI

Examples of Architecture Types

2. Service Bureau
Institution connecting its Messaging Interface to a Service Bureau – A2

General Enterprise IT Environment

SBXAXXXX

Scope of Security Controls Scope of security

Local SWIFT Infrastructure

Messaging Communication
Interface Interface

Back Office
RMA SNL
or Data exchange
Middleware

HSM PKI
GUI
SWIFTNet

End User Admin

Service Bureau
SWIFT User

Examples of Architecture Types Subject to CSP controls Subject to SIP Program 8

framework
Institution connecting its Messaging Interface to a Service Bureau– A3 – File
server solution
SBXAXXXX
General Enterprise IT Environment
Scope of security

Scope of Security Controls

Messaging
Interface
Local SWIFT Infrastructure
RMA

Communication
Back Office
Data exchange Interface
or Connector
Middleware
GUI

SNL
SWIFTNet
HSM PKI

End User Admin

SWIFT User Service Bureau

Examples of Architecture Types Subject to CSP controls Subject to SIP Program 9

framework
Institution connecting its BO to a Service Bureau– Architecture Type- B Subject to CSP controls framework.
Strongly recommended to consider
A3 controls for Back Office and
Middleware
General Enterprise IT Environment

Scope of Security Controls Scope of security SBXAXXXX

Messaging
Interface
Admin End User RMA

Communication
Server Environment Interface

GUI
Back Office Data exchange
or
Middleware SNL
SWIFTNet
HSM PKI

SWIFT User Service Bureau

Examples of Architecture Types Subject to SIP Program 10

User connecting through a L2BA – Architecture Type- B
In scope of CSP Program (CSCF)
Scope of Security Controls

https
End User
General Enterprise IT Environment

Server Environment

Scope of Security

GUI
Alliance
Lite2
Alliance
Lite2
Admin
SWIFT network

Business MultiBic
Back-Office Application AutoClient

SWIFT User SWIFT as

(e.g Corporate) L2BA
Service Provider
11

In scope of L2BA Program

3. Users of a Browse service
Browse service - Architecture Type A1 (Stack with no own Messaging Interface)

Scope of security controls

Alliance Web Platform

RTGS

End User
Alliance Gateway
SWIFT network

SWIFTNet Link

HSM PKI

13

Examples of Architecture Types

4. Shared ARG
Shared ARG – Architecture Type B

BIC ARG Customer (Architecture Type

General (Architecture Type B) A2)
Enterprise IT
Environment Scope of security controls

End User

Alliance Web Platform

Alliance Access
SWIFT network

Scope of security controls

15

Examples of Architecture Types

Shared ARG – Architecture Type A3

BIC ARG Customer (Architecture Type

General (Architecture Type A3) A2)
Enterprise IT
Environment Scope of security controls

End User

Alliance Web Platform

Back
Office Data exchange Connector
Application (e.g. FTP)
Alliance Access
SWIFT network

Admin
Scope of security controls

16

Examples of Architecture Types