Introduction

This document details the connectivity protocol and set-up for clients wishing to trade on BEQUANT Exchange.

Purpose of this document

This document is intended for clients who wish to trade through BEQUANT Exchange and who wish to access BEQUANT’s services by using the Financial Information Exchange (FIX) protocol, to allow them to understand the functionality offered by BEQUANT and to configure their software appropriately.

The FIX protocol enables access to the trading services and security information within BEQUANT, using a messaging standard developed for real-time exchange of security transactions.

BEQUANT’s FIX server is designed to closely follow the official FIX Protocol FIX 4.4 specifications. This document should therefore be read in conjunction with the FIX specifications on the FIX Protocol website (http://www.fixprotocol.org).

Note that optional fields are listed with a yellow shaded background and italicised. Members of repeating blocks are prefixed with ">>".

Functional Overview

Connectivity

BEQUANT offers two transport mechanisms for clients wishing to connect via FIX: VPN and Co-location.

VPN

Standard connectivity to BEQUANT’s FIX Gateway is via a Virtual Private Network (VPN) over public internet. BEQUANT uses OpenVPN – see https://openvpn.net/ for more details. Each BEQUANT client will be provided with individual connection VPN details for UAT and Production during the onboarding process.

Note that there are two FIX end-points, with different network addresses:

  • FIX Trading end-point: interface for trading (placing new orders, order status requests, execution reports, order cancellation).

  • FIX Market data end-point: interface for market data subscription.

Co-location

In Q2 2019 BEQUANT will be offering latency-sensitive FIX clients the ability to connect directly via our presence in the Equinix LD4 Data Centre in Slough, UK.

By Q4 2019 BEQUANT will be offering Co-location clients the ability to connect using FIX 5.0 in addition to FIX 4.4.

Additionally, by Q4 2019, BEQUANT will be offering co-location clients the ability to consume Market Data via a high-performance multicast mechanism.

For more details of co-location, including pricing, please contact BEQUANT Sales.

Trading Session

BEQUANT runs a continuous 24-hour trading session. Clients are able to trade at any time, seven days a week.

Day (session) orders automatically expire at UTC 00:00. Note that there is no automated cut-off and rollover to the next trading day i.e. if a day order is placed at UTC 23:59:00 it will expire after one minute at UTC 00:00:00.

Trading is not available during system maintenance. Clients will be notified well in advance of any such maintenance downtime.

Clients are limited to a single concurrent session per user, and are limited to sending 300 messages per second. Message rates in excess of 300/second may result in message rejection. Clients can request multiple user logins.

Clock Synchronisation

Timing issues may arise if clocks are out of synchronisation. Clients should verify with their system administrator that their FIX engine host’s clock is synchronised via a properly-configured NTP service.

Supported Order Types

The BEQUANT FIX Server supports the following Order Types:

Market Orders

Market Orders are orders to buy or sell a particular quantity of a currency pair at the prevailing price at the time the order was received.

Market Orders on BEQUANT will execute at a price not worse than 10% away from the best available price; any remainder will be expired.

Limit Orders

A standard Limit Order requests a trade of some quantity of a currency pair, at the requested price or better. If the prevailing market price is already better than the request price at the time the order is received, the order fills immediately. Otherwise, the order waits for execution until the price stipulation is met or the order expires as per its Time-in-Force.

Limit Orders requesting Day, Fill-or-Kill (FOK), Immediate-or-Cancel (IOC), Good-‘til-Cancel (GTC) or Good-‘til-Date (GTD) behave as described below.

Stop-Market Orders

A Stop-Market order is a Market Order that remains inactive until the market reaches a specified Stop Price.

Stop Limit Orders

A Stop-Limit order is a Limit Order that remains inactive until the market reaches a specified stop price.

Stop-Limit Orders requesting Day, Fill-or-Kill (FOK), Immediate-or-Cancel (IOC), Good-‘til-Cancel (GTC) or Good-‘til-Date (GTD) behave as described below.

Time in Force

All orders sent to BEQUANT must specify a Time-in-Force.

Day Orders

Orders placed with TimeInForce of Day stay on the order book until they are filled, cancelled, or until UTC 00:00:00 at which point they expire.

Fill-or-Kill (FOK) Orders

Orders placed with TimeInForce of Fill-or-Kill (FOK) are executed immediately if the price and quantity stipulations are met at the time the order is received. If they are not met, the order is cancelled in full.

Because FOK orders are always Limit or Stop orders, the Price (field 44) or StopPx (field 99) tags are required, as appropriate.

Immediate-or-Cancel (IOC) Orders

Orders placed with TimeInForce of Immediate-or-Cancel (IOC) are executed immediately if the price stipulation is met, up to the available quantity for execution, and the remaining quantity is cancelled.

Because IOC orders are always Limit or Stop orders, the Price (field 44) or StopPx (field 99) tags are required, as appropriate.

Good ‘til Cancel (GTC) Orders

Orders placed with TimeInForce of Good-‘til-Cancel (GTC) remain on the order book until they are filled or cancelled.

Good ‘til Date (GTD) Orders

Orders placed with TimeInForce of Good-‘til-Date (GTD) remain on the order book until they are filled, cancelled, or until the date stipulated is reached at which point they expire.

Order Management

All orders submitted through the FIX interface should be modified or cancelled through the FIX interface.

Market Data

Clients can obtain Market Data from the BEQUANT FIX Server, either by requesting a onetime Market Data snapshot, or a requesting a snapshot plus a subscription to a stream of incremental updates.

Account Management

The BEQUANT FIX Server supports Position Request messages (message type AN) and in response returns a Position Report (message type AP). This should be used to review account balances.

Duplicate and Resend Message handling

Duplicate messages are typically handled in the session layer. However, clients may wish to implement additional safety checks to protect themselves from duplicate messages.

For example, tag 43 in the standard header of each message indicates potentially duplicate information. The rules for processing this situation are defined within the FIX protocol itself and the FIX Engine session layer typically handles this. However, Clients may decide to improve on the session level handling of duplicates in their own platform, implemented one level above the session layer, and hence serving as an additional safeguard against duplicate information.

Disaster Recovery

In the case of a BEQUANT FIX Server failure there may be a brief interruption of service. In order to return to normal operating conditions Clients will need to reconnect and synchronise message sequence numbers i.e. resend any unsent messages, receive and process any messages not previously received, etc.

If an internal system fault occurs following receipt of a New Order message the Client will receive an Order Reject message with the specific reason “Too late to enter”. Note that in such a situation the order may actually have been placed.

We therefore recommend that upon receipt of an Order Reject message with the specific reason “Too late to enter” clients cancel all their open orders, close their FIX connection, open a new FIX connection, and then resubmit all orders.

We recommend that all Orders are sent with ExecInst (tag 18) set to 'o' – this instructs the FIX engine to cancel that order automatically on connection disconnect. Alternatively, Clients can set tag 10001 (Cancel on Disconnect) to “Y” in the Logon message – this will automatically cancel all orders upon FIX engine disconnection regardless of the value of ExecInst on the individual order messages.

In case of a severe fault the FIX session may be forcibly reset. In this case Clients will receive a Sequence Reset (type 4) message from the server, and should synchronise their state via an Order Mass Status Request (type AF) message.

For Co-location clients we can offer the option of a secondary cross-connect for added redundancy.

Symbology, Tick sizes and Lot sizes.

  • Clients must pass the identity of the currency pair they wish to trade via the Symbol (tag 55) field.

  • Quantity is represented in lots (e.g. 1 lot of BTCUSD is 0.00001 BTC), and must be supplied as an integer.

  • Price is represented in natural value (e.g. 550$ for BTC).

For a list of all supported currency pairs, their lot size and their tick size refer to Appendix 1.

Note that the symbol you must supply when sending orders via FIX can differ from the symbol displayed on the Bequant website, for example, the FIX symbol for BCH is BCHABC.

Start of Day / End of Day Procedures

The BEQUANT FIX Server runs 24/7, so there is no official start-of-day / end-of-day. Clients should set appropriate start and end times for their FIX sessions when connecting to BEQUANT in line with their own requirements.

Counterparty Identification

When initiating a connection to the BEQUANT FIX Server, clients will need to populate the SenderCompID (tag 49) and TargetCompID (56) fields.

BEQUANT will inform each client what values to set for these two fields as part of the onboarding process.

FIX Message Details

Headers and Trailers

Standard FIX Header and Trailers should be added by the Client to each message sent to the BEQUANT FIX Server.

Header

Tag

Name

Values

Type

Comments

8

BeginString

FIX.4.4

String

9

BodyLength

Message length in bytes

String

Message length, in bytes, forward to the CheckSum (tag 10) field

35

MsgType

0 - Heartbeat
1 - Test Request
2 - Resend Request
A - Logon
5 - Logout
D - NewOrderSingle
F - Order Cancel Request
H - Order Status Request
V - Market Data Request
AF - Mass Status Request AN - Request For Positions

String

49

SenderCompID

Will be in the format "login_<userID>”

Note that only one connection can be established with the same SenderCompID BEQUANT will inform client of appropriate value for <username>

56

TargetCompID

<TargetCompID>

String

BEQUANT will inform client of appropriate value for <TargetCompID>

34

MsgSeqNum

<sequence number>

SeqNum

Integer message sequence number

43

PossDupFlag

‘Y’ or ‘N’

Boolean

Indicates possible retransmission of message with this sequence number. If not supplied, defaults to N.

52

SendingTime

<Time message sent>

UTCTimestamp

In UTC

122

OrigSendingTime

<Time original message sent>

UTCTimestamp

Populated for messages resent as a result of a ResendRequest. If data is not available will be set to same value as SendingTime (tag 52)

Trailer

Tag

Name

Values

Type

Comments

10

CheckSum

Checksum of the message

String

Three byte simple checksum as per the standard FIX spec.

Administrative Messages

Logon

The Logon message (message type A) authenticates the Client establishing a connection to the BEQUANT FIX Server. In addition to the standard fields, clients will need to populate two additional fields – Username (tag 553) and Password (tag 554). BEQUANT will inform each client what values to set for these two fields during the onboarding process.

Clients can optionally populate custom tag 10001 (Cancel on Disconnect) in the Logon message with the value “Y”; this instructs the FIX engine to cancel all orders upon disconnection of the FIX session. If this tag is populated with “Y” then there is no need to populate ExecInst (tag 18) with value “o” on each New Order Single (type D) message.

Tag

Name

Values

Type

Comments

Header

35

MsgType

A

String

Logon message

Body

98

EncryptMethod

0

Integer

Should always be set to 0 (None)

108

HeartBtInt

Any numeric value in seconds e.g. 30

Integer

Desired heartbeat interval in seconds

141

ResetSeqNumFlag

Y or N

Boolean(optional)

Optional flag instructing Bequant Exchange to reset the connection sequence numbers. If not supplied defaults to N

553

Username

<username>

String

Will be supplied by Bequant

554

Password

<password>

String

Will be supplied by Bequant

10001

CancelOnDisconnect

Y or N

Boolean(optional)

Optional flag instructing Bequant to cancel all open orders should the Client’s FIX session unexpectedly disconnect. If not supplied defaults to N

Logout

The Logout message (type 5) initiates or confirms the termination of a FIX session. It can optionally contain the Text field (tag 58) which is populated with the reason for the Logout.

Tag

Name

Values

Type

Comments

Header

35

MsgType

5

String

Logout Message

Body

58

Text

<reason for logout>

String

Optional string which if populated contains the reason for the logout where initiated by BEQUANT.

Heartbeat

The Heartbeat message (type 0) monitors the status of the communication link and identifies when the last of a string of messages was not received. A Heartbeat is sent every x seconds, as defined in the HeartbeatInterval field in the Logon message, as well as in response to a TestRequest message.

Inclusion of the optional TestReqID field (tag 112) indicates that this Heartbeat is a response to a TestRequest message.

Tag

Name

Values

Type

Comments

Header

35

MsgType

0

String

Heartbeat message

Body

112

TestReqID

String

Optional string which if populated contains whatever was passed in the Test Request message that this Heartbeat is responding to.

Test Request

The test request message (type 1) forces a heartbeat from the opposing application. It can be initiated both from the Client and from the BEQUANT server.

Tag

Name

Values

Type

Comments

Header

35

MsgType

1

String

TestRequest message

Body

112

TestReqID

Any value

String

Custom identifier which will be returned in the resulting Heartbeat

Resend Request

A ResendRequest (type 2) message can be sent by either the Client or the BEQUANT FIX Server to request the retransmission of a previous message or a range of messages.

This function is used if a sequence number gap is detected, if the receiving application lost a message, or as a function of the initialisation process.

If request is for a single message then BeginSeqNo should have the same value as EndSeqNo. If the request is for all messages subsequent to a particular message defined in BeginSeqNo, then EndSeqNo should be set to ‘0’.

Tag

Name

Values

Type

Comments

Header

35

MsgType

2

String

Resend Request

Body

7

BeginSeqNo

<sequence number>

SeqNum

Message sequence number of the first message in range to be resent

16

EndSeqNo

<sequence number> or 0

SeqNum

Message sequence number of the last message in a range to be resent.
If request is for a single message BeginSeqNo = EndSeqNo.
If request is for all messages subsequent to a particular message, EndSeqNo = "0"

Reject

A Reject (type 3) message is issued when a message is received but cannot be properly processed due to a session-level rule violation. Whenever possible, it is strongly recommended that the cause of the failure be described in the Text (tag 58) field.

Tag

Name

Values

Type

Comments

Header

35

MsgType

3

String

Reject

Body

45

RefSeqNum

< sequence number>

SeqNum

MsgSeqNum of rejected message

371

RefTagID

<tag id>

Integer

The tag number of the FIX field being referenced.

372

RefMsgType

<message type>

String

The MsgType (field 35) of the FIX message being referenced.

58

Text

String

An optional message explaining the reason for the rejection

SequenceReset

A Sequence Reset (type 4) message instructs the receiving FIX Server to set the next expected message sequence number to a new value, which is contained in the FIX message in the NewSeqNo (tag 36) field.

The Sequence Reset (type 4) message has two modes: Gap Fill mode and Reset mode.

Gap Fill mode

Gap Fill mode is used in response to a Resend Request (type 2) message when one or more messages must be skipped over for one of the following two reasons:

  1. During normal resend processing, the sending application may choose not to send a message (e.g. an aged order).

  2. During normal resend processing, a number of administrative messages are skipped and not resent (such as Heart Beats, Test Requests).

Gap Fill mode is indicated by GapFillFlag (tag 123) field = "Y".

If the GapFillFlag (tag 123) field is present and equal to "Y", the MsgSeqNum (tag 34) in the Header should conform to standard message sequencing rules i.e. the MsgSeqNum (tag 34) of the Sequence Reset Gap Fill mode message should represent the beginning MsgSeqNum (tag 34) in the Gap Fill range because the remote side is expecting that next message sequence number.

Reset mode

Reset mode involves specifying an arbitrarily higher new sequence number to be expected by the receiver of the Sequence Reset Reset message, and is used to re-establish a FIX session after an unrecoverable application failure.

Reset mode is indicated by the GapFillFlag (tag 123) field being set to "N" or if the field is omitted entirely.

If the GapFillFlag (tag 123) field is not present, or set to N, it can be assumed that the purpose of the Sequence Reset message is to recover from an out-of-sequence condition. In Sequence Reset - Reset mode, the MsgSeqNum (tag 34) in the header should be ignored i.e. the receipt of a Sequence Reset - Reset mode message with an out of sequence MsgSeqNum (tag 34) should not generate resend requests.

Note that ‘Sequence Reset – Reset’ should NOT be used as a normal response to a Resend Request message. The Sequence Reset - Reset should ONLY be used to recover from a disaster situation which cannot be recovered via the use of Sequence Reset - Gap Fill. Note also that the use of Sequence Reset - Reset may result in the possibility of lost messages.

Tag

Name

Values

Type

Comments

Header

35

MsgType

4

String

Sequence Reset

Body

123

GapFillFlag

N or Y

Boolean

Indicates that the Sequence Reset message is replacing administrative or application messages which will not be resent. If this field not supplied, value defaults to N.

36

NewSeqNo

SeqNum

New sequence number

Order message types

New Order Single

The New Order (type D) message is used by clients wishing to electronically submit orders to BEQUANT Exchange for execution.

The Cancel on Disconnect logic is as follows:

  1. Check the value of optional tag CancelOnDisconnect (10001) in the New Order message. If that is set to Y then this order will be cancelled upon session disconnect. If it is set to N then this order will not be cancelled upon session disconnect, regardless of the session-level setting.

  2. If CancelOnDisconnect (10001) is not supplied in the Order message then the value of tag CancelOnDisconnect (10001) that was sent in the Logon message (i.e. the session-level setting) will be used to determine whether this order will be cancelled upon disconnect.

Tag

Name

Values

Type

Comments

Header

35

MsgType

D

String

New Order Single

Body

11

ClOrdID

<client defined>

String

Unique identifier for Order as assigned by the Client. Uniqueness must be guaranteed within a single trading day. Clients, particularly those who submit multi-day orders, should ensure uniqueness across days, for example by embedding a date within the ClOrdID field. Has to be <= 32 characters

453

NoPartyIDs

1

NumInGroup

BEQUANT expects each order to be single, hence only details of one counterparty will be supplied.

>>448

PartyID

Will be in the format "user_<userID>”

String

Client’s BEQUANT Exchange user ID
Member of the Parties component repeating / block.

1

Account

Will be in the format "account_<userID>”

String

Account mnemonic as agreed between Client and BEQUANT

55

Symbol

<currency pair>

String

See appendix for list of symbols

54

Side

1 – Buy
2 – Sell

Char

60

TransactTime

<order time>

UTCTimestamp

Time in UTC this order request was sent by the Client

38

OrderQty

<quantity>

Integer

Quantity ordered. Must be compliant with Lot Size for this symbol (see Appendix 1)

40

OrdType

1 – Market
2 – Limit
3 – Stop
4 – Stop Limit

Char

44

Price

<price>

Price

Required for Limit and Stop Limit orders. Should not be specified for Market and StopMarket orders.

59

TimeInForce

0 - Day
1 - Good ‘Til Cancel (GTC)
3 = Immediate or Cancel (IOC)
4 = Fill or Kill (FOK)
6 - Good ‘Til Date (GTD)

Char

Day orders expire at UTC 00:00:00

Note that this field is mandatory.

99

StopPX

<stop price>

Price

Required for Stop Limit and Stop orders. Should not be specified for Market and Limit orders.

126

ExpireTime

<utc datetime>

UTCTimestamp

Date/Time when GTD orders should expire, in UTC. Required for GTD orders, not needed for others.

18

ExecInst

6 = Post-Only (aka participate don't initiate)

String

If ExecInst (18) = 6 then the order will only be placed onto the order book if does not immediately trigger a transaction.
If the order would have immediately triggered a transaction then it will be immediately expired. In this situation the client will receive two Execution Report messages – a New followed by an Expired.

10001

CancelOnDisconnect

Y or N

Boolean

If set to Y, instructs BEQUANT to cancel this order if the client’s FIX session is disconnected.

Execution Report

The Execution Report (type 8) message is used to:

  • confirm the receipt of an order.

  • confirm changes to an existing order (i.e. accept cancel and replace requests).

  • relay order status information.

  • relay fill information on working orders.

  • reject orders.

  • report post-trade fees calculations associated with a trade.

Each execution report contains two fields which are used to communicate both the current state of the order as understood by the broker - OrdStatus (tag 39) - and the purpose of the message - ExecType (tag 150).

Note that OrdStatusReqID (790) is not populated on execution reports which are responding to an OrderStatusRequest message.

Tag

Name

Values

Type

Comments

Header

35

MsgType

8

String

Execution Report

Body

37

OrderID

<order id>

String

Order ID allocated by BEQUANT

11

ClOrderID

<client order id>

String

Client’s Order ID

41

OrigClOrdID

<client order id>

String

ClOrdID of the previous accepted order when cancelling or replacing an order. Only populated if this execution report is in response to an OrderCancelRequest message.

17

ExecID

<execution ID>

String

Unique identifier of execution message as assigned by BEQUANT

527

SecondaryExecID

<execution ID>

String

150

ExecType

0 - New
4 - Cancelled
5 - Replaced
8 - Rejected
9 - Suspended
C - Expired
F - Trade (partial fill or fill)
I - Order Status

Char

Describes the purpose of the execution report.

39

OrdStatus

0 - New
1 - Partially filled
2 - Filled
4- Cancelled
8 – Rejected
9 - Suspended
C - Expired

Char

Describes the current state of the order.

103

OrdRejReason

1 - Unknown symbol
2 - Exchange closed
4 - Too late to enter
5 - Unknown Order
6 - Duplicate Order (e.g. dupe ClOrdID (11))
11 - Unsupported order characteristic
15 - Unknown account(s)
99 - Other

Char

Only populated if this Execution Report is rejecting a previously placed order i.e. 150=8

1

Account

Will be in the format "account_<userID>”

String

Account mnemonic as agreed between Client and BEQUANT

55

Symbol

<currency pair>

String

See appendix for list of symbols

54

Side

1 – Buy
2 – Sell

Char

60

TransactTime

<order time>

UTCTimestamp

Time in UTC this order request was sent by the Client

38

OrderQty

<quantity>

Qty

Quantity ordered.

40

OrdType

1 – Market
2 – Limit
3 – Stop
4 – Stop Limit

Char

44

Price

<price>

Price

Only populated for Limit orders

59

TimeInForce

0 - Day
1 - Good ‘Til Cancel (GTC)
2 - Immediate or Cancel (IOC)
4 - Fill or Kill (FOK)
6 - Good ‘Til Date (GTD)

59

Day orders expire at UTC 00:00:00

126

ExpireTime

<time>

UTCTimestamp

Expiration time (if Good Til Date order)

18

ExecInst

6 - Post-Only (aka participate don't initiate)

String

99

StopPX

<stop price>

Price

Only populated for Stop & Stop Limit Orders

32

LastQty

<quantity>

Qty

Quantity bought/sold on this fill.
Required if ExecType = Trade

31

LastPx

<price>

Price

Price of this fill.
Required if ExecType = Trade

851

LastLiquidityInd

1 - Added Liquidity
2 - Removed Liquidity

Char

Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity. Applicable only for OrdStatus of Partial or Filled.

151

LeavesQty

<quantity>

Qty

Quantity open for further execution. If the OrdStatus is Cancelled, DoneForTheDay, Expired, Calculated, or Rejected (in which case the order is no longer active) then LeavesQty could be 0, otherwise LeavesQty = OrderQty - CumQty.

14

CumQty

<quantity>

Qty

Currently executed quantity

6

AvgPx

<price>

Price

Calculated average price of all fills on this order.

137

MiscFeeAmt

<trading fee amount>

Amt

Exchange fee associated with this trade

138

MiscFeeCurr

<trading fee currency>

Currency

Currency that the trading fee is denominated in

139

MiscFeeType

4 – Exchange Fees

Char

Indicates that Fee is an Exchange Fee

584

MassStatusReqID

<client-defined ID>

String

Required if responding to an Order Mass Status Request. Echoes back the value provided by the requester.

912

LastRptRequested

N - There is at least one more execution report
Y - This is last execution report

Boolean

Can be used when responding to an Order Mass Status Request to indicate that this is the last Execution Reports which will be returned as a result of the request.

Order Cancel Request

The Order Cancel Request (type F) message requests the cancellation of all of the remaining quantity of an existing order.

Each Cancel Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Cancel Reject (type 3) message, as well as the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field. The ClOrdID (tag 11) assigned to the cancel request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.

Tag

Name

Values

Type

Comments

Header

35

MsgType

F

String

Order Cancel Request

Body

41

OrigClOrdID

<order id>

String

ClOrdID of the order the client is requesting to cancel.

11

ClOrdID

<order id>

String

Unique ID for this Cancel Request as assigned by the client.

1

Account

Will be in the format "account_<userID>”

String

Account associated with the order that the client is requesting to cancel

453

NoPartyIDs

1

NumInGroup

Number of counterparties (always one) in the following Party Component Repeating Group

>>448

PartyID

Will be in the format "user_<userID>”

String

Client’s BEQUANT Exchange user ID
Member of the Parties component repeating / block.

>>447

PartyIDSource

D = Proprietary

Char

Member of the Parties component repeating / block.

>>452

PartyRole

3 = Client ID

Integer

Member of the Parties component repeating / block.

55

Symbol

<currency pair>

String

Symbol associated with the order the client is requesting to cancel

54

Side

1 – Buy
2 – Sell

Char

Side associated with the order the client is requesting to cancel

60

TransactTime

<order time>

UTCTimestamp

TransactTime of the order the client is requesting to cancel

38

OrderQty

<quantity>

Qty

OrderQty = CumQty + LeavesQty of the order the client is requesting to cancel.

Order Cancel/Replace Request

The Order Cancel/Replace Request (type G) message can be used to change the details of an existing order.

An order will lose its time priority in the order book if any of its parameters are amended via a Cancel/Replace Request.

The following attributes of an order may be amended via the Order Cancel/Replace Request message:

  • Quantity.

  • Price.

BEQUANT will respond with an Execution Report or Order Cancellation Rejection to confirm or reject the amendment request respectively.

Stop Market/Stop Limit orders cannot be amended whilst they are suspended i.e. prior to the order becoming active. Once a Stop Market/Stop Limit order has become active, the quantity and where applicable the limit price may be amended.

If an order receives one or more fills while an amendment request is in flight, the system will not reject the incoming amendment request provided its quantity after amending will still be greater than the filled quantity. If this is not the case the amendment request will be rejected.

When processing a Cancel/Replace the existing order is cancelled and a new order is placed on the order book. This is executed as a single atomic transaction. However, the newly-placed order loses its order book time priority. Hence, if the intention is to increase the quantity of an existing order we recommend clients send a New Order message for the increased quantity rather than a Cancel/Replace.

Clients should not use this message to cancel the remaining quantity of an outstanding order, instead they should send an Order Cancel Request (type F) message.

The Cancel/Replace Request will only be accepted if the order being cancelled can successfully be pulled back from the exchange without executing. Requests which cannot be processed will be rejected using the Cancel Reject (type 3) message.

Each Cancel/Replace Request is assigned a unique ID in the ClOrdID (tag 11) field, and is subsequently treated as a separate entity. If rejected, the ClOrdID (tag 11) of the cancel request will be sent in the Cancel Reject (type 3) message, as well as the ClOrdID (tag 11) of the actual order in the OrigClOrdID (tag 41) field. The ClOrdID (tag 11) assigned to the cancel request must be unique amongst the ClOrdID (tag 11) fields assigned to regular orders and replacement orders.

Tag

Name

Values

Type

Comments

Header

35

MsgType

G

String

Order Cancel/Replace Request

Body

37

OrderID

<order id>

String

ID of the Order assigned by BEQUANT that the client wishes to cancel & replace. Must be supplied if OrigClOrdID missing.

453

NoPartyIDs

1

NumInGroup

Number of counterparties (always one) in the following Party Component Repeating Group

>>448

PartyID

Will be in the format "user_<userID>”

String

Client’s BEQUANT Exchange user ID
Member of the Parties component repeating / block.

>>447

PartyIDSource

D = Proprietary

Char

Member of the Parties component repeating / block.

>>452

PartyRole

3 = Client ID

Integer

Member of the Parties component repeating / block.

11

ClOrdID

<order id>

String

Unique ID for this Cancel Request as assigned by the client.

41

OrigClOrdID

<order id>

String

ID of the Order assigned by the Client that the client wishes to cancel & replace. Must be supplied if OrderID missing.

1

Account

Will be in the format "account_<userID>”

String

Account associated with the order that the client is requesting to cancel/replace

55

Symbol

<currency pair>

String

Symbol associated with the order the client is requesting to cancel/replace

40

OrdType

1 = Market
2 = Limit
3 = Stop
4 = Stop Limit

Char

Order Type

54

Side

1 – Buy
2 – Sell

Char

Side associated with the order the client is requesting to cancel/replace

38

OrderQty

<quantity>

Qty

New Order quantity. Must be greater than CumQty.

44

Price

< price>

Price

New Price. Required for Limit and Stop-Limit orders

99

StopPx

<stop price>

Price

Required for Stop and Stop-Limit orders. Can not be modified from original order.

126

ExpireTime

<utc datetime>

UTCTimestamp

Date/Time when GTD orders should expire, in UTC. Required for GTD orders, not needed for others. Can not be modified from original order.

60

TransactTime

<order time>

UTCTimestamp

TransactTime of the order the client is requesting to cancel

Order Cancel Reject

The Order Cancel Reject (type 9) message is issued by BEQUANT upon receipt of a Cancel Request message which cannot be honoured.

Tag

Name

Values

Type

Comments

Header

35

MsgType

9

String

Order Cancel Reject

Body

37

OrderID

<order id>

String

Order ID of the order the client attempted to cancel. If CxlRejReason=”Unknown order”, value of this tag will be “NONE”

11

ClOrdID

<order id>

String

Unique order id assigned by Client to the cancel request that was rejected

41

OrigClOrdID

<order id>

String

ClOrdID which could not be cancelled. ClOrdID of the previous accepted order (NOT the initial order of the day) when cancelling an order.

39

OrdStatus

0 - New
1 - Partially filled
2 - Filled
4 - Cancelled
8 - Rejected
9 - Suspended
C - Expired

Char

OrdStatus value after this Cancel Reject is applied. If CxlRejReason = "Unknown Order", value will be “Rejected”.

434

CxlRejResponseTo

1 = Order Cancel Request
2 = Order Cancel/Replace Request

Char

Identifies the type of request that a Cancel Reject is in response to

102

CxlRejReason

0 = Too late to cancel
1 = Unknown order
99 = Other

Integer

Order Status Request

The Order Status Request (type H) message is used by Clients to request order status for one of their orders. BEQUANT will respond with an Execution Report (type 8) message with ExecType (tag 150) ="Order Status".

In case of any errors for example if the Order is not found, BEQUANT will respond with a Reject message.

Tag

Name

Values

Type

Comments

Header

35

MsgType

H

String

Order Status Request

Body

11

ClOrdID

<order id>

String

Unique order id assigned by Client to the order they want status for.

790

OrdStatusReqID

<client defined>

String

Can be used to uniquely identify a specific Order Status Request message. When supplied this is echoed back on the subsequent execution report message.

1

Account

Will be in the format "account_<userID>”

String

Account associated with the order that the client is status for.

453

NoPartyIDs

1

NumInGroup

Number of counterparties (always one) in the following Party Component Repeating Group

>>448

PartyID

Will be in the format "user_<userID>”

String

Client’s BEQUANT Exchange user ID
Member of the Parties component repeating / block.

>>447

PartyIDSource

D = Proprietary

Char

Member of the Parties component repeating / block.

>>452

PartyRole

3 = Client ID

Integer

Member of the Parties component repeating / block.

55

Symbol

<currency pair>

String

Symbol associated with the order the client is requesting status for.

54

Side

1 – Buy
2 – Sell

Char

Side associated with the order the client is requesting status for.

Order Mass Status Request

The Order Mass Status Request (type AF) message requests the status for all orders for the Client in the supplied Account.

A mass status request is assigned a ClOrdID (tag 11) and is treated as a separate entity.

Execution Reports with ExecType (tag 150) ="Order Status" are returned for all orders matching the criteria provided on the request (i.e. for the Client/Account). Such an Execution Report will have the MassStatusReqID (tag 584) field filled in, and the very last one will have the LastRptRequested (912) flag populated.

Tag

Name

Values

Type

Comments

Header

35

MsgType

AF

String

Order Mass Status Request

Body

584

MassStatusReqID

<client defined>

String

Unique ID of mass status request as assigned by the Client. Echoed back on the execution report responses.

585

MassStatusReqType

7

All orders

1

Account

Will be in the format "account_<userID>”

String

Account associated with the orders that the client is asking status for.

453

NoPartyIDs

1

NumInGroup

Number of counterparties (always one) in the following Party Component Repeating Group

>>448

PartyID

Will be in the format "user_<userID>”

String

Client’s BEQUANT Exchange user ID
Member of the Parties component repeating / block.

>>447

PartyIDSource

D = Proprietary

Char

Member of the Parties component repeating / block.

>>452

PartyRole

3 = Client ID

Integer

Member of the Parties component repeating / block.

Business Message Reject

A Business Message Reject (type j) message is sent by BEQUANT when a Client message cannot be processed.

Tag

Name

Values

Type

Comments

Header

35

MsgType

j

String

Business Message Reject. Note that this is lowercase i.e. j not J.

Body

45

RefSeqNum

<sequence number>

SeqNum

MsgSeqNum of rejected message

372

RefMsgType

<message type>

String

Message type of the FIX message being referenced.

380

BusinessRejectReason

0 = Other
1 = Unkown ID
3 = Unsupported Message Type
4 = Application not available
5 = Conditionally Required Field Missing
6 = Not authorized

Integer

Code to identify reason for a Business Message Reject message.

Market Data message types

Market Data Request

Clients can use the Market Data Request (type V) message to both subscribe to and unsubscribe from real-time receipt of Market Data from BEQUANT Exchange.

When making a Subscription Request, Clients must supply the Symbols they are requesting market data for and whether they want the entire order book or just the top of the book. Clients can request a one-time Snapshot, or a Snapshot plus ongoing streamed updates.

When Unsubscribing, the Client must pass the ID of the Subscription Request they wish to cancel.

A successful Market Data Subscription Request returns one or more Market Data (type W or type X) messages, each containing one or more Market Data Entries. Each Market Data Entry can be a Bid, an Offer or a Trade associated with a currency pair.

Requesting just the top of book will result in receipt of just the Best Bid and Best Offer. For a full book, the Bid and Offer side may each have several Market Data Entries.

A Snapshot causes the current state of the market to be sent. A Snapshot + Updates causes the current state of the market to be sent along with any updates as they occur, until the client requests that the Snapshot + Updates be disabled.

When just a Snapshot is requested, the complete data for only one currency pair will be returned in the FIX Market Data Snapshot Full Refresh message.

When Snapshot + Updates is requested, the updates are streamed incrementally. Several incremental updates of market data entries for different instruments can be included in one FIX Market Data message. Note that you may receive incremental updates before a Snapshot is received; these should be ignored.

Trades are not supplied in a Snapshot but are supplied in Snapshot + Incremental Update.

A Market Data Request Reject (message type Y) may be sent in response to a request that cannot be honoured.

Tag

Name

Values

Type

Comments

Header

35

MsgType

V

String

Market Data Request

Body

262

MDReqID

<client defined unique id>

String

Either unique if this is a new request, else the ID of the previous Market Data Request to disable if SubscriptionRequest
Type = 2 (Disable previous Snapshot + Updates Request).

263

SubscriptionRequestType

0 - Snapshot
1 - Snapshot + updates
2 - Disable previous Snapshot + Update Request (Unsubscribe)

Char

264

MarketDepth

0 - Full Book
1 - Top of Book

Integer

Required for subscription requests.

146

NoRelatedSym

<number of instruments>

NumInGroup

The number of entries in the InstrmtMDReqGrp repeating group (i.e. how many tag 55s). Required for subscription requests.

>>55

Symbol

<symbol>

String

Currency Pair Symbol that you are requesting market data for.
There can be multiple tag 55s as part of the InstrmtMDReqGrp repeating group. Required for subscription requests.

MarketDataRequestReject

A MarketDataRequestReject (type Y) message is sent to a Client if a MarketDataRequest cannot be honoured by BEQUANT.

Tag

Name

Values

Type

Comments

Header

35

MsgType

Y

String

Market Data Request Reject

Body

262

MDReqID

<client defined unique id>

String

ID of the Market Data Request this reject pertains to.

281

MDReqRejReason

0 = Unknown Symbol
1 = Duplicate MDReqID
4 = Unsupported Subscription Request Type
5 = Unsupported Market Depth
6 = Unsupported MDUpdate Type
8 = Unsupported MDEntry Type

Char

Optional field which may be populated to explain why the request was rejected.

58

Text

<reason for rejection>

String

Optional text.

MarketDataSnapshotFullRefresh

The Market Data Snapshot Full Refresh message (type W) is used as the response to a Market Data Request (type V) message.

Market Data messages sent as the result of a Market Data Request message will specify the appropriate MDReqID (tag 262).

Market Data messages can take two forms - a static Snapshot, or a Snapshot plus incremental streamed Updates.

A Snapshot is the current state of the order book at the time of the request; it contains only bids and offers for the depth specified in the request. Each one message contains the order book just for one symbol, snapshots never contain trades.

A Snapshot is sent in response to a Snapshot Request, or when subscribing to Snapshots + Updates. When subscribing, one Snapshot is sent, and after that only Updates are published.

Tag

Name

Values

Type

Comments

Header

35

MsgType

W

String

Market Data Snapshot Full Refresh

Body

262

MDReqID

<client defined unique id>

String

ID of the Market Data Request this message pertains to.

55

Symbol

<currency pair symbol>

String

Currency pair this message contains market data for.

268

NoMDEntries

<number of entries>

NumInGroup

Number of MD Entries in the repeating group

>>269

MDEntryType

0 – Bid
1 – Offer

Char

Member of repeating group of MD entries

>>270

MDEntryPx

<price>

Price

Member of repeating group of MD entries

>>271

MDEntrySize

<quantity>

Qty

Quantity or volume represented by the Market Data Entry.
Member of repeating group of MD entries

>>272

MDEntryDate

<date>

UTCDateOnly

Member of repeating group of MD entries

>>273

MDEntryTime

<time>

UTCTimeOnly

Member of repeating group of MD entries

MarketDataIncrementalRefresh

A Market Data Incremental Refresh message (type X) can also be sent in response to a Market Data Request (type V) message. They contain details of incremental updates to a previously supplied Snapshot addition, deletion or level changing to the Order Book as well as details of any trades that have taken place.

Note that Tag 271 (MD Entry Size) will be set to zero if the price level of this MD Entry was removed from the Order Book.

Each message will only contain information about one currency pair but can contain details of multiple Order Book increments and Trades.

Tag

Name

Values

Type

Comments

Header

35

MsgType

X

String

Market Data Snapshot Full Refresh

Body

262

MDReqID

<client defined unique id>

String

ID of the Market Data Request this message pertains to.

268

NoMDEntries

<number of entries>

NumInGroup

Number of MD Entries in the repeating group

>>279

MDUpdateAction

0 – New
1 – Change
2 - Delete

Char

In the case of a level removal MDEntrySize will be 0
Member of the MD Entries repeating group

>>269

MDEntryType

0 – Bid
1 – Offer
2 – Trade

Char

Member of the MD Entries repeating group

>>55

Symbol

<currency pair symbol>

String

Currency pair this message contains market data for.

>>270

MDEntryPx

<price>

Price

>>271

MDEntrySize

<quantity>

Qty

Quantity or volume represented by the Market Data Entry.

>>272

MDEntryDate

<date>

UTCDateOnly

Member of repeating group of MD entries

>>273

MDEntryTime

<time>

UTCTimeOnly

Member of repeating group of MD entries

>>278

MDEntryID

<trade ID>

String

Contains ID of the trade that generated this Market Data Update(where applicable)

Account message types

RequestForPositions

The Request for Positions message (type AN) is used by the Client to request a Position Report from BEQUANT.

BEQUANT only supports one-time snapshot of positions, hence the value of the PosReqType (tag 724) field will always be 0, as well the value of the SubscriptionRequestType (tag 263) field.

Tag

Name

Values

Type

Comments

Header

35

MsgType

AN

String

Request For Positions

Body

710

PosReqID

<client defined unique id>

String

Unique ID of this Position Request

724

PosReqType

0 - Positions

Integer

BEQUANT only supports request for positions hence value always 0

263

SubscriptionRequestType

0 - Snapshot

Char

BEQUANT only supports snapshots positions hence value always 0

453

NoPartyIDs

0

NumInGroup

BEQUANT returns all positions for the client, hence this value is set to 0.

1

Account

Will be in the format "account_<userID>”

String

Client Account Identifier

581

AccountType

8 – Joint Backoffice Account

Integer

Hardcode to 8

15

Currency

<currency>

Currency

Identifies currency used for price.

715

ClearingBusinessDate

Now in format YYYYMMDD

LocalMktDate

Ignored but mandatory, pass “now”

60

TransactTime

Now in UTC

UTCTimeStamp

Ignored but mandatory, pass “now”

PositionReport

The Position Report (type AP) message is returned by BEQUANT a position in response to a Request for Position message from the Client. The purpose of the message is to report all aspects of a position and may be provided on a standing basis to report end of day positions to an owner.

The report contains a repeating group of Position Amount entries.

Tag

Name

Values

Type

Comments

Header

35

MsgType

AN

String

Request For Positions

Body

721

PosMaintRptID

<id>

String

Unique ID of this Position Report

710

PosReqID

<client defined unique id>

String

Unique identifier for the Request for Positions associated with this report

728

PosReqResult

0 - Valid request
1 - Invalid or unsupported request

Integer

If the request is processed successfully this field is not populated, hence is missing can be assumed to have a value of 0

715

ClearingBusinessDate

19810711

LocalMktDate

Mandatory but not used hence dummy value.

453

NoPartyIDs

0

NumInGroup

BEQUANT returns all positions for the client, hence this value is set to 0.

1

Account

Will be in the format "account_<userID>”

String

Client Account Identifier

581

AccountType

8 – Joint Backoffice Account

Integer

Hardcode to 8

15

Currency

<currency>

Currency

Identifies currency used for price.

720

SettlePrice

0.0

Price

Mandatory but not used hence dummy value.

731

SettlePriceType

1 = Final

Integer

734

PriorSettlPrice

0.0

Price

Mandatory but not used hence dummy value.

702

NoPositions

0

NumInGroup

Number of position entries.

753

NoPosAmt

1 or 2

NumInGroup

1 indicates an error.2 indicates a success.

>>707

PosAmtType

CASH (Cash Amount)
CRES (Cash Residual Amount)

String

CASH (Cash Amount Corporate Event) is the total amount of this currency on the user's account.
CRES (Cash Residual Amount) is the amount of this currency not blocked by the position that is, available for opening positions. Member of Position repeating group

>>708

PosAmt

<amount>

Amt

Account balance or 0 in case of errorMember of Position repeating group

58

Text

“15 (Currency)”
“1 (Account)”
“710 (PosReqID)”

String

Contains incorrect tag in case of wrong message

Appendix 1: Symbology

Symbol

FIX Symbol

Base Ccy

Quote Ccy

Lot Size

Tick Size

Fee Ccy

BTCUSDT

BTCUSD

BTC

USDT

0.00001

0.01

USDT

BTGBTC

BTGBTC

BTG

BTC

0.001

0.0000001

BTC

BTGUSDT

BTGUSD

BTG

USDT

0.001

0.00001

USDT

EOSBTC

EOSBTC

EOS

BTC

0.01

0.00000001

BTC

EOSUSDT

EOSUSD

EOS

USDT

0.01

0.00001

USDT

ETCBTC

ETCBTC

ETC

BTC

0.01

0.0000001

BTC

ETCUSDT

ETCUSD

ETC

USDT

0.01

0.00001

USDT

ETHBTC

ETHBTC

ETH

BTC

0.0001

0.000001

BTC

ETHUSDT

ETHUSD

ETH

USDT

0.0001

0.001

USDT

LTCBTC

LTCBTC2

LTC

BTC

0.001

0.0000001

BTC

LTCUSDT

LTCUSD

LTC

USDT

0.001

0.0001

USDT

NEOBTC

NEOBTC

NEO

BTC

0.01

0.0000001

BTC

NEOUSDT

NEOUSD

NEO

USDT

0.01

0.00001

USDT

XRPBTC

XRPBTC2

XRP

BTC

0.1

0.000000001

BTC

XRPUSDT

XRPUSD2

XRP

USDT

0.1

0.000001

USDT

BTCEURS

BTCEURS

BTC

EURS

0.00001

0.01

EURS

EOSEURS

EOSEURS

EOS

EURS

0.01

0.00001

EURS

ETHEURS

ETHEURS

ETH

EURS

0.0001

0.0001

EURS

LTCEURS

LTCEURS

LTC

EURS

0.001

0.0001

EURS

NEOEURS

NEOEURS

NEO

EURS

0.01

0.00001

EURS

XRPEURS

XRPEURS

XRP

EURS

0.1

0.000001

EURS

BTCDAI

BTCDAI

BTC

DAI

0.00001

0.01

DAI

ETHDAI

ETHDAI

ETH

DAI

0.0001

0.001

DAI

EOSDAI

EOSDAI

EOS

DAI

0.01

0.00001

DAI

USDTDAI

USDDAI

USDT

DAI

0.01

0.00001

DAI

NEODAI

NEODAI

NEO

DAI

0.01

0.00001

DAI

LTCDAI

LTCDAI

LTC

DAI

0.001

0.0001

DAI

XRPDAI

XRPDAI

XRP

DAI

0.1

0.000001

DAI

EURSDAI

EURSDAI

EURS

DAI

0.01

0.00001

DAI

BTCGUSD

BTCGUSD

BTC

GUSD

0.00001

0.01

GUSD

ETHGUSD

ETHGUSD

ETH

GUSD

0.0001

0.001

GUSD

USDTGUSD

USDGUSD

USDT

GUSD

0.01

0.000001

GUSD

EOSGUSD

EOSGUSD

EOS

GUSD

0.01

0.00001

GUSD

BCHBTC

BCHABCBTC

BCH

BTC

0.0001

0.000001

BTC

BCHUSDT

BCHABCUSD

BCH

USDT

0.0001

0.001

USDT

BSVBTC

BCHSVBTC

BSV

BTC

0.001

0.000001

BTC

BSVUSDT

BCHSVUSD

BSV

USDT

0.001

0.0001

USDT

BTCPAX

BTCPAX

BTC

PAX

0.00001

0.01

PAX

ETHPAX

ETHPAX

ETH

PAX

0.0001

0.001

PAX

USDTPAX

USDPAX

USDT

PAX

0.01

0.000001

PAX

EOSPAX

EOSPAX

EOS

PAX

0.01

0.0000001

PAX

BTCUSDC

BTCUSDC

BTC

USDC

0.00001

0.00001

USDC

ETHUSDC

ETHUSDC

ETH

USDC

0.0001

0.000001

USDC

USDTUSDC

USDUSDC

USDT

USDC

1

0.00000001

USDC

DAIUSDC

DAIUSDC

DAI

USDC

0.1

0.00000001

USDC

BTCKRWB

BTCKRWB

BTC

KRWB

0.00001

1

KRWB

USDCKRWB

USDCKRWB

USDC

KRWB

0.01

0.01

KRWB

USDTKRWB

USDKRWB

USDT

KRWB

0.01

0.01

KRWB

EOSETH

EOSETH

EOS

ETH

0.01

0.0000001

ETH

ETCETH

ETCETH

ETC

ETH

0.01

0.0000001

ETH

BTGETH

BTGETH

BTG

ETH

0.001

0.000001

ETH

NEOETH

NEOETH

NEO

ETH

0.01

0.0000001

ETH

XRPETH

XRPETH2

XRP

ETH

0.1

0.00000001

ETH

TRXBTC

TRXBTC

TRX

BTC

1

0.0000000001

BTC

TRXETH

TRXETH

TRX

ETH

1

0.000000001

ETH

TRXUSDT

TRXUSD

TRX

USDT

1

0.0000001

USDT

TRXEOS

TRXEOS

TRX

EOS

1

0.00000001

EOS

BTCEUR

BTCEURB

BTC

EURB

0.00001

0.01

EURB

ETHEUR

ETHEURB

ETH

EURB

0.0001

0.001

EURB

EOSEUR

EOSEURB

EOS

EURB

0.01

0.00001

EURB

EUREURS

EURBEURS

EURB

EURS

0.01

0.00001

EURS

EURUSDT

EURBUSD

EURB

USDT

0.01

0.00001

USDT

BCHETH

BCHABCETH

BCH

ETH

0.0001

0.00001

ETH

BCHDAI

BCHABCDAI

BCH

DAI

0.0001

0.001

DAI

BCHTUSD

BCHABCTUSD

BCH

TUSD

0.0001

0.001

TUSD

BCHEURS

BCHABCEURS

BCH

EURS

0.0001

0.001

EURS

BTCTUSD

BTCTUSD

BTC

TUSD

0.00001

0.01

TUSD

ETHTUSD

ETHTUSD

ETH

TUSD

0.0001

0.001

TUSD

TUSDDAI

TUSDDAI

TUSD

DAI

0.01

0.00001

DAI

USDTTUSD

USDTUSD

USDT

TUSD

0.01

0.000001

TUSD

BTCUSD

BTCUSDB

BTC

USDB

0.00001

0.01

USDB

ETHUSD

ETHUSDB

ETH

USDB

0.0001

0.001

USDB

EOSUSD

EOSUSDB

EOS

USDB

0.00001

0.001

USDB

TUSDUSD

TUSDUSDB

TUSD

USDB

0.01

0.00001

USDB

USDTUSD

USDUSDB

USDT

USDB

0.01

0.00001

USDB

DAIUSD

DAIUSDB

DAI

USDB

0.01

0.00001

USDB

BTCEOSDT

BTCEOSDT

BTC

EOSDT

0.00001

0.01

EOSDT

ETHEOSDT

ETHEOSDT

ETH

EOSDT

0.0001

0.001

EOSDT

EOSEOSDT

EOSEOSDT

EOS

EOSDT

0.01

0.00001

EOSDT

USDTEOSDT

USDEOSDT

USDT

EOSDT

0.01

0.00001

EOSDT

USDTUSDT20

USDUSDT20

USDT

USDT20

0.01

0.00001

USDT20

BTCUSDT20

BTCUSDT20

BTC

USDT20

0.00001

0.01

USDT20

Appendix 2: Field Types

Type

Comment

Amt

A float field typically representing a Price times a Qty

Boolean

A single character taking values Y or N

Char

Single Character

Currency

String field representing a currency type using ISO 4217 Currency code (3 character) values.

Float

Sequence of digits with optional decimal point and sign character (ASCII characters "-", "0" - "9" and "."); the absence of the decimal point within the string will be interpreted as the float representation of an integer value. All float fields must accommodate up to fifteen significant digits.

Integer

Sequence of digits without commas or decimals and optional sign character (ASCII characters "-" and "0" - "9" ). The sign character utilizes one byte (i.e. positive int is "99999" while negative int is "-99999"). Note that int values may contain leading zeros (e.g. "00023" = "23").

LocalMktDate

Date of Local Market (as opposed to UTC) in YYYYMMDD format.

NumInGroup

Integer field representing the number of entries in a repeating group. Value must be positive.

Price

Float field representing a price. Note the number of decimal places may vary.

SeqNum

Int field representing a message sequence number. Value must be positive.

String

Alpha-numeric free format strings, can include any character or punctuation except the delimiter. All char fields are case sensitive (i.e. BEQUANT != Bequant).

UTCTimestamp

String containing a time/date combination represented in UTC (Universal Time Coordinated, also known as "GMT") in either YYYYMMDD-HH:MM:SS (whole seconds) or YYYYMMDD-HH:MM:SS.sss (milliseconds) format.

UTCDateOnly

String field representing Date represented in UTC (Universal Time Coordinated, also known as "GMT") in YYYYMMDD format

UTCTimeOnly

String field representing time-only represented in UTC (Universal Time Coordinated, also known as "GMT") in either HH:MM:SS (whole seconds) or HH:MM:SS.sss* (milliseconds) format, colons, and full stop required

Change Log

Date

Version

Change

1.0

5.April.2019

Initial Publication

1.1

6.April.2019

Minor formatting changes.

1.2

9.April.2019

Minor corrections/amendments to Reject, Execution Report, Cancel/Replace, Order Status Request, Order Mass Status Request, Market Data Request , MarketDataSnapshotFullRefresh, MarketDataIncrementalRefresh and PositionReport messages.

1.3

11.April.2019

More detail regarding Cancel/Replace plus a minor correction to the definition of OrderQty in the Cancel/Replace message. Revised definition & explanation of the MarketDataIncrementalRefresh message

1.4

30.April.2019

Made clear that it’s currently not possible to modify the Stop Price when doing a Cancel/Replace on a Stop Order.

1.5

7.June.2019

Updated symbology appendix

1.6

12.July.2019

Updated symbology appendix

1.7

17.July.2019

Updated New Order Single message specification, notably Time In Force options, and added extra Time and Date fields to Market Data response messages

1.8

27.August.2019

Fixed typo – ExecInst is tag 18 not 8

1.9

16.September.2019

Removed erroneous reference to tag 278 in the Market Data section

2.0

27.September.2019

Added reference to new functionality that returns Fees in Execution Report (MiscFeeAmt and MiscFeeCurr)

2.1

22.October.2019

Cleaned up symbology table

2.2

28.November.2019

Added tag 278 to X message

Did this answer your question?