AlgoTraderAlgoTrader Documentation

Chapter 22. Adapters

22.1. Fix Interface
22.1.1. FIX configuration
22.1.2. FIX logging
22.1.3. FIX message persistence
22.1.4. FIX Drop-copy support
22.2. Crypto Exchange interfaces
22.2.1. Custom currency mapping
22.2.2. Crypto-Order Constraints
22.2.3. Supported Crypto-Order Types
22.3. Adapter rate-limiting
22.4. Session life-cycle events
22.5. Automatic order reconciliation after re-connect
22.6. Bloomberg
22.7. Currenex
22.8. DukasCopy
22.9. Exante (XNT)
22.10. EzeSoft / Real Tick
22.11. Fortex
22.12. FXCM
22.13. IB Native Interface
22.13.1. IB Market Data Subscriptions
22.13.2. Delayed IB Market Data
22.13.3. IB Generic Tick Events
22.14. IB Fix Interface
22.15. Intrinio Dividend feed
22.16. JP Morgan
22.17. LMAX
22.18. Nexus Prime
22.19. One Zero
22.20. PrimeXM
22.21. Quandl
22.22. QuantHouse
22.23. SocGen
22.24. Trading Technologies (TT)
22.25. UBS
22.26. B2C2
22.26.1. B2C2 Order Constraints
22.27. Binance
22.27.1. Binance Order Constraints
22.27.2. Binance Account Management
22.28. Bitfinex
22.28.1. Bitfinex Order Constraints
22.28.2. Bitfinex Account Management
22.29. Bitflyer
22.29.1. Bitflyer Order Constraints
22.29.2. Bitflyer Account Management
22.30. BitMEX
22.30.1. BitMex Order Constraints
22.30.2. BitMex Account Management
22.31. Bitstamp
22.31.1. Bitstamp Order Constraints
22.31.2. Bitstamp Account Management
22.32. CoinAPI
22.33. Coinbase Pro
22.33.1. CoinBase Pro Order Constraints
22.33.2. Coinbase Pro Account Management
22.34. Coinigy
22.34.1. Setup Instructions
22.34.2. Coinigy Order Constraints
22.34.3. Coinigy Account Management
22.35. CoinMarketCap
22.36. Tilde
22.36.1. Tilde Order Constraints

The following sections give a detailed overview of the different adapters available for AlgoTrader.

AlgoTrader uses QuickFix/J for it's Fix connections and currently supports FIX 4.2 and 4.4. Because FIX messages are not compatible between different version, the two distinct services Fix42OrderService and Fix44OrderService exist. Incoming messages are handled by their corresponding Fix42MessageHandler and Fix44MessageHandler.

To configure a Fix trading connection the following steps have to be taken care of:

  • Add the corresponding fix trading profile to the VM argument spring.profiles.active (e.g. cNXFix):

    -Dspring.profiles.active=live,pooledDataSource,cNXFix,embeddedBroker,html5,InfluxDB 
  • Add the fix session to /algotrader/bootstrap/conf/src/main/resources/fix.cfg (Use the fix-template.cfg file as basis - do not delete the default section):

    [session]
    SessionQualifier=CNXT
    BeginString=FIX.4.4
    SenderCompID=xxx
    TargetCompID=CNX
    SocketConnectHost=dret-fix-ssl.currenex.com
    SocketConnectPort=443
    SocketUseSSL=Y
    Username=xxx
    Password=xxx
    ValidateIncomingMessage=N
    ResetOnLogon=Y
    Inactive=Y
  • Make sure there is an entry in the MySQL account table where the column ORDER_SERVICE_TYPE matches the type of the fix interface (e.g. CNX_FIX), the column SESSION_QUALIFIER matches the SessionQualifier specified in the file fix.cfg and the ACTIVE column is set to 1.

If market data is also received through a Fix interface the following items need to be added as well:

  • Add the corresponding fix market data profile to the VM argument spring.profiles.active (e.g. cNXFix):

    -Dspring.profiles.active=live,pooledDataSource,cNXMarketData,embeddedBroker,html5,InfluxDB 
  • Add the fix session to /algotrader/bootstrap/conf/fix.cfg (an example file fix-template.cfg is provided in the same directory):

    [session]
    SessionQualifier=CNXMD
    BeginString=FIX.4.4
    SenderCompID=xxx
    TargetCompID=CNX
    SocketConnectHost=dret-fix-ssl.currenex.com
    SocketConnectPort=443
    SocketUseSSL=Y
    Username=xxx
    Password=xxx
    ValidateIncomingMessage=N
    ResetOnLogon=Y
    Inactive=Y
  • When making subscriptions add the AdapterType corresponding to the Fix interface (e.g. CNX)

Important

Please make sure to have the setting Inactive=Y in both trading and market-data sections. Without this setting the fix session will be initialized before the remaining system has been fully initialized and might cause either trading or market data to malfunction.

For further information regarding QuickFix/J configuration please visit the QuickFix/J documentation

