An automation is conditional logic, represented as a decision tree scheduled to run at a particular time.

Global Controls

If an automation results in a new position opening, there is very strict adherence to the global controls within the Bot Settings page. There are 3 primary controls:
Total capital from your trading account available for the bot to open positions
Daily Position Limit
Number of positions that can be opened by the bot in one day.
Max Position Limit
Number of positions that can be open at any given time.
The first task a bot has before building an Opportunity to send to the broker is to check whether or not its state is within the bounds of its global limits. If the opening of a new position would violate any of these limits, the bot will simply throw an error.
These are the “kill switch” conditions that must be dictated for every bot and are checked before each traversal of a decision tree automation. If the conditions imposed by the global bot parameters have been satisfied, we cascade to the decision tree automations dictated by the user.

Binary Trees

We modeled decision trees after one of the most fundamental structures in all of computer science: binary trees. There are many ways to define a binary tree. The use of the word tree here comes from the fact that, when we draw them, the resultant drawing often resembles the trees found in a forest. Mathematically, a binary tree is a connected, undirected, finite graph with no cycles and no vertex of degree greater than three.
For most computer science applications, as in the case of the autotrading bots, binary trees are rooted: A special node, r, of degree at most two is called the root of the tree. For every node u ≠ r the second node on the path from u to r is called the parent of u. Each of the other nodes adjacent to u is called a child of u. Most of the binary trees we are interested in are ordered, so we distinguish between the left child and right child of u, i.e., the Yes/No decision path.
Binary trees are typically drawn from the root downward, with the root at the top of the drawing and the left and right children respectively given by left (Yes) and right (No) positions in the drawing.


Each parent and/or root node of the decision tree is composed of conditional statements, using both logical and relational operators that are built out of "decision recipes" curated by the Option Alpha team.
Grouped conditional statements work in the same way they would in any modern programming language, discrete math and/or discrete logic, with the exception that decisions in automations do not use negation.
Example of translated logic in Node.js: A && B && (C || D) && E
If a leaf node in a decision tree results in an action to open or close a position, the bot will use your broker's API to submit the order.
Input parameters first go through a translation process, e.g., the rate of return in “Opportunity rate of return is greater than 25%” is translated into a real number before the mathematical condition is tested.
The translation process into mathematical properties requires the user to input theoretical trade criteria, and that trade criteria has parameters of its own. In this case, the parameter input process is multiple layers deep. Fortunately, these trade inputs are identical to the opening position parameters required for the action of placing a real trade, typically located at the bottommost node of the decision tree.
All parameters are evaluated for a binary outcome (true or false). In general, all numeric parameters are used to test a conditional statement for truthfulness. The conditions are described with natural language that represents a mathematical operation, e.g., above or below implies greater than (>) or less than (<) in “MSFT price is above/below 100.”
The decision tree “decisions” and their parameters are grouped into four main categories: stock-based, opportunity-based, indicator-based, and position-based.

Automation Types

Scanners & Monitors

Scanner and Monitor automation categories are simply logical groupings for the abstract automation type. Automations in the Scanner category are intended for the searching and opening of opportunities, while automations in the Monitor category are intended for the management and closing of open positions.
There is no functional difference between the automations in either category. If required by the user, a Scanner automation can close a position or a Monitor automation can open one. In this sense, the Scanner/Monitor categorization is a convenience. Scanners will not run once a position limit is met. However, when using a monitor to open a position, if that position violates the global position limit settings, an error safeguard is in place and will throw an error for violating the set limit.
Scanners are designed to be used as the primary position opening automation because of their strict adherence to the position limit settings.


Events offer more granular control over automation execution than generic intervals. Users can create events to fire on a specific date at a specific time, at this very moment, and everything in between.
Events are established and executed in Eastern Time. When creating events, you are creating the event based on Eastern Time which may cause a difference in current or next-day interpretation from your browser's timezone.


Scheduled events are automations that run on a schedule, either once or in a repeating fashion. Users can choose to schedule one highly specific event, such as May 12th, 2021 at 9:45 AM Eastern, or on an arbitrary repeating schedule - e.g., the first of every month, every Mon/Wed/Fri, every third Friday, etc.
Holidays are accounted for in scheduled events. A user will have the option to run an automation the day before a holiday, the day after a holiday, or skip the holiday altogether. Selection can be made on the "Schedule" tab of an automation event.


There are 2 types of unscheduled events: resultant events and button clicks. Resultant events will fire as a result of another event occurring, such as the Opening or Closing of a position. When any position of a particular type is opened or closed, the user can choose to execute a separate automation immediately afterward.
Button clicks events are fired as a result of pressing a button the user adds to his or her dashboard. One button click results in one execution of an automation. These can be executed at any time during open market opens.

Automation Behavior

Synchronous Execution

Automations on the bot platform execute in an adjustable synchronous order. This means automations will 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 the individual automation's name. The automation on top runs first with the automation on the bottom running last.
It is important to note that the synchronous execution applies to "Scanners" and to "Monitors" as separate types of automations. This means "Scanner 1" and "Monitor 1" will run at the same time followed by "Scanner 2" and "Monitor 2".
A redundant position check is performed prior to each execution. In the event where Scanner 2 has opened a position prior to Scanner 1 and has thereby reached a global Position Limit, an error will be thrown alerting the user that the maximum position count has been reached. This can happen in cases where Scanner 1 has an execution method that is slower than Scanner 2, and Scanner 2 has obtained a fill prior to Scanner 1.
Scanner and monitor automations are queued and processed synchronously. Execution order is never guaranteed.


The platform employs two different types of Loops -- Position and Symbol. Loops offer 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 logic below it is executed for all symbols simultaneously.

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 thing in a production 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.


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.
Was this page helpful? Please click here to provide feedback.
Last modified 1mo ago