1.2版
2023年7月 開示
2023年7月 適用

本仕様書は、CONNEQTORと取引参加者システム（以下「参加者システム」という。）間のFIX（Financial Information eXchange）プロトコルに基づく接続仕様を記述したものである。 なお、システム間の全ての電文及び通信手順は、FIXプロトコルV4.2(Errata)に準拠するものとする。

機関投資家とマーケットメイカーはCONNEQTORを通じて気配提示依頼や気配提示を行い、CONNEQTORはマッチした注文等の情報を本仕様書に定める接続仕様に準じて参加者システムに連携する。参加者システムまたはCONNEQTORはToSTNeTシステム間接続仕様書・FIX接続仕様書に準じてToSTNeTに注文する。

CONNEQTORは、arrownet(注1)またはインターネットを経由して参加者システムのFIXクライアントに接続する。 参加者システムは、CONNEQTORと通信を行うためのFIXクライアントを設置する。FIXクライアントは、FIX　V4.2(Errata)に準拠したFIXサービス（注2）とFIXアプリケーション（注3）が存在する。参加者システムのFIXサービスは、CONNEQTORのFIXサービスと実際に通信を行うFIXの制御部である。FIXアプリケーションは、接続要求（Logon）によりCONNEQTORとの間にFIXセション（論理リンク）（注4）を確立する。 FIXサービスは参加者側にて用意する必要がある。また、FIXアプリケーションは、後述の電文シーケンス及び、電文フォーマットに従い参加者側にて作成する必要がある。 FIXサービスとFIXアプリケーションは1つのアプリケーションとして存在しても特に問題はない。（参加者側のシステムに依存）

• （注1）arrownetへの接続にあたっては「arrownet version2.0ガイドライン【ネットワーク接続_共通編】」「arrownet version2.0ガイドライン【ネットワーク接続_JPX編】」及び「arrownet version2.0ガイドライン【手続き・運用_共通編】」「arrownet version2.0ガイドライン【手続き・運用_JPX編】」に記載されているルールにしたがって必要なネットワーク設定を行うこと。
• （注2）FIXサービスとは、FIXプロトコルに準拠したメッセージの送受信制御部分を実装するアプリケーションである。
• （注3）FIXアプリケーションとは、ＦＩＸサービスの上位に位置するもので、東証FIX接続仕様書に準拠したFIX業務メッセージの分解、チェック、組立て等を実装するアプリケーションである。
• （注4）1FIXセションは、CONNEQTORで対応しているシステム区分単位に括り付けとし、1FIXセションは1システム区分にかかる取引区分の業務のみを行う。

本番面は本システムのサービスを利用することを目的とした環境である。利用可能時間は取引日の8:00（JST）から18:00（JST）である。
取引日の8:00（JST）に、CONNEQTORは全ての参加者システムのFIXクライアントに対してログオンを試みる。
図 2.1.1に示すCONNEQTOR（本番面）、プライマリセンタのToSTNeT・NW機器、arrownetの広域被災時においては、同環境でのサービス再開を目指し、当該機器が復旧するまで本サービスを停止する。また、耐障害性を考慮し参加者システムのFIXクライアントは同一IPアドレスまたは異なるIPアドレスで冗長化することが可能である。
本番面の全体構成イメージを図 2.1.1に示す。
取引所から参加者システムへはarrownetまたはインターネットのいずれかを経由して接続する。
取引日の18:00（JST）に、CONNEQTORは参加者システムのFIXクライアントからログアウトを行う。

図 2.1.1 全体構成イメージ（本番面）

ステージング面は、テストを行うことを目的とした環境である。

基本的にテストは平日木曜日、金曜日に実施し、祝日と重なる場合は実施対象外とする（平日月曜日～水曜日はFIX未接続でのテスト等を行う）。
テスト実施日の8:00（JST）に、CONNEQTORは全ての参加者システムのFIXクライアントに対してログインを試み、FIXセションを確立した参加者システムのみをテストの参加対象とみなす。
テストの途中に参加者起因（参加者システムのメンテナンス作業等）でFIXセションが切断された場合は、再ログインを試みない。 CONNEQTOR起因（CONNEQTORのシステム障害等）でFIXセションが切断された場合は、再度全ての参加者システムのFIXクライアントに対してログインを試みる。

