Session 466 - CBPR+ Charges information

 Transaction charges are the charges that banks apply for the processing of customer payments.

Interbank transfers do not have associated charges, only customer payments do.

Each bank can decide at its discretion about its own price policy.

pacs.008 elements related to charges

 

How the charges-related information is presented in customer payment?

To answer this question, we have to consider the following elements of pacs.008:

Interbank Settlement Amount – this is the point-to-point currency amount that is settled between banks in one payment leg. This element may change throughout payment chain.

Instructed Amount – this is a conditional element that captures currency and amount instructed by the Debtor.

The Instructed Amount is present when Interbank Settlement Amount is in a different currency or amount. This may happen because of charges deduction or currency conversion. Instructed Amount cannot be changed in the payment chain.

Exchange Rate – this is a rate used for currency conversion. It must be present when currencies in Interbank Settlement Amount and Instructed Amount differ.

How the Exchange Rate is presented?

Instructed Amount currency is a base currency referred to as a whole unit to perform the exchange and the Interbank Settlement Amount currency is the quote currency.

If for example the Instructed Amount is in USD and the Interbank Settlement Amount is in EUR, USD 1 will be taken to show the exchange rate: 0.93998, because USD 1 equals EUR 0.93998.

Charge Bearer – this element specifies which party would bear the charges. Possible values in CBPR+ are:

CRED – Creditor

DEBT – Debtor

SHAR – Shared

Charges Information – this field provides information on the charges to be paid by the Charge Bearer. The meaning of this element is twofold. It shows either:

•     The amount of charges and the bank for whom the charges are due. This is a pre-paid scenario. In this scenario, the BIC of the bank for whom the charges are due is populated by the previous bank in the payment chain. The next bank upon receiving the message identifies its BIC and knows that the charges were pre-paid.
•     The amount of charges and the bank that has deducted the charges. In this scenario, charges were not pre-paid. Bank deducts its charges from the Interbank Settlement Amount and provides its BIC and amount deducted to inform the next banks in the payment chain.

This is a repetitive field and it may be added at each payment leg. As this element may show both charges pre-paid for Bank X, and in other business case charges deducted by Bank X, it is crucial that other charges-related information in the message (e.g. Interbank Settlement Amount and Instructed Amount) are used correctly.

Additionally it is important to note, that even that CBPR+ does not prevent Charges from being booked in different currency, for transparency the Charges in the message should be represented in the Interbank Settlement Amount Currency.

 

So, now, let’s have a look at how the information analyzed above is provided in the message itself: 

I hope that you can identify each element we discussed above.

However, I know that the business usage of these elements may not be clear for the time being. The theoretical explanation is not enough. But, I am sure it will become more understandable if we put it in the business context. And this is precisely the aim of the below examples.

The examples show the 3 charges options: DEBT, SHAR, and CRED.

While investigating them we are going to see how in practice banks levy their charges. 

 

DEBT

 

In this scenario, Bank A received the request for payment in EUR. The Amount is the EUR equivalent of USD 100.

The Instructed Amount is in USD, but the Interbank Settlement Amount is going to be in EUR. 

The Debtor’s account with Bank A is in USD.

Debtor informed Bank A that he will bear all the charges – DEBT option.

Three banks are involved in the payment. All of them have their own charges.

The below diagram depicts how the messages are structured.

 

(1) pacs.008 sent by Bank A

In our scenario, the Instructed Amount is USD 100.

The Instructed Amount is in USD and the Interbank Settlement Amount is in EUR. Instructed currency is used as the whole unit to perform the exchange, that is  USD 1 equals EUR 0.9401. This is our Exchange Rate.

EUR equivalent of the USD 100 is EUR 94.01. 

Bank A knows, however, Bank B’s charges for such a payment. They equal 10 EUR. In the message, Bank A adds EUR 10 to the EUR 94.01. So, the Interbank Settlement Amount is EUR 104, 01 (EUR equivalent of USD 100 + Bank B’s EUR 10 charges).

