CONNEQTOR

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

\\
\\
\\
===== 1.Introduction =====

This document describes the interface specifications based on the FIX (Financial Information eXchange) protocol between CONNEQTOR and the trading participant system (hereinafter, "participant system").
All messages and transmission procedures between systems shall conform to FIX Protocol V4.2 (Errata).

\\
\\
\\
===== 2. Overview =====

==== 2.1 System Overview ====

Institutional Investors and market makers request and provide quotations via CONNEQTOR, and CONNEQTOR delivers matching orders and other information to the participant system based on the interface specifications defined in this document. Participant system or CONNEQTOR shall order ToSTNeT in accordance with ToSTNeT System Interface Specifications and FIX Interface Specifications.
CONNEQTOR connects to FIX Clients of participant system through the Internet or arrownet (*1).
Participant 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 participant 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 the participant. The FIX application shall be created by the participant 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 participant system)

  * (Note 1) To connect to CONNEQTOR via arrownet, Participant 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 a.m. (JST) to 6 p.m. (JST) on trading days.
CONNEQTOR logs in to FIX clients of all participant systems at 8 a. m. (JST) on business days. CONNEQTOR does not have a disaster recovery site. In the event of a broader disaster of CONNEQTOR (production), ToSTNeT or network equipment at the primary center, or arrownet, shown in Fig. 2.1.1, the service shall be stopped until the equipment is restored. Participants 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.
Participants can connect to CONNEQTOR via the Internet or arrownet.
CONNEQTOR logs out from Participant System at 6 p.m. (JST) on trading days.

\\
{{ :spec:en:fig2-1-1.svg?700 |Overall configuration image (Production)}}
;#;
**Figure 2.1.1 Overall configuration image (Production)**
;#;

\\
=== 2.1.2 Staging Environment ===
The staging environment is for testing purpose.
Basically, test shall be performed on Thursday and Friday. When it falls in a national holiday, the test shall not be performed. (From Monday to Wednesday, test shall be performed without FIX connection.)
At 8:00 JST on the test day, CONNEQTOR shall attempt to log in to the FIX Clients of all participant systems and consider only those participant systems that have established the FIX session as test participants.
If the FIX session is disconnected due to a participant cause (maintenance work of participant system, etc.) during the test, CONNEQTOR shall not attempt to log in again.
When the FIX session is disconnected due to a CONNEQTOR cause (CONNEQTOR system failure, etc.), CONNEQTOR shall attempt to log in to the FIX client of all participant systems again.
(In the case where investors and market makers are matched choosing a securities company that does not log in FIX, investors and market makers cannot proceed on to execution. The TSE will prepare pseudo participants to enable investors and market makers to execute their trades.)
In the event of a broader disaster of CONNEQTOR (staging), network equipment at the primary center, or ToSTNeT, arrownet at the secondary center, shown in Fig. 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.
Participants can connect to CONNEQTOR via the Internet or arrownet.

{{ :spec:en:fig2-1-2.svg?700 |Figure 2.1.2 Overall configuration image (Staging)}}
;#;
** Figure 2.1.2 Overall configuration image (Staging) **
;#;
==== 2.2 Scope of Specifications ====
This document describes the interface specifications based on FIX Protocol V4.2 (Errata) between CONNEQTOR and participant 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 Participant ====
This section shows the connection configuration and specification between the participant system and CONNEQTOR.
\\
\\
=== 3.1.1 Connection Configuration ===
The connection between participant system and CONNEQTOR is shown below. TCP/IP shall be used as the transmission control procedure, and it is connected through the internet or arrownet.