Per default Fix interfaces uses the following items to identify a particular instrument:

Options

Exchange IB_CODE

Option TRANSACTION_CURRENCY

SecurityFamily SYMBOL_ROOT

Option STRIKE

Option TYPE

Option EXPIRATION

Option CONTRACT_SIZE

Future

Future TRANSACTION_CURRENCY

Exchange IB_CODE

SecurityFamily SYMBOL_ROOT

Future EXPIRATION

Future CONTRACT_SIZE

Forex

Forex TRANSACTION_CURRENCY

Exchange IB_CODE

Forex BASE_CURRENCY

Stock

Stock TRANSACTION_CURRENCY

Exchange IB_CODE

Stock SYMBOL

Fund

Fund TRANSACTION_CURRENCY

Exchange IB_CODE

Index SYMBOL

In addition to stock QuickFix/J configuration capabilities AlgoTrader provides a custom option to select a logging back-end out of those supported by QuickFix/J per individual session through custom Logimpl parameter.

Supported parameter values are:

file (default)

Log to QuickFix/J standard file logger.

The file option (which is the default) will create fix log files in the log sub-directory of the directory where AlgoTrader was started. One log file will be created for messages and one for QuickFix/J internal events. The name of both files contains the full FIX session name. To use the file logger the following settings are required within the fix.cfg file:

FileLogPath=log
FileLogHeartbeats=N
FileIncludeMilliseconds=Y
FileIncludeTimeStampForMessages=Y
none

Disable logging. No FIX session events or messages will be logged.

The none option might be especially useful for volume intensive market data sessions where persistent message log could be unnecessary or even excessive. Custom Fix logging options can be configured as follows:

[session]
SessionQualifier=FIXMD
BeginString=FIX.4.4
...
LogImpl=none
screen

Logs all QuickFix/J events and messages to the standard console logger.

slf4j

Log to the Simple Logging Facade for Java (SLF4J). Log entries will be committed to the logging back-end configured by SLF4J.

The slf4j allows log messages to be re-directed to the Log4J Chapter 29, Logging system which is highly configurable. Here is an example:

[session]
SessionQualifier=FIXMD
BeginString=FIX.4.4
...
LogImpl=slf4j

Log messages are logged to the following 4 loggers per default:

  • quickfixj.event for regular events (e.g. sessions logging on)

  • quickfixj.errorEvent for error events (e.g. connection issues)

  • quickfixj.msg.incoming for incoming messages

  • quickfixj.msg.outgoing for outgoing messages

A typical log statement would then look like this

2019-04-23 23:23:34,352 INFO  [NioProcessor-4] [quickfixj.event] FIX.4.4:AT->TT: Created session: FIX.4.4:AT->TT

It is also possible to customize the log categories per session for added flexibility. It is for example possible to log FIX messages from different FIX sessions into separate Files. The following example has two sessions, one for market data (FIXMD) and one for trading (FIXORD).

[session]
SessionQualifier=FIXMD
BeginString=FIX.4.4
...
LogImpl=slf4j
SLF4JLogIncomingMessageCategory=quickfixj.msg.md.incoming
SLF4JLogOutgoingMessageCategory=quickfixj.msg.md.outgoing

[session]
SessionQualifier=FIXORD
BeginString=FIX.4.4
...
LogImpl=slf4j
SLF4JLogIncomingMessageCategory=quickfixj.msg.ord.incoming
SLF4JLogOutgoingMessageCategory=quickfixj.msg.ord.outgoing

By adding the following sections to the log4j2.xml separate log files for market data (fix-md.log) and trading (fix-ord.log) will be created.

...
<RollingFile
	name="FixMD"
	fileName="log/fix-md.log"
	filePattern="log/fix-md-%d{MM-dd-yyyy}-%i.log.gz">
	<PatternLayout pattern="%d %m %n"/>
	<Policies>
		<TimeBasedTriggeringPolicy />
		<SizeBasedTriggeringPolicy size="250 MB"/>
	</Policies>
</RollingFile>
<RollingFile
	name="FixORD"
	fileName="log/fix-ord.log"
	filePattern="log/fix-ord-%d{MM-dd-yyyy}-%i.log.gz">
	<PatternLayout pattern="%d %m %n"/>
	<Policies>
		<TimeBasedTriggeringPolicy />
		<SizeBasedTriggeringPolicy size="250 MB"/>
	</Policies>
</RollingFile>
...
<logger name="quickfixj.msg.md" level="info" additivity="false">
	<AppenderRef ref="FixMD"/>
</logger>
<logger name="quickfixj.msg.ord" level="info" additivity="false">
	<AppenderRef ref="FixORD"/>
</logger> 

For both files a daily rolling file scheme is used where at the end of a day all contents of each file will be zipped (e.g. fix-md-12-08-2019.log.gz). In addition if the file size reaches 250MB a new zip file will be created as well.

AlgoTrader provides several crypto currency exchange adapters which are based on REST, Web Socket or REST.