投資家、マーケットメイカーが、FIXのログインを行っていない証券会社を選択してマッチングした場合、証券会社と通信できないため、マッチング処理以降のテストを実施することができない。このため、取引所は擬似参加者を用意し、投資家、マーケットメイカーは擬似参加者を選択してテストすることを可能とする。
また、図 2.1.2に示すCONNEQTOR（ステージング面）、プライマリセンタのNW機器、セカンダリセンタのToSTNeT、arrownetの広域被災時は、同環境でのサービス再開を目指し、当該機器が復旧するまでテスト実施対象外とする。

ステージング面の全体構成イメージを図 2.1.2に示す。 取引所から参加者システムへはarrownetまたはインターネットのいずれかを経由して接続する。

図 2.1.2 全体構成イメージ（ステージング面）

本仕様書は、CONNEQTORにおけるシステム間接続方式において、CONNEQTORと参加者システム間のFIXプロトコルV4.2(Errata)に準拠する接続仕様について記述したものである。システム間通信において、本仕様書記載以外の電文は認めないものとする。

本章では、参加者システムとCONNEQTORとの接続構成と接続条件について示す。

参加者システムとCONNEQTORとの接続形態を以下に示す。伝送制御手順としてはTCP/IPを使用し、arrownetまたはインターネット経由で接続する。

図 3.1-1 接続構成

取引参加者は、CONNEQTORからのログイン電文を受信してからCONNEQTORからのログアウト電文を受信するまではCONNEQTORと接続しなければならない。

参加者システムのFIXサービスとCONNEQTOR間はTCP/IPにより通信する。

基本的に、下表に記載のRFCに準拠しなければならない。

表 3.2-1 TCPバージョン

CONNEQTORと参加者システムは取引所と取引参加者の間で決められたIPアドレス、ポート番号でTCPコネクションを確立して業務を行う。

参加者システムが利用するIPアドレス、ポート番号については利用申請時に参加者側から指定する。FIXクライアントを異なるIPアドレスで冗長化する場合は、現用系・待機系双方のIPアドレス、ポート番号を指定する。CONNEQTORのIPアドレス、ポート番号については利用申請時に取引所側で指定したものを使用する。IPアドレスおよびポート番号について取引所より割り当てられる箇所については下図を参照。

図 3.2.2-1 IPアドレスとポート番号 (arrownet経由で接続する場合)

図 3.2.2-2 IPアドレスとポート番号 (インターネット経由で接続する場合)

TCPコネクションの接続条件を以下に示す。

CONNEQTOR側は、電文送信時にTCP_NODELAYのパラメータを採用する。 取引参加者システム側は、当該パラメータがCONNEQTORへの送信効率を向上させるものと判断された場合、CONNEQTORとのTCPコネクション接続にて設定を有効にすることが可能である。

• TCP_NODELAYとは、回線を効率よく使用するためにまとめてデータを送る目的で適宜待ち合わせて送信するかどうかを設定するものである。

取引参加者は、CONNEQTORに過度な負荷をかける通信(TCPコネクション確立中に再度確立を要求するパケットを送信する、通信シーケンスの異常を検知した際の復旧を求めるパケットを極めて短い間隔で連続的に送信する等)を行ってはならない。
当該禁止事項に違反し、不正な通信を検出(取引所からの連絡を含む)した場合には、速やかにコネクションを遮断する等の対策を講じなければならない。

インターネット経由で接続する場合の接続条件(SSL/TLS)について以下に記す。
arrownet経由で接続する場合、SSL/TLSは用しない。

TLS1.2をサポートする。

下表に示す暗号スイートをサポートする。
　　　　　　　　　　　 表 3.3.1 TCPコネクション接続条件

　サーバ証明書はアクセプタ（参加者）が用意する。 クライアント証明書は必須とせず、取引参加者が利用有無を定める。クライアント証明書を利用する場合はイニシエータ（取引所）が証明書を用意し、参加者は、取引所のプライベートCAのルート証明書をインポートし、クライアント証明書を用いたTLSセッション確立を行う。

　FIXセションとは、２つのシステム間における双方向の連続的なシーケンス番号を持つ順序だったメッセージの流れと定義される。
　一連の会話の中では、送受信されるすべてのメッセージに一意なシーケンス番号が振られ、メッセージの順序性及び欠落のないメッセージ転送が保証される。シーケンス番号は、メッセージの転送方向毎に送信シーケンス番号、受信シーケンス番号が別々に管理され、セション開始時にそれぞれ１から始まり、１ずつ増加していく。
　FIXセションはシーケンス番号が１であるLogonメッセージの交換により開始される。通信を行う２者間の合意に基づき、シーケンス番号がお互いにクリアされた時点で終了する。また、通信を行う２者は、Logon/Logoutメッセージの交換により、FIXセションの確立、解放を繰り返すことで、FIXセションを維持したまま何度でも会話の中断、再開を行うことができる。

