本文へ移動
記事一覧へ戻る

注文集約・執行・アロケーション・照合・決済の全体構造


運用会社(アセマネ)の実務で、「一括発注」「バスケット」「ブロック」といった用語が混在して使われることがある。それらの意味について、フロントの執行からバックオフィスの決済に至るまでの構造と実務ルールと共に整理して記録しておく。

1. 概念整理:「何を束ねているか」による違い

一括発注(合算発注 / Order Aggregation) 複数ファンドの同一銘柄・同一売買の注文を合算して発注すること。顧客間の公平性確保、発注・約定管理の効率化、取引コストの軽減などが主な目的となる。

平均単価取引 複数の約定を合算して平均単価を算出し、その平均単価を単価とする取引を指す。複数ファンドの注文を一括発注した場合、市場で複数回に分かれて約定することがある。これらの約定について、事前に定めた配分基準に従って各ファンドへ配分する。平均単価方式を採用する場合は、全約定を集約して平均単価を算出し、その平均単価を各ファンドに適用する。

バスケット発注(Basket Order / Portfolio Trading) 複数銘柄の売買注文を、一つのバスケットとしてまとめて管理・執行する方法。例えば1ファンドのポートフォリオ売買でもバスケット発注は成立する。複数ファンドの同一銘柄については、ファンドごとの注文を一つの親注文(Block / Aggregate Order等)にまとめて一括発注することがある。

ブロック注文(親注文のシステム文脈) 注文・約定の親子構造における「親」を表す。複数ファンドの注文を束ねた親注文を指す場合がある。OMS(発注管理システム)によって「Block Order」「Parent Order」「Master Order」「Aggregate Order」など呼称は異なる。「Block Order」という言葉自体に業界共通の一意なシステム定義があるわけではなく、「アグリゲートした結果できたもの=必ずBlock Orderと呼ぶ」とは限らない点には注意が必要である。

ブロックトレード(市場の文脈) 取引規模(大口)を表す。市場価格に影響を与えるようなまとまった数量の取引。OMS上の親注文(Block Order)とは別概念なので注意が必要。

2. 典型的なOMSのデータ構造(バスケットとブロックと一括発注の関係)

複数ファンドで複数銘柄を売買する場合、OMS上では以下のような階層構造になることが多い(※あくまで典型的なモデルであり、システムによって異なる)。

【バスケット】
(複数銘柄の売買をまとめた取引単位)
│
├─ [銘柄A] トヨタ自動車
│ │
│ └─【ブロック注文 / Block Order・Parent Order】
│     買 10,000株 ← 複数ファンドの注文を集約
│     │
│     ├─ ファンド①:5,000株
│     ├─ ファンド②:3,000株
│     └─ ファンド③:2,000株
│
└─ [銘柄B] ソニーグループ
  │
  └─【ブロック注文 / Block Order・Parent Order】
      買 5,000株 ← 複数ファンドの注文を集約
      │
      ├─ ファンド①:2,000株
      └─ ファンド②:3,000株

3. 注文 → 約定 → 配分 → 決済 の全体フロー

実務上重要なのは、市場で複数回に分かれて約定(Execution)したものが、どのように集約され、最終的にファンドごとに配分(Allocation)されるかという流れである。

1. 運用判断 ファンドA:トヨタ 5,000株買 ファンドB:トヨタ 3,000株買 ファンドC:トヨタ 2,000株買

2. 注文集約・ブロッキング A~Cファンドの注文を集約し、合計10,000株のブロック注文として発注する。

3. 市場執行(Execution) 市場で複数回に分かれて約定する ・Execution① 3,000株 @2,490円 ・Execution② 4,000株 @2,500円 ・Execution③ 3,000株 @2,510円

4. 約定集約 複数Executionを親注文レベルで集約して管理する。平均単価方式を採用する場合は、総約定金額÷総約定数量により平均単価(ここでは2,500円)を算出する。

