FIXプロトコルの仕組み 2022年03月07日 – Posted in: Forex trading

はじめに

 株式市場の取引の歴史は、その始まりから大きく変化してきました。最初の証券取引所が登場したのは約400年前。当時は、取引は口頭で行われ、取引ルールも始まったばかりでした。しかし世の中は止まっているわけではなく、時代に合わせて証券取引所は当時考えうるあらゆる技術的な手段を取り入れていったのです。

こうして19世紀半ばには、取引所からある程度離れた場所での取引申し込みには、電信線がつながりました。その後、電話がそれに取って代わりました。そしてやがて、トレーダーの最初の取引要求がインターネットの通信を駆け抜ける瞬間がやってきたのです。

公平に見て、電話を介した取引は時にはまだいくつかのブローカーで現代においても発生しています。そして、そのうちのある部分は取引を行う唯一の保証された方法です。また最初の取引所の始まりから21世紀の初めまで、取引所の取引の領域で直接口頭で行われていました。このような取引所はストックピットと呼ばれ、同じような題材のハリウッド映画ではおなじみの光景でした。

FIX プロトコルの歴史　

 古くからあるデジタル取引プロトコルのひとつにFIXプロトコルがあります。「Financial Information Protocol」または「FInancial eXchange protocol」の略で、両方の定義があります。FIXプロトコル仕様は、1992年にフィデリティ・インベスメンツとソロモン・ブラザーズの間で行われた株式取引に関する情報を提供するために作成されました。ブローカーや投資ファンドは、取引所での取引プロセスをスピードアップさせたいと考えていました。その結果、どの主要な組織も管理しない、電子的に情報を伝送するためのオープンスタンダードが誕生したのです。現在では、FIXは各国の金融市場参加者がそれぞれの商品を接続するために使用する業界標準となっています。

当初、この通信プロトコルは上記の2つの取引所間だけで使われ、SBX（Salomon Brothers Exchange）と呼ばれ、株式取引にのみ使用されていました。その後、話の流れで自分たちの発明の重要性に気づいたこれらの企業のリーダーたちが、ゴールドマン・サックスとプットマンの開発に参加したいと申し出てきたのです。その後、このプロトコルは現在の名称になりました。

当初、このプロトコルは17種類のメッセージと103個のタグしかサポートしていませんでした。このアイデアは成功し、1995年には米国の全証券会社の70％以上がこのプロトコルを使用するようになりました。これはコスト削減、原価低減、取引ミスの減少が理由でした。やはり電話を通じての取引では、人間の要素が非常に大きな影響を与えます。時が経つにつれて、プロトコルは大幅に拡張されました。デリバティブ、債券、通貨取引のサポートが追加されたのです。現在のFIX仕様は、168のメッセージ、7,868のタグを記述し、すべてのクラスの有価証券をカバーしています。1998年、FIXプロトコルとその仕様の開発、および関連技術の開発は、FIX プロトコル有限コンソーシアムに移管されました。その後、同コンソーシアムはFIX トレーディングコミュニティと改称されました。現在、270以上の大手金融機関が加盟しています。

FIXプロトコルの仕組み

 FIXプロトコルはTCP上で動作します。現在、FIX プロトコルモデルは、セッションまたは制御レベル（セッションの作成、データ配信作業）とアプリケーションレベル（データコンテンツの説明）の 2 つのレベルで定義されています。制御層は、FIX セッションの基本的なパラメータ（接続の開始と終了、失われたメッセージの回復）を担当します。アプリケーション層は、データの送受信を制御します。リクエスト、執行、拒否、マーケット・データ、ステータス情報のリクエストなどです。プロトコル自体はテキストで、ASCII テーブルの文字を使用します。タグ＝値（Tag=Value または Key=Value）という従来の表現と，XML（FIXML）表現の2種類に分けられています。最新バージョンは現在5.0ですが、バージョン4.2や4.4が一般的です。ブローカーや取引所によって異なるバージョンのプロトコルを使用することができ、同時に複数のバージョンを使用することもあります。

構文  タグ=値

次のようなメッセージが表示されます:

8=FIX.4.2 | 9=178 | 35=D | 34=1234567 | 49=TESTER | 56=PHLX | 52=20071123-05:30:00.000 | 11=ATOMNOCCC9990900 | 54=1 | 167=FUT | 55=MSFT | 38=15 | 40=2 | 44=15 | 59=0 | 10=128 |

これは、縦棒で区切られたいくつかの部分からなるテキスト文字列です。これらの部分はフィールドと呼ばれます。それぞれの部分は、等号で区切られたキーと値のペアから構成されています。記号の右側がキーで、左側が値です。FIX 仕様書では、キーはタグと呼ばれています。 タグは常に正の整数であり、本質的にはフィールド名へのポインタとなります。すべてのフィールド名とその値の可能性は、特定の取引所のドキュメントに記載されています。これらのフィールドのほとんどは標準的なもので、あらゆる交換のBOM で見つけることができます。またカスタムフィールドもあり、これは特定のエクスチェンジ内でのみ定義され意味を持ちます。標準フィールドの記述が一般的な FIX プロトコル仕様にある場合、カスタムフィールドは交換の FIX プロトコル仕様に記述する必要があります。また、必須フィールド、オプション・フィールド、条件付き必須フィールド（メッセージ内の他のフィールドの存在に依存して必要となる）があります。SoH（Start of Header）記号は、フィールド間のセパレータとして使用されます。これは実際には見えないので、この例では縦棒に置き換えています。UNICODEエンコーディングでは、この文字のコードは” \u0001″ です。

次にメッセージはフィールドに分割されますが、さらに3つの構成要素を定義します:

  • ヘッダー (メッセージヘッダー)
  • ボディ（メッセージボディ）
  • メッセージトレーナー(チェックサム)

FIX1.1/FIX5.0 では、ヘッダには、8（BeginString）、9（BodyLength）、35（MsgType）、49（SenderCompID）、56（DestComppID）、1128（ApplVerID – 存在する場合は 6 番目のポジションになければならない）の 5 つの必須フィールドと 1 つのオプションフィールドがあります。メッセージには、管理メッセージと応用メッセージの 2 つの主要なグループがあります。管理メッセージは、FIX セッションの基本を扱います。これらのメッセージはセッションの開始と終了、および見逃したメッセージの復元を可能にします。アプリケーションメッセージは、ワラントの要求や、そのワラントの現在のステータスおよびその後の執行に関する情報など、取引関連情報の送受信に関連するものです。

このメッセージを分析します:

  • 8=FIX.4.2 – BeginString. プロトコルのバージョンが使用されます。トレーダープログラムに、このメッセージのフィールドを解析するために適用するルールを指示します。
  • 9=178 – BodyLength. メッセージ本体の長さは、ヘッダを含めて 178 バイトです。タグ35（含む）からタグ10（含む）までの文字数として計算されます。SoHスプリッタも考慮されます。
  • 35=D – MsgType. メッセージの種類。この場合、D は取引要求を出すことを意味します。例えば、35=V のフィールドは、その商品に関する相場情報を取得することを意味します。
  • 34=1234567 – MsgSeqNum. メッセージ番号。MsgSeqNum メッセージが送信されたシーケンスで 1 つも異ならない場合、サーバーはエラーを返し、メッセージを処理しません。
  • 49=TESTER – SenderCompID. 送信者 ID。取引所から発行されます。これは、ユーザー名、またはメッセージがブローカーによって送信される場合はブローカー名とすることができます。
  • 56=PHLX – TargetCompID. 送信先の受信者 ID。これも取引所から発行されます
  • 52=20071123-05:30:00.000 – SendingTime. メッセージが送信された日付と時刻。
  • 11=ATOMNOCCC9990900 – ClOrdID. ブローカー取引システムにおけるアプリケーション番号。
  • 54=1 – Side. 資産購入アクション
  • 167=FUT – SecurityType. 資産が未来
  • 55=MSFT – Symbol. マイクロソフトのプロモーションです。ティッカーは取引所によって異なる場合があります。
  • 38=15 – OrderQty. 取引数量は15ロットまたはコントラクトです。
  • 40=2 – OrdType. 限定価格購入、限定注文。
  • 44=15 – Price. 購入価格 – 15
  • 59=0 – TimeInForce. 申込期限は営業日終了後となります。
  • 10=128 – CheckSum. メッセージのチェックサム。 常にメッセージの最後のフィールド。特別な計算式で計算され、プロトコル仕様に記載されています。チェックサムフィールドの文字を除く、メッセージ内のすべての文字のASCII値を合計することで設定されます。その値を256で割って、区画の余りを取ります。チェックサムは常に3文字でなければなりません。つまり、モジュラスが22であれば、数字の前にゼロ-“022 “が追加されます。

