I was lucky twice to go to Thailand, a beautiful place. But most of the times I had to go to a shop on the road, the vendor used to show me the price of the article using a calculator. That was the only medium using which he could convey me the price, as he did not know English and I did not know Thai. The calculator acted as a medium of communication between the two of us. Similarly today where I should say infinite quantity of data is exchanged in the form of messages, the sender and receiver have to agree upon a standard format of message to transmit the data, to ensure that the receiver clearly knows the position of each data in the message, to extract and process it.
In the payment cards domain, especially Debit & Credit space in which I work, one such format is ISO8583. This is a standard defined by International Organization for Standardization (ISO) for financial transaction card originated messages. This standard is widely used by many organizations inclusive of MasterCard and VISA networks. ISO8583 is a bitmap based format, where different types of messages are identified by four byte message type indicators (MTIs), followed by the bitmap of the data-elements, and then by the data-elements which contain the data itself.
Similarly in the securities space, one of the key data format standards is ISO 15022 – SWIFT. These messages are formatted in a different manner from that of ISO8583. Each message has a 3 byte message type indicator, and the data is represented in the form of tags. The tag and its corresponding value are sent on the message.
Each of these data formats/standards have been devised to meet that particular domains’ expectation, for example ISO 8583 message format would carry data related to the payment cards. ISO 15022 would carry information related to securities. The representation of the data also is different between these formats. For example, currency of the transaction in the ISO 15022 format is present in tag: 11A, but in the ISO 8583, the currency is present in the Data Element 49 of the message.
Numerous numbers of aforesaid formats are actively used in the market across domains and geographies, which create a lot of overhead to the financial institutions in offering different services to its customers. For example, if the bank plans to offer a service where using its debit card, the customer should be able to buy some securities, the bank has to generate two different messages in different formats one in ISO 8583 to update its debit card and one in ISO 15022 to buy the securities. This acts as an overhead to the bank to maintain two different formats.
In the current market place, where the customer expects everything to be a click away, financial institutions have to offer innovative products (banking, payments, securities etc), spanned over different financial institutions across geographical boundaries. This drives a need to maintain a common format across different domains. This common format should be able to carry the business function and the related data.
While browsing over the internet, I found an interesting development that is happening around this area in the industry i.e., evolution of a new standard by ISO namely ISO 20022. The aim of this format is to allow smooth inter-operability between the financial institutions, by standardizing the data formats across domains. Each financial institution/domain uses its own terminologies to define the different business concepts. Idea of this format is to standardize the terminologies used by different institutions and define them in the ISO 20022 data dictionary. By using this standardized data models, developers can build syntax independent message models, which can be transformed into different messages according to desired syntax. The current preferred syntax is XML format. In this format the business model is to be defined first, which means
- What is type of activity?
- Who are the parties involved?
- What is the information need to complete the activity?
All the business functions are grouped to a root business function which would contain the parties/elements that corresponding to the root business function and each specific business function would have its own additional elements.
Business Function (ex: Payment) -> Actual Function (ex: Credit Transfer) -> Actual Message Syntax (ex: XML).
For example, a credit card payment or money transfer falls under the same umbrella of a payment function, which would involve a debtor, creditor, debtor bank and a creditor bank. Specific to the credit card payment, there would be elements like expiry date etc, a remittance date for a money transfer. This hierarchical model of grouping the common elements allows re-usability of the function defined. Thus, this data format standardizes the messages across the industry. So whenever a message comes for a credit card payment, it can clearly know, what to expect in the message.
Technically, XML is the best suite to store all the message format and corresponding descriptions, which can be stored under an XML schema. XML files are machine readable; hence addition or maintenance of the messages is easy and requires less manual effort. Being an international standard, it enjoys support of lot of software tools for maintenance of the message schema at a lower cost.
There are also certain technical considerations to be kept in mind for this new ISO 20022 formats. ISO 8583 occupies at the maximum of 3500-4000 bytes of space per message. But if the same number of data elements are to put on a XML message considering the XML tags, my guesstimate is that the message length would be at least 10 times the normal ISO 8583 messages. It means that the more data is to be put on the network resulting in higher bandwidth requirement though it should still be manageable.
Finally thanks to “ISO 20022 for Dummies” (Dummies, Yeah it’s me) and “http://www.iso20022.org/” for putting some information over the web, for people like me to read J
