8 Sending trade orders

8.1 General usage

Five order types are supported in IB-Matlab, which use the following values for IBMatlab’s Action parameter: ‘Buy’, ‘Sell’, ‘SShort’, ‘SLong’, ‘Close’.72

Several additional IBMatlab parameters affect trade orders. The most widely-used properties are Type (default='LMT'), Quantity and LimitPrice. Additional properties are explained below. Here is a simple example for buying and selling a security:

orderId = IBMatlab('action','BUY','symbol','GOOG','quantity',100,...
'type','LMT', 'limitPrice',600);

orderId = IBMatlab('action','SELL','symbol','GOOG','quantity',100,...
'type','LMT', 'limitPrice',600);

In this example, we have sent an order to Buy/Sell 100 shares of GOOG on the SMART exchange, using an order type of Limit and limit price of US$600. IBMatlab returns the corresponding orderId assigned by IB – we can use this orderId later to modify open orders, cancel open orders, or follow-up in TWS or in the trade logs.

warningImportant: The IB server accepts up to 50 messages per second. If you exceed this rate, you will receive an error message from IB. This is important when submitting multiple orders to IB in a loop (baskets are not currently supported by the IB API).

IBMatlab always returns an orderId (positive integer number) if the order is successfully created. This does not mean that the order is accepted: it may be rejected or held by the IB server or exchange. In such cases, a followup error message is sent from the IB server and appears as a red message in the Matlab console. For example:

[API.msg2] The following order "ID:662631663" size exceeds the Size Limit of 500. Restriction is specified in Precautionary Settings of Global Configuration/Presets. {662631703, 451}

[API.msg2] Order Message:
SELL 12 GOOG NASDAQ.NMS
Warning: your order will not be placed at the exchange until
2016-10-06 09:30:00 US/Eastern {662631843, 399}

The order’s Type parameter is described in detail below (§8.3). In addition to specifying the Symbol, Type, Quantity and LimitPrice, several other parameters may need to be specified to fully describe the order.

All the order parameters listed below are optional, except for Action and Quantity.73 Depending on the order Type, additional parameters may also be mandatory (e.g., LimitPrice and AuxPrice). Here is a summary of order parameters in IBMatlab:74

Parameter

Type

Default

Description

Action

string

(none)

One of: 'Buy', 'Sell', 'SShort', 'SLong' 75 or 'Close' (see §8.2 below)

Quantity

number

0

Number of requested shares. Must be > 0.

Type

string

'LMT'

Refer to the order-types table in §8.3 below

LimitPrice

number

0

Limit price used in Limit order types

AuxPrice

number

0

Extra numeric data used by some order types (e.g., STP and TRAIL)

TrailingPercent

number

0

Trailing percent for TRAIL order types (§8.4)

TrailStopPrice

number

0

The stop price used when Type='Trail Limit'

TIF

string

'GTC'

Time-in-Force. Not all TIFs are available for all orders. Can be one of:

'Day' – Good until end of trading day

'DTC' – Day Till Cancelled

'GTC' – Good Till Cancelled (default)

'GTD' – Good Till Date (uses the GoodTillDate parameter below) 76

'GAT' – Good After Time/date (uses GoodAfterTime parameter below) 77

'IOC' – Immediate or Cancel

'FOK' – Fill or Kill78

'OPG' – Open Price Guarantee79

'AUC' – Auction, submitted at the Calculated Opening Price80

GoodTillDate

string

''

Format: 'YYYYMMDD hh:mm:ss TMZ' (TMZ is optional81)

GoodAfterTime

string

''

Format: 'YYYYMMDD hh:mm:ss TMZ' (TMZ is optional82)

OutsideRTH

integer or logical flag

0=false

0 or false: order should not execute outside regular trading hours

1 or true: order can execute outside regular trading hours if required.83

Hold

integer or logical flag

0=false

0 or false: order is sent to IB immediately

1 or true: order is prepared in IB-Matlab but not sent to IB. The user can them modify the order properties before sending it to IB. See §9.6 below for additional details.

Transmit

integer or logical flag

1=true

