トレーディングシステム開発（10）-FIXプロトコル

トレーディングシステム開発（10）-FIXプロトコル

1. FIXプロトコルの概要

1. FIXプロトコルの概要

FIX（Financial Information eXchange Protocol）は、国際FIX協会によって提供されるオープンな合意です。その目的は、国際貿易の電子プロセスを促進することです。投資マネージャー、ブローカー、バイヤーを含むさまざまな参加者の間で、売り手はリアルタイムの電子通信プロトコルを確立します。
FIXプロトコルの目標は、さまざまな証券および金融ビジネス要件プロセスを、コンピューター言語で記述できる機能プロセスにフォーマットし、さまざまな機能モジュールの接続を容易にするために、各ビジネス機能インターフェースの交換フォーマットを統一することです。
 2006年10月、FPL（FIX Protocol Ltd）はFIX5.0をリリースし、FIX5.0はTI（トランスポート独立）トランスミッション独立フレームワークを導入しました。TIは、FIXセッション層をアプリケーション層プロトコルから分離します。TIフレームワークでは、アプリケーション層プロトコルメッセージは、適切な任意の伝送技術を介して送信できます。FIXセッション層プロトコルは、FIXアプリケーション層メッセージのオプションの伝送プロトコルの1つです。2つのプロトコルレイヤーのバージョンラベルは異なります。FIXXYは、財務活動に関連するビジネスデータ構造を定義するFIXアプリケーションレイヤープロトコルバージョンです。FIXTXYは、FIXセッションレイヤープロトコルバージョン番号で、セッションレイヤープロトコルは、データ通信を定義します。関連する契約。

2. FASTプロトコル

FIXプロトコル伝送市場データの高冗長性と高帯域幅需要の問題を解決するために、シカゴマーカンタイルエクスチェンジ（CME）は2003年にFPL（FIX Protocol Ltd）にソリューションを提出し、FPLは2004年に市場を確立しましたデータ最適化作業グループ（MDOWG）。2005年に、MDOWGは一部のPOC（Prove of Concept）の結果に基づいてプロトコル標準の策定を開始し、2006年の初めにFAST（FIX Adapted for Streaming）V1.0を完了し、2006年12月に完了しました。 FAST V1.1。 
FASTプロトコルの中心は圧縮アルゴリズムであり、FIX仕様で定義されたデータを圧縮した後、送信側と受信側の帯域幅を大幅に削減できます。
FASTプロトコルの利点は、高圧縮率、低リソース消費、シンプルで効率的なアルゴリズム、1秒あたり100万レベルのメッセージ処理能力です。

3. STEPプロトコル

STEP（証券取引所交換プロトコル）は、FIXプロトコルのFIX 4.4バージョンに基づいた、中国語にローカライズされたFIXプロトコルバージョンです。これは、中国の国家金融業界標準であり、シンプルな構文を持つ事実上の証券データ標準になっています。定義は柔軟で拡張が容易で、データは比較的冗長です。

4.バイナリアグリーメント

Binaryは、さまざまなメッセージフィールド、エンコードおよびデコードルールなどを定義するバイナリプロトコルです。深セン証券取引所のバイナリプロトコルでは、すべてのメッセージは、メッセージヘッダー、メッセージ本文、メッセージテールの3つの部分で構成されています。メッセージヘッダーは8バイトで、整数のMsgTypeと整数のBodyLenを含みます。MsgTypeはメッセージのタイプを表し、BodyLenはメッセージ本文の長さを表します。メッセージの本文はBodyLenのサイズに従って読み取られます。メッセージの終わりは4バイトのチェックサムです。

5. FIXプロトコルの長所と短所

FIXプロトコルの利点は、キーと値のペアを使用してメッセージの内容を簡単に表示し、新しいフィールドを拡張できることです。国際的に普遍的であり、強力な適応性があります。
FIXプロトコルの欠点は、速度が遅いことです。

2. FIXプロトコルの動作原理

1. FIXアプリケーションモード

FIXには2つのアプリケーションタイプがあります。イニシエーターとアクセプターです。イニシエーターは通信のイニシエーターであり、最初のログオンメッセージを送信してセッションを開始します。アクセプターはFIXセッションのレシーバーで、第1レベルの認証を実行し、ログオンメッセージの応答を送信して正式な接続要求が受け入れられることを確認します。 。
FIXプロトコルは、イニシエーターが通信のイニシエーターであり、アクセプターがレシーバーであることを規定しています。FIX標準アプリケーションモードでは、ゲートウェイをアクセプターとして、クライアントをイニシエーターとして使用します。

