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