このメッセージを一般的に説明すると、マイクロソフトの株式先物を上限価格15で、有効期限を当日の終わりにして、15枚の枚数で購入するアクションです。

FIXでより柔軟性を提供するために、プロトコルはユーザー定義フィールド、ユーザー定義フィールドとして知られているものが含まれています。これらは、協力する金融機関同士のデータ転送に使用されます。5000から9999までのタグ番号がカスタムフィールド用に確保されており、規格の公式サイトで予約することができました。その後、これらの番号が使用されたため、新たに2万から3万9999までの区間が割り当てられたのです。

FIXML構文

1998年に構文に関する作業が始まり、1999年に最初のバージョンがリリースされました。意味的にはタグで符号化されたメッセージと同等ですが、XMLのパース技術を使用しています。FIXML 形式での操作のための新しいアプリケーションは次のとおりです。:

<FIXML>

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>

<Instrmt Sym=”IBM” ID=”459200101″ IDSrc=”1″/>

<OrdQty Qty Qty=”1000″/>

</Order>

</FIXML>

XMLフォーマットでは、コードの特定のブロックは、いわゆるタグ（プロトコル自体で使用されるものではない別のタグ）で囲まれています。例えば、<FIXML>というトップ・オーダーのタグがあります。どのタグも、特定のコードやメッセージの一部を切り離し、同じタグで閉じますが、左端の内側には、スラッシュ文字があります。したがって、前述のタグは次のようにブロックを閉じることになります: </FIXML>.

次に、このタグの中に、次のようなタグがあります:

<Order ClOrdID=”123456″ Side=”2″ TransactTm=”2001-09-11T09:30:47-05:00″ OrderTyp=”2″ Px=”93.25″

Acct=”26522154″>.

ここでは、タグ名「Order」と、中括弧の中に追加情報（タグ=値構文と同じフィールド、キー=値のペア）があることがわかります。

この場合:

ClOrdID=”123456″ – ブローカー取引システムにおける注文ID

Side=”2″ – 販売注文

TransactTm=”2001-09-11T09:30:47-05:00″ 取引日時

OrdTyp=”2″ – クレームタイプ – 限定注文

Px=”93.25″ – 購入または売却する資産の価格

Acct=”26522154″ – ユーザーアカウント番号

前のXMLタグと同様に、XMLタグはスラッシュで閉じます – </Order>

XMLタグの開始と終了の間の内容をタグ本体と呼びます。したがって、注文タグはFIXMLタグの本体となります。本体であるOrderタグの内部には、さらに2つのタグが存在します。Instrmt と OrdQty です。

次のタグ:

<Instrmt Sym=”IBM” ID=”459200101″ IDSrc=”1″/>

ここでは、閉じると同時に、その末尾に斜線があることがわかります。これは、タグにnobodyがある場合であり、別途フレームタグを作る意味はありません。このタグには、ツールのティッカー、IDなどの情報が含まれています。

<OrdQty Qty=”1000″/>タグには、取引量に関する情報を見ることができます。これは、本文のない終了タグでもあります。

FIXMLは通常、バックオフィスや清算のアプリケーションに使用され、取引には使用されません。