{{ :spec:en:fig3-1-1.svg?800 |Figure 3.1.1 Connection Configuration}}
;#;
** Figure 3.1.1 Connection Configuration **
;#;
\\
\\
=== 3.1.2 Connection Specification===
Participant shall connect to CONNEQTOR after receiving the login message from CONNEQTOR and until receiving the logout message from CONNEQTOR.
\\
\\
==== 3.2 TCP/IP connection ====
Transmission between the FIX service of the participant system and CONNEQTOR shall be conducted via TCP/IP.
\\
\\
=== 3.2.1 Version ===
Participant 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 Participant System shall establish TCP connections with IP addresses and port numbers arranged between Exchange and Trading Participant. \\
The IP address and port number for Participant System shall be assigned by Participant at the time of applications. Participants are also required to assign their IP address 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:fig3-2-2-1.svg?900 |Figure 3.2.2-1 IP Address and Port Number (via arrownet)}}
;#;
**Figure 3.2.2-1 IP Address and Port Number (via arrownet)**
;#;

{{ :spec:en:fig3-2-2-2.svg?900 |Figure 3.2.2-2 IP Address and Port Number(via internet)}}
;#;
**Figure 3.2.2-2 IP Address and Port Number (via internet)**
;#;
\\
\\

=== 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.
;#;
**Table 3.2.2 TCP connection Conditions**
;#;


^Connect Direction|Connect from CONNEQTOR.|
^Disconnect Direction|Disconnect from CONNEQTOR.|
 \\
\\
== (2) TCP Options (for TCP_NODELAY) ==
CONNEQTOR uses TCP_NODELAY when sending messages. Participant 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 ==
Participants 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 Participant detects a breach of this article, including by receiving any messages for Exchange, Participant shall take any measures to correct the breach such as immediately disconnecting from CONNEQTOR.

\\
\\
==== 3.3 SSL/TLS ====
Connection requirements (SSL/TLS) for connection via internet are as follows.\\
SSL/TLS is not used in case of connections via arrownet.


=== 3.3.1 Version ===
TLS 1.2 is supported.

=== 3.3.2 Cipher Suite ===
The following cipher suites are supported.\\
;#;
** Table 3.3.1 TCP connection Conditions **
;#;

^Cipher suite^TLS^Level^Key Exchange^Authentication^Encryption^
|ECDHE-RSA-AES256-GCM-SHA384|TLSv1.2|ECDH|RSA|AESGCM(256)|AEAD|
|ECDHE-RSA-AES256-SHA384|TLSv1.2|ECDH|RSA|AES(256)|SHA384|
|AES256-GCM-SHA384|TLSv1.2|RSA|RSA|AESGCM(256)|AEAD|
|AES256-SHA256|TLSv1.2|RSA|RSA|AES(256)|SHA256|
|ECDHE-RSA-AES128-GCM-SHA256|TLSv1.2|ECDH|RSA|AESGCM(128)|AEAD|
|ECDHE-RSA-AES128-SHA256|TLSv1.2|ECDH|RSA|AES(128)|SHA256|
|AES128-GCM-SHA256|TLSv1.2|RSA|RSA|AESGCM(128)|AEAD|
|AES128-SHA256|TLSv1.2|RSA|RSA|AES(128)|SHA256|

=== 3.3.3 Certificate ===
The server certificate is prepared by the acceptor (participant). Client certificates are not required, and the preparation is up to Participants. When they use a client certificate, the initiator (Exchange) prepares one. Participants import the exchange's private CA's root certificate and establish a TLS session using the client certificate.

