注文案を評価する
要求された操作を、対象口座と方針に照らして評価します。既存のエクスポージャー、未約定注文の予約済み限度、入力データの鮮度を考慮します。
- 注文、口座、方針の関連情報
- 取引前の限度と予約済み限度
- 理由を添えた許可・拒否・保留
リスクルールを確認。注文を送信する前に。
既存のトレーディングシステムを維持しながら、口座ごとのポリシーで注文案を確認します。判定を注文経路に結び付け、古い入力データやチェック不能時のルールを明確にします。
お問い合わせゲートウェイ / 注文判定
理由の分かる判定。
許可判断 / 0142
承認済みの方針の範囲内です。
必要な入力データは最新であり、注文案は利用可能な限度内に収まっています。
- 方針
- MANDATE-A / v3
- 根拠
- 今回のチェックに必要な鮮度を満たす
- 注文経路の対応
- 判定の範囲内で続行
執行経路で判定結果を適用する必要があります。
01
リクエストごとの許可・拒否・保留
02
判断に用いたポリシーの版と根拠
03
注文経路に紐づく判断記録
製品画面
リスク判断の根拠を確認します。
注文案、方針に基づく判定、接続した注文経路の対応を、一緒に検証できるようにします。
対象業務
注文チェックに明確な判断仕様を。
判断には口座、ポリシーの版、根拠の時刻、有効期限が伴います。未約定注文の予約枠と障害時の対応も合わせて定義します。
運用会社の既存トレーディングシステムと連携
外部運用会社または執行サービス提供者と、判定の入出力仕様と適用箇所を合意します。注文の訂正、取消、再試行も設計に含めます。
- 外部運用会社または注文・執行管理システム（OEMS）との連携
- 判定ID、方針のバージョン、有効期限
- 注文ライフサイクルと予約済み限度の照合
障害時の動作を明確にする
チェックが失敗した場合や未完了の場合は、注文を許可しません。遅延、古いデータ、サービス停止時のデスクの対応を定め、注文経路で適用されることを確認します。
- タイムアウトと古いデータへの対応
- 不明な口座や限度の未設定時の動作
- 迂回防止、障害対応の責任者、復旧
連携箇所
判定には、適用する場所が必要です。
運用会社の注文経路のどこでAPIを呼び、各判定結果にどう対応するかを合意します。
- 01
外部運用会社
既存の取引システムが注文案を送ります。
- 02
リスク判定
方針、エクスポージャー、最新の根拠に基づいて判定します。
- 03
判定を適用する経路
接続した注文経路が、許可・拒否・保留に従います。
- 04
対象の取引所
注文とその後の約定に、判定時の関連情報を残します。
API応答だけでは、連携を迂回する経路を遮断できません。
業務例
限度の情報を、注文の判定とともに。
注文が口座の利用可能な限度を超えた場合、ゲートウェイは適用ポリシーと根拠を添えて拒否を返します。接続された注文経路は発注を止め、判断記録を保存します。
01
要求
口座と方針の適用範囲を伴う注文案。
02
評価
現在のエクスポージャー、予約済み限度、入力データの品質。
03
判定を適用
接続した注文経路が、許可・拒否・保留に従います。
04
記録
判定、注文、その後の結果を結び付けて残します。
導入設計
導入を計画する。
業務に必要な入力、責任、検証項目を定めます。
- お客様からの入力
- リスク管理の責任分担、対象の注文経路、障害時の方針。
- Corbelが構成するもの
- 判定の入出力仕様、方針の評価、連携の検証記録。
- 検証と管理
- 遅延、同時処理、限度予約、有効期限、迂回への対応をテストします。
お客様に合わせて構成するCorbel
リスクポリシーを、連携された発注経路に組み込みます。
注文経路とリスクポリシーをお聞かせください。Corbelが判断仕様を定め、執行サービス提供者と統制の適用を検証します。