MT5 NDDでの実作業 - ページ 10

[hrenfx]

メタトレーダーには大きな制約があり、現在の価格より悪い価格で指値をすることはできません。そ のため、多くのストラテジーをメタトレーダーで実装することができません。

例えば、Bid価格がある価格水準に達したときに、N pipsを超えない範囲でマイナスのスリッページで売ることができるようにしたい場合です。これは、ベストプライスで必要な数量が足りないときに、ストラテジーロジックがそう設定されているので（例えばテスターで）、実行する必要があるのですが、とても必要なことなのです。

その場合、必要なBid価格が表示されたらすぐに、Bid-N価格、つまり現在の価格よりN pips悪い価格でSellLimitを設定します。そうすることで、現在のBid価格から最悪N pipsを下回らない加重平均 価格で、より大きな指値の充填を得ることができます。

実はこれ、アーカイブのことなんです。そして、有能なブローカーは、加重平均価格を形成するもののうち最悪の価格という追加のパラメータを持つこのような条件付き指値注文を持っています。このような条件付き制限は、古典的な制限と同じテーブルに格納されているため、ブローカーの実行速度を悪化させることはできません。

[Andrei01]

hrenfx:

もっとよく読んでください：純粋なECNと ECN/STPについて。

リジェクトとポジティブリミットのスリッページ

STPでは、そこからの価格が指値注文より良いか等しい場合に、指値注文が送信されます。さらに、注文がSTPに流れている間、価格は、まだ改善する（正のスリッページ）、限界領域を出る（再注文）など、どの方向にも変化することができます。

ありがとうございます。しかし、次の点がよくわからない。あなたの説明から、ECNは内部と外部の共通の市場スタックを持っておらず、外部市場は常に指値スリップがあるわけではなく、指値注文を事前にトレーダーが送信して価格が正しくヒットしたとしても、価格がどこかで滑って再拒否につながる可能性がある最後の瞬間であることがわかります。事前に送った指値注文が、ECNが最後の瞬間に一般プールに入れなかったために執行されないということはなさそうですが、この記述は本当にそうでしょうか？さらに驚くべきは、この瞬間に正のスリッページが発生する可能性があるという説明で、ECNはこのスリッページをトレーダーに返します。

[hrenfx]

内部（ECN）と外部（接続された各流動性プロバイダー）という多くのステークがあります。共通のベッティングマーケットがない。

ブローカーによっては、リミッターの実行をリダイレクトせずに多かれ少なかれ保証するために、いわゆるスナップショットを作成します。例えば、ある価格が3つの流動性プロバイダーから同時に利用できる場合にのみ、フィードに取り込まれます。

また、ECNはDCとはほとんど関係なく、ディーリングはしていない。透明性の高いブローカーは、プラスのスリッページをトレーダーに還元します。さらに、現在より悪い値段で指値をすれば、必ずプラスのスリッページが発生します。そして、ブローカーがそれを返さなければ、かなり見苦しいことになる。もちろん、プラスのスリッページの一部しか与えないブローカーもあります。でも、近づかない方がいいんです。

[Ilnur Khasanov]

開発者：この点については、プラットフォームの発展（スレッドで声があがった問題点、リミッターの拡大など...）に期待してもいいのでは？

[Andrei01]

hrenfx:

内部（ECN）と外部（接続された各流動性プロバイダー）という多くのステークがあります。共通の料金表はありません。

ありがとうございます。では、なぜアグリゲーターは、すべてのプロバイダーを共通の「自分の」カップに集約し、最良の価格だけを選択することができないのだろうか？それが、彼らの仕事ではないでしょうか？

[hrenfx]

Andrei01:
ありがとうございます。では、なぜアグリゲーターは、すべてのプロバイダーを1つの共通の「自分の」カップに集約し、最良の価格だけを選ぶことができないのでしょうか？それが、彼らの仕事ではないでしょうか？

あなたは、何かトリッキーな市場法を見ているようですが、実際はすべてが非常にシンプルなのです。

証券会社が市場原理を働かせないというのは、ほとんど嘘である。証券会社がほとんどポジションを執行しない場合、それは市場活動に従事していないことを意味しない。そうではないのです。

マーケットメイクをしながら、撤退してリスクを抱え込まないこと、撤退すること、これがすべてマーケットである。どちらの方式も、小規模な小売店から大規模な施設まで、ほぼすべてのオフィスで利用されている。

アグリゲーターとは、簡単に言えば、複数のオフィスの誰かが同時に取引条件を集計することです。通常、これらの企業は、誰かがどこかで組み合わせていることさえ知らない。例えば、MQL+WinAPIを使えば、Metatrader上の多くのブローカーを簡単に組み合わせることができます。市場のようなものを持つことになります。しかし、問題は、ブローカー自身がこのあなたのシステムのクライアントではないということでしょう。彼らはあなたのマーケットに注文を送らないが、あなたは自分のニーズのために仮想マーケットを形成する-取引またはブローキングのために。

したがって、実際のECN市場は、仮想の市場（STP）ではなく、そこに送られる注文からだけ本当の市場である可能性があります。ブローカーの場合は、それほど多くはない自分の顧客の注文だけでよい。

メリットとデメリットがあります。例えば、すでに配置したLimitsを外部から誰も見ないというメリットがあります。したがって、あなたの戦略を理解し、操作することはできません。そして、自分の限界は他のクライアントの限界の山の中にあるわけですから、外の世界には何もないのです。

[Andrei01]

hrenfx:

これにはメリットとデメリットがあります。例えば、プラス面では、あらかじめ設定したリミッターを外部の人が見ることができないことです。その結果、誰もあなたの戦略を把握して操ることはできません。また、自分の限界は他のクライアントの限界の山の中にあるので、外の世界には何も見えません。

いずれにせよ、この説明では、流動性アグリゲーターが誰であろうと、次の点が理解できない。仮に、複数の流動性供給者がそれぞれの利害関係を持っていて、それらを新しいアグリゲーターとして私の家に統合したいとします。外部市場スタックへのアクセス時間の誤差（1秒の数分の1）で市場環境を 悪化させることなく、このマージを完全に等価にするには、どうやら十分な深さまでスタックをマージすればよいようで、外部スタックにある指値注文や一般に保留中の注文は、自動的に外部スタック、結果として内部、マージしたスタックにも表示されて、保留中の注文と任意のスタックを形成するからです。

しかし、保留中の注文は通常事前に、つまりメガネ同士の結合時間よりもずっと前に設定されているため、すでに外部のメガネから内部のメガネにすべて集約されており、ここでは原理的に予測はできません。

[hrenfx]

大まかには、以下のような方式です。

1. 事前に注文を出すと、ECNブローカーのクライアントの注文から内部スタックに入ります。
2. しかし、ブローカーは、仮想スタック＝内部スタック（ECN）＋外部スタック（STP）を表示しています。
3. 内部ECNに逆の注文が出た場合、両者はほぼ瞬時にボリュームmin(Limit1, Limit2)で約定し（スリッページなしで一致）、ブローカーは（各注文から）2倍の手数料を受け取ることになります。
4. 注文を満たす価格が外部市場（例：第三流動性供給者-LP3）から来た場合
5. お客様の注文は、内部ECN-Stackから削除（凍結）されます。
6. 特定のLiveTime（通常、数十～数百ミリ秒）でLP3に送信される。
7. あなたの注文は、LP3に届いたとき、通常、LP3の現在の価格 よりも悪い価格で提供されます。したがって、それに対応する正のスリッページが発生します。
8. LP3での現在の価格（発送-配達の間に変更されている可能性があります）よりも入札価格が良い場合、LiveTimeの価格が満足のいくものでない場合は、リベートがあります。
9. LiveTimeを通じて、お客様の注文の残高（一部執行中）はLP3から削除され、内部ECNに配置（凍結解除）されます。
10. 外部執行では、ブローカーは同じ手数料から LP3 の手数料を差し引いた額を得る（LP3 のブローカーは、単に顧客の代理人として行動しているにすぎない）。そして、潜在的なプラスのスリッページやリベートを得ることができるのです。

その結果、ECN/STPスキームでは、内部ECNによるより有利な価格とブローカーへの二重手数料からの利益があり、それらをあなたの戦略と潜在的な正のスリッページ（およびリダイレクト）にカモフラージュする可能性を与えながら、（STP）複数の流動性プロバイダーを集約すると、より有利な価格であります。

P.S. 興味のある方は、自分でMTアグリゲータを書いてみてはいかがでしょうか？それは、実にシンプルなことです。しかし、それを通して取引を始めると、上記の大まかなスキームではもちろん明記されていない、膨大な数の落とし穴が見えてくるのです。

[Andrei01]

hrenfx:

大まかには以下のようなスキームです。

スキームには感謝していますが、以前から疑問が残っています。

1.アグリゲーション方式を実装するのはこの方式だけなのか？

2.なぜ、私が説明したように、タンブラーを1つに集約することができないのでしょうか？結局のところ、その中で外部スタックとの相互作用は、必然的に実行の条件を悪化させる必要があり、不必要な遅延を導入し、要求のトリガー時だけでなく、単一のスタックを形成するために連続的なのでしょうか？さらに、あなたのスキームによれば、すべては最後の瞬間にのみ執行されるため、保留中の注文と成行注文の間に違いはなく、保留中の注文を事前に送信しても、最後の瞬間にのみ外部市場に入るため意味がない。

[hrenfx]

Andrei01:

1.アグリゲーションスキームを実装するのはこのスキームだけなのか？

大まかには、そうですね。

2.なぜ、私が説明したアグリゲーション方式を実現できないのでしょうか？

なぜなら、すべての流動性プロバイダーは、あなたのECNシステムの顧客にならなければならないからです。そんなブローカーがあるんですよ、LMAX。これは実質的に純粋なECN（MTF-barer）であり、流動性プロバイダーは作成されたシステムのクライアントである。つまり、一部の銀行と何らかの契約を結んで、その条件を受け入れているのです。上記でLastLookを紹介したが、それ以外にも多くの銀行がこのような条件を採用しない理由がある。

結局のところ、その中で、外部スタックとの相互作用は、注文がトリガされた瞬間だけでなく、単一のスタックを形成するために常に発生し、それは必然的に実行条件を悪化させるはず不要なラグを導入しているのですか？

はい、アグリゲーションによる実行は保証されていません。スナップショット（フィルター）で実行力を高める方法はいろいろありますが、これは一面的なものです。アグリゲーションの長所は、すでに上記で何度も声を上げている。

しかも、あなたのスキームによれば、すべては最後の瞬間にしか執行されないので、保留中の注文と成行注文に違いはなく、保留中の注文は最後の瞬間にしか外ガラスに届かないので、事前に送信する理由はないのだそうです。

成行注文は両方向にスリッページが発生しても執行され、指値注文はプラス方向のみ、または見逃されるという大きな違いがあります。事前に（少なくとも1秒前に）保留注文を設定することで、端末<->取引サーバー<->集計装置に依存することを避け、それぞれ実行にかかる時間を短縮し、実行自体を向上させることができるのです。