\\
\\
\\
===== 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.4(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:fig4-2-1.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.\\
  *Where the order of messages transmitted via the session is maintained by maintaining transmission sequence numbers.\\
  *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, participant shall be acceptor, while TSE shall be initiator.
\\
\\
==== 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, TSE 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 participant 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:fig4-6-1.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 \\ Receipt of non-Logon by Logon Acceptor. \\ Logon receiver (Acceptor) receives messages other than Logon. \\ Logon Sender (Initiator) receives other messages prior to receiving Logon response.| |
|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 ====
CCONNEQTOR 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  ^
|Logon Timer|Waiting time from CONNEQTOR sends Logon Request to CONNEQTOR receives Logon Response. When CONNEQTOR does not receive Logon Response within this period, CONNEQTOR resends Logon Request.|120 seconds (fixed 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 participant 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 participant 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 participant systems.|Dependent on participant 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 Participant System. In case of exceeding this limit, CONNEQTOR sends Logout with an error reason and disconnect without waiting for any responses from Participant System.|10 times (fixed value)|
\\
\\
==== 4.9 Procedures of Reconnection of FIX Sessions ====
Participant should contact TSE at the phone number specified on the last page of this specification if a FIX connection is not connected or is disconnected and failed to reconnect* for some reasons. Then, CONNEQTOR tries to log in to Participant Systems.  In this case, we may ask brokers to reset sequence number.

* CONNEQTOR may sends logon requests for 3 times and each request is sent every 5minutes baased on the reason of disconnection.

\\
\\
==== 4.10 Switching of FIX Clients ====
Switching procedures of FIX clients of Participant System when Participant has a secondary system are shown below.
\\
=== 4.10.1 Redundant system with multiple IP addresses over arrownet ===
Participants are allowed to switch a connection to a secondary system during the trading hours if Participant System is connected over arrownet, and have multiple IP addresses. CONNEQTOR usually tries to connect to a primary site of Participant System. When disconnection of TCP/IP to the primary site is detected, CONNEQTOR automatically tries to connect to the secondary site. Then TSE manually logs in to the secondary Participant System.

{{ :spec:en:fig4-10-1.svg?800 |Figure 4.10.1 Switching Procedures of TCP/IP Connections}}

*1 When both the primary and the secondary sites are connectable with TCP/IP, CONNEQTOR communicates with the primary site. If 5 minutes elapses after a disconnection to the primary site, CONNEQTOR automatically switches the destination to the secondary site. Note FIX connections are not established automatically. TSE staff logs in to the secondary site in manual. \\
*2 When both connections to the primary site and the secondary site are connectable, CONNEQTOR communicates with the primary. In this case, manual logging in by TSE staff is necessary to establish FIX connections to the primary site.
\\
;#;
** Figure 4.10.1 Switching Procedures of TCP/IP Connections **
\\
\\
** Table 4.10.1 Switching Flow of FIX Connections **
;#;

|< 100% 5% 12% 12% 50% 10% >|
^  #  ^  Category ^  Sub Category  ^  Contents  ^  Operator  ^
|  1  |Switching to secondary|Application for FIX reconection|Applies to TSE to reestablish a FIX connections to the secondary site. \\ Note TCP/IP connections between the primary site and CONNEQTOR should have been lost.|Participant|
|  2  |:::|FIX Reconnction|Reconnect FIX sessions.|TSE|
|  3  |Switching back to Primary|Recovery|Switching back to the primary on the day of the first switch to the seconday system is not allowed. If Pariticipant suceeds in recovering its primary system between the end of the trading day and establishment of FIX connection on the next day, CONNEQTOR connects to the primary system on the next day. Keep the primary system disconnected over TCP/IP when Paricipant cannot recover the primary system so that CONNEQTOR establishes connections to the secondary system. |Participant|
\\
\\
=== 4.10.2 Redundant system with multiple IP addresses over Internet ===
Participant having its secondary system with different IP address from the primary over Internet cannot switch connections on the day. When switching to the other site is necessary, Participants should ask TSE to connect to the site from the next day.

\\
\\
=== 4.10.3 Redundant system with single IP address ===
Participant having its secondary system with the same IP address over arrownet or Internet can switch connections on the day. Participants should ask TSE to establish FIX connection after their switching TCP/IP connections has been completed. 


\\
\\
\\
===== 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|Order Entry Message|Order Entry|Up|New Order - Single|D|
|:::|:::|Cancel Order Entry|Up|Order Cancel Request|F|
|:::|Acceptance Notice Message|Order Acceptance Notice|Down|Execution Report|8|
|:::|:::|Order Approval Rejection / Error Notice|Down|Execution Report|8|
|:::|:::|Order Cancellation Error Notice|Down|Order Cancel Reject |9|
|:::|:::|Other/Data Type Error Notice|Up|Business Message Reject|j|
|:::|Execution Notice Message|Execution Completion Notice|Down|Execution Report|8|
|:::|:::|Cancel Result Notice|Down|Execution Report|8|
|:::|:::|Expired Order Notice|Down|Execution Report|8|
*) Upstream: CONNEQTOR -> Participant Systems \\
Downward: Participant Systems -> CONNEQTOR   
\\
\\
\\
===== 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:fig6-1-1.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) Passive Establishment (authentication OK) ==

