Financial messaging

Financial messaging


Table of Contents
< All Topics

Interbanking transactions

Banking institutions are globally involved in business-to-business relations that require dense information exchange, so called interbanking transactions, and that apply in various business contexts including interbank trading, lending, payments, cash management, foreign exchanges and securities settlements to name a few. Those transactions characterize by fast and highly automated transfers of large monetary amounts and high volumes of messages. The underlying information is transferred according to financial messaging standards, which allows the industry to reach a high automation degree of the processing, also referred to as straight-through processing (STP).

In this context, the network SWIFT (Society for Worldwide Interbank Financial Telecommunication) plays a central role as it connects together more than 11’000 financial institutions in more than 200 countries1. It is the major focus of Swiftflow.

Messaging standards

Various messaging standards have been developed and adopted by the banking industry to facilitate those transactions. Those include on the front office side the Financial Information eXchange (FIX)2 for securities trading related transactions or the Financial products Markup Language (FpML)3 for over-the-counter (OTC) derivative transactions.

On the back office side, the ISO1500224 and ISO200225 standards (the second being the successor of the first) represent a high share of the global traffic, while being complemented by a wide variety of other standards on regional scales or specific interactions. 


This standard has been developed in the 1990’s as a successor of ISO7775, mostly for securities transactions. While the entire banking industry is migrating from ISO15022 to ISO20022 for cross-border payments (horizon 2025), there is no planned decommissioning of the ISO15022 standard for the other business domains it covers (corporate payments and cash management, securities post-trade, clearing and settlement, corporate actions, foreign exchange, treasury and trade finance), as stated by SWIFT6.

In terms of volume, the FIN standard alone (that includes MT7 and ISO150022) shows a daily traffic of about 40 mio/d  messages with a yearly growth rate of more than 10%. The MT standards represents about half of the volume exchanged over the SWIFT network8.

The standard complies to specific rules and syntax described in the literature9, and not repeated here. In short, it is composed of different levels of business contexts. The message family refers to a business domain while a given message type10 represents a specific type of transaction in this domain. A single message is divided into blocks, sections, sub-sections and fields. A field is constituted of tags (built from a type and an option) and contents, that can be qualifiers or sub-fields.

Some of the components are mandatory, other ones optionals. The standard also specifies the character types that are allowed in each of the field or sub-field. On one hand, a field can have a very granular structure and in case its components are encoded in short and fixed-length sequences of reduced set of characters. On the other hand, a field can be of free text type when it contains long chains of any character type, which makes the translation to machine interpretation challenging. Examples of unstructured fields are given below.

The following snippet shows an example of a raw MT541 message11. This message type is called an Instruction to Receive Against Payment.

"{1:F01ABNACHZ8XXXX2596106739}{2:O5411345160418ICBKCNBJXBJM00897254971604181345N}{3:{108:110110149709}}{4:\r\n:16R:GENL\r\n:20C::SEME//1234567890123456\r\n:23G:NEWM\r\n:98C::PREP//20181123165256\r\n:16S:GENL\r\n:16R:TRADDET\r\n:98A::TRAD//20181123\r\n:98A::SETT//20181127\r\n:35B:ISIN CH0012138530\r\nCREDIT SUISSE GROUP\r\n:16S:TRADDET\r\n:16R:FIAC\r\n:36B::SETT//UNIT/10,\r\n:97A::SAFE//0123-1234567-05-001\r\n:94F::SAFE//NCSD/INSECHZZXXX\r\n:16S:FIAC\r\n:16R:SETDET\r\n:22F::SETR//TRAD\r\n:16R:SETPRTY\r\n:95R::DEAG/SCOM/CH123456\r\n:16S:SETPRTY\r\n:16R:SETPRTY\r\n:95P::SELL//ABCDABABXXX\r\n:97A::SAFE//123456789\r\n:16S:SETPRTY\r\n:16R:SETPRTY\r\n:95P::PSET//INSECHZZ\r\n:16S:SETPRTY\r\n:16R:AMT\r\n:19A::SETT//CHF218,4\r\n:16S:AMT\r\n:16S:SETDET\r\n-}"

Various tools exist to parse such text content, namely to extract its components into a structured machine-readable object. Those include vendor solutions and open source products12,13.

Being able to fully capture all the above mentioned contexts into one single data model at one pass is a differentiator of Swiftflow. The JSON object resulting of such transformation can be consulted on the demo page14.

→ Features of Swiftflow


The ISO20022 emerged in the 2000’s and was partly inspired by the ISO15022 while intending to improve and generalize it. It specifies a recipe for making financial standards 15. It aims at covering the entirety of business domains found in banking by proposing a vast set of message definitions and message sets16.

Like ISO15022, a ISO20022 message also features a nested structure. However the ISO20022 presents a deeper (more depth levels) and wider (more field definitions) structure, and therefore more granular (shortened field contents) values, ultimately making the entire object and standard qualified as more structured and richer than its predecessor, with all the potential and promises that this entails.

The below snippet shows an example of a raw pacs.008 message. This message type is used for Payments Clearing and Settlements.

<?xml version="1.0" encoding="UTF-8"?>
<Document xmlns="urn:iso:std:iso:20022:tech:xsd:pacs.008.001.08">
			<IntrBkSttlmAmt Ccy="USD">36998765.25</IntrBkSttlmAmt>
				<Nm>Midnight Spares S de RL</Nm>
					<TwnNm>Mexico City</TwnNm>
				<Nm>Rimac Automobili</Nm>
					<AdrLine>Rue de l'Avenir</AdrLine>
				<Ustrd>Invoice: 65897/445</Ustrd>

Since ISO20022 natively supports the XML and JSON syntaxes, it does not represent any issue for software solutions regarding the parsing of its content, with exceptions of the unstructured fields discussed hereafter. However, it still represents a challenge in term of data modeling when analytics applications are in scope. Side-by-side comparisons of MT and ISO20022 can be found17.

→ Features of Swiftflow

Unstructured content

Both ISO15022 and ISO20022 tolerate the presence of free text fields, also referred to as unstructured content, for example to accommodate for technical communication, error message, remittance information or party data18. Those contents can be isolated at field type level or can compose entire message like with the wrapping tag CDATA that is found in some regional flavors of the ISO20022 standard.

The party data consists of the information related to a specific entity like a bank account, an individual or company name, the address, etc.) and is of key importance in the Payments domain. In its less structured form, a party field like 50a or 59a for ISO15022 or <PstlAdr>in ISO20022 19 can be a free text showing the wide variety of patterns found in postal addresses worldwide, such as in the 50K variant. Other variants like 50F enforce to comply to some structure, yet the validation of real messages against those constraints is actually very intricate and deviation to the standard often occur that ultimately require manual review.

As shown below, the ISO20022 standard allows for both unstructured and structured version of the field20. In its most structured form, all components of the address are atomically isolated.

It is of crucial importance to be able to interpret patterns of the party fields so as to be able to apply structure and make them machine readable.

→ Features of Swiftflow
→ Features of PTparser


  7. MT is the SWIFT proprietary variant of the standard ISO150022
  8. ISO20022 for Dummies, John Wiley & Sons, Ltd., 2020
  15. ISO20022 for Dummies, John Wiley & Sons, Ltd., 2020
Previous The case