2、FIX接続

FIX接続は、ログオンログイン、メッセージ交換メッセージ送信、ログアウトログアウトの3つの部分で構成されます。

3、修正セッション

FIXセッションは1つ以上のFIX接続で構成され、FIXセッションは複数のログインを持つことができます。
FIXセッションは、接続された2つのパーティ間で連続したシーケンス番号を持つ、順序付けられたメッセージの双方向送信ストリームとして定義されます。単一のFIXセッションは、複数の連続した（並列ではない）物理接続にまたがることができます。FIXセッションでは、参加者は複数回接続および切断できます。接続された当事者は、個々のシステムとタイムゾーンの要件に従って、セッションの開始と終了を公に交渉する必要があります。
24時間の接続を維持し、ログオンメッセージに設定されているResetSeqNumFlagを介して新しいシーケンス番号を確立するために、24時間ごとに新しいFIXセッションを確立することをお勧めします。
各FIX参加者は、FIXセッションの2つのシーケンス番号を維持する必要があります。1つは受信シーケンス番号で、もう1つは送信シーケンス番号です。どちらもFIXセッションが確立されると1に初期化されます。各メッセージには一意のシーケンス番号値が割り当てられており、メッセージの送信後に増分されます。さらに、各受信メッセージには固有のシーケンス番号があり、受信シーケンス番号カウンターは各メッセージが受信された後に増分されます。
受信したシリアル番号が目的の正しいシリアル番号と一致する必要がない場合は、エラーを修正する必要があります。

4.シリアル番号

各FIXメッセージは一意のシリアル番号で識別されます。シリアル番号は各FIXセッションの開始時に1に初期化され、セッション全体で増加します。監視シーケンス番号により、セッション参加者は失われたメッセージを識別して処理し、FIXセッションで再接続するときにアプリケーションをすばやく同期できます。
各セッションは、互いに独立した一連の送受信シーケンスを確立します。セッション参加者は、メッセージの送信に割り当てられたシーケンスと、受信したメッセージを監視するためのメッセージブロックギャップシーケンス番号を維持します。

5.ハートビート

メッセージの対話中に、FIXアプリケーションは定期的にハートビートハートビートメッセージを生成します。ハートビートメッセージは、通信リンクのステータスを監視し、受信したシーケンス番号のギャップを識別できます。ハートビートメッセージの定期的な間隔は、ログオンメッセージのHeartBtIntフィールドを使用してセッションイニシエーターによって定義されます。
ハートビートハートビートメッセージの時間間隔は、各メッセージの送信後にリセットする必要があります。つまり、メッセージを送信した後、指定された時間間隔内に他のメッセージが送信されない場合、ハートビートハートビートメッセージが送信されます。HeartBtInt値は、両方のセッションパーティによって認識され、セッションイニシエーターによって定義され、セッションレシーバーによってログオンメッセージを通じて確認される必要があります。同じHeartBtIntが、セッションの両方の当事者（ログイン開始者とログイン受信者）によって使用されます。

6.データの完全な検証

メッセージデータコンテンツの整合性は、メッセージの長さとチェックコードチェックの2つの方法で確認できます。
プログラムは、BodyLengthフィールドからCheckSumマーク（ "10 ="）区切り文字までの文字数を計算し、フィールドBodyLengthで識別されるメッセージ長を比較することにより、整合性検証を完了します。
ChekSum整合性チェックは、フィールド「8 =」で「8」から始まる各文字の2進数を計算し、CheckSumタグフィールドの直後の区切り文字を含めて、それをCheckSumと比較することによって取得されます。
FIXメッセージのチェックサムは、ChechSumフィールド（含まれていない）のメッセージの各バイトの合計を計算することによって計算されます。次に、チェックサムは、送信と比較のために256を法とする数値に変換されます。チェックサムは、すべての暗号化操作の後で計算されます。
FIXメッセージの例は次のとおりです
。8= FIX.4.29 = 7335 = A34 = 149 = CLIENT52 = 20181119-10：42：48.76856 = SERVER98 = 0108 = 30141 = Y10 = 208
メッセージ長：9 = 73、識別されたメッセージ本文は次のとおりです：
35 = A34 = 149 = CLIENT52 = 20181119-10：42：48.76856 = SERVER98 = 0108 = 30141 = Y