In passive establishment, TCP connection and receipt of Logon request from the participant system are prearranged. If there are no problems authenticating the Logon request, a Logon response shall be sent to CONNEQTOR and the establishment shall be completed.

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

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

{{ :spec:en:fig6-1-3.svg?800 |Figure 6.1.3 Establish (Authentication Denied) }}
;#;
** Figure 6.1.3 Establish (Authentication Denied)  **
;#;
\\
== (3) Active Release ==
Active release in participant 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 ==
In passive release, a Logout response shall be sent in response to Logout request and the establishment shall be completed. CONNEQTOR shall disconnect the TCP connection.

{{ :spec:en:fig6-1-4.svg?800 |Figure 6.1.4 Passive Release}}
;#;
** Figure 6.1.4 Passive Release **
;#;
During passive release, when a Logout response sent from the participant system is not delivered to CONNEQTOR due to loss on the transmission line, etc., the participant system 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".

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

{{ :spec:en:fig6-1-6.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 participant 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 participant system ==
When a ResendRequest is received from the participant 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:fig6-1-7.svg?800 |Receive ResendRequest (retransmission request) from participant system}}

;#;
** Figure 6.1.7 Receive ResendRequest (retransmission request) from participant system **
;#;
\\
== (2) Gap Detection when Receiving AplMessages ==
When a sequence gap is detected in a message received from the participant 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 participant 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:fig6-1-8.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 participant system at the receipt of a Logon request, CONNEQTOR shall first send a Logon response to the participant system, then send a ResendRequest to request the retransmission of the message. For example, if CONNEQTOR could not receive the message from the participant system due to the system down, this sequence shall be performed.

{{ :spec:en:fig6-1-9.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 CONNEQTOR at the receipt of a Logout request, the participant system 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:fig6-1-10.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 Logout response ==
When CONNEQTOR detects a sequence Gap in a message from the participant system at the receipt of a Logout response, CONNEQTOR shall not send a ResendRequest and disconnect the TCP connection. Lost messages will be resynchronized in the next connection sequences. Refer to "(3) Gap Detection when receiving Logon request".

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

{{ :spec:en:fig6-1-12.svg?800 |Figure 6.1.12 Gap Detection when Receiving HeartBeat}}
;#;
** Figure 6.1.12 Gap Detection when Receiving HeartBeat **
;#;
\\
== (7)  Gap Detection when Receiving TestRequest ==
When a sequence gap is detected in a message from the participant 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:fig6-1-13.svg?800 |Figure 6.1.13 Gap Detection when Receiving TestRequest}}
;#;
** Figure 6.1.13 Gap Detection when Receiving TestRequest **
;#;
\\
== (8) Gap Detection when Receiving ResendRequest ==
When a sequence gap is detected in a message from the participant system at the receipt of a ResendRequest, CONNEQTOR shall first process the retransmission request from the participant system and then send a ResendRequest to request a retransmission of the message.

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

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

{{ :spec:en:fig6-1-16.svg?800 |Figure 6.1.16 Gap Detection when Receiving Reject}}
;#;
** Figure 6.1.16 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 participant 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:fig6-1-17.svg?800 |Figure 6.1.17 Cross-over between ResendRequest (retransmission request) and AplMessages}}
;#;
** Figure 6.1.17 Cross-over between ResendRequest (retransmission request) and AplMessages **
;#;
\\
\\
==== 6.2 Application Message Sequence ====
This section describes examples of application message sequences between participant system and CONNEQTOR.
For the reason codes to be set for error notices, etc., refer to Appendix 2 "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) CONNEQTOR Order (Normal) ==
The following diagram shows the basic sequences of CONNEQTOR normal messages.