Additionally, Bank A signals to Bank B that the charges have been prepaid. How?

In Charges Information Bank A adds the BIC of BANK B (Agent – BANKFRBBXXX). This will indicate to Bank B that the charges have been pre-paid. Additionally Bank A populates the Amount that has been pre-paid (EUR 10).

What is not presented in the pacs.008 is what are the charges of Bank A for this payment. Let’s assume they equal USD 5.

In accordance with Debtor’s banking agreement Bank A will debit Debtor’s account for:

• USD 100 that the Debtor instructed
• USD 5 of Bank A’s charges
• USD equivalent for Bank B’s EUR 10 charges that have been pre-paid. As the Debtor’s account is in USD, any bookings on this account have to be reflected in USD.

(2) pacs.008 sent by Bank B

Bank B recognizes the pre-payment of charges by the inclusion of its BIC in the Charge Information Agent element. 

What is characteristic about the pre-paid scenario is also the fact that Interbank Settlement Amount is higher than Instructed Amount.

Bank B deducts its charges from the Interbank Settlement Amount. In the outgoing pacs.008 the Interbank Settlement Amount equals EUR 94.01 (EUR 104.01 – EUR 10). Now, the Interbank Settlement Amount is precisely the EUR equivalent of instructed USD 100.

Bank B removes the Charges Information as it is not needed for Bank C. If bank B left the Charges Information with Bank B’s BIC the information could be misleading for Bank C. The amounts presented would not add up.

(3) pacs.008 at Bank C

Bank C receives the payment and notices that the Charge Bearer code is DEBT. Bank C identifies that its charges have not been pre-paid. There is no its BIC in the Charges Information.

With DEBT option Bank C cannot deduct its charges from the amount it credits to the Creditor. In other words, Creditor receives EUR 94, 01 which is the EUR equivalent of USD 100 as instructed by Debtor.

Bank C may in such a situation claim the charges. Sometimes it is also possible to debit the Nostro account of Bank B that Bank C may hold for Bank B. This is subject to a bilateral agreement between banks.

 

Before we move on I would like to make one remark about the above scenario.

You may have noticed that Bank B is located in France. In European Union, there is PSD2 legislation (you can access this document here) that regulates that for certain payments only SHAR option is allowed (Article 62 (2)). Additionally, there is a so-called full amount principle introduced (Article 81). However, let’s assume that this scenario is a one-leg payment (both Bank A and Bank C are outside EEA). In this case, according to the Guidance for implementation of the revised Payment Services Directive (available here), these PSD2 articles are not applicable.

 

 SHAR

 

In this scenario, Bank A received the request for payment of USD 100. To avoid making this example too complex this time the currency of the Instructed Amount and Interbank Settlement Amount is going to be USD. Additionally, all four banks involved in the payment are located in the USA. All of them have their own charges expressed in USD. Debtor’s and Creditor’s accounts are also in USD.

I am aware that this may not be very probable business scenario, as such payment would be processed via the Payment system in the USD, however, for educational purposes I think is still valuable and will allow us to understand how the charges are processed.

Debtor informed Bank A that the charges will be shared – SHAR option.

The below diagram depicts how the messages are structured. 

 

(1) pacs.008 sent by Bank A

As the Interbank Settlement Account is in the same currency as the Instructed Amount, and there is no Charges Information, Bank A does not include Instructed Amount element in pacs.008.

In SHAR option Bank A’s charges are borne by Debtor, so Bank A will debit Debtor’s account for:

• USD 100 that the Debtor instructed
• USD 5 of Bank A’s charges

(2) pacs.008 sent by Bank B

In SHAR option, except the charges of the Debtor’s Agent (Bank A), all other banks’ charges are borne by Creditor. So, in practice, beginning of Bank B the way SHAR charges are processed is the same as for CRED option.

How do banks levy their charges in such a scenario? Banks deduct their charges from the Interbank Settlement Amount. 