7.メッセージの確認

FIXプロトコルは単一のメッセージの確認をサポートしていません。メッセージのタイムスロットを監視する方法は、メッセージの回復と検証に使用されます。
通常のデータ送信（単一のメッセージ確認なし）は、メッセージシーケンスのギャップを介したエラー識別に使用されます。各メッセージは、一意のシリアル番号で識別されます。受信側のアプリケーションは、受信したメッセージのシーケンス番号を監視して、メッセージギャップを識別し、再送信要求を生成します。

8.暗号化

暗号化アルゴリズムは、接続の両方の当事者によってネゴシエートされます。
メッセージの任意のフィールドを暗号化して、SecureDataフィールドに配置できます。ただし、表示される一部のフラグフィールドはクリアテキストで送信する必要があります。完全性を確保するために、SecureDataフィールドで平文フィールドを繰り返すことができます。
暗号化を使用する場合、すべてのメッセージ本文を暗号化することをお勧めします。メッセージ内のサイクリックグループデータの一部を暗号化する場合は、サイクリックグループをすべて暗号化する必要があります。
事前にネゴシエートされた暗号化アルゴリズムは、ログオンメッセージで宣言されます。

9.カスタムドメイン

FIXプロトコルは、ユーザーに最大限の柔軟性を提供し、ユーザーがドメインをカスタマイズできるようにします。カスタムドメインが実装され、合意された参加者間に適用されるため、競合を回避するように注意する必要があります。
FIXプロトコルは、5000〜9999のタグが企業提携での情報交換用のユーザー定義ドメイン用に予約されており、FIX Webサイトを通じて登録できることを規定しています。10,000を超えるタグは、登録なしで単一の企業による内部使用のために予約されています。

10.順序付けられたメッセージ処理

FIXプロトコルは、メッセージがすべての参加者間で完全な順序で送信されることを前提としています。プロトコルの実装者は、メッセージギャップを埋めるプロセスを設計するときに、シーケンシャル送信の想定を考慮する必要があります。メッセージのギャップを処理するには2つの方法があります。1つ目は、受信したメッセージが最後に受信したメッセージのフォローアップメッセージであること、またはすべての新しいメッセージの順序付けされたシーケンスを維持するときに特定の欠落メッセージを要求することです。たとえば、受信者が5つのメッセージブロックの2番目を失うと、プログラムは3番目から5番目のメッセージを無視して、メッセージ2からメッセージ5への再送信要求、またはメッセージ2から無限大への再送信要求を生成できます。リクエストを渡します。2番目の方法は、メッセージ3〜5を一時的に格納し、メッセージ2のみを再送信するように要求することです。

11.メッセージを繰り返す

FIXエンジンが指定されたターゲットによるメッセージの受信に成功した場合、または再送信要求に応答した場合、可能なメッセージコピーが生成されます。重複したメッセージは同じシーケンス番号で再送信され、ヘッダーのPossDupFlagフィールドは「Y」に設定されます。受信側のプログラムは、再送信メッセージの処理を担当します。再送信メッセージは、新しいメッセージとして処理することも、実際の状況に応じて無視することもできます。
すべての再送信要求の応答メッセージには、値が「Y」のPossDupFlagフィールドが含まれます。PossDupFlagフィールドまたはPossDupFlagフィールドが「N」でないメッセージは、初期送信メッセージと見なされます。PossDupFlag値が「Y」の再送信メッセージは、CheckSum値を再計算する必要があります。レプリケーションメッセージの変更されたフィールドには、CheckSum、OrigSendingTime、SendingTime、BodyLength、PossDupFlagが含まれ、暗号化関連フィールド（SecureDataLenおよびSecureData）も再構築する必要があります。

12.メッセージの再送信

あいまいなアプリケーション層メッセージは、Po *** esendフラグと共に再送信される場合があります。この方法は、指定された時間内に注文が確認されない場合、またはエンドユーザーが送信せずに注文を一時停止する場合に非常に役立ちます。受信プログラムはこのフラグを認識し、その内部ドメインに質問して、コマンドが以前に受信されたかどうかを判断する必要があります。再送信されたメッセージには、元のメッセージと同じデータ本文が含まれますが、Po *** esendフラグと新しいシーケンス番号が含まれます。さらに、CheckSumと暗号化関連のドメイン値を再構築する必要があります。

