Broker functions generate the orders that create, remove or adjust positions.

 

All Broker Object Orders created will be applied to the data on the next available trading date.

 

Broker object contains three classes of functions:

 

Each Broker function selection determines an order's type and execution requirements:

 

Notes:

When a Broker function is executed, it starts the process of assembling the information the software will need to determine if the order can succeed, or fail, with the current market information.  

 

All Trading Blox orders are "Day-Orders."   This means that once they are tested against the market's information they must be enabled, or rejected.  Rejected orders are canceled and removed from access.  

 

When an order is rejected it is no longer available and it must be recreated with another Broker function execution so a new order will be available for the next test-date market information.  Recreating the order assume the system requires an order for the next market record.

 

Entry orders to reverse a position will exit a position trading in the opposite direction to the new entry order.  In testing this works well, but in brokerage most electronic orders require an order to exit and a different order to enter in the opposite direction.  This means that orders reversing direction in systems that will be traded should generate an exit order and a new entry order to ensure the brokerage follows the system's intent.

 

It is important at this stage to get a solid understanding of the order creation process.  Click on this link Order Object, If you have not studied how orders are created and processed.

 

Risk and Broker Orders

Protective exit price Stop-orders are used to calculate the risk of trades.  Risk is determined by difference between the order price and the protective exit stop price of an active position.  This difference creates a position point spread that is part of the risk/reward calculations, and is sometimes used with position sizing in the Money Manager.  For instance, the Fixed Fractional Money Manager uses the entry risk provided in a new entry order to determine the unit's quantity.  If you have no stops, undefined risk is assumed, and there is insufficient information to complete a Fixed Fractional calculation required for this sizing method.

 

When new entry orders are generated without any risk point spread, a different method for determining size must be used.  For example, the "Multi Money Manager" money manager blox allows the trader to select volatility sizing approach so as to create an estimate of the new entry order risk in order for a fractional sizing calculation to be successful.  There are many other methods for determining size that can be found in the postings in the Trading Blox forum.

 

 

In the second broker example where the order's execution type is to enter on the next open, the risk basis price uses the difference from the current date Close price to the protective "stopPrice" to determine the risk of a single contract or share purchase.  This is also the same process used with active positions that use protective exit prices to determine the risk amount of each contract in the position.  When multiple units are used, the point spread between the Close-price to each unit's protective price is used to estimate each unit's risk,  Multiple unit positions then sum the total risk of all units to create the instrument's currentPositionRisk.

 

The quantity of each order is determined by the Money Manager. The Broker object calls the Money Manager, and the Money Manager sets the quantity for each order.  If there is no Money Manager Block in the system, the unitSize defaults to 0. You must set the order quantity using order.order.SetQuantity() in the Unit Size script, or the size will be 0, which will result in a trade that has no effect in your testing.

 

When a protective stop price is used in the entry order, that value is saved with the instrument and can be accessed using the instrument's unitExitStop property. The stop order itself, however, is only placed for the entry price bar. To 'hold' the stop and place it in the market every day, use the following code in your Exit Orders script:

 

 

Many of our built-in systems use the above method to "hold" stops (keep a protective order in the market).

 

Multiple Units require an order for each unit when units are treated independently:

 

Price-Record Processing:

Use the Entry Day Retracement parameter to adjust how entry day stops are processed. A setting of 100% is the most conservative, a setting of 0% is the least conservative, and a setting of -1 will disable entry day stops.

 

 

Symbol as the First Parameter:

All broker functions will execute an order for the current default instrument in context.  When an order is intended for an instrument that isn't by default in the script at that time, the broker function's first parameter can be an instrument symbol. Applying a symbol that is different than the instrument in context will apply the order to instrument specified in the broker function.  When no symbol is provided the broker function will apply the order to the current instrument in context.

 

When specifying any instrument out of its normal context assignments it is important to check the instrument.tradesOnTradeDate property to know if there is a new record available, or a holiday omission in the instrument's data.  This practice is just as important when manually looping over instruments using the LoadSymbol function, be sure new calculations with missing data are not distorting previously correct instrument information.

 

 

AlternateBroker:

When the Broker Object is out of the context of its default context scripts, the AlternateBroker object should be used to execute any of the Broker Object Entry and Exit Functions. AlternateBroker has the same functions and properties as the Broker Object and will work in the same way.  

 

---