CONNEQTOR

この文書は読取専用です。文書のソースを閲覧することは可能ですが、変更はできません。もし変更したい場合は管理者に連絡してください。
====== CONNEQTOR FIX Interface Specifications (Investor/Connection) ======
Version 1.0\\
Created in June 2023\\
\\
\\
\\
===== 1.Introduction =====

This document describes the interface specifications based on the FIX (Financial Information eXchange) protocol between CONNEQTOR and investor systems. All messages and transmission procedures between systems shall conform to FIX Protocol V4.2 (Errata).
\\
\\
\\
===== 2.Overview =====

==== 2.1 System Overview ====

Institutional Investor (investor system) sends RFQs to CONNEQTOR in accordance with this FIX Connection Specification. Institutional investor receives quotes from market makers through CONNEQTOR. CONNEQTOR sends information of the matched order to the trading participant.
CONNEQTOR connects to FIX Clients of investor system through the arrownet (*1).
Investor system shall set up FIX Clients to communicate with CONNEQTOR. FIX Clients consist of FIX Services (*2) and FIX Applications (*3) that conform to FIX V4.2 (Errata). The FIX Service of the investor system is the controller which actually conducts transmissions with the FIX Service of CONNEQTOR. The FIX Application establishes FIX sessions (Logical Link(*4)) with CONNEQTOR via connection request (Logon).
The FIX Service shall be prepared by investors. The FIX application shall be created by the investor in accordance with the message sequence and message format described in this document.
Users may save the FIX Service and the FIX Application as a single application. (depending on the investor system)

  * (Note 1) To connect to CONNEQTOR via arrownet, investor shall configure network settings in accordance with arrownet v2 Guideline for NW Connection(Common), arrownet v2 Guideline for NW Connection(JPX), arrownet v2 Guideline for Procedures Operations(Common) and arrownet v2 Guideline for Procedures Operations(JPX).
  * (Note 2) FIX service is an application equipped with the transmission controller for messages based on FIX protocol.
  * (Note 3) FIX application is an upper-level application in FIX Service which analyses, checks, and assembles FIX business messages based on TSE FIX Interface Specifications.
  * (Note 4) One FIX session is allocated to the system classification unit corresponding to CONNEQTOR. One FIX session only conducts operations for one system classification unit.

=== 2.1.1 Production Environment ===

The production environment is for the purpose of using the system service, and available from 8:00 a.m. (JST) to 6:30 p.m. (JST) on trading days.The investor system logs on to CONNEQTOR during the available hours of the trading day.　CONNEQTOR does not have a disaster recovery site. In the event of a broader disaster of CONNEQTOR (production), network equipment at the primary center, or arrownet, shown in Figure 2.1.1, the service shall be stopped until the equipment is restored. Investors are allowed to have multiple FIX clients with the same IP address or the different IP addresses for fault tolerance. Figure 2.1.1 shows the overall configuration image of the production environment. The investor system logs out to CONNEQTOR during the available hours of the trading day.\\
\\
{{ ::spec:en:isv:Figure 2.1.1 Overall configuration image (Production).svg?800 |Figure 2.1.1 Overall configuration image (Production)}}
;#;
**Figure 2.1.1 Overall configuration image (Production)**
;#;

\\
=== 2.1.2 Staging Environment ===
The staging environment is for testing purposes, and the test day is basically the same day as the trading day of the production environment. It is available from 8:00 a.m. (JST) to 9:00 p.m. (JST) on the day of testing. When the investor performs the test, the investor system will attempt to log in to CONNEQTOR during available hours on the day of the test. If the FIX session is disconnected during the test, the investor system may attempt to log in again.
In the case where investor selects a securities company that does not log in FIX, the test cannot be performed after RFQ sending. Therefore, TSE will prepare pseudo participants to enable investors to send RFQs.
In the event of a broader disaster of CONNEQTOR (staging), network equipment at the primary center, or arrownet, shown in Figure 2.1.2, the test shall be stopped until the equipment is restored, in order to resume the service in this environment. Figure 2.1.2 shows the overall configuration image of the staging environment. Investors can connect to CONNEQTOR via the arrownet.

\\
\\
==== 2.2 Scope of Specifications ====
This document describes the interface specifications based on FIX Protocol V4.2 (Errata) between CONNEQTOR and investor systems in the CONNEQTOR inter-system connection method. Messages other than those described in this document shall not be permitted for inter-system transmission.
\\
\\
\\
===== 3. TCP connection =====
==== 3.1 Connection Configuration for Investor ====
This section shows the connection configuration and specification between the investor system and CONNEQTOR.
=== 3.1.1 Connection Configuration ===
The connection between investor system and CONNEQTOR is shown below. TCP/IP shall be used as the transmission control procedure, and it is connected through the arrownet.

{{ :spec:en:isv:Figure 3.1.1 Connection Configuration.svg?800 |Figure 3.1.1 Connection Configuration}}
;#;
** Figure 3.1.1 Connection Configuration **
;#;

=== 3.1.2 Connection Specification ===
Investor system shall connect to CONNEQTOR after sending the login message to CONNEQTOR and until sending the logout message to CONNEQTOR.

==== 3.2 TCP/IP connection ====
Transmission between the FIX service of the investor system and CONNEQTOR shall be conducted via TCP/IP.