図 4.1.1　FIXセションの開始と終了

• 注）本書では通信リンク（TCPコネクション）の接続／切断をともなうメッセージ交換の再開／中断のことをFIXセションの確立／解放と呼ぶ。FIXセションの開始／終了とは別の意味であることに注意されたい。

TCPコネクションとFIXセションは、ある時点を見れば1対1に対応する。1つのTCPコネクションに複数のFIXセションのメッセージを混在させて送受信することはできないし、1つのFIXセションのメッセージを同時に複数のTCPコネクションに分割して送受信することもできない。また、TCPコネクションを通してやりとりされるデータは、FIXプロトコル仕様 (Ver4.2(Errata))で規定されたメッセージそのものであり、特別なヘッダ/トレーラの付加は行わない。

FIXセションは(時間的に)複数のTCPコネクションをまたがって存続する。単一のFIXセションの中で、複数回のLogon/Logoutが可能である。

図 4.2.1 TCPコネクションとFIXセションの関係

• Logon要求 TCPコネクションの接続時に、接続の認証、接続条件の取り決め、及びメッセージの同期合わせを行うための手続き。 また、FIXセションが未開始の状態では、セション開始手続きの意味を持つ。(この時、LogonﾒｯｾｰｼﾞのMsgSeqNumは1である。)
• Logout要求 TCPコネクションの切断に先立ち、相手システムとの意識合わせを行う手続き。この手続きなしでの切断は、異常な事態である。 LogoutはFIXセション終了を意味しないことに注意。
• FIXセションの終結 FIXセション終結のタイミングは、FIXプロトコルによって接続される２つのシステムの間の合意に基づく。例えば、１日の取り引きの終わりの決められた時刻にセションをリセットするなどの手段がある。

なお、FIXセションの存続とは、実質的には、次の状態を意味する。
　　A) 送受信シーケンス番号の保持によって、セションを通して転送されるメッセージの順序性が維持されている状態。
　　B) メッセージの再送に備え、送信メッセージのログが保持されている状態。

通信を行なう2者間でLogonメッセージを交換することにより、FIXセションの確立を行うことができる。
Logonメッセージの送信者（イニシエータ）はTCPコネクションを接続後、Logonメッセージを送信する。Logonメッセージの受信者（アクセプタ）は受信したLogonメッセージの認証を行い相手が正しい接続先であると認めた場合には、Logon応答メッセージをイニシエータに送信する。認証を拒否する場合は、TCPコネクションを切断する。FIXセションの確立以降、相手システムとの間でメッセージの送受信が可能となる。

図 4.3.1　セションの確立

なお、CONNEQTORでは、参加者側がアクセプタ、東証側がイニシエータとなる。

Logoutメッセージを交換することにより、FIXセションを解放することができる。
Logoutメッセージの送信者は、欠落メッセージの検出シーケンス（下図の網かけ部分）を実行することにより、送信した全てのメッセージが相手システムに到達したことを確認する。この結果、欠落メッセージがないことを確認して、Logoutメッセージの送信を行う。
FIXセションの解放以降、相手システムとの間でメッセージの送受信はできない。

図 4.4.1 セションの解放

なお、CONNEQTORでは、東証側がセション解放の開始者となる。

　FIXプロトコルでは、接続された２つのシステムの間で、互いにメッセージの到着間隔を監視することにより、相手システムまたはネットワークの状態をモニタしている。LogonメッセージのHeartBtInt(Tag=108)で指定された時間＋ハートビート受信余裕時間（回線等の影響でメッセージが遅延することを考慮した時間）以上経過しても相手システムからメッセージが到着しない場合には、Test Requestメッセージを送信して、相手システムのHeartBeatメッセージを誘発する。
　Test Requestメッセージを送信したが、一定時間内に応答のHeartBeatメッセージを受信しない場合は、相手システムまたはネットワークに何らかの異常が発生したものと判断してTCPコネクションを切断する。逆に、LogonメッセージのHeartBtInt(Tag=108)に指定した時間が経過しても、アプリケーションからメッセージの送信要求が無い場合、HeartBeatメッセージを生成し、自システムが生存していることを相手に通知する。
また、HeartBeatメッセージは、欠落メッセージの早期検出のためにも用いられる。

