Remember me

Register  |   Lost password?

The Trading Mesh

Timing is Everything; or is it?

Fri, 14 Dec 2012 04:21:32 GMT           

This is the second of a 2-part series on the buy vs. build decision process. You can access my other article here


In a world where trading systems can execute deals in microseconds and algorithms can snatch the best offer before your brain can process the number, one can begin to get the feeling that timing is everything. So time-to-market with a new trading system is of the essence. But is a quicker time to market enough to differentiate your firm in today's competitive marketplace? It depends.


In most cases, implementing an off-the-shelf product will reduce time to market. But this can be an oversimplification. Certainly the time needed for the front-end implementation may be reduced, but this is largely a by-product of the restricted customizability inherent in many off-the-shelf products. Anyone making a build or buy decision must weigh the advantages provided by a quick time to market against the benefits that could be derived by incorporating specialized functionality that differentiates your firm. While it may be difficult to quantify any potential losses due to not incorporating proprietary functionality, your institution must weigh this against time to market advantages. 


Generally, we recommend that if the functionality is relatively commoditized, you should buy something off-the-shelf, as having something unique is generally not as valuable as a quick time to market.


While off-the-shelf systems usually can be quickly integrated and launched, the amount of implementation time required for the in-house team to familiarize themselves with the system is often underestimated. Also, buying a one-size-fits-all platform is rarely the option that creates the kind of personalized client service and satisfaction that attracts order flow. If your clients send their flow to a competitor that offers a richer set of functionality, it really doesn’t a matter that your system was launched in record time.


Building a system from scratch can take substantially more time than implementing and learning to use an off-the-shelf product. In-house development of a trading platform will typically take upwards of two years. Developing a system in-house means meeting lots of requirements that have little to do with business functionality, including load balancing, scalability, disaster recovery and fail-over, low latency, state management, API interfaces and many other specifications. All this development requires a substantial information technology team, and resources like this are not always readily available.  As the relevant life cycle for software shortens through competitive forces and market needs, the time and resources required for an in-house development project are often out of the question.


Rather than choosing between buy and build, we recommend going with a hybrid, buying the commoditized components, assembling them, and developing proprietary functionality like specialized pricing, algorithms, and risk management on top of those components. Of course, that assumes that the pre-built components include a flexible API.  


By harnessing the pre-built commoditized components within a buy-build hybrid model, you can quickly integrate key functionality required by a changing market, effectively capturing a first mover advantage. By purchasing these commoditized components, developers can focus on the functionality that truly differentiates your system from competitors and delivers value in terms of revenue, improved risk management, or customized services and pricing.


A faster and more reliable time to market while creating a competitive advantage. These are important advantages derived from the buy-build hybrid model. The relevant risks and benefits to the model, compared to buy or build in isolation, are detailed in a recent fact sheet published by smartTrade. You can access that here.


David Vincent, CTO and Co-Founder, smartTrade Technologies


The opinions and writing contained in this article are of the author alone and do not necessarily represent those of

, , , , , , , , , , , , , ,