=== 3.2.1 Version ===
Investor shall follow RCFs shown below.
\\
;#;
** Table 3.2-1 TCP Version **
;#;
^ Protocol ^Abbr. ^RFC  ^Title ^
|Internet Protocol|IP(IPv4)|791|Internet Protocol|
|:::|:::|792|Internet Control Message Protocol|
|:::|:::|919|Broadcasting Internet Datagrams|
|:::|:::|922|Broadcasting Internet datagrams in the presence of subnets|
|:::|:::|950|Internet Standard Subnetting Procedure|
|Transmission Control Protocol|TCP|793|Transmission Control Protocol|
|:::|:::|1122|Requirements for Internet Hosts - Communication Layers|
|:::|:::|1323|TCP Extensions for High Performance|
|:::|:::|5681|TCP Congestion Control|
|:::|:::|2018|TCP Selective Acknowledgment Options|
|:::|:::|2883|An Extension to the Selective Acknowledgement (SACK) Option for TCP|
\\
=== 3.2.2 IP address and Port Number ===
CONNEQTOR and investor system shall establish TCP connections with IP addresses and port numbers arranged between Exchange and investor.
The IP address and port number for investor system shall be assigned by investor at the time of applications. Investors are also required to assign their IP addresses and port numbers for their secondary system if they use, in addition to ones for their primary site. Those for CONNEQTOR shall be assigned by Exchange. The IP address and port numbers assigned by Exchange are described in the following figure.

{{ ::spec:en:isv:Figure 3.2.2-1 IP Address and Port Number.svg?800 |Figure 3.2.2-1 IP Address and Port Number}}
;#;
**Figure 3.2.2-1 IP Address and Port Number **
;#;

\\
\\

=== 3.2.3 Connection Conditions for TCP connection ===
== (1) How to connect and disconnect TCP connection ==
The connection condition for TCP connection shall be as follows.
^Connect Direction|Connect from investor system.|
^Disconnect Direction|Disconnect from investor system.|

== (2) TCP Options (for TCP_NODELAY) ==
CONNEQTOR uses TCP_NODELAY when sending messages. Investor system is allowed to enable the TCP option when connection to CONNEQTOR if the option is judged to improve transmission efficiency.\\
  *(Note) TCP_NODELAY is used to wait and aggregate data to utilize the line.

== (3) Prohibitions on TCP connection ==
Investor shall not put an extra load on CONNEQTOR including, but not limited to, sending connection request packet when connection has been established or sending many restore requests within a short period when detecting failure of communication sequence.
\\
In case investor detects a breach of this article, including by receiving any messages for Exchange, investor shall take any measures to correct the breach such as immediately disconnecting from CONNEQTOR.\\
\\
\\
===== 4. FIX Session Connection Protocol =====

==== 4.1 FIX Session Overview ====

The FIX session shall be defined as a flow of messages which have bidirectional and continuous sequence numbers between two systems. In a single set of communications, all messages are given a unique sequence number which guarantees the order and the forwarding of messages in their entirety. Sequence numbers are managed separately for each direction of transmission, including sending sequence numbers and receiving sequence numbers. Sequence number starts from 1 at the start of a session and increases by 1. The FIX session begins with the exchange of a Logon message with a sequence number of 1. In accordance with an agreement between the two communicating parties, the FIX Session shall end when sequence numbers clear on both sides. Additionally, the two communicating parties may interrupt and resume the communication as many times as necessary while maintaining the FIX session by repeating the establishment and release of the FIX session via the exchange of Logon/Logout messages.

{{ :spec:en:fig4-1-1.svg?800 |Figure 4.1.1 Start and End of FIX Session}}
;#;
** Figure 4.1.1 Start and End of FIX Session **
;#;
  *NOTE) In this document, “a establishment/release of a FIX session” shall represent a resumption/interruption of a message by connection/disconnection of the communication link (TCP connection). Note that it is different from start/end of a FIX session.
\\
==== 4.2 Relationship between TCP connection and FIX Session ====

TCP connection and FIX session shall have a one-to-one correspondence at any one time. Multiple FIX session messages cannot be mixed on a single TCP Connection and a single FIX session message cannot be transmitted over multiple TCP connections. Additionally, data transmitted over TCP connections are messages prescribed in the FIX Protocol Specifications (Ver4.2(Errata)), and no special headers/trailers shall be added.

FIX session continues over multiple TCP connections (time-wise). Multiple Logons/Logouts are possible during a single FIX session.

{{ ::spec:en:isv:Figure 4.2.1 Relationship between TCP connection and FIX Session.svg?800 |Figure 4.2.1 Relationship between TCP connection and FIX Session}}
;#;
**Figure 4.2.1 Relationship between TCP connection and FIX Session**
;#;
\\
\\
  *Logon Request – Procedures for connection confirmation, arrangement of connection conditions, and message synchronization at the time of TCP connection. In addition, this means the procedure for starting the session when the FIX session has not been started. (The MsgSeqNum of the Logon message at this time is 1.)
  *Logout Request – Procedures to gain attention of the other system before disconnecting TCP connection. Disconnection without this procedure is abnormal. Note that Logout does not indicated the end of the FIX session.
  *FIX Session Conclusion – The timing of the conclusion of the FIX session shall be based on agreement between the two systems connected by the FIX Protocol. For example, there is a way to reset a session at the end of a day's trade.
