diff --git a/README.md b/README.md index d876564..af859b1 100644 --- a/README.md +++ b/README.md @@ -4,21 +4,30 @@ ## What is it? -A docker image to run Interactive Brokers Gateway and TWS without any human interaction on a docker container +A docker image to run Interactive Brokers Gateway and TWS without any human +interaction on a docker container It includes: - [IB Gateway](https://www.interactivebrokers.com/en/index.php?f=16457) ([stable](https://www.interactivebrokers.com/en/trading/ibgateway-stable.php) or [latest](https://www.interactivebrokers.com/en/trading/ibgateway-latest.php)) - Trader Workstation [TWS](https://www.interactivebrokers.com/en/trading/tws-offline-installers.php) ([stable](https://www.interactivebrokers.com/en/trading/tws-offline-stable.php) or [latest](https://www.interactivebrokers.com/en/trading/tws-offline-latest.php)), from `10.26.1h` -- [IBC](https://github.com/IbcAlpha/IBC) - to control IB Gateway (simulates user input). -- [Xvfb](https://www.x.org/releases/X11R7.6/doc/man/man1/Xvfb.1.xhtml) - a X11 virtual framebuffer to run IB Gateway Application without graphics hardware. -- [x11vnc](https://wiki.archlinux.org/title/x11vnc) - a VNC server to interact with the IB Gateway user interface (optional, for development / maintenance purpose). +- [IBC](https://github.com/IbcAlpha/IBC) - to control TWS/IB Gateway (simulates user input). +- [Xvfb](https://www.x.org/releases/X11R7.6/doc/man/man1/Xvfb.1.xhtml) - a X11 + virtual framebuffer to run IB Gateway Application without graphics hardware. +- [x11vnc](https://wiki.archlinux.org/title/x11vnc) - a VNC server to interact + with the IB Gateway user interface (optional, for development / maintenance purpose). - xrdp/xfce enviroment for TWS. Build on top of [linuxserver/rdesktop](https://github.com/linuxserver/docker-rdesktop/). -- [socat](https://manpages.ubuntu.com/manpages/jammy/en/man1/socat.1.html) a tool to accept TCP connection from non-localhost and relay it to IB Gateway from localhost (IB Gateway restricts connections to container's 127.0.0.1 by default). -- Optional remote [SSH tunnel](https://manpages.ubuntu.com/manpages/jammy/en/man1/ssh.1.html) to provide secure connections for both IB Gateway and VNC. Only available for `10.19.2g-stable` and `10.25.1o-latest` or greater. +- [socat](https://manpages.ubuntu.com/manpages/jammy/en/man1/socat.1.html) a + tool to accept TCP connection from non-localhost and relay it to IB Gateway + from localhost (IB Gateway restricts connections to container's 127.0.0.1 by + default). +- Optional remote [SSH tunnel](https://manpages.ubuntu.com/manpages/jammy/en/man1/ssh.1.html) + to provide secure connections for both IB Gateway and VNC. Only available for + `10.19.2g-stable` and `10.25.1o-latest` or greater. - Support parallel execution of `live` and `paper` trading mode. - [Secrets](#credentials) support (latest `10.29.1e`, stable `10.19.2m` or greater) -- Works well together with [Jupyter Quant](https://github.com/gnzsnz/jupyter-quant) docker image. +- Works well together with [Jupyter Quant](https://github.com/gnzsnz/jupyter-quant) + docker image. ## Supported Tags @@ -26,10 +35,10 @@ Images are provided for [IB gateway][1] and [TWS][2]. With the following tags: | Image| Channel | IB Gateway Version | IBC Version | Docker Tags | | --- | -------- | ------------------- | ---------------- | ---------------------------------------------- | -| [ib-gateway][1] | `latest` | `10.29.1g` | `3.18.0` | `latest` `10.29` `10.29.1g` | -| [ib-gateway][1] |`stable` | `10.19.2n` | `3.18.0` | `stable` `10.19` `10.19.2n` | -| [tws-rdesktop][2] | `latest` | `10.29.1g` | `3.18.0` | `latest` `10.29` `10.29.1g` | -| [tws-rdesktop][2] |`stable` | `10.19.2n` | `3.18.0` | `stable` `10.19` `10.19.2n` | +| [ib-gateway][1] | `latest` | `10.29.1h` | `3.19.0` | `latest` `10.29` `10.29.1h` | +| [ib-gateway][1] |`stable` | `10.19.2n` | `3.19.0` | `stable` `10.19` `10.19.2n` | +| [tws-rdesktop][2] | `latest` | `10.29.1h` | `3.19.0` | `latest` `10.29` `10.29.1h` | +| [tws-rdesktop][2] |`stable` | `10.19.2n` | `3.19.0` | `stable` `10.19` `10.19.2n` | All tags are available in the container repository for [ib-gateway][1] and [tws-rdesktop][2]. IB Gateway and TWS share the same version numbers and tags. @@ -56,12 +65,14 @@ services: TWS_PASSWORD: ${TWS_PASSWORD} TRADING_MODE: ${TRADING_MODE:-paper} TWS_SETTINGS_PATH: ${TWS_SETTINGS_PATH:-} + TWS_ACCEPT_INCOMING: ${TWS_ACCEPT_INCOMING:-} READ_ONLY_API: ${READ_ONLY_API:-} VNC_SERVER_PASSWORD: ${VNC_SERVER_PASSWORD:-} TWOFA_TIMEOUT_ACTION: ${TWOFA_TIMEOUT_ACTION:-exit} BYPASS_WARNING: ${BYPASS_WARNING:-} AUTO_RESTART_TIME: ${AUTO_RESTART_TIME:-} AUTO_LOGOFF_TIME: ${AUTO_LOGOFF_TIME:-} + TWS_COLD_RESTART: ${TWS_COLD_RESTART:-} SAVE_TWS_SETTINGS: ${SAVE_TWS_SETTINGS:-} RELOGIN_AFTER_TWOFA_TIMEOUT: ${RELOGIN_AFTER_TWOFA_TIMEOUT:-no} TWOFA_EXIT_INTERVAL: ${TWOFA_EXIT_INTERVAL:-60} @@ -108,10 +119,12 @@ All environment variables are common between ibgateway and TWS image, unless spe | `BYPASS_WARNING` | Settings relate to the corresponding 'Precautions' checkboxes in the API section of the Global Configuration dialog. Accepted values `yes`, `no` if not set, the existing TWS/Gateway configuration is unchanged | **not defined** | | `AUTO_RESTART_TIME` | time to restart IB Gateway, does not require daily 2FA validation. format hh:mm AM/PM. See IBC [documentation](https://github.com/IbcAlpha/IBC/blob/master/userguide.md#ibc-user-guide) | **not defined** | | `AUTO_LOGOFF_TIME` | Auto-Logoff: at a specified time, TWS shuts down tidily, without restarting | **not defined** | +| `TWS_COLD_RESTART` | IBC >= 3.19 set this value to | **not defined** | | `SAVE_TWS_SETTINGS` | automatically save its settings on a schedule of your choosing. You can specify one or more specific times, ex `SaveTwsSettingsAt=08:00 12:30 17:30` | **not defined** | | `RELOGIN_AFTER_2FA_TIMEOUT` | support relogin after timeout. See IBC [documentation](https://github.com/IbcAlpha/IBC/blob/master/userguide.md#second-factor-authentication) | no | | `TIME_ZONE` | Support for timezone, see your TWS jts.ini file for [valid values](https://ibkrguides.com/tws/usersguidebook/configuretws/configgeneral.htm) on a [tz database](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones). This sets time zone for IB Gateway. If jts.ini exists it will not be set. if `TWS_SETTINGS_PATH` is set and stored in a volume, jts.ini will already exists so this will not be used. Examples `Europe/Paris`, `America/New_York`, `Asia/Tokyo` | "Etc/UTC" | | `TWS_SETTINGS_PATH` | Settings path used by IBC's parameter `--tws_settings_path`. Use with a volume to preserve settings in the volume. If `TRADING_MODE=both` this will be the prefix four your settings. ex `/config/tws_settings_live` and `/config/tws_settings_paper`. | | +| `TWS_ACCEPT_INCOMING` | See IBC documentation, possible values `accept`, `reject`, `manual` | `manual` | | `CUSTOM_CONFIG` | If set to `yes`, then `run.sh` will not generate config files using env variables. You should mount config files. Use with care and only if you know what you are doing. | NO | | `JAVA_HEAP_SIZE` | Set Java heap, default 768MB, TWS might need more. Proposed value 1024. Enter just the number, don't enter units, ex mb. See [Increase Memory Size for TWS](https://ibkrguides.com/tws/usersguidebook/priceriskanalytics/custommemory.htm) | **not defined** | | `SSH_TUNNEL` | If set to `yes` then `socat` won't start, instead a remote ssh tunnel is started. if set to `both` then `socat` AND remote ssh tunnel are started. SSH keys should be provided to container through ~/.ssh volume. | **not defined** | @@ -140,6 +153,7 @@ TWS_PASSWORD=myTwsPassword # tws #TWS_SETTINGS_PATH=/config/tws_settings TWS_SETTINGS_PATH= +TWS_ACCEPT_INCOMING= TRADING_MODE=paper READ_ONLY_API=no VNC_SERVER_PASSWORD=myVncPassword @@ -147,6 +161,7 @@ TWOFA_TIMEOUT_ACTION=restart BYPASS_WARNING= AUTO_RESTART_TIME=11:59 PM AUTO_LOGOFF_TIME= +TWS_COLD_RESTART= SAVE_TWS_SETTINGS= RELOGIN_AFTER_2FA_TIMEOUT=yes TIME_ZONE=Europe/Zurich @@ -455,6 +470,16 @@ secrets: ``` +In "dicussions" section you will find full examples for [ibgateway](https://github.com/gnzsnz/ib-gateway-docker/discussions/103) and [tws-rdesktop](https://github.com/gnzsnz/ib-gateway-docker/discussions/105) + +### RDP + +[tws-rdesktop][2] will create a new TLS certificate every time the container +starts. You can create your own certificate following this +[instructions](https://github.com/gnzsnz/ib-gateway-docker/discussions/104). +Once this steps are put in place the same TLS certificate will be used every +time, which will allow you to trust it in your RDP client. + ## Troubleshooting socat and ssh In case you experience problems with the API connection, you can restart the `socat` process @@ -534,7 +559,7 @@ https://github.com/gnzsnz/ib-gateway-docker/raw/gh-pages/ibgateway-releases/ibga `ibgateway-${IB_GATEWAY_VERSION}-standalone-linux-x64.sh`, where `{IB_GATEWAY_VERSION}` must match the version as configured on Dockerfile (first line) -1. Download IBC and name the file `IBCLinux-3.18.0.zip`, where +1. Download IBC and name the file `IBCLinux-3.19.0.zip`, where `{IBC_VERSION}` must match the version as configured on Dockerfile 1. Build and run: `docker-compose up --build` diff --git a/latest/Dockerfile b/latest/Dockerfile index 28ee841..4a58b74 100644 --- a/latest/Dockerfile +++ b/latest/Dockerfile @@ -8,9 +8,9 @@ # hadolint global ignore=DL3008 FROM ubuntu:22.04 as setup -ENV IB_GATEWAY_VERSION=10.29.1g +ENV IB_GATEWAY_VERSION=10.29.1h ENV IB_GATEWAY_RELEASE_CHANNEL=latest -ENV IBC_VERSION=3.18.0 +ENV IBC_VERSION=3.19.0 WORKDIR /tmp/setup @@ -31,7 +31,7 @@ RUN apt-get update -y && \ chmod a+x ./ibgateway-${IB_GATEWAY_VERSION}-standalone-linux-x64.sh && \ ./ibgateway-${IB_GATEWAY_VERSION}-standalone-linux-x64.sh -q -dir /root/Jts/ibgateway/${IB_GATEWAY_VERSION} &&\ # Install IBC - curl -sSOL https://github.com/IbcAlpha/IBC/releases/download/${IBC_VERSION}-Update.1/IBCLinux-${IBC_VERSION}.zip && \ + curl -sSOL https://github.com/IbcAlpha/IBC/releases/download/${IBC_VERSION}/IBCLinux-${IBC_VERSION}.zip && \ mkdir /root/ibc && \ unzip ./IBCLinux-${IBC_VERSION}.zip -d /root/ibc && \ chmod -R u+x /root/ibc/*.sh && \ @@ -49,7 +49,7 @@ COPY ./scripts /root/scripts FROM ubuntu:22.04 -ENV IB_GATEWAY_VERSION=10.29.1g +ENV IB_GATEWAY_VERSION=10.29.1h # IB Gateway user constants ARG USER_ID="${USER_ID:-1000}" ARG USER_GID="${USER_GID:-1000}" diff --git a/latest/Dockerfile.tws b/latest/Dockerfile.tws index d9b44c6..42ce401 100644 --- a/latest/Dockerfile.tws +++ b/latest/Dockerfile.tws @@ -7,7 +7,7 @@ # hadolint global ignore=DL3008 -ARG IB_VERSION=10.29.1g +ARG IB_VERSION=10.29.1h FROM ghcr.io/gnzsnz/ib-gateway:${IB_VERSION} as setup WORKDIR / @@ -18,9 +18,9 @@ WORKDIR / FROM lscr.io/linuxserver/rdesktop:ubuntu-xfce -ENV IB_GATEWAY_VERSION=10.29.1g +ENV IB_GATEWAY_VERSION=10.29.1h ENV IB_GATEWAY_RELEASE_CHANNEL=latest -ENV IBC_VERSION=3.18.0 +ENV IBC_VERSION=3.19.0 # IB Gateway user constants # IBC env vars diff --git a/latest/config/ibc/config.ini.tmpl b/latest/config/ibc/config.ini.tmpl index a48dcb7..c4f1f4b 100644 --- a/latest/config/ibc/config.ini.tmpl +++ b/latest/config/ibc/config.ini.tmpl @@ -1,925 +1,960 @@ -# 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= - - -# 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=/home/ibgateway/Jts - - -# Store settings on server -# ------------------------ -# -# 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). - -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=primary - - -# 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 and Auto-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. -# -# - Auto-Restart: at a specified time, TWS shuts down and then restarts -# without the user having to re-autheticate. -# -# 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 choose to auto-restart, you should take note of the considerations -# described at the link below. Note that where this information mentions -# 'manual authentication', restarting IBC will do the job (IBKR does not -# recognise the existence of IBC in its docuemntation). -# -# https://www.interactivebrokers.com/en/software/tws/twsguide.htm#usersguidebook/configuretws/auto_restart_info.htm -# -# If you use the "RESTART" command via the IBC command server, and IBC is -# running any version of the Gateway (or a version of TWS earlier than 1018), -# note that this will set the Auto-Restart time in Gateway/TWS'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 to your desired value before running IBC. NB: this does not -# apply to TWS from version 1018 onwards. - -AutoLogoffTime=${AUTO_LOGOFF_TIME} - -AutoRestartTime=${AUTO_RESTART_TIME} - - -# ============================================================================= -# 5. TWS Tidy Closedown Time -# ============================================================================= -# -# Specifies a time at which TWS will close down tidily, with no restart. -# -# There is little reason to use this setting. It is similar to AutoLogoffTime, -# but can include a day-of-the-week, whereas AutoLogoffTime and AutoRestartTime -# apply every day. So for example you could use ClosedownAt in conjunction with -# AutoRestartTime to shut down TWS 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 , for example: -# ClosedownAt=22:00 -# -# To tell IBC to tidily close TWS at a specified day and time -# each week, set this value to , 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=reject - - -# 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=no - - -# 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= +# 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= + + +# 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=primary + + +# 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 , 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 , for example: +# ClosedownAt=22:00 +# +# To tell IBC to tidily close TWS at a specified day and time each week, set +# this value to , 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=no + + +# 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=