5. アロケーション(配分) 事前に定めたルールに従い、各ファンドへ配分 ・A:5,000株 ・B:3,000株 ・C:2,000株

6. ファンド別取引(最終単価) ・A:5,000株 @2,500円 ・B:3,000株 @2,500円 ・C:2,000株 @2,500円

7. 決済(Settlement) ファンド別口座・カストディ口座等で、株式・資金の受渡を実行

4. 照合(Reconciliation)とコンファメーション(Confirmation)の多層的な構造

照合業務は注文、約定、アロケーション、証券会社との確認、カストディとの決済、計理システムのポジションなど、システムや関係者間で複数の照合が存在する。 ここで押さえておくべきは、Confirmation(約定内容の確認情報・確認書)は「照合する対象」であり、Reconciliation(照合)は「照合する行為」であるという整理だ。つまり「コンファメーションを照合する(リコンサイルする)」という表現が正確である。代表的には以下の2段階に整理して捉えると分かりやすい。

約定レベルの照合 運用会社トレーダーと証券会社ブローカー等の間で行われる。照合単位は注文・約定(複数Executionをまとめた親注文を含む)。証券会社から送付されるコンファメーションをもとに、銘柄、合計株数、執行単価、手数料等を自社システムと照合(Reconciliation)する。この段階では、主として親注文・約定レベルの内容を確認し、ファンド別の最終配分は照合対象としない。

決済・残高レベルの照合 運用会社と証券会社・信託銀行等の決済関係者の間で行われる。照合単位はファンド・口座別(アロケーション単位)。最終的な決済や資産管理の場面では、ファンド・口座単位で株数や受渡代金等を確認することになる。(※典型的な国内投信の3者間照合のほか、外国資産におけるグローバルカストディアンを交えた複雑な経路など多様な形がある)

5. 一括発注・アロケーションにおける主要な実務ルール

複数ファンドの注文を一括発注する場合、金融庁の監督指針や社内規程に基づき、公平性を確保するための厳格なルールが求められる。

事前に配分基準を定める(Pre-allocationの徹底) 事後的に「良い単価を特定のファンドに割り振る」ような利益相反(チェリーピッキング)を防ぐため、発注前に、各ファンドへの配分方法や配分基準をあらかじめ定めておくこと(プリアロケーション / Pre-allocation)が重要である。

不正なポストアロケーションの禁止と職務分離 約定後にシステムが事前に設定されたルールに基づいて各ファンドへ自動配分する「正常なポストアロケーション」は、実務上の通常のプロセスである。問題となり固く禁止されているのは、「約定結果を見た後、担当者が裁量で恣意的に有利な約定を特定ファンドへ割り当てること(不正な事後配分)」である。 コンプライアンス上の職務分離の観点からは、以下のように役割が分担される。

  • FM(運用部門):「どのファンドに何株」というオーダーを入力し、プリアロケーション(事前配分)のルールを決定する。
  • TR(トレーディング部門):注文を束ねて市場で執行し、約定結果をOMSに登録する(正常なシステム処理としてのポストアロケーションのトリガーとなる)。TRに配分比率を変更する権限はない。
  • OMS(システム):TRが約定結果を入力すると、プリアロケーションのルールに従い、自動的に各ファンドへの事後配分を計算・確定させる。

平均単価方式の採用 一括発注において平均単価方式を採用する場合、複数の約定を合算して平均単価を算出し、その平均単価で各ファンドに配分する。平均単価は「総約定金額÷総約定数量」で算出する方法などが用いられ、これにより全ファンドが同一単価で約定した扱いになる。

内出来(一部約定)時の配分基準 注文数量の一部しか約定しなかった場合、事前に定めた配分基準に従って各ファンドへ配分する。総約定数量÷総発注数量を各ファンドの注文数量に乗じる「比例配分(プロラタ配分)」は、その代表的な方法の一つである。