0 or false: order is sent to IB but waits in TWS until user clicks <Transmit> (§9.6)

1 or true: order should immediately be sent by IB to the exchange for execution

WhatIf

integer or logical flag

0=false

0 or false: regular order sent to exchange

1 or true: dummy order to compute margin impact (see §8.6 below for details)

AccountName

string

''

IB account used for this trade. Useful if you manage multiple accounts, else leave empty.

FAProfile

string

''

Financial Advisor profile for trades allocation (§8.5). Only relevant for Financial Advisor accounts, otherwise leave empty.

FAGroup

string

''

Financial Advisor account group for trades allocation (§8.5). Only relevant for Financial Advisor accounts, otherwise leave empty.

FAMethod

string

''

Method by which trades allocate within the stated FAGroup (§8.5). Only relevant for Financial Advisor accounts, else leave empty.

FAPercentage

number

0

Percentage of position change used when FAMethod='PctChange' (§8.5). Relevant for Financial Advisor accounts, else leave as-is.

OrderId

integer

(auto-assigned)

If specified, and if the specified OrderId is still open, then the specified order data will be updated, rather than creating a new order. Use this to modify open orders (see §10 below).

ParentId

integer

0

Useful for setting child orders of a parent order: these orders are only active when their parent OrderId is active or gets triggered. This is used in hedged- and bracket orders (see §9.3 below), but can also be used otherwise.

BracketTypes

cell array of 2 strings

Buy: {'STP', 'LMT'}

Sell: {'LMT', 'STP'}

Types of child bracket orders. The first string in the cell array defines the order type for the lower bracket; the second string defines the order type for the upper bracket. See related BracketDelta parameter above, and §9.3 below for additional details.

BracketDelta

number

[]=empty

Price offset for stop-loss and take-profit bracket child orders (see §9.3 below).

BracketDelta may be a single value or a [lowerDelta,upperDelta] pair of values > 0

Note: value(s) must be positive:
- low bracket will use limitPrice – lowerDelta
- high bracket will use limitPrice + upperDelta

OCAGroup

string

''

One-Cancels-All group name. This can be specified for several trade orders so that whenever one of them gets cancelled or filled, the others get cancelled automatically.84

OCAType

integer

2

One of (where allowed/applicable):

1 = Cancel on fill with block

2 = Reduce on fill with block

3 = Reduce on fill without block

HedgeType

string

''

One of:85

'D' – Delta (parent option, child stock)

'B' – Beta

'F' – FX

'P' – Pair

Relevant only for hedge orders, otherwise leave empty (or do not specify at all).

Note: hedge orders must be child orders (ParentId>0) with Quantity=0.

HedgeParam

number

[]=empty

Beta = x for Beta hedge orders (0=unused);

Ratio = y for Pair hedge orders.

Relevant only for Beta/Pair hedge orders, otherwise leave empty (or do not specify).

TriggerMethod

integer

0

One of:86

0=Default

1=Double-Bid-Ask

2=Last

3=Double-Last

4=Bid-Ask

7=Last-or-Bid-Ask

8=Mid-point

OrderRef

string

''

A comment that is attached to the order, displayable in TWS as an Order Attribute

8.2 Close orders

When setting Action to ‘Close’, IBMatlab fetches the current portfolio position for the specified Symbol or LocalSymbol, and issues a trade order to liquidate this position.

For example, if we have 15 shares of GOOG in our portfolio, the following commands are equivalent (internally, the first (CLOSE) command is automatically converted into the second (SELL) command before being sent to IB):

orderId = IBMatlab('action','CLOSE','symbol','GOOG',...
'type','LMT', 'limitPrice',600);

orderId = IBMatlab('action','SELL','symbol','GOOG','quantity',15,...
'type','LMT', 'limitPrice',600);

The main benefit of using Action=’Close’ is that you do not need to know the exact number of shares in the portfolio. If IBMatlab does not find the specified contract in the portfolio, then the command simply returns with an orderId of -1.

Naturally, when Action=’Close’, any user-specified Quantity value is ignored – the order quantity is determined based on the actual portfolio position.

