Image of correspondent Baning and SWIFT

Strategy #3 to understand how cross border payments work

This article is about the third strategy to understand how cross border payments work: Understand the role of the SWIFT Network and the SWIFT standards.

In case you have not read the introductory article and the article about the first and second strategies, I strongly recommend you to read them so that you can easily connect the dots and understand how cross border payments work. In this article, we will first do some history and see how the situation was before SWIFT, then we will present the major problems that arose and look at the solutions SWIFT offered to address them.

The situation before SWIFT

We saw in the previous article that Banks access payments systems in foreign countries by setting up correspondent relationships and becoming customers of banks in those countries.

As customers, banks have the following basic needs:

  1. Instruct their correspondents to transfer funds from their account(s) to beneficiaries
  2. Receive funds on their accounts
  3. Receive reporting about payment execution
  4. Receive account statements
  5. And so on.

Banks and their correspondents must therefore exchange a lot of information. Various means were used in the past for that purpose: Phone, Fax and Telex. These were fairly handy at the start. But with the time, two major problems arose and they were worsened with the fast growing international trade.

First, telex, phone and fax messages are not secure. A fraudster can easily send a message and pretend to be someone else. Or he can just spy on messages carrying confidential information. In the financial world, it is not acceptable and that situation could even slow the development of international trade.

Second, messages received through these channels require a lot of manual work to carry out the payment orders or to process the reporting and account statements. Humans are prone to errors and mistakes. And this results in many delays and rework causing customer unhappiness and increasing the costs.

The major role of SWIFT

SWIFT was created to address these two problems in correspondent banking relationships: security of the message transport and automation for the message processing. The security challenge is met through its network called SWIFTNet and the automation issue is addressed through standardization.

Security is a major pilar in SWIFT success, but remains a concern

Image of Banks and the SWIFT Network
Banks exchange financial information through the SWIFT highly secure Network

SWIFTNet carries financial messages in a highly secure way from one party to another over the network. SWIFT has set up a Public Key Infrastructure (or PKI) since the early days to enable secure communication among its participants. All communication going through SWIFTNet is highly encrypted, so that an external party cannot spy on the message or forge it.

The PKI allows among others the management of digital certificates and public-key encryptions for the member banks and corporations. Before exchanging financial messages, the parties must exchange their certificates or keys. This is done via the Relationship Management Application (RMA) that replaced the Bilateral Key Exchange (BKE) encryption scheme. RMA is also used to manage which message types are permitted in the communication between users of a SWIFT service. The receiver specifies which message types are permitted, and sends this permission data to the sender. The sender checks the message type against the permission data before sending a message to the receiver.

At the beginning, SWIFTNet was used to transport financial messages. Nowadays, SWIFT also provides services for the transfer of high value documents, such as commercial contracts, in a safe and efficient manner around the globe.

Despite all the work and precautions, security remains a major preoccupation of SWIFT today. Fraudsters still find ways to trick banks and people out of their money using very sophisticated means. So it is a constant challenge for SWIFT to keep the network secure. Despite all that, SWIFT remains the world’s leading provider of secure financial messaging services. As of 2016, SWIFT linked more than 11,000 financial institutions in more than 200 countries and territories, who were exchanging an average of over 28 million messages per day (See Highlights 2017 on the SWIFT website).

SWIFT makes automation possible through Standardization

Before SWIFT, payment orders from different countries did not carry the same information and there were a lot of misunderstandings about how to interpret the information. Communication was really difficult. Standards were therefore needed to enhance the communication among banks. A standard is a widely accepted, agreed upon, or established definition of what something should be. SWIFT MT is a Financial Messaging standard, a common language that financial institutions use for the exchanges of financial information with their customers and among themselves.

Standards define the structure and meaning of messages allowing banks to know what to expect in payment orders, reporting and account statements. And even more interesting, computers can “understand” standards since information is transmitted in a harmonized manner. That enables the message processing to be partially or completely automated.

