Will REST/WEBSOCKET take over FIX?

Combining REST & WebSocket

Since the emergence of digital assets, crypto exchanges have operated with a combination of REST & Websocket APIs allowing their customers to trade, see balances and see market data. The two interfaces will in some cases expose much of the same data, so why then do exchanges and venues need both? Why do counterparties have to make a connection to both to get the functionality they require?

To answer this, we need to look at the way each interface works, how data is transferred and the resulting functionality that can be achieved.

Snapshot vs Streaming

A connection via REST is structured as a call-and-response or a question-and-answer interface and therefore serves only to provide a response to the “question” posed in the request.

This call-and-response structure means that REST is somewhat limited in terms of the functionality it can support in the world of real-time trading. It is, however, very effective for certain use cases such as the download of reference data or checking trading account balances. REST would however not be practical for a workflow that requires live and up-to-date market data, as this would require an approach of continually polling to get updated information.

Enter WebSocket, which can provide a streaming interface and therefore an ability to push real-time data through a constant TCP connection. Because WebSocket is newer than REST, however, developers may (currently) have less experience with them and therefore there is a learning curve. Once established, however, the interface allows data to be streamed in both directions and it can therefore be used for a more varied set of use cases, the most common of which is real-time market data.

So if WebSocket can stream data in both directions, the next question might be: is there any need for REST? Yes – the call-and-response structure of REST is often more practical and effective for workflows in which a developer needs to link the request and corresponding response together.

Consider for a minute the Websocket connection where both ends can send any data to the other end, at any time. That could get quite noisy quite quickly! At any particular moment in time, the two data streams might be unrelated to each other. For example, one end may have requested some data, but the next message it receives might be in response to a completely different request. And so it can become tricky to correlate messages received with requests made. REST removes this issue by tying the question (request) to the response even if there is a delay, making REST a better choice for request-response workflows than Websocket.

Individually, REST and Websocket would only provide part of the use cases required for a Crypto exchange, but when both APIs are offered in tandem they can offer streaming market data and trading workflows in a way that is easy for developers to access.

So what about more traditional finance? If this combination provides both types of interface, what is the need for FIX? Will we see this API combination take over how banks and exchanges connect and interact?

FIX runs too deep

In more traditional banking and finance, the FIX protocol is extremely entrenched with a mature dictionary of tags and messages to create comprehensive coverage of trading assets and workflows.

FIX APIs can handle both request/response type interactions as well as unsolicited streaming data through a constant TCP connection (although we should recognise that real-world use of FIX in market data is less common than for order entry).

We all know wholesale or even minor change in this industry is rare, and the entrenched status of FIX makes it unlikely that a WebSocket / REST combination will replace FIX where such an API exists today. It might be possible, however, that targeted WebSocket and/or REST is offered alongside FIX in some situations.

Which situations might that be? Well, there are some non-time-sensitive workflows that are modelled in FIX, but you rarely see them in real-world APIs and often feel slightly clunky when you do see them. These include some of the reference data messaging in pre-trade and some post-trade workflows. My intention here is not to offend anyone by calling them “clunky” – at the time FIX was created there was no alternative and so they tried to make it work. My comments are really to suggest that REST might be a more suitable, modern alternative.

Indeed, we are seeing more adoption of REST APIs by banks and venues, especially reference data as an alternative to legacy flat-file downloads, which can be quite a manual, painful process for customers who receive them today. Today this might be an automated email out to customers with a CSV attachment, or a downloadable spreadsheet or text file from a corporate website or SFTP site. Customers who are also receiving similar data from multiple counterparties are forced to collate and normalise data elements somehow. A REST API could help automate this data ingestion problem, or – to go one better – a GraphQL API could help automate the normalisation process.

REST is therefore becoming more prevalent in the traditional finance space but what about the other direction? What about FIX in crypto?

FIX in the digital space

This is a trend that is gathering significant momentum. FixSpec has been working closely with digital exchanges as they embark on their journey to support FIX connectivity alongside their existing REST and WebSocket APIs.

The main reason for this move is demand from a new type of customer, “traditional” financial institutions who are developing an appetite for digital assets, but who also demand FIX connectivity into their existing systems.

But for those who have never been exposed to it, FIX is not easy or accessible and often requires a specialist to implement it. Large financial institutions will often have a whole team designated to FIX connectivity. And so some Crypto firms are at an information disadvantage to the customers they are keen to attract.

Replicating the functionality of REST and WebSocket into FIX is a complicated process and not a well-trodden path. It involves mapping all the existing workflows in the platform and identifying the most appropriate messages and workflows in FIX to best replicate the functionality. This is not an exact science and is based on traditional finance “good practices” and what customers might expect to see when connecting. This requires significant experience to understand what works and what doesn’t.

Additionally, as many of the mature exchanges and venues will attest, getting it right the first time is crucial. Re-engineering a brown-field site is extremely difficult once live and can lead to significant disruption to your connecting customers. We would therefore recommend bringing in FIX experts to consult from an early stage.

The benefits are, however, obvious. By exposing a FIX API, financial institutions can extend the liquidity-providing algorithms designed for traditional markets into the realms of cryptocurrencies and digital assets. Crypto exchanges and platforms supporting FIX connectivity, therefore, have significant advantages over those that do not support it, not least attracting larger institutions and increasing their market share.

Going back to my original question – will REST/Websocket take over FIX – the answer is probably no. I expect traditional financial firms to expose more REST APIs alongside their FIX APIs and possibly the flexibility of ALL three. Certainly, in the digital world, I can see a world where it is normal to offer all three, mainly to diversify their customer base and increase their market share.

FIX is certainly not going anywhere soon but always remember there are alternatives. FIX might not be optimal for every workflow. But really think about the developer experience before exposing the most suitable API. Or speak to FixSpec and we can steer you in the right direction.