ハートビート受信監視タイムアウトをトリガに Test Request を送信して参加者システムのHeartBeatを誘発する。しかし、何も送信されてこないため、再度受信タイムアウトが発生し、TCP コネクションを切断する。
※図中に示すハートビート受信監視のタイムアウトまでの時間は、ハートビート受信監視タイマとハートビート受信余裕タイマの合計時間である。

図 4.5.1 ハートビート

受信するメッセージのMsgSeqNum(Tag=34)を検証することで、欠落メッセージを検出することができる。欠落メッセージを検出した場合は、Resend Request（再送要求）メッセージを送信して、相手システムに再送処理を要求する。再送要求を受信した場合は、要求されたシーケンス番号を持つメッセージの再送処理を行う。

セションを通して一意に管理されるシーケンス番号は以下の２種類である。

• 送信シーケンス番号 ：メッセージ送信時、MsgSeqNum(Tag=34)に設定する番号。メッセージ送信後はカウントアップし、次に送信するメッセージに設定する番号とする。
• 受信シーケンス番号 ：次に受信するメッセージのMsgSeqNum(Tag=34)に設定されていることを期待する番号。

メッセージ受信時、管理されている受信シーケンス番号と受信したメッセージのMsgSeqNum(Tag=34)の関係により、以下の処理を行う。

表 4.6.1　メッセージ受信時の処理

PossDupFlag(Tag=43)がYに設定されているメッセージは、本表の適用対象外となる。

ResendRequest（再送要求）メッセージを受信した場合、要求されたシーケンス番号を持つメッセージの再送処理を行う。再送メッセージはPossDupFlag(Tag=43)をYに設定して送信する。なお、再送対象が管理メッセージの場合、再送対象の管理メッセージの代わりに、SequenceResetメッセージを送信する。管理メッセージの再送について、以下の表 4.6.2　制御メッセージの再送可否表 4.6.2に記述する。

表 4.6.2　制御メッセージの再送可否

*補足）通常、管理メッセージの代行として送信するメッセージは、Sequence Reset-GapFill(GapFillFlag(123)=Y)を使用するが、再送要求で指定されたメッセージを送信できない場合（送信履歴にない等）は、Sequence Reset-Reset(GapFillFlag(123)=N)を使用する。SequenceReset-Reset使用時は、メッセージが失われた可能性がある。

本シーケンスは、MsgSeqNum=13 のAplMessageを受信した時にGapを検出し、GapFill処理を行うシーケンスである。AplMessageとは、アプリケーションメッセージを指す。全てのアプリケーションメッセージは再送の対象である。
※1 このように Gap 検出で再送要求を出す場合、ResendRequest(再送要求)メッセージで要求する再送範囲は、正常に受信したメッセージの次のシーケンス番号から0番（無限大の意）までとする。0番までとすることは、再送要求を受信するシステムに対して、最後に送信した電文までが再送対象であることを示している。
※2 MsgSeqNum=12のHeartBeatメッセージは、再送対象外の管理メッセージであるため、SequenceReset-GapFill メッセージを代わりに送信する。

図 4.6.1 GapFILLシーケンス

FIXプロトコル上、許されないメッセージを受信した場合、受信したシステムは、受信したメッセージを破棄する。ただし、プロトコルエラーの種類によっては、送信元システムに対してRejectまたはBusinessMessageRejectを送信する。 RejectまたはBusinessMessageRejectを送信する条件は、以下の表に従う。

表 4.7.1　不正なメッセージを受信した場合の処理

CONNEQTORでは、無限ループの回避や応答監視用など、FIXプロトコルを正常に制御するために、以下のプロトコル制御パラメタを使用する。

表 4.8.1　使用するプロトコル制御パラメタ

FIXセッションが確立できなかった場合、または、何らかの理由で切断され再接続（※）できなかった場合、本仕様書最終頁記載の連絡先に連絡するものとする。 その後、CONNEQTORから参加者システムへのログオンを試みる。なお、状況によってはFIXセッションのシーケンス番号リセットが必要となる可能性がある。 ※切断理由によって、切断検知後に自動でCONNEQTORから5分間ごとに最大3回までログオン要求を実施する。

参加者システムのFIXクライアントを冗長化したときの切替方法を示す。

arrownet経由の参加者システムで異なるIPアドレスで冗長化する場合は、日中に接続先を切り替えることが可能である。 通常時、CONNEQTORは参加者システムの現用系に接続を試みる。現用系との間でTCP/IP接続が切れた場合は待機系に自動で接続先を変更し、その後手動でFIX再接続を行う。

