Earlier this year, as one of Sinara’s founding directors, I participated in a financial market data industry panel that covered the topic of Market Data APIs. This Blog post covers some of my views on the subjects discussed at that event, based on my industry experience and role as one of the system architects of Sinara’s Market Data Platform.
Summary of the Topic
Consumers of financial market data are looking to avoid being locked in to market data systems, services and data vendors. This is a large and complex issue, covering both commercial and technology aspects. One part of the overall problem is choosing a suitable set of APIs against which clients can build and integrate their applications.
We set up Sinara over 25 years ago, and for most of that time we have been working with market data, starting when there were no APIs as such, and we had to use more basic software engineering techniques. Since then, we’ve spent a lot of time using APIs from various suppliers, and delivering data and functionality via APIs of our own design, and even emulating other peoples APIs in order to provide interoperability.
Why bother with APIs at all?
APIs are essential for Interoperability and automation.
Since maybe the late seventies, IT systems have been focussed on delivering functionality and data to human users, via screens and printouts – hence the historical focus on the market data terminal business.
But now I think the key driving motivation is the need to do more work with fewer people – this leads to the need for more automation, with the ability to move data between systems ‘untouched by human hand’. Thus you need well designed APIs that provide a consistent way for programs to access the data.
The original usage was probably mainly for trading support, automated trading and the like, but progressively the scope of usage has widened to support more areas – position keeping, portfolio and risk management, compliance, trade reconciliation and so on.
David Wheeler famously said – “there is no problem in computer science that cannot be solved by adding another level of indirection”, and this is particularly true when it comes to market data systems. The more abstract the access model, the more likely it is to prove flexible and adaptable.
How does “OPEN” apply to APIs?
Open is usually used as a synonym for the idea of avoiding vendor lock-in. When Sinara started, market data was typically delivered to actual physical terminals, and our earliest work was on video-switching systems, because that was the only way to achieve any flexibility in delivery.
We did some work with the early Windows-based terminal from a major vendor where we were attempting to implement automated data contribution by intercepting the message flow within the terminal and simulating a user typing the deals in.
So compared to those days, I tend to regard any mechanism which gives you a well-defined, reliable interface as being open. And things like OpenDACS and Bloomberg Open API come into this category.
However, the word Open has also gained a further meaning – to identify things that you can use for free.
Beyond that, we have open source – where you have free use and can also modify the source code. This can be viewed as good because no single company has control of the technology, but on the down side nobody takes ultimate responsibility for making sure it works. Open source is great for encouraging co-operation and inter-operability, but it’s not a panacea. In particular, you should not regard it as a way of getting functionality without paying.
Some technical things to look out for
If you asked a programmer they would say that the essential characteristics of an API were the methods, parameters, and behaviour of the API; for example synchronous or asynchronous behaviour, callbacks and so forth. Also, how that API is built and linked with their own code. These are factors which can make an API difficult to use if not thought through properly.
Symbology is also a challenging issue – reasonably straightforward for simple exchange-traded securities, but more problematic for OTC and complex derivatives (butterflies, straddles, strangles etc). There are a number of open symbology initiatives going on – BB open Symbology, looser RICS licensing.
Providing support for APIs
Good support for an API is critical. Most people think IT-related support consists of someone on the end of a phone, but for developers that’s almost the last thing you want.
Good support starts with the design of the API and associated deliverables – a consistent and easy to use API, comprehensive documentation, good examples and test harnesses – all go to lighten the support burden.
To make life as easy as possible for your API users you need to support their development environment as closely as possible. For example, Sinara provide pre-built binary libraries whenever possible – so this means we invest a lot of time building the API libraries for different versions of multiple Linux variants, 32 and 64 bit, dynamic and statically linked, on Windows explicitly supporting multiple Visual Studio versions, and so on. We do this so that we can get as much done in our controlled environment before handing over the deliverables to the client so they can build an example program straight away.
Deploying changes to APIs needs to be carefully managed. With a change to a user interface, a human can see the difference and adapt. But if you change an API, client applications will potentially break. So there is a definite skill in designing APIs so that they can easily be extended without breaking applications, and also in managing the change.
How can customers get best value from their APIs and platforms?
It is useful to look at this in terms of the costs to the client and how they get the most out of their investment. If a client invests the effort and cost in using a set of APIs for developing and integrating their applications with their market data system, they want to make sure they get the most out of that investment. One way of achieving this is to make the APIs vendor-agnostic and consistent across internal/external data where possible, which is the approach Sinara have taken. As previously mentioned, a good set of APIs provides a level of abstraction or ‘insulation layer’ between the application and the data source. The ideal is for a client to build their applications independent of data vendors and have free and easy access to their own internal data.