When trading crypto currencies it is recommended to update the following properties inside conf.properties. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

# the currency all portfolio balances will be calculated in
misc.portfolioBaseCurrency=BTC

# the number of digits all portfolio balances will be displayed with
misc.portfolioDigits=8

This will cause all balances to be displayed in BTC with a precision of 8 digits

Most exchange APIs have rate-limits. It means that there's a limited amount of requests that can be made by single user in given timespan. Exceeding the rate-limit may cause user requests to be temporarily blocked. In order to ensure stable connectivity with the exchange by, AlgoTrader outgoing HTTP calls are limited. Request rate is configurable by properties.

xyz.rateLimits = 100/1s,1000/1m

The above example means that adapter xyz allows 100 requests per second, but no more than 1000 requests per minute.

Rate-limit property should be specified in the following format:

[number of requests in timespan]/[duration][time unit]

Valid time units are:

Rate-limit examples:

All trading interface adapters generate session events, which enable the server engine as well as individual strategies to listen for and react to session events such as session being fully established or temporary loss of connectivity.

@Override

public void onSessionEvent(final SessionEventVO event) {
    switch (event.getState()) {
        case CONNECTED:
            // session connected but not yet authenticated
            break;
        case LOGGED_ON:
            // session connected and authenticated
            break;
        case DISCONNECTED:
            // session disconnected
            break;
    }
}

Specially when connecting to a slow Market Data adapters it might be necessary to listing to those session events and only subscribe for securities once the session is in the LOGGED_ON state.

Most crypto exchanges provide REST and/or Web Socket APIs only. Unfortunately these protocols are stateless. So In case the AlgoTrader server gets disconnected from an exchange for some time or the AlgoTrader server is restarted, an active order may get cancelled or executed in the meantime.

For this purpose AlgoTrader provides an automatic order reconciliation feature. An automated order reconciliation process is invoked once the AlgoTrader server reconnects to synchronize the orders statuses between the exchange on the AlgoTrader server.

In case of trading adapters that use FIX interface, order reconciliation is provided automatically by the exchange FIX server. This is done using the Resend FIX protocol message. Unfortunately the Resend message is not supported by the Coinbase Pro exchange FIX server.

In case you want to turn off the AlgoTrader provided order reconciliation, add noOrderReconciliation into active Spring profiles list when starting the AlgoTrader server.

Please check the corresponding adapter section to see if the automatic order reconciliation is implemented for your exchange.

If your Strategy relies on reconciliation process and required information about whether it is currently running or not, it is possible to subscribe for ReconciliationEvents. After subscription, your Strategy will be notified about reconciliation process being started and finished. Code example below shows how to subscribe to such events from your StrategyService class:



                @Override
                protected void onReconciliationEvent(final ReconciliationEventVO event) {
                // place code that reacts on reconciliation events here
                }
            

One example use case that you can implement with such reconciliation events is state recovery processing after AlgoTrader was stopped and started (it is recommended to wait until reconciliation is finished and all order statuses are updated before starting your regular Strategy process)

The Bloomberg interface supports Market Data, Historical Data as well as Reference Data.

The Bloomberg interface provides both synchronous connections and asynchronous connections. Asynchronous connections are generally used for live market data whereas synchronous connections are used for retrieval of historical data as well as retrieval of reference data.

If market data is received through the Bloomberg interface the following items need to be added:

Bloomberg uses the BBGID field of the Security table to identify instruments.

For further details on the Bloomberg interface please visit the Bloomberg Open API

The main features of the Currenex platform are

The Currenex implementation of the FIX/4.4 protocol has some peculiarities

Currenex uses the columns Forex BASE_CURRENCY and SecurityFamily CURRENCY to identify an instrument.

AlgoTrader supports both trading and market data connectivity via broker DukasCopy.

Since the DukasCopy FIX protocol implementation does not follow the FIX standard very closely, we at the moment don't support order modifications via Dukascopy trading adapter. Modification of an open order can be achieved by cancelling and submitting a new order.

Note that Dukascopy does not support Stop Limit orders.

Exante brokerage adapter, FIX 4.4 protocol based.

The adapter supports market data and trading.

Exante provides its customers with a demo platform with the same characteristics as the live platform. Market data in the Demo platform is delayed by at least 30 minutes. Live platform requires setting up an SSH tunnel, details for which are available at their website.

Reference data download is currently not supported by AlgoTrader. Individual securities may be enabled on AlgoTrader side for use with Exante by setting their XNTID database field with the correct Exante instrument code.

EzeSoft / RealTick provides connectivity to about 30 institutional and 10 retail brokers.

The EzeSoft / RealTick Fix interface currently supports only Order Processing.

The Fix Implementation of EzeSoft / RealTick is well conforming with the Fix Standard no customizations had to be made.

The Fix interface uses standard Fix instrument definitions mentioned at the end of section Section 22.1, “Fix Interface”.

Fortex uses almost vanilla Fix/4.4 protocol with very few customizations. It supports FX only.

