注文経路の内側で行う pre-trade リスクチェック

注文がゲートウェイに届く。取引所へ出す前に、そのアカウントが送ってよいかを何かが判断しなければならない。その判断は、まったく問題のない圧倒的多数を含むすべての注文で走る。つまりそのコストは、拒否される注文だけでなく通常のトラフィック全体が負担する。

まず名指しすべき制約はそれだ。注文経路に置かれたリスクチェックは、発注にかかる税金である。技術的な問いは、チェックをいかに賢くするかではない。トレーダーが感じない程度に小さく、それでも拒否すべき注文はきちんと拒否できるだけ正直に作るにはどうするか、である。

注文経路に本当に置くべきもの

ホットパスが答える問いはひとつだけだ。このアカウントについて今分かっていることを踏まえて、この注文を今すぐ送ってよいか。その問いに答えるチェックは中に残る。別の問いに答えるチェックは外へ出す。

• ポジションとエクスポージャーの上限 ― 銘柄・グループ・アカウントでの結果ポジションを、設定された上下限と突き合わせる
• 証拠金または買付余力 ― 現在の証拠金モデルのもとで、そのアカウントにまだ余地があるか
• fat-finger の上下限 ― 注文数量、想定元本、基準値からの価格乖離。取引所より先に打ち間違いを捕まえる
• 銘柄とアカウントの状態 ― 取引停止、アカウント制限、クローズのみ、このアカウントで有効化されていない商品
• kill switch の状態 ― 上のすべてを上書きするひとつのフラグ
• 取引所が備えていない場合の、重複注文と自己約定のガード

それ以外はすべて経路の脇で、同じ状態の上で、注文を止めずに走る。ホットパスが強制する上限値に情報を与えはするが、トレーダーと取引所の間には座らない。

• ポートフォリオのリスク分析 ― シナリオ計算、ストレステスト、アカウント横断の相関エクスポージャー
• パラメータ変更時の証拠金モデルの再評価、および板全体に触れるあらゆる再計算
• 監視とパターン検知。ホットパスが意図的に持たない履歴を必要とする
• レポーティング、照合、そしてデータベースや外部サービスと話すものすべて
• 与信とカウンターパーティ審査。性質上、より遅い時間軸で動く

ポジション状態がどこにあるか、そしてなぜデータベースは経路に無いのか

pre-trade チェックが必要とする状態 ― 現在のポジション、有効注文、使用済みおよび利用可能な証拠金、上限の設定 ― は、その判断を下すプロセスのメモリの中にある。データベースの前のキャッシュでもなければ、ネットワーク越しでもない。プロセスの中だ。

理由は速度だけではない ― もっとも、クエリはローカル配列の参照より桁違いに高い。理由は正しさだ。データベースは書き込まれた時点のポジションを持つ。リスクチェックが必要とするのは、直前に送ってまだ約定も確認応答も永続化もされていない注文を含めたポジションである。ストレージから読めば、自分自身のフローがすでに追い越した過去に対して照合することになる。

実際のところ、それは低 latency のコンポーネントが一般にそうであるように、プロセスの形を決める:

• アカウントごとに書き手はひとり。アカウントはリスクインスタンス間でシャーディングされ、アカウントの状態が競合することはなく、注文経路でロックは取らない
• フラットで事前確保された構造 ― セッション開始時に解決した、アカウントと銘柄 ID で引く固定長配列。注文ごとに作る文字列のハッシュ引きではない
• 判断経路ではアロケーションも I/O も、ブロックするロギングもしない。監査記録はキュー経由で別スレッドに渡す
• 再起動なしに変わる設定は、不変のスナップショットとして丸ごと差し替える。チェックが更新途中の上限値を読むことはない

データベースはポジションが記録される場所だ。ポジションが分かる場所ではない。

全走査ではなく差分での再計算

アカウントのエクスポージャーと証拠金を完全に再計算すると、すべてのポジションとすべての有効注文をたどることになる。そのコストは板の大きさとともに増えるため、最も多く取引する顧客ほどリスクチェックが遅くなる。だからホットパスは再計算しない。差分を適用する。

アカウントは走行中の集計値を持つ ― 銘柄別・グループ別の純および総エクスポージャー、使用証拠金、発注中の想定元本。入ってきた注文はその集計値に小さな変化をもたらし、変わった値を上限と比べ、注文は受理されるか拒否される。仕事量はポートフォリオではなく注文に比例する。

• 送信時に、その注文の最悪ケースの影響を集計値に対して予約する。飛行中の2つの注文が同じ残り枠に同時に収まることはない
• 拒否・キャンセル・失効では予約を解放する。約定では予約を、実現したポジション変化で置き換える
• 部分約定はその両側を1ステップで調整する。この種のエンジンのバグは、実際そこに最も多く住んでいる
• ネッティングとグルーピングの規則は、注文ごとではなく銘柄の読み込み時に解決する。だから差分計算はわずかな算術演算で済む

