Limit symbol entries across strategies

[stevenev]

Say I have multiple strategies, all acting on the same symbol. How would I restrict number of entries for that symbol globally. This is done so that we don't over-trade and create a bias towards one symbol.

I know there is EntriesPerDirection but I don't know how that works across strategies.

[NinjaTrader_Jesse]

Hello,

Thank you for the question.

If these are all running on the same account, In general there would not be a way to restrict based on the accounts current entries from multiple strategies. This is because each strategy has its own virtual position so in the case that strategy A places a long trade and becomes long, Strategy B would not know of this occurring.

The suggested correction for this would be to not use more than 1 strategy per instrument/account, likely you would need to consolidate the strategies into a single script that executes all of that logic so all of that logic is aware of the same position information.

There are undocumented ways to access the account in which you may be able to pull the accounts actual position information but because this way is not documented there would be no guideline on how or if this would work correctly. http://ninjatrader.com/support/forum...78&postcount=2

I look forward to being of further assistance.

[stevenev]

Thanks, Jesse, that works.

[bltdavid]

If you're up for some coding you can always create a lock file.

If the lock file exists, this means that another strategy is trading that instrument for that account and thus you're currently locked out.

If the lock file does not exist, then create it, and then enter the trade. This will create the lock file that other strategies will see, telling the others they are locked out.

My strategies use a well known filename for the lock file, for ex,

C:\Users\<name>\Documents\NinjaTrader 7\tmp\NTBrk-CL-02-16.lock

the important pieces in the filename are the A) account name and B) instrument name.

I use a well known name (aka, I invent nicknames, like NTBrk, NtBrk1, NTBrk2, etc) for the account name.

The point is: when a strategy wants to trade an instrument, it must acquire the lock before it can enter the trade. When the trade is exited, it releases the lock.

[stevenev]

Thanks, bltdavid

That is a great solution, and testament to the extended power that c# provides for Ninja.

I think one could also use mysql. I have seen code for that on the forum, so both solutions work. Guess just have to make sure locks are properly removed when the position is closed.

[bltdavid]

Guess just have to make sure locks are properly removed when the position is closed.

Yep, and that's very easy to do with OnPositionUpdate.

May I suggest you figure out in your code how to make OnPositionUpdate be the gatekeeper for calling three methods that you invent:

  OnPositionExit
  OnPositionEntry
  OnPositionChange

then the call to ReleaseTradeLock is placed in OnPositionExit.

[stevenev]

Thanks, bltdavid. Great advice.

[bltdavid]

I think one could also use mysql.

Yes, absolutely.

I wanted to elaborate ...

The trade lock file solution I employ does not provide control over, say, the total number of contracts that are tradable for an instrument at any one time.

What I mean is, my lock file approach is an all or nothing type of lock.

A more elaborate solution (implemented with the benefit of a database, such as MySQL) could keep track of maximum contracts tradeable, and the lock method becomes more a "reservation" system.

Let's say your strategy would like to go long for 3 contracts -- something first primes the database to know that, say, 10 contracts is the maximum -- then the strategy submits a "reservation request" for "3 long", which is granted if

1. The database has no reservations for that instrument, or,
2. The current reservation is already "long" and at least 3 contracts are available to be reserved.

If this is the first reservation, then #1 applies, and the database count of "reservations in use" is set to 3.

If another strategy wants to go long for 5 contracts for the same instrument, then the database grants this request, and increments the "in use" count of that instrument to 8.

If a third strategy wants to go long for 5 contracts, the database denies that request due to only 2 contracts being available.

If a 4th strategy wants to go short 2, this is denied because the current reservation direction is long.

Strategy #1 exits and vacates its reservation on its 3 contracts -- the database is updated via OnPositionExit and the "in use" count is decremented by 3.

Strategy #3 exits and vacates its reservation on its 5 contracts -- the database is updated via OnPositionExit and the "in use" count is decremented by 5.

Hopefully the finer grained logic with the "reservation" system, which MySQL could greatly assist with, is clear.

Once all reservations are vacated (aka, the "in use" counter for that instrument is zero) then the next reservation, long or short, means all contracts are available for the next trade. As you can see, if only a portion of the 10 available is reserved by the next trade, the leftover is available for a future reservation *but only in the same direction* as the "primary" reservation.

The point of a reservation system is to allow multiple strategies (esp those that employ different algorithms) to rely upon the database to confirm/deny their order entry requests. The overall account size could be programmed into the database such that the database issues its own type of "order denied" (aka, a local version of the 'order rejected' error that the broker would issue) when the order "long 3" is reserved.

Perhaps you see the potential of such logic.

[stevenev]

Yes, absolutely. This would be an incredibly powerful portfolio management system. I think it is something the community can work on to develop. I am not quite there yet, but once I am a bit more advanced, I am happy to contribute to it.

The good thing with mysql is one can use phpmyadmin, so can see everything in a nice tabular format, and do in-line edits/deletes of the entries for manual maintenance.