Version 1.0
Created in June 2023

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

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

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

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

Figure 2.1.1 Overall configuration image (Production)

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

This document describes the interface specifications based on FIX Protocol V4.2 (Errata) between CONNEQTOR and investor systems in the CONNEQTOR inter-system connection method. Messages other than those described in this document shall not be permitted for inter-system transmission.

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

The connection between investor system and CONNEQTOR is shown below. TCP/IP shall be used as the transmission control procedure, and it is connected through the arrownet.

Figure 3.1.1 Connection Configuration

Investor system shall connect to CONNEQTOR after sending the login message to CONNEQTOR and until sending the logout message to CONNEQTOR.

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

Investor shall follow RCFs shown below.

Table 3.2-1 TCP Version

CONNEQTOR and investor system shall establish TCP connections with IP addresses and port numbers arranged between Exchange and investor. The IP address and port number for investor system shall be assigned by investor at the time of applications. Investors are also required to assign their IP addresses and port numbers for their secondary system if they use, in addition to ones for their primary site. Those for CONNEQTOR shall be assigned by Exchange. The IP address and port numbers assigned by Exchange are described in the following figure.

Figure 3.2.2-1 IP Address and Port Number

The connection condition for TCP connection shall be as follows.

CONNEQTOR uses TCP_NODELAY when sending messages. Investor system is allowed to enable the TCP option when connection to CONNEQTOR if the option is judged to improve transmission efficiency.

• (Note) TCP_NODELAY is used to wait and aggregate data to utilize the line.

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

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.2(Errata)), and no special headers/trailers shall be added.

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

Figure 4.2.1 Relationship between TCP connection and FIX Session

• Logon Request – Procedures for connection confirmation, arrangement of connection conditions, and message synchronization at the time of TCP connection. In addition, this means the procedure for starting the session when the FIX session has not been started. (The MsgSeqNum of the Logon message at this time is 1.)
• Logout Request – Procedures to gain attention of the other system before disconnecting TCP connection. Disconnection without this procedure is abnormal. Note that Logout does not indicated the end of the FIX session.
• FIX Session Conclusion – The timing of the conclusion of the FIX session shall be based on agreement between the two systems connected by the FIX Protocol. For example, there is a way to reset a session at the end of a day's trade.

Furthermore, the persistence of the FIX session shall, substantially, refer to the following situations.
　　A) Where the order of messages transmitted via the session is maintained by maintaining transmission sequence numbers.
　　B) Where the transmitted message log is maintained in case of retransmission of messages.

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, investor shall be initiator, while TSE shall be acceptor.

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, investor 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 investor system. However, no Heartbeat response comes in, another timeout occurs, and then the TCP connection is disconnected.
Note) The time until the Heartbeat Reception Monitoring timeouts shown in the figure is the total time of the Heartbeat Reception Monitoring Time and the HeartBeat reception allowance time.

Figure 4.5.1 HeartBeat

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

CONNEQTOR shall use the following Protocol Control Parameters to properly control the FIX Protocol, including for infinite loop avoidance and response monitoring.

Table 4.8.1 Protocol Control Parameters

Messages used in CONNEQTOR are shown below.

Table 5.1.1 Message List

*) 　Upstream: Investor Systems → CONNEQTOR
　　Downstream: CONNEQTOR → Investor Systems

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 active establishment, the investor system makes a TCP connection and Logon request to CONNEQTOR. If there are no problems authenticating the Logon request, a Logon response shall be sent to investor system and the establishment shall be completed.

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

Figure 6.1.2 Establish (Authentication OK)

If there is a problem authenticating Logon request received from investor system, it is judged to be a party with invalid connection, and the connection will be refused by disconnecting the TCP connection.

Figure 6.1.3 Establish (Authentication Denied)

Active release in the investor system receives a Logout response from the CONNEQTOR to the Logout request, at which point the release is complete. Investor system shall disconnect the TCP connection.

Figure 6.1.4 Active Release

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

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

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

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 investor system uses a HeartBeat, CONNEQTOR monitors the interval of messages received from the investor system. When no messages are sent even after the monitoring time elapses, CONNEQTOR shall send a TestRequest to confirm the existence of the investor system. If, due to some reason, no response is received from the investor system again, CONNEQTOR shall deem that a failure has occurred in the line or investor system and disconnect the TCP connection.

Figure 6.1.6 Timeout of HeartBeat Reception Monitoring
Note) Since the existence of the investor system cannot be verified, the TCP connection shall be disconnected without sending a Logout request.

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

Figure 6.1.7 Receive ResendRequest (retransmission request) from investor system

When a sequence gap is detected in a message received from the investor system, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the missing message. The following shows the sequences when CONNEQTOR detects the sequence gap in Application Messages received from the investor system.

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

Figure 6.1.8 Gap Detection when Receiving AplMessages

When CONNEQTOR detects a sequence Gap in a message from the investor system at the receipt of a Logon request, CONNEQTOR shall first send a Logon response to the investor system, then send a ResendRequest to request the retransmission of the message. For example, if CONNEQTOR could not receive the message from the investor system due to the system down, this sequence shall be performed.

Figure 6.1.9 Gap Detection when Receiving Logon request

When a sequence gap is detected in a message from investor system at the receipt of a Logout request, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message. Then it shall send a Logout response when it receives all the messages that requested the retransmission.

Figure 6.1.10 Gap Detection when Receiving Logout request