3、メッセージタイプ

1.経営ニュース

管理メッセージ（管理メッセージ）は、ログイン、ハートビート、検査要求、再送信要求、拒否（交換プロセス）シーケンスのリセットとログアウトなど、よりスムーズで一貫性のある情報交換プロセスに使用されるコントロールです。

2.アプリケーションニュース

アプリケーションメッセージ（アプリケーションメッセージ）は、次のデータを含むトランザクションデータ
です。お知らせ：完了したトランザクション情報を発表します。
重要な注意：ブローカーによって売買された証券が、株式によって制限されている民間企業によって所有されているのか、またはエージェントとその持ち株によって所有されているのかを教えてください。
メッセージ：ブローカーと機関の間で送信される一般的な自由形式のメッセージであり、識別情報の緊急性と事業名の分類記号が含まれています。
電子メール：その形式と目的はメッセージ情報と同じですが、両方の当事者による非公開に使用される傾向があります。
見積もりリクエスト：一部の市場では、ブローカーが各注文の前に見積もりを行う必要があります。
見積と複数見積：見積依頼の情報に応答し、事前見積の発行に使用されます。
複数の見積の確認を要求する：見積の確認を選択的にサポートするには、見積応答レベルマークを使用します。
見積キャンセル：見積開始者は、見積をキャンセルするために使用されます。
見積ステータスリクエスト：機関が実行レポートを生成するために使用します。
見積確認：見積、複数見積、見積取消、見積依頼に対応します。
市場データ要求：この要求を通じて、指定された証券および外国為替取引の相場の市場データを取得します。
市場データ-スナップショット、完全更新：両当事者の注文レジスター、見積リスト、トランザクションリスト、インデックス値、始値、終値、トランザクション単価、最高価格、最低価格、変動加重平均価格などを送信するために使用されます。
Market data-add refresh：更新リクエストを追加するために使用されます。
市場データ要求の拒否：ブローカーが取引または技術的な理由により市場データの要求を受け入れない場合に使用されます。
証券定義要求：指定された証券と第三者の間のトランザクションに使用されます。
証券定義：証券定義情報で要求された証券を受け入れるか拒否し、証券とタイプのリストを送り返します。
有価証券状態要求：有価証券の状態に関する要求を行うために使用されます。
証券ステータス：証券ステータスの変更に関するレポートを提供します。
注文状況リクエスト：市場状況に関する情報をリクエストします。
取引ステータス：市場の状況に関する情報を提供します。
新しい注文：機関は証券または外国為替の注文をブローカーに提供します。
実行レポート：注文または注文変更情報の受信の確認、注文ステータスまたは注文トランザクション情報の送信、およびトランザクションコストのレポート。
不明なトランザクション：受け取った注文が実行されたことをトランザクションパーティに通知します。
注文のキャンセルと交換のリクエスト：注文のパラメータを変更します。
注文キャンセル拒否：ブローカーが受け取ったキャンセル要求情報を受け入れることができないときにブローカーが送信するメッセージ。
注文状況リクエスト：代理店は、ブローカーに注文状況に関する情報を生成して表示するように要求します。
転送：オーダーまたはオーダーのグループを1つ以上のアカウントに分割する方法を指定します。
振込確認：機関から送信された振込情報とステータスの受信を確認します。
決済指示：ブローカーまたは機関による取引の決済に関する指示。
入札リクエスト：プライベートマーケットとオープンマーケットでは、市場ルールが異なるため使用方法が異なります。
入札レスポンス：2つの市場ルールが異なるため、使用方法も異なります。
新しい注文リスト：2つの市場ルールにより異なる。
ノックダウン価格：取引所の元本取引のノックダウン価格。
ステータスリスト：売り手は、応答ステータスリストのリクエスト情報を積極的に送信します。
リストの実行：代理店は、提出された証券注文情報の実行を開始するようブローカーに指示するために使用されます。
リストのキャンセル要求：取引注文の実行前または実行中に、提出された証券注文メッセージをキャンセルするために機関によって使用されます。
ステータスリストリクエスト：代理店がブローカーにステータスリストに関する情報を生成するように指示するために使用されます。
リスト順序情報の分解：他のFIX情報と同じ方法を使用して、プログラムトランザクションの情報の分解をサポートします。
トランザクション情報の拒否：トランザクションの注文ルールに準拠しているため他の方法では拒否できないアプリケーションレベルの情報を拒否します。

