In every part of Istanbul, you’ll find stores which sell a plethora of snacks, ranging from dried fruit to nuts to baklawa. Whilst everything seems delightfully fantastic, ultimately, you can’t buy every single item. You need to make a choice. Invariably, when I recently visited Istanbul, I ended up choosing a mix of different things, perhaps some dried apricot, maybe some figs too, rounded off with a bit of baklawa. It’s always possible to choose one item and buy large amounts of it. The problem with that approach is that, you might find you really don’t like it: that sounds like an unnecessary downside risk to me. There’s a happy medium picking enough items, so you have enough to enjoy, but not too many that you have too little of each item.
In a sense, it’s like trading. The best way to get fired, is to concentrate all your risk in one position. Yes, it might work, but equally, it is taking a lot of risk and you can have a massive drawdown. Ideally, you want to diversify. From a systematic point of view, that means not only increasing the number of assets you trade, but also about diversifying the signal types you use. When it comes to developing a fintech business, it can seem like the only way is to put all your risk in one place, rather than the diversified “trading” approach. The argument goes that if you really want a business to succeed you need to focus on something specific. I can understand the rationale, of putting all your eggs in one basket and this can sometimes work. The difficulty is the trader in me absolutely abhors managing risk in this way.
So what are the typical business models you could adopt as a fintech firm, which is by no means a full list. I’m going to try focusing on B2B firms. Mainly, because that’s what my experience has been at Cuemacro, and I’m not familiar with B2C as much. I’ve been grappling with these questions for a while for Cuemacro, and am still looking for many of the answers too.
Software on a subscription basis
Increasingly firms are trying to pivot to this model, rather than having a one off licence fee. You pay an annual subscription and you get a licence to use the software (and any updates to it) for that year. Office 365 is an example of this. Adobe has also successfully transitioned to this. Typically, clients don’t get the source code, hence, makes changes is not as flexible. It is also possible to sell clients one off licences. Clients are then able to pay for technical support on an annual basis (or updates).
Data and analytics on a subscription basis
The idea here is that you have access to specific analytics. In a sense it’s like the software subscription approach, but you host it all in the cloud, rather than clients needing to install the software locally. Your analytics can also provide results based on data stored in the cloud (which the client can’t access in the raw form). Over time it is also possible to collect data to help improve the service and create value for a firm. For many firms these days, their data constitutes a large part of their value. For fintech, it could be for example option pricing or transaction cost analysis. This provides convenience for clients, because it’s (relatively) plug and play. However, again it is more difficult for clients to “own” the process, given they can’t change the code. Clients also need to share their data/requests externally, which not all clients might wish to do. Data is also something that can be offered on a subscription basis by fintech firms too, and this of course has been around as an idea for many years.
Open source model
Here you open source some your code. A fintech can offer additional code and features for paying subscribers or have offer technical support subscriptions. For clients there are lots of benefits, in particular that they get full transparency over all the source code and having the community view the code (and fix it) is likely to result in better code long term. The downside for the fintech is that potentially it becomes difficult to monetise, as many clients might simply use the free open source version and too few choose the premium features or pay for technical support. Of course there are some firms which have succeeded using this route like MongoDB. My experience of open sourcing software is that you can get a lot of users (eg. Cuemacro’s finmarketpy library), and it can be great marketing. However, more direct monetisation is tricky. One potential compromise is to get a sponsor for your open source library, who can get a marketing benefit from being associated with it. This is one approach that I’m thinking of pursuing for my tcapy (transaction cost analysis) library, finding a sponsor to help support me in open sourcing part of the library so they can get marketing benefits from it.
Consulting model
Here the fintech is effectively a consulting firm, providing more customised solution for individual clients. This gets clients exactly the solutions they want. However, it isn’t as easy to scale as standardised products, which we’ve mentioned earlier.
So what’s best?
I haven’t got an answer for this (yet), but if you have any thoughts about this stuff let me know! However, one thing that I’ve found is that a portfolio approach can work, and helps to diversify risk and cashflows. For example, a lot of the work I do, does involve consulting. However, at the same time, I also sell datasets as a service (for Fed communications). I’m also exploring different business models for selling my tcapy Python library.