Furthermore, the persistence of the FIX session shall, substantially, refer to the following situations.\\
　　A) Where the order of messages transmitted via the session is maintained by maintaining transmission sequence numbers.\\
　　B) Where the transmitted message log is maintained in case of retransmission of messages.\\

==== 4.3 Establishment of FIX Session ====

FIX session may be established via the exchange of Logon messages between the two communicating parties. The sender of the Logon message (initiator) shall send a Logon message following TCP connection establishment. The recipient of the Logon message (acceptor) shall, in cases where the Logon message has been authenticated and the initiator's connection address has been acknowledged, send a Logon response message to the initiator. In cases where authentication is refused, the TCP connection shall be disconnected. After establishing the FIX session, transmission of messages between each system shall be possible.

{{ :spec:en:fig4-3-1.svg?800 |Figure 4.3.1 Establish Session}}
;#;
** Figure 4.3.1 Establish Session **
;#;
\\
\\
In CONNEQTOR, investor shall be initiator, while TSE shall be acceptor.

==== 4.4 Release of FIX Session ====

FIX session may be released via the exchange of Logout Messages between the two communicating parties.\\
The sender of the Logout message shall confirm whether messages reached the other system via the message gap detection sequence (the gray box below). As a result, the sender shall confirm that there are no missing messages and send a Logout message.\\
Messages cannot be transmitted between the systems following release of the FIX session.

{{ :spec:en:fig4-4-1.svg?800 |Figure 4.4.1. Release Session}}
;#;
** Figure 4.4.1 Release Session **
;#;
\\
\\
In CONNEQTOR, investor shall be the initiator of the session release.
\\
==== 4.5 HeartBeat ====
In FIX Protocol, the condition of the other system or the network is monitored via mutual monitoring of message arrival times between two connected systems. In cases where a message from the other system does not arrive even after the time indicated in the HeartBtInt(Tag=108) of the Logon message + the HeartBeat reception allowance time (the time in consideration of message delays due to the lines, etc.) has elapsed, a TestRequest message shall be sent to request a HeartBeat message from the other system.\\
In cases where a Test Request message is sent, but no HeartBeat message is received within a certain period of time, it is assumed a failure occurred in the other system or the network, and the TCP connection shall be disconnected. Conversely, in cases where there is no request for transmission of a message from the application even after the time indicated in the HeartBtInt (Tag=108) of the Logon message has elapsed, a HeartBeat message shall be generated to notify the other system of the existence of one's own system.\\
In addition, HeartBeat messages shall be used for early detection of missing messages.\\

{{ :spec:en:fig4-5-1.svg?600 |Figure 4.5.1 HeartBeat }}

Triggered by timeout of the Heartbeat Reception Monitoring Timer, a TestRequest message is sent to request a HeartBeat message from investor system. However, no Heartbeat response comes in, another timeout occurs, and then the TCP connection is disconnected.\\
Note) The time until the Heartbeat Reception Monitoring timeouts shown in the figure is the total time of the Heartbeat Reception Monitoring Time and the HeartBeat reception allowance time.

;#;
** Figure 4.5.1 HeartBeat **
;#;


\\
==== 4.6 GapFill ====
Missing messages may be detected by verifying MsgSeqNum (Tag=34) of received messages. In cases where missing messages are detected, a Resend Request (retransmission request) message will be sent requesting retransmission from the other system. In cases where a Resend Request is received, the message with the sequence number requested shall be retransmitted.

The following 2 type of Sequence Numbers are managed uniquely through the session.
  *Outbound Sequence Number: The number set to MsgSeqNum (Tag=34) when sending a message. After sending a message, the number will count up and the next message transmitted shall have such number.
  *Inbound Sequence Number: The number expected to be the MsgSeqNum (Tag=34) of the next message received.

When sending a message, the following procedures will be conducted according to the relationship between the Inbound Sequence Number and the MsgSeqNum (Tag=34) of the message sent.
;#;
** Table 4.6.1 Procedure when Sending Message **
;#;
^Inbound Sequence Number (rSeq) vs MsgSeqNum^Procedure^
|rSeq = MsgSeqNum|Message received in the correct sequence. Processing continues normally.|
|rSeq < MsgSeqNum|Missing message detected. Send a ResendRequest (retransmission request) message and conduct GapFill procedure.|
|rSeq > MsgSeqNum|Serious failure occurred. Disconnect TCP connection by sending a Logout message with Text (Tag=58) added the reason for session release. (Logout message may not be sent.)|
\\
Messages with a PossDupFlag (Tag=43) set to Y are not covered by this table.

In cases where a ResendRequest (retransmission request) message is received, the message with the requested sequence number shall be retransmitted. The retransmission message shall be sent with a PossDupFlag (Tag=43) set to Y. Furthermore, when an administrative message is to be retransmitted, a SequenceReset message shall be sent in place of the administrative message. Retransmission of administrative messages shall be as below.
\\
;#;
** Table 4.6.2 Propriety of Retransmitting Control Message **
;#;
^Administrative Message^Retransmission Availability^Procedure^
|HeartBeat|No|SequenceReset message sent due to ineligibility for retransmission.|
|Logon|No|SequenceReset message sent due to ineligibility for retransmission.|
|TestRequest|No|SequenceReset message sent due to ineligibility for retransmission.|
|ResendRequest|No|SequenceReset message sent due to ineligibility for retransmission.|
|Reject|Yes|Eligible for retransmission. Resent with PossDupFlag set to Y.|
|SequenceReset|No|SequenceReset message sent due to ineligibility for retransmission.|
|Logout|No|SequenceReset message sent due to ineligibility for retransmission.|
  *Note) Regularly, Sequence Reset-GapFill(GapFilLFlag(123)=Y) will be used for messages sent in place of administrative messages, however in cases where the message indicated in the request cannot be sent (such as when it is not in the transmission history), Sequence Reset-Reset(GapFillFlag(123)=N) shall be used. When using SequenceReset-Reset, the message may have been lost.

