The SWIFT environment in a nutshell
A typical SWIFT customer environment consists of a combination of individual components that interact with each other to provide messaging services. Use this section as your reference and your glossary.
| FIN CBT | Software product that processes and that exchanges FIN messages, by using the FIN application through the SWIFT network. Alliance Access and Alliance Entry are FIN CBT products that are provided by SWIFT. As of now, these CBT products also offer the functionality to send messages for your Solutions through the Alliance Messenger interface. |
| SNL | SWIFTNet Link. Mandatory SWIFT software component that is required in order to connect to SWIFTNet. |
| RA | Remote API. SWIFT middleware component that is used in order to link back-end applications and workstations to Alliance Gateway, which acts as the messaging concentrator. |
| MQ | Message Queue. IBM middleware component that is used in order to link back-end applications through the Alliance Gateway. |
| HSM | Hardware Security Module. A hardware device that is tamper-resistant and that ensures the secure storage and the processing of PKI secrets. HSMs replace the current Secure Card Rearders and the ICCs. There are three types of HSM devices: HSM boxes, HSM tokens, and HSM cards and card readers. Only one type of HSM is supported on the same SWIFTNet Link. |
| HTTPS | Secure Hypertext Transport Protocol. A protocol that is used in order to access web servers that are hosted on SWIFTNet. The HTTPS proxy, which is a part of Alliance Gateway, is used for routing purposes. |
| Vendor product | Product that is offered by a SWIFT partner and that allows to connect to additional services hosted on SWIFTNet. These products have an embedded SWIFTNet Link, or they connect to Alliance Gateway. |
| VPN box | Virtual Private Network hardware device. Mandatory SWIFT network component for the connection to the multi-vendor secure IP network. A VPN box implements network security that is based on IPsec. |
| PKI | Public Key Infrastructure certificate. SWIFT acts as the certification authority on SWIFTNet. |
Four message flows for typical SWIFTNet services are described below. The diagram illustrates each message flow.
1. FIN using a FIN CBT with an embedded SWIFTNet Link
The basic FIN message flow consists of the following steps.a. FIN messages are built in the FIN CBT. FIN messages can be entered directly by using a screen-based message entry product, or they can be entered through a link to a back-office application.
b. The FIN CBT creates the SWIFTNet FIN protocol envelope for the message. Then it calls the local SWIFTNet Link software in order to request transportation through SWIFTNet.
c. The SWIFTNet Link encapsulates the message payload with a SWIFTNet message envelope, and sends it through an established TCP/IP connection to the VPN box.
d. The VPN box has established IPsec tunnels with the SWIFTNet central systems through the multi-vendor secure IP network. These tunnels are established over physical lines between your premises and the multi-vendor secure IP network Backbone Access Points.
e. The SWIFTNet central systems are connected to the FIN application servers at SWIFT, which send back a FIN response to the initial FIN CBT.
f. When a FIN ACK response message is received, you are assured that the FIN application will deliver the original message to the intended receiver. On the other hand, a NAK message indicates that an error occurred and that the message cannot be delivered to the intended receiver.
2. FIN using a FIN CBT through a Alliance Gateway
In a single-window infrastructure, based on Alliance Gateway, the message flow is similar to the flow that is described above. However, the step b is replaced by the following two steps:b1. The FIN CBT creates the SWIFTNet FIN protocol envelope for the message and sends it through the customer network to the Alliance Gateway, by using the Remote Application or the Message Queue software on the FIN CBT.
b2. The Alliance Gateway receives the message through the corresponding host adapter. Then it calls the local SWIFTNet Link software in order to request transportation through SWIFTNet.
3. Accessing a Browse service from an Alliance WebStation
Using an Alliance WebStation directly connected to SWIFTNet:a. The Browse services are offered by organisations that have a Web Server that is connected to the SWIFTNet network. The access to the external Web Server is accomplished by creating an HTTPS request on a standard Web Browser product that runs as part of the Alliance WebStation. This standard Web Browser product can be Internet Explorer or Netscape Navigator.
b. The HTTPS request is sent through a new TCP/IP connection to the VPN box. Then this request is sent further to the external Web Server.
c. The Web Server collects the data and responds to the HTTPS request. It returns the response to the Alliance WebStation browser.
4. An Alliance WebStation connected to an Alliance Gateway
Similar to FIN, other services can also be accessed through an Alliance WebStation that is connected to a single-window infrastructure that is based on Alliance Gateway. However, the step b is replaced by the following two steps:b1. The HTTPS request is sent through the customer network to the HTTPS proxy that runs on the Alliance Gateway.
b2. The HTTPS request is sent through the multi-vendor secure IP network to the external Web Server.
Similar flows are applicable for vendor applications and for other InterAct services or FileAct services.