# Note that in the comments in this file, TWS refers to both the Trader

# Workstation and the IB Gateway, unless explicitly stated otherwise.

#

# When referred to below, the default value for a setting is the value

# assumed if either the setting is included but no value is specified, or

# the setting is not included at all.

#

# IBC may also be used to start the FIX CTCI Gateway. All settings

# relating to this have names prefixed with FIX.

#

# The IB API Gateway and the FIX CTCI Gateway share the same code. Which

# gateway actually runs is governed by an option on the initial gateway

# login screen. The FIX setting described under IBC Startup

# Settings below controls this.

# =============================================================================

# 1. IBC Startup Settings

# =============================================================================

# IBC may be used to start the IB Gateway for the FIX CTCI. This

# setting must be set to 'yes' if you want to run the FIX CTCI gateway. The

# default is 'no'.

FIX=no

# =============================================================================

# 2. Authentication Settings

# =============================================================================

# TWS and the IB API gateway require a single username and password.

# You may specify the username and password using the following settings:

#

# IbLoginId

# IbPassword

#

# Alternatively, you can specify the username and password in the command

# files used to start TWS or the Gateway, but this is not recommended for

# security reasons.

#

# If you don't specify them, you will be prompted for them in the usual

# login dialog when TWS starts (but whatever you have specified will be

# included in the dialog automatically: for example you may specify the

# username but not the password, and then you will be prompted for the

# password via the login dialog). Note that if you specify either

# the username or the password (or both) in the command file, then

# IbLoginId and IbPassword settings defined in this file are ignored.

#

#

# The FIX CTCI gateway requires one username and password for FIX order

# routing, and optionally a separate username and password for market

# data connections. You may specify the usernames and passwords using

# the following settings:

#

# FIXLoginId

# FIXPassword

# IbLoginId (optional - for market data connections)

# IbPassword (optional - for market data connections)

#

# Alternatively you can specify the FIX username and password in the

# command file used to start the FIX CTCI Gateway, but this is not

# recommended for security reasons.

#

# If you don't specify them, you will be prompted for them in the usual

# login dialog when FIX CTCI gateway starts (but whatever you have

# specified will be included in the dialog automatically: for example

# you may specify the usernames but not the passwords, and then you will

# be prompted for the passwords via the login dialog). Note that if you

# specify either the FIX username or the FIX password (or both) on the

# command line, then FIXLoginId and FIXPassword settings defined in this

# file are ignored; he same applies to the market data username and

# password.

# IB API Authentication Settings

# ------------------------------

# Your TWS username:

IbLoginId=${TWS_USERID}

# Your TWS password:

IbPassword=${TWS_PASSWORD}

# FIX CTCI Authentication Settings

# --------------------------------

# Your FIX CTCI username:

FIXLoginId=

# Your FIX CTCI password:

FIXPassword=

# Second Factor Authentication Settings

# -------------------------------------

# If you have enabled more than one second factor authentication

# device, TWS presents a list from which you must select the device

# you want to use for this login. You can use this setting to

# instruct IBC to select a particular item in the list on your

# behalf. Note that you must spell this value exactly as it appears

# in the list. If no value is set, you must manually select the

# relevant list entry.

SecondFactorDevice=${TWOFA_DEVICE}

# If you use the IBKR Mobile app for second factor authentication,

# and you fail to complete the process before the time limit imposed

# by IBKR, this setting tells IBC whether to automatically restart

# the login sequence, giving you another opportunity to complete

# second factor authentication.

#

# Permitted values are 'yes' and 'no'.

#

# If this setting is not present or has no value, then the value

# of the deprecated ExitAfterSecondFactorAuthenticationTimeout is

# used instead. If this also has no value, then this setting defaults

# to 'no'.

#

# NB: you must be using IBC v3.14.0 or later to use this setting:

# earlier versions ignore it.

ReloginAfterSecondFactorAuthenticationTimeout=${RELOGIN_AFTER_TWOFA_TIMEOUT}