※1 現用系及び待機系と TCP/IP 接続が可能な場合は、現用系に通信する。現用系との TCP/IP 接続が 5 分間不通の場合は、自動的に待機系に通信先を切り替える。なお、FIX セションは自動的に確立しないため、東証担当者により手動での再接続が必要となる。
※2 待機系と通信時に現用系と TCP/IP 接続が可能になった場合は、自動的に現用系に通信先を切り替える。この場合も、FIX セションは手動での再接続が必要となる。

図 4.10.1　TCP/IPコネクション切替動作

表 4.10.1　FIX接続切替え・切戻しフロー

インターネット経由の参加者システムで異なるIPアドレスで冗長化する場合は、日中に接続先を切り替えることはできず翌営業日に切り替える。 接続先を切り替える場合、取引参加者は東証に対して、翌営業日の接続先切替え依頼を行う。

arrownet経由またはインターネット経由の参加者システムで同一のIPアドレスで冗長化する場合は、日中に接続先を切り替えることが可能である。 参加者システム側の切替えが完了した後、取引参加者は東証に対してFIX再接続依頼を行う。

CONNEQTORで使用するメッセージを以下に示す。

表 5.1.1 メッセージ一覧

※）　上り：CONNEQTOR ⇒ 参加者システム
　　　下り：参加者システム ⇒ CONNEQTOR
　　　のメッセージをいう

本章では、FIXプロトコルの制御シーケンス例について示す。

FIXプロトコルの通信シーケンスには、大きく分けてLogonをやり取りする確立シーケンス、アプリケーションメッセージをやり取りするメッセージ送受信、Logoutをやり取りする解放シーケンスがある。以下にFIXプロトコルの通信シーケンスの概要を示す。

補足)一度解放した後でも、シーケンス番号は継続していることに注意。

図 6.1.1　シーケンス概要

受動型確立では、CONNEQTORからのTCPコネクション接続とLogon要求受信を待ち合わせる。受信したLogon要求の認証に問題がない場合には、CONNEQTORに対してLogon応答を送信し、この時点で確立が完了する。

(注意) Logon要求/応答のMsgSeqNumは必ずしも1とは限らない。

図 6.1.2　確立（認証ＯＫ）

CONNEQTORから受信したLogon要求の認証に問題があった場合、不当な接続相手と判断し、TCPコネクションの切断により接続を拒否する。

図 6.1.3　確立（認証ＮＧ）

参加者システムにおける能動型解放は、「表 4.7.1　不正なメッセージを受信した場合の処理」の項番2に該当する不正電文受信、Reject電文を受信、CONNEQTOR側のシステム異常が発生した場合に行う。シーケンスについては、「6.3異常時のシーケンス」を参照。

受動的解放ではLogout要求に対してLogout応答を送信し、この時点で解放が完了する。TCPコネクションの切断はCONNEQTORが行う。

図 6.1.4　受動型解放

　受動型解放中に、参加者システムから送信されたLogout応答が伝送路上の消失等によりCONNEQTORに届かなかった場合、参加者システムはハートビート受信監視で異常を検出し、その時点でTCPコネクションを切断する。シーケンスについては、「6.1.3 (2)ハートビート受信監視タイムアウト」を参照。

CONNEQTORがHeartBeatを使用する時のシーケンスである。Logon要求のHeartBtIntで指定した時間が経過しても、何らメッセージを送信しない場合に、HeartBeatを送信する。

図 6.1.5　ハートビート送信

参加者システムがHeartBeatを使用する場合、CONNEQTORは、参加者システムから受信するメッセージの間隔を監視する。監視時間が経過しても何らメッセージが送信されてこない場合、CONNEQTORはTestRequestを送信して参加者システムの生存を確認する。再度、何らかの原因で参加者システムから応答がない場合、CONNEQTORは回線、または参加者システムに異常が発生したと判断してTCPコネクションを切断する。

図 6.1.6　受信ハートビート監視タイムアウト
補足）参加者システムの生存が確認できないため、Logout要求は送信せずにTCPコネクションを切断する。

参加者システムからのResendRequestを受信した場合、ResendRequestの要求内容に従って再送処理を行う。Rejectを除く管理メッセージは再送対象外であるため、再送範囲にこれらのメッセージが含まれていた場合には、SequenceReset-GapFillの送信で代替する。

図 6.1.7　参加者システムからResendRequest（再送要求）受信

参加者システムから受信したメッセージにシーケンスGapを検出した場合、即時にResendRequestを送信し、参加者システムに欠落したメッセージの再送を要求する。

