バックトゥザフューチャー:履歴データを使用した取引ロボットのパフォーマンスの検証

画像



前に、私たちはすでに株式市場で働くための取引戦略の開発の必須段階の問題を検討しました。 最も重要な段階の1つは、履歴データで戦略のパフォーマンスをテストすることです-バックテスト。 今日は彼についてお話します。



これは何ですか



簡単に言えば、バックテストとは、過去の財務データを使用した取引戦略アルゴリズムの開始です。 アルゴリズムが特定の交換イベント(「シグナル」)を検出すると、金融商品の売買注文を生成します。これらの操作には関連する損益があります。



取引戦略で指定された期間の総利益または損失(損益、P&L、PnL)は、アルゴリズムの成功または失敗の指標になります。



トレーディングソフトウェア開発者がバックテストを通じて達成する目標はいくつかあります。





ご覧のとおり、バックテストは金融システムの開発者にとって便利なツールですが、履歴データを常に正しくテストできるとは限りません。 より高い頻度の戦略を実装する必要があるため、特定の市場状況と特定の交換プラットフォームのパラメーターがシステム全体のパフォーマンスに与える影響を正確にモデル化することは難しくなります。



画像



バックテストの間違い



交換取引の専門家であり、交換ロボットの開発者でもあるマイケルホールズムーアは、交換システムの初心者開発者が特定のエラーのためにミスを起こすことが多いと確信しています。 特に、専門家このような4つの誤解を引用しています。



将来的に同様に良い結果が期待される


多くの場合、開発者は、より説得力のある結果を得るために、テストパラメーターに変更を加えようとします。



同時に、履歴データの場合に何かを変更して結果を正確に予測する機会がある場合、「戦闘」モードではロボットはまったく効果的に動作しない可能性があります。 入力パラメーターの異なる値で戦略のパフォーマンスを測定する必要があります。



「将来の」データの使用


場合によっては、取引戦略立案者は、データセットに将来の市場状況に関する仮定を含めます。 コードのエラー、戦略の最適なパラメーターの誤った計算、または極端な価格値(高値と安値)の誤った使用の場合、実際の市場でのそのような戦略の起動は失敗する可能性があります(これは、戦略が履歴データでより効率的に機能する最も一般的な理由の1つです。リアルタイムよりも)。



彼らの心理的安定性の誤った評価


テストを実施する際、開発者はアルゴリズムの最終的なパフォーマンスを確認します。 システムが特定の期間(たとえば、1年または5年)に利益を上げる場合、成功へのパスに沿って発生した預金のドローダウン(損失)に注意を払わないように誘惑します。 人々は、彼らのお金の25%の損失を簡単に乗り切ることができるように思えます(結局、ロボットは回収しなければなりません)。



実際には、誰もがそのような瞬間を急いで行動することなく生き残ることができるわけではありません(そして、アルゴリズムが歴史の25%のお金の損失を許すなら、実際にはこの状況は非常に可能性が高いです)、それはしばしばより大きな損失につながります。



考慮すべきパラメーター



取引システムの開発者は、特定の戦略の最終的な財務的実行可能性に影響を与える可能性のある多くの異なるパラメーターを考慮する必要があります。



取引費用


初心者のトレーダーは、多くの場合、市場で直接アルゴリズムのパフォーマンスにのみ注意を払いますが、関連するコストを考慮することを忘れており、受け取ったすべての収入を平準化できます。 この場合の最も明白なコストは、取引所とブローカーから徴収される取引の手数料です(ITinvestの場合、 料金は為替手数料とほぼ同じです)。



スリッページと遅延


スリッページとは、取引ロボットがトランザクションを実行しようとしたときと実際に通過したときの価格の差です。 為替取引システムの中核に注文を「届ける」には時間がかかります。 高速取引ロボット(HFT)の場合、価格がわずかに変化する可能性のあるアカウントで1ミリ秒ごとにすると、トランザクションはそれほど収益性が高くなりません(またはまったく利益がありません)。



一部の金融商品はボラティリティが非常に高いため(価格は頻繁に変化するため)、取引を行う際に発生する可能性のある滑りを割り引く必要があります。



流動性効果


比較的流動性の低い商品を扱う場合、トレーダーは自分の取引システムの動作が市場に与える可能性のある影響を念頭に置いておく必要があります。 多くの人が特定の株式を売買しない場合、そのような株式を大量に購入する注文は価格を大きく変える可能性があります。 このような状況を回避するためには、ロボットに、取引を市場に大きな影響を与えない多数の小さな注文に分割するように教える必要があります。



取引注文の種類


取引戦略は、開発者がトランザクションを完了するために使用する予定の取引注文の種類にも影響されます。 ほとんどの場合、トレーダーは成行注文と指値注文に頼ります。



市場注文(「市場別」)は、現時点で市場で形成された金融商品(株式、 先物オプションなど)の価格で直ちに実行されます 。したがって、大量の株式を購入するなど、大規模な取引を完了する必要がある場合、市場注文が発生します異なる価格でいくつかの取引があるという事実に-市場は、ある価格で株式を販売したい人の適切な数を持たない可能性があり、その後、すべての株式を購入した後、ロボットは次の提示価格に進みます。



成行注文は積極的なツールです-トレーダーは最終取引価格を知らないまま、常に実行されます。



指値などの注文により、ロボットはトランザクションを実行するのに意味のある最低価格を決定できます。 そのような注文は未履行のままである可​​能性があり(市場で示された価格で販売または購入する意思のある人がいない場合)、または部分的に実行されます(十分な意思のある人がいなかった)ため、より受動的な取引方法と見なされます。



画像



もちろん、その利点は、取引価格が事前に決定されているという事実です。 現在行われている指値タイプの注文のリストは注文帳と呼ばれ、取引端末の別のウィンドウに表示されます。



戦略をテストするとき、成行注文と指値注文を使用するときの行動に注意を払うことが重要です。 注文キューが正しくモデル化されていない場合、リアルタイムで作業している場合、履歴データで実行する場合と比較して、取引戦略は悪い結果を示す場合があります。



バックテストツール



財務戦略をテストするために使用できる公的に利用可能なシステムはかなり多数あります。





画像



SmartXターミナルのTradeScriptでロボットを作成するためのプラグインのバックテスト用ウィンドウ



おわりに



バックテストは、取引戦略の開発における最も重要な段階であり、これなしでは、実際の市場の「戦闘」状態での取引ロボットの適切な動作を当てにすることは困難です。 履歴データに対する戦略の成功した操作は、リアルタイムのリアルタイム取引で使用された場合、同等の良い結果を保証しないことを理解することが重要です。



開発者は、履歴データのテストに加えて、リアルタイムでプログラムをチェックする必要があります。これは、取引所とブローカーが提供する特別なテスト取引システムを使用して実行できます。 このようなリスクのないシステムを仮想マネーで使用すると、変化する市場状況に対するロボットの反応をデバッグできます。通常、このような場合のデータは交換プラットフォームによって提供されます(遅延または「間引き」)。



今日は以上です。見てくれてありがとう。 コメントで質問にお答えします。



注意! C#GUI開発者にとって欠員となったITinvestでは、仕事は取引所での取引のためのソフトウェア製品のフロントエンド開発を実装することです。 詳細はwww.itinvest.ru/about/vacancies/programmer-gui-cで入手できます。



画像



PSタイプミスやエラーに気付いた場合は、個人的なメッセージを書いてください。すぐに修正します。



関連リンクと投稿:






All Articles