Financial advisors should note that Action=’Close’ commands are not supported for multiple accounts at once, only for a single account at a time. If you try to issue the command for multiple accounts (as shown in §4.1, §4.2), then an error will be thrown asking you to specify the AccountName parameter to a single account. Alternatively, use the PctChange FAMethod to close the open positions (as shown in §8.5). If you only manage a single IB account, then the AccountName parameter is ignored and you do not need to worry about this limitation.

8.3 Order types

IB supports many order types. Some of these may not be available on your TWS and/or the requested exchange and security type.87 Also, some order types are not supported by IB on paper-trading accounts, only live accounts.88 You need to carefully ensure that the order type is accepted by IB before using it in IBMatlab.

Here is the list of order types supported by IBMatlab, which is a subset of the list in IB’s documentation (if you encounter an order type that you need and is not on this list, try using it in IBMatlab – perhaps it will indeed be accepted by the IB server):

Class

Order type
full name

Order type abbreviation

Description

Limit risk

Limit

LMT

Buy or sell a security at a specified price or better.

Market-to-Limit

MTL

A Market-To-Limit order is sent as a Market order to execute at the current best price. If the entire order does not immediately execute at the market price, the remainder of the order is re-submitted as a Limit order with the limit price set to the price at which the market order portion of the order executed.

Market with Protection

MKT PRT

A Market With Protection order is sent as a Market order to execute at the current best price. If the entire order does not immediately execute at the market price, the remainder of the order is re-submitted as a Limit order with the limit price set by Globex to a price slightly higher/lower than the current best price

Stop

STP

A Stop order becomes a Market order to buy (sell) once market price rises (drops) to the specified trigger price (the AuxPrice parameter).

Stop Limit

STP LMT

A Stop Limit order becomes a Limit order to buy (sell) once the market price rises (drops) to the specified trigger price (the AuxPrice parameter).

Limit risk

Trailing Limit if Touched

TRAIL LIT

A Trailing Limit-If-Touched sell order sets a trigger price at a fixed amount (AuxPrice parameter) or % (TrailingPercent parameter) above the market price. If the market price falls, the trigger price falls by the same amount; if the market price rises, the trigger price remains unchanged. If the market price rises all the way to the trigger price the order is submitted as a Limit order.

(and vice versa for buy orders)

Trailing Market If Touched

TRAIL MIT

A Trailing Market-If-Touched sell order sets a trigger price at a fixed amount (AuxPrice parameter) or % (TrailingPercent parameter) above the market price. If the market price falls, the trigger price falls by the same amount; if it rises, the trigger price remains unchanged. If the market price rises all the way to the trigger price, the order is submitted as a Market order.

(and vice versa for buy orders)

Trailing Stop

TRAIL

A Trailing Stop sell order sets the stop trigger price at a fixed amount (AuxPrice parameter) or % (TrailingPercent parameter) below the market price. If the market price rises, stop trigger price rises by the same amount; if it falls, the trigger price remains unchanged. If market price falls all the way to trigger price, the order is submitted as a Market order.

(and vice versa for buy orders)

(see details and usage example in §8.4 below)

Trailing Stop Limit

TRAIL LIMIT

A Trailing Stop Limit sell order sets the stop trigger price at a fixed amount (AuxPrice parameter) or % (TrailingPercent parameter) below market price. If the market price rises, the stop trigger price rises by the same amount; if the market price falls, the trigger price remains un-changed. If the price falls all the way to the trigger price, the order is submitted as a Limit order (see usage example below).

(and vice versa for buy orders)

(see details and usage example in §8.4 below)

Execution speed

Market

MKT

An order to buy (sell) a security at the offer (bid) price currently available in the marketplace. There is no guarantee that the order will fully or even partially execute at any specific price.

Market-if-Touched

MIT

A Market-if-Touched order becomes a Market order to buy (sell) once the market price drops (rises) to the specified trigger price.

Market-on-Close

MOC

Market-on-Close executes as a Market order during closing time, as close to the closing price as possible.

Pegged-to-Market

PEG MKT

A Limit order whose price adjusts automatically relative to market price using specified offset amount