下図はCONNEQTORが参加者システムから受信したApplication MessagesにシーケンスGapを検出した時のシーケンスである。

(注意) CONNEQTORは、欠落メッセージの先頭以降の全メッセージをResendRequestの再送要求範囲とする。(EndSeqNo=0固定)

図 6.1.8　AplMessages受信でGap検出

CONNEQTORがLogon要求受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、先ず参加者システムにLogon応答を送信してから、ResendRequestを送信してメッセージの再送を要求する。例えば、システムダウンで参加者システムからのメッセージをロストした場合に、このシーケンスが実行される。

図 6.1.9　Logon要求受信でGap検出

Logout要求受信でCONNEQTORからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。その後、再送を要求したメッセージが全て届いたらLogout応答を送信する。

図 6.1.10　Logout要求受信でGap検出

CONNEQTORがLogout応答受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、ResendRequestは送信せず、TCPコネクションを切断する。ここで失われたメッセージは、次の接続シーケンスで回復することを期待する。(「(3) Logon要求受信でGap検出」を参照。)

図 6.1.11　Logout応答受信でGap検出

HeartBeat受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。

図 6.1.12　HeartBeat受信でGap検出

TestRequest受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。 (注意)Gap検出時にはTestRequestの応答としてのHeartBeat送信は行わない。

図 6.1.13　TestRequest受信でGap検出

ResendRequest受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、参加者システムからの再送要求を処理した後に、ResendRequestを送信してメッセージの再送を要求する。

図 6.1.14　ResendRequest受信でGap検出

SequenceReset-GapFill受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、まだGapFill処理中であったとしても、再度、参加者システムにResendRequestを送信してメッセージの再送を要求する。

図 6.1.15　SequenceReset-GapFill受信でGap検出

Reject受信で参加者システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。

図 6.1.16　Reject受信でGap検出

補足）Rejectは再送対象の管理メッセージである。

シーケンスGapを検出してResendRequestを送信した後で、すれ違いにApplication Messageを受信した場合、受信したApplication MessageにもシーケンスGapを検出して、再度ResendRequestを送信する。再送メッセージが再び消失することも考えられるため、CONNEQTORは、シーケンスGapを検出する都度、必ずResendRequestの送信を行う。

図 6.1.17　ResendRequest（再送要求）とAplMessagesのすれ違い

本章では、参加者システムとCONNEQTOR間におけるアプリケーションメッセージのシーケンス例について示す。 なお、エラー通知等に設定される理由コードについては、「CONNEQTOR　ＦＩＸ接続仕様書（データフォーマット編）」の「付録２ 理由コード一覧」を参照。

本章では、CONNEQTORの業務系メッセージのシーケンス例を示す。

CONNEQTORの正常系メッセージの基本的なシーケンスを、以下の図 6.2.1に示す。

1. CONNEQTOR より注文入力電文を送信。
2. 参加者システムは注文受付通知をCONNEQTOR に送信
3. 参加者システムは ToSTNeT に発注する。
4. ToSTNeTは注文受付通知を送信する。
5. ToSTNeTでの約定成立後、ToSTNeTは参加者システムに約定成立結果を送信する。
6. 参加者システムは CONNEQTOR に注文約定通知を送信。

図 6.2.1　CONNEQTOR注文（正常系）のシーケンス

CONNEQTOR注文時がToSTNeTで業務エラーとなった場合の基本的なシーケンスを、以下の図 6.2.2に示す。

1. CONNEQTOR より注文入力電文を送信。
2. 参加者システムは注文受付通知をCONNEQTORに送信。
3. 参加者システムはToSTNeTに発注する。
4. 注文がエラーとなった場合、ToSTNeTから参加者システムに相手方指定注文エラー通知を送信する。
5. 参加者システムはCONNEQTORに注文承認拒否・注文エラー通知を送信する。

図 6.2.2　CONNEQTOR注文（業務エラー系）のシーケンス

CONNEQTOR注文がToSTNeTで失効となった場合の基本的なシーケンスを、以下の図 6.2.3に示す。

1. CONNEQTORより注文入力電文を送信。
2. 参加者システムは注文受付通知をCONNEQTORに送信。
3. 参加者システムはToSTNeTに発注する。
4. ToSTNeTは注文受付通知を送信する。
5. ToSTNeTは参加者システムに相手方指定注文失効通知を送信する。
6. 参加者システムはCONNEQTORに注文失効通知を送信する。

