Without a doubt FIX (Financial Information eXchange), the information and data protocol used to disseminate price and trade information among the financial trading community, has become the de-facto messaging standard for pre-trade, trade, and post-trade communication, and it is compatible with almost every commonly used network technology.

It is ubiquitous, covering all asset classes and the FIX Trading Community have continued to add workflow processes over the years, including order delivery and execution, quoting market data, and post-trade activities, including settlement. So, “if it ain't broke, don’t FIX it!” Right?

Well, most large trading venues that are concerned about low latency execution and data flow have built their own proprietary APIs, to ensure that they stay ahead of the “arms race” amongst algorithmic and high-frequency traders. But they will all generally offer a FIX alternative for those who are less concerned about nanoseconds. Alternatively, many new users who are entering financial markets and are not familiar with FIX have been looking for alternatives that provide greater flexibility. They don’t want data that is tied to standardised protocols or methods, they want to process multiple types of calls, send different data formats and build an API that meets users’ needs, including integration with their Excel Add-In.  In other words, “give me a REST!”

REST v.s FIX, pros and cons

REST - Representational state transfer- is a software architectural style that was created to guide the design and development of the architecture for the World Wide Web. So it is not surprising that the tech-savvy, quant-driven newbies that enter today’s trading floors are more familiar with REST APIs and WebSockets than a FIX interface. And it is not just the financial community that deploys them, it is egalitarian, available across all industries as part of the new API Economy. REST APIs essentially provide a “request-response” type interaction, where users send a request for information (“pull”) and the recipient responds with a one-time response. For “push” notifications, such as market data and notifications of a trade the WebSocket works alongside REST APIs to handle that traffic. 

The other thing to consider when determining your approach is the time, effort and therefore cost of deploying a FIX API. FIX is a point-to-point protocol (between two parties) as opposed to a broadcast protocol (one to many). Therefore, given the security requirements of the financial community, the legacy approach has been to connect to clients via FIX with a Virtual Private Network (VPN) or a dedicated lease line. This further requires integration with and/or management of FIX engines to ensure a persistent connection between the provider and their client and to maintain the session, including the exchange of logon messages and a “heartbeat” process to detect disconnects. Therefore, it is not unusual for a new FIX project to stretch into a 6-month onboarding process! ipushpull has seen sell-side clients connect to and be operational on our REST API in 30 minutes.

The best of both worlds

So, where does this leave us? There is no need to develop an API altercation or ageist references to “old” FIX engineers relative to “new” REST developers. The future is hybrid! Firms are investigating ways in which they can mix and match the convenience and flexibility of REST with the efficiency and interoperability of FIX. Let’s call it FIRST!? Furthermore, there is a standardised way to convert FIX messages into JSON, which is the format that REST APIs commonly use.

The crypto and digital asset exchanges/venues have shown us that, while many of them started out as REST API/WebSocket driven, as they have attracted more institutional clients they have started to offer FIX as some of those clients are more familiar with that. Therefore, we have seen moves toward FIX protocol absorbed within a REST wrapper or some variation on that theme the other way. For example, ipushpull is now taking post-trade FIX messages from a trading portal and translating the protocol into human and chatbot-readable messages via our REST API which is routed into a dedicated Symphony chat room. Naturally, that works interoperably in the other direction.

An example of FIX trade axes delivered over Symphony chat, picked up by an ipushpull chatbot, transformed and aggregated into a live overview in the ipushpull platform

In summary, there are no bounds to developments in the API space but for sure there is increasing acceptance of REST APIs in the financial community and this will grow further with the OpenAPI initiative which is defining a standard, language-agnostic interface to RESTful APIs without access to source code, documentation, or through network traffic inspection. This should provide standardisation analogous to the FIX protocol. Moreover, the new no/low code development is compatible with a REST API environment, driving further adoption.

The future's bright …. The future's FIRST?

Click here if you want to know more about using ipushpull for your integration needs. Why not contact us to discuss this further?