Relative

REL

An order whose price is dynamically derived from the current best bid (offer) in the marketplace. For a buy order, the price is calculated by adding the specified offset (or %) to the best bid. A limit price may optionally be entered to specify a cap for the amount you are willing to pay.

(and vice versa for sell orders)

Price improvement

Box Top

BOX TOP

A Market order that automatically changes to Limit order if it does not execute immediately at market.

Limit-on-Close

LOC

Limit-on-close will execute at the market close time, at the closing price, if the closing price is at or better than the limit price, according to the exchange rules; Otherwise the order will be cancelled.

Limit if Touched

LIT

A Limit-if-Touched order becomes a Limit order to buy (sell) once the market price drops (rises) to the specified trigger price.

Pegged-to-Midpoint

PEG MID

A Limit order whose price adjusts automatically relative to midpoint price using specified offset amt.

TWAP -
best efforts

TWAP

Achieves the Time-Weighted Average Price on a best-effort basis (see details in §9.2 below).

VWAP -
best efforts

VWAP

Achieves the Volume-Weighted Average Price on a best-effort basis (see details in §9.1 below).

VWAP – guaranteed

Guarrante-edVWAP

The VWAP for a stock is calculated by adding the dollars traded for every transaction in that stock (“price” x “number of shares traded”) and dividing the total shares traded. By default, a VWAP order is computed from the open of the market to the market close, and is calculated by volume weighting all transactions during this time period. IB allows you to modify the cut-off, expiration times using Time in Force (TIF) and Expiration Date fields respectively.

8.4 Trail orders

Here is a usage example for sending a TRAIL order:89 In this example, we previously purchased 100 shares of IBM at an average price of $139.156 and now wish to lock-in a profit and limit our loss. We set a trailing stop order with the trailing amount $0.20 below the current market price of $139.71. To do this, create a sell order, with Type='TRAIL' and AuxPrice=0.20 (the trailing amount):

orderId = IBMatlab('action','SELL', 'symbol','IBM', 'quantity',100,...
'type','TRAIL', 'auxPrice',0.20);

The trigger (stop) price will follow (trail) market movements upwards, and remains stable when the market falls. The trigger (stop) price is initially set to $139.71 - $0.20 = $139.51, and rises with the market. When the market price reaches $139.89, the corresponding stop price is updated to $139.89 - $0.20 = $139.69. When the market price then falls to $139.73, the stop price remains stable at $139.69:

temp

When the market price drops all the way to the stop price, the order is submitted as a Market order, which immediately fills (depending on market fluidity).

We can specify the trailing offset as either a fixed amount (AuxPrice parameter) or a percentage (TrailingPercent parameter), but not both.

As a related example, we can use a TRAIL LIMIT order:90 Here we want a Limit (not Market) order when the market price drops to the trigger (stop) price. So, we provide a limit offset price in addition to trailing amount/%, using the TrailStopPrice parameter. In our example, when market (last) price was $168.38 we set AuxPrice= 0.10, TrailStopPrice=168.32, and LimitPrice=168.35, i.e. a limit offset of $-0.03:

orderId = IBMatlab('action','SELL', 'symbol','IBM', 'quantity',1,...
'type','TRAIL LIMIT', 'auxPrice',0.10, ...
'TrailStopPrice',168.32, 'LimitPrice',168.50);

???

As long as the market rises and last price >= TrailStopPrice + AuxPrice, both the trigger (stop) price and limit price will rise. Once the price drops to the latest stop price ($168.39, which is $0.10 below the highest market price up to now: $168.49), the order will change into a LMT order with a limit price of $168.39+$0.03=$168.42 and marked as triggered (Status field in TWS will change from ??? to ???).

warningNote 1: IB’s API changed the meaning of TrailStopPrice in 2016, so test carefully!

Note 2: Trail orders with a limit (TRAIL LIMIT, TRAIL LIT), require either a fixed offset amount (TWS Global ConfigàPresets) or a specified LimitPrice, but not both. Depending on your TWS version, TWS global configuration might have a fixed default offset amount ($0.01) that conflicts with the specified LimitPrice, causing an IB error:

orderId = IBMatlab('action','SELL', 'symbol','CHS', 'quantity',200,...
'type','TRAIL LIT', 'AuxPrice',0.30, ...
'TrailStopPrice',4.80, 'LimitPrice', 4.85);

[API.msg2] Error validating request:-'bN' : cause - You must specify one value: limit price or limit price offset value. {1065098216, 321}

In such cases, the order will be held in TWS and will not be transmitted for execution. You will need to interactively modify the order’s parameters in TWS (remove either the offset amount or limit price), before it can be transmitted to IB for execution.

???

To avoid this problem and transmit TRAIL LIMIT/LIT orders directly from IB-Matlab, either set LimitPrice to Inf (if you want to use a fixed offset without a fixed limit), or remove (replace with a blank value) the default offset amount in TWS Global Configà Presets (if you want to use a specified LimitPrice without a fixed offset).

8.5 Financial Advisor (multi-client) orders

Financial Advisor (FA, or “multi-client”) accounts in IB have the ability to manage multiple individual accounts under a single parent account. IB does not expose FA functionalities to individual-account holders – such users should skip this section.

When sending a trade order to an FA account, we need to tell IB which sub-account(s) should be affected by the order. The possible alternatives are:

Execute the trade order in a specific sub-account.

Execute the trade order in multiple sub-accounts, using an Allocation Profile (that was previously-defined in TWS91).

Execute the trade order in multiple sub-accounts, using an Account Group (that was previously-defined in TWS92) and a specified allocation method.

We can also set-up a default allocation in TWS,93 avoiding the need to specify the allocation separately for each trade order. The following discussion assumes that such a default allocation is not used, or that it is overridden on a per-trade basis.

For example, assume that our parent account is called DF1230 and it has three sub-accounts (DU1231, DU1232, and DU1233).

To send the trade to a specific account, simply state the AccountName parameter:

orderId = IBMatlab('action','BUY', 'symbol','IBM', 'quantity',100,...
'type','MKT', 'AccountName','DU1232');

To send the trade to multiple specific sub-accounts using a predefined allocation profile, state the FAProfile parameter with the requested profile name:

orderId = IBMatlab('action','BUY', 'symbol','IBM', 'quantity',100,...
'type','MKT', 'FAProfile','myProfile1');

To send the trade to multiple specific sub-accounts using a predefined accounts group, state the FAGroup and FAMethod parameters, and possibly also the FAPercentage parameter (only if FAMethod = 'PctChange'):

% Enter into position: allocate to sub-accounts based on their netliq
orderId = IBMatlab(
'action','BUY', 'symbol','IBM', 'quantity',100,...
'type','MKT', 'FAGroup','EntryGroup', ...
'FAMethod','NetLiq');

% Exit position: each sub-account's position reduced by 100%
orderId = IBMatlab(
'action','SELL', 'symbol','IBM', ... % no Quantity
'type','MKT', 'FAGroup','ExitGroup', ...
'FAMethod','PctChange', 'FAPercentage',-100);

Note how in this latest example, we’ve used the NetLiq method to enter into a position (split up amongst the sub-accounts defined in our EntryGroup, based on the accounts relative net liquidation values), but we exit the position using the PctChange method (i.e., sell securities such that the new position in each sub-account is -100% of its current position). This is a very typical entry/exit usage scenario.

The benefit of using PctChange to exit a position is that we do not need to calculate or even know the total Quantity nor the actual current position in each of the sub-accounts. We cannot use NetLiq to exit the position (as we have to enter it), since the different sub-accounts may possibly have a different NetLiq relative ratio between themselves, so the liquidation order would leave a few extra shares in some sub-acounts and a few missing (shorted) shares in the other sub-accounts.

warningNote that FAMethod only works with FAGroup and is a mandatory parameter when FAGroup is specified. In other words, we cannot specify FAMethod with FAProfile, nor specify FAGroup without a corresponding FAMethod.

When specifying FAMethod=PctChange, it is an error to specify the Quantity, since the quantity is automatically calculated by IB. Also, the trade order will only have an effect if the trade Action and the current total position would result in a trade having the same direction as the requested FAPercentage.

