This site uses cookies

To give you the best possible experience, the GAM website uses cookies. You can read full information of our cookie use here. Your privacy is important to us and we encourage you to read our privacy policy here.

OK
False a974677f-952f-4fbd-ade5-9965030f44d8

Comma Separated Vexation

Tuesday, May 23, 2017

As featured in HFM Technology, Tom Howat, Chief Technology Officer at GAM Systematic I Cantab, discusses the need for greater standardisation when communicating trades.

The problem

How many third party systems do your company’s systems talk to? Count them – you may be surprised. You’ve got your executing brokers, obviously. Prime brokers too. Clearers, both for your own funds and for your managed accounts. Oh, and administrators naturally. Custodians. Exchanges. Regulators. Data providers.

Next, for how many of those do your systems either send or receive comma separated value (CSV) files? It’s probably quite a few. (Aside: CSVs are like the contents of Excel spreadsheets written as plain text, with each column value separated from the next by a comma (hence the name -- though symbols besides commas can be used). It’s easy to write code to understand CSVs, which is why they’re so popular. The ‘format’ of a CSV is basically the names and types of the columns: trade date, quantity, settlement date, and so on.)

Now, the kicker: how many of those CSV formats are the same? I’m going to guess: None. It’s none, isn’t it? Even when you’re talking to two different parts of the same institution.

My firm is a global asset manager with a large systematic investing capability. We’ve written code to make dealing with different formats really easy. It takes just a few lines of code to define a new format, complete with validation and read-write capability. I just ran a search on our code base and found that we use this piece of kit in almost one hundred different places, to deal with 96 different counterparty-specified formats. One of these formats specifies 85 columns (that’s out to column CG in Excel), and the meanings of some columns change depending upon the values of other columns. These are not pleasant.

Almost all these formats do one of two things: report details of trades, either for allocation or reconciliation; or report details of positions, for reconciliation, administrative, or regulatory reasons. So why does our company need to handle so many formats? Why are there so many formats?

One problem is symbology: in what way do you describe the thing you’ve just traded? There are many options, depending on the sort of thing it is: Bloomberg codes, Reuters RICs, CUSIPs, ISINs, SEDOLs, Newclear codes, IFM codes… Some firms use one of these, and naturally expect everyone else to use the same one (but they don’t, of course). (We ended up writing a dedicated symbology system to abstract away all these differences, seamlessly converting between different standards as required.)

In a similar vein: how do you represent prices and quantities? Are prices in dollars or in cents (or pounds or pence)? Are futures quoted in underlying quantity (e.g. 1,000 WTI = 1,000 barrels of oil) or lot quantity (1,000 WTI = 1,000,000 barrels of oil)? (As with symbology, we wrote a system we call quoteology for dealing with these various differences.)

Another problem was long ago best summed up by Randall Munroe in his xkcd comic #927.

Hfmt Image

Source: xkcd.com

This same story repeats across many different areas of engineering and technology: a group of people, tired with the multitude of supposedly universal yet mutually incompatible and competing standards, gets together to dream up a new truly universal one. But, almost inevitably, this new universal standard isn’t universally adopted, resulting in yet another supposedly universal standard to compete with all the others, making the problem worse than it was to start with.

The FIX?

With good, modular, reusable code, it’s possible -- even easy -- to live with this absurd number of ways to tell other people about your trades and positions. But we’re all solving this same problem. And new entrants have to solve it too. Over and over and over again, programmers in financial firms all over the world are writing code to read some trades or positions from a database and format them just so, to suit the demands of their counterparties. Isn’t this a little bit depressing?

Obviously, I’m not the first to make this observation. This problem has been seen before, in all technological walks of life, including in other areas of finance. Back in 1992, Bob Lamoureux and Chris Morstatt started work on a way to standardise stock trading between Fidelity Investments and Salomon Brothers. The result was FIX: Financial Information eXchange. They and others drove the adoption of this protocol, which aimed to become the standard way for institutions to request quotes and execute trades. It succeeded. The first publicly available specification, FIX version 2.7, was released in 1995. In subsequent years, new versions of FIX introduced support for more asset classes: FX, futures, bonds, swaps etc. Today, most firms (at least, most firms we deal with) use FIX versions 4.2–4.4, and they cover essentially everything that can be traded electronically.

By imposing some structure on how firms send trade executions to each other, and through the wide adoption by many financial firms, FIX forestalled a proliferation of mutually incompatible communication methods. Legions of programmers should be thankful for this! (Having said that, FIX isn't perfect. In order to get it widely adopted, and for greater flexibility, the original designers shied away from over-standardisation. This has led to questionable decisions on the part of some implementers. For example, one of our counterparties uses the mysteriously named SecondaryExecID field to indicate when a trade is part of a spread; another counterintuitively uses the Account field to send us the trader name.)

Why am I bringing FIX up here? Because, essentially, FIX is also trying to solve the problem which opened this article. In a paper entitled FIX Post Trade Processing: A Case for Using Financial Information eXchange, the organisation behind FIX laid out the case for deploying it to send and receive allocations and confirmations. Rather than have countless jobs producing CSV files, transmitting them to other jobs which then parse and understand them, would it not be better to use the same FIX infrastructure we already use for trade execution? I think so.

Unfortunately, that paper isn’t recent: it was written in 2005. Here we are, nearly twelve years later, still mired in file formats, still SFTP-ing or (even worse) emailing CSVs and Excel spreadsheets across the globe. It’s not clear to me how we push for change, for greater standardisation, in this area – it probably wasn’t clear back in 1992, either. But every so often I'll ask my CSV-hungry counterparties if they’ll consider accepting something better.


Important legal information
The information in this document is given for information purposes only and does not qualify as investment advice. Opinions and assessments contained in this document may change and reflect the point of view of GAM in the current economic environment. No liability shall be accepted for the accuracy and completeness of the information. Past performance is no indicator for the current or future development.