Fortex uses the columns Forex BASE_CURRENCY and SecurityFamily CURRENCY to identify an instrument.

FXCM interface FIX/4.4 protocol does not deviate much from the standard but has some peculiarities about the way FIX sessions are established

FXCM uses the columns Forex BASE_CURRENCY and SecurityFamily CURRENCY to identify an instrument.

The native IB Interface connects to the local Trader Workstation (TWS) or IB Gateway instance and uses methods supplied by the IB client. The interface is fully capable of handling IB's Financial Advisor functionality like Sub Accounts, Account Groups and Allocation Profiles.

The IB interface supports Market Data, Historical Data, Order Processing, Retrieval of account information as well as Reference Data.

To configure an IB connection the following steps have to be taken care of:

  • Add the profile iBNative to the VM argument spring.profiles.active:

    -Dspring.profiles.active=live,pooledDataSource,iBNative,embeddedBroker,html5,InfluxDB 
  • Make sure there is an entry in the account database where the column ORDER_SERVICE_TYPE is set to IB_NATIVE) .

If market data is also received through the IB interface the following items need to be added as well:

  • Add the profile iBMarketData to the VM argument spring.profiles.active:

    -Dspring.profiles.active=live,pooledDataSource,iBMarketData,embeddedBroker,html5,InfluxDB 
  • When making subscriptions add the AdapterType IB

The IB interface has the following options to identify a particular instrument:

  • CONID specified in the security table

  • Use instrument symbols and additional data depending on the instrument type:

    Options

    Exchange IB_CODE

    SecurityFamily CURRENCY

    SecurityFamily SYMBOL_ROOT

    Option STRIKE

    Option TYPE

    Option EXPIRATION

    SecurityFamily CONTRACT_SIZE

    Future

    SecurityFamily CURRENCY

    Exchange IB_CODE

    SecurityFamily SYMBOL_ROOT

    Future EXPIRATION

    SecurityFamily CONTRACT_SIZE

    Stock

    SecurityFamily CURRENCY

    Exchange IB_CODE

    Stock SYMBOL

    Index

    SecurityFamily CURRENCY

    Exchange IB_CODE

    Index SYMBOL

    Combination

    SecurityFamily CURRENCY

    Exchange IB_CODE

    SecurityFamily BASE_SYMBOL

    Security CONID of each Component

    Component QUANTITY

In addition the following items apply to the IB Native interface

  • The IB Native interface uses the RT_VOLUME events to process incoming trade events

  • The IB Native interface propagates daily OPEN and CLOSE prices to strategies in case the following property inside conf-ib.properties is enabled. Alternatively the properties can be changed via Section 2.3, “VM Arguments”

    # enables emission of generic open and close ticks
    ib.emitOpenClose = true
  • The IB Native interface propagates VWAP prices to strategies in case the following property inside conf-ib.properties is enabled. Alternatively the properties can be changed via Section 2.3, “VM Arguments”

    # enables emission of generic VWAP ticks
    ib.emitVWAP = true
  • The IB Native interface expects orders to be sent with their order ids in ascending order. The Class IBOrderIdSynchronizer is responsible to make sure order ids are actually in ascending order. In case an order id is skipped the IBOrderIdSynchronizer will wait for up to maxOrderSyncTime milliseconds for the order with the correct order id to arrive.

  • The IB Native interface supports trading of tradable / non-synthetic combinations by placing BAG orders through the IB interface.

  • The IB Native interface reports volBid, volAsk and vol in lots of 100 contracts for US equities. Please see the following page for further details on handling of Odd Lot Orders

For further details on the IB native interface please visit the IB API Reference Guide

In the traditional financial sector (excluding cryptocurrencies) market data is not free and requires market data subscriptions.

IB provides free 15min delayed data. It is possible to obtain this free 15min delayed data when logged in via a trial account. This however is available only when logged in via Trader Workstation (TWS). Please see Section 22.13.2, “Delayed IB Market Data”

Market data can be accessed both through the IB paper trading account as well as the live trading account.

Note

  • The paper trading account has one single username assigned to it. The live trading account can have multiple user names.

  • For each username (live account & paper trading account) only one session can exist at the same time. If you login with the same username on a different machine the other session will get logged out.

  • If the live account username (that is sharing its market data subscription with the paper trading account) is currently logged in, the paper trading account doesn't get market data until the live account is again logged out.

  • If a client wants to login to the live trading account at the same time that AlgoTrader is connected to the paper trading account, he has to create a second username under the live account and purchase additional market data subscriptions for that username.

To get a market data subscriptions one has to login to the IB account management with the live trading account. Then follow these steps:

  1. Select Settings / User Settings in the menu on the left. Then select Market Data Subscriptions on the right

  2. Then click on the icon next to Current Subscriptions

  3. Then select the region (e.g. North America)

  4. On the next screen individual market data subscriptions can be selected