端数処理の事前ルール化 比例配分等によって取引単位に満たない端数が発生する場合の処理方法も、あらかじめ定めておく必要がある。事前に定めたルールによらず、恣意的に配分先を決定することは認められない。

6. ファンド別に発注するケース(非合算発注)

複数ファンドの同一銘柄・同一売買の注文であっても、必ずしも一括発注するとは限らない。注文条件や運用上の事情に応じて、ファンドごとに分けて発注する場合がある。

あえて分ける主な理由

  • 顧客ごとに証券会社、執行条件、手数料その他の取引条件が異なる場合(SMAや年金基金等)。
  • 大口解約対応等で、特定のファンドのみ執行スピードやアルゴリズムを変える必要がある場合。
  • 流動性や注文サイズ、外国株の市場慣行等による制約がある場合。
  • 注文数量や市場の流動性、取引市場・商品固有の市場慣行等により、一括発注が適さない場合。

付録:現場のリアルな会話と頻出用語(フレーズブック)

アセマネのフロント・ミドル・バックオフィスの実務では、以下のような会話が日常的に交わされる。

「A・B・Cファンドの注文を銘柄ごとにアグリゲートし、ブロック注文として発注する。約定後、コンファメーションを照合し、各ファンドへアロケートして計上する。」

このように、業務とシステム(OMS等)の境界では様々な専門用語が飛び交う。実務用語の意味と「現場での使われ実感」を以下にまとめる。

用語 実務での意味 使われ頻度・体感
Order 注文 「オーダー」「注文」ともに非常によく使う
Basket Order バスケット注文 「バスケット」が定着しており、日本語への置き換えはほぼしない
Aggregate / Aggregation 複数注文を集約する/集約 「アグリゲートする」が自然。実務でもよく使う
Block Order 複数ファンド分をまとめたブロック注文・親注文 「ブロックオーダー」「ブロック注文」の両方を使う
Execution 約定・執行 「Execution」「約定」ともに使う。文脈によって使い分ける
Transaction 売買などの取引記録。約定・アロケーション後に、ファンド・口座単位の取引として管理されるデータを指すことが多い 「トランザクション」「Transaction」がシステム・会話の両方で頻出
Fill 注文の約定。部分約定・全約定を含む トレーディング周辺では「Fillした」「Fill数量」など普通に使う
Allocation 約定を各ファンドへ配分すること 「アロケーション」「アロケートする」「配分する」のいずれも使う
Confirmation 約定内容の確認書・確認情報 「コンファメーション」がかなり定着。日本語に置き換えることは少ない
Reconciliation システム・関係者間の取引内容等の照合 「Reconciliation」「リコン」「照合」ともに使う
Booking 取引をシステムへ計上・登録すること 「Bookingする」「計上する」ともに使う
Settlement 証券・資金の決済・受渡 「Settlement」「決済」ともに非常によく使う
Trade Date 約定日 「Trade Date」「約定日」ともに使う
Settlement Date / Value Date 決済日・受渡日 「Settlement Date」「Value Date」「決済日」など、商品・業務によって使い分ける
Position 保有ポジション・残高 「ポジション」が一般的。日本語の「保有残高」よりそのまま使うことが多い
Cash 現金・資金残高 「Cash」「キャッシュ」「資金」ともに使うが、「Cash」がシステム項目名等でも頻出
記事一覧へ戻る

このサイトについて

Asset Management Notesは、資産運用業界で働く運営者が、実務にまつわるさまざまなテーマを取り上げる個人運営サイトです。

日々の業務で得た知識や、気になって調べたこと、整理しておきたい仕組みや考え方などを、分野を問わず書き留めています。

運営者について

資産運用会社に勤務しています。日々の業務で培った経験を生かしながら、記事を執筆しています。ご意見・お問い合わせは、お問い合わせフォームからお寄せください。

記事について

記事の作成にあたっては、公表資料や各種データを参照し、できる限り正確でわかりやすい内容を心がけています。なお、掲載内容は運営者個人の見解であり、所属する組織の見解を示すものではありません。