業者が客を追い出すとき（前半）
この問題は以前から気になっている。かつて一度ここでも少し触れたことがある。HFTの存在がだんだんと大きくなるにつけ、こうした追い出しにからむ事例は海外でもたまに聞くことがあるが、米国を例に挙げれば、米国という文化的特殊性から訴訟リスクの高さや、業界全が規制当局の強い方針のもとＥＥモデル化し、かつＳＥＦ制に大きくシフトしたことによりこの手の問題はあまり表面化しているようには見えない（というより、ＥＥモデルにはこの手の問題は発生しえない）。
昨今投資家のIT技術力も上がり、提供するシステムの裏を突くような注文を投げつけてくるケースもあり、業者としては頭の痛い問題である。業者ごとに様々な対応がされているのだろうが、今回はこの問題をどうとらえるべきかという観点からその中身、実態について考えてみた。
私の論点は以下の４つに集約される。
１）取引約款等の事前合意内容
そもそもどういう契約を結んでいるか
２）“損害をこうむる”の定義
なぜ締め出したいのか
そこに客観性はあるか
透明性、公正性の観点から検証しているか
店頭取引の本質
３）技術的な客観性
具体的に証拠を出せるか
判断する人間の金融知識、常識、技術力等のリテラシーは十分か
４）業者としての矜持（プライド）
業者としての品位、プライド、レベル感、市場からの信頼は考慮するか、されるべきか
じぶんの会社や商品に対する情熱
１）取引約款等の事前合意内容
各社この問題への対応としては、契約書上で、いわゆる「ツール取引」をおこなったときは強制的に口座閉鎖する権限を業者側が持つというような約束事が書いてあるものだが、その定義にあいまいさを感じることがままある。実際にその条項を行使する前提があるなら、細かく定義する必要性があるのだが、そこまで踏み込んでいる契約書はどれくらいあるのだろう。（私も細かくは見ていないので、これから見ていかなくては・・・）
単純に考えれば、まず「ツール取引」とはなんだろう。個人的にはこの言葉は奇異に感じる。問題の本質から考えれば、「業者側が投資家に提供する取引システム、俗に取引チャネルとも呼ばれ、一般には、ウェブブラウザー、リッチクライアント、スマホアプリ等のデバイス上で動かすアプリケーション上、業者側が想定していない手段によって、そのシステムに対するアクセスがおこなわれ、かつ想定していないルート、手段で発注行為が行われ、結果的に業者側に想定外の損害を及ぼすような行為」であると定義できるのではないだろうか。つまり「ハッキング行為」を指しているといえる。逆に、一部の業者は、取引ＡＰＩを公開しており、それを利用する投資家も多い。かれらが行う行為はいわば「ツール取引」にあたる。業者側が提供しているアプリケーションの取引画面を経由せず、その裏側に設定されている発注のためのＡＰＩを利用して独自の発注画面を開発して発注するという行為を禁止するならば、それは取引約款上で明確にうたう必要があるのが今の時代であると思われる。たとえば、こう約款上でうたう。
「当社が提供する取引チャネル（上記定義済み）上での発注行為のみを認めるものであり、それ以外の方法（たとえば、プログラム内に存在する関連ＡＰＩを直接投資家自身が開発したプログラム上から発注する行為等）によって発注されたと判断しうる事象を発見した場合は、当社は強制的に当該顧客の口座を閉鎖する権限を有することに同意する」
この条件に同意しつつそれに該当する行為があれば、文句なく強制講座閉鎖をする権限を業者は有すると断言できる。問題は、その行為があったと断言できるだけの証拠をどう見つけるかである。
２）“損害をこうむる”の定義
そもそもそういう客を追い出したいという動機は、その客の取引によって業者側が損をするばかりであるという場合なのだろうが、EEモデルでないときに、その客によって損失を被るという判断を、何をもってするのかが重要なポイントになってくる。
たとえば、ある客が1か月を通して９０％の勝率をたたきだし、100万円の資金が1000万円になったとしよう。そしてその人の取引頻度は1回の売買（新規・決済）が早くても10秒程度だったとしよう。そしてヒットしているレートは確かにその業者が出している有効レートであるとしよう。この例では９０％の勝率だけが目立つわけだが、やっていること自体「ツール取引」ではないとしよう。仮にツールで取引していたとしても、客観的にみて業者側には何ら問題があるようには見えない。客が900万円の利益をこの業者から上げたからといって業者にとっていやな客だという判断は店頭の取引の根本が勘違いされている。この場合業者はそれ以上の利益をカバー取引においてあげればいいのである。それを担保するためにマークアップがあるということを忘れてはいけない。いやいや最近はスプレッド競争で鞘が小さすぎてなかなか利益が上げられないのだ、という言い訳は通るわけがない。それをも鑑みず、あなたは売買頻度が高くて、結果としてものすごく儲けたから出て行ってくれというのは、あたかも業者が自分自身で私は呑み屋ですと宣言しているようなものである。まさかそんな業者はいないと思うが。
店頭業者の利益の源泉は客から放り込まれるポジションをCP側でうまくヘッジしていかに利益を出すかである。そのために、CP側から配信されるレートにわずかなマークアップを乗せることで利益を出しやすくしている。したがって、客の注文が業者のサーバーに届いた時に、業者がCP側で即座にカバーに行ったとしたら（この仮説が大切なのだが）取引ごとにどれくらいの利益が出ていたかを見なくてはならない。それが設定するマークアップに収斂するなら、予定調和である。つまりそのシステムはその客に対してもうまく動いているといえる（※）。
※ちなみに、米国で標準化したＥＥモデル（on ＳＥＦ）はこの収益を１００％確保する代わりに、それ以上のディーリング収益の可能性を放棄するモデルである。
しかし、当該業者はＩＥモデルでヘッジしており、結果へたなディーリングのせいで損したというならそれはディーラーの責任であり客は関係ない。システムがEEモデルを機能させられるなら、この例の客の取引からでもちゃんと利益は出せるのであれば、この客は業者にとっていい客であり、何ら問題のない客である。客の口座の売買損益がどうであるかは論点たりえない。業者にとっての勝負は、それが新規注文だろうが、決済注文だろうが関係ない。あくまでも一つ一つの客の注文を約定させながら、そこからCP側のカバー取引をいかにうまく（あるいは素早く）執行するかにかかっている。仮にＥＥモデルだったとして計算してみても、客の注文がその時点での注文レートとして妥当であり、約定エンジンに届いてからＣＰカバーに行くいわゆる“ＩＥ＝先付モデル”を想定しても、どうしても遅れてしまうのであればそれはシステムのパフォーマンスが悪い、あるいはそういうスプレッドを提供するに堪えられるだけのスペックをその業者のシステムは出し切れていないということになる。
もしこの客からやってくる注文がいつもサーバー上のCPのレートと比べて逆ザヤになっているとするなら（つまり想定している鞘の分だけが全然確保できない状態がその客の注文においてのみ発生する現象が続く状態）、かつ、なにがしかの「ハッキング行為」によってそれを可能とする以外それが起きえないと断言できるなら、業者側にその客を追い出す正当性はあると私個人としては断言できる。しかし、その原因が業者のシステムのパフォーマンスの悪さに起因するとしたら、それは客を追い出す理由にはなりにくい。あえてこの場合でもその客を追い出したいなら、「当社のシステムのスペック上あなたの取引スピードについていけないので他でやってください」と言うことはできるかもしれないが、それを言うのはプロとして悲しい。
