今回は、ディーリングモデルとリスクというタイトルで一部【第214回】と二部【第215回】にわけ、その後のストレステストのコラムでも二部【第216回】、【第217回】に分けて、計4部でお送りする。

---

1.ディーラーによるカバーと評価

---

２０年〜１５年前のように人が客の注文を一件ずつさばいているときはそれでいいが、秒間何百件も注文が押し寄せる時代になってからは、それらをいちいち人が判断してさばくことは不可能なわけで、いまどきのディーラーは、数秒、数分ごとぐらいにブックにため込まれたポジション情報をもとに今全部カバーするか、一部カバーするか、あるいはまったくしないか、という判断をし続けることになる。それにより一日を締めたとき、仮に全部をSTP（ＩＥもでるでもＥＥモデルでもいいとして）でカバーしたとしたら実現していたであろう平均ピップスを凌駕しているのであれば、このディーラーは“アルファ収益を生み出している”と評価でき、このカバー手法が最適であると、まずはいえるかもしれない。問題はそれであらゆる市場の動きに対応できるのか、再起不能になるような損失をこうむるリスクはあるのかないのかという分析をどうすればいいのかである。とりあえずリスクについては後段に譲りまずは評価の話。

---

理論的に導かれる先付STPを前提とする自動カバーの平均収益ピップスをファンドになぞらえてここでは“ベータ収益”と呼び、それを凌駕した分を“アルファ収益”と呼ぶことにする。為替には株式市場と違いベンチマークがないのでファンド運用評価で使われるこれらベータ、アルファの意味とは違うが、わかりやすいのでそれになぞらえる。

理屈は単純でこのアルファが恒常的に出せないのならそのディーラーは利益に貢献していないので、だれかと交代するか、やり方を見直すか、自動カバーに方針を変更するかという検討が始まるべきであるが、課題となるのは、“もしも先付STPでやっていたとしたら”というシミュレーションをする仕組みが業者にあるのかという点である。この手の対照区シミュレーションは毎日行われることが望ましい。そうすることでディーラーに対して公正な凌駕すべき目標、プレッシャーを与えることになる。さらに、できるならばそのシミュレーションによる仮想損益が、彼らが見ているキャッシュブロッターの実際のディーリング損益の横にリアルタイムで表示されるぐらいにすると理想的である。これによりディーラーは常にベータ収益を超えるアルファをリアルタイムで出しているかどうかがわかる。これ自体システム的に実装することはさほど難しくはない。ディーラーもこのようなまさにベンチマークがあったほうが自分のディーリングのコントロールがしやすい。たとえて言えば、棒高跳びでバーがあるほうが目標とする高さを超えて飛びやすいのと同じである。

---

比較対象を先付STPとし、EEモデル（後付け）にしないのは、あくまでも日本の業者は市場リスクを最小にする手段（カバーモデル）としてこれを採用するだろうという想定による。EEモデルも検討対象であるとするなら、それもシミュレーションに加えることになるが、これは実装が難しい。どちらにしてもそれらは仮想的にしか計算できないので、あくまでも理論的ベンチマークとなる。

---

2.自動カバー

---

2.1先付STP

---

まず単純なのは、客の注文をマリーせず一件ごとにカバーに出すモデル。ここでは少しでもマリーするとそれはSTPとは言わないこととする。このモデルは、想定するマークアップ分がほぼ理論どおりに実現されるから、相場が安定しているときは気持ちよくかつ安全に働く。ただし、カバー側で得られる現実的なスプレッドよりも広いスプレッドを顧客側に提示しないと理論通りに実現されていくのは「損失」になるという言わずもがなの欠点がある。仮に顧客向けのスプレッドが十分広いとしても、先付のためもくろんでいるマークアップ分をきっちり確保してカバーができるとは限らないので、相場が荒れれば業者の有利、不利どちらかにずれることがある。その時のスリッページを客にしわ寄せするか、業者が呑むかという点で、「許容スリッページ」の扱いや、「約定拒否」のロジック、ロスカット注文時の約定価格決定ロジック等において様々なアプローチ（見ようによっては試行錯誤）がなされている。強制ロスカットによる成行き注文にどういう理屈で約定価格を与えるか、そしてどうやってそのカバーをとるかについてはそれだけで一つのテーマになるので、それは次回以降に譲るとして、ここでは、先付STPはディーリング収益を安定化させるにはいい手段だが、色気は求められないし、スプレッドに関してその業者がカバー側（LP側）から平均的に取りうるベストスプレッドより狭いスプレッドを客に提供することは収益構造上困難になる。また、千ドル等の少額の取引を提供していると、それをそのままLPへカバーとして出すのはビジネス的にも嫌がられるのでどうしてもマリーする必要が出てくる。

---

2.2トリガーカバー

---

先付により客から放り込まれるポジションに対して一定のトリガー条件をセットし、それがヒットすると、その時点での全量、もしくは一定量をカバーに出すというやり方である。あるいは、ポジションや、損益ではなくて、５分毎とか、１０分毎とかの「時間」でトリガーを発動することもあるかもしれない。一日一回EOD時点では必ずスクエアにするというのもこれに属するとする。

客に千ドル単位の取引を提供しながら先付STPをするとLPに対してやたらと細かいチケットを投げつけるため、チケットコストが上がってしまう。当然互いにできれば避けたい。そうなると、ポジションが１０万ドルぐらいまでたまったらカバーしようとなる。あるいは百万ドルまでため込もうとするかもしれない。ではそのトリガー条件にヒットするまでの間、客の売りや買いをマリーしている過程でどれくらい業者は損益の揺れを放置しているのかを考えなくてはならないのだが、これも前章と同じでそれをバックテストによって常に評価分析するファシリティがないと難しい。時々エンジニアがSQLを駆使してデータを解析するというのではなくて（これは私も実際やったがとてつもなく手間暇がかかる）、恒常的にかつリアルタイムに近い状態でそれをやり続ける運用体制がほしい。そうしないと何がよくて何がいけないのかがわからないし、そういう現象は一か月もすると全然違う様相を呈することがあるので結果の普遍性が担保できない。

業者が取引相手として対峙する個人投資家の一群はそれを一つの意志あるエンティティとしてとらえてみれば“極めて気まぐれな、それでいて頑固なダークプール”である。ここでも先付STPをしていたらどうであっただろうかというシミュレーションを行うことは推奨したい。

続く>>[第215回] ディーリングモデルとリスク（2の2）へ

---

---