ストップロスはもう通用しない、負けることは負けるのだ。 - ページ 4 1234567 新しいコメント Aleksey Vyazmikin 2019.09.07 08:12 #31 この状況について、ブローカーから正式な回答を得たので、引用する。 " なんとかログを解析して、状況を再現することができました。 ログによると、17:30からあなたのストップが何度もポジションを閉じようとしましたが、そのたびに「No many」というエラーが返されました - 取引に必要な資金が不足している のです。 解析の結果、16:43に発注した売りの指値注文がブロックの原因であることが判明しました。削除されずに有効なまま、既存の契約をブロックしていたのです。この注文でポジションを決済したことを意味します。 そのため、ストップロスの発動により別の売り注文を 出したところ、取引システムから「2枚の売り取引を完了するには資金が不足している」というメッセージが返されました。 そして、清算後、最初の注文が削除されました（未約定の注文はすべて取引所により取引終了時に削除されます）。その後、ストップロスが即座に執行され、ポジションがクローズされました。 ログのスクリーンショットと注文書そのものがメールに添付されています。 " どう反応したらいいのか、まだわかりません。 1.なぜ、お金がないことを端末のログメッセージに変換せず、サーバーに流したのか。 2.なぜブローカーは成行ではなく、指値注文で決済しようとしたのでしょうか？ ストップロスで決済した時に、指値注文でポジションを建てるだけの資金があったことを記しておきます。 全般的におかしなことになっていて、SEが全部入っている状態でポジションを開くと、Limit OrderによるTake ProfitでStopLossができないことが判明しました（SEは100％入っておらず、900ポイントほど移動可能な箇所が残っていました）。 Dmitiry Ananiev 2019.09.07 12:59 #32 Aleksey Vyazmikin: この状況について、ブローカーから正式な回答を得たので、引用する。 " なんとかログを解析して、状況を再現することができました。 ログによると、17:30からあなたのストップが何度もポジションを閉じようとしましたが、そのたびに「No many」というエラーが返されました - 取引に必要な資金が不足している のです。 解析の結果、16:43に発注した売りの指値注文がブロックの原因であることが判明しました。削除されずに有効なまま、既存の契約をブロックしていたのです。この注文でポジションを決済したことを意味します。 そのため、ストップロスの発動により別の売り注文を 出したところ、取引システムから「2枚の売り注文を執行するには資金が不足している」というメッセージが返されました。 そして、清算後、最初の注文が削除されました（未約定の注文はすべて取引所により取引終了時に削除されます）。その後、ストップロスが即座に執行され、ポジションがクローズされました。 ログのスクリーンショットと注文書そのものがメールに添付されています。 " どう反応したらいいのか、まだわかりません。 1.なぜ、お金がないことを端末のログメッセージに変換せず、サーバーに流したのか。 2.なぜブローカーは成行ではなく、指値注文で決済しようとしたのでしょうか？ ストップロスで決済した時に、指値注文でポジションを建てるだけの資金があったことを記しておきます。 一般に、状況は奇妙で、フルストップでポジションを開いた場合、指値注文による利食いでのStopLossは不可能であることが判明しました（CSは100％ロードされておらず、利食いのために約900ポイント残っていました）。 ということで、白抜きの文字で書かれていましたね。 そのため、別の売り注文を出した ところ（ストップロスが発動した結果）、取引システムは2限の売り取引を実行するには資金不足であるというメッセージを返しました。 取引に必要な資金が足りないというのは、取引所というより端末の開発者の問題です。そして、さらにあなたへの質問です。なぜトレードの基本ルールを勉強していないのですか？ Aleksey Vyazmikin 2019.09.07 13:53 #33 Dmitiry Ananiev: わかりやすく書いてありますよ〜。 また、取引に必要なお金が足りないというのは、取引所というより、端末の開発者の問題です。そして、さらにあなたへの質問です。なぜトレードの基本ルールを勉強していないのですか？ 成行注文と指値注文の違いもよく読んで～理解してるんでしょ？回答では、ストップロスを 処理するために別の指値注文を出したかったと書かれているので、なぜそうすることにしたのか、なぜ成行で決済しなかったのかは不明です。 削除済み 2019.09.07 16:02 #34 Aleksey Vyazmikin: 成行注文と指値注文の違いもよく読んで～理解してるのか？回答では、ストップロスを 処理するために別の指値注文を出したかったと書いてあるので、なぜそうすることにしたのか、なぜ成行で決済しないことにしたのかは不明です。 個人的には、ストップオーダーとリミットオーダーが同じ価格だと理解しました。そのため、2つの注文が一度に処理され、それを実行するための資金が足りなかった（2つ同時に処理された）のです。2回目のリミットは論外です。 Aleksey Vyazmikin 2019.09.07 16:04 #35 Сергей Таболин: 個人的な理解では、ストップとリミットが同値だったのでは？そのため、一度に2つの注文が処理され、それを実行するための資金が足りなくなった（2つ同時）。2回目のリミットは論外です。 最初のスクリーンショットをよく見てください。買いポジションがあり、テイクプロフィットの代わりに売り 指値注文が あり、ポジションの下にストップロスがあることがわかります。 Aleksey Vyazmikin 2019.09.07 16:17 #36 これは基本的に、彼らがシステムによってどのように状況を認識させたかのスクリーンショットです。このメッセージは出回っていたので、その部分を切り取っただけです。 問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのである なぜ、そのように計画マージンを計算したのですか？ Sergey Chalyshev 2019.09.08 00:03 #37 Aleksey Vyazmikin: これは基本的に、彼らがシステムによってどのように状況を認識させたかのスクリーンショットです。このメッセージは出回っていたので、その部分を切り取っただけです。 問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのであるなぜ、予定マージンがそのようにカウントされたのですか？ これですべて納得です。 その通り、逆指値注文は基本的に成行注文、つまり最悪価格での指値注文です。そのため、1.5倍のマージンが必要なのです。 しかし、なぜそのようなことが端末に表示されないのでしょうか。これは開発者の方への質問です。 Roman 2019.09.08 05:40 #38 Sergey Chalyshev: これですべて納得です。 その通り、ストップビッドは基本的にマーケットビッド、つまり最悪の価格での指値注文である。だから、1.5倍のマージンが必要なのです。 しかし、なぜそのようなことが端末に表示されないのでしょうか。これは開発者の方への質問です。 そうですね、取引所には成行注文は存在しません、それは単なるスラングです 取引所には指値注文しかなく、最悪価格で送ることで、即座に、つまり成行で執行することが義務づけられている。 しかし、状況は面白いもので、別の指値注文のマージンのためにオープンポジションが ブロックされ、マーケットでのストップロス（指値）のマージンが足りなくなったのです。 そう、MQのサーバー側の改良ではなく、サーバー機能としてのストップロスがこの場合優先されるべきなのです。 つまり、ストップロス機能は、実行するのに十分なマージンがないかをチェックし、その後、発注された指値注文のチェックを行う必要があります。 で、あれば、必要なマージンが確保されるまで取り出す。 状況をノートに書き留めるだけ。 Aleksey Vyazmikin 2019.09.08 09:21 #39 Sergey Chalyshev: これですべて納得です。 その通り、ストップビッドは基本的にマーケットビッド、つまり最悪の価格での指値注文である。だから、1.5倍のマージンが必要なのです。 待って、あなたの論理では、売りの指値注文の開始にかかわらず、いかなる場合でもストップロスは発動しないのですか？ しかし、そうではなく、必ずクローズが発生します。 私の理解では、同じ数量で反対の指値注文（成行・保留）を出しても、S/Lは増えない（補正係数があるのかもしれませんが）。 発注した保留中の注文は取引所に行き、ストップロスはブローカーのシステムに残ったままです。さらに、マーケットでポジションを閉じるときにCSを増やさないというルールも存在すると思うのです。 その結果、ブローカーのポジションを制御するプログラムは、Sell limitはSEを増やさない注文とみなし、Stop Lossはポジションを閉じる注文とみなさず、売り注文とみなすことにしたため、SEが過大に要求されることになったのです 指値注文と成行注文の2つのイベントが同時に発生することはありえないので、同時にポジションを閉じるためのリスクをカウントしようとするのは間違っていると思うのですが、いかがでしょうか。売り指値が発動されるとストップロスは解除され、ストップロスが発動されると売り指値の分だけGOとなり、2つの事象が同時に発生することはありません。 もう一度ログを見てみることにしました。ここでは、ポジションが開く前にSell指値が開かれたというニュアンスですが、必要証拠金の再計算とそれに対する各注文の分類がリクエストごとに発生しているのだと思います。 OM 0 16:52:49.442 Trades '***': sell limit 1.00 Si-9.19 at 66992 PF 0 16:52:49.468 Trades '***': accepted sell limit 1.00 Si-9.19 at 66992 DP 0 16:52:49.469 Trades '***': sell limit 1.00 Si-9.19 at 66992 placed for execution HS 0 16:52:49.474 Trades '***': order #108360210 sell limit 1.00 / 1.00 Si-9.19 at 66992 done in 31.520 ms JG 0 16:52:56.193 Trades '***': deal #64625350 sell 1.00 Si-9.19 at 66992 done (based on order #108360210) EK 0 16:53:31.179 Trades '***': buy limit 1.00 Si-9.19 at 66982 PQ 0 16:53:31.214 Trades '***': accepted buy limit 1.00 Si-9.19 at 66982 FF 0 16:53:31.215 Trades '***': buy limit 1.00 Si-9.19 at 66982 placed for execution LD 0 16:53:31.218 Trades '***': order #108360263 buy limit 1.00 / 1.00 Si-9.19 at 66982 done in 38.649 ms DS 0 16:53:31.857 Trades '***': deal #64625365 buy 1.00 Si-9.19 at 66982 done (based on order #108360263) MO 0 16:55:13.704 Trades '***': modify #108360263 buy 1.00 Si-9.19 sl: 0, tp: 0 -> sl: 66855, tp: 0 KN 0 16:55:13.736 Trades '***': accepted modify #108360263 buy 1.00 Si-9.19 sl: 0, tp: 0 -> sl: 66855, tp: 0 EI 0 16:55:13.738 Trades '***': modify #108360263 buy 1.00 Si-9.19 -> sl: 66855, tp: 0 done in 34.064 ms 論理的に無理な要求であることは、先ほど証明しましたが、問題は、ブローカーが取引所のルールに従って行動し、そのルールにそのような論理的な誤りがあるのか、それともブローカーのサーバーの設定の問題なのか、ということです。 セルゲイ・チャリシェフ ただし、なぜそのようなことが端末に反映されないのでしょうか？それは開発者への質問です。 はい、まさにそれが最大の不満点です！状況情報が不足しているのです。 ローマン そうです、おっしゃるとおり、取引所には成行注文は存在しません、それは単なるスラングです 取引所には指値注文しかなく、最悪価格で送ることで、即座に、つまり成行で約定しなければならないのです。 しかし、状況は面白いもので、別の指値注文のマージンのためにオープンポジションが ブロックされ、マーケットにストップロス（指値）を入れるためのマージンが足りなくなったのです。 そう、MQのサーバー側の改良ではなく、サーバー機能としてのストップロスがこの場合優先されるべきなのです。 つまり、ストップロス機能は、実行するのに十分なマージンがないかをチェックし、その後、発注された指値注文のチェックを行う必要があります。 で、あれば、必要なマージンが確保されるまで取り出す。 状況をノートに書き留めるだけ。 ただ、市場のものは存在していて、スラングではなく、ドキュメントなのですが、plaza2のプロトコルでは名前で存在しないのです。 指値注文は取引所にあり、先に行ったので、GOに負荷のかからないカウンターオーダーとしてカウントされ、ストップロスはGOを増やしたマーケットオーダーとみなされる、それが問題なのですそして、ここのブローカーが嘘の回答を始めたということは、GOのカウントを間違えたのは彼らのシステムだったということでもある...。 ここに「PRINCIPLES OF WARRANTY BENEFITS OF NCC (JSC) ON THE EMPLOYMENT MARKET」という資料がありますが、今のところCSについては何とか見つけましたが、そこで計算に入るのはそう簡単なことではありませんね。 Aleksey Vyazmikin 2019.09.08 09:26 #40 Sell Limitにはサインがあるべきで、それはポジションを閉じるか 新たに建てることを目的としているはずで、もしそれが存在するならば、Stop LossまたはTake Profitでポジションを閉じるとき、そのようなサイン付きの反対売買注文はマーケットから削除されるべきと思われます。 1234567 新しいコメント 取引の機会を逃しています。 無料取引アプリ 8千を超えるシグナルをコピー 金融ニュースで金融マーケットを探索 新規登録 ログイン スペースを含まないラテン文字 このメールにパスワードが送信されます エラーが発生しました Googleでログイン WebサイトポリシーおよびMQL5.COM利用規約に同意します。 新規登録 MQL5.com WebサイトへのログインにCookieの使用を許可します。 ログインするには、ブラウザで必要な設定を有効にしてください。 ログイン/パスワードをお忘れですか？ Googleでログイン
この状況について、ブローカーから正式な回答を得たので、引用する。
"
なんとかログを解析して、状況を再現することができました。
ログによると、17:30からあなたのストップが何度もポジションを閉じようとしましたが、そのたびに「No many」というエラーが返されました - 取引に必要な資金が不足している のです。
解析の結果、16:43に発注した売りの指値注文がブロックの原因であることが判明しました。削除されずに有効なまま、既存の契約をブロックしていたのです。この注文でポジションを決済したことを意味します。 そのため、ストップロスの発動により別の売り注文を 出したところ、取引システムから「2枚の売り取引を完了するには資金が不足している」というメッセージが返されました。
そして、清算後、最初の注文が削除されました（未約定の注文はすべて取引所により取引終了時に削除されます）。その後、ストップロスが即座に執行され、ポジションがクローズされました。
ログのスクリーンショットと注文書そのものがメールに添付されています。
"
どう反応したらいいのか、まだわかりません。
1.なぜ、お金がないことを端末のログメッセージに変換せず、サーバーに流したのか。
2.なぜブローカーは成行ではなく、指値注文で決済しようとしたのでしょうか？
ストップロスで決済した時に、指値注文でポジションを建てるだけの資金があったことを記しておきます。
全般的におかしなことになっていて、SEが全部入っている状態でポジションを開くと、Limit OrderによるTake ProfitでStopLossができないことが判明しました（SEは100％入っておらず、900ポイントほど移動可能な箇所が残っていました）。
この状況について、ブローカーから正式な回答を得たので、引用する。
"
なんとかログを解析して、状況を再現することができました。
ログによると、17:30からあなたのストップが何度もポジションを閉じようとしましたが、そのたびに「No many」というエラーが返されました - 取引に必要な資金が不足している のです。
解析の結果、16:43に発注した売りの指値注文がブロックの原因であることが判明しました。削除されずに有効なまま、既存の契約をブロックしていたのです。この注文でポジションを決済したことを意味します。 そのため、ストップロスの発動により別の売り注文を 出したところ、取引システムから「2枚の売り注文を執行するには資金が不足している」というメッセージが返されました。
そして、清算後、最初の注文が削除されました（未約定の注文はすべて取引所により取引終了時に削除されます）。その後、ストップロスが即座に執行され、ポジションがクローズされました。
ログのスクリーンショットと注文書そのものがメールに添付されています。
"
どう反応したらいいのか、まだわかりません。
1.なぜ、お金がないことを端末のログメッセージに変換せず、サーバーに流したのか。
2.なぜブローカーは成行ではなく、指値注文で決済しようとしたのでしょうか？
ストップロスで決済した時に、指値注文でポジションを建てるだけの資金があったことを記しておきます。
一般に、状況は奇妙で、フルストップでポジションを開いた場合、指値注文による利食いでのStopLossは不可能であることが判明しました（CSは100％ロードされておらず、利食いのために約900ポイント残っていました）。
ということで、白抜きの文字で書かれていましたね。
そのため、別の売り注文を出した ところ（ストップロスが発動した結果）、取引システムは2限の売り取引を実行するには資金不足であるというメッセージを返しました。
わかりやすく書いてありますよ〜。
また、取引に必要なお金が足りないというのは、取引所というより、端末の開発者の問題です。そして、さらにあなたへの質問です。なぜトレードの基本ルールを勉強していないのですか？成行注文と指値注文の違いもよく読んで～理解してるんでしょ？回答では、ストップロスを 処理するために別の指値注文を出したかったと書かれているので、なぜそうすることにしたのか、なぜ成行で決済しなかったのかは不明です。
成行注文と指値注文の違いもよく読んで～理解してるのか？回答では、ストップロスを 処理するために別の指値注文を出したかったと書いてあるので、なぜそうすることにしたのか、なぜ成行で決済しないことにしたのかは不明です。
個人的には、ストップオーダーとリミットオーダーが同じ価格だと理解しました。そのため、2つの注文が一度に処理され、それを実行するための資金が足りなかった（2つ同時に処理された）のです。2回目のリミットは論外です。
個人的な理解では、ストップとリミットが同値だったのでは？そのため、一度に2つの注文が処理され、それを実行するための資金が足りなくなった（2つ同時）。2回目のリミットは論外です。
最初のスクリーンショットをよく見てください。買いポジションがあり、テイクプロフィットの代わりに売り 指値注文が あり、ポジションの下にストップロスがあることがわかります。
これは基本的に、彼らがシステムによってどのように状況を認識させたかのスクリーンショットです。このメッセージは出回っていたので、その部分を切り取っただけです。
問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのである なぜ、そのように計画マージンを計算したのですか？
これは基本的に、彼らがシステムによってどのように状況を認識させたかのスクリーンショットです。このメッセージは出回っていたので、その部分を切り取っただけです。
問題は、この6504.45という推定マージンがどこから出てきたのか、ということです。それは何から生まれたのでしょうか？売りの指値注文から買いの指値注文と同じ証拠金を差し引いたものが4500円となったが、その証拠金は、あたかもその瞬間に市場で始値を作る予定であるかのように計算されていることが判明したのであるなぜ、予定マージンがそのようにカウントされたのですか？
これですべて納得です。
その通り、逆指値注文は基本的に成行注文、つまり最悪価格での指値注文です。そのため、1.5倍のマージンが必要なのです。
しかし、なぜそのようなことが端末に表示されないのでしょうか。これは開発者の方への質問です。
これですべて納得です。
その通り、ストップビッドは基本的にマーケットビッド、つまり最悪の価格での指値注文である。だから、1.5倍のマージンが必要なのです。
しかし、なぜそのようなことが端末に表示されないのでしょうか。これは開発者の方への質問です。
そうですね、取引所には成行注文は存在しません、それは単なるスラングです
取引所には指値注文しかなく、最悪価格で送ることで、即座に、つまり成行で執行することが義務づけられている。
しかし、状況は面白いもので、別の指値注文のマージンのためにオープンポジションが ブロックされ、マーケットでのストップロス（指値）のマージンが足りなくなったのです。
そう、MQのサーバー側の改良ではなく、サーバー機能としてのストップロスがこの場合優先されるべきなのです。
つまり、ストップロス機能は、実行するのに十分なマージンがないかをチェックし、その後、発注された指値注文のチェックを行う必要があります。
で、あれば、必要なマージンが確保されるまで取り出す。
状況をノートに書き留めるだけ。
これですべて納得です。
その通り、ストップビッドは基本的にマーケットビッド、つまり最悪の価格での指値注文である。だから、1.5倍のマージンが必要なのです。
待って、あなたの論理では、売りの指値注文の開始にかかわらず、いかなる場合でもストップロスは発動しないのですか？
しかし、そうではなく、必ずクローズが発生します。
私の理解では、同じ数量で反対の指値注文（成行・保留）を出しても、S/Lは増えない（補正係数があるのかもしれませんが）。
発注した保留中の注文は取引所に行き、ストップロスはブローカーのシステムに残ったままです。さらに、マーケットでポジションを閉じるときにCSを増やさないというルールも存在すると思うのです。
その結果、ブローカーのポジションを制御するプログラムは、Sell limitはSEを増やさない注文とみなし、Stop Lossはポジションを閉じる注文とみなさず、売り注文とみなすことにしたため、SEが過大に要求されることになったのです
指値注文と成行注文の2つのイベントが同時に発生することはありえないので、同時にポジションを閉じるためのリスクをカウントしようとするのは間違っていると思うのですが、いかがでしょうか。売り指値が発動されるとストップロスは解除され、ストップロスが発動されると売り指値の分だけGOとなり、2つの事象が同時に発生することはありません。
もう一度ログを見てみることにしました。ここでは、ポジションが開く前にSell指値が開かれたというニュアンスですが、必要証拠金の再計算とそれに対する各注文の分類がリクエストごとに発生しているのだと思います。
論理的に無理な要求であることは、先ほど証明しましたが、問題は、ブローカーが取引所のルールに従って行動し、そのルールにそのような論理的な誤りがあるのか、それともブローカーのサーバーの設定の問題なのか、ということです。
ただし、なぜそのようなことが端末に反映されないのでしょうか？それは開発者への質問です。
はい、まさにそれが最大の不満点です！状況情報が不足しているのです。
そうです、おっしゃるとおり、取引所には成行注文は存在しません、それは単なるスラングです
取引所には指値注文しかなく、最悪価格で送ることで、即座に、つまり成行で約定しなければならないのです。
しかし、状況は面白いもので、別の指値注文のマージンのためにオープンポジションが ブロックされ、マーケットにストップロス（指値）を入れるためのマージンが足りなくなったのです。
そう、MQのサーバー側の改良ではなく、サーバー機能としてのストップロスがこの場合優先されるべきなのです。
つまり、ストップロス機能は、実行するのに十分なマージンがないかをチェックし、その後、発注された指値注文のチェックを行う必要があります。
で、あれば、必要なマージンが確保されるまで取り出す。
状況をノートに書き留めるだけ。
ただ、市場のものは存在していて、スラングではなく、ドキュメントなのですが、plaza2のプロトコルでは名前で存在しないのです。
指値注文は取引所にあり、先に行ったので、GOに負荷のかからないカウンターオーダーとしてカウントされ、ストップロスはGOを増やしたマーケットオーダーとみなされる、それが問題なのですそして、ここのブローカーが嘘の回答を始めたということは、GOのカウントを間違えたのは彼らのシステムだったということでもある...。
ここに「PRINCIPLES OF WARRANTY BENEFITS OF NCC (JSC) ON THE EMPLOYMENT MARKET」という資料がありますが、今のところCSについては何とか見つけましたが、そこで計算に入るのはそう簡単なことではありませんね。