CONNEQTOR FIX接続仕様書（投資家/接続編）

1.0版
2023年6月 作成

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

機関投資家（投資家システム）は本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システム区分にかかる取引区分の業務のみを行う。

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

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

ステージング面は、テストを行うことを目的とした環境であり、テスト実施日は基本的に本番面の取引日と同日である。利用可能時間はテスト実施日の8:00（JST）から21:00（JST）である。
テストを実施する場合、投資家システムはテスト実施日の利用可能時間内にCONNEQTORに対してログインを試みる。
テストの途中にFIXセションが切断された場合は、再ログインを行うことも可能である。

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

ステージング面の全体構成イメージは図 2.1.1と同様であり、投資家システムからCONNEQTORへはarrownetを経由して接続する。

本仕様書は、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アドレスとポート番号

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

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

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

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

　FIXセションとは、2つのシステム間における双方向の連続的なシーケンス番号を持つ順序だったメッセージの流れと定義される。
　一連の会話の中では、送受信されるすべてのメッセージに一意なシーケンス番号が振られ、メッセージの順序性及び欠落のないメッセージ転送が保証される。シーケンス番号は、メッセージの転送方向毎に送信シーケンス番号、受信シーケンス番号が別々に管理され、セション開始時にそれぞれ1から始まり、1ずつ増加していく。
　FIXセションはシーケンス番号が1であるLogonメッセージの交換により開始される。通信を行う２者間の合意に基づき、シーケンス番号がお互いにクリアされた時点で終了する。また、通信を行う2者は、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またはExecution Reportを送信する。 RejectまたはExecution Reportを送信する条件は、以下の表に従う。

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

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

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

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　確立（認証ＮＧ）

投資家システムにおける能動型解放は、Logout要求に対してCONNEQTORからのLogout応答を受信し、この時点で解放が完了する。TCPコネクションの切断は投資家システムが行う。

図 6.1.4　能動型解放

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

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

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

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

図 6.1.5　ハートビート送信

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

図 6.1.6　受信ハートビート監視タイムアウト
補足）投資家システムの生存が確認できないため、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要求受信で投資家システムからのメッセージにシーケンスGapがあることを検出した場合、即時にResendRequestを送信してメッセージの再送を要求する。その後、再送を要求したメッセージが全て届いたらLogout応答を送信する。

図 6.1.10　Logout要求受信でGap検出

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

図 6.1.11　HeartBeat受信でGap検出

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

図 6.1.12　TestRequest受信でGap検出

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

図 6.1.13　ResendRequest受信でGap検出

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

図 6.1.14　SequenceReset-GapFill受信でGap検出

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

図 6.1.15　Reject受信でGap検出

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

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

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

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

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

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

1. 投資家システムはCONNEQTORにRFQを送信。
2. CONNEQTORは投資家システムにRFQ受付通知を送信。
3. ToSTNeTでの約定後、CONNEQTORは投資家システムに約定通知を送信。
4. CONNEQTORは投資家システムにDone for dayを送信。

図 6.2.1　RFQ送信から約定通知受信（正常系）のシーケンス

RFQ送信で業務エラーとなった場合の基本的なシーケンスを、以下の図 6.2.2に示す。

1. 投資家システムはCONNEQTORにRFQを送信。
2. CONNEQTORは投資家システムにRFQ受付拒否通知を送信。

図 6.2.2　RFQ送信（業務エラー系）のシーケンス

RFQが取消等となった場合の基本的なシーケンスを、以下の図 6.2.3に示す。

1. 投資家システムはCONNEQTORにRFQを送信。
2. CONNEQTORは投資家システムにRFQ受付通知を送信。
3. CONNEQTORは投資家システムにRFQキャンセル通知を送信。

図 6.2.3　RFQが取消等となった場合のシーケンス

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

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

1. 投資家システムはCONNEQTORからの電文をFIXプロトコル不正と認識した場合、CONNEQTORへ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. 障害原因を取り除いたのち、投資家システムよりLogon（要求）をCONNEQTORに送信し、FIXセションの確立を行う。
3. FIXセション確立後、CONNEQTORは、未送信であると認識している電文から出力を再開する。

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

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

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

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

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

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

• New Order Single
  • MsgType(Tag=35)が同一で且つClOrdID(Tag=11)に受信済の値が設定されている。

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

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

図7.1.1　【一日の運用】

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

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

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

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

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

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

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

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