# This setting is only relevant if

# ReloginAfterSecondFactorAuthenticationTimeout is set to 'yes',

# or if ExitAfterSecondFactorAuthenticationTimeout is set to 'yes'.

#

# It controls how long (in seconds) IBC waits for login to complete

# after the user acknowledges the second factor authentication

# alert at the IBKR Mobile app. If login has not completed after

# this time, IBC terminates.

# The default value is 60.

SecondFactorAuthenticationExitInterval=${TWOFA_EXIT_INTERVAL}

# This setting specifies the timeout for second factor authentication

# imposed by IB. The value is in seconds. You should not change this

# setting unless you have reason to believe that IB has changed the

# timeout. The default value is 180.

SecondFactorAuthenticationTimeout=180

# DEPRECATED SETTING

# ------------------

#

# ExitAfterSecondFactorAuthenticationTimeout - THIS SETTING WILL BE

# REMOVED IN A FUTURE RELEASE. For IBC version 3.14.0 and later, see

# the notes for ReloginAfterSecondFactorAuthenticationTimeout above.

#

# For IBC versions earlier than 3.14.0: If you use the IBKR Mobile

# app for second factor authentication, and you fail to complete the

# process before the time limit imposed by IBKR, you can use this

# setting to tell IBC to exit: arrangements can then be made to

# automatically restart IBC in order to initiate the login sequence

# afresh. Otherwise, manual intervention at TWS's

# Second Factor Authentication dialog is needed to complete the

# login.

#

# Permitted values are 'yes' and 'no'. The default is 'no'.

#

# Note that the scripts provided with the IBC zips for Windows and

# Linux provide options to automatically restart in these

# circumstances, but only if this setting is also set to 'yes'.

ExitAfterSecondFactorAuthenticationTimeout=no

# Trading Mode

# ------------

#

# This indicates whether the live account or the paper trading

# account corresponding to the supplied credentials is to be used.

# The allowed values are 'live' (the default) and 'paper'.

#

# If this is set to 'live', then the credentials for the live

# account must be supplied. If it is set to 'paper', then either

# the live or the paper-trading credentials may be supplied.

TradingMode=${TRADING_MODE}

# Paper-trading Account Warning

# -----------------------------

#

# Logging in to a paper-trading account results in TWS displaying

# a dialog asking the user to confirm that they are aware that this

# is not a brokerage account. Until this dialog has been accepted,

# TWS will not allow API connections to succeed. Setting this

# to 'yes' (the default) will cause IBC to automatically

# confirm acceptance. Setting it to 'no' will leave the dialog

# on display, and the user will have to deal with it manually.

AcceptNonBrokerageAccountWarning=yes

# Login Dialog Display Timeout

#-----------------------------

#

# In some circumstances, starting TWS may result in failure to display

# the login dialog. Restarting TWS may help to resolve this situation,

# and IBC does this automatically.

#

# This setting controls how long (in seconds) IBC waits for the login

# dialog to appear before restarting TWS.

#

# Note that in normal circumstances with a reasonably specified

# computer the time to displaying the login dialog is typically less

# than 20 seconds, and frequently much less. However many factors can

# influence this, and it is unwise to set this value too low.

#

# The default value is 60.

LoginDialogDisplayTimeout=60

# =============================================================================

# 3. TWS Startup Settings

# =============================================================================

# Path to settings store

# ----------------------

#

# Path to the directory where TWS should store its settings. This is

# normally the folder in which TWS is installed. However you may set

# it to some other location if you wish (for example if you want to

# run multiple instances of TWS with different settings).

#

# It is recommended for clarity that you use an absolute path. The

# effect of using a relative path is undefined.

#

# Linux and macOS users should use the appropriate path syntax.

#

# Note that, for Windows users, you MUST use double separator

# characters to separate the elements of the folder path: for

# example, IbDir=C:\\IBLiveSettings is valid, but

