バックテストにはどれだけのレイテンシを加えるべきか？私たちのレイテンシをミリ秒単位で計測しました

すべて自社のペーパートレード環境で計測した4つの数字です。1つの戦略、1分足のBTCUSDT無期限契約シグナル、31日間、1,418件の注文。バー確定から取引所が注文を確認するまでの時間の中央値は195 ms。99パーセンタイルは2,970 ms。実現ボラティリティが最も高かった1%の分足では、中央値が840 ms。そして、その前の1年近くバックテストの設定に入っていたレイテンシ定数は0.

このうち3つの数字は退屈です。0が間違いだとは誰もが知っていて、いずれ何かに置き換えますが、その何かはたいてい誰かが勘で決めた定数です。100 ms、250 ms、「保守的にいこう、500」。本当に重要なのは840です。レイテンシが市場の状態によって変わり、しかも遅延が大きくなる市場状態は、シグナルが何かを見つけたと思い込む市場状態と重なることを示しているからです。

195 msの内訳

以下が予算の全容です。各段階の移行時に単調時計のタイムスタンプを記録して測定しました。実行環境はAWSのap-northeast-1インスタンスで、取引所のエンドポイントと同じリージョンです。取引所と同じ場所にサーバーを置かない個人向け環境としては、かなり有利な条件です。

興味深い点に入る前に、2つ押さえておきましょう。1つ目。中央値は足し算になりません。128 + 3 + 11 + 47 = 189ですが、エンドツーエンドの中央値は実測で195です。パーセンタイルは足し合わせられません。各段階のp99を合算してレイテンシを推定すると3,128 msになりますが、実際のp99は2,970です。今回は近い値ですが、各段階が逆方向に相関していると大きく外れます。経路全体を測定してください。

2つ目。最上段を見てください。中央値の予算の3分の2は、取引所からバー確定の通知が届くのを待つ時間です。ネットワークでも、コードでも、注文ルーティングでもありません。取引所は約定を集計してklineを作り、その1分が終わったと判断してから配信します。その配信の前にはキューがあり、同じストリームを購読する全員で共有しています。

840の正体

シグナルが発生した分足の実現ボラティリティを基準に、1,418件の注文を分類すると、分布の様子が一変します。

すべての段階で同時に遅延が悪化し、それが積み重なります。取引所の集計・配信キューにはマッチングエンジンの負荷が反映されるため、約定が11,000件ある分足は、600件の分足より配信が遅くなります。同じ時間帯に自分のプロセスも、より多くの板更新と約定通知を処理するので、通常なら3 msで済む特徴量更新に28 msかかります。REST注文経路は他の参加者の注文殺到と競合し、たまに503エラーと再試行が発生して、それだけで丸1秒失うこともあります。私たちのサンプルでは、シグナル対象バーの約定数とエンドツーエンドのレイテンシの相関係数は0.41でした。非常に強い相関ではありませんが、固定値を台無しにするには十分です。

そして、最初のスクリーニングを通過する戦略の大半は、ブレイクアウト、反転、価格の乖離、清算カスケードを狙います。まさにレイテンシが最悪の区分でシグナルが発生します。1分間に40 bps動いたときだけ発動するモメンタムシグナルは、構造上、常に自分のシステムの最も遅い状態で処理されるように仕組まれたシグナルです。

以前、毎晩ほぼ同じ時刻に発生する3.6秒の外れ値を追いかけて、丸1日費やしたことがあります。原因はlogrotateでした。プロセスが書き込み中の2 GBファイルを同じEBSボリューム上でコピーしながら切り詰め、イベントループを停止させていたのです。市場に落ち度はありませんでした。まず計測し、それから市場マイクロストラクチャを疑いましょう。

約定への影響

待っている間に価格は動きます。ランダムな分足では、中央値の195 msの間にシグナル方向と逆へ動く不利な値動きは平均約1.1 bpsでした。中央値が312 msの上位四分位の分足では5.8 bps。840 msの上位1%の分足では、注文が板に届く前に不利な方向へ約14 bps動きます。

BTC無期限契約では、スプレッドの影響はほとんどありません。84,000の気配値に対して1ティックは0.012 bpsなので、損失の原因はスプレッドを跨ぐコストではなく、不利な値動きです。同じ戦略を中型銘柄の無期限契約に移すと、もう1つの要因が効いてきます。私たちのサンプルでは、最良気配のスプレッドは落ち着いた分足の1.4 bpsから上位四分位では6.2 bpsに広がり、その価格の板の厚みは半分以上減りました。不利な値動き、広がったスプレッド、薄くなった板のすべてが、共通の原因によって同時に損失をもたらします。

同じ31日間を一定の200 msではなく、バーごとに条件付けしたレイテンシでリプレイしたところ、バックテストの平均エントリー価格は3.1 bps悪化しました。その影響は取引の9%にほぼ集中していました。バックテストとペーパートレードのエントリー価格の乖離は4.2 bpsから0.9 bpsに縮まりました。この戦略のインサンプルSharpeは1.7から1.1に下がりました。これが実態を反映した数字で、もともとそうだったのです。

では、設定には何を入れるのか

単一の値ではありません。現在の設定は次のとおりです。

1. 値を設定するのではなく、サンプリングする。シミュレーション上の各注文のレイテンシは、そのバーの活動状況に応じた経験分布から抽出します。約定数と絶対リターンがあれば十分で、どちらも標準的なklineに含まれています。取引所ごと、注文種別ごとに一度フィットし、毎月再フィットします。
2. 裾を残す。対数正規分布にフィットして終わりにしないでください。p99には、滑らかな分布では再現できない再試行の集中発生やGCの停止が含まれます。p95を超える範囲では再サンプリングした裾を使い、経験分位点を維持しています。
3. キャンセルにもレイテンシを適用する。ストップ注文の置き換えもヘッジ注文のキャンセルも、同じ遅延の影響を受けます。相場が速く動くと、キャンセルと約定が競争になります。シミュレーターが即時にキャンセルするなら、そのリスクモデルは現実を反映していません。
4. 古さのガードを設け、シミュレーションにも反映する。私たちのシステムは、到着時点でバーが1.5秒以上前のシグナルを破棄します。これは実際の挙動であり、実際にコストも伴います。取引がひそかに除外されるため、バックテストでも同じ取引を除外しなければなりません。
5. ペーパートレードの結果で再調整する。実測値を得られるのがペーパートレードです。注文ごとに4つの段階のタイムスタンプを記録し、シミュレーターの想定と分布を毎週比較してください。

この種の誤りに共通するのは、シグナルを動かしている同じ状態変数の関数である執行パラメーターを、独立した定数として扱うことです。手数料は安定し、ファンディングも安定しますが、レイテンシはそうではありません。今回の話から数字を1つだけ覚えるなら、比率を覚えてください。私たちのp99は中央値の15倍で、シグナルの発生時刻はp99側に偏っています。

4つの段階を計測してください。午後の作業で済み、パラメーター探索をもう1週間続けるより、戦略について多くのことが分かります。