プロップファーム運営事業者
トレーダー評価プログラムの基盤
- 課題
- 評価の合否と失格の条件が文章でしか決まっておらず、判定の根拠を後から示せない状態でした。
- 対応
- 目標・期間・最大損失をルールの設定として持たせ、ルール変更を遡及させない構成にした
- 判定に使った値と、その時点で参照していたルールの版を記録に残す形にした
- トレーダー向けの進捗表示と、運営側が根拠を確認できる画面を用意した
- 技術
- 評価プログラム基盤 ／ ブローカー接続 ／ FIX API
概要
プロップファームの基盤で難しいのは、リスク管理を事後の集計ではなく執行の手前に置くことです。ドローダウンの判定が日次バッチでは、限度を超えた取引が成立してしまいます。監視と限度の執行を発注経路に組み込む設計が要ります。
もう一点が、判定の説明可能性です。評価の合否や失格の判定は、後から根拠を示せなければ紛争になります。判定に使った値と、その時点で参照していたルールの版を記録に残す構成にしておきます。
提供内容
評価プログラム基盤
ルール（目標・期間・最大損失）を設定として持ち、トレーダーごとの進捗と判定を管理します。ルール変更を遡及させない設計にします。
リスク限度の自動執行
ドローダウンや建玉上限の判定を発注経路に組み込み、限度超過の取引が成立する前に止めます。
損益・報酬の計算
計算基準日と権利確定の関係、期中の変更の扱い、計算ロジックの版を記録に残す形で実装します。訂正の手順も先に決めます。
不正検知
複数口座間の相殺取引、指標発表前後の集中、極端に短い保有時間など、規約に反する取引パターンの検出を実装します。
進め方
- 01
ルールの言語化
評価の合否条件、失格条件、報酬の計算式を、判定可能な形まで落とします。曖昧なまま実装すると紛争の種になります。
- 02
ブローカー接続の設計
口座の開設・紐づけと、約定・残高の取得経路を設計します。監視をどこで行うかがここで決まります。
- 03
監視と執行の実装
限度の判定を発注経路に組み込み、超過時の動作を実装します。判定の根拠を記録に残す設計を同時に入れます。
- 04
精算とダッシュボード
損益・報酬の計算と、トレーダー向けの進捗表示を実装します。運営側が判定の根拠を確認できる画面も用意します。
関連する対応 API
この領域の実績
守秘義務のため、社名と具体的な数値は伏せています。
プロップファーム運営事業者
ドローダウン監視を発注経路へ組み込む
- 課題
- ドローダウンの判定が日次バッチで、限度を超えた取引がそのまま成立してしまう状態でした。
- 対応
- 限度の判定を発注経路そのものへ組み込み、超過する注文を成立前に止めた
- 建玉上限と損失限度の判定を、約定の反映遅延を考慮した形で設計した
- 止めた注文の理由を記録し、後から説明できるようにした
- 技術
- リスク管理 ／ ブローカー接続 ／ 約定・残高の突合
プロップファーム運営事業者
損益・報酬の計算と不正検知
- 課題
- 報酬計算の基準日と権利確定の関係が曖昧で、期中のルール変更をどう扱うかが決まっていませんでした。
- 対応
- 計算基準日と権利確定の関係を整理し、計算ロジックの版を記録に残す実装にした
- 訂正が必要になったときの手順を、実装より先に決めた
- 複数口座間の相殺取引や、指標発表前後に集中する取引を検出の対象に載せた
- 技術
- 損益・報酬計算 ／ 不正検知 ／ Trading Technologies API
プロップファーム事業支援についてよくあるご質問
事業の立ち上げ段階から相談できますか。
できます。むしろルールの言語化から入るほうが確実です。評価の合否条件と失格条件が判定可能な形になっていないと、実装も判定の説明もできません。
既存のブローカーやプラットフォームを使えますか。
接続方式が公開されていれば対応します。約定と残高をどの経路で、どの遅延で取得できるかによって、監視をどこに置けるかが決まります。まず接続先の仕様確認から入ります。
不正検知はどこまで実装できますか。
規約で禁止している行為を、データから判定可能な形に落とせる範囲で実装します。検知したものをすべて自動で失格にするのではなく、確認の対象として上げる運用にするのが一般的です。