“It’s awesome, I’ve built an amazing market quant model” says a quant (hopefully, more than once in their career). Let’s say this is you, this model can help forecast markets. Is that it? Well, not really. The key point is that any financial model needs to be used in order to actually get any benefit out of them. It’s like building a burger joint, which has the most amazing burgers, but then hiding the front door, so no customers can actually find the place. I guess no one will find out quite how good the burgers are! For quants, this means, basically making models accessible to users to run.
So what does accessible mean? It doesn’t mean you have to expose all the mathematical complexities to a user. Accessibility is more about putting a front end on top the model which users can be comfortable. One of the most obvious ways to do this, is to create an Excel add-in. Excel, for better or worse, is the ubiquitous tool on every trader’s desktop. Having your analytical model accessible in Excel, immediately makes it bit more palatable to users. If you use Python, xlwings is a great library to connect your back end Python code to Excel. You can read and write to Excel cells and also respond to Excel events like button clicks.
You can also make it accessible through the use of a customised GUI, in particular a web based one. The nice thing with web based solutions is of course that you don’t need to install lots of dependencies on every user machine. Taking the web GUI route might take longer than trying to do something in Excel (although there are some tools such as Dash for Python and Shiny which are making it easier). It’s also worth noting that it isn’t necessary in every case, unless you are really making use of the graphical abilities of a browser. For a trader who has many different tools, having a separate GUI for each, can end up being overkill (unless of course you can somehow integrate them all in the same GUI!). In practice, having everything feeding into Excel could be a decent solution for many traders.
If in doubt, ask your client audience what front end they’d prefer! I’ve done some projects for clients where having something Excel based has been tool of choice. In other cases, I’ve opted for a web based GUI, given the graphical capabilities in Excel were not sufficient for what I wanted (visualisation around TCA). It really should be considered on a case by case basis. Ideally, you’d want to have multiple front ends implemented, but obviously, this can be time consuming.
Excel and other GUI options aren’t the only way to make your models accessible. Having easy to use APIs is also a big part of it. An easy to use API allows users to run more customised calls of your model. Of course, your users will still need to be able to write a bit of code to call the API, but you can still shield a lot of the complexity of the underlying model from them. Also make sure to add a decent number of example scripts to show how to call your API. No one likes having to figure out how to call an API, because of poor documentation, and having simple examples (in my experience) is a good way to get started. It can also be good to provide APIs which are accessible in multiple languages, if there is sufficient user demand (one option is to have RESTful API access, and then you can write simple client side libraries that wrap on top).
If you want people to use a financial model which you’ve developed, making it easy to access, means that it’ll be used a lot more. A brilliant financial model which no one can access is not worth as much as an easy to use one which perhaps isn’t quite as sophisticated.