When you are building your strategies for algo trading, you may need to backtest your strategies at some point to know if your algorithm works exactly the way you have planned. When you need to optimize the strategy you'll need to backtest it against some data and tweak your parameters based on your backtest results.
Playground is where your backtestings take place. A playground provide all the utilities you need for you to run those tests. To build a playground, You need to consider these four features.
Fake money: Perhaps, this is the most important feature of a playground. You don't use real money in it, else you're may lose your life savings if your strategies are losing. You'll need to code a fake bank or a fake crpyto wallet. At the easiest form, the fake money can reside inside a float variable in your program.
Trade processor: This is the guy that recieves request, process them, and sends back results or feedbacks. This is the heart of the Playground. it handles all the post orders, market orders, stop-limit orders, and stores the state of the market. This is where most of the coding hardwork goes into. At the easiest form you can use the trade processor of your broker or exchange (Assuming they provide their own playground, and you are building yours). But often times, the trade processor that your broker has, only works with real money, so you'll need to build yours or, if you can get it, use third party trade processor for that market.
API access: API means Application Programming Interface. It provides means of communication between independent programs or applications. The trade processor is the back end, while the API is the front end that allows you to access the trade processor. The backtester communicates with the trade processor using this means. There's always a restful API access to your trade processor, and you can write a API wrapper for it in any programming language. You can get third party API wrappers on GitHub, but if you built the trade processor yourself, you would have likely created the API access on the fly. But then, you may wish to model the API access in another way, not necessarily the broker's API model. As a feature, you can write a single API that unifies all different trading market. so if you want to add a new trading market you only need to write a trade processor for it.
Data: Finally, data. how does your trading processor obtain market data? Traditionally and the easiest approach is to use historical market data you have gathered yourself or you got from third parties. Another approach is to use live market data as trades happen. Using live data can have an advantage over historical data as you get what's currently happening, so you won't optimize your strategies to overfit an historical trading condition. The last approach to the generate your own data yourself, while this may not be advised but it comes in handy in many situations. With data generation, you can create the market conditions youself and watch how your your algorithm behaves. For example, create a market data that'll guarantee constant loss,then try to make your strategy strong enough to hedge the losses or even make profit from it. when you use such strategy in live market, you'll be guaranteed that it will never suffer huge losses even in the rarest cases.
That wraps up the steps to creating a playground. With an offline data(plus a data generator) and an offline trade processor, you can start experimenting on all the approach proposed on scientific journals without connecting to the internet or a broker.
Submitted October 02, 2020 at 11:30AM by kompleksanda