Following this logic, Bank B reduces the Interbank Settlement Amount by the amount of its charges (USD 10), so that the Interbank Settlement Amount in pacs.008 sent to Bank C equals USD 90.

Additionally, Bank B adds also the Charges Information to inform the next banks in the chain that it has deducted its charges.

Because, the Charges Information has been added and Interbank Settlement Amount is now different from the amount that Debtor instructed, Bank B adds also the Instructed Amount to pacs.008. This way, the whole picture becomes clear for the next banks.

(3) pacs.008 sent by Bank C

Following the same logic, Bank C reduces further the Interbank Settlement Amount by the amount of its charges (USD 7), so that the Interbank Settlement Amount in pacs.008 sent to Bank D equals USD 83.

Additionally, Bank C adds also the Charges Information to inform the next bank in the chain that it has deducted its charges.

Here we have an example of the repetitive nature of Charges Information. We have two occurrences of this element. 

What we can observe is that there is a very straightforward relationship between the following elements:
Instructed Amount – Charges = Interbank Settlement Amount.

(4) pacs.008 at Bank D

Bank D receives the payment and notices that the Charge Bearer code is SHAR so its charges will be borne by Creditor.

Bank D decreases Interbank Settlement Amount (USD 83) with the amount of its charges (USD 5) and credits the Creditor (USD 78).

 

CRED

 

This scenario is a simpler version of the previous one. We have only 3 banks located in the USA. 

Bank A received the request for payment of USD 100. Again, to avoid making this example too complex the currency of the Instructed Amount and Interbank Settlement Amount is going to be USD. All of the banks have their own charges expressed in USD. Debtor’s and Creditor’s accounts are also in USD.

Debtor informed Bank A that the charges will be borne by Creditor – CRED option.

The below diagram depicts how the messages are structured. 

(1) pacs.008 sent by Bank A

As the Interbank Settlement Amount is in the same currency as the Instructed Amount we could expect that the Instructed Amount will not be populated by Bank A. However, in this scenario Bank A’s charges are paid by Creditor. Bank A makes Creditor pay its charges by reducing the Interbank Settlement Amount by its charges (USD 5). Also, Bank A adds the relevant information in Charges Information indicating that it has deducted its charges by including its BIC (BANKUSAAXXX) and providing the amount (USD 5). 

In CRED option Bank A’s charges are borne by Creditor, so Bank A will debit Debtor’s account only for:

• USD 100 that the Debtor instructed

(2) pacs.008 sent by Bank B

In CRED option charges are borne by Creditor. Banks deduct their charges from the Interbank Settlement Amount.

Following this logic, Bank B reduces the Interbank Settlement Amount by the amount of its charges (USD 10), so that the Interbank Settlement Amount in pacs.008 sent to Bank C equals USD 85.

Additionally, Bank B adds also the Charges Information, to inform the next bank in the chain that it has deducted its charges.

(3) pacs.008 at Bank C

Bank C receives the payment and notices that the Charge Bearer code is CRED so its charges will be borne by Creditor.

Bank C decreases Interbank Settlement Amount (USD 85) with the amount of its charges (USD 5) and credits the Creditor (USD 80).

 

This is the end of the charges part. In my opinion, this is one of the most difficult aspects of payment processing. It would be great if the information I provided were of some help. In CBPR+ pacs.008 usage Guidelines there are many detailed rules that show cross-element dependencies in this context. I advise you to consult them in case of any questions.  

Reference - https://www.iso20022payments.com/cbpr/charges/

Session 465 - ISO 20022 & Addresses: Structured, Unstructured, and Semi-Structured 🧩📬

 ISO 20022 & Addresses: Structured, Unstructured, and Semi-Structured 🧩📬

By the end of 2026, address data must be transmitted in a structured format. But what does this mean in practice? And what role do semi-structured addresses play? 🤔

📌 What does “structured address data” mean?

In structured addresses, information such as street, house number, city, postal code, and ISO country code is entered in separate fields. This clear segmentation improves data quality, enables automated processing, more precise validation, and reduces errors.

