FIX Protocol has undoubtedly been a success story in the industry. When it was launched it was well ahead of its time but as the protocol matures, progress has understandably slowed. At a time when the wider API ecosystem is booming, Chris Lees asks whether the FIX Protocol can remain relevant for the long term.
The FIX protocol has been around for 30 years, an astonishing accomplishment when you consider that back at launch in 1991 there was precisely one website in the whole world; FIX pre-dates the modern internet by many years.
So if it is so established and mature, why is it that firms routinely struggle with FIX processes that remain stubbornly manual, lack transparency, and are so unpredictable? If you work in FIX connectivity, you might recognise the feeling of working like crazy simply to maintain business as usual, let alone undertake anything strategic.
By contrasting how FIX has evolved over time compared to the evolution of web (REST) APIs, it turns out that there was a pivotal moment in the evolution of web APIs which has placed them on different trajectories. I believe this will be the key differentiator that seals their fate into the future.
FIX – Before and After 2001
FIX first appeared in 1991 and evolved rapidly in the first few years. Fast forward to 2001 and the protocol was well-established, FIX 4.2 had been released (a version still widely used in equities today), software such as VeriFIX and CameronFIX were enjoying early success, and QuickFIX would appear a year later.
But what happened in the next 20 years? While the protocol has extended into other asset classes and responded to regulation, the pace of change has slowed significantly (a positive – you want protocols to achieve a level of maturity and stability). Except for a brief flurry of activity around FIXatdl, FIX tooling has generally stalled, with the same brands still dominating market share today. While platforms have innovated around automated FIX certification, these have run headlong into the biggest problem FIX faces today – 20 years of deeply ingrained working practices which have barely changed since the 1990s.
Web APIs – Before and After 2011
Commercial web APIs first started appearing around 2001 from companies such as Salesforce. Unlike FIX, web APIs don’t have the advantage of a standards body to define elements such as expected content, naming conventions and enumerations; web APIs had (and still have) fewer guide rails beyond well-defined HTTP verbs and error codes. Despite this, within ten years web APIs had – much like FIX – gained a lot of traction.
This 10-year mark is the pivotal point at which the fortunes of FIX and web APIs diverged.
In their first decade, both FIX and web APIs were documented using “traditional” means – largely static documents posted on some website. But in 2011 the first version of a JSON schema to describe web APIs was launched, called “Swagger”. It recognised that while every API was different, they could (and should) be described in a consistent, machine-readable manner and that these documents could be re-used to automate some frustrating and time-consuming tasks related to API connectivity, such as testing and code generation.
The Swagger schema (later changed to the OpenAPI Specification or “OAS”) has transformed how web APIs are used, fuelling an exponential boom in their adoption.
By contrast, “modern” FIX connectivity remains stuck shuffling PDFs around…
Is It Too Late To Save FIX?
When I ask what they think the future might bring for FIX, I typically hear a variation along the lines of “FIX is too deeply embedded to go anywhere”. This is quite a troubling statement, as it suggests people do not feel a positive attraction to FIX, but rather they use it purely because they always have and because other firms expect it. The lacklustre response suggests that the day may arrive (soon?) when something else could arrive to displace FIX. Given that most crypto exchanges now routinely offer FIX alongside REST/Websocket APIs, that day may arrive sooner than people think.
At fixspec, we are more positive about the future of FIX. There is – after all – a mountain of value in the detailed, domain-specific data and workflow modelling that the FIX Trading Community has built up over the decades, and this is work is echoed in the crypto REST APIs above – names and enumerations often mirror FIX almost perfectly.
Our optimism is tempered, however, by the belief that to “compete” and remain relevant against web APIs in particular, FIX must undergo the same transformation that web APIs went through in 2011. As an industry we must adopt structured, machine-readable and re-usable API documentation or else FIX will fade into irrelevance.
What is the prize?
Everybody is busy. The last thing anybody wants to hear is that they need to dust off their FIX document and invest time and energy to convert it into something machine-readable.
The same was true for web APIs, but by adopting structured, machine-readable documentation, the web API ecosystem now boasts a range of tools that are simply not available to FIX, including:
• the ability to mock APIs without writing code
• the ability to interactively test an API from within the documentation
• the ability for customers to create code stubs directly from the documentation
• the ability to auto-generate API test cases directly from the documentation
• …
All of these advantages are also available to FIX if only we (collectively) put in the work to make it happen.
The overall business trend towards greater workflow automation and integration is clear and has only accelerated during the pandemic. Firms want connectivity to become a well-oiled machine, which is efficient, transparent and fast. Such an outcome is achievable, but it critically requires firms to shrug off outdated processes and start making strategic investments in their process and documentation.
If we can do that, then maybe there’s life in FIX yet.