{{ :spec:en:fig6-2-1.svg?800 |Figure 6.2.1 Sequences of CONNEQTOR Order (Normal)}}
  - Send an order entry message from CONNEQTOR.
  - Participant system sends an order acceptance notice to CONNEQTOR
  - Participant systems sends an order to  ToSTNeT.
  - ToSTNeT sends an order acceptance notice.
  - When the order has been executed in ToSTNeT, ToSTNeT sends an execution completion notice to participant system.
  - Participant system sends an order execution notice to CONNEQTOR.
;#;
** Figure 6.2.1 Sequences of CONNEQTOR Order (Normal)  **
;#;
\\
== (2) CONNEQTOR Order (Error Case)  ==
The following diagram shows the basic sequences for an error case in placing an order in CONNEQTOR.

{{ :spec:en:fig6-2-2.svg?900 |Figure 6.2.2 Sequences of CONNEQTOR Order (Error Case) }}
  - Send an order entry message from CONNEQTOR.
  - Participant system sends an order acceptance notice to CONNEQTOR
  - Participant system sends an order to ToSTNeT.
  - When an order fails, ToSTNeT sends a named counterparty error notice to participant system.
  - Participant system sends an Order Approval Rejection/Error Notice to CONNEQTOR.
;#;
** Figure 6.2.2 Sequences of CONNEQTOR Order (Error Case)  **
;#;
\\
== (3) Expired CONNEQTOR Order in ToSTNeT ==
The following diagram shows the basic sequences when a CONNEQTOR order is expired.

{{ :spec:en:fig6-2-3.svg?900 |Figure 6.2.3 Sequences of Expired CONNEQTOR Order in ToSTNeT}}
  - Send an order entry message from CONNEQTOR.
  - Participant system sends an order acceptance notice to CONNEQTOR
  - Participant system sends an order to ToSTNeT.
  - ToSTNeT sends an order acceptance notice.
  - ToSTNeT sends a named counterparty expiry notice.
  - Participant system sends an expired order notice to CONNEQTOR.

;#;
** Figure6.2.3 Sequences of Expired CONNEQTOR Order in ToSTNeT **
;#;
\\
== (4) Timeout of Execution Notice ==
In case Participant fails to send an Execution Notice to CONNEQTOR by the end of working hours of CONNEQTOR, the order is regarded timed out and expired.
\\
== (5) Rejection of Order Approval of its own customer ==
The following diagram shows the basic sequences when the participant rejects an order approval of its own customer. Figure 6.2.4 Sequences of Rejection of Order Approval of its own customer.

{{ :spec:en:fig6-2-4.svg?600 |Figure 6.2.4 Sequences of Rejection of Order Approval of its own customer}}
  - Send an order entry message from CONNEQTOR.    
  - Participant system sends an Order Approval Rejection/Error Notice to CONNEQTOR.
;#;
** Figure 6.2.4 Sequences of Rejection of Order Approval of its own customer **
;#;
\\
== (6) Rejection of Order Approval by Counterparty Participant ==
The following diagram shows the basic sequences when the counterparty participant rejects an order approval. 

{{ :spec:en:fig6-2-5.svg?900 |Figure 6.2.5 Sequences of Rejection of Order Approval by Counterparty Participant}}
  - Send an order entry message from CONNEQTOR.
  - Participant system sends an order acceptance notice to CONNEQTOR
  - Participant system sends an order to ToSTNeT.
  - ToSTNeT sends an order acceptance notice.
  - When CONNEQTOR receives an order approval rejection /error notice of counterparty participant, CONNEQTOR sends cancel order entry message to participant system.
  - Participant system receives a cancel order entry message, then send a cancel order to ToSTNeT.
  - ToSTNeT sends a named counterparty order cancel result notice
  - Participant system sends order cancel result notice to CONNEQTOR. (If cancellation is not possible, participant system sends an order cancel error notice instead.)

;#;
** Figure 6.2.5 Sequences of Rejection of Order Approval by Counterparty Participant **
;#;
\\
== (7) Cancellation by brokers after placing orders on ToSTNeT  ==
The following diagram shows the basic sequences when a participant cancels an order after placing orders on ToSTNeT for some reasons (e.g. the counterparty participant does not place orders on ToSTNeT).

