In this article, I’d like to shine a light on an area of FIX that seems to be quite confused in people’s minds, and that is the “security” (or not) of FIX specifications.
The background to this is that we conducted some market research in December 2020 in which we asked people how they distribute their FIX specifications today. We found that 51% of respondents said that they
email a PDF to a defined distribution list, and a further 24% said that they simply post a PDF onto their website. So we can simply conclude then that the vast majority of forms take a “traditional” method of distributing specs, based around a PDF. No surprises so far then.
We also asked the question of whether they would be interested in sharing their specifications through a secure portal if such a thing existed. Now 49% of respondents said that — yes — they would consider using such a portal, and a further 18% gave the stronger response that they would definitely use such a system. So we can conclude that the majority of respondents are at least open to the idea of distributing specs in a mo0re modern way.
The interesting insights here, however, lie in the free-text comments that people left in their response which explored some of their concerns or minimum requirements to adopt such a system. Three broad themes appeared:
1) Versioning: how do they make sure that their customers have the correct version?
2) Security: how do they know that nobody can hack into our servers and “steal” their specification?
3) Control: how do they know that customers that they send their spec it don’t forward it on to somebody who shouldn’t have it?
Scoring Distribution Approaches
These themes give a useful framework to evaluate and compare the three distribution mechanisms considered (email, post on a website and portal).
Our questionnaire found that this was the most common mechanism, and I like to refer to it as the “pinky swear” method as it essentially entails sending an email to someone and asking them to pinky swear not to do anything malicious with it. What is peculiar about this scenario, is that often they barely know the person they are emailing (the spec is one of the first documents exchanged), and therefore there isn’t the level of trust yet.
You can probably assume that the recipient will save the file onto a shared drive somewhere to allow his/her colleagues to access it. But who are they and can you trust them? You can see that you very quickly lose control over the document, which means that this mechanism scores very poorly on both security and control.
Email also scores poorly for versioning. Sure, the first version of the document may have made it to your contact, but what happens if they leave or go on holiday and the next version is lost or drops into spam or something?
So what about putting the document on your website? Well, I should first note that this option is not available to everybody. Many brokers would not even consider this route, as they may fear that proprietary intellectual property might become visible to their competitors. In other words, they have such a high demand for “security” that the idea of posting it publicly is an anathema to them.
[As an aside, I would strongly challenge such a position which typically stems from the idea that competitors can “reverse engineer” their systems simply by reading their API documentation. This is simply not the case; the far bigger problem is that the same API documentation is likely to also contain detailed functional descriptions, and it is this information that can allow others to replicate their systems and not the pure API documentation.]
The only firms who typically post API documentation to their websites, then, are trading venues. The act of publicly posting the document implies that the idea of secrecy and control are not important factors for them. But what about versioning?
While we would love it if our customers checked our websites every day looking for an update, the obvious fact is that they don’t. And therefore posting it on the website doesn’t remove the need for an email notification at all, and so it scores no more highly than email distribution does on this criteria. The ability to withdraw old versions from your website gives little more than the illusion of version control, in fact — it doesn’t stop customers from saving a local copy.
Secure Portal Distribution
Of course, there are lots of different ways in which a secure portal can be organised which will influence its score against these criteria. The secure portal we described in our market research was a new cloud-based “app” due to be released by FixSpec in June 2021. It is a centralised portal capable of privately sharing specifications from multiple firms. It’s not a public library that anybody can search, but instead a many-to-many service designed for precisely this purpose.
So how would it handle versioning? The app allows document authors to create and maintain multiple versions of as many specifications as they need, and to click to publish them whenever they are ready. The act of publishing a spec automatically notifies anybody who has previously received a copy of that specification, removing the need to separately maintain email distribution lists. Updates immediately arrive inside the workspace of the recipient, which makes the email notifications purely a notification; if they miss the email then they still get the update.
What about control? Because the specification lives inside the app, we can collect detailed information about when it is accessed; useful management reporting information that isn’t possible with PDFs. We can also restrict the ability for specifications from being forwarded on to other people, giving a much higher level of control than email-based mechanisms.
And finally, what about security? We find that unfortunately firms still become extremely concerned when you use the word “cloud” as if the cloud is inherently insecure. We’ve designed the system to be as secure as possible; every single specification on our server is encrypted with its own encryption key that rotates every 24 hours, meaning that in the unlikely event that somebody did manage to get hold of one of the keys (which is unlikely), they would have a very limited window to access just one document before that access was closed again. The encryption keys are on our server, of course, which means that we encrypt all of them too! So it is daily encrypted keys that are themselves encrypted and stored inside of a security-hardened server. Can your “pinky-swear” email mechanism do that?!
Summing It Up
There are two key messages that I want to leave you with today.
The first is that our market research indicates that while most people are using “traditional” methods of distributing PDF-based specifications, but that respondents don’t appear to be wedded to this approach and A significant majority would at least consider moving to a secure portal if one was available.
The second is that moving to such a secure portal will directly address the top three considerations highlighted by respondents for spec distribution — versioning, security and control.