Trading engine built on the API

API Developers
1

I have spent the past couple months learning about and building on the API, and I would like to share what I built so far:

tradehur_thumbnail_v1
Introducing Trade Hur

Thank you to everyone on this forum for all your help, I would be very interested to hear what you think!

1 Like
2

Professional Video… Check
Promoting how easy it is to make and an algo and make money… check

It is completely unbelievable that you’re “new to this” and “not even a developer” and “this is actually the first program I’ve written on my own”… with a completed strategy… against the API… (which isn’t simple or bug free)… and also have an algo that’s profitable.

So. I guess good job for making good money promoting Tradovate and NinjaTrader.

3

@Arthur this is really incredible work! Glad to see you’re having success already. At this rate, you’re sure to become a huge inspiration to the API Developers’ community.

P.S. I really like the note mapping feature - that’s a really interesting way to judge what’s happening without having to watch directly.

1 Like
4

Have you tried this in a live environment yet maybe on the Micros? MES or MNQ.

5

I understand where you’re coming from, but let’s walk through the logic for a moment.

If Tradovate and NinjaTrader were paying me to promote them, how much do you think they would pay me? Would it be more than the $40K the engine did when I screen recorded it that day?

Here’s how it performed this past week. Would they have paid me more than $167K?

2022-0222-0225
2022-0222-02251866×2739 333 KB

Bottom line is I put a lot of time and effort into building my engine and if it can perform as well in a live environment as it does in demo mode, then it will be worth much more than anyone can pay me to make a video for them.

1 Like
6

Thanks Alexander, it was really just building on top of the boilerplate examples you set up in the tutorials.

I thought the tonify function would be a lot harder to implement, but it was surprisingly fast to get up and running, and the methodology behind it ended up being one of the foundations for my strategy!

7

I have not run it in a live environment yet. I am still working out some edge cases, but when it is ready, I do plan on running it on the micros.

8

You haven’t run anything live yet. Your profits aren’t real.

You have not said you’ve backtested anything so we have no basis to ask you questions about how your algo performed historically across many different types of market environments.

I hope you’re a savant and have somehow just skipped the normal due diligence most of us mere mortals must go through. and I hope you’re wildly successful. I really do.

However, most of us would need to backtest hundreds or thousands of ideas before arriving at one which might work… when trading in the most efficient and heavily algo traded market in the world. (emini futures).

You’ve skipped the long arduous task that banks spend countless dollars on each year in research and development. You’ve written an algo without the help of a programmer, which hasn’t been been backtested, and which you haven’t explained many metrics on… which, is allegedly, wildly profitable on an undisclosed capital base.

With an average hold time of 3-4 seconds…which means you’re scalping in an extremely small time frames…which is exceptionally difficult for most.

Please come back in a few months and show us your verified profit.

1 Like
9

I like the video; i’m looking forward to updates. If you continue down this path I would definitely propose 3 things that I did not see in the video. (or add it to the PR if you have already tackled them :slight_smile:)

1 building a backtesting component. There are different ways to accomplish this however I would propose writing a job that leverages market replay to download many sessions of market data quotes to a database that could then be backtested against many times faster than the 400% replay cap.

2 Really spend a lot of time on the backbone of such engine; error handling, retries, exceptions, state management (to pick back up after the prior, especially if a failure occurs while in an active trade), alerting (sms alerts on issues etc). I would estimate this to be around 50% of the overall development effort of a production trading engine and maybe you’ve already taken some of these steps but they were not discussed in the video. I do understand that overhauling the websocket implementation in the sample code is no novice effort but it is great learning on websockets!

3 Consider looking for larger timeframe strategies that yield a higher point/trade ratio. While some strategies may look wildly successful with the appropriate amount of leverage using mini’s the reality is most will start live trading using micro’s where contract fees play a larger role. The round trip on a micro is around $1.22 so using your screenshot as an example 12.8k trades would have totaled 15.6k in fees for a gross profit of 20.2k. Not to say that 4.6k in a week on a single micro isn’t wildly successful but slippage in a live environment could quickly eat away at the potential profitability of such strategy with so many trades; eg. quarter point of slippage per micro ($.50) on 13k trades would turn this strategy red. TLDR is if you plan to start with micro’s, sim with micros too.

Super impressive video! Pleased to check back in to see what progress has been made.

2 Likes
10

There are so many red flags in this video that make it unbelievable. Kind of surprised others keep taking it seriously.

Regardless… wogann
Wow. I didn’t realize option 1 (tick data available via replay) even existed. Hugely awesome idea I’m going to probably implement.
thank you!

11

NP, that’s what I do personally. You can control replay via the API with /initializeClock and then just have your job loop through the days you want to gather until you have the amount of historical data you want. The main throttle is the 400% speed limitation. It still took my cron job nearly 2 months to pull 200 days of tick data but the backtesting value pays itself back 100 fold.