🔄 What is a semi-structured address?

A semi-structured address combines elements of unstructured data with some structured fields.

• Example: Street and house number, along with other data, can remain combined in one field, while city and country code are provided separately. 🌍

• Advantage: Offers flexibility during data migration, making it ideal for companies transitioning gradually to fully structured processing.

📅 When will it be available?

Semi-structured addresses will be available starting in November 2025, providing companies with a practical solution.

💡 5 Tips to Prepare:

1️⃣ Understand the requirements:

By end of 2026, address data must be structured for payment transactions. This is mandatory for cross-border payments 🌏 and relevant for 🇪🇺 SEPA payments as well.

2️⃣ Ensure data quality:

Review your master data! Are fields like “City,” “Country,” and other address elements already separated and complete? 🗂️

3️⃣ Keep track of specific rules:

While address data is not recommended for SEPA payments, it may be a mandatory for payments outside the SEPA area 🌍 e.g., to the UK or Switzerland, even if it’s classified as a SEPA payment.

4️⃣ Leverage semi-structured options:

From 2025, semi-structured addresses will provide a smoother entry point. 🛠️ They allow for incremental updates to your systems and processes.

5️⃣ Stay informed:

ISO 20022 standards are continuously evolving. Use updates from organizations like SWIFT or consult your banking partner 💛.

🔍 Conclusion:

The structured processing of addresses is a key component of the ISO 20022 migration. Semi-structured addresses offer a pragmatic transition and help companies optimize their processes efficiently and future-proof their operations.

♻️ Did you find this post helpful? Share it with your network and follow me for more insights and updates.

Session 453- CBPR+ - HVPS+ Comparison pacs.008 pacs.009 pacs.002 pacs.004 pacs.010

 Session 453- CBPR+ - HVPS+ Comparison pacs.008 pacs.009 pacs.002 pacs.004 pacs.010

CBPR+ ➢ Number of transactions Single Transaction only ➢ Date/Time Datatype: Time Offset made mandatory (Mandatory in FIN)

HVPS+ ➢ Number of transactions Single transaction only ➢ Date/Time Datatype: Time Offset made mandatory 

Ex: Ottawa 2019-08-07T09:27:01.001-05:00 A particular point in the progression of time defined by a mandatory date and a mandatory time component, expressed in local time with UTC offset format (YYYY-MM-DDThh:mm:ss.sss+/-hh:mm). This representation is defined in "XML Schema Part 2: Datatypes Second Edition - W3C Recommendation 28 October 2004" which is aligned with ISO 8601. Note on the time format: 1) beginning / end of calendar day 00:00:00 = the beginning of a calendar day 24:00:00 = the end of a calendar day 2) fractions of second in time format Decimal fractions of seconds may be included. In this case, the involved parties shall agree on the maximum number of digits that are allowed. Example: 2020-07-16T19:20:30.45+01:00 

CBPR+ ➢ 

Character Set: All textual fields (all messages) are restricted to FIN X Characters: 0-9 a-z A-Z / - ? : ( ) . , ' + .

Special characters are allowed in ❑ All Name and postal Address for all actors, ❑ Related Remittance Information and Remittance Information (structured and unstructured), ❑ Email Address where included as part of a proxy element are extended to support the following additional characters. 

List of special characters: !#$&%*=^_’{|}~";<>@[\] 

