Articles related to research conducted by Empirica in the area of algorithmic trading and software development.

FinTech. Lessons learned from over 5 years of financial technology software projects.

By Michal Rozanski, CEO at Empirica.

 

Reading news about fintech we regularly see the big money inflow to new companies with a lot of potentially breakthrough ideas. But aside from the hype from the business side, there are sophisticated technical projects going on underneath. And for new fintech ideas to be successful, these projects have to end with the delivery of great software systems that scale and last. Because we have been building these kind of systems for the fintech area for over 5 years we want to share a bit of our experience.

 

fintech empirica

 

“Software is eating the world”. I believe these words by Marc Andreessen. And now the time has come for finance, as technology is transforming every corner of the financial sector. Algorithmic trading, which is our speciality, is a great example. Other examples include lending, payments, personal finance, crowdfunding, consumer banking and retail investments. Every part of the finance industry is experiencing rapid changes triggered by companies that propose new services with heavy use of software.
The best evidence that something is happening somewhere is to see where the money goes. Investments in fintech companies globally grew to $12 billion last year, which is a three times increase comparing to 2013, and five times during the last five years, according to the research reports by CBInsights.

If fintech relies on software, and there is so much money flowing into fintech projects, what should be looked for when making a fintech software project? Our outsourcing software projects for the fintech industry as well as building our own algorithmic trading platform has taught us a lot. Now we want to share our lessons learned from these projects.

 

1. The process – be agile.

Agile methodology is the essence of how software projects should be made. Short iterations. Frequent deliveries. Fast and constant feedback from users. Having a working product from early iterations, gives you the best understanding of where you are now, and where you should go.
It doesn’t matter if you outsource the team or build everything in-house; if your team is local or remote. Agile methodologies like Scrum or Kanban will help you build better software, lower the overall risk of the project and will help you show the business value sooner.

 

2. The team – hire the best.

A few words about productivity in software industry. The citation is from my favourite article by Robert Smallshire ‘Predictive Models of Development Teams and the Systems They Build’ : ‘… we know that on a small 10 000 line code base, the least productive developer will produce about 2000 lines of debugged and working code in a year, the most productive developer will produce about 29 000 lines of code in a year, and the typical (or average) developer will produce about 3200 lines of code in a year. Notice that the distribution is highly skewed toward the low productivity end, and the multiple between the typical and most productive developers corresponds to the fabled 10x programmer.’.
I don’t care what people say about lines of code as a metric of productivity. That’s only used here for illustration.
The skills of the people may not be that important when you are building relatively simple portals with some basic backend functionality. Or mobile apps. But if your business relies on sophisticated software for financial transactions processing, then the technical skills of those who build it make all the difference.

And this is the answer to the unasked question why we in Empirica are hiring only best developers.

We the tech founders tend to forget how important it is to have not only best developers but also the best specialists in the area which we want to market our product. If you are building an algo trading platform, you need quants. If you are building banking omnichannel system, you need bankers. Besides, especially in B2B world, you need someone who will speak to your customers in their language. Otherwise, your sales will suck.
And finally, unless you hire a subcontractor experienced in your industry, your developers will not understand the nuances of your area of finance.

 

3. The product – outsource or build in-house?

If you are seriously considering building a new team in-house, please read the points about performance and quality, and ask yourself the question – ‘Can I hire people who are able to build systems on required performance and stability levels?’. And these auxiliary questions – can you hire developers who really understand multithreading? Are you able to really check their abilities, hire them, and keep them with you? If yes, then you have a chance. If not, better go outsource.
And when deciding on outsourcing – do not outsource just to any IT company hoping they will take care. Find a company that makes systems similar to what you intend to build. Similar not only from a technical side but also from a business side.
Can outsourcing be made remotely without an unnecessary threat to the project? It depends on a few variables, but yes. Firstly, the skills mentioned above are crucial; not the place where people sleep. Secondly, there are many tools to help you make remote work as smooth as local work. Slack, trello, github, daily standups on Skype. Use it. Thirdly, find a team with proven experience in remote agile projects. And finally – the product owner will be the most important position for you to cover internally.

And one remark about a hidden cost of in-house development, inseparably related to the IT industry – staff turnover costs. Depending on the source of research, turnover rates for software developers are estimated at 25% to even 38%. That means that when constructing your in-house team, every fourth or even every third developer will not be with you in a year from now. Finding a good developer – takes months. Teaching a new developer and getting up to speed – another few months. When deciding on outsourcing, you are also outsourcing the cost and stress of staff turnover.

 

4. System’s performance.

For many fintech areas system’s performance is crucial. Not for all, but when it is important, it is really important. If you are building a lending portal, performance isn’t as crucial. Your customers are happy if they get a loan in a few days or weeks, so it doesn’t matter if their application is processed in 2 seconds or in 2 minutes. If you are building an algo trading operations or payments processing service, you measure time in milliseconds at best, but maybe even in nanoseconds. And then systems performance becomes a key input to the product map.
95% of developers don’t know how to program with performance in mind, because 95% of software projects don’t require these skills. Skills of thinking where bytes of memory go, when they will be cleaned up, which structure is more efficient for this kind of operation on this type of object. Or the nightmare of IT students – multithreading. I can count on my hands as to how many people I know who truly understand this topic.

 

5. Stability, quality and level of service.

Finance is all about the trust. And software in fintech usually processes financial transactions in someway.
Technology may change. Access channels may change. You may not have the word ‘bank’ in your company name, but you must have its level of service. No one in the world would allow someone to play with their money. Allowing the risk of technical failure may put you out of business. You don’t want to spare on technology. In the fintech sector there is no room for error.

You don’t achieve quality by putting 3 testers behind each developer. You achieve quality with processes of product development. And that’s what the next point is about.

 

6. The Dev Ops

The core idea behind DevOps is that the team is responsible for all the processes behind the development and continuous integration of the product. And it’s clear that agile processes and good development practices need frequent integrations. Non-functional requirements (stability and performance) need a lot of testing. All of this is an extra burden, requiring frequent builds and a lot of deployments on development and test machines. On top of that there are many functional requirements that need to be fulfilled and once built, kept tested and running.

On many larger projects the team is split into developers, testers, release managers and system administrators working in separate rooms. From a process perspective this is an unnecessary overhead. The good news is that this is more the bank’s way of doing business, rarely the fintech way. This separation of roles creates an artificial border when functionalities are complete from the developers’ point of view and when they are really done – tested, integrated, released, stable, ready for production. By putting all responsibilities in the hands of the project team you can achieve similar reliability and availability, with a faster time to the market. The team also communicates better and can focus its energy on the core business, rather than administration and firefighting.

There is a lot of savings in time and cost in automation. And there are a lot of things that can be automated. Our DevOps processes have matured with our product, and now they are our most precious assets.

 

7. The technology.

The range of technologies applied for fintech software projects can be as wide as for any other industry. What technology makes best fit for the project depends, well, on the project. Some projects are really simple such as mobile or web application without complicated backend logic behind the system. So here technology will not be a challenge. Generally speaking, fintech projects can be some of the most challenging projects in the world. Here technologies applied can be the difference between success and failure. Need to process 10K transaction per second with a mean latency under 1/10th ms. You will need a proven technology, probably need to resign from standard application servers, and write a lot of stuff from scratch, to control the latency on every level of critical path.

Mobile, web, desktop? This is more of a business decision than technical. Some say the desktop is dead. Not in trading. If you sit whole day in front of the computer and you need to refer to more than one monitor, forget the mobile or web. As for your iPhone? This can be used as an additional channel, when you go to a lunch, to briefly check if the situation is under control.

 

8. The Culture.

After all these points up till now, you have a talented team, working as a well-oiled mechanism with agile processes, who know what to do and how to do it. Now you need to keep the spirits high through the next months or years of the project.
And it takes more than a cool office, table tennis, play station or Friday parties to build the right culture. Culture is about shared values. Culture is about a common story. With our fintech products or services we are often going against big institutions. We are often trying to disrupt the way their business used to work. We are small and want to change the world, going to war with the big and the powerful. Doesn’t it look to you like another variation of David and Goliath story? Don’t smile, this is one of the most effective stories. It unifies people and makes them go in the same direction with the strong feeling of purpose, a mission. This is something many startups in other non fintech branches can’t offer. If you are building the 10th online grocery store in your city, what can you tell your people about the mission?

 

Final words

Fintech software projects are usually technologically challenging. But that is just a risk that needs to be properly addressed with the right people and processes or with the right outsourcing partner. You shouldn’t outsource the responsibility of taking care of your customers or finding the right market fit for your product. But technology is something you can usually outsource and even expect significant added value after finding the right technology partner.
At Empirica we have taken part in many challenging fintech projects, so learn our lessons, learn from others, learn your own and share it. This cycle of learning, doing and sharing will help the fintech community build great systems that change the rules of the game in the financial world!

 

 

HFT – the good, the bad and the ugly

High Frequency Trading, known also as HFT, is a technology of market strategies execution. HFT is defined by technically simple and time costless algorithms that run on appropriate software optimized for data structures, level of memory usage and processor use, as well as suitable hardware, co-location and ultra low-latency data feeds.

 

Although HFT exists on the market for over 20 years, it has became one of the hottest topic during past few years. It is caused by several factors, such as May 6, 2010, “Flash crash”, latest poor situation on the market and Michael Lewis book – “Flash Boys”. Let’s look where all that fuss comes from.

 

The Bad

 

Among other things, the advantage over other market participants and ability to detect market inefficiencies is the reason why so many people critics HFT so much. Most common charges put on the table are:

 

  • Front Running – HFT companies use early access to incoming quotes to buy shares before other investors and then turn around and sell him just bought shares with slightly bigger price.
  • Quote Stuffing – Way of market manipulation by quick sending and withdrawing large number of orders. Because of speed of operations, it creates a false impression of the situation on the market that leads other participants to executing against phantom orders. Then there is nothing else to do, but to exploit favorable prices by HFT investors.
  • Spoofing – Another method for market manipulation by placing orders and then cancelling them for price increase/decrease. It is based on placing big order on the market to bait other investors, and when the market starts to react, quickly cancel it. Then new price allows to gain some profit by HFT investor.

 

But that’s just a tip of the iceberg. It can be often heard that there is lack of proper HFT regulations, exist false belief that there are Dark Pools without any regulations where HFT companies can hide their activity, and there is still active argument if HFT brings liquidity to the market or just useless volume.

 

The Ugly?

 

Bill Laswell once said “People are afraid of things they don’t understand. They don’t know how to relate. It threatens their security, their existence, their career, image.” That phrase perfectly fits to what is happening now on High Frequency Trading topic. When people would like to take a closer look on how exchanges work, probably, they would be less sceptic to High Frequency Trading.

 

Thus, on most, maybe even on all, exchanges exist two mechanism which can efficiently handle problem of quote stuffing and spoofing. First of them is limitation of number of messages per second that can be send from one client. For example on New York Stock Exchange there is a limit of 1000 messages/sec, so it means that if HFT company burst whole 1000 of messages in first half of the period, in second half it cannot send any message, so it’s cut out of the market. Other limitation used by exchanges is a limit of messages per trade. It hits even harder in quote stuffing and spoofing. In most of the cases limit is around 500 messages per trade and if someone exceed it then he should be prepared for fines. On top of it company that frequently break limits could be banned from exchange for some time.

 

If we talk about front running, first thing we have to know is a fact that front running, in the dictionary meaning, is illegal action, and there are big fines for caught market participants who use it. Front running is using informations about new orders before they will go to the order book. Let’s say Broker gets new order with price limit to process, but before putting it to exchange, he will buy all available shares at better price than limit and then he execute client’s new order at limit getting extra profit. That’s highly not allowed and that’s not what HFT companies do.

 

All they do is tracking data feed, analyzing quotes, trades, statistics and basing on that information they try to predict what is going to happen in next seconds. Of course, they have advantage due to latency on data feed and so on, because of co-location, better connection and algorithms, but it’s still fair.

Hft-scalping-for-large-orders.svg

(source: Wikipedia)

 

HFT companies have to play on the same rules as other market participants, so they don’t have any special permits letting them do things not allowed for others. Same with Dark Pools, specially that they are regularly controlled by Finance Regulators.

 

The Good

 

First, we have to know that suppliers of liquidity, i.e. Market Makers and some investors use HFT. They place orders on both sides of the book, and all the time are exposed to sudden market movement against them. The sooner such investors will be able to respond to changes in the market, the more he will be willing to place orders and will accept the narrower spreads. For market makers the greatest threat is the inability to quickly respond to the changing market situation and the fact that someone else could realize their late orders.

 

System performance in this case is a risk management tool. Investments in the infrastructure, both a software and hardware (including co-location), are able to improve their situation in terms of risk profile. The increase in speed is then long-term positive qualitative impact on the entire market, because it leads to narrowing of the spread between bids and offers – that is, reduce the transaction costs for other market participants, and increase of the liquidity of the instruments.

 

HFT AND MARKET QUALITY

 

In April of 2012. IIROC (Investment Industry Regulatory Organization of Canada), the Canadian regulatory body, has changed fee structure based so far only on the volume of transactions, adding the tariffs and fees that also take into account the number of sent messages (new orders, modifications and cancellations). In result, introducing new fees made trading in the high frequencies more difficult. It was very clearly illustrated by data from the Canadian market.

 

Directly in the following months these fees caused a decrease in the number of messages sent by market participants by 30% and hit, as you might guess, precisely the institutions that use high-frequency trading, including market makers. The consequence for the whole market was increase in the average bid-ask spread by 9%.

NO PLACE FOR MISTAKES

 

When people talk about HFT, both enthusiast and critics, it is not rare to hear that HFT is risk free. Well, on the face of it, after analyzing how HFT works you would possibly agree with it, but there is a dangerous side of HFT that can be not so obvious and people often forgot about it. HFT algorithms works great if the code is well written, but what would happen if someone would run wrong, badly tested or incompatible code on a real market?

 

We don’t have to guess it, because it happened once and it failed spectacularly, it was a “Knightmare”. Week before unfortunate 1st of August Knight Capital started to upload new version of its proprietary software to eight of their servers. However Knight’s technicians didn’t copy the new code to one of eight servers. When the market started at 9:30 AM and all 8 server was run, the horror has begun. Old incompatible code messed up with the new one and Knight Capital initiated to lose over $170,000 every second.

(source: nanex.net)

It was going for 45 minutes before someone managed to turn off the system. For this period Knight Capital lost around $460 million and became bankrupt. That was valuable lesson for all market participants that there is no place for mistakes in HFT ecosystem, because even you can gain a lot of money fast, you can lose more even faster.

 

SUMMARY

 

HFT is a natural result of the evolution of financial markets and the development of technology. Companies that invest their own money in technology in order to take advantage of market inefficiencies deserve to profit like any other market participant.

 

HFT is not as black as is painted.

 

Aldridge, Irene (2013), High-Frequency Trading: A Practical Guide to Algorithmic Strategies and Trading Systems, 2nd edition, Wiley,

 

TWAP Strategy

Time-Weighted Average Price (TWAP) is another trading algorithm based on weighted average price and in compare to Volume-Weighted Average Price its calculations are even simplier. Also it’s one of the first execution algorithms and unlike most algorithms nowadays it’s passive execution algorithm that waits for proper market price to come, doesn’t chase it.

 

Calculations

 

As TWAP doesn’t bother about volume it’s extremely simple to obtain it. All it takes is to get Typical Price for every period bar using equation below and then calculate average of Typical Prices.

 

Typical Price = (Close+High+Low+Open)/4

 

Let’s just take a look at example results calculated on 1-minute interval intraday Morgan Stanley’s stock.

 

Time Close High Low Open Typical Price TWAP
09:30:00 38.90 38.96 38.90 38.96 38.93 38.930
09:31:00 38.94 38.97 38.86 38.92 38.92 38.926
09:32:00 38.91 38.96 38.91 38.94 38.93 38.928
09:33:00 38.89 38.94 38.88 38.92 38.91 38.922
09:34:00 38.90 38.94 38.90 38.90 38.91 38.920
09:35:00 38.97 38.97 38.90 38.90 38.93 38.922
09:36:00 38.92 38.96 38.92 38.96 38.94 38.925
09:37:00 38.90 38.93 38.86 38.93 38.91 38.922
09:38:00 38.90 38.92 38.89 38.89 38.90 38.920
09:39:00 38.92 38.92 38.88 38.91 38.91 38.918
09:40:00 38.90 38.92 38.88 38.91 38.90 38.917
09:41:00 38.84 38.89 38.82 38.89 38.86 38.912
09:42:00 38.87 38.87 38.84 38.84 38.86 38.908
09:43:00 38.85 38.89 38.84 38.89 38.87 38.905
09:44:00 38.81 38.85 38.80 38.85 38.83 38.900
09:45:00 38.69 38.80 38.67 38.80 38.74 38.890

 

Strategy

 

The most common use of TWAP is for distributing big orders throughout the trading day. For example let’s say you want to buy 100,000 shares of Morgan Stanley. Putting one such a big order would vastly impact the market and the price most likely would start to raise. To prevent that, investor can define time period in TWAP Strategy over which they want to buy shares. It will slice evenly big order into smaller ones and execute them over defined period.

 

TWAP could be used as alternative to VWAP, but because of itssimplicity we have to remember about some pitfalls. Even if we slice big orders, we do it evenly, thus there is a possibility to hit on low liquidity period when our splitted order will impact the market hard. That’s why it’s recommended to use TWAP over short periods or on stocks that are believed to not have any volume profile to follow.

 

Be random

 

There is also another threat coming directly from dividing big order evenly, namely, other traders or predatory algorithms. Obviously trading in such a predictable way can lead to situation where other traders or algorithms would look through our strategy and start to “game” us.

 

Barry Johnson in his book suggests adding some randomness to the strategy as a solution to the issue. He says that “We can use the linear nature of the target completion profile to adopt a more flexible trading approach. At any given time, we can determine the target quantity the order should have achieve just by looking up the corresponding value on the completion rate chart.”

 

In practice it means that when we have run 4-hour TWAP we don’t slice the order into evenly parts, but otherwise we focus on percentage completion. So for instance we would want to have 25% of the strategy completed by first hour, 50% by second and 75% by third. That gives a more freedom into size of orders, so we can be more random with it and hence less predictable for other traders on the market.

 

TWAP vs VWAP

 

As both indicators use same mechanism, i.e. weighted average price, it’s common to compare them. Despite that VWAP’s nature is more complex and includes volume in its calculations, on  instruments with low turnover TWAP and VWAP values can be close. On the other hand when a session starts to be more volatile both indicators will diverge.

 

 

On a table below there are TWAP and VWAP calculated for whole trading day. As we can see at the beginning of the trading day the difference is less than a cent, but on close the difference raised up to 2 cents. It happened because during the day there were some small volume trades for lower price that didn’t affected VWAP, but did TWAP.

 

Time Close High Low Open TWAP VWAP
09:44:00 38.81 38.85 38.80 38.85 38.900 38.904
09:45:00 38.69 38.80 38.67 38.80 38.890 38.887
15:57:00 38.70 38.70 38.68 38.69 38.666 38.686
15:58:00 38.71 38.72 38.68 38.70 38.666 38.686

 

Summary

 

TWAP Strategy is another great tool for executing big orders without impacting the market too hard. Like everything it has its own pros and cons and it’s up to us to select if TWAP will be the best strategy to use for our case or maybe we should consider using VWAP or other strategy.

 

References

  1. H. Kent Baker, Greg Filbeck. “Portfolio Theory of Management” (2013) , pp.421
  2. Barry Johnson “Algorithmic & Trading DMA – An introduction to direct access trading strategies” (2010), pp. 123-126