One of the trends that we are seeing with more recent trading venues (which tend to be crypto exchanges), is that they are starting to offer both REST/Websocket and FIX interfaces. You might be asking why have both, and what’s the difference between them?
I’ll assume here that if you are reading this, you know probably know more about REST/Websocket APIs than FIX APIs because it’s quite an old and specialist protocol.
FIX was originally launched in the early 90s (a time before the modern internet!) and has grown to dominate institutional market connectivity within trading; it’s the protocol that the vast majority of investment banks and brokers use to “talk” both to each other and to trading venues. Its strengths lie in the fact that it covers all asset classes and the organisation behind it — the FIX Trading Community — have modelled more and more workflows in it over the years, including order delivery and execution, quoting, market data, and even into after-the-trade activities such as settlement.
FIX really was well ahead of its time when it was first launched, and while it has a learning curve to it, it is simple and robust enough that it is still really well-suited to the job today, thanks to the fact that it is very efficient and it is extremely well-supported.
So what’s the difference between FIX and REST/Websocket?
Well, the first (and perhaps) biggest thing to note is that I’m referring to REST and Websocket here you need both in combination with web APIs to achieve the type of communication you need for trading. The REST portion is essentially a “request-response” interaction; I send you a request (get or post), and you respond with a one-time response back. But this doesn’t work for “push” notifications such as market data, or notifications of a trade after a period of delay. And that’s what the Websocket portion of the API handles. On the other hand, FIX opens a persistent TCP connection which allows the parties to exchange both types of message. This is something that is handled automatically by a FIX engine.
A FIX engine is a software component that establishes a persistent connection (also known as a session) between you and the firm you are connecting to. Establishing this session involves the exchange of logon messages, and a “heartbeat” mechanism to detect disconnects. Most of this technical detail is hidden from view, however.
The FIX engine also allows you to send and receive application messages to perform actions such as submitting an order or receiving a trade notification (the exact range of what can be sent or received is detailed in the API’s FIX documentation).
Now, you might ask the question of whether market data can also come down FIX connections as it can with Websockets. The answer is a caveated yes. FIX is a point-to-point protocol (between two parties) as opposed to a broadcast protocol (one to many). And so if the market data is somehow limited, filtered or tailored to you or your requirements, then FIX certainly has the messages and workflows to send that type of information down a FIX connection. If, however, the market data needs to be distributed to a large audience, then it becomes quite inefficient to repeat the same data many, many times. And for this reason, there is a slightly different version of FIX called FIX FAST, which is better optimised for broadcasting market data to multiple recipients at once.
I hope this gives you a basic understanding of how FIX APIs differ from REST/Websocket APIs that you might have experienced before. I’ll be sharing more information about FIX here in the future, so please click the follow button to keep updated. Alternatively, please check out my YouTube channel with lots more information on FIX.