➢ Settlement Information (if present) Settlement Method: Instructed Agent Instructing Agent COVER (pacs.008 and pacs.009 ADV) Settlement Account: Used (in pacs.009 Core and COV only) Clearing System: Not Used → No impact – Many to Many multiple transactions leg ➢ Original Transaction Reference block (Pacs.004

 

HVPS+ 

➢ Character Set: All textual fields (all messages) are restricted to FIN X Characters: 0-9 a-z A-Z / - ? : ( ) . , ' + . Special characters are allowed in ❑ All Name and Postal Address for all actors, 

 ❑ Related Remittance Information and Remittance Information (structured and unstructured),

 ❑ Email Address where included as part of a proxy element are extended to support the following additional characters. List of special characters: !#$&%*=^_’{|}~";<>@[\] 

➢ Settlement Information (if present) Settlement Method: Clearing System Settlement Account: Not Used Clearing System: Used → No impact - High Value Payment ➢ Original Transaction Reference block (Pacs.004) Not Use

Session 451 – What is T-account and Wash account ?

 Session 451 – What is T-account and Wash account ?

In this article, I would like to briefly present the bookings on T-accounts and Wash accounts.

T-accounts

As not all of the readers may be familiar with double-entry accounting represented on T-accounts, in many sections of my website I use the simplified illustration of booking entries. It still seems important, however, to illustrate how bookings would look on T-accounts. This is the purpose of this section.

What is a T-account?

A T-account is a term used in the context of double-entry bookkeeping.

It is called a T-account because the bookkeeping entries are laid out in a way that resembles a T-shape.

This is what the T-account looks like:

As you can see debits are listed on the left and credits are recorded on the right.

But we can still ask what a debit or a credit mean in the context of the account that banks hold.

So, when the account is debited it means that the balance on the account decreases. As a consequence, if you are Debtor funds are taken from your account.

On the other hand, when the account is credited it means that the balance on the account increases. If you are Creditor, you receive funds on your account.

Additionally, a very important notion is the rule according to which to record every transaction, there will be two accounting entries needed:

 one account will get a debit entry and

 the second one will get a credit entry.

This is to ensure that the total sum of debits is equal to the total sum of credits.

How about having a look at an example?

Let’s say that Bank A sends the Credit transfer to Bank B.

We can illustrate the bookings with T-accounts in the following way:

Needless to say, in the above example, we do not consider any currencies, charges, etc.

What we can see, however, is that in both banks there is one entry on the debit side and one entry on the credit side. In both banks amount debited is equal to the amount credited.

What is additionally worth noticing is that, if the Mirror Nostro is credited then the actual Nostro in a correspondent bank is debited and vice versa. Mirror Nostro is used to reflect the status/balance of the Nostro account.

Between Bank A and Bank B, we can see an arrow symbolizing a payment message. And what is written above the arrow may be easily overlooked, but in fact, is very important.

The above example refers to Credit transfer.

In Credit transfer, the direction of the message is the same as the direction of the funds: from Debtor to Creditor. We can see that message arrow points from the left to the right.

The same is the direction of the bookings in Bank A and in Bank B.

Bank A sends the message as Debtor Agent to Bank B which is Creditor Agent.

Why Bank A sends this message?

It does so on behalf of its customer. The Debtor initiates the transfer and Debtor Agent pushes funds toward Creditor Agent.

This is why Credit transfer is an example of push transfer.

The opposite situation we are going to have in the case of Direct debit.

In the case of Direct debit, it is Creditor that initiates the transfer. It’s a pull transfer. The Creditor Agent pulls the funds.

The direction of the message is from Creditor to Debtor, but the direction of the funds will be from Debtor toward Creditor.

Of course in the case of Direct debit, the bookings will look different, however, the logic still is the same: debits on the left, credits on the right.

Wash accounts

As you certainly know, accounting rules differ among banks.

One of the differences is that some banks may use additional temporary accounts, like Wash accounts during the processing flow.

Temporary accounts are zero-balance accounts. It means that after all the transactions are finalized these accounts should not have any debit or credit balance. You always take out the same amount that you put in.

There are many benefits of using Wash accounts.

In this section, I would like to complement the above example with only one scenario.

What I have in mind is a Customer payment sent with Cover method.

As you may know, Cover method decouples the settlement from the payment information. There are two messages sent:

 one is an announcement with information concerning payment details

 second is the cover payment which moves the funds

So, let’s say that Bank B from the example above is going to receive the payment sent with Cover method.

When should Bank B perform bookings?

Of course, it may be that when Bank B receives an announcement it decides to wait for the arrival of the respective funds before doing any bookings.

But sometimes Bank B may decide that it will book the Creditor without waiting for the funds. The bookings will be carried out upon receiving the announcement. This may be because Bank B trusts the banks involved in the transfer.

What will these first bookings based on the announcement look like?

In such a case Bank B will credit the Creditor.

But, what account will be debited?

Bank B will not want to debit Bank A’s Nostro Account because the funds have not arrived yet.

We can see already, that Bank B will need a temporary account to perform the bookings.

Bank B is going to use a dedicated Wash account.

This will be done as follows:

We can see that in that case the credit side of the transaction is decoupled from the debit side.

To perform bookings only on the Credit side of the transaction a temporary account is needed.

And what will happen when the funds finally arrive?

When the Cover payment arrives the second booking will be conducted:

This second booking takes care of the debit side of the transaction.

Nostro account of Bank A is debited, and Wash account is credited.

After this second booking, the Wash account is correctly balanced.

As a temporary account, the Wash account is a 0-balance account.

And precisely, after this second booking, there is no debit or credit balance on this account.

Source of information - https://www.iso20022payments.com/miscellaneous/t-account-and-wash-account/

Please follow

www.linkedin.com/in/prashantpppatil

https://www.linkedin.com/groups/9809571/

https://www.youtube.com/@BankingPayments

The Future of SWIFT

  As global commerce evolves, countries have searched for a safe and secure means to get money from one bank to the next. International transactions often require a network or intermediary institution to ensure everything goes smoothly. In Europe, it’s called SWIFT.

What is SWIFT?

SWIFT (Society for Worldwide Interbank Financial Telecommunication) is a global financial messaging network that enables financial institutions worldwide to securely exchange information and electronic messages about financial transactions.

What is a SWIFT Payment?

SWIFT payments are transactions made through an intermediary bank that allows you to send/receive electronic payments internationally. The SWIFT network doesn’t actually transfer funds, nor is it a banking system, Rather, it sends payment orders between banks using SWIFT codes. The SWIFT payment system is a means to transfer money overseas quickly, accurately, and securely. 

The financial service creates a global level of connectivity that speeds up international business and brings the world a little closer together. In November 2022, SWIFT recorded an average of 44.8 million FIN messages per day. Traffic grew by over 7.1% versus the same period of the previous year.

The SWIFT payment network allows individuals and businesses to accept/send international money via electronic or credit card payments. This can be done even if the customer or vendor uses a different bank than the payee. The network is a place for secure financial messaging. In a sense, it’s nothing more than a messenger between banks. 

What is a SWIFT Code?

How does SWIFT work? When you use SWIFT, you are not actually sending a money transfer. Instead, it is referred to as a “payment order” between two banks. This is done using a SWIFT code. 

When looking at IBAN vs SWIFT, it was the SWIFT network that standardized the formats for IBAN (international bank account numbers) and BIC ( bank identifier codes). SWIFT owns and administers the BIC (Business Identifier Code) system. This means it can identify a bank in seconds and send a secure payment quickly.

A unique SWIFT code is comprised of 8 or 11 characters. Other names for this same code include:

• Bank identifier code (BIC)
• SWIFT ID
• ISO9362

Example of a Swift Code

An example of a SWIFT code is the Italian bank UniCredit Banca in the city of Milan. The code is UNICRITMM. 

The first four characters (UNCR) is the bank code. The next two characters (IT) is the country code for Italy. Then the next two characters (MM) stand for the bank’s location or city code. The last three characters (which you do not see here) are optional. They are only used by banks to assign codes to individual branches. 

Using a SWIFT Code

An example of this in action would be when a customer walks into a central bank, like Bank of America in New York, and wants to make an international money transfer to their friend in Venice through UniCredit Banca. They need their friend’s bank account number and the unique BIC code that applies not only to UniCredit Banca, but to the exact branch in Venice. 

Bank of America will then send a SWIFT message to UniCredit Banca over the secure SWIFT network. Once the Italian bank gets the message, it will clear and credit the money to the Italian friend, while Bank of America debits the customer’s account.

How Does a SWIFT Payment Work?

The original design and intent of SWIFT was to create a way for banks to communicate faster and more securely among themselves. Particularly in relation to processing international payments. The word “communicate” is always used because SWIFT is simply a messenger between banks. SWIFT money does not exist. It channels the message enclosing payment instructions from the issuing bank (i.e. the payor) to the remitting bank (i.e. the beneficiary/receiver). 

All banks engaged in a SWIFT transfer will move funds from one account to another based on an underlying network of Nostro and Vostro accounts. This refers to accounts that banks have opened up with each other for the sole purpose of executing SWIFT transactions. 

How to Make a SWIFT Transaction

To make a SWIFT transaction, follow these steps:

1. Contact your bank: Provide them with the details of the transaction. This includes the recipient’s name, bank name, account number, amount, currency, and any other relevant information.
2. Complete the required forms: Your bank will provide you with the necessary forms to initiate the SWIFT transaction. These forms will typically include information on the originator and beneficiary of the transaction, the amount to be transferred, and the currency involved.
3. Provide payment: Once the forms are completed, you will need to provide payment. This typically involves transferring the funds from your account to your bank’s account.
4. Wait for confirmation: Once the transaction has been initiated, you will need to wait for confirmation that the funds have been transferred successfully. This can take several hours or even days, depending on the banks involved and the complexity of the transaction.

SWIFT transactions can be costly, especially for smaller transactions, as they often involve fees and charges from multiple banks involved. You should also ensure that you provide accurate and complete information to avoid delays or errors in processing.

The Nostro and Vostro Accounts

As both banks keep a record of money deposited into the account, this leads to two mirroring sets of ledger known as the Nostro and Vostro accounts. Nostro refers to the account used by the bank to hold money, whereas Vostro refers to the name of the account used by the bank opening it in their books. 

When both banks have a commercial relationship with Nostro and Vostro accounts, the SWIFT transfers are direct and immediate. When banks do not have this type of relationship, the SWIFT network has to determine the best means to pass the message on. In this case, a third party is required; also known as an intermediary bank. 

You have to find a middleman to handle the transaction. Once a correspondent bank that has a commercial relationship between the two financial institutions is found, the SWIFT transaction can proceed. In this case, additional fees will be incurred from the third-party services.

The more intermediary banks involved in the transaction, the more it will cost you to send. It will also take longer to send the payment, at a much higher risk, as there are more parties involved. 

Who Uses SWIFT Payments?

In the beginning, SWIFT was created to facilitate communication about treasury and correspondent transactions only. The functionality of the message format design allowed for large scalability. SWIFT gradually expanded to provide services for:

• Banks
• Clearing systems
• Money brokers and security broker-dealers
• Corporates
• Non-bank financial institutions
• Treasury market participants
• Asset management companies
• Depositories
• Foreign exchange
• And more…

How Much Does SWIFT Cost?

SWIFT is a cooperative society that is owned by SWIFT members. These members are categorized into classes based on their share of ownership. All members pay a one-time fee plus annual charges, which vary by member class. 

In addition, the messaging system makes money by charging users for message type and length. These charges will vary based on the bank’s usage volume. This explains why you pay different fees for international payments from one bank to the next. Another reason is the bank’s commercial policy on international funds transfers.

SWIFT also charges for extra services like business intelligence, professional apps, global payments innovations, and compliance.

A Brief History of the SWIFT System

Prior to the development of the SWIFT network, banks relied on a system called TELEX to send wire transfers. Not only did the process move at a snail’s pace, but TELEX lacked the security and sophistication for a time when technology was making exponential progress. The free message format did not have a unified set of codes (like SWIFT) to name banks and transaction types. This created a lot of confusion and led to many human errors. TELEX senders had to describe every transaction in full sentences, which was then interpreted and executed by a dedicated receiver.

Therefore, as necessity is the mother of invention, the SWIFT network was born.

SWIFT is a member-owned organization. It was founded in Brussels, Belgium, in 1973 for the purpose of establishing common processes and standards for financial transactions. Banks needed a universal and consistent way to get money across the oceans. That’s where the SWIFT network comes in. Six major international banks formed a cooperative society to operate the global network in a secure and timely manner.

What is the SWIFT Payment System?

The SWIFT payment system enables banks and other financial institutions to securely exchange electronic messages about international transactions. It provides a standardized messaging platform that facilitates communication between banks and other financial entities.

How Does the SWIFT Payment System Work Today?

Currently, SWIFT provides messaging services to over 10,000 financial institutions in 212 different countries worldwide and helps facilitate global business. SWIFT achieved a new peak day on 30th Nov 2021, with 50.3 million messages, higher than the peak on 26th Feb 2021 by +8.5%

While the network started primarily for simple financial messages and payment instructions, it now sends reference data for a wide range of actions. This includes transactions for:

• Security  
• Treasury  
• Trade 
• System

In Swift’s latest report, from January 2022, data showed 44.5% of SWIFT traffic is still for payment-based messages, while 50.6% represents security transactions, and the remaining traffic flows to Treasury, trade, and system transactions.

Economic Sanctions

In the past decade, SWIFT has also been used for economic sanctions. In 2012, the European Union passed a sanction against Iran that compelled SWIFT to disconnect sanctioned Iranian banks.

As of Feb. 28, 2022, the United States, EU, U.K., and Canada have agreed to levy sanctions against Russia in response to its invasion of Ukraine. They have agreed to remove select Russian banks from the SWIFT messaging system.

Additional SWIFT Services

The SWIFT system offers many services that will help you send seamless, international transactions. Here are a few to check out:

Industry-leading Applications

SWIFT connections give you access to a variety of applications, from real-time instruction matching to forex transactions and treasury. 

Expect applications that include tools for:

• Banking market infrastructure for processing payments between banks
• Securities market infrastructure for clearing and settlement instructions
• Instructions for securities, forex, and derivatives transactions

Business Intelligence

SWIFT offers universal business intelligence dashboards and reporting utilities. This enables customers to get a dynamic, 360-degree view of messaging, activity, reporting, and trade flow. You can filter based on demographics like region, country, message types, and other related parameters.

Compliance Services

SWIFT offers services aimed at financial crime compliance. This includes reporting and utilities for Know Your Customer (KYC), Anti-Money Laundering (AML), and Sanctions. 

Messaging and Connectivity

SWIFT is the king of conversation, and the entire focus is communication. The core of the business resides in streamlining the movement of messages and providing a safe, reliable, and secure network. SWIFT has a variety of messaging hubs and software so clients can effortlessly send and receive global transactional messages.

Global Payment Innovations

SWIFT’s latest service is called SWIFT Global Payments Innovations (GPI). The goal of SWIFT GPI is to improve the traceability and transparency of all cross-border payments. This means, if your bank is a member of SWIFT, they can check on the status of a payment at any given time of day. This type of flexibility when it comes to international payment processing is unparalleled by any other system. 

The Future of SWIFT

Although there are other real-time messaging services like Ripple, Fedwire, and Clearing House Interbank Payments Systems (CHIPS), SWIFT continues to retain a dominant position in capital markets. There’s a good reason for that too. The attributed success is due to how continually the network adds new message codes to transmit different kinds of financial transactions. In other words, it’s constantly adapting to new financial needs and fintech processes. This makes it the most reliable, flexible, and functional system for international wire transfers on the planet.

If your business is considering using SWIFT as a messaging network, understanding the process is a good first step! However, there are numerous options for paying international suppliers, from prepaid debit cards to international ACH to wire transfers and more. Check out our latest ebook: Comparing the Top Global Payment Methods, for more.

reference - https://tipalti.com/payments-hub/swift-payments/