How To Build A FIX API

The most popular API choice for the more forward-thinking venues, particularly for digital assets, is the combination of REST and Websocket. A call-and-response REST interface is ideal for order entry workflows and Websockets, with their streaming capabilities, work well for market data, order books and trade history. The interfaces allow for a relatively painless connectivity process for customers, and are invariably supported by a variety of efficiency-boosting tools such as 3-column online documentation, as well as SDKs and sandboxes for rapid development. Such assets make it far easier for retail customers and modern software vendors and trading houses to connect to complete development.

But the issue comes when these exchanges try to sell their services to the large, more traditional banks or buy-side firms, who invariably demand FIX as a protocol they are more familiar or comfortable with. This, in turn, causes exchanges to take the decision to add FIX alongside their existing APIs.

Who on staff “speaks” FIX? FIX experience typically commands a salary premium, and so there may not be anyone. As this is a long-term API option for them, the conversation quickly turns to hiring a team to do this. Developers with FIX expertise do not come cheap and spinning up a FIX API is a significant project with several challenges and strategic decisions along the way.

This is the typical point at which we meet new firms for projects like this; they’ve made the decision to offer FIX, but they don’t know where to start. By offering outcome-based consulting (as opposed to fixed term consulting), we are able to offer crucial guidance, support, training and analysis in those early days before they have assembled their full team. This sets them up for success, and lets them take over the reins when their team is in place.

This article describes the different phases of a typical consulting project and how, on a high level, a functioning FIX API that will be accepted by the largest financial institutions in the market can be designed and built.

Phase 1 — Discovery. Design. Document.

So where do you start? If a venue has existing functionality exposed through either a User Interface or REST/Websocket, this phase is slightly more straightforward. This phase takes a deep dive into the REST/Websocket functionality and proposes a target FIX API for relevant interactions that are currently supported. This involves mapping functionality and workflows to suitable FIX messages, fields and values based on our industry experience and best practices where known.

One challenge here is that REST and Websocket rarely translate perfectly to FIX, which has evolved over time and is often subject to customisation. This requires a blend of expertise and domain-knowledge to advise on best-practices that institutions will (hopefully) recognise and accept.

For completely greenfield new venues, the discovery phase is higher as it requires a detailed understanding of the proposed functionality and trading workflows of the exchange or venue. Our consultants have designed trading platforms for some of the world’s largest firms, so don’t worry — we speak your language.

The key outcome of this phase is the completion of a professional API specification or “rules of engagement” that is suitable to hand out to customers and prospects to begin development. These documents not only present the message contents themselves, they also describe the functionality in business and technical terms and seek to answer many of the questions we typically hear about FIX APIs.

Think of this phase as an architectural drawing for your API; a professional, detailed document which describes what we are aiming to build. The next step is then to build it.

Phase 2: Engine & API Build

FIX connectivity is established and “managed” by a FIX engine — a piece of software that takes care of sending and receiving messages. A key decision here is whether to build in-house, licence a commercial engine, or deploy an open-source FIX engine; this will depend on a number of factors such as performance and support requirements, budget, need for message transformations, surrounding infrastructure and what language it is written in.

There are several commercial engines to choose from, and free (open-source) FIX engines on Github in most common programming languages, including C++ and Java. Navigating and comparing the various options can be difficult, not least because there is often limited information available on commercial engines, and because performance metrics are rarely presented in a like-for-like manner.

We recently completed a project which analysed the various options on the market and are therefore in a good position to support this decision. Broadly speaking, however, commercial engines have the advantage of better support, out-of-the-box integrations, and user-friendly tooling for message transformation. On the other hand, the open-source QuickFIX engine has a long history and (while not the fastest engine on the market) is extremely robust.

When considering FIX engines, it is important to understand that the engine is really just a software library or component; you will still need to write the code to construct messages to send, and interpret messages received from others.

Phase 3: Devise An Onboarding Process

A key element of onboarding to a FIX interface is conformance — the “driving test” that customers and software vendors are typically asked to perform to confirm that they have coded to your API correctly.

There is software that automates the mundane task of reviewing log files to confirm conformance, but how do you write the conformance tests in the first place? If this is your first FIX API, then it can be hard to know what to test, how detailed or exhaustive they should be, and even what format you should provide them in. You need to strike the balance and write conformance scenarios that will both reflect your FIX specification from phase one, and deliver them in a format that customers will expect and accept.

In software engineering, it is now rare to see API documentation posted on a website or emailed out as a PDF file — this is something that is peculiar to FIX it seems. More modern APIs consider the overall developer experience and ensure that it is as frictionless as possible. That means providing (and collecting) the correct information in the right order to ensure that the customer is connected as quickly as possible; it means putting the customer at the centre of the process as opposed to forcing them to adopt your way.

A developer portal is a great way to present (and collect) all the required information to customers, which is why the majority of REST APIs typically offer these today. This is currently less common in the FIX world, however, simply because most trading firms have no suitable (web) development skills on staff to deliver them. A portal can, however, be a place where customers are delivered the right information at the right time, and guided step-by-step through the process. You can give them online forms to complete and then expose digital versions of your specifications which are rendered onto a web page in a user-friendly way, and even show them real-time FIX message traffic.

You need to take a step back and look at your internal systems and customer touchpoints to ensure a seamless onboarding experience. To support this, we have examples of workflow asset templates that can be built out and we have built custom developer portals for customers that incorporate the whole process.

Phase 4: Quality Control

Before exposing your shiny new FIX interface to customers, it is always a good idea to give it a test run. We are not (just) talking about QA here, but by a third party who was willing to experience the overall process from the eyes of a customer and give you candid feedback on where to improve.

This process should ideally examine the end-to-end onboarding process, from making a network connection, through data collection, reading the documentation, and through conformance testing. It is about identifying the points at which information becomes unclear or confusing, and confirming (at a technical level) that your API behaves in the way the documentation says it does.

Once any required re-work has been completed, your FIX API is ready and you can start onboarding customers. If you have the luxury of a larger list of prospects that are ready to connect, it might be worth including a market feedback phase. This involves cherry picking a few customers to test out the onboarding and connectivity processes before mass deployment. Not all buy-side or vendors are the same and this can therefore produce some really useful feedback and allow you to incorporate some flexibility in your processes for different counterparties.

—

And of course, this is not something that gets designed and implemented once and it doesn’t get touched again. This is a process that gets tweaked and fine-tuned over time. The functionality you support will likely be iteratively built on over time and you need to ensure that changes are integrated seamlessly and do not break existing connectivity. There are therefore best practices that can be followed to ensure minimal disruption for customers and remove the need for excessive re-conformance following an update. We often continue to work with our consulting clients far beyond them going live to make sure their customers continue to have an optimal connectivity experience.