システムトレード

初勝利!2012年システムトレード成績

12/28に全ロボットが決済をし、2012年の取引を終えました。

年間損益: +3,680,175

2008年からトレードロボットの研究をしてきましたが、年間損益がプラスになることは初めてで初勝利となります。これまでバックテストの結果は良くても、実際に日々ロボットを動かしてみると損失を積み重なるというパターンを繰り返していました。いろいろ取引方針の転換をしていますが、その中でも

デイトレード → 短~中期の相場

日経225先物一本 → 日経225先物、FX、商品先物

これらの方針変更が一番大きかったのではと考えています。

バックテストの結果と今年一年の仮運用でだいぶ自信がつきましたので、来年からはこのロボットを使って実際に取引をしてみようと思います。ただ、アベノミクス?の期待からか現時点で株価もだいぶ上がってしまっていますので、エントリするのが少々怖いですね。(^-^;

2012

| | コメント (2) | トラックバック (0)

取引回数とシュミレーション結果の信頼性について考える-2

2008年1月~2009年2月に使用した「2008年モデル」と2009年3月から使用している「2009年モデル」の性能を、今年の日経225miniのデータでシュミレーションし比較してみました。結果の損益グラフは以下の通りです。
Graph_2

青い線が「2009年モデル」、赤い線が「2008年モデル」です。どちらもトレンドフォロー戦略ですが、2009年モデルの方が慎重に行動する(取引回数が少なくなる)よう作っています。旧式のシュミレーション結果の方が2倍以上の損失ですので、3月の変更は間違いではなかったように見えますが、現状のシステムを使い続けることには疑問を感じてます。去年の10月中旬以降のようなチャンスがこないとも限りませんので、今年も去年と同様のルール(損失がシュミレーション時の最大ドローダウンの2倍を超えた場合リアル取引中止)で観察しようと思います。ここ数ヶ月のデイトレは逆張りでしか取りようのない相場に見えますので、今の戦略が脆弱で将来的にも無用なのか、ただ不運が続いているだけなのかの判断が難しいです。

| | コメント (0) | トラックバック (0)

オープンソース(LGPLv3)のトレードシステム部品をSOURCEFORGEで公開しました

トレードロボット基本コンポーネントパッケージをRobotTraderLibraryに名称変更し、ソースをSOURCEFORGEで管理するようにしました。バージョンはv2.00にアップしています。ソースの入手方法などメインサイトに載せています。このライブラリは現状本稼動中のトレードシステムで実際に使っており、現在ほとんどバグは出ていませんので比較的安定しているのではと思います。

また、ライセンスを今までのBSDライクなものからLGPLv3に変更しました。これでRobotTraderLibraryから派生したライブラリはオープンソースであることを義務付けられ、将来的にこのライブラリを独占されることはありません(私を含めて他の誰にも)。また、ライブラリの母体となるアプリケーション(呼び出し元)はオープンソースにしなくてもよいライセンスなので(詳しくはGNUからでているライセンスを参照ください)、安心して利用できるのではと思います。

トレードシステムの肝心要な売買ルール部分は誰も公開しないと思いますが、証券会社との通信処理やテクニカル指標の算出など共有可能なプログラム部品については、いろいろな開発者の方々の手によってメンテ、機能アップされた方が全トレードシステム開発者にとってメリットであると思いオープンソース化しました。ぜひ皆様もお気軽に開発に参加していただければと思います(Eclipseがあれば実現できます)。参加希望の方はメールをいただければ必要な情報を返信します(メールアドレスはメインサイトを参照ください)。

| | コメント (0) | トラックバック (1)

https通信の内容をモニタして解析する(フリーソフトBurpSuiteでキャプチャ)

証券会社のサイトからの気配情報取得や発注処理を作りこむ時、なかなかうまく行かず壁にあたってしまった場合はIEなどのブラウザから実際に発注をしてみて、その通信内容をキャプチャしたいところですが、通信内容がhttpsで暗号化されているため、wiresharkなどのパケットモニタツールでは内容を解析することができません。このような場合はBurpSuiteというツールを使うと便利です。IEなどでこのBurpSuiteをProxyに設定して通信をすると、通信内容のすべてを見ることができます。使い方は以下のとおりです。

(1)BurpSuiteを以下の場所からダウンロードする。
http://portswigger.net/burp/download.HTML

・上記のページで「Free Edition」をダウンロードします。
・jarファイルがダウンロードされます。この記事を書いた時はburpsuite_free_v1.5.jarでした。

(2)ダウンロードしたjarファイルをダブルクリックします。画面がたちあがります。

(3)ブラウザでlocalhostのポート8080をproxyに設定します。
IEの場合はツール→インターネットオプションで接続タブを開きLANの設定ボタンをクリックします。その中の「LANにプロキシサーバーを使用する~」にチェックし、アドレスにlocalhost、ポートに8080を入力します。

(4)証券会社のサイトにアクセスします。するとburpsuiteの画面のproxyタブの文字色が変わるのでこれをクリックします。

(5)リクエスト内容が表示されています。「forward」ボタンをクリックして通信を進めます。ブラウザが通信中でなくなるまで「forward」ボタンをクリックし続けます。

(6)historyタブを開くとそこまでの通信履歴を見ることができます。さらに表から各通信をクリックするとrequestとresponseタブでそれぞれの通信内容を見ることができます。

| | コメント (0) | トラックバック (1)

証券会社PCサイトでの自動発注(クリック証券に挑戦)

トレードロボットの自動発注処理は携帯サイトやPDAサイトなどのようにHTMLがシンプルなサイトを選んで作りこんでいますが、今回クリック証券のPCサイトでの発注に挑戦してみました。トレードロボット基本コンポーネントパッケージを使って気配情報取得や新規発注を実装しましたが、携帯サイトやPDAサイトなどと違いJavaScriptとhtmlが複雑に絡み合っていますのでどうしても手間がかかります。

JavaScriptなしのサイトはHtmlParserクラスのparseHtmlFormメソッドを使って生成したHtmlFormに発注数や発注条件をセットしてsendForm(Webクラス)するだけでよく、hidden項目などには何もしなくていいのですが、PCサイトではHTMLに書かれているformの要素をJavaScriptで編集しているケースが多く(クリック証券の場合はToggle系やformの送信先URL)、この部分の解析とプログラミングに時間がかかります。

今後FXの自動発注処理を作っていく予定ですが、HTMLがシンプルなサイトを選ぶことになりそうです。

| | コメント (0) | トラックバック (0)

トレードロボット基本コンポーネントパッケージv1.20とシグナルボックスエディタβ2.10を公開しました

トレードロボット基本コンポーネントパッケージv1.20とシグナルボックスエディタβ2.10をメインサイトで公開しました。大きく変わった点は以下の通りです。

  • トレードロボット基本コンポーネントパッケージ
    今までSignalStreamやSignalBlockのgetSignalメソッドでシグナルを取得していたところをgetJudgmentResultメソッドで取得するように変更しました。
  • シグナルボックスエディタ
    リレーション削除の操作方法を変更しました。
    リレーション削除ボタンをクリックしてキャンバスをドラッグすると線が表示されるようになっています。この線を削除したいリレーションと交差させるとリレーションが削除されます。複数リレーションを一度に削除できるようにするためこのように変更しました。

| | コメント (0) | トラックバック (0)

JavaのHttpURLConnectionのdisconnect()メソッドで認識違い(FIN,ACKパケットは流れない)

トレードロボット基本コンポーネントパッケージのWebクラスではWebサイトからhtmlを取得する時の処理の流れを以下のようにしています。

(1)HttpURLConnectionのconnect()を実行
(2)HttpURLConnectionのgetResponseCode()をした上でgetInputStream()からhtmlを取得
(3)HttpURLConnectionのdisconnect()を実行

このそれぞれの処理で以下のようなパケットのやりとりを想定していましたがⅡの方が大きな間違いでした。

Ⅰ.上記(1)のconnect()でSYN→SYN,ACK→ACKのパケットが流れてTCPのコネクションが確立される。
Ⅱ.上記(3)のdisconnect()でFIN,ACKのパケットをやりとりしコネクションを切断する。→×

wireshark(フリーのパケットキャプチャツール)でパケットのやりとりを見てみますとHttpURLConnectionのdisconnect()を行ってもFIN,ACKのパケットは流れません。
FIN,ACKはConnectionヘッダーのデフォルトをKeep-Aliveにしていたためか、(2)を行った後、数秒何もしないとサーバー側から送られてきていました。
Connectionヘッダーをcloseにすると(2)でhtmlを受け取った後、ただちにFIN,ACKパケットがサーバーに送られます。

今までWebクラスのgetHtmlメソッドやpostHtmlメソッドの中が上記の(1)~(3)のような処理でしたが、Keep-Aliveの時に連続してgetHtmlメソッドを実行すると問題が発生しそうです。以前HTTPのレスポンス受信時にIOException"Connection reset"が発生するトラブルがありましたがこれが根本原因なのかもしれません。修正版(getHtmlとpostHtmlメソッドの中のdisconnect()呼び出しをやめる)の基本コンポーネントパッケージを近日中に公開したいと思います。

なお上記以外にも以下のようなことがわかりました。
・Keep-Aliveで接続が持続されている状態でHttpURLConnectionのオブジェクトがスコープを外れるなどして破棄される時にはRST,ACKパケット(強制切断)がサーバーに送られる。
・HttpURLConnectionのconnect()はコネクションが確立していればSYN→SYN,ACK→ACKのパケットが流れない(これはjavadocに書いてありますね)のでKeep-Aliveには対応できる。

| | コメント (6) | トラックバック (0)

非専業システムトレーダーにとって重要な異常通知機能

常にPCの前にいて取引できる専業のトレーダーの方々と違い、私のような普段会社勤めをしている非専業のシステムトレーダーにとっては異常通知機能が大変重要になってきます。特にポジションを持っている状態で異常が発生した場合などは強制決済をしなければなりませんのでなるべく早く異常をキャッチする必要があります。

私の場合は以下の3段階で確認できるようにしています。

(1)トレードロボットのプロセスとは別にトレードロボットが動作しているか確認するプロセスを起動しておいて、トレードロボットと通信ができなくなった時に携帯電話に異常通知メールを送る。

→トレードロボットのプロセスが停止した時に通知を受けられます。基本的にはこれで十分なはずですが・・

(2)メインサイトのトップページに各ロボットがLastUpdate時刻を記録する。(20秒おき)

→トレードロボットとトレードロボット監視プロセスの両方が停止しても、このLastUpdate時刻を見れば異常をキャッチできます。

(3)メインサイト自体が見れない場合は光回線のDSU(ADSLの場合はADSLモデム)に異常があると判断します。

| | コメント (0) | トラックバック (0)

トレードロボット基本コンポーネントパッケージ(オープンソース)がv1.10にバージョンアップしました

トレードロボット基本コンポーネントパッケージ(オープンソース)がv1.10にバージョンアップしました。Web通信(http,https)クラスでCookieを自動処理するよう機能改善しています。今までのバージョンではCookieの送受信処理を自分で実装しなければなりませんでしたが、jp.robotbrain.net.Webクラスのgoメソッド(新)とsendFormメソッドを使うことにより基本コンポーネント側でCookieの送受信が行われます。これにより今まで面倒であった証券会社のPCサイトへのログインが携帯サイト、PDAサイトと同じようにシンプルなコードで実装できるようになりました。メインサイトでクリック証券、SBI証券、カブドットコムへのログイン処理のサンプルJavaソースをアップしましたのでよろしければご覧ください。

| | コメント (1) | トラックバック (0)

取引回数とシュミレーション結果の信頼性について考える

3月から実戦トレードロボットを旧式のnikkei_dolphin_sig001から現nikkei_ape_sig001に切り替えました。2008年度の実績をもとに算出した日経225mini1枚あたりの1取引(往復)のコスト(スリッページ+手数料)\1,200で2000年~2008年を旧式で再シュミレーションしたところ総損益マイナスの結果となったため、ロジックやパラメータを見直して新しいロボットに切り替えたのですが不安材料がいくつかあります。まずは旧式のロボットにくらべ現ロボットの年間平均取引数が少ない点。日経225miniのデイトレード(イブニングは除外)で旧式の平均年間取引数は278回ですが、現ロボットは157回です。これが多いか少ないかは1年くらい実トレードしてみないとなんとも言えませんが、2009月3月度だけを見るとまずまずの結果になりました。以下の表は旧式(青い線)と現ロボット(赤い線)の2009月3月度のシュミレーション結果ですが、現ロボットの方がドローダウンが小さく、最終的な損益も旧式よりも若干上まわりました。今後も旧式との比較をしながら、どのくらいの取引数が妥当か研究していきたいと思います。

0803_0903_2

| | コメント (0) | トラックバック (0)

より以前の記事一覧