FIX プロトコル

取引所やブローカーから約定の通知を受け取り、自社の取引管理システムに取り込む仕事では、通知の形式の 1 つとして FIX を使う接続先があります。通知が二度届いたり、番号が飛んだりしたときに、取り込みがどう振る舞うべきかを知っていると、システムの担当者と業務の担当者が同じ前提で話せます。

FIX とは何か

FIX（Financial Information eXchange）は、金融機関、取引所、ベンダーが、取引のメッセージを共通の形でやりとりするための標準です。FIX Trading Community が開発と維持を担い、仕様は公開されています。ネットワークの種類に依存せず、メッセージの構造と内容、手順を定めるプロトコルです¹。

対象の資産には、株式、債券、為替のほか、上場デリバティブと店頭デリバティブが入ります。メッセージは、取引の前、取引、取引の後に分けて整理されています¹。

層、書き方、版

FIX は、セッションとアプリケーションの 2 つの層で定義されています。セッション層はデータの配送を扱い、アプリケーション層は業務の内容を定めます²。

セッション層は、メッセージの個別の受領確認をしません。送る側がセッションの中で 1 から順に MsgSeqNum（番号）を付け、受ける側が番号の欠落を見つけて、再送を求める作りです³。

FIX 4.4 の仕様書では、書き方はタグ=値形式と FIXML の 2 つです。業務のメッセージの流れは同じで、同じものを別の書き方で表すだけです。タグ=値形式は、数字のタグと値を「タグ=値」の形で並べ、項目の区切りに制御文字の SOH（0x01）を使います。FIXML は XML の書き方で、セッション層を持たないため、FIX のセッションの中でも、ほかのプロトコルの上でも運べます⁴。現行の仕様では、従来のタグ=値形式のほかに、binary や JSON などの形式もあります¹。

次の例は、先物の約定を知らせる Execution Report（MsgType が 8）を、FIX 4.4 のタグ=値形式で書いたものです⁵。メッセージの名前と MsgType は、FIX 4.4 の定義のものです⁶。

8=FIX.4.4|
9=243|
35=8|
34=2087|
49=SELLSIDE1|
56=BUYSIDE1|
52=20261021-01:23:45.200|
37=ORD-000123|
11=CL-000045|
17=EXEC-000789|
150=F|
39=1|
1=ACCT-DUMMY|
55=DUMMYFUT|
167=FUT|
200=202612|
54=1|
38=10|
32=4|
31=1234.5|
14=4|
151=6|
6=1234.5|
60=20261021-01:23:45.123|
75=20261021|
10=041|

同じ約定を FIXML で書くと、次のようになります⁷。

<FIXML xmlns="http://www.fixprotocol.org/FIXML-4-4" v="4.4">
  <ExecRpt OrdID="ORD-000123" ID="CL-000045" ExecID="EXEC-000789"
           ExecTyp="F" Stat="1" Side="1"
           LastQty="4" LastPx="1234.5" CumQty="4" LeavesQty="6" AvgPx="1234.5"
           TrdDt="2026-10-21" TxnTm="2026-10-21T01:23:45.123Z" Acct="ACCT-DUMMY">
    <Hdr SID="SELLSIDE1" TID="BUYSIDE1" SeqNum="2087" Snt="2026-10-21T01:23:45.200Z"/>
    <Instrmt Sym="DUMMYFUT" SecTyp="FUT" MMY="202612"/>
    <OrdQty Qty="10"/>
  </ExecRpt>
</FIXML>

版の考え方

FIX は、4.x の版から 5.0 のサービスパックを経て、2009 年からは「FIX Latest」に移りました。FIX Latest は、拡張パック（仕様を少しずつ加えていく単位）で更新されます。FIX Trading Community は、FIX Latest の利用を強く勧めています。2026 年 10 月時点で、古い実装のために 4.2 と 4.4 の対応も続けています⁸。

FIX 5.0 では、セッション層がアプリケーション層から分かれ、FIXT という別の版の名前を持ちます。アプリケーション層は「FIX.x.y」、セッション層は「FIXTx.y」で表します⁹。5.0 SP2 は 2013 年 12 月 9 日の仕様で、19 の拡張パックを含みます¹⁰。

版によって、項目の名前や使い方が違います。約定の取消と訂正の表し方を、FIX 4.2 と FIX 4.4 で比べると、次のとおりです¹¹。

FIX Latest の ExecType も、F、G、H を持っています¹¹。