Typical market data subscriptions are:

  • IDEAL FX: free Forex market data

  • NASDAQ (Network C/UTP): live market data for NASDAQ listed equities

  • NYSE (Network A/CTA): live market data for NYSE listed equities

  • US Securities Snapshot and Futures Value Bundle: live market data for US futures and snapshot data for US equities (AT cannot process snapshot data, so in addition NASDAQ and NYSE has to be subscribed as well)


To use these market data subscriptions through the paper trading account follow these steps:

  1. Select Settings / User Settings in the menu on the left. Then select Paper Trading Account on the right

  2. Then select Yes next to Share real-time market data subscriptions with paper trading account

  3. Then Select the username whose market data you want to share. This will share the market data subscriptions of the live account with the paper trading account.



Note

In case no market data arrives through the IB interface it is usually best to login to InteractiveBrokers Trader Workstation (TWS) as there are usually warning messages that indicate what might be the issue

In addition to Section 17.6, “Generic Events” IB adapter also provides Generic Ticks (class IBGenericTickVO), unlike GenericEvents, IBGenericTicks are IB specific. A Generic Tick Event represents additional price information on a particular instrument made available by market data provider (e.g. open price, close price, vwap price).

As IBGenericTickVO is a subclass of MarketDataEventVO a strategy will automatically get Generic Tick Events delivered when it has subscribed to the corresponding instrument.

A Generic Tick has a TickType which can be one of OPEN, HIGH, LOW, CLOSE, SETTLEMENT, OPEN_INTEREST, IMBALANCE or VWAP. A Generic Tick Event can hold either a BigDecimal, Double or Integer value.

The IB Fix Interface provides the same Order Management features as the IB Native Interface. However Market Data is not available through this interface.

The interface is fully capable of handling IB's Financial Advisor functionality like Sub Accounts, Account Groups and Allocation Profiles.

For further details on the IB Fix interface please visit the IB FIX/CTCI Users' Guide

The IB Fix interface uses standard Fix instrument definitions mentioned at the end of section Section 22.1, “Fix Interface”.

Intrinio provides different types of market data. As of now AlgoTrader only supports the dividends data feed.

It can be enabled by activating the profile iNTRDividendGenericEvents and by setting the following property in conf-intr.properties:

intr.apiKey = XXXX

The JP Morgan Fix interface supports Order Processing only.

As the JP Morgan Fix Implementation is well conforming with the Fix Standard no customizations had to be made

The JP Morgan Fix interface uses standard Fix instrument definitions mentioned at the end of section Section 22.1, “Fix Interface”.

Supports only a limited number of securities, mainly Forex

LMAX implementation of the FIX/4.4 protocol has some peculiarities

LMAX uses the column LMAXID of the security table to identify an instrument

Nexus Prime is a MetaTrader MT4 FIX interface provided by IS Risk Analytics. The Nexus Prime interface uses Fix 4.4 and it supports FX only. Due to the underlying MetaTrader MT4 a few limitations apply.

  • Market Data subscriptions cannot be cancelled

  • Orders cannot be modified, instead one needs to cancel the current order first and then resend a new one.

  • Buy limit orders need to be placed below the market price. Sell limit orders need to be placed above the market price

  • Buy stop orders need to be placed above the market price. Sell stop orders need to be placed below the market price.

  • Minimum trade size allowed on most currency pairs is .01 lots which is 1000 notional

Nexus Prime uses the columns Forex BASE_CURRENCY and SecurityFamily CURRENCY to identify an instrument.

One Zero provides connectivity to a number of exchanges. There are differences in supported symbols between the exchanges. Pair symbols can be mapped to the expected form using currency-code-mappings.csv file.

OneZero Financial Systems LLC develops low-latency software systems. The Company provides traders, managers, and brokers with software tools to identify market opportunities, automate their trading, and control risk.

One Zero implements the FIX/4.4 protocol and requires to use TLSv1:

EnabledProtocols=TLSv1

The PrimeXM FIX/4.4 interface implementation follows the Fix Standard closely, but uses MassQuote messages for conveying the market data. Each MassQuote message has to be acknowledged by the FIX client.

Only Forex instruments are supported by the PrimeXM Fix Interface.

Market, limit and stop orders are supported but only with time in force IOC (Instant or Cancel) or FOK (Fill or Kill).

Order modifications are not supported.

Quandl is a public service that provides a wide range of financial, economic and alternative data. It is mostly end of day data but also some intra-day (e.g. hourly) data. To find out if they have what you are looking for, check their data products page. AlgoTrader allows downloading historical data from Quandl. For more information about Quandl please have a look at the Quandl Docs/Help.

Data on Quandl is divided into databases. Each database contains multiple datasets. For instance EOD database contains end-of-day data for all publicly-traded US stocks. Each database/dataset pair is uniquely identified by database_code/dataset_code pair. For instance EOD/AAPL is the globally unique code for the AAPL stock dataset within the EOD database. The Quandl database browser can be used to find suitable databases for desired instrument type, region and data type.

