Check open positions by lot

[jonfan45]

I would like to know if we can check positions by lot in API.

Account.Positions API is only keeping track of the overall position instead of lots.
Although I am trading the same instrument, my strategy has different reasons for entering each lot and I want to be able to tailor my exit strategy based on lot.

Currently I am doing my bookkeeping. I use specific signalName on EnterLong and I am using a Dict to keep track of the lots and to drive individual exit strategy. However, those data structures do not survive crashes. It would be great that it is being tracked on the Account side so even if the program restarts, it can pick up from where it left off.

Thanks,
Jonathan

[NinjaTrader_Jim]

Hello Jonathan,

Thanks for your post.

Account.Positions will reflect all open positions in the account. You can loop through this collection of positions to check each each individual Position, and you can check that Position's Quantity property to check the quantity of that active position. An example snippet that loops through the Account.Positions collection can be found in the Account.Positions documentation.

Account.Positions - https://ninjatrader.com/support/help...ns_account.htm

The Strategy Position can be checked with the Position object (strategy positions are separate from actual account positions, please see below for more details.)

Strategy vs. Account Position - https://ninjatrader.com/support/help..._account_p.htm

Position - https://ninjatrader.com/support/help...8/position.htm

If you want to have the strategy pick up where it left off after a restart, I suggest using ImmediatelySubmit for your start behavior.

When a strategy is enabled, it processes historical data to determine trades that the strategy would have made on the data that is already on the PC/chart and to determine what position the strategy is in. (Strategy positions are separate from actual Account positions.)

Immediately Submit automatically submits working orders from when the strategy processed historical data, and assumes the strategy position and account position are where you want it when you enable the strategy. This is typically used to have a strategy resume a position after disabling/enabling. If the strategy already had live orders running, the orders will resume with the new enablement of the strategy if they match the historically calculated orders. If the orders calculated from historical data do not match the live working orders, the live working orders will be cancelled and replaced by those calculated from historical data.

Start Behaviors — https://ninjatrader.com/support/help..._positions.htm

We look forward to assisting.

[jonfan45]

Thanks Jim for the information.

1) On the issue of Account vs Strategy Positions, it appears that Strategy Position is what I wanted.

My followup question is where can I access that information. Here is one concrete scenario: In the sim101 account, I have 4 different EnterLong(signalName) at different times. I would expect Positions containing 4 separate lots. However, when I debug the variable in VSStudio, there is only 1 position with 4x the quantity. Can you please shred some light on this?

2) On the topic of disaster recovery, I read the link you sent me to learn more about the immediatelySubmit hook. My intention was less on enforcing Account positions to be like Strategy positions in case of mismatch, but more on making sure that I know the actual state of the account positions and do some exit or damage control as much as possible. Most likely I will try to use your suggestions to exit all the positions until the strategy runs to a steady state before making any new entries.

[NinjaTrader_Jim]

Hello Jonathan,

A position will reflect being Long/Short on an account/instrument (or for that specific strategy.) With four separate entries, we would have still have 1 position as each entry would affect this single position.

With the Managed Approach, we can tie entries and exits together using Signal Names, but we would still be modifying one position instead of creating new positions.

ImmediatelySubmit is used particularly to have a strategy resume if it has been disabled. There is not any "damage control" done here, as the start behavior assumes the strategy has been the only thing modifying the account.

You could consider checking the strategy Position and the account position (PositionAccount) when the strategy reaches State.Realtime in OnStateChange, and then set some variables to put the strategy in a "panic" mode where the user can be notified that the strategy and account are out of sync and to prevent further actions by the strategy logic. Draw.TextFixed could be used to inform the user of an issue.

Draw.TextFixed - https://ninjatrader.com/support/help..._textfixed.htm

We look forward to assisting.

[jonfan45]

Thanks Jim for the explanation.

Currently, we leverage bookkeeping on entries and exits using signalNames, and decide on signalName specific exit strategy.
Do signalNames for entries and exits survive get stored somewhere and survive through a restart? For example, if we have a signalName entry called "Long Breakout", and another called "Long Volatile",
upon restart,
1) Can those signalName based entries be retrieved from APIs?
2) If it is not available, let's say we persist the signalName ourselves, would ExitLong ("Long Breakout") be recognized and exit only the portion by that signal?

Thanks for the suggestion on ImmediatelySubmit and the visual clue. I will give that a try.

Best,
Jonathan

[NinjaTrader_Jim]

Hello Jonathan,

If we use ImmediatelySubmit and restart the strategy, the strategy processes historical data to see what trades it would have made, which generates the strategy position and what orders should be attempted to be resumed by the strategy.

Those entries/exits would be tied together via signal names. If you have two separate entries using "Long Breakout" and "Long Volatile" for the Enter methods' signal name and the Exit methods' FromEntrySignal name, we can expect the Exit method using "Long Breakout" for the FromEntrySignal name to remain tied to the "Long Breakout" Entry, and we can expect the Exit method using "Long Volatile" for the FromEntrySignal name to remain tied to the "Long Volatile" Entry.

Calling ExitLong("Long Breakout"); will only close out the quantity of a position opened by an Enter method using "Long Breakout" as the Entry signal name. For example, if we entered long for 2 contracts with "Long Breakout" and 1 contract with "Long Volatile" then we would be back to 1L after calling ExitLong("Long Breakout");

Please let us know if you have any additional questions.

[jonfan45]

Thanks Jim for the information.

I am having a much clearer pictures now. Positions is a notion on the client side, The whole history and the positions is rebuilt upon restart to bring it in sync with where it left off.

One follow on question to that: We are trading by minute / Tick. There is a good chance when the system restarts the application, it could be a few minutes away. For instance

• we have a crash at 12:00 and at that point, we are holding 2 long positions.
• NJ is started again at 12:05. With immediatelySubmit, our strategy would have sold both positions between 12:00 to 12:05. Is my understanding correct that immediatelySubmit will attempt to reconcile the positions between the current position (2 long) vs expected positions based on historical data (0 position)?

Thanks,
Jonathan

[NinjaTrader_Jim]

Hello Jonathan,

ImmediatelySubmit assumes that the strategy position and account position are in sync. The strategy will resume what was calculated from historical data, and if the account and strategy are out of sync, the strategy will not try to reconcile the position.

ImmediatelySubmit + Synchronize Account will submit an additional order to close/open an account position to sync it with the calculated strategy position. This could be an option in that particular case.

Alternatively, there is the AdoptAccountPosition start behavior where the strategy inherits the account position. This requires additional programming and may be best to ignore historical processing when using it. I have attached an example that uses this if you would like to investigate that functionality further.

We look forward to assisting.

[jonfan45]

Thanks so much Jim!