When a sequence gap is detected in a message from the investor system at the receipt of a HeartBeat, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

Figure 6.1.11 Gap Detection when Receiving HeartBeat

When a sequence gap is detected in a message from the investor system at the receipt of a TestRequest, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

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

Figure 6.1.12 Gap Detection when Receiving TestRequest

When a sequence gap is detected in a message from the investor system at the receipt of a ResendRequest, CONNEQTOR shall first process the retransmission request from the investor system and then send a ResendRequest to request a retransmission of the message.

Figure 6.1.13 Gap Detection when Receiving ResendRequest

When a sequence gap is detected in a message from the investor system at the receipt of a SequenceReset-GapFill, CONNEQTOR shall send another ResendRequest to the investor system requesting a retransmission of the message, even though the GapFill process is still ongoing.

Figure 6.1.14 Gap Detection when Receiving SequenceReset-GapFill

When a sequence gap is detected in a message from the investor system at the receipt of a Reject, CONNEQTOR shall immediately send a ResendRequest to request a retransmission of the message.

Figure 6.1.15 Gap Detection when Receiving Reject

NOTE) Reject is an administrative message to be retransmitted.

If an Application Message from the investor system and a ResendRequest from CONNEQTOR cross over after sending a ResendRequest following a detection of a sequence gap, CONNEQTOR will detect another sequence gap in the Application Message and send another ResendRequest. There is a possibility that another resent message could be lost, thus CONNEQTOR shall send a ResendRequest every time a sequence gap is detected.

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

This section describes examples of application message sequences between investor system and CONNEQTOR. For the reason codes to be set for error notices, etc., refer to Appendix 1 “List of Reason Codes in CONNEQTOR FIX Interface Specifications (Data Format)”.

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

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

1. Investor system sends RFQ to CONNEQTOR.
2. CONNEQTOR sends acceptance notification to investor system.
3. After execution on ToSTNeT, CONNEQTOR sends execution notification to the investor system.
4. CONNEQTOR sends Done for day to the investor system.

Figure 6.2.1 Sequences From RFQ Sending to Receive Execution Notifice (Normal)

The following diagram shows the basic sequences for an error case in RFQ sending.

1. Investor system sends RFQ to CONNEQTOR.
2. CONNEQTOR sends rejection notice to investor system.

Figure 6.2.2 Sequences of RFQ Sending (Error Case)

The following diagram shows the basic sequences of RFQ Cancellation, etc.

1. Investor system sends RFQ to CONNEQTOR.
2. CONNEQTOR sends acceptance notification to investor system.
3. CONNEQTOR sends cancellation notice to investor system.

Figure 6.2.3 Sequences of RFQ Cancelled, etc.

This section describes examples of sequences for abnormal case. For the reason codes to be set for error notices, etc., refer to Appendix 1 “List of Reason Codes in CONNEQTOR FIX Interface Specifications (Data Format)”.

The following diagram shows the sequences for an invalid protocol case where an downstream message from CONNEQTOR is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and the investor system does not recognize it as normal. Figure 6.3.1 Sequence for Malformed Messages

1. When investor system recognizes a message from CONNEQTOR as an invalid FIX-protocol, investor system sends a Reject to CONNEQTOR.
2. Investor is required to contact TSE to investigate the cause of the error.

* See “4.7 Protocol Error (Session Reject)” for Reject sending condition.
* Commonly, CONNEQTOR does not send incorrect messages to investor System. Recovery Procedure: After the cause of the error is eliminated, the FIX session establishment sequence is executed.

Figure 6.3.1 Sequence for Malformed Messages
Investor system detects a logically inconsistent error (fatal error) in a message (downstream) received from CONNEQTOR.

The following diagram shows the sequences for an invalid protocol case where an upstream message from the investor system is not FIX compliant (i.e. it does not conform to the FIX protocol v4.2 (Errata)) and CONNEQTOR does not recognize it as normal.

1. When CONNEQTOR recognizes a message from investor system as an invalid FIX-protocol, CONNEQTOR sends a Reject to investor 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 investor system and disconnect without waiting for Logout Response

* The first 5 bytes of the Text tag in the Logout request represents the reason for the release request.
Recovery Procedure: After the cause of the error is eliminated, the FIX session establishment sequence is executed.

Figure 6.3.2 Sequence for Malformed Messages
CONNEQTOR detects a logically inconsistent error (fatal error) in a message (upstream) received from investor system

“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 investor system does not recognize it as normal.

1. When investor system detects an invalid message content, it sends a Logout request to CONNEQTOR and release the FIX session. Furthermore, it is required to contact TSE to investigate the cause of the error.
2. After getting rid of a cause, investor system sends a Logon request to CONNEQTOR to establish a FIX session.
3. When the FIX session has been established, CONNEQTOR restarts the notice sending operation from the one it recognizes “unsent.”

Figure 6.3.3 Sequence for Malformed Messages
Investor system detects an invalid data in a message (downstream) received from CONNEQTOR

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 CONNEQTOR, the error content is set to Reject Message and sent to investor system.
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 (upstream) received from investor system.

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

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

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

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 investor shall confirm in advance that they will be able to communicate in accordance with the specifications set forth herein. Therefore, when implementing to newly establish / change FIX clients, the both parties shall agree on a new/changed work schedule, test schedule, etc. and respond without delay according to the schedule.

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