完全な再計算は依然として行われる ― 定期的に、証拠金パラメータが変わったとき、そして差分計算の結果に対する定期的な自己点検として。それは経路の外でコピーの上を走り、その結果は差し替えられるか、不一致として報告される。真の状態から黙って乖離していく差分状態は、チェックが無いよりたちが悪い。だからこの比較は任意ではない。

kill switch は独立した経路

kill switch は、すでに何かが壊れているときにこそ使われる。だからこそ、壊れている当の仕組みの上に載せて作ることはできない。それ自身のルールを持つ、独立した経路である。

• チェックの冒頭で、ポジション状態・証拠金・銘柄データに触れる前に読む、ひとつのアトミックなフラグである ― だからそれらが古くても、欠けていても、壊れていても機能する
• 作動の引き金は複数あり、互いに独立している。オペレータの操作、自動条件、リスク状態が依存するマーケットデータや約定フィードの喪失
• 安全側に倒れる。リスクプロセスが自分の状態の正しさを確認できなければ、ゲートウェイはスイッチが作動しているものとして振る舞う
• 適用範囲を持つ ― 全社、1つのデスク、1つのアカウント、1つの戦略。すべてを止めることしかできないスイッチは、使われるのが遅すぎるからだ
• 作動は1つの操作と1つの確認で済み、設定のデプロイではない。解除は意図的に行い、必ず記録される

新規注文を止めるのは簡単なほうの半分だ。難しいのは、すでに取引所に置かれている注文にスイッチが何をするかである。送信経路を止めたままで、クオートの引き上げと有効注文のキャンセルができなければならない。そのキャンセル経路には専用のテストが要る。使われるのは平常時ではなく、最悪の日だからだ。

再起動と、状態の戻り方

メモリ上の状態は、永続的な記録から導かれたビューである。だからこそ再起動を生き延びられる。リスク状態を変えるすべての事象 ― 注文の受理、予約の解放、約定の反映、上限値の変更、スイッチの作動 ― は、下流で実行される前にローカルマシンのジャーナルへ追記される。

• 起動時にプロセスはジャーナルを再生して集計値を再構築し、その後ポジションと有効注文について取引所とクリアリングの drop copy と照合する
• 照合が終わるまで、そのアカウントは取引可能にならない。ポジションを把握している最中に注文を受け付けるリスクエンジンは、リスクエンジンではない
• 再生した状態と取引所側の見え方が食い違えば、そのアカウントを停止してアラートを上げる。どちらか一方を黙って優先して片付けることはしない
• ホットスタンバイは同じジャーナルを追随するため、フェイルオーバーはコールドな再生ではなくウォームな状態から復旧する。スタンバイは理屈ではなく定期的に昇格させて検証する

復旧時間は板の大きさではなく、ジャーナルの長さと drop copy の可用性で決まる。そして不明点があったときの振る舞いは常に同じ ― そのアカウントの取引を拒否する。

この設計が与えないもの

限界は率直に述べておく価値がある。このアーキテクチャがそもそも合うかどうかを決めるのはそこだからだ:

• チェックの正しさは約定フィードの正しさを超えない。drop copy や執行報告が遅れればエクスポージャーは過小評価される。正しい対応は、古い状態のまま取引を続けることではなく、保守的な上限に落とすかスイッチを作動させることだ
• 本質的に加算的でないポートフォリオ証拠金モデルは、差分評価になじまない。うまくいくのは、経路上では保守的な差分の上界を使い、完全なモデルは経路の外で回すやり方だ。代償として、完全なモデルなら通ったはずの注文がいくつか拒否される
• スイッチが守るのは自分のフローからであって、市場からではない。すでに保有しているポジションのギャップやスリッページは防げない
• プロセス内に状態を置くとは、リスクエンジンと注文ゲートウェイが運命を共にするということだ。latency を買う代わりに、両者を独立にスケールさせる自由を失う
• アカウント単位の単一書き手シャーディングは、アカウント横断の上限を難しくする。全社的なチェックには、それ自身の鮮度の遅れを抱えた低速な集計層が必要になる
• データベースに頼るチェックより運用の手間は多い。ジャーナル、照合、スタンバイ昇格の訓練。注文発注が latency に敏感でないなら、この複雑さを買う価値はない

amBrain はこの種の pre-trade リスク経路を、ブローカーや自己勘定業者向けに、ホットパスを Rust で書いて構築している。チームは2019年からアルメニア・エレバンでトレーディング基盤に取り組んできた。