概要
FIX はアプリケーション層のプロトコルです。FIX Trading Community の説明では「どのような業務情報をやり取りし、それが何を意味するかを定義するものであり、その情報を物理的にネットワーク上でどう送るかを定義するものではない」とされています。トランスポートからは意図的に分離されており、同じ業務メッセージを TCP/IP でもマルチキャストでも WebSocket でも運べます。
バージョンについては、FIX 4.2 と FIX 4.4 がレガシー実装向けに引き続きサポートされる一方、現行の標準は FIX Latest です。FIX Latest は従来のようにバージョンを切って出すのではなく、Extension Pack によって漸進的に更新されます。接続先ごとに採用バージョンが違うことは前提として設計します。
技術仕様
公式ドキュメントで確認した内容です。出典はページ末尾に記載しています。仕様は更新されることがあるため、実装前に一次資料をご確認ください。
- プロトコルの位置づけ
- アプリケーション層。業務情報の構造・内容・ワークフローを定義し、物理的な伝送方式は定義しない
- トランスポート
- 非依存。TCP/IP、マルチキャスト、WebSocket などで搬送できる
- レガシー版
- FIX 4.2 / FIX 4.4（既存実装向けにサポート継続）
- 現行標準
- FIX Latest。Extension Pack による漸進的更新で、従来のバージョン別リリースを置き換えた
- 実装で扱う範囲
- ログオン・ハートビート・シーケンス番号・再送要求といったセッション管理と、発注・訂正・取消・約定通知の業務メッセージ
受託の範囲
- FIX エンジンの選定（商用 / OSS）と、接続先ごとのセッション設計
- カウンターパーティ固有のカスタムタグ・必須項目の差異を吸収するアダプタ実装
- シーケンス番号の管理、再送、障害時のリカバリ設計
- 認証局証明書・専用線・VPN を含む接続経路の構成
- 接続テスト（Conformance）の実施と、本番切替の手順整備
実装で詰まりやすい点
バージョンが同じでも「方言」がある
FIX 4.4 同士でも、カウンターパーティごとに必須タグとカスタムタグが違います。共通のドメインモデルを持ち、差分を接続アダプタへ閉じ込める構成にしないと、接続先が増えるたびに業務ロジックが汚れます。
セッション層の実装を自作しない
シーケンス番号のずれ、再送、重複、切断時の復帰は、正しく実装するのが難しい部分です。実績のある FIX エンジンに任せ、自前で作るのは業務メッセージのマッピングに限定するのが現実的です。
約定の突合をリアルタイム処理に混ぜない
約定通知の欠落や重複は必ず起きます。受信したメッセージをそのまま状態更新に使わず、シーケンスと約定 ID で冪等に処理し、日次で突合する経路を別に持ちます。
参照元
FIX API についてよくあるご質問
接続先が複数ある場合、どう設計しますか。
共通のドメインモデルを中央に置き、接続先ごとの差異はアダプタに閉じ込めます。カスタムタグや必須項目の違いをアダプタが吸収する構成にしておくと、接続先の追加が既存ロジックに波及しません。
FIX Latest へ上げるべきですか。
接続先が対応しているかで決まります。FIX 4.2 / 4.4 はレガシー実装向けにサポートが続いているため、既存接続を無理に上げる必要はありません。新規接続で選択肢がある場合に FIX Latest を検討するのが順当です。