The QdlHistoricalDataService is integrated with the AlgoTrader Historical Data Download and needs to be enabled by specifying the qdlHistoricalData Spring profile (see section Section 18.3, “Historical Data Download”). The QdlHistoricalDataService transforms retrieved Quandl data into AlgoTrader bars. Transformation rules between the Quandl data format and AlgoTrader Bar format are defined in the file quandl.yml. By default the file quandl.yml already contains the transformation rules for most commonly used Quandl databases. Additional transformation rules can be added to the file as needed:

EOD: 1
    barSize: DAY_1 2
    columnMapping: 3
        dateTime: Date
        open: Open
        high: High
        low: Low
        close: Close
        vol: Volume

1

The Quandl database code

2

barSize supported by the Quandl database (e.g. DAY_1 or MIN_1)

3

Column mappings between Quandl data fields and AlgoTrader BarVO fields

The relevant properties for the Quandl adapter are defined inside the file conf-qdl.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
qdl.apiKey = ATVxxxxxxxxxxxxx

To use the QdlHistoricalDataService please replace the property qdl.apiKey with the API Key that can be retrieved through the Quandl Account Settings.

In terms of historical data download a mapping between the Quandl database and the Security entity is defined by the quandl_database field in the security table. Similarly a mapping between the Quandl dataset and the Security entity is defined by the quandl_dataset field in the security table. AlgoTrader sample data files (samples/db/mysql/mysql-data.sql and samples/db/mysql/h2-data.sql) already contain quandl_database/quandl_dataset values for all sample security families and most sample securities.

The QuantHouse adapter is based on the QuantHouse ultra low latency market data feed QuantFEED. The QuantHouse adapter supports live Market Data.

If market data is received through the QuantHouse interface the following items need to be added:

QuantHouse uses the Exchange MIC and Security SYMBOL fields to identify instruments.

For further details on the QuantHouse interface please contact QuantHouse

The SocGen FIX/4.2 interface supports Order Processing only.

The SocGen Fix Implementation follows the Fix Standard closely, but some minor customizations according to the 'SocGen FIX Rules of Engagement' had to be made. Additionally exchange specific restrictions rules defining the allowed order type / TIF combinations were added.

Only Future instrument orders are supported by the SocGen Fix Interface.

Supports a wide range of future and option contracts tradable at multiple venues / exchanges.

The relevant properties for TT adapter are defined inside the file conf-tt.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"market request user name"}
tt.username = xxx

The tt.username property defines the username on the Trading Technologies side

The UBS Fix interface supports Order Processing for futures and options only.

As the UBS Fix Implementation is well conforming with the Fix Standard no customizations had to be made

The UBS Fix interface uses standard Fix instrument definitions mentioned at the end of section Section 22.1, “Fix Interface”.

B2C2 is a cryptocurrency market maker/OTC trading services provider.

The B2C2 interface supports Market Data, Order Processing, Request for Quote (RFQ) process, Retrieval of account information as well as Reference Data. B2C2 only allows one RFQ to be in effect at a time and a second one invalidates the previous.

The relevant properties for the B2C2 adapter are defined inside the file conf-b2c2.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"Long","label":"The id of the account to be used in conjunction with the b2c2 RFQ (Request For Quote) process."}
b2c2.quoteAccountId = 207

#{"type":"String","label":"Price levels to subscribe per currency - coma separated key=value pairs"}
b2c2.priceLevels = BTC=10,ETH=50

B2C2 does not have an order book but will stream prices to you at the requested level.

The price levels define the quantity (in base currency) you wish to receive streamed prices for.

Above a certain value (to be agreed with B2C2), you will not be able to execute orders directly but need to go through the RFQ process.

In order to populate the database with B2C2 Accounts, Exchanges, Security Families and Securities run the ReferenceDataStarter with b2C2ReferenceData spring profile enabled and program argument: all. For further details please visit Chapter 19, Reference Data.

Note that time in force (TIF) for B2C2 Previously Indicated orders has to be Immediate or Cancel (IOC) or Fill or Kill (FOK), and for non RFQ orders only FOK is supported.

Binance is a cryptocurrency exchange. Please see the API reference page for the technical details.

Binance provides Java library for interacting with Binance API. It supports REST requests to endpoint providing orders functionality, account data and reference data. Support for market data is done using WebSocket API.

The relevant properties for the Binance adapter are defined inside the file conf-bnc.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
bnc.apiKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"API Secret"}
bnc.apiSecret = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
bnc.importAllPairs = true           

A Binance account is necessary in order to use Binance adapter. Unique apiKey and apiSecret settings must be set to the actual values (either in the properties file or by setting a VM argument)

Note

Binance is very time sensitive , i.e. if your computer is ahead of the Binance system clock, the API might reject your orders with an exception similar to

com.binance.api.client.exception.BinanceApiException: Timestamp for this request was 1000ms ahead of the

server's time

To prevent these issues, we suggest synchronizing your system clock with an internet reference time using e.g. this time sync tool.