For example, if we currently have 20 shares of IBM in DU1231, 30 shares in DU1232 and 50 shares in DU1233 (i.e., a total of 100 shares), then the exit order above would result in a valid trade order that would sell 100 shares of IBM at MKT and reduce each of the sub-accounts’ holdings to 0 shares (-100% of their current holdings).

On the other hand, if we used Action=BUY (rather than SELL), then the direction of the action and position (i.e., increase the position) would not match the direction of the requested FAPercentage (-100%, i.e. decrease position). The IB-calculated order size would be 0, the order would not execute, and IB will send us an error message:

orderId = IBMatlab('action','BUY', 'symbol','IBM', ... % no Quantity
'type','MKT', 'FAGroup','ExitGroup', ...
'FAMethod','PctChange', 'FAPercentage',-100);

[API.msg2] The order size cannot be zero. {640996954, 434}

Action

FAPercentage

Long position

Short position

Buy

Positive (>0)

Trade increases position

Error (no trade)

Negative (<0)

Error (no trade)

Trade decreases position

Sell

Positive (>0)

Error (no trade)

Trade increases position

Negative (<0)

Trade decreases position

Error (no trade)

If you state a FAMethod that is not officially supported by IB, IB-Matlab issues a warning but sends the request to IB anyway, in the hope that the method is supported after all. If IB does not support it, the request is ignored and IB sends an error message:

IBMatlab('action','BUY', 'symbol','IBM', 'quantity',100,...
'type','MKT', 'FAGroup','EntryGroup', 'FAMethod','XYZ');

Warning: FAMethod 'XYZ' may possibly not be supported by IB
(Type "warning off YMA:IBMatlab:FAMethod" to suppress this warning.)

[API.msg2] Order rejected - reason: Invalid value in field # 6159 {640973648, 201}

Note that Action=’Close’ commands (§8.2) are not supported for multiple accounts at once, only for a single account at a time. If you try to issue the command for multiple accounts (as shown in §4.1, §4.2), then an error will be thrown, asking you to specify the AccountName parameter to a single account. Alternatively, use the PctChange method to close the open positions as shown above.

The following parameters affect Financial Advisor (FA) trade orders:

Parameter

Type

Default

Description

AccountName

String

''

The specific IB account used for this trade.
Useful when you manage multiple IB accounts, otherwise leave empty.

FAProfile

String

''

Financial Advisor profile for trade allocation. Only relevant for Financial Advisor (multi-client) accounts, otherwise leave empty.

FAGroup

String

''

Financial Advisor account group for trade allocation. Only relevant for Financial Advisor (multi-client) accounts, otherwise leave empty.

FAMethod

String

''

Method by which trades will be allocated within the stated FAGroup. Only relevant for Financial Advisor accounts, otherwise leave empty.

IB officially supports the following methods:

NetLiq

EqualQuantity or Equal (depends on TWS version)

AvailableEquity

PctChange (requires FAPercentage)

FAPercentage

Number

0

Percentage of position change used when FAMethod = 'PctChange'. Only relevant for Financial Advisor accounts, otherwise leave as-is.

When this FAPercentage parameter is specified, the Quantity parameter may NOT be specified.

8.6 Potential impact of an order (“what-if”)

It is possible to investigate the margin and commission impact of a potential order using the WhatIf parameter. By default this parameter has a value of false, meaning that a regular trade order will be sent to the markets. But if you set WhatIf to a value of true (or 1) then IB will not really sent the trade order to the market – IB will just calculate and return the potential impact of the specified order on your account, including the updated account margin and the trade’s estimated commission:

>> data = IBMatlab('action','buy', 'symbol','IBM', 'type','MKT', ...
'quantity',1, 'whatif',true)
data =
status: 'PreSubmitted'
initMargin: 38.59
maintMargin: 38.59
equityWithLoan: 1004892.14
commission: Inf
minCommission: 0.34685725
maxCommission: 0.35345725
commissionCurrency: 'USD'
warningText: []

