Synchronous Execution

Automations execute in an adjustable synchronous order, meaning automations run in the order specified by the user. Automations following in sequence will not wait for order completion but rather will wait for a callback and proceed to the next automation. This means 5 scanners with 5-minute limit order will not hold up execution.

The order is configured by selecting the arrows to the right of an automation. The automation on top runs first and the bottom automation runs last.

It is important to note that monitor automations will run first to process any closing orders ahead of possible new opening orders from a scanner. This is designed to alleviate concurrency issues when opening and closing positions on the same scan interval.

Scanner and monitor automations are queued and processed synchronously. Execution order is never guaranteed.

A redundant position check occurs prior to each execution. In the event Scanner 2 opens a position prior to Scanner 1, and has reached a global position limit, a warning will alert the user that the maximum position count has been reached.

This can happen when Scanner 1 has an execution method that is slower than Scanner 2, and Scanner 2 fills an order prior to Scanner 1.

The overall order of automations are: Exit Options, Scheduled Events, Monitors and Scanners.

Loops

The platform employs two different loop types -- Position and Symbol. Loops give you the ability to cycle through, or loop, a group of positions or symbols to check for other logic conditions down your decision tree.

Although scanner automation groups and monitor automation groups operate in a synchronous manner, loops inside them do not, and modifying this behavior would result in excessively long execution time. When a loop executes, the full logic of the decision tree is run for each symbol sequentially one after another.

When looping through Positions, the processing order is always Oldest to Newest. However, be aware that we reserve the right to change the way the cache system works and the behavior of how it returns the list of positions.

Position Allocation & Loops

When using a multi-symbol loop with a percentage-based allocation for each trade, it is not guaranteed that the % of available capital is distributed in the same order as the symbols inside of the loop.

Capital use is done by first figuring out how much there is total, then how much can be used based on the desired per position amount, and finally how many contracts/shares can fit into that amount based on margin requirements.

Example: Using $10k Total Allocation, 45% Net Liquid per position, with SPY, QQQ, and TLT in a Symbol Loop.

If you run the SPY, QQQ, TLT example test 100 times in a test environment, it will almost certainly use 45% SPY, 45% QQQ, and ~10% TLT, 100 times out of 100, because that's the order in which they're initially called and no one is competing for processor time.

But the moment you run the same loop in an active environment with hundreds of other bots executed by the same process, and at the same time pulling and waiting on all kinds of asynchronous data (e.g., opportunity decisions, indicators, etc.) from other processes, there is no guarantee which symbol will end up with the ~10%.

This means whichever symbol makes it to the order book first will get first dibs on decrementing the capital pool for itself. Nothing is based on fill or execution because that hasn't happened yet. The only certainty is whoever gets to the capital pool first and begins the process of opening a position gets to synchronously decrement the pool first with its pending draw value.

That is how we ensure the bot stays under $10k at all times. Poorly constructed logic will have the potential to yield unexpected results and it is encouraged to utilize other decisions to avoid common errors and warnings when utilizing loops.

If you attempt to open multiple positions using a percentage-based allocation amount greater than 50%, the subsequent position contract or share amount will be reduced intentionally to avoid an overallocation of more than 100% of bot capital.

1-Minute Exit Options

Any position can be assigned 1-minute Exit Options through an automation's Open Position action, its Update Position Exit Options action or the Manual Trading interface. The user-defined parameters are checked every one market minute between 9:40 AM and 3:59 PM Eastern. Safeguards have been established to ensure that your profit or stop loss levels are set to the worst possible fill based on the direction of the spread at the point the order is initiated (e.g., the bid price if selling or the ask price if buying). This can result in an order being canceled if unfilled but ensures that high exit efficiency is maintained.

The default exit method for Exit Options is SmartPricing set to normal and 100% of the Bid/Ask spread. It is possible that your exit fill may be within a 1% tolerance of your specified stop or target value because of the ask price's value at the point SmartPricing begins. Additionally, because SmartPricing will begin near the bid price, for example, exits can be higher than your specified target when trading a liquid underlying and contract.

In high volatility times it is possible the price of an option contract can change rapidly and surpass your Stop level.

Bots will actively prevent an action from taking place when an identical action is already in process to avoid overlapping with other automations. The event sequence is set to run Exit Options before other automations in the following order:  Exit Options, Scheduled Events, Monitors, and Scanners

Intervals

Every Scanner and Monitor has a default scanning interval of 15 minutes. This means every 15 minutes—beginning approximately 15 minutes after the market opens, and ending at 15 minutes before the market close—automation(s) will scan for the criteria specified in the automation. If criteria are met, your bot will take an action, whether that is to open a trade, close a trade, or prompt you to take further action.

At this time, the only interval option is the 15-minute intervals, alternate intervals may be added at a future date and time for a small additional fee, and notices will be sent out as this option becomes available.

All user automations are pushed into a distributed work queue and executed in parallel by worker processes. There is no guarantee an automation will run exactly on the 15-minute marks of every hour.

If a price, indicator, etc. exceeds a threshold between intervals, the bot does not know about it. The one major exception is tracking Smart Stops, where the position gain and high gain are tracked every minute. Regardless, even if a bot is logging information or position data between intervals, it will not act upon it until automation execution at the next interval.

In most cases, a bot will pull fresh data for all relevant decisions in every automation during execution. In other words, every 15 minutes, all relevant securities or options symbols will be quoted with the most up-to-date (usually sub-second) data.

Expiration Day

The last bot automation interval takes place at 3:45 Eastern time (15 minutes before market close) and will fire off any orders at that time, with one caveat. If it is expiration day and any leg of an options position is in-the-money (ITM), the bots will attempt to close the entire position.  Bots do not support assignments. They will attempt to close ITM positions at 3:50, 3:55, and 3:59 Eastern Time on the last day of trading, regardless of account level.