# IbDir=C:\IBLiveSettings is NOT valid and will give unexpected

# results. Linux and macOS users need not use double separators,

# but they are acceptable.

#

# The default is the current working directory when IBC is

# started, unless the TWS_SETTINGS_PATH setting in the relevant

# start script is set.

#

# If both this setting and TWS_SETTINGS_PATH are set, then this

# setting takes priority. Note that if they have different values,

# auto-restart will not work.

#

# NB: this setting is now DEPRECATED. You should use the

# TWS_SETTINGS_PATH setting in the relevant start script.

IbDir=

# Store settings on server

# ------------------------

#

# TWS only: if you wish to store a copy of your TWS settings on

# IB's servers as well as locally on your computer, set this to

# 'yes': this enables you to run TWS on different computers

# with the same configuration, market data lines, etc. If set

# to 'no', running TWS on different computers will not share the

# same settings. If no value is specified, TWS will obtain its

# settings from the same place as the last time this user logged

# in (whether manually or using IBC).

#

# Note that this setting does not apply to Gateway, which does not

# provide this capability.

StoreSettingsOnServer=

# Minimize TWS on startup

# -----------------------

#

# Set to 'yes' to minimize TWS when it starts:

MinimizeMainWindow=no

# Existing Session Detected Action

# --------------------------------

#

# When a user logs on to an IBKR account for trading purposes by any means, the

# IBKR account server checks to see whether the account is already logged in

# elsewhere. If so, a dialog is displayed to both the users that enables them

# to determine what happens next. The 'ExistingSessionDetectedAction' setting

# instructs TWS how to proceed when it displays this dialog:

#

# * If the new TWS session is set to 'secondary', the existing session continues

# and the new session terminates. Thus a secondary TWS session can never

# override any other session.

#

# * If the existing TWS session is set to 'primary', the existing session

# continues and the new session terminates (even if the new session is also

# set to primary). Thus a primary TWS session can never be overridden by

# any new session).

#

# * If both the existing and the new TWS sessions are set to 'primaryoverride',

# the existing session terminates and the new session proceeds.

#

# * If the existing TWS session is set to 'manual', the user must handle the

# dialog.

#

# The difference between 'primary' and 'primaryoverride' is that a

# 'primaryoverride' session can be overriden over by a new 'primary' session,

# but a 'primary' session cannot be overriden by any other session.

#

# When set to 'primary', if another TWS session is started and manually told to

# end the 'primary' session, the 'primary' session is automatically reconnected.

#

# The default is 'manual'.

ExistingSessionDetectedAction=${EXISTING_SESSION_DETECTED_ACTION}

# Override TWS API Port Number

# ----------------------------

#

# If OverrideTwsApiPort is set to an integer, IBC changes the

# 'Socket port' in TWS's API configuration to that number shortly

# after startup (but note that for the FIX Gateway, this setting is

# actually stored in jts.ini rather than the Gateway's settings

# file). Leaving the setting blank will make no change to

# the current setting. This setting is only intended for use in

# certain specialized situations where the port number needs to

# be set dynamically at run-time, and for the FIX Gateway: most

# non-FIX users will never need it, so don't use it unless you know

# you need it.

OverrideTwsApiPort=

# Override TWS Master Client ID

# -----------------------------

#

# If OverrideTwsMasterClientID is set to an integer, IBC changes the

# 'Master Client ID' value in TWS's API configuration to that

# value shortly after startup. Leaving the setting blank will make

# no change to the current setting. This setting is only intended

# for use in certain specialized situations where the value needs to

# be set dynamically at run-time: most users will never need it,

# so don't use it unless you know you need it.

OverrideTwsMasterClientID=

# Read-only Login

# ---------------

#

# If ReadOnlyLogin is set to 'yes', and the user is enrolled in IB's

# account security programme, the user will not be asked to perform

# the second factor authentication action, and login to TWS will