{{ ::spec:en:isv:Figure 4.6.1 GapFill Sequence.svg?600 |Figure 4.6.1 GapFill Sequence}}
In this sequence, when the AplMessage MsgSeqNum=13 is received, a gap is detected and GapFill procedures are conducted. AplMessage means application message. All application messages are eligible for resending.\\
*1 In cases where a Retransmission Request is sent in response to Gap Detection, resending range requested by the ResendRequest message shall be between the sequence number following the last message received normally and 0 (meaning infinity). Including up to 0 indicates that messages up until the last sent are eligible.\\
*2 Since the HeartBeat MsgSeqNum = 12 is an administrative message neligible for resending, a SequenceReset-GapFill message shall be sent instead.\\
;#;
** Figure 4.6.1 GapFill Sequence **
;#;
\\
==== 4.7 Protocol Error (Session Reject) ====

According to FIX Protocol, in cases where unapproved messages are sent, the receiving system shall discard such messages. However, depending on the type of protocol error, a Reject or a BusinessMessageReject shall be sent to the system from which such unapproved message originated. The conditions for sending a Reject or a BusinessMessageReject shall be as follows.
;#;
** Table 4.7.1 Procedure when Invalid Message Received **
;#;

|< 100% 5% 20% 30% 30% 15% >|
^  Item  ^  Condition  ^  Example  ^  Action  ^  Reference  ^
|Before FIX session establishment|||||
|  1  |Received improper message.|Logon Confirmation Failure \\ Logon receiver (Acceptor) receives messages other than Logon. \\ Logon Sender (Initiator) receives other messages prior to receiving Logon response.|Logon receiver (Server) disconnects the connection.| |
|FIX session established|||||
|  2  |Received serious error message. Subsequent message exchanges may not continue.|Invalid MsgSeqNum (no tag, value is a non-numeric character) \\ MsgSeqNum is smaller than expected. (PossDupFlag=N) |Receiving program sends Logout set with error reason and disconnects connection without waiting for response Logout.| |
|:::|:::|Same Standard Header tag in Standard Header exists twice or more times. \\ Same Body tag in Body (excluding repetitive tags) exists twice or more times. \\ Mandatory tag is missing. (mandatory as FIX protocol) \\ Conditionally mandatory tag is missing. (mandatory as FIX protocol) \\ No value is found in Tag. \\ Data format of tag is invalid. \\ Invalid MsgType (no tag and out of support in MsgType)|Receiving program sends Reject in order to announce the failed message processing. Additionally, after continuously sending Reject for multiple times determined in Table 4.8.1, the program sends Logout with error reason and disconnects connection without waiting for response Logout.| |
|  3  |Received processing failure message on application level. Next message may be processed correctly.|Mandatory tag is missing. (non-mandatory as FIX protocol but mandatory as CONNEQTOR) \\ Conditionally mandatory tag is missing. (non-mandatory as FIX protocol but mandatory as CONNEQTOR) \\ Tag value is invalid. (except for invalid data format)|Receiving program sends BusinessMessageReject in order to announce the failed message processing.| |
|  4  |Not recognized message correctly.|First tag is not BeginString. \\ Second tag is not a BodyLength. \\ Third tag is not a MsgType. \\ Last tag is not CheckSum. \\ Invalid value in BeginString, BodyLength, and CheckSum.|Receiving program discards message without updating message sequence number.|Next correct message is received, GapFill is detected, and retransmission of the discarded message is requested.|


==== 4.8 Protocol Control Parameter ====
CONNEQTOR shall use the following Protocol Control Parameters to properly control the FIX Protocol, including for infinite loop avoidance and response monitoring.
;#;
** Table 4.8.1 Protocol Control Parameters **
;#;

|< 100% 21% 60% 19% >|
^  Protocol Parameter  ^  Description  ^  Set value  ^
|HeartBeat Transmission Timer|For existence verification. When no message is transmitted even after the set time of the timer has elapsed, CONNEQTOR shall generate and send a HeartBeat. This timer is set in the HeartBtInt field of the Logon and notified to the investor systems.|60 seconds (fixed value)|
|HeartBeat Reception Monitoring Timer|For existence verification. When no message is received even after the total time of the timer and the HeartBeat Allowance Timer has elapsed, a TestRequest shall be sent to confirm the existence of the investor systems. Furthermore, if the total time of the timer and the HeartBeat Allowance Timer has elapsed, the TCP Connection shall be disconnected. This timer will use the value set in the HeartBtInt field of the Logon received from the investor systems.|Dependent on investor system (0 second is not a valid setting)|
|HeartBeat Allowance Timer|For existence verification. Use with the HeartBeat Reception Monitoring Timer when such timer is used. This timer is used in consideration of the delay caused by lines, etc.|30 seconds (fixed value)|
|Continuous Reject Limit|The upper limit of continuously sending Reject from CONNEQTOR caused by incorrect messages from investor system. In case of exceeding this limit, CONNEQTOR sends Logout with an error reason and disconnect without waiting for any responses from investor system.|10 times (fixed value)|
\\
\\
\\
===== 5. Message List =====