Bitfinex is a cryptocurrency exchange. The Bitfinex adapter provides order execution, market data, reference data and account data functionality. Please see the Bitfinex API reference page for technical details about the supported features.

The relevant properties for the Bitfinex adapter are defined inside the file conf-bfx.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
bfx.apiKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"API Secret"}
bfx.apiSecret = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
bfx.rateLimits = 40/1m

#{"type":"Integer","label":"API-level constant'}
bfx.scale = 5

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
bfx.importAllPairs = true

A Bitfinex account is necessary in order to use Bitfinex adapter. Unique apiKey and apiSecret settings must be set to the actual values (either in the properties file or by setting a VM argument)

Bitflyer is a cryptocurrency exchange. The Bitflyer adapter supports order execution, market data, reference data and account data functionality. Please see the Bitflyer API reference page for technical details.

Note

At this point (April 2018), Bitflyer does not yet support cross-border trading, so trading vs. USD is only possible with a US account.

The relevant properties for the Bitflyer adapter are defined inside the file conf-bfl.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
bfl.apiKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"API Secret"}
bfl.apiSecret = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"PubNub Subscribe Key"}
bfl.pubNubSubscribeKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
bfl.rateLimits = 40/1m

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
bfl.importAllPairs = true           

A Bitflyer account is necessary in order to use Bitflyer adapter. Unique apiKey, apiSecret as well as market data subscription key settings must be set to the actual values (either in the properties file or by setting a VM argument)

BitMEX is a cryptocurrency futures exchange. The BitMEX adapter provides order execution, market data, reference data and account data functionality through REST and WebSocket API. Please see the API reference page for technical details about the supported features.

The relevant properties for the BitMEX adapter are defined inside the file conf-bmx.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
bmx.apiKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"API Secret"}
bmx.apiSecret = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
bmx.rateLimits = 60/1m

#{"type":"Integer","label":"API-level constant'}
bmx.balanceScale = 8

A BitMEX account is necessary in order to use the BitMEX adapter. Unique apiKey and apiSecret settings must be set to the actual values (either in the properties file or by setting a VM argument)


BitMEX supports trading of the perpetual contract and of the futures.

The minimum quantity for all contracts is 1 contract (lot size = 1). Only integer number of contracts are allowed. The QUANTITY_SCALE for all securities is set to 0 and must not be changed.

Placing an order to buy one XBTUSD means buying the amount of Bitcoin worth 1 USD. For more information please consult the BitMEX perpetual contract details page..

Bitstamp is a cryptocurrency exchange. Please see the API reference page for the technical details.

Order and market data related functionality is provided via FIX/4.4 protocol. Account data and reference data is provided via REST API.

Bitstamp FIX/4.4 interface follows the standard closely, but offers only one session for both market data feed and trading operations. Bitstamp market data supports only limited number of cryptocurrency (Forex) securities. Order modifications are not supported. For more information about the Bitstamp FIX specification please have a look at the Bitstamp public FIX interface.

The relevant properties for the Bitstamp adapter are defined inside the file conf-bts.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
bts.apiKey = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"API Secret"}
bts.apiSecret = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"String","label":"Customer ID"}
bts.customerId = XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
bts.rateLimits = 40/1m

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
bts.importAllPairs = true

A Bitstamp account is necessary in order to use Bitstamp adapter. Unique apiKey and apiSecret settings must be set to the actual values (either in the properties file or by setting a VM argument)

CoinAPI is a market data gateway to multiple crypto exchanges. CoinAPI provides historical and live market data. It also provides reference data for the supported instruments, however it doesn't provide trading related functionality. Please see the API reference page for the technical details.

Historical data is available down to 1 second bars. Historical data availability varies by currency. Up to 100 daily requests can be placed for free. Consult their pricing if you require more.

Instruments and exchanges must have CNPID value setup in security and exchangedatabase tables.

The relevant properties for the CoinAPI adapter are defined inside the file conf-cnp.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"API Key"}
cnp.apiKey = XXXXXXXXXXXXXXXXX

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
cnp.rateLimits = 40/1m

#{"type":"Integer","label":"API-level constant'}
cnp.scale = 5

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
cnp.importAllPairs = true

#{"type":"String[]","label":"can contain values: trade, quote, book20"}
cnp.websocketUpdates = trade,quote

Unique apiKey and apiSecret settings must be set to the actual values (either in the properties file or by setting a VM argument)

Coinbase is a cryptocurrency exchange. The Coinbase Pro adapter supports order execution, market data, reference data and account data functionality. Please see the Coinbase API reference page for technical details.

Note

Currently Coinbase Pro does not yet support cross-border trading, so trading vs. USD is only possible with a US account.

The relevant properties for the Coinbase Pro adapter are defined inside the file conf-cnb.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"Web Socket Url"}
cnb.webSocketUrl = wss://ws-feed.pro.coinbase.com
#cnb.webSocketUrl = wss://ws-feed-public.sandbox.pro.coinbase.com