# occur automatically in read-only mode: in this mode, placing or

# managing orders is not allowed.

#

# If set to 'no', and the user is enrolled in IB's account security

# programme, the second factor authentication process is handled

# according to the Second Factor Authentication Settings described

# elsewhere in this file.

#

# If the user is not enrolled in IB's account security programme,

# this setting is ignored. The default is 'no'.

ReadOnlyLogin=no

# Read-only API

# -------------

#

# If ReadOnlyApi is set to 'yes', API programs cannot submit, modify

# or cancel orders. If set to 'no', API programs can do these things.

# If not set, the existing TWS/Gateway configuration is unchanged.

# NB: this setting is really only supplied for the benefit of new TWS

# or Gateway instances that are being automatically installed and

# started without user intervention (eg Docker containers). Where

# a user is involved, they should use the Global Configuration to

# set the relevant checkbox (this only needs to be done once) and

# not provide a value for this setting.

ReadOnlyApi=${READ_ONLY_API}

# API Precautions

# ---------------

#

# These settings relate to the corresponding 'Precautions' checkboxes in the

# API section of the Global Configuration dialog.

#

# For all of these, the accepted values are:

# - 'yes' sets the checkbox

# - 'no' clears the checkbox

# - if not set, the existing TWS/Gateway configuration is unchanged

#

# NB: thess settings are really only supplied for the benefit of new TWS

# or Gateway instances that are being automatically installed and

# started without user intervention, or where user settings are not preserved

# between sessions (eg some Docker containers). Where a user is involved, they

# should use the Global Configuration to set the relevant checkboxes and not

# provide values for these settings.

BypassOrderPrecautions=${BYPASS_WARNING}

BypassBondWarning=${BYPASS_WARNING}

BypassNegativeYieldToWorstConfirmation=${BYPASS_WARNING}

BypassCalledBondWarning=${BYPASS_WARNING}

BypassSameActionPairTradeWarning=${BYPASS_WARNING}

BypassPriceBasedVolatilityRiskWarning=${BYPASS_WARNING}

BypassUSStocksMarketDataInSharesWarning=${BYPASS_WARNING}

BypassRedirectOrderWarning=${BYPASS_WARNING}

BypassNoOverfillProtectionPrecaution=${BYPASS_WARNING}

# Market data size for US stocks - lots or shares

# -----------------------------------------------

#

# Since IB introduced the option of market data for US stocks showing

# bid, ask and last sizes in shares rather than lots, TWS and Gateway

# display a dialog immediately after login notifying the user about

# this and requiring user input before allowing market data to be

# accessed. The user can request that the dialog not be shown again.

#

# It is recommended that the user should handle this dialog manually

# rather than using these settings, which are provided for situations

# where the user interface is not easily accessible, or where user

# settings are not preserved between sessions (eg some Docker images).

#

# - If this setting is set to 'accept', the dialog will be handled

# automatically and the option to not show it again will be

# selected.

#

# Note that in this case, the only way to allow the dialog to be

# displayed again is to manually enable the 'Bid, Ask and Last

# Size Display Update' message in the 'Messages' section of the TWS

# configuration dialog. So you should only use 'Accept' if you are

# sure you really don't want the dialog to be displayed again, or

# you have easy access to the user interface.

#

# - If set to 'defer', the dialog will be handled automatically (so

# that market data will start), but the option to not show it again

# will not be selected, and it will be shown again after the next

# login.

#

# - If set to 'ignore', the user has to deal with the dialog manually.

#

# The default value is 'ignore'.

#

# Note if set to 'accept' or 'defer', TWS also automatically sets

# the API settings checkbox labelled 'Send market data in lots for

# US stocks for dual-mode API clients'. IBC cannot prevent this.

# However you can change this immmediately by setting

# SendMarketDataInLotsForUSstocks (see below) to 'no' .

AcceptBidAskLastSizeDisplayUpdateNotification=accept