FIX セッション層

 これまでの例では、アプリケーション層について説明しました。この仕様では、クライアントと交換の間のセッションレベルを担当する特別なフィールドタイプを定義しています:

  • 35=A – Logon. 接続時に交換システムに対してユーザーを認証するために使用されます。このメッセージは最初に送信され、データセッションの開始を交換を通知します。送信に成功すると、応答メッセージが届きます。接続に失敗した場合は、エラーが返されます。
  • 35=5 – Logout. このメッセージは、サーバーとの認証を解除し、取引所との取引セッションを終了するために使用されます。
  • 35=0 – Heartbeat. 心拍数または脈拍。このメッセージは、接続の両側から互いに送信され、両側がメッセージを受信および送信する準備ができていることを示します。ハートビート周波数は、最初のLogonメッセージで設定されます。
  • 35=1 – Test Request. このメッセージはテストメッセージであり、相手が設定期間内にハートビートメッセージを送信しなかった場合に送信されます。このメッセージに応答しないままだと、セッションは終了します。
  • 35=2 – Resend Request. このメッセージは、何らかの情報の欠落があった場合に再送信を要求するメッセージです。
  • 35=3 – Reject、または reject. 直前のメッセージが不正であった場合や実行できない場合に、相手方から送信されます。
  • 35=4 – Sequence Reset または reset the message sending sequence.2つの形式があります。

– 123=”Y” – 指定された値を持つ GapFillFlag タグが存在する。管理用メッセージが再送される場合、それを無視する要求を示します。

– MsgSeqNum カウンタをゼロにするために使用。

FIX APIの拡張としてのFASTの実装

大量のFIXデータの処理に大幅な遅延が発生し、トレーダーは効果的な取引戦略を立てられなくなりました。このような問題に気づいた直後から、事態の収拾に向けた第一歩が始まったのです。FASTプロトコルの目的は、大量のデータを送信しても、情報の取得に遅れが生じないようにすることでありました。FAST（FIX Adapted for STreaming、ストリーミングに適応したFIXと訳される）は、FIX Protocol Ltd.が開発した技術標準であり、特にネットワーク表示の最適化を目的として設計されたものです。基本的にはFIXプロトコルのバイナリ形式であり、取引や市場環境に関する大量の情報をコンパクトな形で転送することが可能です。そのため、伝送遅延の少ない高速取引システムでの利用が可能です。Fastは、パサデナにあるカリフォルニア工科大学で開発されました。現在、最新バージョンはFAST1.2。最も一般的なアプリケーション – ブローカーの取引システムをバイパスして、取引所に直接接続します。FASTプロトコルは、市場情報配信プロトコルとして標準化されており、世界で最も普及しています。以前、すべてのインターネットトラフィックは、前世紀の70年代に開発された伝送制御プロトコル（TCP）システムに基づいていました。TCPはソケット接続で、パケット配信の確認応答が必要です。大きなファイルやメッセージを1500バイトのパケットに分解し、それぞれにパケットの送信元アドレスと送信先アドレスを記述します。 送信者は、送信したパケットが正常に届いたかどうかの確認を待ち、初めて次のパケットを送信します。配信に失敗したり、指定されたタイムアウト時間内に配信信号が到着しない場合、パケットは再度送信されますが、その速度はより低いものになります。そして配信が成功したという信号が来るまで、指数関数的に速度が下がりながら、好きなだけ続けることができるのです。送信に失敗するたびに貴重なミリ秒を失うことになるため、ちょっとした回線トラブルでもデータレートに深刻な影響を与えることが明らかになりました。この方法では、パフォーマンスの低下を探る時間がかからないため、ほとんどの場合パケットの再送が不要になります。いくつかの交換では、接続インターフェースは2種類の接続によって実装されています。UDPとTCPです。UDPソケットですべてのデータを送信しても意味がありません。このような接続では送達の確認が不要なため、パケットは単に消滅し、どちらの当事者もそのことを知ることはありません。したがって、ほとんどのデータはUDPソケットで送信され、未配信のデータセットだけがTCPで送信されます。動きの速い市場では、再送信に伴う遅延はしばしば好ましくなく、機会損失や悪い取引につながります。

FAST の仕組み

すでにご存知のように、FIXプロトコルは、順番にキー=値のペアで構成されるフィールドの列です。文字列のフォーマットが本質的に冗長であることに加え、各メッセージにはフィールド名や「=」文字などの重複した要素があることにお気づきでしょう。FAST では、メッセージの構造全体を記述したテンプレートを使用することで、冗長性を排除しています。この方法は暗黙的なタグ付けと呼ばれています。送信データ内の FIX タグは「暗示的」なだけなので、タグ = 値 の構文は以下のように変化します。

  • テンプレートは、構造化されたフィールドのセットとその演算子を記述します
  • メッセージ内のフィールド・シーケンスは、テンプレート内のタグ・シーケンスと一致します
  • メッセージでは、データの変更のみが送信されます。

