アービトラージ(裁定取引)について考えてみる その3 検証結果簡易報告編

investmentNo Comments

You Are Here:アービトラージ(裁定取引)について考えてみる その3 検証結果簡易報告編

5日目の投稿にして、すでにBlog書くの辛いなぁモードのueebeeです。
今回の内容が、検証や準備にシステムを作ったりでコードを書かないといけないというのを差し引いても、個人で毎日Blogを続けてらっしゃる方は本当に凄いなと感服します。

今回検証した内容

今回はUSDJPYの通貨ペアで、2ブローカーからのTick単位でのデータを溜め込みました。取得期間は5日です。

謎にMariaDB on Dockerが落ちる、会社から帰ってきてから落ちてるのに気づくというのが2回あり、合計10時間くらい空白の期間があります。5日で2回、1回あたり平均4.5時間サービス提供不可。商用だったら青くなるレベルの鯖落ちっぷりですw(商用だったら、当たり前ですが負荷テストだったり監視は必須ですね)

Docker側のログには軽く見た感じでは何も残ってません。MariaDBのコンテナだけ落ちてて、nginxやらが入ってる他の複数Dockerコンテナは無事なので、なんだか原因追うのが大変そうな感じです。

取得結果

前置きが長くなりましたが結果です。以下のレコード数がサーバー側に記録されていました。

レコード数 ブローカー
408,337 broker B
350,660 broker A

稼働時間は、 5日間 - 10時間 なので 396,000sec 程度です。

(60 x 60 x 24 x 5) - (60 x 60 x 10) = 396,000

上記をみると、私が用意した環境では 慣らすと1secに1回程度、ブローカーからレートの提示があった ことになります。想定よりゆっくりで、これはちょっと使えないかもな感がします。

検証内容雑感

今回検証しようと思ったポイントは2つあります。

  1. 価格の不均衡がブローカー間で存在するか?
  2. レート提示の速度差が、ブローカー間で存在するか?

1のロジックは「同タイミングで、価格が高いブローカーでsell、安いブローカーでbuy」としてポジションを持つ。そしていずれ価格差が収束するので、収束したタイミングでポジションを解消すると差額分だけ利益が手元に残るというものです。

2のロジックはレート提示が早いブローカーと遅いブローカーがいた場合、レート提示が早いブローカーをウォッチしておくと、レート提示が遅いブローカーBの少し先の未来の価格が予測できるかもというものです。

期末感ましましなので、今日はここまでです。次回以降で、分析、バックテスト、まとめを2、3回に分けて記事にしたいと思います。

About the author:

マーケティング屋さんとシステム屋さんの間の領域で活動してるOssanです。東京都在住。 ブラックラグーンとドトールコーヒーと旅とバッカスが好きです。最近興味本位に流されてAI周り、投資周りにも興味があります。

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

Top