==== 5.1 Message ====

Messages used in CONNEQTOR are shown below.
;#;
** Table 5.1.1 Message List **
;#;
^:::^^^^  FIX  ^^
^  Category  ^  Sub Category  ^  Message Name  ^Upstream/Downstream (*)^  FIX Message  ^MsgType^
|Administration Message|  -  |Logon|Up/Down|Logon|A|
|:::|:::|Logout|Up/Down|Logout|5|
|:::|:::|Heart Beat|Up/Down|Heart Beat|0|
|:::|:::|Test Request|Up/Down|Test Request|1|
|:::|:::|Resend Request|Up/Down|Resend Request|2|
|:::|:::|Reject|Up/Down|Reject|3|
|:::|:::|Sequence Reset|Up/Down|Sequence Reset|4|
|Application Message|RFQ sending Message|RFQ Transmission|Up|New Order - Single|D|
|:::|Acceptance Notice Message|RFQ acceptance/rejection notification|Down|Execution Report|8|
|:::|:::|RFQ Cancel Notification|Down|Execution Report|8|
|:::|Execution Notice Message|Execution Notice|Down|Execution Report|8|
|:::|:::|Done for day Notice|Down|Execution Report|8|
*) 　Upstream: Investor Systems → CONNEQTOR\\
　　Downstream: CONNEQTOR → Investor Systems\\

\\
\\
\\
===== 6. Message Sequence =====


==== 6.1 FIX Protocol Control Sequence ====

This section provides an example of the control sequence for the FIX protocol Control Sequence.

=== 6.1.1 Overview of the Sequence ===
FIX protocol transmission sequence primarily consists of the Establishment Sequence for the Logon exchange, the message transmission for the application message exchange, the Release Sequence for the Logout exchange. The FIX protocol transmission sequence is outlined below.

{{ ::spec:en:isv:Figure 6.1.1 Sequence overview.svg?800 |Figure 6.1.1 Sequence overview}}
;#;
Note that the sequence numbers are continued even after releasing the sequence.
;#;
;#;
** Figure 6.1.1 Sequence overview **
;#;
\\
=== 6.1.2 Establishment/Release ===

== (1) Active Establishment (authentication OK) ==

In active establishment, the investor system makes a TCP connection and Logon request to CONNEQTOR. If there are no problems authenticating the Logon request, a Logon response shall be sent to investor system and the establishment shall be completed.

(Note) The MsgSeqNum of the Logon request/response is not always 1.

{{ ::spec:en:isv:Figure 6.1.2 Establish (Authentication OK).svg?800 |Figure 6.1.2 Establish (Authentication OK) }}
;#;
** Figure 6.1.2 Establish (Authentication OK) **
;#;
\\
== (2) Active Establishment (authentication denied) ==
If there is a problem authenticating Logon request received from investor system, it is judged to be a party with invalid connection, and the connection will be refused by disconnecting the TCP connection.

{{ ::spec:en:isv:Figure 6.1.3 Establish (Authentication Denied).svg?800 |Figure 6.1.3 Establish (Authentication Denied)}}
;#;
** Figure 6.1.3 Establish (Authentication Denied) **
;#;
\\
== (3) Active Release ==
Active release in the investor system receives a Logout response from the CONNEQTOR to the Logout request, at which point the release is complete. Investor system shall disconnect the TCP connection.

{{ ::spec:en:isv:Figure 6.1.4 Active Release.svg?800 |Figure 6.1.4 Active Release}}
;#;
** Figure 6.1.4 Active Release **
;#;

During active release, when a Logout response sent from CONNEQTOR is not delivered to investor system due to loss on the transmission line, etc., CONNEQTOR shall detect the failure by the Heartbeat Reception Monitoring and disconnect the TCP connection at that time. To check the sequence, refer to “6.1.3 (2) Heartbeat Reception Monitoring Timeout”.

In addition, active release in investor system shall be conducted when it occurs with the following situations: receiving improper message corresponding to the item 2 in “Table 4.7.1 Procedure when Invalid Message Received”, receiving reject message, a certain system failure occurring on CONNEQTOR side. To check the sequence, refer to “6.3 Sequences for Abnormal Cases”.


== (4) Passive Release ==
Passive release in investor system shall be conducted when it occurs with the following situations: receiving improper message corresponding to the item 2 in “Table 4.7.1 Procedure when Invalid Message Received”, receiving reject message, a certain system failure occurring on CONNEQTOR side. To check the sequence, refer to “6.3 Sequences for Abnormal Cases”.


=== 6.1.3 HeartBeat ===

== (1) HeartBeat Transmission ==
Below is the sequences in which CONNEQTOR uses HeartBeat. When no message is sent even after the time set in the HeartBtInt of the Logon response has elapsed, a HeartBeat message shall be sent.