Automation can allow to process payments messages STP (Straight-Through Processing) without human intervention at all. It is faster because the receiver quickly receives the funds, but cheaper as well since no human intervention means less error and less rework.

SWIFT plays a key role in messages standardization in the financial industry. The International Organization for Standardization (ISO) became involved and adopted the SWIFT message standard (MT) as an international standard. And SWIFT is the registration authority for the ISO 20022 standard.

In conclusion,

Image of correspondent Baning and SWIFT
Correspondent Banks are interconnected worldwide through the global SWIFT Network

[box type=”note”]SWIFTNet is a messaging system, not a clearing or settlement system.[/box]

SWIFT transports financial messages, but does not hold accounts for its members and does not perform payment clearing or settlement. In fact, SWIFT stands for Society for Worldwide Interbank Financial Telecommunication. The messaging service is supported by SWIFTNet, the SWIFT global IP-based network for secure and reliable communication.

SWIFT developed a message standard (SWIFT MT) which has been adopted as international standard to help financial institutions to automate messages processing and streamline their processes. SWFT is involved in many standardization initiatives for the financial industry worldwide.

With this brief but important presentation of SWIFT role, we made another important step towards understanding how cross border payments work. But one piece of the puzzle is still missing: the foreign exchange market. What is it? And how do banks use it in cross border payments? You will have the answer to these questions in the next article. Subscribe to the newsletter you will receive a mail when it is available.

10 thoughts on “Strategy #3 to understand how cross border payments work”

  1. Praveen Bhosale

    A simple and apt explanation of SWIFT to begin with. Thanks Jean for providing all the required information at one place!!
    Would love to see some comparisons and mappings between SWIFT MT and MX messages.
    Good luck!

    1. Thanks!
      I take note of it and will work on it.
      You will be informed when a solution will be available.
      Regards!

  2. What is the role of the Clearing System of the respective countries involved in a cross-border payment.
    Example – A cross border payment between individuals from US and France

    1. The Clearing systems can be used to settle the cover payment which move funds from the Sender’s correspondent to the receiver’s correspondent. Both are located in the same country and therefore a local clearing system can be used.
      Let me know if you have further questions.

  3. So, is it possible that a Brazilian bank could instruct its correspondent in France to make a EURO payment to the customer of a German bank, using SEPA or similar, rather than a MT 202 COV?

    1. Hi William,
      I have been busy these days.
      Yes you got it. 🙂 That is absolutely possible. And that is what happens most of the time.
      It is cheaper to use the local clearing systems than to go over the SWIFT network.

  4. Hi Jean,
    Thanks for wonderful article.
    I have two queries , when I am doing internet banking within my country then does that payment request sent to other bank over swift network ? If not then which network bank uses for local payment ? What would be the message format ?
    Does swift network is only used for crossborder payment ?

    1. Hi Ash,
      In payments, you need to distinguish domestic payments and cross-border payments. Domestic payments go through domestic networks. Banks in a country are interconnected to Clearing and settlement systems using various communication protocols, technical solutions and infrastructures. They are really country dependent. The SWIFT network was originally created for Cross-border payments and up to these days, the vast majority of cross-border payments go through the SWIFT network.
      So if you send money within your country, it will not go over the SWIFT network. Local payments usually use local formats based on flat or XML files. Cross-border payments use SWIFT MT format. They will move to SWIFT MX format that is based on the ISO 20022 standard.

  5. Hello Sir,
    The {next article} link appears to have broken or taken down.
    Could you please provide the missing piece of the puzzle.

    1. The link is now working. For some reason it did not come up yesterday. I had tried clicking on the all possible navigation options (link in main article, bread Crumbs etc)
      It’s working today. Many thanks of you did something to fix this. And thankyou for summing up the CBPR concept so wonderfully

Leave a Comment

Your email address will not be published. Required fields are marked *