図 6.2.3　CONNEQTOR注文が失効となった場合のシーケンス

取引参加者が取引日のCONNEQTORの利用時間内にToSTNeTで約定した旨をCONNEQTORに送信できなかった場合、取引参加者からの注文失効通知がなくとも当該注文は失効したものとする。

取引参加者が自社顧客の注文承認を拒否した場合の基本的なシーケンスを、以下の図 6.2.4に示す。

1. CONNEQTORより相手方指定注文入力電文を送信。
2. 参加者システムは注文承認拒否・注文エラー通知をCONNEQTORに送信。

図 6.2.4　自社が注文承認を拒否した場合のシーケンス

相手方取引参加者が注文の承認を拒否した場合の基本的なシーケンスを以下の図 6.2.5に示す。

1. CONNEQTOR より注文入力電文を送信。
2. 参加者システムは注文通知をCONNEQTORに送信。
3. 参加者システムはToSTNeTに発注する。
4. ToSTNeTは注文受付通知を送信する。
5. CONNEQTORは相手方取引参加者の注文承認拒否通知及び注文エラー通知を受信すると、他方の取引参加者に対して取消注文入力電文を送信する。
6. 参加者システムは取消通知入力電文を受信後、ToSTNeTに注文取消を実施する。
7. ToSTNeTは参加者システムに相手方指定注文取消結果通知を送信する。
8. 参加者システムはCONNEQTORに注文取消結果通知を送信する。（なお、取消ができなかった場合には代わりに注文取消エラー通知を送信する）

図 6.2.5　相手方取引参加者の承認拒否のシーケンス

ToSTNeTへの発注後に相手方取引参加者からの発注がない等の理由により、取引を中止する場合の基本的なシーケンスを以下の図 6.2.7に示す。

1. CONNEQTORより注文入力電文を送信。
2. 参加者システムは注文通知をCONNEQTORに送信。
3. 参加者システムはToSTNeTに発注する。
4. ToSTNeTは注文受付通知を送信する。
5. 取引を中止することを決定し、参加者システムは取消通知入力電文を受信後、ToSTNeTに注文取消を実施する。
6. ToSTNeTは参加者システムに相手方指定注文取消結果通知を送信する。
7. 参加者システムは CONNEQTORに承認拒否・エラー通知を送信する。

図 6.2.6 ToSTNeTへの発注後の証券会社側による取引中止にかかわるシーケンス

本章では、異常時におけるシーケンス例について示す。 なお、エラー通知等に設定される理由コードについては、「CONNEQTOR　FIX接続仕様書（データフォーマット編）」の「付録2 理由コード一覧」を参照。

CONNEQTOR送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）により参加者システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.1に示す。

1. 参加者システムはCONNEQTORからの電文をFIXプロトコル不正と認識した場合、参加者システムへRejectを送信する。
2. 参加者は東証と連絡を取り、障害原因の調査を行う必要がある。

※ Rejectの送信条件は、「4.7 プロトコルエラー(セションReject)」参照。
※ CONNEQTORから不正電文が送信されることは通常あり得ない。 回復時の処置：障害原因を取り除いた後、FIXセション確立シーケンスを実行する。

図 6.3.1　【電文不正時のシーケンス】
CONNEQTORからの入力電文（上り）を参加者システムにて論理矛盾エラー（重度エラー）と認識した場合のシーケンス

参加者システム送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）によりCONNEQTORで正常電文と認識されない場合のシーケンスを以下の図 6.3.2に示す。

1. CONNEQTOR は参加者システムからの電文をFIXプロトコル不正と認識した場合、参加者システムにRejectを送信する。
2. 再度不正電文を受信した場合は、その都度参加者システムにRejectを送信する。
3. 不正電文を連続して一定回数受信した場合、CONNEQTORは参加者システムにLogoutを送信し、Logout(応答)を待たずにコネクションを切断する。(連続回数については表 4.8.1 使用するプロトコル制御パラメタ参照)

※1 LogoutのTextタグの先頭5バイトに、解放要因となった理由が設定される。
　回復時の処置：障害原因を取り除いた後、FIX セション確立シーケンスを実行する。

図 6.3.2　【電文不正時のシーケンス】
参加者システムからの通知電文（下り）をCONNEQTORにて論理矛盾エラー（重度エラー）と認識した場合のシーケンス

データ不正とは、電文に設定されている業務内容や指示内容に、データ仕様上規定されていないデータが設定されている状態をいう。