# This setting determines whether the API settings checkbox labelled

# 'Send market data in lots for US stocks for dual-mode API clients'

# is set or cleared. If set to 'yes', the checkbox is set. If set to

# 'no' the checkbox is cleared. If defaulted, the checkbox is

# unchanged.

SendMarketDataInLotsForUSstocks=

# Trusted API Client IPs

# ----------------------

#

# NB: THIS SETTING IS ONLY RELEVANT FOR THE GATEWAY, AND ONLY WHEN FIX=yes.

# In all other cases it is ignored.

#

# This is a list of IP addresses separated by commas. API clients with IP

# addresses in this list are able to connect to the API without Gateway

# generating the 'Incoming connection' popup.

#

# Note that 127.0.0.1 is always permitted to connect, so do not include it

# in this setting.

TrustedTwsApiClientIPs=

# Reset Order ID Sequence

# -----------------------

#

# The setting resets the order id sequence for orders submitted via the API, so

# that the next invocation of the `NextValidId` API callback will return the

# value 1. The reset occurs when TWS starts.

#

# Note that order ids are reset for all API clients, except those that have

# outstanding (ie incomplete) orders: their order id sequence carries on as

# before.

#

# Valid values are 'yes', 'true', 'false' and 'no'. The default is 'no'.

ResetOrderIdsAtStart=

# This setting specifies IBC's action when TWS displays the dialog asking for

# confirmation of a request to reset the API order id sequence.

#

# Note that the Gateway never displays this dialog, so this setting is ignored

# for a Gateway session.

#

# Valid values consist of two strings separated by a solidus '/'. The first

# value specifies the action to take when the order id reset request resulted

# from setting ResetOrderIdsAtStart=yes. The second specifies the action to

# take when the order id reset request is a result of the user clicking the

# 'Reset API order ID sequence' button in the API configuration. Each value

# must be one of the following:

#

# 'confirm'

# order ids will be reset

#

# 'reject'

# order ids will not be reset

#

# 'ignore'

# IBC will ignore the dialog. The user must take action.

#

# The default setting is ignore/ignore

# Examples:

#

# 'confirm/reject' - confirm order id reset only if ResetOrderIdsAtStart=yes

# and reject any user-initiated requests

#

# 'ignore/confirm' - user must decide what to do if ResetOrderIdsAtStart=yes

# and confirm user-initiated requests

#

# 'reject/ignore' - reject order id reset if ResetOrderIdsAtStart=yes but

# allow user to handle user-initiated requests

ConfirmOrderIdReset=

# =============================================================================

# 4. TWS Auto-Logoff, Auto-Restart and Cold Restart

# =============================================================================

#

# TWS and Gateway insist on being restarted every day. Two alternative

# automatic options are offered:

#

# - Auto-Logoff: at a specified time, TWS shuts down tidily, without

# restarting. The user must make their own arrangements for restarting

# as required.

#

# - Auto-Restart: at a specified time, TWS shuts down and then restarts

# without the user having to re-authenticate (in particulaar this avoids

# the need for second factor authentication after the initial login). Make

# sure to read the section on Auto-Restart limitations and Cold Restart

# below for important further information.

#

# The normal way to configure the time at which this happens is via the Lock

# and Exit section of the Configuration dialog. Once this time has been

# configured in this way, the setting persists until the user changes it again.

#

# However, there are situations where there is no user available to do this

# configuration, or where there is no persistent storage (for example some

# Docker images). In such cases, the auto-restart or auto-logoff time can be

# set whenever IBC starts with the settings below.

#

# The value, if specified, must be a time in HH:MM AM/PM format, for example

# 08:00 AM or 10:00 PM. Note that there must be a single space between the

# two parts of this value; also that midnight is "12:00 AM" and midday is

# "12:00 PM".

#

# If no value is specified for either setting, the currently configured

# settings will apply. If a value is supplied for one setting, the other