4、FIXプロトコル

1.データ型

FIXプロトコルのデータ型には、整数int、浮動小数点数float、文字char、ブールブール、文字列String、データデータが含まれます。

2、フィールド

フィールドは、タグ、値、およびデリミタで構成されます。デリミタは、異なるフィールドを区切るために使用されます。たとえば、8 = FIX4.1SOH、タグは8、値はFIX4.1、デリミタはSOH（0x01）です。
共通フィールドは次のとおりです。
タグフィールド名説明
8 BeginString開始文字列、FIXプロトコルバージョン
9 BodyLengthメッセージ長
35 MsgTypeメッセージタイプ：たとえば、F =注文キャンセルリクエスト、
11 ClOrdIDクライアント注文ID
37 OrderIDサーバー注文ID
41 OrigClOrdID元のクライアントサイドオーダーID
54サイドトランザクションタイプ。例：1 =購入、2 =売却
55シンボル株式コード。例：YRD
10 CheckSumチェックコード

3.ニュース

FIXメッセージは、メッセージヘッダー、メッセージ本文、メッセージテールの3つの部分を含む複数のフィールドで構成されます。
メッセージヘッダーの最初の3つのフィールドの順序は変更できません。開始文字列（Tag = 8）、メッセージ本文の長さ（Tag = 9）、メッセージタイプ（Tag = 35）です。
メッセージの最後の最後のフィールドは、チェックサムフィールド（Tag = 10）でなければなりません。
8 = FIX.4.49 = 6335 = 034 = 115849 = SAMPLESENDER52 = 20150201-00：22：34.99556 = SAMPLETARGET10 = 114
循環グループでは、フィールドの出現順序は、循環グループがメッセージまたはコンポーネントで定義されている順序に従う必要があります。メッセージでは、サイクリックグループフィールド以外のフィールドは繰り返し表示できません。
FIXメッセージはパブリックネットワークや安全でないネットワーク上で送信および交換される可能性があるため、関連する機密データを暗号化する必要があります。具体的な暗号化方法は、接続する当事者が合意した内容によって決まります。
FIXメッセージでは、公的に識別する必要がある一部のフィールドを除いて、他のフィールドを暗号化して暗号文データフィールド（SecureData）に配置でき、暗号化されたフィールドはプレーンテキスト表現も保持できます。
暗号化スキームを使用する場合、FIXメッセージの本文にあるすべてのフィールドを暗号化できます。暗号化する必要があるメッセージの循環グループの一部がある場合は、循環グループ全体を暗号化する必要があります。
FIXプロトコルは、デジタル署名、鍵交換、テキスト暗号化などのセキュリティテクノロジーをサポートするためのいくつかのフィールドも提供します。

4.メッセージヘッダー

各セッションまたはアプリケーションメッセージにはメッセージヘッダーがあり、メッセージヘッダーは、メッセージタイプ、メッセージ本文の長さ、送信先、メッセージシーケンス番号、送信開始ポイント、および送信時間を示します。
タグのドメイン名には
8文字列を指定する必要がありますY開始文字列、値：FIX.4.2（暗号化されていない、
メッセージの最初のフィールド）9 BodyLength Yメッセージ本文の長さ（暗号化されていない、メッセージの2番目のフィールド）
35 MsgType Yメッセージタイプ（暗号化されていない、メッセージの3番目のフィールド）
49 SenderCompID Y送信者コード（暗号化されていない、送信者識別子）
59 TargetCompID Y受信者コード（暗号化されていない、受信者識別子）
115 OnBehalfOfCompID N初期送信者識別子（暗号化可能）、第三者による送信に使用されます。
128 DeliverToCompID Nサードパーティによる送信に使用される最終受信者識別子（暗号化可能）。
90 SecureDataLen N暗号文データ長
91 SecureData N暗号文データ（暗号文データ長フィールドに続く）
34 MsgSeqNum Yメッセージシーケンス番号（暗号化可能）、トランザクションパーティがFIXセッションメカニズムを使用しない場合、タグを固定に設定できます。値、たとえば0。
50 SenderSubID N送信者サブ識別子（
暗号化可能）142 SenderLocationID N送信者ロケーション識別子（
暗号化可能）57 TargetSubID N受信者サブ識別子（
暗号化可能）143 TargetLocationID N受信者ロケーション識別子（
暗号化可能）116 OnBehalfOfSubID N最初の送信者サブ識別子（暗号化可能）
144 OnBehalfOfLocationID N初期送信者位置識別子（暗号化
可能）129 DeliverToSubID N最終受信者サブ識別子（
暗号化可能）145 DeliverToLocationID N最終受信者位置識別子（
暗号化可能）43 PossDupFlag Nフラグが繰り返される場合があります。繰り返し送信する場合、この印をつけなさい。（暗号化可能）
97 Po *** esend Nはフラグを再送信できます。（
暗号化可能）52 SendingTime Y送信時間（
暗号化可能）122 OrigSendingTime N元の送信時間（
暗号化可能）347 MessageEncoding Nメッセージのエンコードフィールドの文字エンコードタイプ（非ASCIIコード）
369 LastMsgSeqNumProcesse d N最後に処理されたメッセージシーケンス番号（暗号化可能））
370 OnBehalfOfSendingTime N最初の送信時刻（UTCを使用して時刻を示す）

