If you have ever wondered how the established protocols work so that our money travels from one part of the world to another with maximum reliability, this is the article where you will find the answer.

After my previous talk at the conference 101 Panel Tech Days (puYou can see the video here), I got down to work and, by hitting the keys on my computer, I have managed to synthesize a complex subject such as SWIFT messaging in a few words. I hope it helps you.

To get started, a brief introduction to SWIFT messaging.

What is SWIFT? For many of you, hearing it, the imagination will lead you to the latest in the development of applications for Apple environments. And the truth is, you are right. Google sometimes misleads us. If we launch a query with the term SWIFT, the first links that the famous search engine returns refer to the aforementioned programming environment. We will have to go down a few lines until we find the SWIFT that we are looking for and the object of this post.

Let's do a bit of hindsight. Quiet we will not go very far, only a few decades. In those years, there were only a handful of banks. The relationship between them used to be quite rare and when a client was unfaithful, it was enough to cross a street and carry the money to the neighboring bank in hand. With the passing of the years, growth, new technologies and the emergence of new actors, caused both the number of users and financial entities to grow exponentially. The multiplication of products and services accentuated the complexity and the number of transactions that had been carried out. To solve the inherent difficulties that appeared in this new scenario, a series of banks and financial entities decided to meet and create a new figure; an intermediary. Someone to add and subtract. Someone who could be trusted. Someone to help and add value throughout this process. Out of all these needs emerged the clearing houses. We are not going to elaborate any further on your presentation. It is enough for us to know that there are chambers at the local, territorial and global levels.

SWIFT can be considered within the latter category, although it is not a common clearinghouse. Rather, it is a set of protocols and actions that solve the problems raised in the complex world of interbank communications.

In this link you can see what SWIFT (Society for Worldwide Interbank Financial Telecommunication) says about herself.

From the previous definition, we are going to stay with that SWIFT is a platform that provides its members with a series of products and services aimed at standardizing a reliable and secure communication protocol for their financial operations.

Are there other alternatives? The answer is yes. Although it is beyond the scope of this article. Comment very in passing that there are other entities that operate similar to SWIFT. If we look at the geographical classification that we have discussed previously; we would have at the local level: IBERPAY; operates with affiliated entities only in Spain. At the territorial level, we would have EBA; a clearinghouse that establishes a series of protocols for entities with visibility in Europe. Both establish communication protocols that guarantee the reliability and security of the operations carried out through their systems.

But let's get back to SWIFT and dive into the ins and outs of its protocols and standards.

The SWIFT Architecture

How do you think SWIFT provides its communication services to its members? In fact, it is quite simple and complex at the same time. It seems like a contradiction, but it is not. They have implemented a very simple communication service that allows them to establish very complex security protocols, which guarantee the confidentiality of the transaction. Without going into much detail (it is not relevant), comment that the transport method used, in most cases, is based on a standard communications messaging structure, such as MQ or JMS.

The financial message uses the power of these messaging structures: reliable, asynchronous and independent, to travel from one point to another. Responsibility for sending and receiving the financial message rests with said communication infrastructure. SWIFT will be exclusively responsible for the proper management in the formation of the content of the message.

SWIFT message structure.

As we have already mentioned, SWIFT provides a series of services to facilitate communication between entities, it is what is known as FIN SERVICE (Financial Services). Let's review the possible scenarios:

The simplest communication is between a sender -> SWIFT -> receiver. The sender mounts the message and sends it to SWIFT. After validation, the message is sent to the receiver.

SWIFT - Standard FIN Service communication

The second scenario is the communication of the FIN Service type T. The differentiating model lies in the intervention of a Service administrator. The message is formed at the sender and sent to SWIFT where the administrator has the possibility to complete the message, notifying both the sender and the receiver. It should be noted that the message is not retained by the administrator on his journey.

SWIFT - FIN Service communication type T

Finally, we will analyze the Y type model, where FIN Service provides a message from the sender to the receiver, and in which the administrator either only notifies the sender or receiver, or can notify both and in turn retain the message until an authorization notification is sent or rejection, either by the sender or by the receiver.

SWIFT - FIN Service type Y communication

The detail of the SWIFT message.

The structure of the message, called END COPY (financial message model) is made up of five delimited blocks.

We will focus on the so-called user-to-user messages. It is mandatory that these messages consist of blocks 1, 2, 4 and 5, and the composition is very simple: a plain text file is mounted, which will contain the block structure described below:

{1: BASIC HEADER / HEADER BLOCK}

{2: APPLICATION HEADER BLOCK}

{3: USER HEADER BLOCK}

{4: TEXT BLOCK}

{5: FINAL BLOCK / TRAILER BLOCK}

• Blocks 1, 2 and 3 contain general and essential information about the message.
• Block 4 contains the particular text for the implementation of the financial message.
• Block 5 adds control information.
• Blocks 3, 4 and 5 can in turn contain sub-blocks, all of them separated by braces. They can also be made up of fields, named by a number.
•  The only block that must appear in all messages will be the header (Header Block).
• Blocks 2 to 5 will be optional. Depending on the nature of the message and the SWIFT application.

In order not to elaborate on the technical detail of the composition of the message, I have detailed all the structure of the different blocks in this document what can you download from here, if you are really interested 🙂

In short, and finally, SWIFT is a network made up of more than 8,000 banks, securities and corporations that are located in more than 200 countries, and that allows the exchange of millions of standardized financial messages between financial institutions throughout the world. What better climax to conclude this blog post than the numbers published by SWIFT, encrypting the closed activity of the year 2016: