A classic way of trading would normally look like finding your industry (or asset) focus, watching the market, analyzing, entering deals of various kinds and exiting at the right time, taking profits.
Why going custom
My development activity is addressing certain underlying limitations of manual trading. Some of these limitations are rooted in human nature, like
- you can’t watch thousands of insturments at the same time
- the interpretation of situations takes longer for a human than for a computer
- interacting with the UI of any trading system (finding a button, or adjusting a spinner input field takes considerably longer time for a human than to a computer with a well-defined trading logic.
To give a real-life example of the above, let’s say you’re watching a chart – EUR/USD, for the sake of concreteness. Even if you are prepared to react a trend brought about by a press release of FED, you’ll need to perceive, analyze, decide, parametrize and confirm a final trade order to react. To humans, all this will take seconds at least. A computer will do this a lot faster – and that speed difference decides whether or not you can catch the wave.
Envisaging the ideal trading solution, I had set the following main requirements (further detailed in the architecture chapter):
Distributed system: components are running on diverse computers. This design enables confidential data be kept on-premise, while utilizing more cost-effective solutions for non-privacy-critical components. By this, one also has the flexibility to move certain latency-sensitive parts closer to the ‘fire’.
Stable application server platform: for the sake of stability, I chose Java Enterprise Environment. This implementation is quite portable and is sort of an industry-standard in (investment) banking.
Unlimited provider compatibility: one thing to note is that brokerages employ various standards for data exchange. Despite some well-established standards (like fix), you might easily find yourself in the situation of having to write a fully custom protocol to receive streaming prices.
Mobile client: for the sake of process-portability and ergonomy, I also built a special mobile client. The platform – in this case – is Android. I could have chosen Apple as well but to keep the number of programming languages applied low, Android is the right choice.
The above components are further detailed in the next chapter.