# setting is cleared. If values are supplied for both settings, only the

# auto-restart time is set, and the auto-logoff time is cleared.

#

# Note that for a normal TWS/Gateway installation with persistent storage

# (for example on a desktop computer) the value will be persisted as if the

# user had set it via the configuration dialog.

#

# If you use the "RESTART" command via the IBC command server, and IBC is

# running any version of the Gateway, note that this will set the Auto-Restart

# time in Gateway's configuration dialog to the time at which the restart

# actually happens (which may be up to a minute after the RESTART command is

# issued). To prevent future auto-restarts at this time, you must make sure you

# have set AutoLogoffTime or AutoRestartTime in this file to your desired value

# before running IBC again.

AutoLogoffTime=${AUTO_LOGOFF_TIME}

AutoRestartTime=${AUTO_RESTART_TIME}

# Auto-Restart limitations and Cold Restart

# -----------------------------------------

#

# If you choose to use auto-restart, you should take note of the considerations

# described at the link below. Note that where this information mentions

# 'manual authentication', closing down and restarting IBC will do the job

# (IBKR does not recognise the existence of IBC in its docuemntation). IBC

# calls this procedure a Cold Restart.

#

# https://www.ibkrguides.com/tws/usersguidebook/configuretws/auto_restart_info.htm?Highlight=auto-restart

#

# To assist in complying with the requirement to fully shut down TWS on

# Sundays, IBC can be configured with a Cold Restart Time, which is a time

# (specified in your local timeframe) that is after 01:00 US/Eastern. When

# this time is reached on Sundays, IBC tidily closes TWS, and the script then

# reloads IBC thus starting a new instance of TWS and initiating the usual full

# logon. There is thus no need to make any other arrangements for closing and

# restarting at the weekend. For a live account, the time chosen should be

# convenient for you to handle 2FA alerts.

#

# When deciding what time to use for Cold Restart, bear in mind that the offset

# between your timezone and US/Eastern may vary if transitions to and from

# Daylight Saving Time occur on different days. For example in the UK, this

# offset can vary between 4 hours and 6 hours, so in this case it would be

# reasonable to set the Cold Restart time to, for example, 07:05, which is

# always after 01:00 US/Eastern. However if you're not an early riser on

# Sundays you might prefer a more sociable time such as 13:00.

#

# To initiate Cold Restart on Sundays, set this value to <hh:mm>, this being a

# time in your local timezone that is after 01:00 US/Eastern:

ColdRestartTime=${TWS_COLD_RESTART}

# =============================================================================

# 5. TWS Tidy Closedown Time

# =============================================================================

#

# Specifies a time at which TWS will close down tidily, with no restart.

#

# This is similar to AutoLogoffTime, but can include a day-of-the-week, whereas

# AutoLogoffTime applies every day. So for example you could use ClosedownAt in

# conjunction with AutoRestartTime to keep TWS running during the week, and to

# shut down on Friday evenings after the markets close, without it running on

# Saturday as well.

#

# To tell IBC to tidily close TWS at a specified time every day, set this value

# to <hh:mm>, for example:

# ClosedownAt=22:00

#

# To tell IBC to tidily close TWS at a specified day and time each week, set

# this value to <dayOfWeek hh:mm>, for example:

# ClosedownAt=Friday 22:00

#

# Note that the day of the week must be specified using your

# default locale. Also note that Java will only accept

# characters encoded to ISO 8859-1 (Latin-1). This means that

# if the day name in your default locale uses any non-Latin-1

# characters you need to encode them using Unicode escapes

# (see http://java.sun.com/docs/books/jls/third_edition/html/lexical.html#3.3

# for details). For example, to tidily close TWS at 12:00 on

# Saturday where the default locale is Simplified Chinese,

# use the following:

# #ClosedownAt=\u661F\u671F\u516D 12:00

ClosedownAt=

# =============================================================================

# 6. Other TWS Settings

# =============================================================================