{{ ::spec:en:isv:Figure 6.1.5 HeartBeat Transmission.svg?800 |Figure 6.1.5 HeartBeat Transmission}}
;#;
** Figure 6.1.5 HeartBeat Transmission **
;#;
\\
== (2) Timeout of HeartBeat Reception Monitoring ==
When the investor system uses a HeartBeat, CONNEQTOR monitors the interval of messages received from the investor system. When no messages are sent even after the monitoring time elapses, CONNEQTOR shall send a TestRequest to confirm the existence of the investor system. If, due to some reason, no response is received from the investor system again, CONNEQTOR shall deem that a failure has occurred in the line or investor system and disconnect the TCP connection.

{{ ::spec:en:isv:Figure 6.1.6 Timeout of HeartBeat Reception Monitoring.svg?800 |Figure 6.1.6 Timeout of HeartBeat Reception Monitoring}}
;#;
** Figure 6.1.6 Timeout of HeartBeat Reception Monitoring **\\
Note) Since the existence of the investor system cannot be verified, the TCP connection shall be disconnected without sending a Logout request. \\
;#;
=== 6.1.4 GapFill (Resynchronization Process) ===

== (1) Receive ResendRequest (retransmission request) from investor system ==
When a ResendRequest is received from the invesor system, retransmission shall be performed according to the details of the ResendRequest. Since administrative messages other than Reject are not subject to retransmission, when such messages are including in the retransmission range, SequenceReset-GapFill shall be sent instead.

{{ ::spec:en:isv:Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system.svg?800 |Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system}}
;#;
** Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system **
;#;
\\
== (2) Gap Detection when Receiving AplMessages ==
When a sequence gap is detected in a message received from the investor system, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the missing message. The following shows the sequences when CONNEQTOR detects the sequence gap in Application Messages received from the investor system. \\

Note) CONNEQTOR shall specify that all messages after the beginning of a missing message are requested to retransmit a ResendRequest. (EndSeqNo=0 fixed)

{{ ::spec:en:isv:Figure 6.1.8 Gap Detection when Receiving AplMessages.svg?800 |Figure 6.1.8 Gap Detection when Receiving AplMessages}}
;#;
** Figure 6.1.8 Gap Detection when Receiving AplMessages **
;#;
\\
== (3) Gap Detection when Receiving Logon request ==
When CONNEQTOR detects a sequence Gap in a message from the investor system at the receipt of a Logon request, CONNEQTOR shall first send a Logon response to the investor system, then send a ResendRequest to request the retransmission of the message. For example, if CONNEQTOR could not receive the message from the investor system due to the system down, this sequence shall be performed.

{{ ::spec:en:isv:figure_6.1.9_gap_detection_when_receiving_logon_request.svg?800 |Figure 6.1.9 Gap Detection when Receiving Logon request}}
;#;
** Figure 6.1.9 Gap Detection when Receiving Logon request **
;#;
\\
== (4) Gap Detection when Receiving Logout request ==
When a sequence gap is detected in a message from investor system at the receipt of a Logout request, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. Then it shall send a Logout response when it receives all the messages that requested the retransmission.

{{ ::spec:en:isv:Figure 6.1.10 Gap Detection when Receiving Logout request.svg?800 |Figure 6.1.10 Gap Detection when Receiving Logout request}}
;#;
** Figure 6.1.10 Gap Detection when Receiving Logout request **
;#;
\\
== (5) Gap Detection when Receiving HeartBeat ==
When a sequence gap is detected in a message from the investor system at the receipt of a HeartBeat, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

{{ ::spec:en:isv:Figure 6.1.11 Gap Detection when Receiving HeartBeat.svg?800 |Figure 6.1.11 Gap Detection when Receiving HeartBeat}}
;#;
** Figure 6.1.11 Gap Detection when Receiving HeartBeat **
;#;
\\
== (6) Gap Detection when Receiving TestRequest ==
When a sequence gap is detected in a message from the investor system at the receipt of a TestRequest, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

(Note) When a gap is detected, a HeartBeat shall not be sent in response to the TestRequest.

{{ ::spec:en:isv:Figure 6.1.12 Gap Detection when Receiving TestRequest.svg?800 |Figure 6.1.12 Gap Detection when Receiving TestRequest}}
;#;
** Figure 6.1.12 Gap Detection when Receiving TestRequest **
;#;
\\
== (7) Gap Detection when Receiving ResendRequest ==
When a sequence gap is detected in a message from the investor system at the receipt of a ResendRequest, CONNEQTOR shall first process the retransmission request from the investor system and then send a ResendRequest to request a retransmission of the message.

{{ ::spec:en:isv:Figure 6.1.13 Gap Detection when Receiving ResendRequest.svg?800 |Figure 6.1.13 Gap Detection when Receiving ResendRequest}}
;#;
** Figure 6.1.13 Gap Detection when Receiving ResendRequest **
;#;
\\
== (8) Gap Detection when Receiving SequenceReset-GapFill ==
When a sequence gap is detected in a message from the investor system at the receipt of a SequenceReset-GapFill, CONNEQTOR shall send another ResendRequest to the investor system requesting a retransmission of the message, even though the GapFill process is still ongoing.

{{ ::spec:en:isv:Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill.svg?800 |Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill}}
;#;
** Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill **
;#;
\\
== (9) Gap Detection when Receiving Reject ==
When a sequence gap is detected in a message from the investor system at the receipt of a Reject, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

