API Specifications FinSpec
What do you think of when you think of the FIX protocol? A well-defined, mature industry-standard that everybody around the world understands, that makes financial services connectivity a breeze? Or do you see painful, manual process that is full of delays and inefficiency?
This post isn't intended to be a criticism of the FIX Protocol itself (which is both rich and mature) or the good people who dedicate their time and energies to maintaining it (hat-tip to all of you folks...). This post is about all of the other stuff that gets in the way of allowing FIX to live up to its promise when it gets out into the real world.
It's just over six years ago now that I set up FixSpec. After a career spent working for banks, exchanges and vendors, I had finally figured out the root cause of the pain, inefficiency and delays in making and maintaining API connections (with FIX being the most common). The problem is not the technology, the protocol or the people. The problem is the spec itself, or more precisely the problem is the way the spec is delivered. We need to change what it means to have a FIX specification. We need to fix (small 'f') the spec.
There are three principal problems we see with FIX specs today:
They are 99% of the time written in Word and exported to PDF - a dreadful structure and format that doesn't help customers read, understand and compare, and essentially impossible for QA teams to meaningfully validate.
They rarely have a clearly-defined owner, making them frequently out of date, inaccurate or incomplete. Banks and vendors who support customer-specific changes compound this problem; the "owner" should be the onboarder who agreed to a customer override, but the agreement is often never formally captured as part of the spec itself (only in email or scattered configurations), perhaps because it isn't appropriate to do so in the Word document.
It's difficult to write a spec which meets the needs of all potential readers. Some aim to keep them short by assuming a lot of FIX knowledge, only to meet other developers who struggle to fill in the blanks. Assuming too little knowledge leads to massive documents that nobody reads. Trying to split or cram too much information into a single idea (eg all asset classes in a single message) just makes things confusing.
I strongly believe that all three of these problems stem from one root cause - Microsoft Word.
That's right - Microsoft Word is the root cause of all of your FIX pain.
The simple reason for this is that Word (and PDF) is designed as a publishing format, and not as a format to be consumed by other processes. In other words, Microsoft Word is a dead-end that is unable to be recycled into anything else of value.
So what do I suggest should replaces Word?
The only way to improve the current situation is to embrace electronic, machine-readable formats. There are a few out there - we would pitch our FinSpec JSON format, FIX Trading Community would point to their FIX Orchestra, and others may note the maturity of the QuickFIX XML format.
The challenge for firms today is not actually which format(s) to choose, but how to manage the migration given the practical constraints they face, which include:
The continued need for a branded PDF to give clients who are not yet able to accept machine-readable formats. The idea of maintaining parallel Word and electronic formats destroys the benefit, and therefore any solution must be "convertible" into branded Word/PDF.
There are a lot of formats out there - some legacy, some new. Any solution needs advanced conversion functions to allow me to edit once and export to anything customers or vendors may demand.
I have a lot of legacy Word specs lying around, with various owners and accuracy levels. Accumulating, uploading and normalising them will take time and resources that I don't have, and so there needs to be an easy process to upload them (preferably one I can outsource at minimal cost).
Once the documents are loaded, I need to be able to manage updates myself (with full audit control, comparison and commenting), and I need tools that help me incrementally improve the quality and accuracy of the documentation.
Any cost associated with new tooling needs to have a corresponding benefit in terms of faster onboarding, higher QA automation, greater spec accuracy, or opening up new integration possibilities that arise from moving to machine-readable specs.
These were the five product development goals of the FixSpec product suite, and the ones that continue to guide our product vision and roadmap. It's about finding practical ways to move the industry towards a more efficient future while managing the short-term realities all firms face today.
As I sign off this post, I'll leave you with a small piece of homework... When you next have five minutes of dead time - walking to a meeting, on your commute, or on the treadmill in the gym - try to think of a benefits that you get from maintaining your FIX spec in Word today. Then think about the benefits you could unlock in the future state that I've described here. I hope you find the exercise enlightening!