1 Like
12

Very good. We should talk offline. I mainly code in TradingView and connect to Tradovate, but TradingView does not have autotrading capability. So I needed to code the algo’s in NinjaTrader. Which I don’t like. Would definitely like to work with you on a project that I already have running in Ninja and see it we can get it going for Tradovate.

13

Hi @wogann,

Thanks for the feedback.

  1. I would like to build a backtesting component at some point, but I’m still focused on making sure the engine works the way I want in real-time. While it does account for slippage, I can’t guarantee what the fills would be like against a database. I do like your approach though, and it’s on the list!

  2. I didn’t get to mention anything in the video about how the engine maintains itself. It is an ongoing process, of course, but here are just a couple highlights for anyone interested:

    • Time penalty:
      All repetitive requests go through a recursive function that resubmits itself with an appended p-ticket value that locks all other requests until the p-time has been met.

    • 401 (access token renewal):
      The renewal procedure happens 1 minute prior to whatever expiration is issued (also recursive), which generally starts at 80 minutes. It also listens for any close frames from the webSocket.

    • 429:
      I’m still monitoring the exact conditions for when this happens, but as far as I can tell, the server responds with a 429 if p-time exceeds 6 seconds or if there are more than 5000 requests in an hour. The engine currently has circuit breakers to liquidate before this happens, because once the 429 comes, you cannot exit open positions programmatically. I haven’t run into a 429 in a while after improving the efficiency of other aspects of the engine, but I do continue to monitor the request rate regularly.

    • Auto-liquidation and trailing max drawdown:
      This was one of the first features I implemented. It liquidates and stops the engine when either a percentage or hard figure is breached. Note that the values are calculated off of the maximum net liquidating value which, depending on how profitable you were previously, could make sure the engine shuts down while you are still profitable.

    • Countdown to open/close:
      There was a brief mention of the countdownToClose feature in the video that liquidates at the close, but there is also a countdownToOpen feature that starts the strategy right at the open if activated within 30 minutes of market opening. This also factors into whether isAutomated is switched on or not.

    • Condition count:
      For anyone familiar with card counting in blackjack, a running count lets you know how favorable the conditions are for the player versus the dealer. The engine keeps a count and ratio that signals when conditions are good to either go live or scale up.

    • Efficiency, errors and auditing:
      Some of the features that took the longest to implement were just error handling. Sometimes the server gives you a mysterious fill. Other times it doesn’t pick up commands you sent. There are error checks and audits that occur for every type of event, along with responding actions. The most important feature though, is making sure every command is sent efficiently and that the engine is lean and non-redundant. I could probably write a separate (and even longer) post about just this.

  3. Yes, this engine is only meant to trade short-term. It is not a swing-trading engine, nor is it a market-making engine. It assumes Brownian motion and only does well during periods of high gamma and range expansion. It does, however, take in a hard constant that can be tweaked, which would definitely affect how aggressively it trades.

    The best hedge for this, and for longer-term trades, would be to take on short option positions that benefit from rangebound markets, positive theta and diminishing volatility.

    And of course, for the longest-term trades, you should just get long, because eventually positive drift will catch up after any wipeouts to the market. Doesn’t help much when you’re leveraged with futures, though.

Hope this was helpful for anyone following along, and bravo to you if you made it this far.

14

Feel free to send a DM anytime.

15

Still maintaining that you have no development experience?

16

I now have experience developing one app on my own :wink:

1 Like
17

I have a strategy on Tradingview, if there is anyone who can code it for me directly on Tradovate API to create auto trader, I will be grateful may be willing to pay for your time. Once again strategy is already designed and coded on Tradingview, I am satisfied with backtest results. All I need is to have it run on Tradovate. I hate that Tradovate makes it like a f… mystery, why is it so hard to launch auto trader?! Anyone upto a task? It is a simple not terribly complicated code. Please contact me before I gave up and left this stupid broker for MT5 or Optimus or… who make it easier to create and turn on auto traders.

By the way whatever Arthur created, surely is impressive, but for me way too complicated. As to results my code generates about over $8000 every 7-10 days trading 1 ES contract on 1 Min chart, 70-80% profitable trades with 6-8 profit factor. I also have a strategy for 15 min chart, which generates even better results, but it is larger time frame and is not for impatient traders…

1 Like
19

hello ,I have experience in tradovate api auto trade, I use java and websocket API ,and get the footprint data by tick market data,but I have no a Effective trading strategy，and stock by the CME （see I am not able to get Symbol Data - #74 by margolinm ）,may be we can together work . my email:zhangdc007@qq.com

20

I first came across this on your youtube channel over a year ago. I would love to see the code logic behind it - is it on github, please?