各タグの値は、バイト単位で固定長です。特定のフィールドの長さと、メッセージ内のフィールドの配置順を知ることで、メッセージ内のこれらのフィールドの値を特定することは難しくありません。したがって、テンプレートでは冗長な文字を転送する必要がなく、データそのもののみを直接転送することができます。各タグの値は、バイト単位で固定長です。特定のフィールドの長さと、メッセージ内のフィールドの配置順を知ることで、メッセージ内のこれらのフィールドの値を特定することは難しくありません。したがって、テンプレートでは冗長な文字を転送する必要がなく、データそのもののみを直接転送することができます。対応するフィールドはメッセージの固定された位置にあるので、目的の値にアクセスするのはずっと簡単です。必要なのは、メッセージの先頭からのオフセットと、その値の長さだけです。タグやFIXMLとは異なり、SBEメッセージは自己記述的ではありません。メッセージを制御するテンプレートを識別するために、最小限のヘッダーを持つデータのみがネットワーク上で送信されます。メッセージ構造を記述したメタデータ（テンプレート）は、主通信路の外で交換されます。必要なテンプレートを受け取った取引サーバーは、この接続されたセッションの枠組みの中で、どのフォーマットでクライアントにデータを送信すればよいかを知ることができます。 このように、データを転送する前に、システムは将来どのように通信するかについて、何らかの形で互いに合意しているのです。メッセージスキーマは通常、XML形式で送信されます。これには、任意の数のメッセージ・テンプレートを含めることができます。テンプレートには、メッセージを構成するフィールドが記述されています。さらに、スキーマは、任意の数のフィールドで再利用可能な単純および複雑なデータ型のリストを提供します。

FIXプロトコルのさまざまな言語に対応するオープンな実装

Java – QuickFIX/J – http://www.quickfixj.org/

.NET/C# – QuickFIX/N – http://quickfixn.org/

FIXメッセージの無料オンライン・パーサー – FIX Parser – https://fix.aprics.net/

FASTのオープンな言語実装

C言語用 – FPLによる参考実装 – www.fixprotocol.org/fastdownload

C#用 – FPLによる参考実装 – www.fixprotocol.org/fastdownload

Java л д code – OpenFAST – www.openfast.org

www.sourceforge.net/projects/openfastdotnet/ Д я

Для C++ – QuickFAST – www.quickfast.org

Для Golang – goFAST – www.github.com/co11ter/goFAST

その他のプロトコルFIXエンコーディング

FIX コミュニティは、FIX プロトコルと次のような他のデータ・シリアライゼーション・プロトコルとの間の標準的なマッピングも開発しました:

  • JSON
  • Google (プロトコルバッファ)

|ASN.1

FIX/FASTプロトコルの応用分野

原則として、2つの単語がぴったりと重なったときに発生する略語です。取引所から様々な金融情報を取得するために使用されます。金融商品の表（価格、数量など）、相場、全取引、指数、およびすべての非人間的なアプリケーションに関する情報などです。取引所によって取得できるデータが異なる場合があります。 主なFIX/FASTは:

  • 個人トレーダーによる取引
  • この技術に基づいた製品を作るプログラマー。例えば – FIX API 取引プラットフォーム、異なる取引所へのコネクタ、取引システム、データ収集システム、統計など。
  • 取引所間の情報交換
  • 各種情報機関の最新データの取得

最も一般的な用途は、高頻度取引業者がDMA（市場への直接アクセス）を通じて他の市場参加者に対して優位に立つことです。このプロトコルは、証券取引所、銀行、FXブローカーによって取引エコシステムに組み込まれることがあります。一般に知られているデータによると、暗号通貨取引所はこの技術を使用していません。歴史的に、これらの取引所は、トレーダーの取引サーバーへの直接接続を提供するために、市場情報を取得するためのWebSocket接続と、取引操作を行うためのHTTP rest API接続を主に使用しています。WebSocket技術がまだTCP接続に匹敵する速度であるとすれば、HTTP rest APIは大きく損をしていることになります。