前回の記事「ハードコア情報 - 定量取引システムの自動現物売り出しに関する詳細と考察 (I. 問題点と困難)」では、通貨サークルにおける実物取引のいくつかの基本的な問題について説明しました。この記事では、企業オファーの主な目的について説明します。

大きく分けて以下の4つがあると思います。

1. 確立された戦略ロジックを実装する

これについては疑いの余地がありません。信号がある場合は、対応する操作を実行して、ポジションを開閉する必要があります。この点は、指値注文を使用しないようにする必要があります。そうしないと、取引が完了できない場合、価格がすでに行き過ぎている可能性があります。質問。

長期的には、成行注文の使用によって生じるスリッページは、時折指値注文を逃して注文を追いかけることによって生じるスリッページとほぼ同じであるため、よほど特殊な戦略でない限り、市場に直接出入りする方が良いでしょう。

さらに、指値注文を使用する場合は、未約定の指値注文を管理してから注文を追跡する必要があるため、コードがより複雑になります。そして、指値注文の一部だけが約定された場合はどうなるでしょうか?残りの指値注文は常に保留されていますか?それとも、その部分を見逃して、別の成行注文を発行する必要がありますか?このようなワンステップ操作では複数の取引注文が生成され、その後のレビューも面倒で混乱しやすいです。したがって、送信が成功する限り、基本的に取引は保証されるので、成行注文を使用することをお勧めします。実際にスリッページに敏感な戦略である場合は、流動性の高いターゲットのみを取引してください。

また、契約に関しては、レバレッジを自由に変更しないでください。バックテストの理想的なレバレッジを 20% 割引するのが最善です。市場を主観的に予測したり、レバレッジを手動で調整したりしないでください。ポジションの変更も自動売買ではタブーです。

リトレースメントが一定のレベルに達したら、自動的に勝ったり負けたりしてポジションを減らすのが最善です。すぐに風が来ると考えてレバレッジを増やすことはしないでください（ただし、レバレッジを増やすことはできます）。元本を削減し、レバレッジを削減します）。最も重要なことはアカウントを存続させることなので、まずは無敗になることです。レバレッジを戻す前に、資本曲線がリトレースメント期間を過ぎるのを待つことができます。ただし、複利モデルを使用すると、それはすでに単純な自動勝敗契約になります。

2. 滑りを最小限に抑える

これについては前回の記事で触れました。滑りをなくすことはできず、軽減することしかできません。そのためには、市場価格情報だけでなく、取引所口座内のさまざまな資金やポジション情報をいち早く入手し、迅速に対応する必要があります。

実際のオファーの全体構造としては、多くのサブ戦略があり、さまざまな情報をタイムリーに取得する必要があるため、タスクを共有するための専用の WebSocket マーケット センターが必要です。バックアップ用にRestfulのプランBマーケットセンターを装備。このように、WebSocket が切断されて接続できない場合でも、市場から退場する必要があるかどうかを判断するための比較的新しい価格がまだ存在します。走るときは、先がどうなるかわからない渋滞に巻き込まれるより、間違った方向に走る方が良いです。

3. 長期稼働

これについては前回の記事で触れました。通貨サークルは 7*24 で実行され、コードをシャットダウンすることはできません。これには、スローされたさまざまな例外によってコードが中断されないこと、およびさまざまな予期せぬ状況を処理するコードが必要であることが必要です。また、メモリ リークなどのバグがあってはなりません。そうしないと、時間の経過とともにプログラムがクラッシュし、さらにはサーバー全体がダウンしてしまいます。幸いなことに、Python にはそのような問題が発生しにくく、自動メモリリサイクルメカニズムが備わっています。それが機能しない場合は、毎日または数日ごとに取引プログラムを手動で再起動できます。いずれにせよ、これは中頻度および低頻度の取引です。これらは基本的なバックエンド コード開発要件であり、簡単に達成できます。

一般的にクオンツトレードではPythonを使用します。スクリプト言語である Python の主な機能は動的コンパイルです。これは、コンパイルと実行を同時に行うためデバッグが容易ではないため、実行効率が若干低くなります (ただし、中低頻度のトランザクションには影響しません)。全て）。コードのロジックに暗黙的な問題がある場合、それを検出するのは簡単ではない可能性があります。たとえば、コードが 100 行あり、99 行目に問題があるが、毎回 95 行目までしか実行されない場合、エラーは 99 行目まで実行してトリガーされた後に見つかる必要があるため、問題は発見されません。関連するコードですが、これは遅すぎる可能性があり、例外をキャッチしようとしないとプログラムが直接クラッシュします。

