Kai-X System Interface Specification...1.06 13-Jun-2016 8 Updated CashMargin tag to only accept cash...

Kai-X System Interface Specification

Chi-X Japan Limited

Document ID: JPCX-L3-D-027

23-Jul-2018

Version 1.37


© 2018 Chi-X Global Technology Page i 23-Jul-2018/Version 1.37 CONFIDENTIAL

CONTENTS

1 Introduction ........................................................................................................ 1 1.1 Relevant documents ......................................................................................... 1 1.2 Revision History ................................................................................................ 1 2 FIX Interface ....................................................................................................... 3 2.1 Supported FIX Version ...................................................................................... 3 2.2 Network Transport ............................................................................................ 3 2.3 FIX Protocol Syntax .......................................................................................... 3 2.4 Message Format ............................................................................................... 3 2.5 Data Types: ...................................................................................................... 3 3 Configuration Information ................................................................................. 4 3.1 Client Configuration........................................................................................... 4 3.1.1 SenderCompID .............................................................................................. 4 3.1.2 TargetCompID ............................................................................................... 4 3.1.3 OnBehalfOfCompID ....................................................................................... 4 3.1.4 Encryption ...................................................................................................... 4 3.2 Kai-X Configuration ........................................................................................... 5 3.2.1 SenderCompID .............................................................................................. 5 3.2.2 TargetCompID ............................................................................................... 5 3.2.3 DeliverToCompID ........................................................................................... 5 3.2.4 Addresses of FIX Servers .............................................................................. 5 3.2.5 Heartbeat Interval........................................................................................... 5 3.2.6 TransactTime ................................................................................................. 5 4 Session Management ........................................................................................ 6 4.1 Message header format to Kai-X ....................................................................... 6 4.2 Message header format to Client ...................................................................... 6 4.3 Message trailer format ...................................................................................... 7 4.4 Logon ................................................................................................................ 7 4.4.1 Logon Request ............................................................................................... 7 4.4.2 Logon Response ............................................................................................ 7 4.4.3 Logon Failure ................................................................................................. 7 4.5 Administrative messages .................................................................................. 7 4.5.1 Heartbeat messages ...................................................................................... 7 4.5.2 Others ............................................................................................................ 8 4.6 Logout Messages .............................................................................................. 8 4.7 Reject Messages .............................................................................................. 8 4.8 Recovery ........................................................................................................... 8 5 Application Messages ....................................................................................... 9 5.1 Symbologies ..................................................................................................... 9 5.1.1 Symbol Tags .................................................................................................. 9 5.2 Order Entry ....................................................................................................... 9 5.2.1 Client .............................................................................................................. 9 5.2.1.1 New Order Single ........................................................................................ 9 5.2.1.2 Order Cancel Request............................................................................... 12 5.2.1.3 Order Cancel/Replace Request ................................................................. 13 5.2.2 Kai-X Order Entry Response Messages ....................................................... 13 5.2.2.1 New Order Single Response ..................................................................... 14 5.2.2.2 Order Cancel Acknowledgement ............................................................... 15 5.2.2.3 Order Cancel Reject or Cancel/Replace Reject ......................................... 16 5.2.2.4 Order Cancel/Replace Acknowledgement ................................................. 16 5.2.2.5 Unsolicited Order Cancel Response .......................................................... 17 5.2.2.6 Execution Report – Indicative Fill .............................................................. 17 5.2.2.7 Execution Correction – ToSTNeT Confirmation ......................................... 18 5.2.2.8 Execution Cancel – ToSTNeT Rejection or Manual Cancel ....................... 20


© 2018 Chi-X Global Technology Page ii 23-Jul-2018/Version 1.37 CONFIDENTIAL

5.2.2.9 Unsupported FIX Messages ...................................................................... 21 5.3 Order Status ................................................................................................... 21 5.3.1 Done For Day Order Status Messages ......................................................... 21 5.3.1.1 Done For Day Order Report ...................................................................... 21 5.3.2 Kai-X Peg Order Status Messages ............................................................... 21 5.3.2.1 Peg Order Suspended Report ................................................................... 21 5.3.2.2 Peg Order Resume Report ........................................................................ 22 5.4 Matching Session Status ................................................................................. 22 6 Appendix – Order State Change Matrices ...................................................... 23 6.1 Filled order ...................................................................................................... 23 6.2 Cancel request issued for a zero-filled order ................................................... 24 6.3 Cancel request issued for a part-filled order – executions occur while cancel request is active ...................................................................................................... 24 6.4 Cancel request issued for an order that becomes filled before cancel request can be accepted ...................................................................................................... 25 6.5 Zero-filled order, followed by cancel/replace request to decrease order qty .... 26 6.6 Partially filled order, followed by cancel/replace request to decrease order qty, execution occurs while order is pending replace ...................................................... 27 6.7 Cancel/replace request sent while execution is being reported – requested order qty exceeds cum qty. Order is replaced then filled ......................................... 28 6.8 Cancel/replace request sent while execution is being reported – requested order qty equals cum qty. Order is amended to cum qty ......................................... 29 6.9 Cancel/replace request sent while execution is being reported – requested order qty is below cum qty. Order is amended to cum qty ....................................... 30 6.10 Cancel/replace request sent which is accepted – another one sent which is also accepted .......................................................................................................... 31 6.11 Order rejected due to duplicate ClOrdID ....................................................... 32 6.12 Poss resend order ......................................................................................... 33 6.13 Fill or Kill order that cannot be filled .............................................................. 33 6.14 Immediate or Cancel order that is partially filled ............................................ 33 6.15 Fully filled order (1 indicative fill), followed by cancellation of indicative fill .... 34 6.16 Fully filled order (multiple indicative fills), followed by cancellation of 1 indicative fill ............................................................................................................. 35 6.17 Partially filled order (multiple indicative fills), followed by cancellation of 1 indicative fill ............................................................................................................. 35 6.18 Partially filled order (1 indicative fill), followed by cancellation of indicative fill, then fully filled .......................................................................................................... 36 7 Appendix B – Kai-X PEG Order Definitions .................................................... 37 7.1 Primary (PRIM) Peg Type ............................................................................... 37 7.1.1 Basic Primary Peg ........................................................................................ 37 7.2 Mid (MID) Peg Type ........................................................................................ 38 7.2.1 Basic Mid Peg .............................................................................................. 38 7.3 Market (MKT) Peg Type .................................................................................. 38 7.3.1 Basic Market Peg ......................................................................................... 38

FIGURES

Figure 1: Relevant Document(s) ............................................................................... 1 Figure 2: Revision History ......................................................................................... 2 Figure 3: Message Header Format to Kai-X.............................................................. 6 Figure 4: Message Header Format to Client ............................................................. 6 Figure 5: Message Trailer Format ............................................................................. 7 Figure 6: Logon Request .......................................................................................... 7


© 2018 Chi-X Global Technology Page iii 23-Jul-2018/Version 1.37 CONFIDENTIAL

Figure 7: New Order Single .................................................................................... 12 Figure 8: Order Cancel Request ............................................................................. 12 Figure 9: Order Cancel / Replace Request ............................................................. 13 Figure 10: New Order Single Response ................................................................. 15 Figure 11: Order Cancel Acknowledgement ........................................................... 15 Figure 12: Order Cancel Reject or Cancel/Replace Reject ..................................... 16 Figure 13: Order Cancel/Replace Acknowledgement ............................................. 17 Figure 14: Unsolicited Order Cancel Response ....................................................... 17 Figure 15: Execution Report – Indicative Fill ............................................................ 18 Figure 16: Execution Correction – ToSTNeT Confirmation ...................................... 19 Figure 17: Execution Cancel – ToSTNeT Rejection or Manual Cancel .................... 20 Figure 18: Done for Day Order Report ..................................................................... 21 Figure 19: Peg Order Suspended Report ............................................................... 22 Figure 20: Peg Order Resume Report .................................................................... 22

