(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2023-12-08
(45)【発行日】2023-12-18
(54)【発明の名称】取引スケジュール管理システム
(51)【国際特許分類】
G06Q 40/06 20120101AFI20231211BHJP
【FI】
G06Q40/06
(21)【出願番号】P 2021538871
(86)(22)【出願日】2019-09-13
(86)【国際出願番号】 CA2019051300
(87)【国際公開番号】W WO2020051712
(87)【国際公開日】2020-03-19
【審査請求日】2022-08-17
(32)【優先日】2018-09-14
(33)【優先権主張国・地域又は機関】US
(73)【特許権者】
【識別番号】522314511
【氏名又は名称】サービスナウ・カナダ・インコーポレイテッド
【氏名又は名称原語表記】SERVICENOW CANADA INC.
(74)【代理人】
【識別番号】100094569
【氏名又は名称】田中 伸一郎
(74)【代理人】
【識別番号】100103610
【氏名又は名称】▲吉▼田 和彦
(74)【代理人】
【識別番号】100109070
【氏名又は名称】須田 洋之
(74)【代理人】
【識別番号】100067013
【氏名又は名称】大塚 文昭
(74)【代理人】
【識別番号】100086771
【氏名又は名称】西島 孝喜
(74)【代理人】
【識別番号】100109335
【氏名又は名称】上杉 浩
(74)【代理人】
【識別番号】100120525
【氏名又は名称】近藤 直樹
(74)【代理人】
【識別番号】100139712
【氏名又は名称】那須 威夫
(74)【代理人】
【識別番号】100176418
【氏名又は名称】工藤 嘉晃
(72)【発明者】
【氏名】バージェロン パスカル
(72)【発明者】
【氏名】チャパドス ニコラス
(72)【発明者】
【氏名】マーコット エティエンヌ
(72)【発明者】
【氏名】サバタ マレック
(72)【発明者】
【氏名】セルギエンコ イヴァン
(72)【発明者】
【氏名】ヴァレンツァーノ リチャード アンソニー
(72)【発明者】
【氏名】クレステル ベンジャミン
【審査官】関 博文
(56)【参考文献】
【文献】特開2006-127155(JP,A)
【文献】特表2010-529553(JP,A)
【文献】特表2008-523501(JP,A)
【文献】米国特許出願公開第2010/0217725(US,A1)
【文献】米国特許出願公開第2002/0147671(US,A1)
(58)【調査した分野】(Int.Cl.,DB名)
G06Q 10/00-99/00
(57)【特許請求の範囲】
【請求項1】
金融資産のポートフォリオ管理において使用されるシステムであって、
現在のポートフォリオにおける資産に関する詳細を含む現在のポートフォリオデータと、
所望のポートフォリオにおける資産に関する詳細を含む所望のポートフォリオデータと、
少なくとも前記現在のポートフォリオを前記所望のポートフォリオに変換すべき実行時間枠の詳細を含む実行時間データと、
を含む入力データを受け取る入力モジュールと、
前記現在のポートフォリオを前記所望のポートフォリオに変換する際に従う必要がある制約について詳述するポートフォリオ管理制約と、
前記入力データを受け取って、前記現在のポートフォリオ及び前記所望のポートフォリオにおける前記資産の売り買いの限界を含む資産管理スケジュールを作成する管理スケジューラモジュールと、
1又は2以上の特定のタスクを実行するための前記資産管理スケジュールの適合性に基づいて、前記資産管理スケジュールを評価して前記管理スケジューラモジュールにフィードバックを提供する評価器モジュールと、
を備え、
前記1又は2以上の特定のタスクは、前記現在のポートフォリオにおける前記資産と前記所望のポートフォリオにおける前記資産との間の資産価値差分の増加の最適化を含み、
前記評価器モジュール及び前記管理スケジューラモジュールは、前記評価器
モジュールが前記
管理
スケジューラモジュールの好適なバージョンを受け入れ可能とみなすまで異なるバージョンを反復し、
前記
資産管理スケジュールは、前記実行時間枠を特定の時間単位に細分し、前記
資産管理スケジュールは、特定の時間単位内で買うべき又は売るべき1又は2以上の資産を詳述する、
ことを特徴とするシステム。
【請求項2】
前記システムは、
前記所望のポートフォリオにおける少なくとも1つの特定の資産の最高買値、
前記現在のポートフォリオにおける少なくとも1つの特定の資産の最低売値、
取引当たりに買うべき最大資産数、
取引当たりに売るべき最小資産数、
取引当たりに売るべき最大資産数、
取引当たりに買うべき最小資産数、
リスク制約、
予想量率制約、及び、
ビッドアスクスプレッド制約、
のうちの少なくとも1つを含むユーザ定義制約を受け入れる、
請求項1に記載のシステム。
【請求項3】
前記
管理スケジューラモジュールは、少なくとも1つの資産取引市場の状況について詳述する市況入力を受け取り、前記
資産管理スケジュールは、前記市況入力に少なくとも基づいて作成される、
請求項1に記載のシステム。
【請求項4】
前記
資産管理スケジュールは、前記資産の売り買いを行うべき1又は2以上の取引所について詳述する、
請求項1に記載のシステム。
【請求項5】
前記システムは、前記
資産管理スケジュールに基づいて前記資産の売り買いを実行すべき1又は2以上の仲買人を該1又は2以上の仲買人による以前の実績の記録に少なくとも基づいて選択する仲買人選択モジュールを含む、
請求項1に記載のシステム。
【請求項6】
前記システムは、前記
資産管理スケジュールに従って資産の売却及び購入を実行する際に使用すべき、前記1又は2以上の仲買人が使用する少なくとも1つの取引方法を選択する、
請求項5に記載のシステム。
【請求項7】
前記システムによって作成された前記
資産管理スケジュールは、承認のためにユーザに送信される、
請求項1に記載のシステム。
【請求項8】
前記
資産管理スケジュールは、前記評価器モジュールによって評価された後にのみ前記ユーザに送信される、
請求項7に記載のシステム。
【請求項9】
前記評価器モジュールは、
市況入力から導出された、前記
資産管理スケジュールに従って前記資産を売り買いすべき資産取引市場の状況、
前記現在のポートフォリオデータ、
前記所望のポートフォリオデータ、
前記実行時間データ、
前記ポートフォリオ管理制約、
前記現在のポートフォリオデータ及び前記所望のポートフォリオデータに基づく潜在的価値利益率計算、
前記現在のポートフォリオ及び前記所望のポートフォリオにおける資産の価格、
前記現在のポートフォリオ及び前記所望のポートフォリオの少なくとも一方における前記資産の量、
特定の特徴を有する取引が実行された後の市場の動向を模倣又は予測しようと努める少なくとも1つのモデル、
のうちの少なくとも1つに基づいて前記
資産管理スケジュールを評価する、請求項1に記載のシステム。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、金融資産の管理に関する。具体的には、本発明は、機械学習を活用して金融資産取引をスケジュールし、管理し、実行するためのシステム及び方法に関する。
【背景技術】
【0002】
政府系ファンド、年金基金、ヘッジファンドなどの買い主側資産管理者(buy side asset managers)は、投資家に直接投資サービスを提供する。投資家は、資産管理者に、退職所得などの高水準目標、並びに損失許容範囲(loss tolerance)及び資産階級割当(asset class allocations)などの制約を与える。そして、資産管理者は、どの特定の証券に顧客資産を投資すべきであるかを決定する。買い主側企業(buy side firms)は、投資家からの新たな現金を投資するとともに、投資家によって与えられた投資条件(investment mandates)内に留まるように定期的にそのポートフォリオのリバランスを行う必要がある。資産管理者は、何を取引すべきであるかを決定すると、売り手側株式仲買人企業に取引指示(trading instructions)を与える。通常、これらの取引指示は、例えば「5日間にわたってApple社を100,000株買え」などの比較的高水準なものである。通常、資産管理者は、注文を送る先の株式仲買人を自由に選ぶことができる。そして、各株式仲買人は、1又は2以上の取引所でそれぞれの注文を実行する。
【発明の概要】
【発明が解決しようとする課題】
【0003】
想像できるように、資産管理者、投資家及び大手金融機関は、資産取引のリバランシング、管理及び実行に関わるプロセスを最適化したいと望んでいる。通常、この問題を検討する際には、極めて多くの検討事項が考慮される。投資家及び管理者によって課される制約事項に対処する必要があるだけでなく、どの仲買人を使用すべきであるかについての問題にも対処する必要があり得る。また、どのような戦略が使用されていようと、タイミング、資産の量、及びこのような資産の買値/売値も織り込まれなければならない。
【0004】
この10年間にわたるアルゴリズム的投資戦略の発展は、特に大手投資銀行では過度に売り手側に集中してきた。これらの投資銀行には、アルゴリズムによって提供される省効率性(efficiency savings)を利用するための資源及び直接的な動機がある。さらに、買い主側企業は、全コストによる取引に関しては比較的蚊帳の外に置かれたままである。この大きな理由は、買い主側企業がこれらのコストの綿密な報告を投資家に返す必要がなかったからである。従って、買い主側及び資産管理側のニーズに対処するシステム及び方法が必要とされている。
【課題を解決するための手段】
【0005】
本発明は、資産ポートフォリオの管理方法を提供する。システムが、現在のポートフォリオを所望のポートフォリオに変換する詳細な取引スケジュールを作成する。このスケジュールは、機械学習を使用して作成され、現在のポートフォリオ、所望のポートフォリオ、実行タイムライン及びユーザ指定の制約を含む複数の入力に基づく。作成されると、システムは、1又は2以上の市場モデルを使用してスケジュールを評価し、1又は2以上のモデルに基づく市場の反応を所与としてスケジュールが実行可能であるかどうかを判定する。システムは、最良のスケジュールに行き着くまで作成/評価のループを繰り返す。また、システムは、取引を実行する際に使用すべき仲買人についてだけでなく、仲買人がスケジュールを実行する際に使用できる取引アルゴリズムについての推奨を提供することもできる。
【0006】
第1の態様では、本発明は、金融資産のポートフォリオ管理において使用されるシステムであって、
現在のポートフォリオにおける資産に関する詳細を含む現在のポートフォリオデータと、
所望のポートフォリオにおける資産に関する詳細を含む所望のポートフォリオデータと、
少なくとも前記現在のポートフォリオを前記所望のポートフォリオに変換すべき実行時間枠の詳細を含む実行時間データと、
を含む入力データを受け取る入力モジュールと、
前記現在のポートフォリオを前記所望のポートフォリオに変換する際に従う必要がある制約について詳述するポートフォリオ管理制約と、
前記入力データを受け取って、前記現在のポートフォリオ及び前記所望のポートフォリオにおける前記資産の売り買いの限界を含む資産管理スケジュールを作成する管理スケジューラモジュールと、
1又は2以上の特定のタスクを実行するための前記資産管理スケジュールの適合性に基づいて前記資産管理スケジュールを評価する評価器モジュールと、
を備え、
前記1又は2以上の特定のタスクが、前記現在のポートフォリオにおける前記資産と前記所望のポートフォリオにおける前記資産との間の資産価値差分の増加の最適化を含み、
前記スケジュールが、前記実行時間枠を特定の時間単位に細分し、前記スケジュールが、特定の時間単位内で買うべき又は売るべき1又は2以上の資産を詳述する、
システムを提供する。
【0007】
第2の態様では、本発明は、金融資産ポートフォリオの管理方法であって、
少なくとも1つの資産タイプ、対応するポートフォリオ重みエンベロープ及び対応する実行タイムラインを含む取引注文を受け取るステップと、
少なくとも1つの資産タイプのポートフォリオ重みエンベロープを所望の資産量エンベロープに変換するステップと、
タイムラインを少なくとも1つの特定の市場の複数の予想取引セッションに分割するステップと、
所望の資産量エンベロープを複数の予想取引セッション間で分配するステップと、
複数の取引期間のうちの少なくとも1つの取引期間中に取引すべき少なくとも1つの分配量を示す少なくとも1つの指示を少なくとも1人の仲買人に発行するステップと、
を含む方法を提供する。
【0008】
以下、同一の要素を同一の参照番号によって示す以下の図を参照しながら本発明を説明する。
【図面の簡単な説明】
【0009】
【
図1】本発明の1つの態様によるシステムのブロック図である。
【
図2】
図1に示すシステムと同様のシステムの別のブロック図である。
【
図3】本発明の別の態様による方法のステップを詳述するフローチャートである。
【発明を実施するための形態】
【0010】
1つの態様では、本発明は、金融資産を管理するためのシステム及び方法を提供する。1つの実装では、このシステムを使用して、現在の資産ポートフォリオと、所望の資産ポートフォリオと、現在の資産ポートフォリオから所望の資産ポートフォリオを変換又は作成するために必要な取引に関する制約と、これを完了するための時間枠に関する入力とをユーザから受け取ることによって資産ポートフォリオのリバランシングを行う。システムは、時間枠をさらに小さな時間単位に分割して、時間枠内のどの時間単位でどの資産を売るべきか、時間枠内のどの時間単位でどの資産を買うべきか、資産を買う時又は売る時にどの資産取引所を使用すべきか、及び買い/売り指示を実行すべき限度価格を詳述する詳細なスケジュールを作成することができる。スケジュールは、どの資産の買い/売り取引においてどの取引所を使用すべきかを含むこともできる。1つの代替例では、スケジュールが、どの取引にどの仲買人及びどの取引アルゴリズムを使用すべきかを詳述することもできる。結果として得られたスケジュールは、承認のためにユーザに送られる。承認されると、関連するスケジュール部分が実行のために関連する仲買人に送られる。
【0011】
なお、スケジュールが作成されると、この作成されたスケジュールは、全体的状況、資産の価格、予想資産購入/売却量に基づいて評価される。評価は、適切に評価された資産を含む好適な所望のポートフォリオという所望の最終結果がスケジュールによってもたらされるかどうかを判定するために行われる。この評価は、作成されたスケジュールで取引を行った時の市場又は取引所の動向を模倣又は再現しようと努める1又は2以上のモデルに基づくことができる。この評価では、評価が正しく行われることを確実にするために、現在の及び所望のポートフォリオ及び上述した制約を含む、ユーザによって入力された入力データを使用することができる。評価の結果、作成されたスケジュールが不十分であり又は所望のニーズを満たさないことが判明した場合には、フィードバックループによって修正スケジュールが作成されるようになる。入力データ及びこのデータの背景に基づく最良のスケジュールを作成するために、評価器からのフィードバックを使用して新規又は修正スケジュールが繰り返し作成される。実装によっては、以下で詳述するような1又は2以上の市況入力に少なくとも基づいて評価を実行することもできる。
【0012】
システムは、スケジュールの作成に役立つように、1又は2以上の資産取引市場又は取引所の状況を詳述する市況入力を受け取ることができる。従って、スケジュールの作成時又は作成されたスケジュールの評価時にはこれらの状況を使用することができる。市況入力は、モニタされている実際の(単複の)市場又は(単複の)取引所からのリアルタイム又は近リアルタイム入力とすることができる。或いは、市況は、このような市場又は取引所のシミュレーションの結果とすることもできる。従って、好適な市場/取引所シミュレータが、市況に関する必要な入力をシステムに提供するために必要なデータを提供することができる。市況入力は、単一の市場/取引所に限定することも、或いは複数の市場又は取引所の状況を詳述することもできることが明らかであろう。
【0013】
上述したように、取引を実行する際には、使用すべき1又は複数の仲買人の選択が重要となり得る。リバランシング戦略の実行効率に仲買人手数料のコストを織り込むだけでなく、以前の売買又は取引におけるその仲買人の過去の実績を、取引をスケジュール内で上手く実行できる見込みの指標として使用することもできる。従って、システムには、作成されたスケジュールに従って資産の売却/購入を実行する1又は複数の仲買人を推奨するのに役立つ仲買人選択モジュールが存在することができる。システムは、使用すべき1又は2以上の仲買人を推奨することに加えて、様々な取引を実行する際にその仲買人のどの取引アルゴリズムを使用するのが最も有利となり得るかに関する推奨を提供することもできる。仲買人選択モジュールは、推奨に役立つように、複数の仲買人、その過去の取引、これらの取引の結果、特定の仲買人を通じた資産売却及び資産購入のコストに関する詳細及びデータ、並びにこれらの仲買人によって使用された取引アルゴリズムに関するデータを含むデータベースに結合することができる。このデータベースには、これらの取引アルゴリズムの詳細な履歴及びこれらのアルゴリズムの実績を記憶することもできる。システムは、場合によっては仲買人選択モジュールを通じてデータベース内のデータにアクセスし、各仲買人及びその取引アルゴリズムの履歴、コスト及び実績を分析することによって、どの1又は複数の仲買人を使用すべきかについての推奨を提供することができる。また、システムは、各仲買人についてどのアルゴリズムを使用すべきかを推奨することもできる。
【0014】
詳細なスケジュールが作成されて適切であると評価されると、このスケジュールは、好適なGUI(グラフィカルユーザインターフェイス)又はAPI(アプリケーションプログラムインターフェイス)を通じてユーザに送信される。ユーザは、スケジュールの受け入れ又は拒否を行うことができる。ユーザがスケジュールを受け入れた場合、スケジュールは、実行のために選択された仲買人に送ることができる。当然ながら、スケジュールが拒否された場合、ユーザは、スケジュールの修正/調整を行って、さらなる作業のためにスケジュールをシステムに返送することができる。
【0015】
図1に、本発明の1つの態様による基本システムのブロック図を示す。
図1で分かるように、システム10は、現在のポートフォリオデータ30と、所望のポートフォリオデータ40と、実行時間データ50と、制約60とを含む入力データを受け取る入力モジュール20を含む。現在のポートフォリオデータ30は、少なくとも現在のポートフォリオ内の資産のアイデンティティ、及び場合によってはこのような資産の価格を含む、これらの資産に関する詳細を提供する。同様に、所望のポートフォリオデータ40は、所望のポートフォリオ内の資産に関する詳細を提供する。実行時間データは、所望のポートフォリオを得るために現在のポートフォリオを変換/調整すべき時間枠を提供する。実行時間データは、最低限でも、変換を完了すべき最終期限、或いは実行時間枠を分割すべきタイムライン又は時間単位(例えば、日数、分割先の時間単位、大きな時間単位当たりの小さな単位数など)を提供する。従って、一例として実行時間データは、10稼働日又は取引日の時間枠を100の時間単位に分割すべきであり、従って時間単位当たりに複数回の取引/売却/購入を実行する必要があり得ることを詳述することができる。
【0016】
また、入力データには、現在のポートフォリオを所望のポートフォリオに変換するために必要な、取引を実行する際に守る必要がある制約も含まれる。あらゆる数の制約を入力することができ、これらの制約は、現在のポートフォリオを所望のポートフォリオに変換するあらゆる態様に関連することができる。制約は、リスクレベル、ビッドアスクスプレッド(bid-ask spread)、売却/購入すべき資産の量、及び資産ロットサイズ(asset lot size)に関連することができる。さらなる例として、制約は、上記所望のポートフォリオ内の少なくとも1つの特定の資産の最高買値、上記現在のポートフォリオ内の少なくとも1つの特定の資産の最低売値、取引当たりに買うべき最大資産数、取引当たりに売るべき最小資産数、取引当たりに売るべき最大資産数、及び取引当たりに買うべき最小資産数を含むことができる。他の制約は、特定のレート、及び市場における利用可能な資産量当たりの相対的取引量に関連することができる。同様に、制約は、時間単位当たり、或いは1日又は取引時間当たりに売却/購入すべき資産の量に関連することもできる。同様に、実装が仲買人選択モジュールを含む場合、制約は、仲買人によって課される取引当たり価格の限界、選択すべき仲買人の必要最低能力レベル、選択すべき取引アルゴリズムの最低能力レベル、及びポートフォリオ変換のための最大仲買人手数料コストを含むことができる。
【0017】
入力モジュール20に入力データが入力され、入力データがシステムによる使用に適するように正しくフォーマットされて処理されると、入力データは取引スケジューラモジュール70に転送される。その後、取引スケジューラモジュール70は、入力データを取り込み、このデータを分析してスケジュールを作成する。取引スケジューラモジュール70は、ニューラルネットワーク、動的プログラミング、制約付き最適化法(constrained optimization methods)、時系列予測、転移学習(transfer learning)、ベイズ推論(Bayesian inference)、及び/又は強化学習(reinforcement learning)の組み合わせに基づくアルゴリズム/方法を使用してスケジュールを作成することができる。モジュール70は、取引実行時間枠内で取引セッション毎に最適に資産の売り買いを行うように、様々な方法及び手段を使用してスケジュールを作成することができる。従って、一例として時間枠が5日間である場合、このモジュールは、5日間の時間枠内に全ての必要な資産の売却及び購入が完了するまで、1日目に株式x1をx株売るべきであり、2日目にy1をy株買うべきであることなどを決定することができる。想像できるように、取引スケジューラモジュール70は、資産取引の一部又は全部の市場への影響を査定する好適な市場影響モデルを考慮することができる。このようなモデルは、ポートフォリオの値の最適な変更が行われる(すなわち、現在のポートフォリオ内の資産と所望のポートフォリオ内の資産との間の値の増加が最大になる)のを確実にするようにスケジュールを調整するために使用することもできる。また、取引スケジューラモジュール70は、各取引によって生み出されるリスクを模倣又は予測する1又は2以上の好適なリスクモデルを考慮することもできる。このリスクは、所望のリスク因子に応じて最小化し、又は必要に応じてリスクモデルに基づいて調整することができる。
【0018】
取引スケジューラモジュール70の機能の一部として、一貫性を保つように入力データをチェックすることもできることが明らかであろう。従って、取引スケジューラモジュール70は、制約が互いに矛盾しないことを確実にするように制約をチェックすることができる。また、取引スケジューラモジュール70を使用して、作成されたスケジュールが入力された様々な制約を確実に守るようにスケジュールをチェックすることもできる。
【0019】
スケジュールが作成されると、このスケジュールは、複数の市場/取引所モデルの支援下で複数の基準を使用してスケジュールを評価する評価器モジュール80によって評価される。評価器モジュール80は、(可能であれば)作成されたスケジュールが様々な制約に従っているかどうかを判定する。また、評価器モジュールは、市況、使用目的の適合性(例えば、スケジュールがわずかな時間内に過度に多くの量の特定の資産の取引を詳述していないかどうか、そしてこれがその資産の価格に悪影響を与える恐れがないかどうか)、及びこれによって最終的に所望のポートフォリオが作成されるかどうかなどの全体的状況に照らしてスケジュールを査定する。上述したように、評価器モジュールは、作成されたスケジュールを取引所/市場動向のための1又は2以上のモデルに基づいて査定する。
【0020】
作成されたスケジュールが評価器モジュール80によって不十分又はどこか足りないと査定された場合には、評価器モジュール80からのフィードバックが取引スケジューラモジュールに返送され、以前のスケジュールは廃棄され又はスケジューラモジュールに返送される。この結果、取引スケジューラモジュール80は、このフィードバック(又は以前に作成されたスケジュール)を使用して、フィードバックに基づいて更新された最新スケジュールを作成する。この反復プロセスは、反復スケジュールが満足できるものである(すなわち、スケジューラがこれ以上スケジュールを改善できないため、このスケジュールが入力データ、制約、状況及び市況を所与とする最良のスケジュールである)との査定を評価器モジュールが行うまで継続する。なお、実装によっては、作成されたスケジュールが制約に従っているかどうかに関する査定を、評価器モジュール又は取引スケジューラモジュールのいずれかにおいて行うことができる。
【0021】
スケジュールが評価されて(場合によっては取引スケジューラモジュールと評価器モジュールとの間の複数回の反復後に)許容できるとみなされると、作成されたスケジュールは、GUI又はAPI90を通じてユーザに送られる。ユーザは、作成されたスケジュールについて独自の評価を行う。承認される(100)と、このスケジュールは1又は2以上の仲買人に送信され(110)、1又は複数の仲買人はスケジュールに従って実行を行う。スケジュールに修正が必要な場合には、ユーザがスケジュールを修正して以前のバージョンのスケジュールを却下する(120)。その後、ユーザによって修正されたスケジュールがさらなる修正のために取引スケジューラモジュール70に戻されて、新たなスケジュールが作成される。
【0022】
図2に、さらにロバストなバージョンのシステムを示す。このバージョンでは、取引スケジューラモジュール70が現在の市況入力を受け取って使用するので、より正確なスケジュールが作成される。また、このバージョンのシステムは、どの1又は複数の仲買人を使用すべきであるか、及びその仲買人と共にどの取引アルゴリズムを使用すべきであるかについての推奨も作成する。
【0023】
図2では、取引スケジューラモジュール70が、商況モジュール(market situation module)130から市況入力を受け取る。商況モジュール130は、市場動向又は取引所動向を模倣又は複製するように設計された様々なモデルを使用して市況を示す入力を生成するために使用することができる。従って、商況モジュール130は、どのモデルを使用して市場動向を模倣したいと望むかに応じて、取引スケジューラモジュール70ための市況入力として使用できる好適なデータを作成することができる。或いは、商況モジュール130は、市況入力として使用できるデータを作成/フォーマットするのに役立つデータを受け取ることもできる。そのため、モジュール140が、市況入力に変換できるデータを作成する。このモジュール140は、既存の市場及び/又は取引所からデータを受け取るようにリアルタイムデータ又は近リアルタイムデータに基づくことができる。この(場合によってはダウ平均株価、NASDAQ総合株価指数又はFTSE100種総合株価指数などの特定の指数の値である特定の資産の価格を含む)データは、モジュール140によって受け取られた後に、パッケージ化されフォーマットされて商況モジュール130に送信される。その後、商況モジュール130は、モジュール140から受け取られたデータに基づいて、市況入力として使用されるデータセットを作成する。
【0024】
別の代替例では、モジュール140が、様々な実在する取引所及び/又は市場から実際のデータを受け取る代わりに、このような市場/取引所データを単独で生成することができる。この生成は、モジュール140内にシミュレータサブモジュールを有し、このシミュレータが受け取られたはずの様々な取引所/市場に関するデータを生成することによって行うことができる。シミュレータによって作成されるデータ、又はモジュール140が受け取るデータは、いずれも作成されたスケジュールを評価器モジュール80が査定する関連状況の一部を形成することが明らかであろう。これにより、作成されたスケジュールが、これを最初に作成するために使用されたデータ/状況と内部的に一貫性を保つことが確実になる。
【0025】
また、
図2では、スケジュール内で資産取引/売却/購入を実行する際に使用すべき特定の仲買人の推奨をシステムが作成することも明らかであろう。作成されたスケジュールを評価器モジュール80が承認すると、このスケジュールはGUI/API90を通じてユーザに送信される。これとは別に、ただしこれと並行して、評価器モジュール80は、承認済みスケジュールを仲買人選択モジュール150にも送信する。この結果、仲買人選択モジュール150は承認済みスケジュールを受け取り、スケジュール内のデータに基づいて、スケジュールにリストされた資産取引を実行するのに最も適していると思われる1又は複数の仲買人に関する推奨を作成する。この推奨の作成は、様々な仲買人の以前の取引記録、スケジュールにリストされた特定のタイプの取引、スケジュール内の取引の量、スケジュール内の取引のタイムライン、特定の仲買人を使用することに関連するコスト(例えば、特定の仲買人の取引当たりのコスト、又は各仲買人が請求する手数料)、及び各仲買人がスケジュール内の取引に使用できるアルゴリズム、のうちの少なくとも1つを査定することによって行うことができる。その後、仲買人選択モジュール150は、1又は2以上の仲買人を選択するための分析及び基準(例えば、最小の仲買人手数料、最大の時間単位当たり取引、仲買人が使用するアルゴリズムの適合性、1又は2以上の関連する取引所での好適な過去の取引履歴など)に基づいて、作成されたスケジュール内の取引を実行するために推奨される1又は2以上の仲買人を出力する。また、仲買人選択モジュール150は、作成されたスケジュールに詳述される取引/リバランシング戦略の実行のためにどの仲買人がどのアルゴリズムを使用すべきであるかを出力することもできる。
【0026】
上記から、仲買人選択モジュール150は、仲買人及びその取引アルゴリズムの推奨を生成するために各仲買人の取引履歴及び各仲買人が使用する各アルゴリズムの履歴のデータベースにアクセスできることが明らかであろう。この結果、モジュール150は、仲買人の履歴、様々なアルゴリズムの履歴及び作成されたスケジュールの内容をその推奨の基礎とすることができる。
【0027】
選択された仲買人のリストがGUI/API90に送信されると、ユーザは承認済みスケジュール及び仲買人の推奨を査定することができる。当然ながら、ユーザは、これらの推奨及び作成されたスケジュールの詳細を受け入れることも又は拒否することもできる。なお、ユーザは、GUI/API90を通じて受け取ったデータの一部又は全部を拒否及び/又は修正することができる。ユーザは、仲買人/アルゴリズムの推奨及び作成されたスケジュールを両方とも承認した場合、この内容を承認して、実行のために(単複の)選択された仲買人に送ることができる。一方で、ユーザが作成されたスケジュールを承認せずに、入力データ内に詳述されたパラメータを修正することによって1又は2以上の制約及び/又はポートフォリオデータを変更した場合には、修正されたパラメータ(及び場合によってはスケジュール)が取引スケジューラモジュール70に返送される。この結果、取引スケジューラモジュール70は、修正されたパラメータに基づいて(すなわち、修正された入力データセットに基づいて)新たなスケジュールを作成する。しかしながら、ユーザがスケジュール及び/又はパラメータのわずかな部分しか修正しないことによって入力データ(すなわち、制約及びポートフォリオデータ)が大幅に変更されず、新たなスケジュールを作成する必要がない場合には、修正されたスケジュールを実行のために仲買人に受け渡すことができる。同様に、ユーザが、作成されたスケジュールは承認したものの仲買人及び/又はアルゴリズムの推奨を承認しなかった場合には、新たな仲買人/アルゴリズムを選択できるように、このフィードバックが仲買人選択モジュール150に送信される。しかしながら、既に承認済みのスケジュールは取引スケジューラモジュールに返送されず、好適な仲買人/アルゴリズムが推奨されるまで一時停止される。好適な仲買人/アルゴリズムが選択されると、その選択された仲買人に実行のために承認済みスケジュールを送信することができる。実装に応じて、取引スケジューラモジュール70は、満足できる/好適なスケジュールを発見できるかどうかを判定できるように、制約を十分に承知するように構成することができる。このような実装では、評価器モジュールを使用して、作成されたスケジュールがどのように機能するかに関する数多くの推定を行うことができる。
【0028】
入力データは、必要な仲買人の数、及びそこから何人の仲買人を選択すべきであるかを詳述できることも明らかであろう。また、この入力データは、取引当たりにどれほどの資産を取引/売却すべきであるか(すなわち、ロットサイズ)、現在のポートフォリオ及び所望のポートフォリオの両方における各資産のアイデンティティ、現在のポートフォリオ及び所望のポートフォリオの両方における各資産のサイズ又は数、並びに現在のポートフォリオ及び所望のポートフォリオにおいて付託される各資産の価格を詳述することもできる。
【0029】
上記に加えて、システムは、市場動向、資産価格動向、並びにシステムによって影響/使用される様々な要素の動向のための様々なモデルを使用することもできる。
【0030】
モジュール140と共に使用できる上述したシミュレータは、スケジュールにリストされた様々な取引の市場への影響を推定するために使用することができる。このシミュレータは、(もしあれば)取引の影響を決定することに加えて、大口取引だけでなく様々なサイズの取引及び様々なタイミングの取引にも関与する仮定のシナリオを実行するために使用することもできる。
【0031】
評価器モジュールに関して言えば、このモジュールは、作成されたスケジュールを評価するための複数のモデルを使用することができる。評価器モジュールは、これらのモデルのうちの1つ又は2つ以上を使用して、作成されたスケジュールが所望の最終結果をもたらすかどうかを判定する。これらの又はその他のモデルは、作成されたスケジュールが市場/取引所に資産価格を損なうような影響を与えることによって所望のポートフォリオ内の資産の価値を潜在的に引き下げるかどうかを査定するために使用される。評価器モジュールは、様々な市場モデルのうちの1つ又は2つ以上を使用してスケジュールの適合性を判定するとともに、この適合性に関する適切なフィードバックを提供する。このフィードバックは、所望のポートフォリオ内の結果的な資産価値が現在のポートフォリオ内の資産価値を好適に上回るような好適なバージョンのスケジュールが作成される(又は他の何らかの基準を使用する)までスケジュールの次の反復の基礎になる。この時点で、評価器モジュールは、スケジュールが好適であり、取引スケジューラモジュールがそのバージョンのスケジュールをこれ以上改善できない旨のフィードバックを送信することができる。評価器モジュールは、シミュレータの出力、市況入力、入力モジュールに入力された入力データ、及びシステムが利用できる他のいずれかのデータを使用して、作成されたスケジュールの査定を作成できることが明らかであろう。
【0032】
本発明の1つの態様では、資産ポートフォリオの管理方法を提供する。
図2では、この方法のステップについて詳述する。方法は、入力データを受け取るステップ200から開始する。上述したように、この入力データは、現在のポートフォリオデータ、所望のポートフォリオデータ、実行時間データ、並びに資産売却及び購入スケジュールの作成に影響を与える制約を含む複数の要素を有することができる。入力データを受け取ると、必要に応じてプロセスの後の段階で使用できるように処理してフォーマットする(ステップ210)。準備が整うと、入力データを取引スケジューラモジュールに送信する(ステップ220)。同時に、取引スケジューラモジュールは、現在の又は所望のポートフォリオ内の資産に影響を及ぼし得る1又は2以上の市場/取引所の全般的状況を詳述する市況入力を受け取る(ステップ230)。上述したように、市況入力は、実際の市況、予測市況、模擬市況又は静的市況から導出することができる。次に、取引スケジューラモジュールは、残りの入力データ及び市況入力を考慮した、制約に従うスケジュールを作成する(ステップ240)。
【0033】
スケジュールが作成されると、このスケジュールを、異なる取引に対する市場又は取引所の動向を予測又は模倣しようと努める1又は2以上のモデルに基づいてスケジュールを評価する評価器モジュールに送る(ステップ250)。次に、評価器が、作成されたスケジュールが次の段階に伝えられるのに適したものであるかどうかの判定255を行う。これらのモデルに基づいて、それ以上スケジュールを改善できない場合、この反復スケジュールは承認されたとみなされ、システムの後の段階に引き継がれる。反復スケジュールが依然として欠点を有するとみなされ、又はさらに改善することができる場合、論理フローはステップ240に戻って更新されたスケジュールを作成する。このステップ240~255間のループは、受け取られた入力データ、受け取られた市況入力及び評価器モジュールからの反復フィードバックに基づいて好適に受け入れられるスケジュールが繰り返し作成されるまで繰り返される。評価器モジュールは、作成されたスケジュールが拒否された理由に関する詳細なフィードバックを取引スケジューラモジュールに提供することが明らかであろう。その後、このフィードバックは、次のバージョンのスケジュールを反復する際の反復スケジュールの編集又は修正のための基礎として使用される。従って、明確にするために言えば、取引スケジューラモジュールは、入力データ及び考慮すべき他の入力に基づいて第1のバージョンのスケジュールを作成することができる。その後、この第1のバージョンは評価器に送られ、評価器は、(複数のモデルを使用してスケジュールを査定できる)その内部の仕組みに基づいてスケジュールに関するフィードバックを提供することができる。フィードバックが第1のバージョンのスケジュールに関する問題点を示す場合には、このフィードバックが取引スケジューラモジュールに送信される。この結果、取引スケジューラモジュールは、このスケジュールを修正して、受け取ったフィードバックと以前に受け取られた他のデータとに基づく第2のバージョンのスケジュールを作成する。次に、この第2のバージョンが評価され、このバージョンが依然として不十分であれば、第nのバージョンのスケジュールが好適(すなわち、制約及び全てのデータ入力を所与とする最良のスケジュール)であると査定されるまでプロセスは継続的に繰り返される。その後、この最良のスケジュールがシステムの後の段階に引き継がれる。
【0034】
スケジュールは、好適であると評価された後にユーザに送信される(ステップ260)。同時に、このスケジュールを使用して、スケジュール内に詳述された取引を実行する好適な1又は複数の仲買人を決定する(ステップ270)。上述したように、この選択は、各仲買人の取引履歴及び各仲買人に関連するコストの分析に基づくことができる。同時に、各仲買人が使用する特定の取引アルゴリズムも分析し、どのアルゴリズムを使用すべきかについての推奨も行う(ステップ280)。これらの取引アルゴリズムは、POV、TWAP、VWAP及びその他を含むことができる。
【0035】
1又は2以上の仲買人を選択し、その取引アルゴリズムも選択した後に、これらをユーザに送る(ステップ290)。この結果、ユーザは、評価器が承認したスケジュールと、仲買人の選択及びアルゴリズムの選択とを査定して、スケジュール及び選択を承認するか否かを判定する(判定300)。ユーザは、これらの選択、又は作成されたスケジュールを承認しない場合、スケジュールの編集/修正を行うことができ(ステップ310)、修正/編集されたスケジュールを取引スケジューラモジュールに返送する(ステップ320)。ステップ320の一部として、修正スケジュールの好適な性能測定基準を提供する評価器が修正スケジュールの性能を評価することもできる。ユーザが作成されたスケジュールを承認した場合、スケジュールは、選択された(単複の)仲買人に実行のために送信される。上述したように、スケジュール又はスケジュールを作成した入力データのどこをユーザが修正したかに応じて、新たなスケジュールを作成することが必要になり得る。また、ユーザが、スケジュールは承認したものの推奨された仲買人/アルゴリズムを承認しなかった場合には、新たなスケジュールを作成する必要なく新たな仲買人/アルゴリズムを選択することが必要になり得る。
【0036】
本発明の方法は、仲買人/アルゴリズムを選択することなく実施することもできることが明らかであろう。従って、ステップ270~280は、方法の全体構造を変更することなく省略することができる。ステップ270~280を省略する場合には、スケジュールがユーザによって承認された時点で、実行のために特定の仲買人に送信することができる。これを行う場合、仲買人は、スケジュール内の取引を実行すべき1又は2以上のアルゴリズムを自由に選択することができる。
【0037】
本発明は、資産ポートフォリオのリバランシングに関して説明しているが、他の金融目的でも使用できることが明らかであろう。一例として、本発明は、所望のポートフォリオにおける特定の資産混合(mix of assets)の獲得、特定の資産の位置移動、及びポートフォリオの資産混合の調整のために使用することができる。本システムは、特定の資産又はポートフォリオの危機管理計画を準備するために使用することもできる。一例として、例えば特定の資産の価格の大幅な変化などの特定の事象又は状況が発生した場合に、作成されたスケジュール(例えば、「株式Aの価格が100下落した場合には、市場への大きな影響と共に、作成されたスケジュールを実行してポートフォリオ混合を資産Bから資産Cに移すこと」)を実行することができる。当然ながら、作成される危機管理スケジュールは、特定の市場/取引所が特定の事象にどのように反応するかを予測/予想するための仮定のシナリオとして作成することができる。
【0038】
本発明の様々な態様は、全体的なソフトウェアシステム内のソフトウェアモジュールとして実装できることが明らかであろう。従って、本発明は、実行時に様々なソフトウェアモジュールに所定の機能を実行させるコンピュータ実行命令の形態をとることができる。
【0039】
また、別途指定していない限り、本明細書における(単数の)「画像」又は(複数の)「画像」についてのあらゆる言及は、ピクセル又は画素を含む(単数の)デジタル画像又は(複数の)デジタル画像を意味することが明らかであろう。同様に、別途指定していない限り、(単数の)「オーディオファイル」又は(複数の)「オーディオファイル」についてのあらゆる言及は、「デジタルオーディオファイル」を意味する。別途指定していない限り、「ビデオ」、「ビデオファイル」、「データオブジェクト」、「データファイル」、及び他の全てのこのような用語は、デジタルファイル及び/又はデータオブジェクトを意味するものとして解釈されたい。
【0040】
本発明の実施形態は、コンピュータプロセッサ、又は方法ステップの形でプログラムされた同様の装置によって実行することも、或いはこれらのステップを実行するための手段を備えた電子システムによって実行することもできる。同様に、コンピュータディスケット、CD-ROM、ランダムアクセスメモリ(RAM)、リードオンリメモリ(ROM)又は当業で周知の同様のコンピュータソフトウェア記憶媒体などの電子メモリ手段を、このような方法ステップを実行するようにプログラムすることもできる。また、これらの方法ステップを表す電子信号を、通信ネットワークを介して送信することもできる。
【0041】
本発明の実施形態は、あらゆる従来のコンピュータプログラミング言語で実装することができる。例えば、好ましい実施形態は、手続き型プログラミング言語(例えば、「C」又は「Go」)又はオブジェクト指向型言語(例えば、「C++」、「java」、「PHP」、「PYTHON」又は「C#」)で実装することができる。本発明の別の実施形態は、予めプログラムされたハードウェア要素、他の関連コンポーネント、又はハードウェアコンポーネントとソフトウェアコンポーネントとの組み合わせとして実装することができる。
【0042】
実施形態は、コンピュータシステムと共に使用されるコンピュータプログラム製品として実装することができる。このような実装は、コンピュータ可読媒体(例えば、ディスケット、CD-ROM、ROM、又は固定ディスク)などの有形媒体上に固定された、或いは媒体を介してネットワークに接続された通信アダプタなどのモデム又はその他のインターフェイス装置を介してコンピュータシステムに送信できる一連のコンピュータ命令を含むことができる。媒体は、有形媒体(例えば、光又は電気通信回線)とすることも、又は無線技術(例えば、マイクロ波、赤外線又はその他の送信技術)を実装する媒体とすることもできる。一連のコンピュータ命令は、本明細書で上述した機能の全部又は一部を具現化する。当業者であれば、このようなコンピュータ命令は、多くのコンピュータアーキテクチャ又はオペレーティングシステムと共に使用される複数のプログラム言語で書くことができると理解しているはずである。さらに、このような命令は、半導体、磁気、光学又はその他のメモリデバイスなどのいずれかのメモリデバイスに記憶することができ、光学、赤外線、マイクロ波又はその他の送信技術などのいずれかの通信技術を使用して送信することができる。このようなコンピュータプログラム製品は、印刷又は電子資料を伴う取り外し可能媒体(例えば、パッケージソフトウェア)として配布することも、コンピュータシステム(例えば、オンシステムROM又は固定ディスク)を使用して予めロードしておくことも、或いはネットワーク(例えば、インターネット又はワールドワイドウェブ)を介してサーバから配信することもできると見込まれる。当然ながら、本発明のいくつかの実施形態は、ソフトウェア(例えば、コンピュータプログラム製品)及びハードウェアの両方の組み合わせとして実装することができる。本発明のさらに他の実施形態は、完全にハードウェアとして、又は完全にソフトウェア(例えば、コンピュータプログラム製品)として実装することができる。
【0043】
本発明を理解した人物であれば、この時点で別の構造及び実施形態又は上記の変形例を思い付くと考えられるが、これらは全て、以下の特許請求の範囲に定める本発明の範囲に含まれるように意図される。
【符号の説明】
【0044】
10 システム
20 入力モジュール
30 現在のポートフォリオデータ
40 所望のポートフォリオデータ
50 実行時間データ
60 制約
70 取引スケジューラモジュール
80 評価器モジュール
90 GUI又はAPI
100 ユーザが受け入れて仲買人に送信
110 仲買人
120 ユーザが拒否