FinTechとトレーディング
ブローカーの注文管理システム:ベンダーの OMS を買うか、トレーディングプラットフォームに備わったものを拡張するか、自社で作るか
ブローカーにとって注文管理システムが何をするのか、それが EMS やトレーディングプラットフォームに組み込まれた注文処理とどう違うのか、EU と米国のルールが注文の記録に何を求めているのか、そしていつ買い、いつ拡張し、いつ作るべきかを解説する。
執筆:amBrain読了9分
この記事の内容
ブローカーの注文管理システム(OMS)とは、顧客の注文を、届いた瞬間から約定または取消しまで扱うソフトウェアである。注文をチェックし、取引施設や別のブローカーに送り、その行方を追い、すべてのステップを記録する。OMS は、ベンダーから買うことも、トレーディングプラットフォームにすでに備わっている注文処理を拡張することも、自社で作ることもできる。どれが正しい選択かは、注文がいくつのプラットフォームと取引施設を通るのか、そして注文の扱い方が自社の売り物の一部なのかどうかで決まる。どれを選んでも義務は変わらない。ソフトウェアを誰が書いたかにかかわらず、リスクチェックと記録については自社が責任を負う。
短い答え:顧客の大半がトレーディングプラットフォームで取引していて、足りないのが一つのリスクルールや一つの新しい流動性プロバイダーのような狭い部分なら、そのプラットフォームを拡張する。ベンダーのほかの顧客とほぼ同じように注文を扱っていて、多くの取引施設への接続がすぐに必要なら、ベンダーの OMS を買う。注文が複数のプラットフォームから届き、それらにまたがって記録とリスク上限をそれぞれ一つにまとめたいなら、自社で作る。どの道を選んでも、注文履歴のすべてをエクスポートできるようにしておく。
注文管理システムは、ブローカーのために何をするのか
注文は、どこから来ても同じステップを通る。モバイルアプリ、デスクトップのターミナル、API を通じた顧客自身のソフトウェア、あるいはディーリングデスクへの電話である。OMS は、自社のシステムのうち、そのステップを実行する部分だ:
- 注文を受け付け、最後まで変わらない ID を付ける
- プレトレードのチェックを行う:十分な資金や証拠金があるか、数量と価格が上限の範囲内か、その銘柄を取引する許可があるか
- 注文を取引所、流動性プロバイダー、または上流のブローカーに送る
- 注文の状態を追跡する。有効(市場でまだ出ている状態)、一部約定、約定、取消し、拒否といった状態と、その途中で顧客が加える変更である
- 約定のたびに、それを顧客の口座と自社のバックオフィスに返す
- すべてのステップを時刻とともに記録する
送信のステップでは、FIX がよく使われる。ブローカーと取引施設が、注文と約定をやり取りするのに使う共通のメッセージ形式だ。FIX を管理する FIX Trading Community は、FIX プロトコルを「金融機関が取引情報をやり取りできるようにする、グローバルでオープンな標準」と説明している。その取引メッセージの一覧は、「注文と執行」から始まる。接続を予定している取引施設とブローカーのそれぞれに、どの FIX バージョンとどのメッセージを想定しているかを尋ねる。
OMS は、EMS や自社のトレーディングプラットフォームとどう違うのか
この記事でいう OMS とは、注文の正式な記録、つまり各顧客が何を求め、その注文がどうなったかを保持するシステムである。執行管理システム(EMS)は、トレーダーが市場で注文をさばくための道具だ。たとえば、大きな注文を小さな注文に分けたり、執行アルゴリズムに渡したりできる。ベンダーは二つの名前をあまり厳密に使い分けておらず、両方の仕事をこなす製品も多い。
リテールブローカーの多くは、すでに三つ目の種類を持っている。トレーディングプラットフォームに組み込まれた注文処理だ。プラットフォームのサーバーが注文を受け付け、口座をチェックし、リスクをブローカーの手元に残すか、ゲートウェイと呼ばれるコネクターを通じて注文を外に流す。MetaQuotes はブローカー向けのページで、MetaTrader 5 のゲートウェイは「ブローカーが即座にリスクをヘッジできるようにする」と述べている。多くのブローカーにとって、誰もそう呼んでいなくても、この組み込みの注文処理こそが OMS である。
規制当局は注文の記録に何を求めているのか
時刻を含む、すべての注文の完全な記録と、顧客の注文を公正に扱う手続きである。米国のルールはさらに、マーケットアクセスを持つブローカーに対し、リスク管理を自らの手に置いておくことを求めている。
EU では、MiFIR の第25条が、投資サービス業者は「自らが行った金融商品のすべての注文とすべての取引に関する関連データを、5年間、所轄当局が利用できるように保持しなければならない」としている。MiFID II の第28条は、顧客の注文を執行する業者に対し、「ほかの顧客の注文や投資サービス業者自身の取引上の利益と比べて、顧客の注文を迅速、公正かつ敏速に執行するための手続きと体制」を求めている。
最良執行に関する MiFID II の第27条は、業者は求めに応じて顧客に対し、「その注文を投資サービス業者の執行方針に従って執行したこと」を示せなければならないとしている。それを示すには、各注文がいつ届き、どこへ送られたかの記録が必要になる。
米国では、SEC Rule 17a-3 が、ブローカー・ディーラーに対し、執行されたかどうかにかかわらず、各委託注文の記録を残すことを求めている。同規則は、この記録をメモランダム(memorandum)と呼ぶ。そこには、「注文または指示の条件」、「注文を受けた時刻、入力の時刻、執行された価格」、そして「実行可能な範囲で、執行または取消しの時刻」が示されていなければならない。
FINRA は、米国のブローカー・ディーラーを監督する自主規制機関である。SEC Rule 613 は、FINRA と米国の全国証券取引所に対し、CAT と呼ばれる統合監査証跡(consolidated audit trail)の計画を共同で提出するよう求めている。FINRA のページは、これを「米国のすべての市場において、取引所に上場されたすべての株式とオプションについて、すべての注文、取消し、変更、取引の執行を収集し、正確に識別する」統合監査証跡だと説明している。同じページには、「全国証券取引所または全国証券業協会の各会員は、CAT NMS Plan のすべての規定を遵守することが求められる」とある。
SEC Rule 15c3-5 は、マーケットアクセスを持つブローカー・ディーラーに対し、「リスク管理のための統制と監督手続きの体制を確立し、文書化し、維持する」ことを求めている。そうした統制は、自らもブローカー・ディーラーである顧客についての限られた例外を除き、「ブローカーまたはディーラーの直接かつ排他的な管理下に置かれなければならない」。ソフトウェアは買えても、上限は自社の管理下に置いたままにする。
この記事の出典はすべて2026年11月2日に閲覧した。扱っているのは EU と米国のルールだけである。ほかの国にはそれぞれ独自のルールがある。
どの道を選んでも変わらないものは何か
こうした仕事は、どの道にも存在する。変わるのは、誰がソフトウェアを書き、運用するかだ:
- すべての新規注文と、有効注文に対するすべての変更についてのプレトレードのリスクチェック。上限は自社のリスク担当者が設定する
- 監査証跡:すべての注文、変更、取消し、約定、拒否を時刻とともに記録し、自社に適用されるルールが求める期間だけ保存する
- 各取引施設と上流のブローカーへの FIX 接続。どの接続も、相手側の会社と一緒に設定し、テストする
- 照合:自社の注文、約定、ポジションを、取引施設、ブローカー、清算会社の記録と毎日突き合わせ、すべての差異について理由を明らかにする
ベンダーやプラットフォームがこの仕事の一部を代わりに担うことはできるが、そのすべてについて責任を負うのは、やはり自社である。
ブローカーがベンダーの OMS を買うべきなのはどんなときか
自社の注文フローがベンダーのほかの顧客のものと似ているなら、買う。典型的な兆候は次のとおり:
- 取引する資産クラスと注文の種類に、製品がすでに対応している
- 多くの取引施設やブローカーへの接続がすぐに必要で、ベンダーがすでにそれらの接続を運用している
- チームが小さく、取引施設が仕様を変えたときに接続を保つ作業はほかの誰かに任せたい
- 自社の強みは、注文の扱い方ではなく、価格設定やアプリにある
その代わりに手放すのは、主導権である。自社のルールはベンダーの設定に合わせなければならず、必要な機能は、ベンダーがそれを計画に入れるか、自社が個別開発の費用を払うまで待つことになる。
トレーディングプラットフォームの注文処理を拡張すべきなのはどんなときか
顧客の大半が一つのプラットフォームで取引していて、その注文処理が機能しており、欠けているのが狭い一部分だけなら、拡張する。その一部分とは、プラットフォームの設定では表現できないリスクルールかもしれないし、新しい流動性プロバイダーへの経路や、自社のバックオフィスとの連携かもしれない。プラットフォームの開発元は、そのために API と呼ばれるプログラミング用のインターフェースを提供している。MetaQuotes は、同社の「Gateway API は、MetaTrader 5 をほかの取引システムと統合し、独自のデータフィードを作成するために使われる」と述べている。Spotware は、自社の cTrader プラットフォームの Manager's API について、ブローカーに「cTrader サーバーのエンティティに対する完全な制御」を与えるものだと説明している。
拡張する前に、次のことを確かめる:
- プラットフォームが誰のライセンスで動いているのか、そしてそのライセンスが終わったら自社の追加機能がどうなるのか
- プラットフォームの開発元が新しいバージョンをリリースするたびに、自社の追加機能がどうテストされるのか
- そのインターフェースが、一日の終わりのレポートだけでなく、すべての注文とすべての変更を、自社のコードが対応できるうちに渡してくれるかどうか
あるプラットフォームのインターフェース向けに書いたコードは、別のプラットフォームには移せない。顧客に二つ目のプラットフォームを提供するつもりなら、リスクチェックや注文の記録のような共通の部分は、両方のプラットフォームの外に置いておく。
自社で OMS を作る価値があるのはどんなときか
自社で作ることが報われるのは、次のような場合である:
- 注文が複数のプラットフォームやチャネルから届き、そのすべてにまたがって、すべての注文の記録とリスク上限をそれぞれ一つにまとめたい
- 注文の扱い方が自社の売り物の一部になっている。たとえば、独自のルーティングルールや、試した製品が対応していない注文の種類だ
- ユーザー、注文、接続ごとの料金が、自社のシステムを運用するチームのコストを上回るまでに膨らんでいる
- 注文履歴のすべてを、自社が管理する構造で、自社のデータベースに置きたい
- プラットフォームや取引施設を追加したり変えたりする予定があり、そのたびに記録を作り直したくない
それは、すべてを置き換えることを意味するとは限らない。多くの場合、それは顧客チャネルと取引施設のあいだに置く一つの層で、注文の記録とリスクチェックを担い、既存のプラットフォームはその下にそのまま残る。
仕事はローンチで終わらない。取引時間中にアラートに対応し、各取引施設の仕様が変わるたびにそれに追随する人が必要だ。その担当者がおらず、採用する予定もないなら、まずは買うか拡張する。
OMS ベンダーと契約する前に、何を確認すべきか
- 注文履歴と監査証跡のすべてを、文書化された形式で、いつでもエクスポートできるのか。契約を終えて離れるときには、それにいくらかかるのか
- リスク上限は誰が設定し、変更するのか。自社の画面で自社のスタッフが行うのか、それとも依頼を受けてベンダーのサポートチームが行うのか
- どの取引施設とブローカーがすでに接続されていて、いまほかの顧客に使われているのか。どれがまだ計画段階にすぎないのか
- ユーザー、注文、取引施設への接続の数が2倍になると、料金はどう変わるのか
- OMS や一つの接続が止まったとき、有効注文はどうなるのか。自社のスタッフは、一つの口座または会社全体の有効注文をすべてキャンセルできるのか
- 独自のルールの価格とスケジュールはどう決まり、自社のために書かれたコードは誰のものになるのか
- ベンダーが製品の提供をやめたり価格を改定したりする場合、どれだけ前に通知を受けられるのか
コードとデータを所有するとは、どういうことか
コードを所有するとは、ビルドと実行に必要なものすべてを含めてソースコードを受け取り、それを変更するためにどのチームでも雇えるということだ。データを所有するとは、すべての注文の記録が、自社が管理するデータベースに文書化された構造で置かれていて、規制当局からの求めに応じるのに誰かを待つ必要がないということである。
OMS のコードはベンダーのものであり、プラットフォームはその開発元のものである。自社のデータと、費用を払って加えた追加機能が自社のものになるのは、契約にそう書かれている場合だけだ。自社で作れば、その両方を所有できる。開発会社には、自らが保持するコンポーネントと、それらを自社が使い続けられるライセンスを契約に列挙してもらう。
構築を任せる会社に何を聞くべきか
- システムはどの注文状態を追跡し、一部約定と有効注文の変更をどう扱うのか
- 取引時間中に再起動したあと、システムは有効注文とポジションをどう再構築し、取引を再開する前にそれらを取引施設の記録とどう照合するのか
- どの取引施設とブローカーに、どの FIX バージョンで最初に接続するのか。それぞれとのテストは誰が手配するのか
- リスクチェックはどこで実行され、どれくらい時間がかかり、それはどう計測されたのか
- 注文ごとに監査証跡に何が、どのタイムスタンプとともに書き込まれるのか。システムは、規制当局が求める記録を出力できるのか
- 毎日の照合はどう行われ、差異が見つかったときは誰に知らされるのか
- いま稼働しているシステムで、これが動いているところを見せてもらえるか
amBrain はどこに位置づけられるか
このブログを発行しているのは amBrain である。amBrain は、仕事のこの分野を一行でこう説明している:「amBrain はアルゴリズム取引の基盤を構築する:注文執行、マーケットデータ、プレトレードのリスク管理。」amBrain のウェブサイトには、もう一行こうある:「トレーディングターミナルの開発、注文管理システム、FIX プロトコルによる取引所連携。」
amBrain は2019年からソフトウェアを作っている。顧客との仕事の進め方については、こう述べている:「三つの形態:フルデリバリー、専任チーム、あるいはあなたのチームに入るエンジニア。」所有権についての一文はこうだ:「顧客は、プロダクトとコードの完全な所有権を保持する。ただし、私たちの再利用可能なコンポーネントは除く。」署名の前に、そのコンポーネントを名前で列挙した一覧を求めること。
この記事は事例紹介ではなく、顧客のための仕事についても述べていない。amBrain がいずれかの顧客のために OMS を構築、購入、拡張したとは述べていない。FIX Trading Community、MetaQuotes、Spotware、FINRA は、それぞれが公開しているページから引用しており、この記事は、amBrain とそれらのいずれかとのあいだに何らかの関係があるとは主張しない。amBrain の価格や期間も示さない。
この記事は法的助言でもない。自社に適用されるルールは弁護士に確認する。amBrain が候補リストに入っているなら、ほかのどの会社とも同じ質問をすること。
トピック
- 注文管理
- ブローカレッジ
- FIXプロトコル
- 自作か購入か