{{ :spec:en:fig6-2-6.svg?900 |Figure 6.2.6 Sequence of Cancellation by brokers after placing orders on ToSTNeT}}
  - Send an order entry message from CONNEQTOR.
  - Participant system sends an order acceptance notice to CONNEQTOR
  - Participant system sends an order to ToSTNeT.
  - ToSTNeT sends an order acceptance notice.
  - Participant system sends cancel orders to ToSTNeT.
  - ToSTNeT sends Cancel Result Notice to Participant system.
  - Participant System sends Order Approval Rejection /Error Notice to ToSTNeT.
;#;
** Figure 6.2.6 Sequence of Cancellation by brokers after placing orders on ToSTNeT **
;#;
\\
==== 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 7 "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. Participant system detects a logically inconsistent error (fatal error) in a message (upstream) received from CONNEQTOR. ==
The following diagram shows the sequences for an invalid protocol case where an upstream message from CONNEQTOR is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and the participant system does not recognize it as normal. Figure 6.3.1 Sequence for Malformed Messages

{{ :spec:en:fig6-3-1.svg?500 |Figure 6.3.1 Sequence for Malformed Messages: Participant system detects a logically inconsistent error (fatal error) in a message (upstream) received from CONNEQTOR.}}
  - When participant system recognizes a message from CONNEQTOR as an invalid FIX-protocol, participant system sends a Reject to CONNEQTOR.
  - Participant 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 Participant 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: Participant system detects a logically inconsistent error (fatal error) in a message (upstream) received from CONNEQTOR. **
;#;
\\
== 2. CONNEQTOR detects a logically inconsistent error (fatal error) in a message (downstream) received from participant system. ==
The following diagram shows the sequences for an invalid protocol case where an downstream message from the participant 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:fig6-3-2.svg?500 |Figure 6.3.2 Sequence for Malformed Messages CONNEQTOR detects a logically inconsistent error (fatal error) in a message (downstream) received from participant system}}

  - When CONNEQTOR recognizes a message from participant system as an invalid FIX-protocol, CONNEQTOR sends a Reject to participant 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 Participant 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 (downstream) received from participant 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. Participant system detects an invalid data in a message (upstream) received from CONNEQTOR. ==
The following diagram shows the sequences for an invalid data case (minor error) and the participant system does not recognize it as normal.

{{ :spec:en:fig6-3-3.svg?500 |Figure 6.3.3 Sequence for Malformed Messages Participant system detects an invalid data in a message (upstream) received from CONNEQTOR}}

  - When participant 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, CONNEQTOR sends a Logon request to participant system to establish a FIX session.
  - When the FIX session has been established, CONNEQTOR restarts the notice sending operation from the one it recognizes "unsent."

* The first 5 bytes of the Text tag in the Logout request is set to the value which indicates the trading suspension (i.e. other than '00000').

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

{{ :spec:en:fig6-3-4.svg?500 |Figure 6.3.4 Sequence for Malformed Messages CONNEQTOR detects an invalid data in a message (downstream) received from participant system}}
  - When a data error (minor error) is detected by participant systems, the error content is set to Business Message Reject and sent to CONNEQTOR.
  - 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 (downstream) received from participant system.
**
;#;
\\
=== 6.3.2 Response when an illegal message is returned from ToSTNeT ===
The interface between participant system and ToSTNeT is outside the scope of the interface specifications. However, when a Reject or a Business Message Reject is returned from ToSTNeT, The participant system is required to retransmit a correct message to ToSTNeT. It is not required to return a Reject or a Business Message Reject messages from ToSTNeT to CONNEQTOR.
\\
\\
==== 6.4 Application-Level Retransmission Message (with PossResend = Y Messages) ====

When the participant 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.


* Execution Report\\
 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:fig7-1-1.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 Participants 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

ユーザ用ツール

サイト用ツール

ページ用ツール
