Formats and Standards, A Disagreement

The definition of a format in the computing and financial world is: a defined structure for the processing, storage, or display of data. Data formats are crucial to financial organizations. It is important to standardize on a common language to integrate and interoperate between and within market participants. However, adoption of formats has its own unfortunate track record.

Let’s take an example of a format (protocol, standard) called FpML which stands for Financial Protocol Markup Language, and is an extension of the customizable XML message standard. This format was created for the financial industries toughest nut to crack which is how to communicate on complex, bespoke derivative instruments. The problem was, and still is today, that legacy systems are not all in synch on how to define and represent similar instruments such as Interest Rate Swaps. In the old days (shows you how old I am) we defined Swaps as two separate Bond instruments that represented similar cashflows as to the ones in the instrument of Swaps. So, we fudged the instrument into older legacy systems by representing it as something else. Well, some of the systems I am talking about that were implemented 15-20 years ago, are still installed in financial institutions today. Many have been upgraded but many have not. This causes an issue when trying to integrate systems and processes, thus FpML was created to represent these instruments.

The process of recommending new extensions to the FpML standard is long and even if an extension is accepted by the organization that governs the standard, it does not mean that there are any mandating requests to adhere to these standards. Thus, several integration points into an organization for the creation and automation of a workflow are not standardized on one FpML version (current version of the latest FpML standard is 5.9). I am integrating into an organization now and I must make sure all of my connections use the same standard and that isn’t the case; one system would be on FpML 4.3 and the other would be on 5.0. This creates major issues when trying to automate processes.

Recently there has been a big push from ISDA and other market participants to standardize on ISO 2022 formats for Trade Reporting. I am a big supporter of standardization and think that ISDA is making a great effort, especially in the major area of complexity such as Reg Reporting. That being said, truePTS is going to support this standard adoption but we’re skeptical as to the major adoption of the standard in the coming years.

We need to automate now and unfortunate or not, create software around integration that will be flexible enough to support a robust interoperability solution beginning now and until there are future implementations of standards such as ISO 2022 or technologies such as Blockchain.