{{ ::spec:en:isv:Figure 6.1.15 Gap Detection when Receiving Reject.svg?800 |Figure 6.1.15 Gap Detection when Receiving Reject}}
;#;
** Figure 6.1.15 Gap Detection when Receiving Reject **\\
;#;
NOTE) Reject is an administrative message to be retransmitted.
\\
=== 6.1.5 Cross-over Sequence ===
== (1) Cross-over between ResendRequest (retransmission request) and AplMessages ==
If an Application Message from the investor system and a ResendRequest from CONNEQTOR cross over after sending a ResendRequest following a detection of a sequence gap, CONNEQTOR will detect another sequence gap in the Application Message and send another ResendRequest. There is a possibility that another resent message could be lost, thus CONNEQTOR shall send a ResendRequest every time a sequence gap is detected.

{{ ::spec:en:isv:Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages.svg?800 |Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages}}
;#;
** Figure 6.1.16 Cross-over between ResendRequest (retransmission request) and AplMessages **
;#;
\\
==== 6.2 Application Message Sequence ====
This section describes examples of application message sequences between investor system and CONNEQTOR. For the reason codes to be set for error notices, etc., refer to Appendix 1 “List of Reason Codes in CONNEQTOR FIX Interface Specifications (Data Format)”.

=== 6.2.1 Operation-related Message ===
The below describes examples of operation-related message sequences used in CONNEQTOR.

== (1) From RFQ Sending to Receive Execution Notifice (Normal) ==
The following diagram shows the basic sequences of CONNEQTOR normal messages.

{{ ::spec:en:isv:Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal).svg?600 |Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal)}}
  - Investor system sends RFQ to CONNEQTOR.
  - CONNEQTOR sends acceptance notification to investor system.
  - After execution on ToSTNeT, CONNEQTOR sends execution notification to the investor system.
  - CONNEQTOR sends Done for day to the investor system.

;#;
** Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal) **
;#;
\\
== (2) RFQ Sending (Error Case) ==
The following diagram shows the basic sequences for an error case in RFQ sending.

{{ ::spec:en:isv:Figure 6.2.2 Sequences of RFQ Sending (Error Case).svg?600 | Figure 6.2.2 Sequences of RFQ Sending (Error Case)}}
  - Investor system sends RFQ to CONNEQTOR.
  - CONNEQTOR sends rejection notice to investor system.
;#;
** Figure 6.2.2 Sequences of RFQ Sending (Error Case) **
;#;
\\
== (3) RFQ Cancellation, etc. ==
The following diagram shows the basic sequences of RFQ Cancellation, etc.

{{ ::spec:en:isv:Figure 6.2.3 Sequences of RFQ Cancelled, etc.svg?600 |Figure 6.2.3 Sequences of RFQ Cancelled, etc.}}
  - Investor system sends RFQ to CONNEQTOR.
  - CONNEQTOR sends acceptance notification to investor system.
  - CONNEQTOR sends cancellation notice to investor system.
;#;
** Figure 6.2.3 Sequences of RFQ Cancelled, etc. **
;#;
\\
==== 6.3 Sequence for Abnormal Case ====
This section describes examples of sequences for abnormal case. For the reason codes to be set for error notices, etc., refer to Appendix 1 “List of Reason Codes in CONNEQTOR FIX Interface Specifications (Data Format)”.

=== 6.3.1 Sequence for Malformed Messages ===
== (1) Logically Inconsistent Error (Fatal Error) ==
== 1. Investor system detects a logically inconsistent error (fatal error) in a message (downstream) received from CONNEQTOR. ==
The following diagram shows the sequences for an invalid protocol case where an downstream message from CONNEQTOR is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and the investor system does not recognize it as normal. Figure 6.3.1 Sequence for Malformed Messages

{{ ::spec:en:isv:Figure 6.3.1 Sequence for Malformed Messages.svg?600 |Figure 6.3.1 Sequence for Malformed Messages}}
  - When investor system recognizes a message from CONNEQTOR as an invalid FIX-protocol, investor system sends a Reject to CONNEQTOR.
  - Investor is required to contact TSE to investigate the cause of the error.
* See “4.7 Protocol Error (Session Reject)” for Reject sending condition. \\
* Commonly, CONNEQTOR does not send incorrect messages to investor System.
Recovery Procedure: After the cause of the error is eliminated, the FIX session establishment sequence is executed.

;#;
** Figure 6.3.1 Sequence for Malformed Messages **\\
** Investor system detects a logically inconsistent error (fatal error) in a message (downstream) received from CONNEQTOR. **\\
;#;
\\
== 2. CONNEQTOR detects a logically inconsistent error (fatal error) in a message (upstream) received from investor system. ==
The following diagram shows the sequences for an invalid protocol case where an upstream message from the investor system is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and CONNEQTOR does not recognize it as normal.

{{ ::spec:en:isv:Figure 6.3.2 Sequence for Malformed Messages.svg?600 |Figure 6.3.2 Sequence for Malformed Messages}}
  - When CONNEQTOR recognizes a message from investor system as an invalid FIX-protocol, CONNEQTOR sends a Reject to investor system.
  - When receiving another malformed message, CONNEQTOR resends a Reject.
  - When CONNEQTOR continuously receives malformed messages for multiple times determined in Table 4.8.1, CONNEQTOR sends Logout Request to investor system and disconnect without waiting for Logout Response