© 2018 Chi-X Global Technology, LLC. All rights reserved.

The copyright in the whole and every part shall not be copied or reproduced in whole or any part in any manner or form or in or on any media without the prior written consent of Chi-X Global Technology (“Chi-Tech”).


© 2018 Chi-X Global Technology Page 1 23-Jul-2018/Version 1.37 CONFIDENTIAL

1 Introduction

This document is a protocol specification of the system interface between Kai-X and the participants. The system interface allows participants to submit orders, replace / cancel orders as well as receiving executions from Kai-X.

Kai-X uses the industry-wide adopted protocol: FIX – Financial Information eXhange protocol. It is an open message standard controlled by no single entity and can be structured to fulfil business requirements of different firms.

The standard documents of FIX protocol specification can be obtained from:

http://www.fixprotocol.org

This document provides the specific usage of the FIX protocol in Kai-X. Audiences should refer to the standard FIX protocol specification for basics, for instance, the data type representations etc.

1.1 Relevant documents

ITEM TITLE VERSION DATE

Figure 1: Relevant Document(s)

1.2 Revision History

ITEM REVISION HIGHLIGHT DOCUMENT REFERENCE

DATE

1 Initial version 1.00 23-Feb-2016

2 Updated ToSTNeT custom tag number

Updated broker preference tag description

Removed cash margin and broker preference from cancel and replace response

1.01 17-Mar-2016

3 Added post only order type

Added primary and market peg types

Updated indicative fill cancellation scenarios

1.02 14-Apr-2016

4 Added custom tags to return ToSTNeT order id and execution id in execution correction message

1.03 18-Apr-2016

5 Added MaxFloor description

Added unsolicited order cancel response

Removed NoSelfTrade from Order Cancel Response

1.04 9-May-2016

6 Added ClientID to Unsolicited Order Cancel Response

1.05 27-May-2016

7 Added TransactTime to Order Cancel Response and Unsolicited Order Cancel Response

1.06 13-Jun-2016

8 Updated CashMargin tag to only accept cash 1.07 17-Jun-2016

9 Updated MinQty description 1.08 21-Jul-2016

10 Added limit price (tag 44) to execution report, execution correction, execution cancel

1.09 3-Aug-2016

11 Updated CashMargin tag (8104) description 1.10 23-Aug-2016

12 Added custom tags (8031, 8032, 8033) to return primary exchange last traded, best bid, best ask, inside execution report and execution correction

1.20 25-Aug-2016

13 Updated ExecType in appendix 6.3 scenario Updated PrimaryLastPx (8031) description

1.21 26-Oct-2016

14 Added PriceProtectionScope (tag 1092) to enable dynamic limit price Added NoTradeKey (tag 7714) to enable broker independent self-trade prevention Added LastLiquidityInd (tag 851) to execution report and execution correction

1.30 15-Dec-2016

15 Updated PriceProtectionScope (tag 1092) description 1.31 19-Dec-2016

16 Updated Order State Change Matrices in appendix 1.32 29-Dec-2016

http://www.fixprotocol.org/



6.3, 6.8, 6.9, 6.14

17 Added custom tag Indicative (6226) to flag indicative fill, trade correction, and trade cancel

1.33 24-Mar-2017

18 Updated MinQty description in 5.2.1.1, 5.2.1.3 Updated NoTradeKey, NoSelfTrade description in 5.2.1.1 Updated Price description in 5.2.1.3 Updated required flag of ClOrdID, OrdType, OrderCapacity, MaxFloor in 5.2.2.1, 5.2.2.4 Added description for required=N tags for reject responses Standardized description of OrderQty, Price, Side, Symbol, TimeInForce in all responses Standardized OrigClOrdID description

1.34 8-May-2017

19 Add OrderClassification(8060) in 5.2.1.1, 5.2.2.1 1.35 9-Nov-2017

20 Change CashMargin tag from 8104 to 544 Updated CashMargin(544) description in 5.2.1.1, 5.2.2.1, 5.2.2.6, 5.2.2.7 Removed CashMargin(8104) from 5.2.1.1, 5.2.1.3, 5.2.2.1,5.2.2.4

1.36 23-Jul-2018

21 Update description of TransactTime(60) about nanosecond precision in

3.2.6,

5.2.2.1, 5.2.2.2, 5.2.2.4, 5.2.2.5,

5.2.2.6, 5.2.2.7, 5.2.2.8

1.37 23-Jul-2018

Figure 2: Revision History



2 FIX Interface

FIX Protocol specification is a generic protocol where there can be different possible implementations. This chapter describes the Kai-X specific implementation of the FIX protocol on a high level.

2.1 Supported FIX Version

Kai-X system interface supports FIX Version 4.2.

2.2 Network Transport

FIX was written to be independent of any specific communication protocol. In Kai-X, the network transport for the FIX Interface is TCP.

2.3 FIX Protocol Syntax

There are two FIX Protocol Syntax defined in the standard. Kai-X uses the “Tag=Value” syntax.

2.4 Message Format1

The general format of a FIX message is a standard header followed by the message body fields and terminated with a standard trailer.

Each message is constructed with a stream of <tag>=<value> fields with a field delimiter between fields in the stream. Tags are of data type TagNum. All tags must have a value specified. Optional fields without values should simply not be specified in the FIX message. A Reject message is the appropriate response to a tag with no value.

Except where noted, fields within a message can be defined in any sequence (Relative position of a field within a message is inconsequential.) The exceptions to this rule are:

1. General message format is composed of the standard header followed by the body followed by the standard trailer.