# Accept Incoming Connection

# --------------------------

#

# If set to 'accept', IBC automatically accepts incoming

# API connection dialogs. If set to 'reject', IBC

# automatically rejects incoming API connection dialogs. If

# set to 'manual', the user must decide whether to accept or reject

# incoming API connection dialogs. The default is 'manual'.

# NB: it is recommended to set this to 'reject', and to explicitly

# configure which IP addresses can connect to the API in TWS's API

# configuration page, as this is much more secure (in this case, no

# incoming API connection dialogs will occur for those IP addresses).

AcceptIncomingConnectionAction=${TWS_ACCEPT_INCOMING}

# Allow Blind Trading

# -------------------

#

# If you attempt to place an order for a contract for which

# you have no market data subscription, TWS displays a dialog

# to warn you against such blind trading.

#

# yes means the dialog is dismissed as though the user had

# clicked the 'Ok' button: this means that you accept

# the risk and want the order to be submitted.

#

# no means the dialog remains on display and must be

# handled by the user.

AllowBlindTrading=${ALLOW_BLIND_TRADING}

# Save Settings on a Schedule

# ---------------------------

#

# You can tell TWS to automatically save its settings on a schedule

# of your choosing. You can specify one or more specific times,

# like this:

#

# SaveTwsSettingsAt=HH:MM [ HH:MM]...

#

# for example:

# SaveTwsSettingsAt=08:00 12:30 17:30

#

# Or you can specify an interval at which settings are to be saved,

# optionally starting at a specific time and continuing until another

# time, like this:

#

#SaveTwsSettingsAt=Every n [{mins | hours}] [hh:mm] [hh:mm]

#

# where the first hh:mm is the start time and the second is the end

# time. If you don't specify the end time, settings are saved regularly

# from the start time till midnight. If you don't specify the start time.

# settings are saved regularly all day, beginning at 00:00. Note that

# settings will always be saved at the end time, even if that is not

# exactly one interval later than the previous time. If neither 'mins'

# nor 'hours' is specified, 'mins' is assumed. Examples:

#

# To save every 30 minutes all day starting at 00:00

#SaveTwsSettingsAt=Every 30

#SaveTwsSettingsAt=Every 30 mins

#

# To save every hour starting at 08:00 and ending at midnight

#SaveTwsSettingsAt=Every 1 hours 08:00

#SaveTwsSettingsAt=Every 1 hours 08:00 00:00

#

# To save every 90 minutes starting at 08:00 up to and including 17:43

#SaveTwsSettingsAt=Every 90 08:00 17:43

SaveTwsSettingsAt=${SAVE_TWS_SETTINGS}

# Confirm Crypto Currency Orders Automatically

# --------------------------------------------

#

# When you place an order for a cryptocurrency contract, a dialog is displayed

# asking you to confirm that you want to place the order, and notifying you

# that you are placing an order to trade cryptocurrency with Paxos, a New York

# limited trust company, and not at Interactive Brokers.

#

# transmit means that the order will be placed automatically, and the

# dialog will then be closed

#

# cancel means that the order will not be placed, and the dialog will

# then be closed

#

# manual means that IBC will take no action and the user must deal

# with the dialog

ConfirmCryptoCurrencyOrders=transmit

# =============================================================================

# 7. Settings Specific to Indian Versions of TWS

# =============================================================================

# Indian versions of TWS may display a password expiry

# notification dialog and a NSE Compliance dialog. These can be

# dismissed by setting the following to yes. By default the

# password expiry notice is not dismissed, but the NSE Compliance

# notice is dismissed.

# Warning: setting DismissPasswordExpiryWarning=yes will mean

# you will not be notified when your password is about to expire.

# You must then take other measures to ensure that your password

# is changed within the expiry period, otherwise IBC will

# not be able to login successfully.

DismissPasswordExpiryWarning=no

DismissNSEComplianceNotice=yes

# =============================================================================