　CONNEQTOR送信電文が、データ不正（軽度エラー）により参加者システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.3　【電文不正時のシーケンス】に示す。

1. 参加者システムにて電文の内容に不正を検出した場合、CONNEQTORにLogout（要求）を送信しFIXセションの解放を行い、さらに東証と連絡を取り、障害原因の調査を行う必要がある。
2. 障害原因を取り除いたのち、CONNEQTORよりLogon（要求）を参加者システムに送信し、FIXセションの確立を行う。
3. FIXセション確立後、CONNEQTORは、未送信であると認識している電文から出力を再開する。

※1 LogoutのTextタグの先頭5バイトに、取引の中断を示す値（‘０００００’以外）を設定する。

図 6.3.3　【電文不正時のシーケンス】
CONNEQTORにて通知系電文のデータ不正（軽度エラー）を検出した場合のシーケンス

CONNEQTORにて電文の内容に不正を検出した場合のシーケンスを以下の図 6.3.4に示す。

1. 参加者システムにてデータ不正（軽度エラー）を検出した場合、CONNEQTORへエラー内容をBusiness Message Reject (エラー）にセットし送信する。
2. 当該入力電文は無効となるが、FIXセションの解放は行わず、次の入力電文の処理は続行される。

図 6.3.4　【電文不正時のシーケンス】
CONNEQTORにおいて参加者システムからの電文がデータ不正と認識された場合のシーケンス

　参加者システムとToSTNeTとの接続については本接続仕様書の範囲外であるが、ToSTNeTからRejectまたはBusiness Message Rejectが返却された場合、参加者システムからToSTNeTに対して正しい電文で再送信する必要がある。ToSTNeTからのRejectまたはBusiness Message RejectのメッセージをCONNEQTORに返却する必要はない。

参加者システムがアプリケーションレベルの再送メッセージ（PossResend＝Yのメッセージ）を送信した場合、当該再送メッセージが受信済のメッセージと同一か否かの判定方法及び受信済メッセージであった場合の扱いを説明する。

再送メッセージが下記に該当する場合、当該再送メッセージは受信済と判断し破棄される。

• Execuion Report
  • MsgType(Tag=35)が同一で且つExecID(Tag=17) に受信済の値が設定されている。

一日の運用を以下の図7.1.1に示す。

一日の初回の Logon 時にシーケンス番号をリセットする。

図7.1.1　【一日の運用】

取引所及び取引参加者は、本書に定める仕様に準拠した通信が行えることを事前に確認する。そのため、FIXクライアントの新設/変更を実施する際は、両者で新設/変更の作業日やテスト日程等を合意し、スケジュールに沿って遅滞なく対応する。

本接続仕様書のご利用に当たっては、必ず以下の項目をお読みいただき、以下の使用許諾条件に同意いただくことを条件とします。

• （著作権等）
  • 本接続仕様書の各種情報等（以下「技術情報等」という。）に関する著作権等の一切の権利は、東証に帰属します。

• （禁止事項）
  • 有償、無償を問わず第三者に対して、使用許諾、譲渡、転売、貸与又は媒体の如何にかかわらず本接続仕様書及び技術情報等の外部への提供若しくは印刷物の出版を禁じます。

• （免責）
  • 東証は、本接続仕様書の誤謬、省略若しくは欠落等に起因する損害等、直接又は間接を問わず技術情報等を利用したこと、又は利用できなかったことにより利用者及び利用者の顧客等に生じた一切の損害について、損害賠償責任を負わないものとします。
  • 東証は、東証の故意又は重過失による場合を除き、本サービスの利用に起因しその他本書に関連して利用者及び利用者の顧客等に生じた損害につき、一切の法的責任を負いません。
  • 東証は、東証の予見の有無を問わず特別の事情から利用者及び利用者の顧客等に生じた損害、及び利用者及び利用者の顧客等に生じた逸失利益については、賠償責任を負いません。
  • 利用者等の損害賠償請求権は、損害発生の日から12ヶ月以内に行使しなければ消滅するものとします。

• （違反）
  • 利用者が使用許諾条件のいずれかの項目に違反した場合、利用者は東証の指示に異議なく従うものとします。

• （その他）
  • 東証は、本接続仕様書に記載した内容について、明示又は黙示の如何を問わずその無誤謬性を一切保証しません。

発行：株式会社 東京証券取引所
　　　東京都中央区日本橋兜町2番1号 〒103-8220
　　　MAIL:ask-conneqtor@jpx.co.jp
　　　セション接続のための連絡先：050-3377-7751