実は、上記の問題には別の機能も含まれています。 Python は厳密に型指定されているため、暗黙的な変換はほとんどありません。サーバーから送信されるデータの種類、特に数値を信頼しすぎると、数値が文字列になる場合があるため、損失を被る可能性があります。異なる為替通貨、異なる API バージョン、WebSocket と REST から返される同じデータのタイプが異なる場合があります。したがって、原則として毎回強制的に変換するか、変換が必要かどうかを判断する必要があります。

また、さまざまな戦略間、特に同じ通貨の開始ポジションと終了ポジションを混同しないようにし、それらを適切に分離してください。そうしないと、極端な市場状況では、戦略 A が戦略 B のポジションをクローズし、最終的には実際のオファーを停止してやり直す必要が生じ、一貫性がなくなり、主要な市場トレンドを見逃す可能性があります。

一言で言えば、すべては長期にわたって完全に自動化され、介入なしで本物の取引を運営するためのものです。

ただし、戦略が複雑すぎる場合は、完全に介入なしでパフォーマンスを達成するのは簡単ではない可能性があります。戦略を単純化することも出発点であり、あまり複雑にしないでください。たとえば、OBV などのシグナルは慎重に使用する必要があります。OBV は長期的な価格と出来高の情報を追跡する必要があり、実際の取引では大量のデータを維持する必要があるため、中断と再開のたびに面倒な問題になります。最後の手段として、そのような要因を避けてください。

4. リスク管理

これは企業オファーの要件の最優先事項です。

最も危険なのはポジションを決済できないことです。市場は逆方向に進み、暴れ続けた結果、理由が何であれ、ポジションは損失でクローズされました。通貨サークルでは、アルトコインが短期間に数回上昇する可能性があります。そのため空売りの場合、レバレッジをかけずに半分のポジションを持っていても、「もう大丈夫」と思っていても、午前中にポジションが消滅している可能性があります。

したがって、終了メカニズムが確実に有効になるようにする必要があります。ポジションをオープンする機会を逃しても、少なくとも致命的ではありません。機会を逃してもせいぜい残念ですが、ポジションを決済する機会を逃すと、大きな問題が発生します。

ここでは 2 つの解決策を簡単に説明します。後で時間があるときに詳しく説明します。

最初のポイントは、固定損失率のストップロスに似たハードストップロスを設定するのが最善であるということです。たとえば、大型通貨が 10% 以上損失を出し、小型通貨が 15% を失った場合、ポジションは即座にクローズされ、逃亡します。

ハードストップロスメソッドの場合、ポジションをオープンするときにストップロス価格を設定する必要があります。したがって、アルゴリズムによるストップロス注文（条件付き注文とも呼ばれる）は、ポジションをオープンした後できるだけ早く送信する必要があり、途中で価格を変更する必要はありません。このようにして、取引所はリアルタイムの価格を監視し、トリガーされた後に市場から退出するための成行注文を送信するのに役立ちます。この方法では多くのスリッページが発生する可能性がありますが、自分で設定したストップロスよりも安定して信頼できる可能性が高く、たとえ何か問題が発生してトリガーされなかったとしても、取引所に行く可能性があります。権利を主張します（したがって、トップの取引所に行く必要があります）。

もちろん、この種のストップロスは底をカバーするために使用され、めったにトリガーされるべきではありません。リトレースメントが小さくなる可能性が高いように、自分の戦略に従って終了のタイミングを制御するのが最善です。

2 番目のポイントは、プログラムがランダムにポジションをオープンしないことです。ポジションを継続的にオープンしているのにそうでないと考えて、最終的に大きなエクスポージャをオープンしてしまうことのないようにしてください。価格が短期間に変動しない場合は問題ありませんが、突然反転した場合はポジションを清算することができます。もちろん、これは低レベルのエラーですが、実際に発生します。特に途中でコードを繰り返してアップグレードした後は、慎重に検討しない可能性があります。

この場合、まずポジションをオープンするペースを落とし、ポジションをオープンする結果が返されるまで待つ必要があります。また、ポジションをオープンする前に、その時点のアカウント情報を確認して確認する必要があります。もちろん、すべての操作をローカルで記録することもできます。これにより、API リクエストの数と取引所独自のクエリの時間を節約できます。アカウントのステータス。

また、より効果的には、取引所の最大レバレッジを事前に制限することも可能です。これは自分で調整できます。 Binance のデフォルトは 20 倍ですが、3 倍または 2 倍に変更することもできます (もちろん、これには戦略自体がハイ レバレッジを使用していないことが必要です。そうしないと、必要なときにハイ レバレッジを開くことができなくなります)。したがって、コードがどれほどクレイジーであっても、寝ている間に大きな露出を生み出すことは不可能です。この方が安全です。

つまり、実際のオファーはトランザクション コードだけではなく、ブラック スワン イベントによる侵入を防ぐために他の防御線を敷く必要がある場合もあります。いかなる時も決して軽視せず、死角をふさぐようにしてください。