2. The first three fields in the standard header are BeginString (tag #8) followed by BodyLength (tag #9) followed by MsgType (tag #35).

3. The last field in the standard trailer is the CheckSum (tag #10).

Field Delimiter:

All fields in a FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" (#001, hex: 0x01, referred to in this document as <SOH>), is used for field termination. Messages are delimited by the “SOH” character following the CheckSum field. All messages begin with the “8=FIX.x.y<SOH>” string and terminate with “10=nnn<SOH>“.

2.5 Data Types:

Please refer to the standard FIX protocol specification.

1 Part of this section is taken from the official FIX protocol specification, please refer to www.fixprotocol.org



3 Configuration Information

Before a client can connect to the FIX system interface, there are some configuration parameters that must be agreed between both parties.

3.1 Client Configuration

Client is responsible to initiate a TCP connection to the Kai-X FIX server.

3.1.1 SenderCompID

Clients must identify the session in the SenderCompID (49) field. The value of the SenderCompID must be approved by Kai-X administrator beforehand. This value is case sensitive and the maximum size is 32 characters.

3.1.2 TargetCompID

TargetCompID must identify the receiving firm, which in the normal case is the owner of Kai-X. The administrator of Kai-X will provide the TargetCompID to the clients.

3.1.3 OnBehalfOfCompID

OnBehalfOfCompID (115) is used to identify the firm originating the message when the message was delivered by a third party like a Broker Service Provider or Execution Management System. The third party firm identifier would be delivered in the SenderCompID field. This field always contains a valid Participant ID.

3.1.4 Encryption

Kai-X does not support encryption of FIX messages.



3.2 Kai-X Configuration

3.2.1 SenderCompID

The value the client will receive in the SenderCompID field from Kai-X will be the value originally supplied to Kai-X in the TargetCompID field in the logon message.

3.2.2 TargetCompID

The value the client will receive in the TargetCompID field from Kai-X will be the value originally supplied to Kai-X in the SenderCompID field in the logon message.

3.2.3 DeliverToCompID

DeliverToCompID (128) is used to identify the firm targeted to receive the message if the message is delivered by a third party like a Broker Service Provider or Execution Management System. The third party firm identifier would be delivered in the TargetCompID field. Value in OnBehalfOfCompID (115) received from the client will be sent back in this field.

3.2.4 Addresses of FIX Servers

Administrator of Kai-X will provide clients with the following:

IP-addresses and port numbers of Kai-X FIX servers.

3.2.5 Heartbeat Interval

The default heartbeat interval for the FIX connection is set to 30 seconds unless otherwise agreed with the participants.

3.2.6 TransactTime

Each session can be configured to send TransactTime(60) Tags in either format YYYYMMDDHH:MM:SS.sss or YYYYMMDD-HH:MM:SS.nnnnnn000 in CTS Order Entry Response Message. The millisecond format is used by default. Clients should contact administrator of CTS to do the setup accordingly if nanosecond format is preferred



4 Session Management

This section describes session-level FIX messages sent between Kai-X and the clients.

In a general production Kai-X setup, multiple FIX servers are installed for each client. One of the FIX servers functions as a Primary while the others function as a Standby server. Clients should first initiate the session to the Primary FIX server. If the connection fails, clients should retry the primary connection after 30 seconds. If the primary re-connection is still not possible, client can connect to the standby server. For message recovery handling, please refer to section 4.8 Recovery.

4.1 Message header format to Kai-X

Kai-X processes only the following fields in the message header and ignores all others:

TAG FIELD NAME REQ’D

COMMENTS

8 BeginString Y FIX.4.2

9 BodyLength Y Must be the second field in the message.

35 MsgType Y Must be the third field in the message.

34 MsgSeqNum Y See standard FIX protocol specification

43 PossDupFlag N Always required for retransmissions, whether prompted by the sending system or as the result of a resend request.

49 SenderCompID Y The value used must be recognized and agreed to by Kai-X

52 SendingTime Y Indicates the time the message was sent by the client.

56 TargetCompID Y Please use the value as provided by Kai-X administrator

97 PossResend N Required when message may be duplicate of another message sent under a different sequence number.

115 OnBehalfOfCompID N Required only if the message is sent via a third party and is present only in the order-related messages listed in Section 5.2 and 5.3.

Figure 3: Message Header Format to Kai-X

4.2 Message header format to Client

Kai-X processes only the following fields in the message header and ignores all others:


COMMENTS

8 BeginString Y FIX.4.2

9 BodyLength Y Must be the second field in the message.

35 MsgType Y Must be the third field in the message.

34 MsgSeqNum Y See standard FIX protocol specification

43 PossDupFlag N Always required for retransmissions, whether prompted by the sending system or as the result of a resend request.

49 SenderCompID Y The value originally supplied to Kai-X in the TargetCompID field in the logon message from the Client.

52 SendingTime Y Indicates the time the message was sent by Kai-X.

56 TargetCompID Y The value originally supplied to Kai-X in the SenderCompID field in the logon message from the Client.

97 PossResend N Required when message may be duplicate of another message sent under a different sequence number.

128 DeliverToCompID N Required only if the message is sent via a third party and is present only in the order-related messages listed in Section 5.2 and 5.3.

Figure 4: Message Header Format to Client



4.3 Message trailer format

Kai-X processes only the following fields in the message trailer and ignores all others:


COMMENTS

10 CheckSum Y (Always unencrypted, always last field in message)

Figure 5: Message Trailer Format

4.4 Logon

4.4.1 Logon Request

The logon message authenticates a user establishing a connection to Kai-X. The logon message must be the first message sent to Kai-X by client.

Kai-X processes only the following fields in the message trailer and ignores all others:


COMMENTS

Message Header Y MsgType=A

98 EncryptMethod Y Always unencrypted. Must send a value = 0

108 HeartBtInt Y Default value used by Kai-X is 30. Please set this to 30 unless otherwise agreed with Kai-X administrators.

Message Trailer Y

Figure 6: Logon Request

Notes:

The sequence number, on the initial logon for each day, must be set to “1”.

If a client receives a sequence number less than expected, the client must terminate their session immediately, and should then contact Kai-X administrator to correct the problem, as per the FIX protocol.

4.4.2 Logon Response

Once Kai-X receives a Logon request, it validates the SenderCompID and performs a recovery process (see section titled Recovery). No messages should be sent to Kai-X until a Logon message is received in reply from Kai-X.

When Kai-X returns a positive Logon response, the client can start performing the following:

Start the heartbeat timer

Start to exchange message

4.4.3 Logon Failure

If the authentication fails, Kai-X shutdowns the connection and no Logout message is sent before the termination.

4.5 Administrative messages

This section describes the minimum requirements to keep the session alive and synchronized.

4.5.1 Heartbeat messages

Kai-X must receive a message from the client at least once in the heartbeat interval (default to 30 seconds) defined in the logon. If the session is idle and no message is received in two



heartbeat interval, Kai-X considers the session is dead. A Logout message is sent to the client and the session is disconnected.

Kai-X sends a message at least once in the heartbeat interval.

4.5.2 Others

Kai-X handles the following administration messages:

Resend Request

Sequence Reset

Test Request

Please note that the tag OrigSendingTime (122) is ignored by Kai-X in all messages.

4.6 Logout Messages

The logout message initiates or confirms the termination of a FIX session. Disconnection without the exchange of the logout message messages should be interpreted as an abnormal condition, for instance, network level disconnection.

There are other scenarios where the client’s FIX session would be disconnected, depending on the situation, Kai-X may or may not wait the logout response message from the client before terminating the connection:

Idle session with no message after two heartbeat intervals.

Kai-X administrator force logout upon client’s misbehaviour

Kai-X maintenance period.

4.7 Reject Messages

Reject messages sent by Kai-X includes the sequence number of the rejected message with the reject reason in the text field, whenever possible.

When Kai-X receives a message with a sequence number less than expected during normal session processing and the message lacks of a PossDupFlag field or with the PossDupFlag field set to “N”, the message is discarded and a Reject message is sent to the client.

4.8 Recovery

When a client reconnects after a break in the session during the same day, Kai-X begins the following recovery sequence:

If Kai-X receives a sequence number less than expected the session will be terminated immediately without sending a logoff. The client should contact Kai-X operators to correct the problem.

Kai-X transmits any unsent execution reports upon receipt of a Resend Request from the client for the missing sequence numbers. If executions occur while the FIX session is down, Kai-X outgoing sequence number will be higher than expected by the client.

When a FIX session is terminated, all open orders will remain open on Kai-X.

It is the responsibility of the client to detect any message gaps after a connection break. If the incoming sequence number is greater than expected, a retransmission of the messages can be requested by sending the “Resend Request” to Kai-X.



5 Application Messages

This section discusses the application-level FIX messages sent and accepted by Kai-X.

5.1 Symbologies

Kai-X supports only the following stock naming identifiers in FIX messages (in order of preference):

1. Chi-X Japan Symbol

2. QUICK

3. RIC

4. ISIN

5. Exchange Symbol (TSE)

5.1.1 Symbol Tags

When Kai-X receives a FIX application-level client message, it processes the symbol definition fields in the message in the following order to yield a valid security symbol:

If the client selects to use ISIN, QUICK or Exchange Symbol to identify securities, the client must:

1. Set the IDSource (22) field to ISIN (4), QUIK (3), or Exchange Symbol (8);

2. Put the ISIN value, QUICK code or Exchange Symbol into the SecurityID (48) field; and

3. Use the SecurityExchange (207) field to identify which market the ISIN, QUICK code or Exchange Symbol executes in. Client requests are rejected if SecurityExchange (207) is not specified for ISIN, QUIK or Exchange Symbol.

If the client selects to use RIC to identify stocks, the client must:

1. Set the IDSource (22) field to RIC (5);

2. Put the RIC code into the SecurityID (48) field.

If the IDSource (22) field is not set, Kai-X expects the Chi-X Japan Symbol to exist in the Symbol (55) field.

If the IDSource (22) field is set, it is recommended to put the security code into the mandatory field Symbol (55) as well.

SecurityExchange (207) is not required for RIC and Chi-X Japan Symbol since these symbols can uniquely identify securities listed in different exchanges. In FIX 4.2 SecurityExchange code for Tokyo Stock Exchange is:

“T” – Tokyo Stock Exchange

5.2 Order Entry

5.2.1 Client

Kai-X currently supports the New Order Single, Order Cancel Request, Order/Cancel Replace Request FIX messages.

5.2.1.1 New Order Single

In addition to the standard header and trailer, Kai-X processes only the following fields in a New Order Single message and ignores all others:




COMMENTS

Message Header Y MsgType=D

1 Account N It can be used by a participant to provide a broker cross reference. Max length is 10 characters.

11 ClOrdID Y Must be unique for each order throughout the day, across all stocks and sides from the same FIX Session ID. Max length is 32 characters

18 ExecInst Y Values supported:

Pegging options (mutually exclusive)

P = Market Peg

R = Primary Peg

M = Mid-price Peg

21 HandlInst Y 1 = Automated execution order, private, no Broker intervention.

NOTE: Values other than 1 will cause the order to be rejected.

22 IDSource N 3 = QUIK

4 = ISIN Number

5 = RIC

8 = Exchange Symbol

38 OrderQty Y Quantity of order. It is positive integer number and max value is 2147483647.

40 OrdType Y P = Pegged (requires ExecInst = M or R or P)

44 Price N Optional for pegged orders, indicating a limit price for the order.

It is positive decimal in format:

"[max 12 digits whole number].[max 7 digits decimal place]"

It may contain leading zeros or trailing zeros. Max value is "100,000,000,000.0000000".

47 OrderCapacity Y A = Agency single order

P = Principal

48 SecurityID N QUICK, RIC or ISIN depending upon the value of the IDSource (22).

54 Side Y 1 = Buy

2 = Sell

5 = Sell short

6 = Sell short exempt

Sell short and Sell short exempt will be treated as Sell (2) for both matching and ToSTNeT reporting.

55 Symbol Y Chi-X Japan Symbol

59 TimeInForce N Absence of this field indicates a day order.

0 = Day – Day orders are in effect until the client cancels the order, or until the Kai-X system is shut down for maintenance

3 = Immediate or Cancel - As much of the order as possible must be executed immediately. Any part of the order that is not executed immediately gets cancelled.

4 = Fill Or Kill (FOK) – Fill the order in its entirety or cancel it immediately.

60 TransactTime Y Time this order request was initiated by client. This field is ignored by Kai-X.

110 MinQty N Minimum quantity of an order to be executed. When the residual quantity falls below the specified minimum quantity, residual quantity will be used as minimum quantity.

Incoming MinQty must conform to the security lot size.

Value of 0 is treated as no MinQty supplied.

111 MaxFloor N Absence of this field indicates MaxFloor = 0

If supplied by client, MaxFloor must be 0 Any other value supplied by the client will cause the order to be rejected.

207 SecurityExchange N Required when the IDSource (Field ID 22) equals ISIN (4), QUIK (3) or Exchange Symbol (8)

Note: uses to specify the Market for the ISIN number or the




COMMENTS

QUICK code.

“T” = Tokyo Stock Exchange

544 CashMargin N “1” = Cash

Absence of this field indicates Cash order.

Any other value supplied by the client will cause the order to be rejected.

1092 PriceProtectionScope N This field indicates whether the order will use the latest primary exchange day high and day low as limit price when the order is re-priced. This tag can only be specified in new order message and cannot be modified afterwards.

Value supported:

1= Enable dynamic limit price

If an explicit limit price (tag 44) is also specified on a dynamic limit price order,

Min(tag 44, latest primary day high) will be the effective limit price for buy order when it is re-priced

Max(tag 44, latest primary day low) will be the effective limit price for sell order when it is re-priced

7714 NoTradeKey N Orders with the same value in NoTradeKey will not be matched against each other, regardless of participant. If the order is not fully-filled, the order will rest on the book.

It is a positive integer and max value is 2147483647.

8021 PostOnly N This field indicates order is post only, i.e. it will not take liquidity. If there is matching opportunity when a post only order is sent to Kai-X, the post only order will be cancelled. Otherwise, the post only order will be entered into the order book for subsequent matching.

TimeInForce(59) cannot be IOC(3) and FOK(4).

Value supported: P = Post or cancel

8060 OrderClassification N Specify the Order Classification. Supported values:

1 = Non Low Latency Trading (Auto)

2 = Non Low Latency Trading (Manual)

3 = Market Making Strategy

4 = Arbitrage Strategy

5 = Directional Strategy

6 = Other Strategy

8174 NoSelfTrade N Identified as Self-Trade Prevention (STP) order.

Orders from the same participant with the same NoSelfTrade key will not be allowed to match with each other. If the order is not fully-filled, the order will rest on the book.

It is a positive integer and max value is 2147483647.

8182 OrderRestrictions N Broker Preferencing logic can ONLY be enabled/disabled by contacting Market Operations to request that it be configured as a default setting on a per FIX Gateway basis. If a participant elects to have broker preferencing enabled on the session, orders will be treated as broker preferencing without the need for any custom tag. Tag <8182> can be used to disable the broker preference on a per order basis provided that the override order has TIF = 3 (IOC) or 4 (FOK).

I = Override broker preference default setting




COMMENTS

Message Trailer Y

Figure 7: New Order Single

5.2.1.2 Order Cancel Request

Kai-X processes a Cancel Request quantity as the full remaining quantity. Kai-X does not support partial cancels.

In addition to the standard header, trailer, and Kai-X accepted symbol definition fields, Kai-X processes only the following fields in an Order Cancel Request message, and ignores all others:


COMMENTS

Message Header Y MsgType=F

11 ClOrdID Y Unique ID of cancel request as assigned by the client.

Max length is 32 characters

41 OrigClOrdID Y ClOrdID of the previous order (not the initial order) as assigned by the client.


54 Side Y For conformance to FIX specification, not processed by Kai-X.

55 Symbol Y For conformance to FIX specification, not processed by Kai-X.

60 TransactTime Y Time this order request was initiated by client.

Message Trailer Y

Figure 8: Order Cancel Request



5.2.1.3 Order Cancel/Replace Request

Cancel/Replace requests are handled as per the FIX protocol. Cancel/Replace requests that cannot be processed are rejected using the Cancel Reject message. If Kai-X rejects the Cancel/Replace request, the ClOrdID of the replacement order is inserted in the ClOrdID field of the Cancel Reject message for identification purposes.

In addition to the standard header, trailer, and Kai-X accepted symbol definition fields, Kai-X processes only the following fields in an Order Cancel/Replace Request message, and ignores all others.


COMMENTS

Message Header Y MsgType=G

11 ClOrdID Y Unique ID of replacement order as assigned by the client.


18 ExecInst Y For a replacement order, this field must be populated anew (i.e. original order values will not be brought forward to replacement order unless redefined within this message).

21 HandlInst Y For conformance to FIX specification, not processed by Kai-X.

38 OrderQty Y Note: The quantity in the Cancel/Replace message is the total order quantity, as defined by the FIX protocol and total order quantity semantics.

40 OrdType Y For conformance to FIX specification, not processed by Kai-X.



44 Price N Optional for pegged orders, indicating a limit price for the order.

It is positive decimal in format:

"[max 12 digits whole number].[max 7 digits decimal place]"

It may contain leading zeros or trailing zeros. Max value is "100,000,000,000.0000000".

If this tag is omitted, the limit price of the order will be removed.

54 Side Y For conformance to FIX specification, not processed by Kai-X.

55 Symbol Y For conformance to FIX specification, not processed by Kai-X.

59 TimeInForce N If this tag is omitted, the order will be reset to a day order.

60 TransactTime Y Time this order request was initiated by client.

110 MinQty N MinQty must conform to the security lot size.

If this tag is omitted, the MinQty of the order will be removed.

If this tag is supplied and value is 0, MinQty of the order will be removed.

111 MaxFloor N If this tag is supplied, it must be 0

7714 NoTradeKey N Refer to New Order Single message for description.

If this tag is omitted, the value of NoTradeKey of the order will be cleared, i.e. reset to normal order without self-trade prevention.

8174 NoSelfTrade N Refer to New Order Single message for description.

If this tag is omitted, the value of NoSelfTrade of the order will be cleared, i.e. reset to normal order without self-trade prevention.

Message Trailer Y

Figure 9: Order Cancel / Replace Request

5.2.2 Kai-X Order Entry Response Messages

For reject responses, tags marked with required=N may not be returned if the tag value in the incoming request fails validation.



5.2.2.1 New Order Single Response

In addition to the standard header, trailer and Kai-X accepted symbol definition fields, Kai-X provides the following fields in an Execution Report message in response to a New Order Single request.


COMMENTS

Message Header Y MsgType=8

1 Account N Kai-X populates this field with the original value supplied in the New Order Single message.

6 AvgPx Y Defaulted to 0 for order acknowledgements.

11 ClOrdID N Kai-X populates this field with the original value supplied in the New Order Single message.

14 CumQty Y Defaulted to 0 for order acknowledgements.

17 ExecID Y A unique identifier of execution message as assigned by Kai-X.

20 ExecTransType Y 0 = New

31 LastPx Y Default to 0 for order acknowledgements.

32 LastShares Y Default to 0 for order acknowledgements.

37 OrderID Y Kai-X order reference number.

38 OrderQty Y Kai-X populates this field with the original value supplied in the New Order Single message.

39 OrdStatus Y 0 = New

8 = Rejected

40 OrdType N Kai-X populates this field with the original value supplied in the New Order Single message.

44 Price N Will be returned with the original value if supplied in the New Order Single message.

47 OrderCapacity N Kai-X populates this field with the original value supplied in the New Order Single message.

54 Side Y Kai-X populates this field with the original value supplied in the New Order Single message.

55 Symbol Y Kai-X populates this field with the original value supplied in the New Order Single message. However, if IDSource and SecurityID are specified and they refer to a valid Chi-X Japan symbol, the Chi-X Japan symbol will be populated to this Symbol field.

58 Text N Reason for order rejection if available

59 TimeInForce N Will be returned if supplied in the original New Order Single message. 0 will be returned if not supplied.

60 TransactTime N Time of new order acknowledgement (expressed as GMT).

If nanoseconds is enabled by the administrator:

YYYYMMDD‐HH‐MM‐SS.nnnnnn000

76 ExecBroker N Identifier of a participant

109 ClientID N Internal connection ID of the client assigned by Kai-X

110 MinQty N Will be returned if supplied in the original New Order Single message.

111 MaxFloor N Will be returned if supplied in the original New Order Single message. 0 will be returned if not supplied.

150 ExecType Y 0 = New 8 = Rejected

151 LeavesQty Y Amount of shares open for further execution.

544 CashMargin N Will be returned if valid value is supplied in the original New Order Single message.

1092 PriceProtectionScope N Will be returned if supplied in the original New Order Single message.

7714 NoTradeKey N Will be returned if supplied in the original New Order Single message.

8021 PostOnly N Will be returned if supplied in the original New Order Single message.

8060 OrderClassification N Will be returned if valid value is supplied in the original New Order Single message.

8174 NoSelfTrade N Will be returned if supplied in the original New Order Single message.

8182 OrderRestrictions N Will be returned if supplied in the original New Order Single



message.

Message Trailer Y

Figure 10: New Order Single Response

5.2.2.2 Order Cancel Acknowledgement

In addition to the standard header, trailer and Kai-X accepted symbol definition fields, Kai-X provides the following fields in an Execution Report message when accepting an order cancel request.

Tag FIELD NAME REQ’D

COMMENTS


6 AvgPx Y The average price of all shares executed.

11 ClOrdID Y Kai-X populates this field with the value assigned by the client in the corresponding Order Cancel Request message

14 CumQty Y Total shares executed.

17 ExecID Y A unique identifier of execution message as assigned by Kai-X

20 ExecTransType Y 0 = New.

31 LastPx Y Default to 0 for order cancel acknowledgements.

32 LastShares Y Default to 0 for order cancel acknowledgements.


38 OrderQty Y Kai-X populates this field with the order’s latest value.

39 OrdStatus Y 4 = Canceled.

40 OrdType N Kai-X populates this field with the order’s original value.


44 Price N Kai-X populates this field with the order’s latest value.

54 Side Y Kai-X populates this field with the order’s original value.

55 Symbol Y Kai-X populates this field with the order’s original value.

59 TimeInForce N Kai-X populates this field with the order’s latest value.

60 TransactTime N Time of cancel acknowledgement (expressed as GMT).




150 ExecType Y 4 = Canceled.

151 LeavesQty Y 0

Message Trailer Y

Figure 11: Order Cancel Acknowledgement



5.2.2.3 Order Cancel Reject or Cancel/Replace Reject

In addition to the standard header, trailer and Kai-X accepted symbol definition fields, Kai-X provides the following fields in an Order Cancel Reject message when rejecting an order cancel request or an order cancel/replace request.


COMMENTS


11 ClOrdID Y Kai-X populates this field with the value assigned by the client in the corresponding Order Cancel Request or Order Replace Request message


39 OrdStatus Y OrdStatus value after this reject is applied.


58 Text N Text message explaining rejection reason.

434 CxlRejResponseTo Y Type of request to which this is a response:

1=Order Cancel Request

2=Order Cancel/Replace request

Message Trailer Y

Figure 12: Order Cancel Reject or Cancel/Replace Reject

5.2.2.4 Order Cancel/Replace Acknowledgement

In addition to the standard header, trailer and Kai-X accepted symbol definition fields, Kai-X provides the following fields in an Execution Report message when accepting an order cancel/replace request.


COMMENTS


1 Account N Kai-X populates this field with the order’s latest value.

6 AvgPx Y The average price of all shares executed.

11 ClOrdID N Kai-X populates this field with the value assigned by the client in the corresponding Order Cancel / Replace Request message.


17 ExecID Y A unique identifier of execution message as assigned by Kai-X.

20 ExecTransType Y 0 = New

31 LastPx Y Default to 0 for Order Cancel / Replace Acknowledgement.

32 LastShares Y Default to 0 for Order Cancel / Replace Acknowledgement.



39 OrdStatus Y 1 = Partially filled

5 = Replaced



44 Price N Will be returned if supplied in order replace request.

47 OrderCapacity N Kai-X populates this field with the order’s latest value.



59 TimeInForce N Will be returned if supplied in order replace request.

0 will be returned if not supplied in order replace request.

60 TransactTime N Time of cancel/replace acknowledgement (expressed as GMT).



76 ExecBroker N Identifier of a participant


110 MinQty N Will be returned if supplied in order replace request.

0 will be returned if MinQty is removed.



111 MaxFloor N Kai-X populates this field with the order’s latest value.

150 ExecType Y 5 = Replaced


7714 NoTradeKey N Will be returned if supplied in order replace request.

8174 NoSelfTrade N Will be returned if supplied in order replace request.

Message Trailer Y

Figure 13: Order Cancel/Replace Acknowledgement

5.2.2.5 Unsolicited Order Cancel Response

An unsolicited order cancel response is generated if order is cancelled by Kai-X. For example, an IOC order, or post-only order that would take liquidity on initial entry.

In addition to the standard header, trailer and Kai-X accepted symbol definition fields; Kai-X provides the following fields in an Execution Report message:


COMMENTS


6 AvgPx Y The average price of all shares traded.

11 ClOrdID Y Kai-X populates this field with the order’s latest value.



20 ExecTransType Y 0 = New.

31 LastPx Y Default to 0 for unsolicited order cancel response

32 LastShares Y Default to 0 for unsolicited order cancel response



39 OrdStatus Y 4 = Cancelled.


41 OrigClOrdID Y Same as ClOrdID




58 Text N Reason for unsolicited cancel


60 TransactTime N Time of unsolicited cancel acknowledgement (expressed as GMT).




150 ExecType Y 4 = Cancelled.

151 LeavesQty Y 0

Message Trailer Y

Figure 14: Unsolicited Order Cancel Response

5.2.2.6 Execution Report – Indicative Fill

Kai-X sends matching reports via the Execution Report messages. The matching report provides fill information as orders are matched, including: average price of shares executed; total shares executed against the original order quantity; transaction time; and execution date. Please note that this does not include settlement information such as commission or tax information.

NOTE: The ExecID is considered to be the unique identifier of an execution message by Kai-X, as per the FIX protocol. It is the client’s responsibility to detect and appropriately process possible duplicate ExecIDs, regardless of whether the PossResend flag has been set on the message or not.



In addition to the standard header, trailer, and Kai-X accepted symbol definition fields, Kai-X provides only the following fields in an Execution Report:

TAG FIELD NAME REQ’D COMMENTS



6 AvgPx Y Average price of shares executed.

11 ClOrdID Y Kai-X will populate this field with the ClOrdID from the current state of the order



20 ExecTransType Y 0 = New – New indicative fill

29 LastCapacity Y Supported values are 1 = Agent

2 = Cross as agent

3 = Cross as principal

4 = Principal

Values of 2 or 3 essentially indicate that the client has executed again themselves.

31 LastPx Y Price of shares bought or sold on this fill.

32 LastShares Y Quantity of shares bought or sold on this fill.




2 = Filled



47 OrderCapacity Y Kai-X populates this field with the order’s latest value.




60 TransactTime N Time and date of execution in Kai-X (expressed as GMT).




150 ExecType Y 1 = Partially filled

2 = Filled


375 ContraBroker Y JSDA member number of the contra broker for confirmed execution

544 CashMargin N Will be returned if value is supplied in the original New Order Single message.

851 LastLiquidityInd N Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity.

Valid values:

1 = Added Liquidity

2 = Removed Liquidity

6226 Indicative Y Y = Is an indicator fill

8031 PrimaryLastPx N Primary exchange last traded price at the time of indicative fill

8032 PrimaryBidPx Y Primary exchange best bid price at the time of indicative fill

8033 PrimaryAskPx Y Primary exchange best ask price at the time of indicative fill

Message Trailer Y

Figure 15: Execution Report – Indicative Fill

5.2.2.7 Execution Correction – ToSTNeT Confirmation

After ToSTNeT confirmed the indicative fill, Kai-X sends Execution Correction Report to provide ToSTNeT order ID, execution ID, and transaction time.





COMMENTS







19 ExecRefID Y When ToSTNeT confirmation arrives, this tag will carry the previous execution ID which is to be corrected.

20 ExecTransType Y 2 = Correct – ToSTNeT fill confirmation

29 LastCapacity N Supported values are

1 = Agent

2 = Cross as agent


4 = Principal

Values of 2 or 3 essentially indicate that the client has executed again themselves.

31 LastPx Y Same as previous Indicative Fill value

32 LastShares Y Same as previous Indicative Fill value




2 = Filled











150 ExecType Y 1 = Partially filled

2 = Filled


375 ContraBroker N JSDA member number of the contra broker for confirmed execution

544 CashMargin N Will be returned if value is supplied in the original New Order Single message.

851 LastLiquidityInd N Indicator to identify whether this fill was a result of a liquidity provider providing or liquidity taker taking the liquidity.

Valid values:

1 = Added Liquidity

2 = Removed Liquidity

6226 Indicative Y N = Is not an indicator fill

8031 PrimaryLastPx N Primary exchange last traded price at the time of indicative fill

8032 PrimaryBidPx Y Primary exchange best bid price at the time of indicative fill

8033 PrimaryAskPx Y Primary exchange best ask price at the time of indicative fill

8101 ToSTNeTOrderID Y Order Acceptance Number in ToSTNeT

8102 ToSTNeTExecutionID Y Execution Notice number in ToSTNeT

8106 ToSTNeTTransactTime Y Transaction time in ToSTNeT (expressed as GMT)

Message Trailer Y

Figure 16: Execution Correction – ToSTNeT Confirmation



5.2.2.8 Execution Cancel – ToSTNeT Rejection or Manual Cancel

After ToSTNeT rejected the indicative fill, Kai-X sends Execution Cancel Report to cancel the previous indicative fill and provide the ToSTNeT transaction time. Execution Cancel Report can also be sent if the indicative fill is manually cancelled by operations. Presence or absence of tag 8106 can be used to differentiate between the two cases.



COMMENTS



6 AvgPx Y Average price of shares executed, excluding the cancelled fill.


14 CumQty Y Total shares executed, excluding the cancelled fill.


19 ExecRefID Y This tag will carry the previous execution ID which is to be cancelled.

20 ExecTransType Y 1 = Cancel

29 LastCapacity N 1 = Agent

2 = Cross as agent


4 = Principal Values of 2 or 3 essentially indicate that the client has executed again themselves.

31 LastPx Y Always 0

32 LastShares Y Always 0


38 OrderQty Y OrderQty will not get decremented.

CumQty and LeavesQty will get decremented.

39 OrdStatus Y 0 = New (order has only one fill, then ToSTNeT reject or manual cancel)

1 = Partially filled

2 = Filled






58 Text N Reason for rejection if available






150 ExecType Y 0 = New (order has only one fill, then ToSTNeT reject or manual cancel)

1 = Partially filled

2 = Filled


375 ContraBroker N JSDA member number of the contra broker for confirmed execution

6226 Indicative Y N = Is not an indicator fill

8106 ToSTNeTTransactTime N Transaction time in ToSTNeT (expressed as GMT) if it is ToSTNeT rejection. This tag will not be sent if it is manual cancel.

Message Trailer Y

Figure 17: Execution Cancel – ToSTNeT Rejection or Manual Cancel



5.2.2.9 Unsupported FIX Messages

Aside from messages mentioned in this document, Kai-X does not support any other FIX message types.

5.3 Order Status

5.3.1 Done For Day Order Status Messages

At the end of Continuous Matching Session, outstanding orders will be cancelled and reported by Kai-X to clients.

5.3.1.1 Done For Day Order Report

Kai-X sends done for day order report via the Execution Report messages.


COMMENTS





17 ExecID Y 0

20 ExecTransType Y 3 = Status



39 OrdStatus Y 3 = Done for day




150 ExecType Y 3 = Done for day

151 LeavesQty Y 0

Message Trailer Y

Figure 18: Done for Day Order Report

5.3.2 Kai-X Peg Order Status Messages

When there is problem with reference price source so that pricing information from primary exchanges are not available, corresponding peg order will be suspended from matching until reference price resumes.

5.3.2.1 Peg Order Suspended Report

Kai-X sends peg order suspended report via the Execution Report messages.


COMMENTS





17 ExecID Y 0

20 ExecTransType Y 3 (Status)



39 OrdStatus Y 9 = Suspended






150 ExecType Y 9 = Suspended


Message Trailer Y

Figure 19: Peg Order Suspended Report

5.3.2.2 Peg Order Resume Report

Kai-X sends you peg order resume report via the Execution Report messages.


COMMENTS





17 ExecID Y 0

20 ExecTransType Y 3 = Status



39 OrdStatus Y Last order status before suspended




150 ExecType Y D = Restated


378 ExecRestatementReason

N 3 = Repricing of order

Message Trailer Y

Figure 20: Peg Order Resume Report

5.4 Matching Session Status

Kai-X sends unsolicited “Matching Session Status” message when market opens or closes.

TAG FIELD NAME REQ’D COMMENTS

Message Header Y MsgType=h

58 Text

336 TradingSessionID Y Identifier for matching session (Market)

Valid values:

TYO

325 Unsolicitedindicator Always Y

Y = Message is being sent unsolicited

339 TradeSesMod Y Matching Session Mode

Valid values:

1 = Testing

2 = Simulated

3 = Production

340 TradeSesStatus Y State of the matching session.

Values:

2 = Open 3 = Closed

Message Trailer Y



6 Appendix – Order State Change Matrices

The shaded rows represent messages sent from client to Kai-X

When two lines of a matrix share the same time, this means either

1. There are two possible paths (e.g. a request is accepted or rejected) – in this case the first row of the two possible paths is the reject case which is italicized. The non-italicized row is the path that is continued by the remainder of the matrix.

2. Two messages are being sent at the same time but in different directions such that the messages cross on the connection (e.g. a cancel request is sent at the same time as Kai-X is sending an execution) – in this case both lines have bold text.

6.1 Filled order

Time Message Received (ClOrdID, OrigClOrdID)

Message Sent (ClOrdID, OrigClOrdID)

Exec Type

OrdStatus Exec Trans Type

Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment

1 New Order(X) 10000

2 Execution(X) Rejected Rejected New 10000 0 0 0 If order is rejected

2 Execution(X) New New New 10000 0 10000 0

3 Execution(X) Partial Fill Partially Filled

New 10000 2000 8000 2000 A Indicative fill of 2000


Correct 10000 2000 8000 2000 B (A) ToSTNeT fill confirmation of 2000 ToSTNeT timestamp returned via tag 8106


New 10000 3000 7000 1000 C Indicative fill of 1000

6 Execution(X) Fill Filled New 10000 10000 0 7000 D Indicative fill of 7000

7 Execution(X) Fill Filled Correct 10000 10000 0 1000 E (C) ToSTNeT fill confirmation of 1000

8 Execution(X) Fill Filled Correct 10000 10000 0 7000 F (D) ToSTNeT fill confirmation of 7000



6.2 Cancel request issued for a zero-filled order



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

Comment




3 Cancel Request(Y,X)

10000

4 Cancel Reject (Y,X)

New 10000 If rejected

4 Execution (Y,X)

Canceled Canceled New 10000 0 0 0

6.3 Cancel request issued for a part-filled order – executions occur while cancel request is active



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment





New 10000 2000 8000 2000 A Indicative Fill for 2000


Correct 10000 2000 8000 2000 B (A) ToSTNeT fill confirmation of 2000


10000

5 Execution(X) Partial Fill

Partially Filled

New 10000 5000 5000 3000 C Indicative fill of 3000. This execution passes the cancel request on the connection

6 Execution (X) Partial Fill Partially Filled

New 10000 6000 4000 1000 D Indicative fill of 1000 while order is pending cancel


Partially Filled

10000 If request is rejected


Correct 10000 6000 0 3000 E (C) ToSTNeT fill confirmation of 3000




Correct 10000 6000 0 1000 F (D) ToSTNeT fill confirmation of 1000

9 Execution (Y,X)

Canceled Canceled New 10000 6000 0 0

6.4 Cancel request issued for an order that becomes filled before cancel request can be accepted


Message Sent

(ClOrdID, OrigClOrdID)

Exec

Type

OrdStatus Exec

Trans Type

Order

Qty

Cum

Qty

Leaves

Qty

Last

Shares

ExecId (ExecRefID)

Comment





Partially Filled


4 Execution (X) Partial Fill

Partially Filled



10000


Partially Filled

New 10000 5000 5000 3000 C Indicative fill of 3000. This execution passes the cancel request on the connection

6 Execution(X) Fill Filled New 10000 10000 0 5000 D Indicative fill of 5000 while order is pending cancel

7 Cancel Reject

(Y,X)

Filled 10000 Cancel request rejected

Text=ORDER NOT FOUND / NOT OPEN

8 Execution (X) Fill Filled Correct 10000 10000 0 3000 E (C) ToSTNeT fill confirmation of 3000

9 Execution (X) Fill Filled Correct 10000 10000 0 5000 F (D) ToSTNeT fill confirmation of 5000



6.5 Zero-filled order, followed by cancel/replace request to decrease order qty



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment




3 Replace Request(Y,X)

9000 Request to decrease order quantity to 9000


New 10000 If request is rejected

4 Execution (Y,X)

Replace Replaced New 9000 0 9000 0

5 Execution (Y) Partial Fill

Partially Filled



Partially Filled

New 9000 3000 6000 2000 B Indicative fill of 2000


Partially Filled

Correct 9000 3000 6000 1000 C (A) ToSTNeT fill confirmation of 1000


Partially Filled

Correct 9000 3000 6000 2000 D (B) ToSTNeT fill confirmation of 2000



6.6 Partially filled order, followed by cancel/replace request to decrease order qty, execution occurs while order is pending replace



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment





Partially Filled



Partially Filled





Partially Filled

New 10000 1100 8900 100 C Indicative fill of 100 before cancel/replace request is accepted


Partially Filled


7 Execution (Y,X)

Replace Partially Filled

New 8000 1100 6900 0 ‘Partially filled’ order status takes precedence over ‘replaced’ order status

8 Execution(Y) Partial Fill

Partially Filled

Correct 8000 1100 6900 100 D (C) ToSTNeT fill confirmation of 100

9 Execution(Y) Fill Filled New 8000 8000 0 6900 E Indicative fill of 6900

10 Execution(Y) Fill Filled Correct 8000 8000 0 6900 F (E) ToSTNeT fill confirmation of 6900



6.7 Cancel/replace request sent while execution is being reported – requested order qty exceeds cum qty. Order is replaced then filled



Exec Type

OrdStatus Exec Trans

Type

Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment





Partially Filled



Partially Filled





Partially Filled

New 10000 1500 8500 500 C Indicative fill of 500. Replace request and this execution report pass each other on the connection


Partially Filled

New 10000 1600 8400 100 D Indicative fill of 100 occurs before cancel/replace request is accepted


Partially Filled


7 Execution (Y,X)


New 8000 1600 6400 0 ‘Partially filled’ order status takes precedence over ‘replaced’ order status. Replace is accepted as requested order qty exceeds cum qty

8 Execution (Y) Fill Filled New 8000 8000 0 6400 E Indicative fill of 6400

9 Execution (Y) Fill Filled Correct 8000 8000 0 500 F (C) ToSTNeT fill confirmation of 500

10 Execution (Y) Fill Filled Correct 8000 8000 0 100 G (D) ToSTNeT fill confirmation of 100

11 Execution (Y) Fill Filled Correct 8000 8000 0 6400 H (E) ToSTNeT fill confirmation of 6400



6.8 Cancel/replace request sent while execution is being reported – requested order qty equals cum qty. Order is amended to cum qty


Message Sent


Exec

Type

OrdStatus Exec

Trans Type

Order

Qty

Cum

Qty

Leaves

Qty

Last

Shares

ExecId (ExecRefID)

Comment







Partially Filled

New 10000 7000 3000 7000 A Indicative fill of 7000. Replace request and this execution report pass each other on the connection


Partially Filled


5 Execution (Y,X)

Replace Filled New 7000 7000 0 0 The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’ or ‘replaced’



6.9 Cancel/replace request sent while execution is being reported – requested order qty is below cum qty. Order is amended to cum qty


Message Sent


Exec

Type

OrdStatus Exec

Trans Type

Order

Qty

Cum

Qty

Leaves

Qty

Last

Shares

ExecId (ExecRefID)

Comment







Partially Filled

New 10000 8000 2000 8000 A Indicative fill of 8000. Replace request and this execution report pass each other on the connection


Partially Filled


5 Execution (Y,X)

Replace Filled New 8000 8000 0 0 The replace request is interpreted as requiring the balance of the order to be canceled – the ‘filled’ order status takes precedence over ‘canceled’ or ‘replaced’



6.10 Cancel/replace request sent which is accepted – another one sent which is also accepted



Exec Type


Type

Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment





Partially Filled



Partially Filled



8000 Request decrease in order quantity to 8000


Partially Filled

New 10000 1500 8500 500 C Indicative fill of 500


Partially Filled

Correct 10000 1500 8500 500 D (C) ToSTNeT fill confirmation of 500

8 Execution (Y,X)




Partially Filled

New 8000 3500 4500 2000 E Indicative fill of 2000


Partially Filled

Correct 8000 3500 4500 2000 F (E) ToSTNeT fill confirmation of 2000

11 Replace Request(Z,Y)

6000 Request decrease in order quantity to 6000

12 Execution (Z,Y)

Replaced

Partially Filled


13 Execution(Z) Fill Filled New 6000 6000 0 2500 G Indicative fill of 2500

14 Execution(Z) Fill Filled Correct 6000 6000 0 2500 H (G) ToSTNeT fill confirmation of 2500



6.11 Order rejected due to duplicate ClOrdID



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment




Partially Filled



Partially Filled


5 New Order(X) 10000 Order submitted with the same order id

6 Execution(X) Rejected Partially Filled

New 10000 1000 9000 0 OrdRejReason = duplicate order



6.12 Poss resend order



Exec Type


Order Qty

Cum Qty

Leaves Qty

Last Shares

Comment



3 New Order(X) 10000 PossResend=Y

4 Execution(X) New New Status 10000 0 10000 Order X has already been received, confirm the current state of the order. Last shares not required when ExecTransType = Status

5 New Order(Y) 15000 PossResend=Y

6 Execution(Y) New New New 15000 0 15000 0 Order Y has not been received before, confirm as a new order.

6.13 Fill or Kill order that cannot be filled



Exec

Type

OrdStatus Exec

Trans Type

Order

Qty

Cum

Qty

Leaves

Qty

Last

Shares

ExecId (ExecRefID)

Comment

1 New Order(X) 10000 Order is FOK



3 Execution(X) Canceled Canceled New 10000 0 0 0 If order cannot be immediately filled, send unsolicited cancel

6.14 Immediate or Cancel order that is partially filled



Exec Type


Type

Order Qty

Cum Qty

Leaves Qty

Last Shares

ExecId (ExecRefID)

Comment

1 New Order(X) 10000 Order is IOC









5 Execution(X) Canceled Canceled New 10000 1000 0 0 Unsolicited cancel

6.15 Fully filled order (1 indicative fill), followed by cancellation of indicative fill



Exec Type


Order Qty

Cum Qty

Leaves Qty

AvgPx Last Shares

Last Px

ExecId (ExecRefID)

Comment



2 Execution(X) New New New 10000 0 10000 0 0

3 Execution(X) Fill Filled New 10000 10000 0 100 10000 100 A Indicative fill of 10000 @ 100

4 Execution(X) Fill Filled Cancel 10000 0 0 0 0 0 B (A) ToSTNeT timeout or rejection, cancel indicative fill of 10000 @ 100



6.16 Fully filled order (multiple indicative fills), followed by cancellation of 1 indicative fill



Exec Type


Order Qty

Cum Qty

Leaves Qty

AvgPx Last Shares

Last Px

ExecId (ExecRefID)

Comment





New 10000 8000 2000 100 8000 100 A Indicative fill of 8000 @ 100


Correct 10000 8000 2000 100 8000 100 B (A) ToSTNeT fill confirmation of 8000 @ 100

5 Execution(X) Fill Filled New 10000 10000 0 102 2000 110 C Indicative fill of 2000 @ 110

6 Execution(X) Fill Filled Cancel 10000 8000 0 100 0 0 D (C) ToSTNeT timeout or rejection, cancel indicative fill of 2000 @ 110

6.17 Partially filled order (multiple indicative fills), followed by cancellation of 1 indicative fill



Exec

Type

OrdStatus Exec

Trans Type

Order

Qty

Cum

Qty

Leaves

Qty

AvgPx Last

Shares

Last

Px

ExecId (ExecRefID)

Comment







Correct 10000 2000 8000 100 2000 100 B (A) ToSTNeT fill confirmation of 2000 @ 100


New 10000 4000 6000 105 2000 110 C Indicative fill of 2000 @ 110


Cancel 10000 2000 6000 100 0 0 D (C) ToSTNeT timeout or rejection, cancel Indicative fill of 2000 @ 110



6.18 Partially filled order (1 indicative fill), followed by cancellation of indicative fill, then fully filled



Exec Type


Order Qty

Cum Qty

Leaves Qty

AvgPx Last Shares

Last Px

ExecId (ExecRefID)

Comment






4 Execution(X) New New Cancel 10000 0 2000 0 0 0 B (A) ToSTNeT timeout or rejection, cancel Indicative fill of 8000 @ 100

5 Execution(X) Fill Filled New 10000 2000 0 110 2000 110 C Indicative fill of 2000 @ 110

6 Execution(X) Fill Filled Correct 10000 2000 0 110 2000 110 D (C) ToSTNeT fill confirmation of 2000 @ 110



7 Appendix B – Kai-X PEG Order Definitions

7.1 Primary (PRIM) Peg Type

This section will provide examples of Basic PRIM Pegged orders.

7.1.1 Basic Primary Peg

Basic PRIM pegged orders are pegged to the same side of the stock’s primary market best bid/offer. The order will float with the market up to the limit price.

PEG ORDER TYPE DOES THE DISPLAY FLOAT

SIDE PEGGED

Basic Primary (PRIM) Y Same side of primary market quote

In the following example, the order is to Buy 3000 at 10.20 pegged to the PRIM:

EXECINST

(18)

ORDERQTY

(38)

ORDTYPE

(40)

PRICE

(44)2

SIDE

(54)

R 3000 P 10.20 1

The primary market best bid and offer is 10.10 – 10.16. The order will be initially at 10.10 and will float with the market but never beyond the limit price of 10.20.

2 If no limit price (Price) is entered for Primary Pegged orders then the order will float until fully executed. This applies to all Primary Pegged orders.



7.2 Mid (MID) Peg Type

This section will provide examples of Basic MID Pegged orders.

7.2.1 Basic Mid Peg

Basic MID pegged orders are pegged to the middle of the primary market best bid and offer. The order will float with the market up to the limit price.


SIDE PEGGED

Basic MID Y Middle Primary Market best bid/offer.

In the following example, the order is to Buy 3000 at 10.20 pegged to the MID:

EXECINST

(18)

ORDERQTY

(38)

ORDTYPE

(40)

PRICE

(44)3

SIDE

(54)

M 3000 P 10.20 1

The primary market best bid and offer is 10.00 – 10.02. Therefore, the order will initially be at 10.01, and will float with the market, but never beyond the limit of 10.20.

7.3 Market (MKT) Peg Type

This section will provide examples of Basic Market (MKT) Pegged orders.

7.3.1 Basic Market Peg

Basic Market (MKT) pegged orders are pegged to the contra-side of the Primary Market. The order will float with the market up to the limit price.


SIDE PEGGED

Basic Market (MKT) Y Contra side of Primary Market

In the following example, the order is to Buy 3000 at 10.20 pegged to the MKT:

EXECINST

(18)

ORDERQTY

(38)

ORDTYPE

(40)

PRICE

(44)4

SIDE

(54)

P 3000 P 10.20 1

The Primary Market best bid and offer is 10.01 – 10.06. Therefore, the order will initially be displayed at 10.06, and will float with the market, but never beyond the limit of 10.20.

3 If no limit price (Price) is entered for Mid Pegged orders then the order will float until fully executed. This applies to all Mid Pegged orders. 4 If no limit price (Price) is entered for Market Pegged orders then the order will float until fully executed. This applies to all Market Pegged orders.

Kai-X System Interface Specification...1.06 13-Jun-2016 8 Updated CashMargin tag to only accept cash...

Documents

Transcript of Kai-X System Interface Specification...1.06 13-Jun-2016 8 Updated CashMargin tag to only accept cash...