Introducing Machine Readable ROEs - FinSpec Schema

FixSpec 2nd Mar 2016
3 min read

API Specifications FinSpec

Last year I wrote a blog post concerning a proposal for an electronic format for FIX specifications (or ROEs) known as FIX Service Profile.

Almost 8 months have passed us by and the only visible progress appears to be a name change to FIX Orchestra. (I hope to learn about more substantial progress at the EMEA FIX conference in London tomorrow). My previous post presented a number of challenges with the proposed format, not least the FIX-specific nature of it, and overcoming the chicken-and-egg problem that may hinder adoption.

FixSpec believe that electronic ROEs are the future, and that the industry can't afford to wait for lengthy FIX Trading Community committees to agree. So today, we have open-sourced OUR vision of what what we believe multi-protocol, electonic specifications for financial services should look like. You can find the schema and documentation at

How do I write an ROE in this format?

ROEs are coded as simple JSON files using the schema. We chose JSON because of it's simplicity, the fact that it doesn't require specialist software to view or edit it, it's widespread support in almost all programming languages, and the fact that it plays nicely with web APIs. There are also a wide variety of free tools to simply and easily difference two JSON documents, so ROE comparison becomes a breeze.

Just because it is JSON doesn't mean this is unstructured however -- this is where the FinSpec schema comes in. The schema (itself a JSON document) describes how a specification must be laid out, and what fields and content are required for the document to validate. It is much like DTDs in XML. So once you have created your ROE document, you can validate it against the FinSpec schema to ensure that the recipient will be able to parse the document. There are a variety of free tools to do that, or simply grab our node.js validator from Github.

By the way, the json-schema has a whole host of other advantages, which I won't go into here but will blog more about as the schema develops.

What information does it contain?

The initial schema supports simple descriptions of messages, fields and values. It can also document contacts, contain message examples, and is extensible to allow custom content.

We are already working on v0.2, which allows the capture of both field conditionality and state-transitioning workflow - more details to follow shortly.

Why Github and not contribute this to FIX Trading Community?

Well, partially because we really want this schema to remain protocol-agnostic and not tied to (or overly-influenced by) FIX. But mostly this is about evolving the schema in a much faster, more transparent way. Your firm doesn't have to be a FIX Trading Community member to contribute, you don't have to be "nominated" to sit on a committee, and you don't have to sit through endless conference calls. We are inviting everybody to contribute to something that we hope will make everybody's lives easier.

Today we release just version 0.1 of this schema. With your help we can quickly make it better and more useful for everybody. Please don't sit on your hands and wait until version 2.x before investigating how this can benefit your firm -- get in on the ground floor and help shape the schema to solve your real-life issues.

Drop us a line or send us an issue on Github, and let's build this schema together.

Find This Useful?

To receive more tips for improving efficiency in YOUR connectivity process, sign up to our FREE monthly email newsletter.

Awesome - thanks for signing up. You can unsubscribe at any time by simply dropping us a line.