#{"type":"Integer","label":"Number of maximum idle period between incoming messages in seconds"}
cnb.webSocketTimeoutSeconds = 10

#{"type":"String","label":"API Key"}
cnb.apiKey = XXX

#{"type":"String","label":"API Secret"}
cnb.apiSecret = XXX

#{"type":"String","label":"API passphrase"}
cnb.passphrase = XXX

#{"type":"String","label":"REST Url"}
cnb.restUrl = https://api.pro.coinbase.com
#cnb.restUrl = https://api-public.sandbox.pro.coinbase.com

#{"type":"Integer","label":"REST API Rate Limit Milliseconds"}
cnb.rateLimits = 5/1s

#{"type":"Boolean","label":"if true import all currencies, otherwise only those defined in ch.algotrader.enumeration.Currency"}
cnb.importAllPairs = true

A Coinbase Pro account is necessary in order to use Coinbase Pro adapter, but not needed for market data. Coinbase Pro provides a sandbox/testing environment, both for the public website (Sandbox website url) and the exchange. You'll need to generate (via the Coinbase website) and configure (see properties above) an API key and API secret in order to use the Coinbase Pro Adapter. The sandbox/testing environment has different URLs (see commented out values cnb.webSocketUrl, cnb.restUrl above).

Coinigy provides connectivity to 45+ of most popular cryptocurrency exchanges allowing to trade hundreds of different crypto currencies. The Coinigy Interface connects to the Coinigy API endpoints via REST and Socket Cluster protocols.

The Coinigy interface supports Market Data, Order Processing, Retrieval of account information as well as Reference Data.

Coinigy uses the columns Security CNGID and Exchange CNGID to identify an instrument.

For further details on the Coinigy interface please visit the Coinigy API Documentation

To setup a connection to Coinigy the following steps have to be taken:

  • Sign-up for a Coinigy account on Coinigy Sign up

  • Enable two factor authentication (2FA) on the account following the 2FA Instructions

  • In the API accounts settings add the API keys from all of the exchanges where an account is setup according to these Instructions

  • In the account preferences generate a new Coinigy API key and Secret Key set it inside conf-cng.properties

  • In the account preferences click the button 'Click to reveal my Private Channel ID (WebSocket API)' and set the Private Channel ID inside conf-cng.properties

The relevant properties for the Coinigy adapter are defined inside the file conf-cng.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"String","label":"WSS Private Channel"}
cng.wssPrivateChannel = XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

#{"type":"String","label":"API Key"}
cng.apiKey = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#{"type":"String","label":"API Secret"}
cng.apiSecret = xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

#{"type":"String","label":"CNG reverse exchanges"}
cng.reverseExchanges = BITS,BTCC,PLNX

#{"type":"String","label":"CNG Default Exchange Codes"}
cng.defaultExchangeCodes = PLNX,BITF,KRKN,GDAX,BTCE,OK,BTRX,BT38,BITS,HUOB

# default exchanges/adapter types to use for market data.
#{"type":"String","label":"Default market feeds"}
misc.defaultMarketFeeds=BMEX:CNG,OKEX:CNG,BINA:CNG

In order to populate the database with Coinigy Accounts, Exchanges, Security Families and Securities run the ReferenceDataStarter with cNGReferenceData spring profile enabled and program argument: all. For further details please visit Chapter 19, Reference Data.

CoinMarketCap - Cryptocurrency Market Capitalizations is a website providing information about all existing crypto currencies and exchanges. The CoinMarketCap interface connects to the website via HTML and REST API.

The CoinMarketCap interface provides the publicly available daily historical data and reference data for all listed crypto currencies. No account is necessary in order to use the CoinMarketCap adapter.

Tilde is a cryptocurrency market maker/OTC trading services provider.

The Tilde interface supports Market Data, Order Processing, Request for Quote (RFQ) process, Retrieval of account information as well as Reference Data.

The relevant properties for the Tilde adapter are defined inside the file conf-tld.properties where they can be changed. Alternatively the properties can be changed via Section 2.3, “VM Arguments”:

#{"type":"Long","label":"The id of the account to be used in conjunction with the tilde RFQ process."}
tld.quoteAccountId = 208

Tilde does not have an order book but will stream prices to you at the requested level for each coin (e.g. prices for 5 BTC).

These price levels for streaming market data need to be agreed with Tilde and are configured on their side.

Above a certain value (to be agreed with Tilde), you will not be able to execute orders directly but need to go through the RFQ process.

In order to populate the database with Tilde Accounts, Exchanges, Security Families and Securities run the ReferenceDataStarter with tLDReferenceData spring profile enabled and program argument: all. For further details please visit Chapter 19, Reference Data.

Note that time in force (TIF) for Tilde Previously Indicated orders has to be Immediate or Cancel (IOC) or Fill or Kill (FOK), and for non RFQ orders Good till Cancel (GTC), Fill or Kill (FOK), IOC [not yet supported] is planned.