Note that the returned data is a Matlab struct, not a scalar orderId as for regular trade orders.

Also note: in IB-Matlab v2.19 (11/2022) and newer, values of Inf indicate an undefined/uninitialized value; in IB-Matlab v2.18 and older such values were reported as 1.79769313486232e+308 (realmax) or 2147483647 (intmax).


72 SShort is only relevant only for institutional accounts configured with Long/Short account segments or clear orders outside of IB, which need to distinguish between shorting/selling a position. In most acounts, orders are cleared by IB so you would only specify SELL for both shorting and selling (IB automatically infers the action type based on the currently-held position). SLong is available in specially-configured institutional accounts to indicate that long position not yet delivered is being sold.

73 Quantity should only be omitted if Action='close' or FAMethod='PctChange' – see §8.2 and §8.5 below.

74 Also see the corresponding API documentation: https://interactivebrokers.github.io/tws-api/classIBApi_1_1Order.html

75 SShort is only relevant only for institutional accounts configured with Long/Short account segments or clear orders outside of IB, which need to distinguish between shorting/selling a position. In most acounts, orders are cleared by IB so you would only specify SELL for both shorting and selling (IB automatically infers the action type based on the currently-held position). SLong is available in specially-configured institutional accounts to indicate that long position not yet delivered is being sold.

76 GTD requires enabling Advanced Time In Force Attributes in TWS / IB Gateway’s Configuration: (http://interactivebrokers.com/en/software/webtrader/webtrader/orders/advanced%20time%20in%20force%20attributes.htm)

77 GAT requires enabling Advanced Time In Force Attributes in the Preferences page of TWS / IB Gateway (http://interactivebrokers.com/en/software/webtrader/webtrader/orders/advanced%20time%20in%20force%20attributes.htm). For additional information see http://interactivebrokers.com/en/software/tws/usersguidebook/ordertypes/good_after_time.htm

78 FOK requires the entire order to be filled, as opposed to IOC that allows a partial fill. For additional information on FOK see http://interactivebrokers.com/en/software/tws/usersguidebook/ordertypes/fill_or_kill.htm

79 An OPG is used with a Limit order to indicate a Limit-on-Open order (http://interactivebrokers.com/en/software/tws/usersguidebook/ordertypes/limit-on-open.htm), or with a Market order to indicate a Market-on-Open order (http://interactivebrokers.com/en/software/tws/usersguidebook/ordertypes/market-on-open.htm)

80 For additional information on AUC see http://interactivebrokers.com/en/software/tws/usersguidebook/ordertypes/auction.htm

81 The list of time zones accepted by IB is listed in §9.1 below

82 The list of time zones accepted by IB is listed in §9.1 below

83 OutsideRTH=true requires setting the corresponding preset option in TWS/Gateway Configuration (Presets-Stocks-Timing). If this preset option is not set, OutsideRTH will be ignored and the order will not be executed outside Regular Trading Hours. https://www.interactivebrokers.com/en/index.php?f=22063#05

84 http://interactivebrokers.com/en/index.php?f=617

85 http://interactivebrokers.github.io/tws-api/hedging.html, http://interactivebrokers.com/en/software/tws/attachedordertop.htm

86 http://interactivebrokers.com/en/software/tws/usersguidebook/configuretws/modify_the_stop_trigger_method.htm

87 http://interactivebrokers.com/en/index.php?f=4985, http://interactivebrokers.github.io/tws-api/available_orders.html, http://interactivebrokers.com/en/software/tws/twsguide.htm#ordertypestop.htm

88 https://ibkrguides.com/clientportal/aboutpapertradingaccounts.htm

89 http://interactivebrokers.com/en/index.php?f=605

90 http://interactivebrokers.com/en/index.php?f=606

91 http://interactivebrokers.com/en/software/tws/usersguidebook/financialadvisors/create_a_share_allocation_profile.htm

92 http://interactivebrokers.com/en/software/tws/usersguidebook/financialadvisors/create_an_account_group_for_share_allocation.htm

93 http://interactivebrokers.com/en/software/tws/usersguidebook/financialadvisors/set_default_allocations.htm