Released July 2023
Applicable on July 2023

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).

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.

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.

Figure 2.1.1 Overall configuration image (Production)

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.

Figure 2.1.2 Overall configuration image (Staging)

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.

This section shows the connection configuration and specification between the participant system and CONNEQTOR.

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.

Figure 3.1.1 Connection Configuration

Participant shall connect to CONNEQTOR after receiving the login message from CONNEQTOR and until receiving the logout message from CONNEQTOR.

Transmission between the FIX service of the participant system and CONNEQTOR shall be conducted via TCP/IP.

Participant shall follow RCFs shown below.

Table 3.2-1 TCP Version

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.

Figure 3.2.2-1 IP Address and Port Number (via arrownet)

Figure 3.2.2-2 IP Address and Port Number (via internet)

The connection condition for TCP connection shall be as follows.

Table 3.2.2 TCP connection Conditions

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.

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.

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

TLS 1.2 is supported.

The following cipher suites are supported.

Table 3.3.1 TCP connection Conditions

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.

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.

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.

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.

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.
  

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.

Figure 4.3.1 Establish Session

In CONNEQTOR, participant shall be acceptor, while TSE shall be initiator.

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.

Figure 4.4.1. Release Session

In CONNEQTOR, TSE shall be the initiator of the session release.

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.

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

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

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

*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.

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

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

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

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.

Switching procedures of FIX clients of Participant System when Participant has a secondary system are shown below.

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.

*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

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.

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.

Messages used in CONNEQTOR are shown below.

Table 5.1.1 Message List

*) Upstream: CONNEQTOR → Participant Systems
Downward: Participant Systems → CONNEQTOR

This section provides an example of the control sequence for the FIX protocol Control 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.

Note that the sequence numbers are continued even after releasing the sequence.

Figure 6.1.1 Sequence overview

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.

Figure 6.1.2 Establish (Authentication OK)

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.

Figure 6.1.3 Establish (Authentication Denied)

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”.

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.

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”.

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.

Figure 6.1.5: HeartBeat Transmission

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.

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.

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.

Figure 6.1.7 Receive ResendRequest (retransmission request) from participant system

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)

Figure 6.1.8 Gap Detection when Receiving AplMessages

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.

Figure 6.1.9 Gap Detection when Receiving Logon 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.

Figure 6.1.10 Gap Detection when Receiving Logout request

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”.

Figure 6.1.11 Gap Detection when Receiving Logout response

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.

Figure 6.1.12 Gap Detection when Receiving HeartBeat

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.

Figure 6.1.13 Gap Detection when Receiving TestRequest

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.

Figure 6.1.14 Gap Detection when Receiving ResendRequest

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.

Figure 6.1.15 Gap Detection when Receiving SequenceReset-GapFill

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.

Figure 6.1.16 Gap Detection when Receiving Reject

NOTE) Reject is an administrative message to be retransmitted.

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.

Figure 6.1.17 Cross-over between ResendRequest (retransmission request) and AplMessages

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)”.

The below describes examples of operation-related message sequences used in CONNEQTOR.

The following diagram shows the basic sequences of CONNEQTOR normal messages.

1. Send an order entry message from CONNEQTOR.
2. Participant system sends an order acceptance notice to CONNEQTOR
3. Participant systems sends an order to ToSTNeT.
4. ToSTNeT sends an order acceptance notice.
5. When the order has been executed in ToSTNeT, ToSTNeT sends an execution completion notice to participant system.
6. Participant system sends an order execution notice to CONNEQTOR.

Figure 6.2.1 Sequences of CONNEQTOR Order (Normal)

The following diagram shows the basic sequences for an error case in placing an order in CONNEQTOR.

1. Send an order entry message from CONNEQTOR.
2. Participant system sends an order acceptance notice to CONNEQTOR
3. Participant system sends an order to ToSTNeT.
4. When an order fails, ToSTNeT sends a named counterparty error notice to participant system.
5. Participant system sends an Order Approval Rejection/Error Notice to CONNEQTOR.

Figure 6.2.2 Sequences of CONNEQTOR Order (Error Case)

The following diagram shows the basic sequences when a CONNEQTOR order is expired.

1. Send an order entry message from CONNEQTOR.
2. Participant system sends an order acceptance notice to CONNEQTOR
3. Participant system sends an order to ToSTNeT.
4. ToSTNeT sends an order acceptance notice.
5. ToSTNeT sends a named counterparty expiry notice.
6. Participant system sends an expired order notice to CONNEQTOR.

Figure6.2.3 Sequences of Expired CONNEQTOR Order in ToSTNeT

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.

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.

1. Send an order entry message from CONNEQTOR.
2. 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

The following diagram shows the basic sequences when the counterparty participant rejects an order approval.

1. Send an order entry message from CONNEQTOR.
2. Participant system sends an order acceptance notice to CONNEQTOR
3. Participant system sends an order to ToSTNeT.
4. ToSTNeT sends an order acceptance notice.
5. When CONNEQTOR receives an order approval rejection /error notice of counterparty participant, CONNEQTOR sends cancel order entry message to participant system.
6. Participant system receives a cancel order entry message, then send a cancel order to ToSTNeT.
7. ToSTNeT sends a named counterparty order cancel result notice
8. 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

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).

1. Send an order entry message from CONNEQTOR.
2. Participant system sends an order acceptance notice to CONNEQTOR
3. Participant system sends an order to ToSTNeT.
4. ToSTNeT sends an order acceptance notice.
5. Participant system sends cancel orders to ToSTNeT.
6. ToSTNeT sends Cancel Result Notice to Participant system.
7. Participant System sends Order Approval Rejection /Error Notice to ToSTNeT.

Figure 6.2.6 Sequence of Cancellation by brokers after placing orders on ToSTNeT

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)”.

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

1. When participant system recognizes a message from CONNEQTOR as an invalid FIX-protocol, participant system sends a Reject to CONNEQTOR.
2. 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.

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.

1. When CONNEQTOR recognizes a message from participant system as an invalid FIX-protocol, CONNEQTOR sends a Reject to participant system.
2. When receiving another malformed message, CONNEQTOR resends a Reject.
3. 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

“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.

The following diagram shows the sequences for an invalid data case (minor error) and the participant system does not recognize it as normal.

1. 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.
2. 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

The following diagram shows the sequences for an invalid data case (minor error) detected by CONNEQTOR.

1. When a data error (minor error) is detected by participant systems, the error content is set to Business Message Reject and sent to CONNEQTOR.
2. 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.

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.

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.

The following shows the daily system operation.

Reset the sequence number on the first Logon of the day.

Figure 7.1.1 Daily System Operation

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.

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.

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