On the surface, connectivity in Fixed Income seems daunting. FIX Specifications are fat documents filled with puzzling arrowed diagrams and tables of arcane jargon, developers only find out if it works when certifying after working in the dark for untold ages, and managers cannot predict how long or what resources will be needed and give up. I know this because I have spent the last 25 years building these and being properly frustrated.
In this blog, I intend to show that FIX is actually a simple protocol, that well written specifications actually make sense and that there are ways to support developers to get the connection done quickly, efficiently and correctly. I will show how and why connectivity to OpenYield is easy, fast and cost effective.
What is FIX?
FIX itself is an ancient (in computer time) line protocol. Each line of bytes is a message. Each message contains fields. Each field starts with a number followed by an equals sign and then the content of the field (e.g. 35=8). Each field is separated by a special ASCII character called a field delimiter, and each line has an ASCII terminator. And all messages end in a checksum so we know the bytes arrived safely. This line format comes from the old mainframe days, it’s proven, easy, reliable and very simple.
For example, a simple texting protocol can be defined as
- Field 1 is the text message we want to send
- Field 2 is the person’s name to send the message to
- Field 10 is the checksum (so we know all the message bytes are received)
If the messages (using delimiter ‘|’) are:
i
Then
- The first text is a birthday message to Mary, and
- The second text is a promotion message to Jane
i
All FIX does is standardize and define 2 things:
- What each number should mean (and in many cases what type or values should be used)
- A set of standard messages to be used in transactions between firms and which numbers (fields) need to be present for each message to be valid
i
And all a developer needs to do is know which messages they need to send or receive, and which fields to fill in (or will be filled in) for each message.
What is in these Fix Spec documents then?
It’s all well and good having a bunch of messages available, but a protocol requires a formal conversation between two computers to implement a transaction. Someone has to initiate the transaction, there may be a conversation between both parties and finally the transaction completes. Think of a protocol as a rote or scripted conversation for each transaction.
For example, the simplest conversation to buy a bond at a price between a trader and an ATS:
- Trader: “I want to buy 100 of AAPL-10Y at 101.1”
- ATS: “Ok, I have sold you 100 of AAPL-10Y at 101.1”
This can be converted into a protocol where
- Trader places an Order
- ATS Executes the order
In arrow diagram form this is:
And in FIX? Well, there are “canned” messages for this:
- Trader sends in a New Order Single Message to place the order
- ATS sends an Execution Report Message to confirm execution of the order
It turns out that trading over FIX requires knowing what the protocols are for each order type or transaction, and what the format of each message is.
That’s what the FIX Specification document defines. The transactions available (the canned conversations that can happen, i.e. when a specific message should be sent or received) and what fields each message should contain.
What about FIX sessions?
As an added level of complexity, marketplaces often offer a handful of various FIX sessions. Think of a session as a separate connection or pipe between your systems and ours. Traditionally, this was because they connected to different venue systems and had to be separate, but the more modern approach is to separate the functionality into logical, performant streams.
Common sessions include:
- A trading session, to send orders and receive executions back
- A RFQ session, to separately support the Request for Quotation trading protocol
- A market data session, in Fixed Income, to get depth of book market data
- A Drop Copy session to deliver copies of executions to back office systems
Each session may be configured differently, for example a Trading and a Drop Copy session will be set up to resend any missing messages on reconnect … so you do not miss any executions, whereas Market Data sessions traditionally do not as you need a clean snapshot on reconnecting and do not need stale orders.
Our FIX Specification makes it clear what each session is for and what messages go over which one.
And uniquely, we offer an Equity Style top-of-market session to provide best bid, best offer, high, low, open and prints in real time.
At OpenYield, how do we make it easier for developers?
So now we know that FIX is actually an old-school simple format, and that FIX specifications, if written well, define the protocols for each transaction, the formats desired and the sessions to use. That should be fast and easy to build, but only if developers are well supported.
Unfortunately, many existing venues were not API first so their interfaces developed on older protocols, pre-standard FIX versions, were built to match internal legacy protocols or implement legacy integrations to systems that no longer exist. As such, they had to heavily customize the standard FIX messages and protocols, often resulting in a confusing mess. Developers may understand the transactions required, but struggle to get the implementation right.
|
At OpenYield, our FIX spec makes it easy for developers:
- Our FIX spec does not customize any message in any way. We use bog standard FIX formats.
- Our protocols (transaction flows) follow those established by FIX and so use the correct messages as per the public standard and do not try to squeeze protocols into the wrong message type. Even our new RFO protocol just looks like a traditional RFQ message flow.
- Our transaction flows are simple Limit and Market orders, with standard acknowledgements, rejections, executions and a few status messages. Nothing unexpected, nothing custom.
But that’s not all, a simple spec may still be hard to follow for new developers, so we also:
- Start with the codes and settings needed to setup and run FIX to OpenYield while developing from anywhere anytime
- Spin up an endpoint to build against from day 1. Developers can create messages and send them to our endpoint and get instant feedback if the message is good or bad.
- Provide a GUI login to enable developers to see the orders placed and to execute the other side. This way, they can trade with themselves over FIX and get fast feedback on any issues across all transactions.
- Offer a real-time Slack channel direct to OpenYield personnel, including our back-end developers, to efficiently handle questions, issues and change requests.
- We provide a detailed certification checklist, so you can pick and choose what to certify and know beforehand if it works.
- And just in case that’s not enough, we’ve built and shared a C++ Open Source, free to use, implementation of our FIX client on Github here. It uses the open source QuickFix engine which is (a) well supported, (b) used everywhere and (c) used internally by OpenYield. If you want the sample in another language, let us know.
We are unaware of any other venue that offers this level of developer support. At OpenYield, it’s always there. Our experience with existing integrations shows they can be done in a matter of weeks from setup to certification.
OpenYield's Easy Button
“… have to give you guys kudos on your design & spec, one of clearer and better thought-out ones we’ve encountered …” |
After 25 years of frustration, I’ve now been able to build the spec I wish I had at OpenYield. We’ve made it easy: simple message flow, lit access to both systems and people and sample code to work from. The bond market you’ve been waiting for is here. Get connected rapidly and experience the joy of technology working for you, not against you, to scale and enhance your trading. Reach out now to get started.