同じ版でも、接続先ごとに標準との差があります。Cboe Futures Exchange は FIX 4.2 のサブセットを使い、標準との差を仕様書に書いています¹²。ドロップコピー（取引所が約定の通知の写しを配信する仕組み）の ASX 24 の仕様は、FIX 5.0 SP2 の拡張パック 196 に基づいています¹³。接続先の仕様書を読むときは、標準の版と、その仕様書が決めた差の両方を見ます。

デリバティブでの使いどころ

海外の上場デリバティブの取引所には、注文の入力と、約定の通知の写しの配信に FIX を使うところがあります。Cboe Futures Exchange は、先物とオプションの注文入力とドロップコピーに FIX を使います¹²。

ドロップコピーは、取引所が、参加者の注文と約定に関するメッセージの写しを、別の接続に配信する仕組みです。ASX 24 の仕様書は、同じ会社の複数のユーザーの約定をまとめて受け取ることと、清算参加者が顧客の約定をまとめて確かめることを、使い方の例に挙げています¹³。ASX 24 では、ドロップコピーの Execution Report は、注文の発注者に送る Execution Report と同じ業務の情報を持ち、CopyMsgIndicator（797）が Y になります¹⁴。

店頭デリバティブでは、5.0 SP2 の拡張パックが、米国商品先物取引委員会（CFTC）のトレード・キャプチャの要件（拡張パック 77）に対応しました。清算の対象にする標準化されたクレジット・デフォルト・スワップの識別（拡張パック 83）にも対応しています¹⁰。FIX Trading Community は、FIX が CFTC などの規制の報告にも使われていると説明しています¹⁵。

FpML、CDM との関係

FpML は、店頭デリバティブの取引の情報を表す XML の標準です¹⁶。FIX は、注文や約定のメッセージをやりとりする標準です。FpML の中身はFpMLで扱います。

FIX 4.4 には、2 つの標準をつなぐ方法があります。銘柄を表す Instrument の項目の中に、FpML の商品の仕様を入れられます。SecurityID（48）に FpML の仕様の XML か、その場所を示す URL を入れ、SecurityIDSource（22）に I（ISDA/FpML Product Specification）を指定します¹⁷。

ISDA CDM は、取引とイベントのデータモデルで、FIX、FpML、ISO 20022 などの標準の形でも表して、受け渡しや保存ができます¹⁸。

約定を取り込むときの注意

FIX で届く約定の通知には、同じ通知が複数回届く場合、番号が飛ぶ場合、後から訂正や取消が届く場合があり、扱いは仕様で決まっています。取り込んだ約定を入力し、確認する業務は約定の管理で扱います。

重複と再送

FIX には、再送を表す印が 2 つあります。PossDupFlag（43）が Y のメッセージは、同じ番号と同じ内容の再送です。受け取る側は、その番号のメッセージをすでに受け取っていれば無視し、まだなら通常どおり処理します¹⁹。再送のときに変わる項目は、CheckSum、OrigSendingTime、SendingTime、BodyLength、PossDupFlag に限られます²⁰。

PossResend（97）が Y のメッセージは、同じ内容を新しい番号で送り直したものです。受け取る側は、注文番号のような項目を調べて、受け取り済みの内容かどうかを判断します¹⁹。約定の通知なら、ExecID が手がかりの 1 つです。東京証券取引所の CONNEQTOR（気配提示の依頼と提示を扱うサービス）の接続仕様書には、参加者のシステムが PossResend を Y にして送った Execution Report の扱いが定められています。ExecID が受信済みの値なら、CONNEQTOR は受信済みと判断して破棄します²¹。

受信した番号が期待より小さく、PossDupFlag もない場合は、重大な誤りです。セッションを切って、人が対応することが強く勧められています²²。

欠落と Resend Request

受信した番号が期待より大きいときは、メッセージの欠落です。受け取る側は Resend Request（MsgType が 2）で再送を求めます。BeginSeqNo（7）に欠落の最初の番号、EndSeqNo（16）に最後の番号を入れ、「それ以降すべて」を求めるときは EndSeqNo を 0 にします²³。欠落した番号の後のメッセージは、欠落分を受け取る前に処理しません²⁰。

再送する側は、元の番号のまま PossDupFlag を Y にして再送するか、再送しないメッセージの番号を Sequence Reset（MsgType が 4）の Gap Fill で飛ばします。Logon や Heartbeat のような管理のメッセージは再送せず、Gap Fill で飛ばします²²。再送された約定の通知は、PossDupFlag が Y でも、元の通知を受け取っていなければ通常どおり処理します¹⁹。

訂正と取消

