Automations adhere to the Bot Settings' strict global controls when opening a new position.
There are 3 primary controls:
Before sending an order to your broker, the bot first checks if it is within the bounds of its global limits. If opening a new position violates any of these limits, the bot will alert you with an error.
These conditions are checked before the bot works through an automation. If the conditions are satisfied, the bot will continue through the automation and follow your actions.
Decision trees are modeled after one of the most fundamental structures in computer science: binary trees. 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 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.
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.
Decision nodes can also be negated by adding a NOT property in front of the decision logic. This allows the user to negate particular logic and more easily force the flow of a binary tree down the No path.
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 automation to open positions because of their strict adherence to the position limit settings.
Events offer more 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, when something happens inside the bot, 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 time zone.
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.
A UTC offset is employed for all Scheduled events. This means that when creating an automation to run 'next day' you must be before UTC 00:00 in order for the event to run the next market day. For example: 7:00pm EST or 8:00pm EDT.
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.