As keen readers will know, I have been a big fan of the idea of transitioning FIX from a message based protocol to a state+message based protocol. This is all quite geeky but it can potentially revolutionise Electronic Trading globally for all asset classes, for buy-side, sell-side, exchanges, regulators and any other market participant.
With that rather ambitious opening paragraph - what am I talking about? In essence, FIX is a very underspecified protocol, so many times in my working life I have seen two firms that hire smart people implement the same functionality in very different ways. Why? There's not enough in the protocol to make it clear to any implementer what is the right way and what is the wrong way. Ah, but isn't that the benefit of FIX - that it's flexible and not beholden to a central body in the manner of SWIFT? Well, yes and no. As a simple example - if you drive a manual car, the clutch is on the left, brake in the middle and throttle on the right. It's an adopted standard and cars that don't conform are few and far between.
When we look at FIX implementations we see vast differences in behaviours, messages used in the wrong direction and with meaning different from specification, hybrid messes of versions with combinations of FIX 4.2, 4.3, 4.4 and 5.0 all in the same workflow and other abominations.
Now, this impacts in terms of the pure, clean aesthetic that many technologists aspire to...
But, way more importantly all of this mis-use of FIX has severe adverse impacts:
- increase the cost of trading
- increase operational risk
- increase time to market for any changes
- makes distribution of business specific workflow to third party platforms such as EMS much harder and more expensive.
So - how does state+message change this? Simply put, we can convert a FIX workflow into a machine readable format that can then be loaded, parsed and processed by computer systems for consuming systems. So an exchange workflow will be loaded, parsed and processed by brokers and a broker workflow will be loaded, parsed and processed by buy-sides. And so on...
But - and here's the key value proposition - this workflow once loaded, parsed and processed will configure the consuming system such that it knows how to interact with the producer system. As a very simple example, if an exchange only supports "day-only" orders then a broker system will know that it can either only send "day-only" orders OR it could, as a value-add to the broker, implement a synthetic good-'til-cancel workflow by resending the leaves quantity on partially filled day-only orders on the next working day.
So we move from having expensive computer systems plus expensive staff to a world of perhaps more expensive computer systems but with fewer staff and less of the adverse consequences listed above.
This proposal has now been brought under the auspices of the FIX Trading Community with the name "FIX Orchestra". If you have time - join the working group - it's going to be huge...
FIIDL - FIX Interactive Interface Definition Language (part three)
Google, robots.txt and the “Search for Liquidity” Google, robots.txt and the “Search for Liquidity”: Fixed Income edition
Comments
Post a Comment