FIX 4.4 以降では、約定の通知の種類を ExecType で分けます。新しい約定は F（Trade）です。誤って報告された約定を取り消す通知は H（TradeCancel）、直す通知は G（TradeCorrect）です。いずれも、元の約定の ExecID を ExecRefID（19）で指します²⁴。FIX 4.2 では、約定は ExecType の 1、2 で表し、取消と訂正は ExecTransType で分けます¹¹。

訂正を複数回行うときは、ExecRefID が最後の訂正の通知の ExecID を指します。取消の通知を取り消すことはできません。取り消した約定を直したいときは、G ではなく F の通知を新たに送ります²⁴。

訂正の通知の CumQty、LeavesQty、AvgPx は、訂正の時点の注文の状態です。元の約定の時点の値ではありません。同じ日に約定を取り消すと、CumQty が取り消した数量だけ減り、LeavesQty が同じだけ増えて、注文の数量は変わりません²⁴。

次の例は、ログオンから約定の通知、番号の欠落、再送、取消、訂正までの並びです²⁵。

R>S 35=A|34=1|98=0|108=30|
S>R 35=A|34=1|98=0|108=30|
S>R 35=8|34=2|37=ORD-000123|17=EXEC-000789|150=F|39=1|32=4|31=1234.5|14=4|151=6|
S>R 35=8|34=4|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4|
R>S 35=2|34=2|7=3|16=0|
S>R 35=8|34=3|43=Y|122=20261021-01:23:46.000|37=ORD-000123|17=EXEC-000790|150=F|39=2|32=6|31=1235.0|14=10|151=0|
S>R 35=8|34=4|43=Y|122=20261021-01:23:47.000|37=ORD-000123|17=EXEC-000791|150=H|19=EXEC-000789|39=1|14=6|151=4|
S>R 35=8|34=5|37=ORD-000123|17=EXEC-000792|150=G|19=EXEC-000790|39=1|32=6|31=1235.5|14=6|151=4|

約定の通知の識別子

約定の通知には、次の 3 つの識別子があります。どの識別子を、重複の判定や、元の約定の特定に使うかは、接続先の仕様書で確かめます。

ExecID が一意でなければならない範囲は、1 取引日の中か、複数日にわたる注文の存続期間の中です。複数日の注文を受ける会社では、OrderID と ExecID に日付を含めて、日をまたいでも一意にする設計があります²⁶。

接続先による違いもあります。ASX 24 のドロップコピーでは、ClOrdID は元の接続で入力された値で、複数の接続の活動をまとめて報告する接続では、一意とは限りません。取引所が付ける OrderID は一意で、注文の特定に使えます¹⁴。

銘柄、口座と持ち高の例

銘柄は、Symbol（55）か、SecurityID（48）と SecurityIDSource（22）の組で表します。SecurityIDSource には、ISIN（4）、取引所のシンボル（8）、ブルームバーグのシンボル（A）などの値が決まっています。先物の限月は MaturityMonthYear（200）に YYYYMM の形で入ります⁵。口座は Account（1）です。

通知を受けて持ち高を更新する処理を、F は加算、H は打ち消し、G は置き換えとする、取り込む側の設計の架空の例で考えます。先物の買い注文 10 枚に対して、上のメッセージの並びと同じ 4 通の通知が届くものとします。FIX の仕様が定めるものではありません。

G の通知は枚数を変えず、約定の価格を 1235.0 から 1235.5 に直します。届いた順に処理すると、EXEC-000791 の取消が EXEC-000790 より先に届いたとき、持ち高は一時的に 0 枚になります。FIX の仕様では、欠落した番号の後のメッセージを、欠落分より先に処理しません²⁰。

日本取引所グループのデリバティブ

日本取引所グループ（JPX）は、大阪取引所のデリバティブの売買システムを J-GATE と呼びます。J-GATE への接続方式には、取引用の API と OUCH があります。API は、相場情報の受信と、注文の発注、訂正、取消ができる共通の接続方式です。OUCH は、注文の発注、訂正、取消に特化した方式です。相場情報は、API か ITCH で受け取ります²⁷。

J-GATE が OMnetAPI で配信する、ユーザーごとの注文と約定に関する配信メッセージのデータは、ドロップコピーのデータとして提供されます。ドロップコピーのデータを使えるのは、大阪取引所の取引参加者だけです²⁸。JPX のこれらのページが挙げる接続方式は、API、OUCH、ITCH、OMnetAPI で、FIX は含まれていません。

この記事が書いていないこと

FIX の全メッセージと全項目の定義、各接続先の仕様の違い、国内の証券会社経由の約定の連携は、この記事では扱いません。