* The first 5 bytes of the Text tag in the Logout request represents the reason for the release request.\\
 Recovery Procedure: After the cause of the error is eliminated, the FIX session establishment sequence is executed.
;#;
** Figure 6.3.2 Sequence for Malformed Messages **\\
** CONNEQTOR detects a logically inconsistent error (fatal error) in a message (upstream) received from investor system **\\
;#;
\\
== (2) Invalid Data (Minor Error) ==
“Invalid data” refers to a situation where a received message includes data that has not been defined in the data specification for the type of operation or details of instruction.

== 1. Investor system detects an invalid data in a message (downstream) received from CONNEQTOR. ==
The following diagram shows the sequences for an invalid data case (minor error) and the investor system does not recognize it as normal.

{{ ::spec:en:isv:Figure 6.3.3 Sequence for Malformed Messages.svg?600 |Figure 6.3.3 Sequence for Malformed Messages}}
  - When investor system detects an invalid message content, it sends a Logout request to CONNEQTOR and release the FIX session. Furthermore, it is required to contact TSE to investigate the cause of the error. 
  - After getting rid of a cause, investor system sends a Logon request to CONNEQTOR to establish a FIX session.
  - When the FIX session has been established, CONNEQTOR restarts the notice sending operation from the one it recognizes “unsent.”

;#;
** Figure 6.3.3 Sequence for Malformed Messages **\\
** Investor system detects an invalid data in a message (downstream) received from CONNEQTOR**\\
;#;
\\
== 2. CONNEQTOR detects an invalid data in a message (upstream) received from investor system ==
The following diagram shows the sequences for an invalid data case (minor error) detected by CONNEQTOR.

{{ ::spec:en:isv:Figure 6.3.4 Sequence for Malformed Messages.svg?600 |Figure 6.3.4 Sequence for Malformed Messages}}
  - When a data error (minor error) is detected by CONNEQTOR, the error content is set to Reject Message and sent to investor system.
  - The entry message becomes invalid, but the FIX session is not released and processing of the next entry message continues.
;#;
** Figure 6.3.4 Sequence for Malformed Messages **\\
** CONNEQTOR detects an invalid data in a message (upstream) received from investor system. **\\
;#;
\\

==== 6.4 Application-Level Retransmission Message (with PossResend = Y Messages) ====
When the investor system sends an application-level retransmission message (with PossResend = Y), the following explains how to determine whether or not the retransmitted message is the same as the received message and how to handle such case.

When the retransmission message falls under the following condition, the retransmitted message shall be judged to have been received and discarded.

  * New Order Single
    * MsgType (Tag=35) is identical and ExecID (Tag=17) is set to the received value.


\\
\\
\\
===== 7. Operation =====
==== 7.1 Daily System Operations ====
The following shows the daily system operation.

{{ ::spec:en:isv:Figure 7.1.1 Daily System Operation.svg?600 |Figure 7.1.1 Daily System Operation}}
Reset the sequence number on the first Logon of the day.
;#;
** Figure 7.1.1 Daily System Operation **
;#;
==== 7.2 Testing when changing the system ====
The Exchange and investor shall confirm in advance that they will be able to communicate in accordance with the specifications set forth herein. Therefore, when implementing to newly establish / change FIX clients, the both parties shall agree on a new/changed work schedule, test schedule, etc. and respond without delay according to the schedule.

\\
\\
\\
===== Notes =====
====Terms and Conditions of Use====

Prior to use of these interface specifications, users are required to read and agree to the terms and conditions described below.

  * Copyright, etc.
    * All rights, including copyright for various pieces of information in these interface specifications (hereinafter referred to as “technical information, etc.”) belong to TSE.

  * Prohibitions
    * Whether with or without consideration, in whatever form or media, including but not limited to a license, transfer, resale or lease, these interface specifications or any part of it including but not limited to technical information, etc. herein must not be provided to any third parties or published.

  * Disclaimer
    * In no event shall TSE be liable for any damage or loss arising directly or indirectly from the use or inability to use of information due to errors, omission, or missing, etc. of information in this document.
    * TSE accepts no responsibility or liability for damage or loss incurred by the users or customers of the users, etc. arising from connecting their systems to the TSE trading system according to information provided in this document or arising in connection with the use of this document unless due to intentional act or gross negligence of TSE.
    * In addition, TSE accepts no liability for damage or loss of profit incurred by the users or customers of the users, etc. arising from any special circumstances irrespective of whether or not TSE has foreseen such circumstances.
    * The right to claim compensation for damage or loss shall be extinguished unless exercised within 12 months from the date such damage or loss occurs.

  * Breaches
    * In the event of any breach of terms or conditions described herein, users shall accept instructions of TSE without dissent.

  * Miscellaneous
    * TSE does not warrant, whether express or implied, that the content in these interface specifications is error-free.
\\
\\
===== Publisher =====
Issued by: Tokyo Stock Exchange, Inc.\\
2-1 Nihombashi Kabutocho, Chuo-ku Tokyo 103-8220\\
MAIL:ask-conneqtor@jpx.co.jp\\
Phone Number to reconnect FIX session: 050-3377-7751\\
CONNEQTOR

ユーザ用ツール

サイト用ツール

ページ用ツール
