Performance Object and Atm Strategies

[whitmark]

I routinely get requests for assistance by discretionary traders who have been turned on to the utility and full functionality of Atm strategies including intrabar position management but are looking to automate their entries by using NinjaScript. They realize the limitations of backtesting for their type of strategy and choose to forward test their strategies using Market Replay or in realtime using a sim account so there is no need for historical processing. They also want the flexibility to modify the Atm settings independantly from the strategy parameter settings.

Using the Performance object is useful to monitor overall trade performance of a strategy, in particular for halting trading in the event a maximum profit or loss is triggered. This works well for orders submitted directly from Ninja Script but it does not track performance of Atm strategy positions that are created by a NinjaScript strategy. Sure, there are the following methods to track individual Atm performance:

• GetAtmStrategyUnrealizedProfitLoss(string AtmStrategyId)
• GetAtmStrategyRealizedProfitLoss(string AtmStrategyId)

but no overall method or metric to query to get the total sum of all Atm positions. For strategies that use multiple Atm strategies to scale into a position, this can be arduous task of keeping track of multiple AtmStrategyIds and their market position if you simply want to know the overall PnL at any given time for the NinjaScript strategy. As an alternative, it would be useful to be able to directly query the PnL of an account regardless if the orders where submitted as Atm or non-Atm orders. For example, it would be most useful if the ATI function RealizedPnL(string Account) that is available to external platforms and works for Atm and non-Atm orders could be made available as a GetRealizedPnl() for execution from within NinjaScript.

Given the continued strong interest in bringing Atm functinality within NinjaScript despite the availablility of more advanced approaches, it would be most useful to have the overall PnL tracking capability for Atm orders be at parity with those methods already available for ATI orders and Ninja Script non-Atm orders.

Comments (including alternative workarounds) by Ninja Support or other users are most welcome. Thanks for listening.

Whitmark

[NinjaTrader_Josh]

As always, thanks for the suggestion whitmark. I will think about potential workarounds after I get packed and move back to school. Winter break is over .

[whitmark]

Thanks Josh,

I'll be the first to admit that I have been spoiled by the use of the following ATI commands that make it easy to query Account Market Position, Realized PnL, and other values that are not yet available when using Atms within a NinjaScript Strategy.

MarketPosition(string account)
RealizedPnL(string account)
BuyingPower(string account)
CashValue(string account)

If you are coming from another platform where you took advantage of the ATI to offload intrabar position management by using an Atm strategy, and you now want to bring that processing entirely into NinjaScript, its important to realize that these account access methods are not supported. Of course, NinjaScript strategies that place non-Atm orders have similiar information available on an overall strategy vs account basis (e.g., Position & Performance Objects) but NinjaScript strategies placing orders with Atm strategies do not. Once again, this is only an issue when more than one Atm is used to enter a position for scaling into a position.

Currently, I am using several arrays to keep track of the AtmStrategyId, MarketPosition, RealizedPnL, and UnRealizedPnl for each individual Atm placed and summing up totals as needed . . . which IMHO is much ado to simply track the account (or strategy) market position and PnL values that are available to the DOM and Control Center.

Good luck transitioning back to school and thanks for your superb ongoing support of this forum and willingness to resolve the challenges I put forth.

Regards,

Whitmark

[NinjaTrader_Josh]

Unfortunately I can't think of any better out-of-the-box solution for the issue. The manual tallying via array is the only way that comes to my mind as well. This will be on our list for future considerations/enhancements.