====== CONNEQTOR FIX接続仕様書（投資家/接続編） ====== 1.0版\\ 2023年6月 作成\\ \\ \\ \\ ===== 1.はじめに ===== 本仕様書は、CONNEQTORと投資家システム間のFIX（Financial Information eXchange）プロトコルに基づく接続仕様を記述したものである。 なお、システム間の全ての電文及び通信手順は、FIXプロトコルV4.2(Errata)に準拠するものとする。 \\ \\ \\ ===== 2.概要 ===== ==== 2.1　システム概要 ==== 機関投資家（投資家システム）は本FIX接続仕様書に準じてCONNEQTORにRFQを送信する。機関投資家は送信したRFQの情報をもとに、マーケットメイカーからCONNEQTORを通じて気配提示を受け、CONNEQTORはマッチした注文等の情報を取引参加者に連携する。 投資家システムはCONNEQTORと通信を行うためのFIXクライアントを設置し、arrownet(注1)を経由してCONNEQTORに接続する。 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接続仕様書に準拠したFIX業務メッセージの分解、チェック、組立て等を実装するアプリケーションである。 * （注4）1FIXセションは、CONNEQTORで対応しているシステム区分単位に括り付けとし、1FIXセションは1システム区分にかかる取引区分の業務のみを行う。 === 2.1.1　本番面 === 本番面は本システムのサービスを利用することを目的とした環境である。利用可能時間は取引日の8:00（JST）から18:30（JST）である。\\ 投資家システムは、取引日の利用可能時間内に、CONNEQTORに対してログオンを行う。\\ 図 2.1.1に示すCONNEQTOR（本番面）、プライマリセンタのNW機器、arrownetの広域被災時においては、同環境でのサービス再開を目指し、当該機器が復旧するまで本サービスを停止する。また、耐障害性を考慮し投資家システムのFIXクライアントは同一IPアドレスまたは異なるIPアドレスで冗長化することが可能である。\\ 本番面の全体構成イメージを図 2.1.1に示す。\\ 投資家システムからCONNEQTORへはarrownetを経由して接続する。\\ 取引日の利用可能時間内に、投資家システムはCONNEQTORからログアウトを行う。\\ \\ {{ :spec:jp:isv:図_2.1.1_全体構成イメージ（本番面）.svg?800 |図 2.1.1 全体構成イメージ（本番面）}} ;#; **図 2.1.1 全体構成イメージ（本番面）** ;#; \\ === 2.1.2　ステージング面 === ステージング面は、テストを行うことを目的とした環境であり、テスト実施日は基本的に本番面の取引日と同日である。利用可能時間はテスト実施日の8:00（JST）から21:00（JST）である。\\ テストを実施する場合、投資家システムはテスト実施日の利用可能時間内にCONNEQTORに対してログインを試みる。\\ テストの途中にFIXセションが切断された場合は、再ログインを行うことも可能である。 FIXのログインを行っていない証券会社を選択した場合、証券会社と通信できないため、RFQ送信以降のテストを実施することができない。このため、取引所は擬似参加者を用意し、投資家システムは擬似参加者を選択してテストすることを可能とする。\\ また、図 2.1.2に示すCONNEQTOR（ステージング面）、プライマリセンタのNW機器、arrownetの広域被災時は、同環境でのサービス再開を目指し、当該機器が復旧するまでテスト実施対象外とする。\\ ステージング面の全体構成イメージは図 2.1.1と同様であり、投資家システムからCONNEQTORへはarrownetを経由して接続する。 \\ \\ ==== 2.2 適用範囲 ==== 本仕様書は、CONNEQTORにおけるシステム間接続方式において、CONNEQTORと投資家システム間のFIXプロトコルV4.2(Errata)に準拠する接続仕様について記述したものである。システム間通信において、本仕様書記載以外の電文は認めないものとする。 \\ \\ \\ ===== 3. TCPコネクション ===== ==== 3.1 投資家接続構成 ==== 本章では、投資家システムとCONNEQTORとの接続構成と接続条件について示す。 === 3.1.1 接続構成 === 投資家システムとCONNEQTORとの接続形態を以下に示す。伝送制御手順としてはTCP/IPを使用し、arrownet経由で接続する。 {{ :spec:jp:isv:図 3.1-1 接続構成.svg?800 |図 3.1-1 接続構成}} ;#; ** 図 3.1-1 接続構成 ** ;#; === 3.1.2 接続条件 === 投資家システムは、CONNEQTORへのログイン電文を送信してからCONNEQTORへのログアウト電文を送信するまではCONNEQTORと接続しなければならない。 \\ ==== 3.2 TCP/IPコネクション ==== 投資家システムのFIXサービスとCONNEQTOR間はTCP/IPにより通信する。 === 3.2.1 バージョン === 基本的に、下表に記載のRFCに準拠しなければならない。 \\ ;#; ** 表 3.2-1 TCPバージョン ** ;#; ^ プロトコル ^略称 ^RFC ^タイトル ^ |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アドレス、ポート番号 === CONNEQTORと投資家システムは取引所と投資家システムの間で決められたIPアドレス、ポート番号でTCPコネクションを確立して業務を行う。\\ 投資家システムが利用するIPアドレス、ポート番号については利用申請時に投資家側から指定する。FIXクライアントを異なるIPアドレスで冗長化する場合は、現用系・待機系双方のIPアドレス、ポート番号を指定する。CONNEQTORのIPアドレス、ポート番号については利用申請時に取引所側で指定したものを使用する。IPアドレスおよびポート番号について取引所より割り当てられる箇所については下図を参照。 {{ :spec:jp:isv:図 3.2.2-1 IPアドレスとポート番号.svg?800 |図 3.2.2-1 IPアドレスとポート番号 (arrownet経由で接続する場合)}} ;#; **図 3.2.2-1 IPアドレスとポート番号 ** ;#; \\ \\ === 3.2.3 TCPコネクションの接続条件 === == (1)TCPコネクションの接続・切断方向 == TCPコネクションの接続条件を以下に示す。 ^コネクション接続方向|投資家システムから接続する。| ^コネクション切断方向|投資家システムから切断する。| == (2) TCPオプション（TCP_NODELAYについて） == CONNEQTOR側は、電文送信時にTCP_NODELAYのパラメータを採用する。 投資家システム側は、当該パラメータがCONNEQTORへの送信効率を向上させるものと判断された場合、CONNEQTORとのTCPコネクション接続にて設定を有効にすることが可能である。\\ *TCP_NODELAYとは、回線を効率よく使用するためにまとめてデータを送る目的で適宜待ち合わせて送信するかどうかを設定するものである。 == (3) TCP通信に係る禁止事項 == 投資家システムは、CONNEQTORに過度な負荷をかける通信(TCPコネクション確立中に再度確立を要求するパケットを送信する、通信シーケンスの異常を検知した際の復旧を求めるパケットを極めて短い間隔で連続的に送信する等)を行ってはならない。 \\ 当該禁止事項に違反し、不正な通信を検出(取引所からの連絡を含む)した場合には、速やかにコネクションを遮断する等の対策を講じなければならない。 \\ \\ \\ ===== 4. FIXセション接続プロトコル ===== ==== 4.1 FIXセションの概要 ==== 　FIXセションとは、2つのシステム間における双方向の連続的なシーケンス番号を持つ順序だったメッセージの流れと定義される。\\ 　一連の会話の中では、送受信されるすべてのメッセージに一意なシーケンス番号が振られ、メッセージの順序性及び欠落のないメッセージ転送が保証される。シーケンス番号は、メッセージの転送方向毎に送信シーケンス番号、受信シーケンス番号が別々に管理され、セション開始時にそれぞれ1から始まり、1ずつ増加していく。\\ 　FIXセションはシーケンス番号が1であるLogonメッセージの交換により開始される。通信を行う２者間の合意に基づき、シーケンス番号がお互いにクリアされた時点で終了する。また、通信を行う2者は、Logon/Logoutメッセージの交換により、FIXセションの確立、解放を繰り返すことで、FIXセションを維持したまま何度でも会話の中断、再開を行うことができる。 {{ :spec:jp:fig4-1-1.svg?800x160 |図 4.1.1　FIXセションの開始と終了}} ;#; ** 図 4.1.1　FIXセションの開始と終了 ** ;#; *注）本書では通信リンク（TCPコネクション）の接続／切断をともなうメッセージ交換の再開／中断のことをFIXセションの確立／解放と呼ぶ。FIXセションの開始／終了とは別の意味であることに注意されたい。 \\ ==== 4.2 TCPコネクションとFIXセションの関係 ==== TCPコネクションとFIXセションは、ある時点を見れば1対1に対応する。1つのTCPコネクションに複数のFIXセションのメッセージを混在させて送受信することはできないし、1つのFIXセションのメッセージを同時に複数のTCPコネクションに分割して送受信することもできない。また、TCPコネクションを通してやりとりされるデータは、FIXプロトコル仕様 (Ver4.2(Errata))で規定されたメッセージそのものであり、特別なヘッダ/トレーラの付加は行わない。 FIXセションは(時間的に)複数のTCPコネクションをまたがって存続する。単一のFIXセションの中で、複数回のLogon/Logoutが可能である。 {{ :spec:jp:isv:図 4.2.1 TCPコネクションとFIXセションの関係.svg?800 |図 4.2.1 TCPコネクションとFIXセションの関係}} ;#; **図 4.2.1 TCPコネクションとFIXセションの関係** ;#; \\ \\ *Logon要求 TCPコネクションの接続時に、接続の認証、接続条件の取り決め、及びメッセージの同期合わせを行うための手続き。 また、FIXセションが未開始の状態では、セション開始手続きの意味を持つ。(この時、LogonﾒｯｾｰｼﾞのMsgSeqNumは1である。) *Logout要求 TCPコネクションの切断に先立ち、相手システムとの意識合わせを行う手続き。この手続きなしでの切断は、異常な事態である。 LogoutはFIXセション終了を意味しないことに注意。 *FIXセションの終結 FIXセション終結のタイミングは、FIXプロトコルによって接続される２つのシステムの間の合意に基づく。例えば、１日の取り引きの終わりの決められた時刻にセションをリセットするなどの手段がある。 なお、FIXセションの存続とは、実質的には、次の状態を意味する。\\ 　　A) 送受信シーケンス番号の保持によって、セションを通して転送されるメッセージの順序性が維持されている状態。\\ 　　B) メッセージの再送に備え、送信メッセージのログが保持されている状態。\\ ==== 4.3 FIXセションの確立 ==== 通信を行なう2者間でLogonメッセージを交換することにより、FIXセションの確立を行うことができる。\\ Logonメッセージの送信者（イニシエータ）はTCPコネクションを接続後、Logonメッセージを送信する。Logonメッセージの受信者（アクセプタ）は受信したLogonメッセージの認証を行い相手が正しい接続先であると認めた場合には、Logon応答メッセージをイニシエータに送信する。認証を拒否する場合は、TCPコネクションを切断する。FIXセションの確立以降、相手システムとの間でメッセージの送受信が可能となる。 {{ :spec:jp:fig4-3-1.svg?800 |図 4.3.1　セションの確立}} ;#; ** 図 4.3.1　セションの確立 ** ;#; \\ \\ なお、CONNEQTORでは、投資家システム側がイニシエータ、東証側がアクセプタとなる。 ==== 4.4 FIXセションの解放 ==== Logoutメッセージを交換することにより、FIXセションを解放することができる。\\ Logoutメッセージの送信者は、欠落メッセージの検出シーケンス（下図の網かけ部分）を実行することにより、送信した全てのメッセージが相手システムに到達したことを確認する。この結果、欠落メッセージがないことを確認して、Logoutメッセージの送信を行う。\\ FIXセションの解放以降、相手システムとの間でメッセージの送受信はできない。 {{ :spec:jp:fig4-4-1.svg?800 |図 4.4.1 セションの解放}} ;#; ** 図 4.4.1 セションの解放 ** ;#; \\ \\ なお、CONNEQTORでは、投資家システム側がセション解放の開始者となる。 \\ ==== 4.5 ハートビート ==== 　FIXプロトコルでは、接続された２つのシステムの間で、互いにメッセージの到着間隔を監視することにより、相手システムまたはネットワークの状態をモニタしている。LogonメッセージのHeartBtInt(Tag=108)で指定された時間＋ハートビート受信余裕時間（回線等の影響でメッセージが遅延することを考慮した時間）以上経過しても相手システムからメッセージが到着しない場合には、Test Requestメッセージを送信して、相手システムのHeartBeatメッセージを誘発する。\\ 　Test Requestメッセージを送信したが、一定時間内に応答のHeartBeatメッセージを受信しない場合は、相手システムまたはネットワークに何らかの異常が発生したものと判断してTCPコネクションを切断する。逆に、LogonメッセージのHeartBtInt(Tag=108)に指定した時間が経過しても、アプリケーションからメッセージの送信要求が無い場合、HeartBeatメッセージを生成し、自システムが生存していることを相手に通知する。\\ また、HeartBeatメッセージは、欠落メッセージの早期検出のためにも用いられる。\\ {{ :spec:jp:fig4-5-1.svg?600 |図 4.5.1 ハートビート}} ハートビート受信監視タイムアウトをトリガに Test Request を送信して投資家システムのHeartBeatを誘発する。しかし、何も送信されてこないため、再度受信タイムアウトが発生し、TCP コネクションを切断する。\\ ※図中に示すハートビート受信監視のタイムアウトまでの時間は、ハートビート受信監視タイマとハートビート受信余裕タイマの合計時間である。 ;#; ** 図 4.5.1 ハートビート ** ;#; \\ ==== 4.6 GapFill ==== 受信するメッセージのMsgSeqNum(Tag=34)を検証することで、欠落メッセージを検出することができる。欠落メッセージを検出した場合は、Resend Request（再送要求）メッセージを送信して、相手システムに再送処理を要求する。再送要求を受信した場合は、要求されたシーケンス番号を持つメッセージの再送処理を行う。 セションを通して一意に管理されるシーケンス番号は以下の２種類である。 *送信シーケンス番号 ：メッセージ送信時、MsgSeqNum(Tag=34)に設定する番号。メッセージ送信後はカウントアップし、次に送信するメッセージに設定する番号とする。 *受信シーケンス番号 ：次に受信するメッセージのMsgSeqNum(Tag=34)に設定されていることを期待する番号。 メッセージ受信時、管理されている受信シーケンス番号と受信したメッセージのMsgSeqNum(Tag=34)の関係により、以下の処理を行う。 ;#; ** 表 4.6.1　メッセージ受信時の処理 ** ;#; ^受信ｼｰｹﾝｽ番号(rSeq) VS MsgSeqNum^処理概要^ |rSeq = MsgSeqNum|正常シーケンスで受信したメッセージ。 \\ 正常に処理を継続する。| |rSeq < MsgSeqNum|欠落メッセージ検出。 \\ ResendRequest(再送信要求)メッセージを送信して、GapFill処理を行う。| |rSeq > MsgSeqNum|重大な異常が発生。 \\ LogoutメッセージのText(Tag=58)に、セションを解放する理由を示す理由文字列を付加して送信し、TCPコネクションの切断を行なう。 \\ （ただし、Logoutメッセージは送信されない場合もある）| \\ PossDupFlag(Tag=43)がYに設定されているメッセージは、本表の適用対象外となる。 ResendRequest（再送要求）メッセージを受信した場合、要求されたシーケンス番号を持つメッセージの再送処理を行う。再送メッセージはPossDupFlag(Tag=43)をYに設定して送信する。なお、再送対象が管理メッセージの場合、再送対象の管理メッセージの代わりに、SequenceResetメッセージを送信する。管理メッセージの再送について、以下の表 4.6.2　制御メッセージの再送可否表 4.6.2に記述する。 \\ ;#; ** 表 4.6.2　制御メッセージの再送可否 ** ;#; ^管理メッセージ^再送の可否^処理概要^ |HeartBeat|×|再送対象でないため、SequenceResetメッセージを送信する。| |Logon|×|再送対象でないため、SequenceResetメッセージを送信する。| |TestRequest|×|再送対象でないため、SequenceResetメッセージを送信する。| |ResendRequest|×|再送対象でないため、SequenceResetメッセージを送信する。| |Reject|○|再送対象である。PossDupFlagをYに設定して再送信する。| |SequenceReset|×|再送対象でないため、SequenceResetメッセージを送信する。| |Logout|×|再送対象でないため、SequenceResetメッセージを送信する。| *補足）通常、管理メッセージの代行として送信するメッセージは、Sequence Reset-GapFill(GapFillFlag(123)=Y)を使用するが、再送要求で指定されたメッセージを送信できない場合（送信履歴にない等）は、Sequence Reset-Reset(GapFillFlag(123)=N)を使用する。SequenceReset-Reset使用時は、メッセージが失われた可能性がある。 {{ :spec:jp:fig4-6-1.svg?600 |図 4.6.1 GapFILLシーケンス}} 本シーケンスは、MsgSeqNum=13 のAplMessageを受信した時にGapを検出し、GapFill処理を行うシーケンスである。AplMessageとは、アプリケーションメッセージを指す。全てのアプリケーションメッセージは再送の対象である。\\ ※1 このように Gap 検出で再送要求を出す場合、ResendRequest(再送要求)メッセージで要求する再送範囲は、正常に受信したメッセージの次のシーケンス番号から0番（無限大の意）までとする。0番までとすることは、再送要求を受信するシステムに対して、最後に送信した電文までが再送対象であることを示している。\\ ※2 MsgSeqNum=12のHeartBeatメッセージは、再送対象外の管理メッセージであるため、SequenceReset-GapFill メッセージを代わりに送信する。\\ ;#; ** 図 4.6.1 GapFILLシーケンス ** ;#; \\ ==== 4.7 プロトコルエラー(セションReject) ==== FIXプロトコル上、許されないメッセージを受信した場合、受信したシステムは、受信したメッセージを破棄する。ただし、プロトコルエラーの種類によっては、送信元システムに対してRejectまたはExecution Reportを送信する。 RejectまたはExecution Reportを送信する条件は、以下の表に従う。 ;#; ** 表 4.7.1　不正なメッセージを受信した場合の処理 ** ;#; |< 100% 5% 20% 30% 30% 15% >| ^ 項番 ^ 条件 ^ 例 ^ 動作 ^ 備考 ^ |FIXセション確立前||||| | 1 |不正メッセージを受信。|Logon認証に失敗。 \\ Logonの受け側(Acceptor)がLogon以外のメッセージを受信。 \\ Logonの送り側(Initiator)が応答のLogonを受信する前に他のメッセージを受信。|受け側(Server)はコネクションを切断する。| | |FIXセション確立中||||| | 2 |重大なエラーがあるメッセージを受信。その後のメッセージ交換が継続できない可能性がある。|MsgSeqNum不当（タグなし、値が数字以外の文字）。 \\ MsgSeqNumが期待している値よりも小さい（PossDupFlag=N）。 |受信プログラムは、エラー理由を設定したLogoutを送信し、応答のLogoutを待たずにコネクションを切断する。| | |:::|:::|標準ヘッダ部に同一の標準ヘッダ部タグが2回以上存在する。 \\ ボディ部に同一のボディ部タグが2回以上存在する。(繰り返しタグを除く) \\ 必須タグの欠落（FIXプロトコルとして必須のタグ）。 \\ 条件付必須タグの欠落（FIXプロトコルとして必須のタグ）。 \\ タグに値が設定されていない。 \\ 値のデータフォーマットが不正。 \\ 無効なMsgType（タグなし、サポート対象外のMsgType）。|受信プログラムは、メッセージが処理できなかったことを知らせるため、Rejectを送信する。また、Reject電文を送信する事象が連続する場合(連続回数については表4.8.1参照)、エラー理由を設定したLogoutを送信し、応答のLogoutを待たずにコネクションを切断する。 | | | 3 |アプリケーションレベルにおいて処理が行えないメッセージを受信。次回メッセージは正しく処理できる可能性がある。 |必須タグの欠落（FIXプロトコルでは任意のタグだが、CONNEQTORとして必須のタグ）。 \\ 条件付必須タグの欠落（FIXプロトコルでは任意のタグだが、CONNEQTORとして必須のタグ）。 \\ タグの値が不正。（データフォーマット不正を除く）|受信プログラムは、メッセージが処理できなかったことを知らせるため、Execution Reportに理由コードを添えて送信する。| | | 4 |メッセージとして正しく認識できない場合。|先頭のタグがBeginStringではない。 \\ 2番目のタグがBodyLengthではない。 \\ 3番目のタグがMsgTypeではない。 \\ 最後のタグがCheckSumではない。 \\ BeginString、 BodyLength、CheckSumの値が不正。|受信プログラムは、メッセージ通番を更新せず、メッセージを破棄する。|次の正常なメッセージを受信し、GapFillを検知し、破棄したメッセージの再送を要求する。| ==== 4.8 プロトコル制御パラメタ ==== CONNEQTORでは、無限ループの回避や応答監視用など、FIXプロトコルを正常に制御するために、以下のプロトコル制御パラメタを使用する。 ;#; ** 表 4.8.1　使用するプロトコル制御パラメタ ** ;#; |< 100% 21% 60% 19% >| ^ プロトコルパラメタ ^ 説明 ^ 設定値 ^ |ハートビート送信タイマ|生存検証用。本タイマで設定した時間が経過しても、何もメッセージを送信しない場合、CONNEQTORはHeartBeatを生成して送信する。本タイマは、LogonのHeartBtIntフィールドに設定されて投資家システムに通知される。|60秒（固定値）| |ハートビート受信監視タイマ|生存検証用。本タイマとハートビート受信余裕タイマの合計時間が経過しても、何もメッセージを受信しない場合は、TestRequestを送信して投資家システムの生存を確認する。それでもなお、本タイマとハートビート受信余裕タイマの合計時間が経過した場合には、TCPコネクションを切断する。本タイマは、投資家システムから受信したLogonのHeartBtIntフィールドに設定されている値を使用する。|投資家システムに依存。（0秒の設定は不可）| |ハートビート受信余裕タイマ|生存検証用。ハートビート受信監視タイマ使用時に、ハートビート受信監視タイマと共に使用する。本タイマは、回線等の要因でメッセージが遅延することを考慮している。|30秒（固定値）| |連続リジェクト回数|CONNEQTORが不正な電文を受信しReject電文を送信する事象が、連続して発生する回数。この回数を超過した場合、CONNEQTORはエラー理由を設定したLogoutを送信し、応答を待たずにコネクションを切断する。|10回（固定値）| \\ \\ \\ ===== 5. メッセージ一覧 ===== ==== 5.1 メッセージ ==== CONNEQTORで使用するメッセージを以下に示す。 ;#; ** 表 5.1.1 メッセージ一覧 ** ;#; ^:::^^^^ FIX ^^ ^ 大カテゴリ ^ 小カテゴリ ^ メッセージ名称 ^上り／下り（※）^ FIXメッセージ ^MsgType^ |管理メッセージ| - |Logon|上り/下り|Logon|A| |:::|:::|Logout|上り/下り|Logout|5| |:::|:::|Heart Beat|上り/下り|Heart Beat|0| |:::|:::|Test Request|上り/下り|Test Request|1| |:::|:::|Resend Request|上り/下り|Resend Request|2| |:::|:::|Reject|上り/下り|Reject|3| |:::|:::|Sequence Reset|上り/下り|Sequence Reset|4| |アプリケーションメッセージ|RFQ送信電文|RFQ送信|上り|New Order - Single|D| |:::|受付系通知電文|RFQ受付/拒否通知|下り|Execution Report|8| |:::|:::|RFQキャンセル通知|下り|Execution Report|8| |:::|約定系通知電文|約定通知|下り|Execution Report|8| |:::|:::|Done for day通知|下り|Execution Report|8| ※）　上り：投資家システム ⇒ CONNEQTOR\\ 　　　下り：CONNEQTOR ⇒ 投資家システム\\ 　　　のメッセージをいう\\ \\ \\ \\ ===== 6. メッセージシーケンス ===== ==== 6.1 FIXプロトコルの制御シーケンス ==== 本章では、FIXプロトコルの制御シーケンス例について示す。 === 6.1.1 シーケンス概要 === FIXプロトコルの通信シーケンスには、大きく分けてLogonをやり取りする確立シーケンス、アプリケーションメッセージをやり取りするメッセージ送受信、Logoutをやり取りする解放シーケンスがある。以下にFIXプロトコルの通信シーケンスの概要を示す。 {{ :spec:jp:isv:図 6.1.1　シーケンス概要.svg?800 |図 6.1.1　シーケンス概要}} ;#; 補足)一度解放した後でも、シーケンス番号は継続していることに注意。 ;#; ;#; ** 図 6.1.1　シーケンス概要 ** ;#; \\ === 6.1.2 確立／解放 === == (1) 能動型確立（認証ＯＫ） == 能動型確立では、投資家システムからCONNEQTORへTCPコネクション接続とLogon要求を行う。投資家システムから受信したLogon要求の認証に問題がない場合には、CONNEQTORは投資家システムに対してLogon応答を送信し、この時点で確立が完了する。 (注意) Logon要求/応答のMsgSeqNumは必ずしも1とは限らない。 {{ :spec:jp:isv:図 6.1.2　確立（認証ＯＫ）.svg?800 |図 6.1.2　確立（認証ＯＫ）}} ;#; ** 図 6.1.2　確立（認証ＯＫ） ** ;#; \\ == (2) 能動型確立（認証ＮＧ） == CONNEQTORが投資家システムから受信したLogon要求の認証に問題があった場合、不当な接続相手と判断し、TCPコネクションの切断により接続を拒否する。 {{ :spec:jp:isv:図 6.1.3　確立（認証ＮＧ）.svg?800 |図 6.1.3　確立（認証ＮＧ）}} ;#; ** 図 6.1.3　確立（認証ＮＧ） ** ;#; \\ == (3) 能動型解放 == 投資家システムにおける能動型解放は、Logout要求に対してCONNEQTORからのLogout応答を受信し、この時点で解放が完了する。TCPコネクションの切断は投資家システムが行う。 {{ :spec:jp:isv:図 6.1.4　能動型解放.svg?800 |図 6.1.4　能動型解放}} ;#; ** 図 6.1.4　能動型解放 ** ;#; 能動型解放中に、CONNEQTORから送信されたLogout応答が伝送路上の消失等により投資家システムに届かなかった場合、CONNEQTORはハートビート受信監視で異常を検出し、その時点でTCPコネクションを切断する。シーケンスについては、「6.1.3 (2)ハートビート受信監視タイムアウト」を参照。 また、「表 4.7.1　不正なメッセージを受信した場合の処理」の項番2に該当する不正電文受信、Reject電文を受信、CONNEQTOR側のシステム異常が発生した場合にも能動型解放を行う。シーケンスについては、「6.3異常時のシーケンス」を参照。 == (4) 受動型解放 == 「表 4.7.1　不正なメッセージを受信した場合の処理」の項番2に該当する不正電文受信、Reject電文を受信、CONNEQTOR側のシステム異常が発生した場合に受動型解放を行う。シーケンスについては、「6.3異常時のシーケンス」を参照。 === 6.1.3 ハートビート === == (1) ハートビート送信 == CONNEQTORがHeartBeatを使用する時のシーケンスである。Logon応答のHeartBtIntで指定した時間が経過しても、何らメッセージを送信しない場合に、HeartBeatを送信する。 {{ :spec:jp:isv:図 6.1.5　ハートビート送信.svg?800 |図 6.1.5　ハートビート送信}} ;#; ** 図 6.1.5　ハートビート送信 ** ;#; \\ == (2) ハートビート受信監視タイムアウト == 投資家システムがHeartBeatを使用する場合、CONNEQTORは、投資家システムから受信するメッセージの間隔を監視する。監視時間が経過しても何らメッセージが送信されてこない場合、CONNEQTORはTestRequestを送信して投資家システムの生存を確認する。再度、何らかの原因で投資家システムから応答がない場合、CONNEQTORは回線、または投資家システムに異常が発生したと判断してTCPコネクションを切断する。 {{ :spec:jp:isv:図 6.1.6　受信ハートビート監視タイムアウト.svg?800 |図 6.1.6　受信ハートビート監視タイムアウト}} ;#; ** 図 6.1.6　受信ハートビート監視タイムアウト **\\ 補足）投資家システムの生存が確認できないため、TCPコネクションを切断する。 \\ ;#; === 6.1.4 GapFill（再同期処理） === == (1) 投資家システムからResendRequest（再送要求）受信 == 投資家システムからのResendRequestを受信した場合、ResendRequestの要求内容に従って再送処理を行う。Rejectを除く管理メッセージは再送対象外であるため、再送範囲にこれらのメッセージが含まれていた場合には、SequenceReset-GapFillの送信で代替する。 {{ :spec:jp:isv:図 6.1.7　投資家システムからResendRequest（再送要求）受信.svg?800 |図 6.1.7　参加者システムからResendRequest（再送要求）受信}} ;#; ** 図 6.1.7　投資家システムからResendRequest（再送要求）受信 ** ;#; \\ == (2) AplMessages受信でGap検出 == 投資家システムから受信したメッセージにシーケンスGapを検出した場合、即時にResendRequestを送信し、投資家システムに欠落したメッセージの再送を要求する。 下図はCONNEQTORが投資家システムから受信したApplication MessagesにシーケンスGapを検出した時のシーケンスである。 (注意) CONNEQTORは、欠落メッセージの先頭以降の全メッセージをResendRequestの再送要求範囲とする。(EndSeqNo=0固定) {{ :spec:jp:isv:図 6.1.8　AplMessages受信でGap検出.svg?800 |図 6.1.8　AplMessages受信でGap検出}} ;#; ** 図 6.1.8　AplMessages受信でGap検出 ** ;#; \\ == (3) Logon要求受信でGap検出 == CONNEQTORがLogon要求受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、先ず投資家システムにLogon応答を送信してから、ResendRequestを送信してメッセージの再送を要求する。例えば、システムダウンで投資家システムからのメッセージをロストした場合に、このシーケンスが実行される。 {{ :spec:jp:isv:図 6.1.9　Logon要求受信でGap検出.svg?800 |図 6.1.9　Logon要求受信でGap検出}} ;#; ** 図 6.1.9　Logon要求受信でGap検出 ** ;#; \\ == (4) Logout要求受信でGap検出 == Logout要求受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。その後、再送を要求したメッセージが全て届いたらLogout応答を送信する。 {{ :spec:jp:isv:図 6.1.10　Logout要求受信でGap検出.svg?800 |図 6.1.10　Logout要求受信でGap検出}} ;#; ** 図 6.1.10　Logout要求受信でGap検出 ** ;#; \\ == (5) HeartBeat受信でGap検出 == HeartBeat受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。 {{ :spec:jp:isv:図 6.1.11　HeartBeat受信でGap検出.svg?800 |図 6.1.11　HeartBeat受信でGap検出}} ;#; ** 図 6.1.11　HeartBeat受信でGap検出 ** ;#; \\ == (6) TestRequest受信でGap検出 == TestRequest受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。 (注意)Gap検出時にはTestRequestの応答としてのHeartBeat送信は行わない。 {{ :spec:jp:isv:図 6.1.12　TestRequest受信でGap検出.svg?800 |図 6.1.12　TestRequest受信でGap検出}} ;#; ** 図 6.1.12　TestRequest受信でGap検出 ** ;#; \\ == (7) ResendRequest受信でGap検出 == ResendRequest受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、投資家システムからの再送要求を処理した後に、ResendRequestを送信してメッセージの再送を要求する。 {{ :spec:jp:isv:図 6.1.13　ResendRequest受信でGap検出.svg?800 |図 6.1.13　esendRequest受信でGap検出}} ;#; ** 図 6.1.13　ResendRequest受信でGap検出 ** ;#; \\ == (8) SequenceReset-GapFill受信でGap検出 == SequenceReset-GapFill受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、まだGapFill処理中であったとしても、再度、投資家システムにResendRequestを送信してメッセージの再送を要求する。 {{ :spec:jp:isv:図 6.1.14　SequenceReset-GapFill受信でGap検出.svg?800 |図 6.1.14　SequenceReset-GapFill受信でGap検出}} ;#; ** 図 6.1.14　SequenceReset-GapFill受信でGap検出 ** ;#; \\ == (9) Reject受信でGap検出 == Reject受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。 {{ :spec:jp:isv:図 6.1.15　Reject受信でGap検出.svg?800 |図 6.1.15　Reject受信でGap検出}} ;#; ** 図 6.1.15　Reject受信でGap検出 **\\ ;#; 補足）Rejectは再送対象の管理メッセージである。 \\ === 6.1.5 すれ違いシーケンス === == (1) ResendRequest（再送要求）とAplMessagesのすれ違い == シーケンスGapを検出してResendRequestを送信した後で、すれ違いにApplication Messageを受信した場合、受信したApplication MessageにもシーケンスGapを検出して、再度ResendRequestを送信する。再送メッセージが再び消失することも考えられるため、CONNEQTORは、シーケンスGapを検出する都度、必ずResendRequestの送信を行う。 {{ :spec:jp:isv:図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い.svg?800 |図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い}} ;#; ** 図 6.1.16　ResendRequest（再送要求）とAplMessagesのすれ違い ** ;#; \\ ==== 6.2 アプリケーションメッセージシーケンス ==== 本章では、投資家システムとCONNEQTOR間におけるアプリケーションメッセージのシーケンス例について示す。 なお、エラー通知等に設定される理由コードについては、「CONNEQTOR　FIX接続仕様書（データフォーマット編）」の「付録1 理由コード一覧」を参照。 === 6.2.1 業務系メッセージ === 本章では、CONNEQTORの業務系メッセージのシーケンス例を示す。 == (1) RFQ送信から約定通知受信（正常系） == CONNEQTORの正常系メッセージの基本的なシーケンスを、以下の図 6.2.1に示す。 {{ :spec:jp:isv:図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス.svg?600 |図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス}} - 投資家システムはCONNEQTORにRFQを送信。 - CONNEQTORは投資家システムにRFQ受付通知を送信。 - ToSTNeTでの約定後、CONNEQTORは投資家システムに約定通知を送信。 - CONNEQTORは投資家システムにDone for dayを送信。 ;#; ** 図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス ** ;#; \\ == (2) RFQ送信（業務エラー系） == RFQ送信で業務エラーとなった場合の基本的なシーケンスを、以下の図 6.2.2に示す。 {{ :spec:jp:isv:図 6.2.2　RFQ送信（業務エラー系）のシーケンス.svg?600 |図 6.2.2　RFQ送信（業務エラー系）のシーケンス}} - 投資家システムはCONNEQTORにRFQを送信。 - CONNEQTORは投資家システムにRFQ受付拒否通知を送信。 ;#; ** 図 6.2.2　RFQ送信（業務エラー系）のシーケンス ** ;#; \\ == (3) RFQ取消等 == RFQが取消等となった場合の基本的なシーケンスを、以下の図 6.2.3に示す。 {{ :spec:jp:isv:図 6.2.3　RFQが取消等となった場合のシーケンス_s.svg?600 |図 6.2.3　RFQが取消等となった場合のシーケンス}} - 投資家システムはCONNEQTORにRFQを送信。 - CONNEQTORは投資家システムにRFQ受付通知を送信。 - CONNEQTORは投資家システムにRFQキャンセル通知を送信。 ;#; ** 図 6.2.3　RFQが取消等となった場合のシーケンス ** ;#; \\ ==== 6.3 異常時のシーケンス ==== 本章では、異常時におけるシーケンス例について示す。 なお、エラー通知等に設定される理由コードについては、「CONNEQTOR　FIX接続仕様書（データフォーマット編）」の「付録1 理由コード一覧」を参照。 === 6.3.1 電文不正時のシーケンス === == (1) システム内論理矛盾エラー（重度エラー） == == ①CONNEQTORからの入力電文（下り）を投資家システムにて論理矛盾エラー（重度エラー）と認識した場合 == CONNEQTOR送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）により投資家システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.1に示す。 {{ :spec:jp:isv:図 6.3.1　【電文不正時のシーケンス】.svg?600 |図 6.3.1　【電文不正時のシーケンス】}} - 投資家システムはCONNEQTORからの電文をFIXプロトコル不正と認識した場合、CONNEQTORへRejectを送信する。 - 投資家は東証と連絡を取り、障害原因の調査を行う必要がある。 ※ Rejectの送信条件は、「4.7 プロトコルエラー(セションReject)」参照。\\ ※ CONNEQTORから不正電文が送信されることは通常あり得ない。 回復時の処置：障害原因を取り除いた後、FIXセション確立シーケンスを実行する。 ;#; ** 図 6.3.1　【電文不正時のシーケンス】 **\\ ** CONNEQTORからの電文（下り）を投資家システムにて論理矛盾エラー（重度エラー）と認識した場合のシーケンス **\\ ;#; \\ == ②投資家システムからの通知電文（上り）をCONNEQTORにて論理矛盾エラー（重度エラー）と認識した場合 == 投資家システム送信電文が、プロトコル不正（FIXプロトコル4.2(Errata)に準拠していない）によりCONNEQTORで正常電文と認識されない場合のシーケンスを以下の図 6.3.2に示す。 {{ :spec:jp:isv:図 6.3.2　【電文不正時のシーケンス】.svg?600 |図 6.3.2　【電文不正時のシーケンス】}} - CONNEQTOR は投資家システムからの電文をFIXプロトコル不正と認識した場合、投資家システムにRejectを送信する。 - 再度不正電文を受信した場合は、その都度投資家システムにRejectを送信する。 - 不正電文を連続して一定回数受信した場合、CONNEQTORは投資家システムにLogoutを送信し、Logout(応答)を待たずにコネクションを切断する。(連続回数については表 4.8.1 使用するプロトコル制御パラメタ参照) ※1 LogoutのTextタグの先頭5バイトに、解放要因となった理由が設定される。\\ 　回復時の処置：障害原因を取り除いた後、FIX セション確立シーケンスを実行する。 ;#; ** 図 6.3.2　【電文不正時のシーケンス】 **\\ ** 投資家システムからの通知電文（上り）をCONNEQTORにて論理矛盾エラー（重度エラー）と認識した場合のシーケンス **\\ ;#; \\ == (2) データ不正（軽度エラー） == データ不正とは、電文に設定されている業務内容や指示内容に、データ仕様上規定されていないデータが設定されている状態をいう。 == ①CONNEQTOR送信電文（下り）が投資家システムでデータ不正と認識された場合 == 　CONNEQTOR送信電文が、データ不正（軽度エラー）により投資家システムで正常電文と認識されない場合のシーケンスを以下の図 6.3.3　【電文不正時のシーケンス】に示す。 {{ :spec:jp:isv:図 6.3.3　【電文不正時のシーケンス】.svg?600 |図 6.3.3　【電文不正時のシーケンス】}} - 投資家システムにて電文の内容に不正を検出した場合、CONNEQTORにLogout（要求）を送信しFIXセションの解放を行い、さらに東証と連絡を取り、障害原因の調査を行う必要がある。 - 障害原因を取り除いたのち、投資家システムよりLogon（要求）をCONNEQTORに送信し、FIXセションの確立を行う。 - FIXセション確立後、CONNEQTORは、未送信であると認識している電文から出力を再開する。 ;#; ** 図 6.3.3　【電文不正時のシーケンス】 **\\ ** 投資家システムにて通知系電文のデータ不正（軽度エラー）を検出した場合のシーケンス**\\ ;#; \\ == ②CONNEQTORにて電文のデータ不正（軽度エラー）を検出した場合 == CONNEQTORにて電文の内容に不正を検出した場合のシーケンスを以下の図 6.3.4に示す。 {{ :spec:jp:isv:図 6.3.4　【電文不正時のシーケンス】.svg?600 |図 6.3.4　【電文不正時のシーケンス】}} - CONEQTORにてデータ不正（軽度エラー）を検出した場合、投資家システムへエラー内容をReject (エラー）にセットし送信する。 - 当該入力電文は無効となるが、FIXセションの解放は行わず、次の入力電文の処理は続行される。 ;#; ** 図 6.3.4　【電文不正時のシーケンス】 **\\ ** CONNEQTORにおいて投資家システムからの電文がデータ不正と認識された場合のシーケンス **\\ ;#; \\ ==== 6.4 アプリケーションレベルの再送メッセージ（PossResend＝Yのメッセージ）について ==== 投資家システムがアプリケーションレベルの再送メッセージ（PossResend＝Yのメッセージ）を送信した場合、当該再送メッセージが受信済のメッセージと同一か否かの判定方法及び受信済メッセージであった場合の扱いを説明する。 再送メッセージが下記に該当する場合、当該再送メッセージは受信済と判断し破棄される。 * New Order Single * MsgType(Tag=35)が同一で且つClOrdID(Tag=11)に受信済の値が設定されている。 \\ \\ \\ ===== 7. 運用 ===== ==== 7.1 一日の運用 ==== 一日の運用を以下の図7.1.1に示す。 {{ :spec:jp:isv:図7.1.1　【一日の運用】.svg?600 |図7.1.1　【一日の運用】}} 一日の初回の Logon 時にシーケンス番号をリセットする。 ;#; ** 図7.1.1　【一日の運用】 ** ;#; ==== 7.2 システム変更時等のテストについて ==== 取引所及び投資家は、本書に定める仕様に準拠した通信が行えることを事前に確認する。そのため、FIXクライアントの新設/変更を実施する際は、両者で新設/変更の作業日やテスト日程等を合意し、スケジュールに沿って遅滞なく対応する。 \\ \\ \\ ===== 留意事項 ===== ====使用許諾条件==== 本接続仕様書のご利用に当たっては、必ず以下の項目をお読みいただき、以下の使用許諾条件に同意いただくことを条件とします。 *（著作権等） * 本接続仕様書の各種情報等（以下「技術情報等」という。）に関する著作権等の一切の権利は、東証に帰属します。 * （禁止事項） * 有償、無償を問わず第三者に対して、使用許諾、譲渡、転売、貸与又は媒体の如何にかかわらず本接続仕様書及び技術情報等の外部への提供若しくは印刷物の出版を禁じます。 * （免責） * 東証は、本接続仕様書の誤謬、省略若しくは欠落等に起因する損害等、直接又は間接を問わず技術情報等を利用したこと、又は利用できなかったことにより利用者及び利用者の顧客等に生じた一切の損害について、損害賠償責任を負わないものとします。 * 東証は、東証の故意又は重過失による場合を除き、本サービスの利用に起因しその他本書に関連して利用者及び利用者の顧客等に生じた損害につき、一切の法的責任を負いません。 * 東証は、東証の予見の有無を問わず特別の事情から利用者及び利用者の顧客等に生じた損害、及び利用者及び利用者の顧客等に生じた逸失利益については、賠償責任を負いません。 * 利用者等の損害賠償請求権は、損害発生の日から12ヶ月以内に行使しなければ消滅するものとします。 * （違反） * 利用者が使用許諾条件のいずれかの項目に違反した場合、利用者は東証の指示に異議なく従うものとします。 *（その他） * 東証は、本接続仕様書に記載した内容について、明示又は黙示の如何を問わずその無誤謬性を一切保証しません。 \\ \\ ===== 発行者 ===== 発行：株式会社 東京証券取引所\\ 　　　東京都中央区日本橋兜町2番1号 〒103-8220\\ 　　　MAIL:ask-conneqtor@jpx.co.jp\\ 　　　セション接続のための連絡先：050-3377-7751