# 8. IBC Command Server Settings

# =============================================================================

# Do NOT CHANGE THE FOLLOWING SETTINGS unless you

# intend to issue commands to IBC (for example

# using telnet). Note that these settings have nothing to

# do with running programs that use the TWS API.

# Command Server Port Number

# --------------------------

#

# The port number that IBC listens on for commands

# such as "STOP". DO NOT set this to the port number

# used for TWS API connections.

#

# The convention is to use 7462 for this port,

# but it must be set to a different value from any other

# IBC instance that might run at the same time.

#

# The default value is 0, which tells IBC not to start

# the command server

#CommandServerPort=7462

CommandServerPort=0

# Permitted Command Sources

# -------------------------

#

# A comma separated list of IP addresses, or host names,

# which are allowed addresses for sending commands to

# IBC. Commands can always be sent from the

# same host as IBC is running on.

ControlFrom=

# Address for Receiving Commands

# ------------------------------

#

# Specifies the IP address on which the Command Server

# is to listen. For a multi-homed host, this can be used

# to specify that connection requests are only to be

# accepted on the specified address. The default is to

# accept connection requests on all local addresses.

BindAddress=

# Command Prompt

# --------------

#

# The specified string is output by the server when

# the connection is first opened and after the completion

# of each command. This can be useful if sending commands

# using an interactive program such as telnet. The default

# is that no prompt is output.

# For example:

#

# CommandPrompt=>

CommandPrompt=

# Suppress Command Server Info Messages

# -------------------------------------

#

# Some commands can return intermediate information about

# their progress. This setting controls whether such

# information is sent. The default is that such information

# is not sent.

SuppressInfoMessages=yes

# =============================================================================

# 9. Diagnostic Settings

# =============================================================================

#

# IBC can log information about the structure of windows

# displayed by TWS. This information is useful when adding

# new features to IBC or when behaviour is not as expected.

#

# The logged information shows the hierarchical organisation

# of all the components of the window, and includes the

# current values of text boxes and labels.

#

# Note that this structure logging has a small performance

# impact, and depending on the settings can cause the logfile

# size to be significantly increased. It is therefore

# recommended that the LogStructureWhen setting be set to

# 'never' (the default) unless there is a specific reason

# that this information is needed.

# Scope of Structure Logging

# --------------------------

#

# The LogStructureScope setting indicates which windows are

# eligible for structure logging:

#

# - (default value) if set to 'known', only windows that

# IBC recognizes are eligible - these are windows that

# IBC has some interest in monitoring, usually to take

# some action on the user's behalf;

#

# - if set to 'unknown', only windows that IBC does not

# recognize are eligible. Most windows displayed by

# TWS fall into this category;

#

# - if set to 'untitled', only windows that IBC does not

# recognize and that have no title are eligible. These

# are usually message boxes or similar small windows,

#

# - if set to 'all', then every window displayed by TWS

# is eligible.

#

LogStructureScope=known

# When to Log Window Structure

# ----------------------------

#

# The LogStructureWhen setting specifies the circumstances

# when eligible TWS windows have their structure logged:

#

# - if set to 'open' or 'yes' or 'true', IBC logs the

# structure of an eligible window the first time it

# is encountered;

#

# - if set to 'openclose', the structure is logged every

# time an eligible window is opened or closed;

#

# - if set to 'activate', the structure is logged every

# time an eligible window is made active;

#

# - (default value) if set to 'never' or 'no' or 'false',

# structure information is never logged.

#

LogStructureWhen=never

# DEPRECATED SETTING

# ------------------

#

# LogComponents - THIS SETTING WILL BE REMOVED IN A FUTURE

# RELEASE

#

# If LogComponents is set to any value, this is equivalent

# to setting LogStructureWhen to that same value and

# LogStructureScope to 'all': the actual values of those

# settings are ignored. The default is that the values

# of LogStructureScope and LogStructureWhen are honoured.

#LogComponents=