5.メッセージの末尾

すべてのメッセージ（会話またはアプリケーションメッセージ）にはメッセージテールがあり、これで終了します。メッセージの末尾は、複数のメッセージを区切るために使用でき、3桁のチェックサム値が含まれています。
タグのドメイン名には
93 SignatureLength Nデジタル署名の長さ（暗号化されていない）を指定する必要があります
。89 SignatureNデジタル署名（暗号化されていません）
10 CheckSum Yメッセージの最後のフィールドであるチェックサム。（暗号化されていません）

6.新しい注文のニュース

メッセージヘッダーにPo *** esendフラグが設定された注文メッセージの場合、トランザクションクライアントの注文番号（ClOrdID）を使用して、注文が受け取られたかどうか、および注文パラメーター（購入方向、証券コード、数量等）確認用です。注文が以前に受け取られている場合は、注文ステータスに実行レポートメッセージで応答する必要があります。それがまだ受信されていない場合は、実行レポートメッセージで注文確認に応答します。

7.実行レポートメッセージ

注文の受領には、注文の確認、注文ステータスの変更の確認（キャンセルの確認など）、トランザクションの返品、
注文の拒否が含まれます。

8.注文状況リクエストメッセージ

注文ステータス要求は、トランザクションサーバーから注文のステータスを要求するために使用され、トランザクションサーバーは実行レポートメッセージを通じて注文ステータスを返します。

9.注文キャンセルメッセージ

注文キャンセルメッセージは、すべての注文の残りの数量をキャンセルするために使用されます。
注文キャンセルメッセージにもClOrdIDが与えられます。拒否された場合、注文キャンセル拒否メッセージのClOrdIDが注文キャンセルメッセージのClOrdIDに配置され、元の注文のClOrdIDがOrigClOrdIDフィールドに配置されます。ClOrdIDは一意である必要があります。

10.キャンセルメッセージ

このメッセージは、注文キャンセルメッセージを拒否するために使用されます。
キャンセルを受け取ったトランザクションサービスパーティは、実行できない（約定した注文を変更できないなど）と判断した場合、キャンセル拒否を送信します。
注文のキャンセルが拒否された場合、キャンセル拒否メッセージはClOrdIDを使用してキャンセルされた注文のClOrdIDを示し、OrigClOrdIDを使用して最後に受け入れられた注文を示します（拒否の理由が「不明な注文」でない場合）。
タグドメイン名は、
標準メッセージヘッダーを指定する必要がありますY MsgType = 9
37 OrderID Y先物会社の注文番号。同じ取引日に一意である必要があります
11 ClOrdID Yトランザクションクライアントの注文番号
41 OrigClOrdID Y元のトランザクションクライアントの注文番号。キャンセルされた注文のClOrdIDを示します。
39 OrdStatus Y注文ステータス
109 ClientID Y顧客資金口座番号
1アカウントY顧客トランザクションコード
60 TransactTime N注文開始時間
434 CxlRejResponseTo N注文の引き出し拒否応答タイプ
102 CxlRejReason N注文の引き出し拒否理由
58テキストN
10標準メッセージ終了Y