💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

원문 렌더가 준비되기 전까지 텍스트 가이드로 표시합니다.

はじめに

投資銀行(IB)のシステムというと、多くの人は華やかなトレーディング画面や超低遅延のマッチングエンジンを思い浮かべます。しかし実際のIB部門のシステムは、一本の長いパイプラインに近いものです。ディールを発掘し、デューデリジェンスで精査し、価格を付け、証券として発行し、取引し、最後には現金と証券を実際に交換する決済(settlement)まで、その流れ全体がソフトウェアとして実装されています。

本記事は、その全体の流れをディールから決済まで一枚の絵としてつなぎ合わせることに焦点を当てます。特に、フロント/ミドル/バックオフィスという3層構造、注文を扱うOMSと執行を扱うEMS、プレトレード・ポストトレードの限度管理、T+1決済サイクルと中央清算機関(CCP)、そして時価・参照・ポジションというデータ層までを扱います。最後には、メインフレームとバッチに代表されるレガシーを、イベント駆動・ストリーミングへと現代化していく方向性も整理します。

先に一つお断りしておきます。本記事は一般的なシステム・アーキテクチャの教育的な解説であり、投資助言や法的助言ではありません。決済サイクル、清算ルール、報告義務といった細部は、管轄地域(jurisdiction)や機関によって異なる場合があります(may vary by jurisdiction and firm)。実際の実装や規制の適用については、必ず所属機関のコンプライアンス部門にご確認ください。本記事で示すコードやスキーマは概念説明のための例であり、そのまま本番で使うためのものではありません。

IBの業務ドメインと全体の流れ

大きく見ると、IBは資本を調達したい発行体(issuer)側と、資本を運用したい投資家(investor)側をつなぐ仕事です。その間で銀行は、助言し、証券を引受・発行し、市場で取引を仲介し、自己勘定でも取引します。これらの活動はすべて最終的に「取引(trade)」という単位に収束し、その取引は必ず決済で締めくくられます。

全体を一つのライフサイクルとして描くと、次のようになります。

ディールソーシングデューデリバリュエーション発行トレーディング決済

(Sourcing) ──▶ (Diligence) ──▶ (Valuation) ──▶ (Issuance) ──▶ (Trading) ──▶ (Settlement)

│ │ │ │ │ │

│ 機会の発掘 │ 財務・法務・ │ DCF、相対価値 │ プライシング、│ 注文・執行、 │ マッチング、確認、

│ CRM、パイプライン │ 事業のレビュー │ リスク評価 │ ブックビル、 │ 約定、ポジション │ 清算、現金と

│ │ データルーム(VDR) │ │ 配分 │ 反映 │ 証券の交換

▼ ▼ ▼ ▼ ▼ ▼

[フロントオフィス] ──────────────────────────────────▶ [ミドルオフィス] ────▶ [バックオフィス]

ディール・取引を創出リスク・統制決済・記録

前半(ソーシング、デューデリ、バリュエーション、発行)は助言・引受業務に近く、後半(トレーディング、決済)は資本市場・セカンダリーマーケットに属します。一つのディールが発行を経て市場に出ると、そこからは無数の取引に分かれ、毎日のように取引され決済されます。つまりディールは「一度」起きますが、その成果物である証券の取引と決済は「継続的に」起き続けます。

各段階のシステム観点の特徴を整理すると、次のようになります。

| --- | --- | --- | --- |

この表で注目すべきは、左に行くほど低頻度・文書中心で、右に行くほど高頻度・トランザクション中心になるという点です。そのため設計の力点も異なります。前段は協業とアクセス制御が、後段は整合性とスループットが核心になります。

フロント/ミドル/バックオフィスの3層アーキテクチャ

IBシステムを組織の観点で切るとき、最も広く使われる軸がフロント/ミドル/バックオフィスです。この3層は物理的な部門区分であると同時に、システムの責務の境界でもあります。

┌───────────────────────────────────────────────────────────────────┐

│ FRONT OFFICE │

│ 収益を生む最前線。ディール・取引を作り出す。 │

│ - ディールメーカー/バンカー: ソーシング、デューデリ、評価、発行 │

│ - トレーダー/セールス: 気配、注文、執行 │

│ システム: CRM、プライシング、OMS、EMS、市場データ端末 │

└───────────────────────────────────────────────────────────────────┘

│ 取引の捕捉(trade capture)

▼

│ MIDDLE OFFICE │

│ 統制と検証。フロントが作った取引を守り、整える。 │

│ - リスク管理: 市場/信用/流動性リスク、限度監視 │

│ - 取引検証: trade validation、P&L算出 │

│ - コンプライアンス: 規制点検、監視 │

│ システム: リスクエンジン、限度管理、P&Lシステム │

│ 検証済み取引(confirmed trade)

▼

│ BACK OFFICE │

│ 記録と完結。取引を実際の現金・証券の移動として締めくくる。 │

│ - 決済: マッチング、確認、清算、決済 │

│ - 会計・照合: 元帳記録、照合(reconciliation) │

│ - カストディ: 保管、コーポレートアクション │

│ システム: 決済エンジン、元帳、照合システム │

この3層の責務を比較すると、次のようになります。

| --- | --- | --- | --- |

ここで重要な考え方は、一つの取引が3層を通過しながら状態を変えるという点です。フロントで「約定」した取引は、ミドルで「検証」され、バックで「決済」されます。この流れを滑らかにつなぐのが、いわゆるSTP(Straight-Through Processing)、すなわち人の介入なしに取引を最初から最後まで自動で流す処理です。STP率が高いほど、誤りと遅延が減ります。

OMSとEMS — 注文管理と執行管理

フロントオフィスのトレーディングの心臓部は、OMSとEMSという二つのシステムです。名前が似ていて紛らわしいのですが、役割は明確に異なります。

- OMS(Order Management System、注文管理システム)は「何を、どれだけ、誰のために」注文するかを管理します。ポートフォリオマネージャーの指示を受けて注文を生成し、プレトレード限度点検を通し、約定結果をポジションと会計に反映します。視点はポートフォリオ・コンプライアンス・記録にあります。

- EMS(Execution Management System、執行管理システム)は「どのように」注文を市場で執行するかを管理します。複数の取引所・流動性プールに注文をルーティングし、アルゴリズム(例: VWAP、TWAP)で細かく分割して執行し、リアルタイムの時価を見ながら約定品質を最適化します。視点は市場・速度・約定品質にあります。

二つのシステムの関係と注文の流れを描くと、次のようになります。

ポートフォリオマネージャー

│ 注文意図(order intent)

▼

┌──────────────┐ 事前限度点検OK ┌──────────────┐

│ OMS │ ─────────────────────▶ │ EMS │

│ 注文生成 │ │ スマートルート │

│ 事前限度点検 │ ◀───────────────────── │ アルゴ執行 │

│ ポジション反映 │ 約定報告(fills) │ 複数会場 │

└──────────────┘ └──────┬───────┘

│ │ 注文ルーティング

│ 約定→ポジション・会計 ▼

▼ ┌──────────────┐

[ミドル・バックオフィスへ] │ 取引所/ECN/ │

│ ダークプール/CCP│

└──────────────┘

多くの機関では、OMSとEMSを一つに統合したOEMSを使うこともあります。二つの境界は機関やベンダーによって異なる場合があります。以下の表で主要な違いを整理します。

| 観点 | OMS | EMS |

| --- | --- | --- |

| 核心の問い | 何を、どれだけ注文するか | どのように執行するか |

| 主な視点 | ポートフォリオ、コンプラ | 市場、約定品質 |

| 代表的機能 | 注文生成、事前限度、ポジション | ルーティング、アルゴ、リアルタイム時価 |

| 遅延感度 | 相対的に低い | 非常に高い |

| 主な利用者 | PM、ミドルオフィス | トレーダー |

| データ保持 | 長期(監査・記録) | 短期(執行の窓) |

OMSの注文ステートマシン

注文は生きて動くオブジェクトです。生成され、承認され、市場に出て、部分・全量約定し、取り消されるか拒否されます。この状態遷移を明確なステートマシンとしてモデル化することが、OMS設計の核心です。以下は概念を示すPythonの例です。

from enum import Enum

class OrderState(Enum):

NEW = "new" # 生成済み(未検証)

PENDING_RISK = "pending_risk" # 事前限度点検の待機

APPROVED = "approved" # 限度通過、執行準備

ROUTED = "routed" # 市場/EMSへ送信済み

PARTIALLY_FILLED = "partially_filled"

FILLED = "filled" # 全量約定

CANCELLED = "cancelled"

REJECTED = "rejected" # 限度違反などで拒否

許可された遷移のみ定義(それ以外の遷移はエラー)

ALLOWED = {

OrderState.NEW: {OrderState.PENDING_RISK, OrderState.REJECTED},

OrderState.PENDING_RISK: {OrderState.APPROVED, OrderState.REJECTED},

OrderState.APPROVED: {OrderState.ROUTED, OrderState.CANCELLED},

OrderState.ROUTED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

OrderState.REJECTED,

OrderState.PARTIALLY_FILLED: {

OrderState.PARTIALLY_FILLED,

OrderState.FILLED,

OrderState.CANCELLED,

}

def transition(current, target):

if target not in ALLOWED.get(current, set()):

raise ValueError(f"invalid transition: {current} -> {target}")

return target

例: 正常な流れ

state = OrderState.NEW

state = transition(state, OrderState.PENDING_RISK)

state = transition(state, OrderState.APPROVED)

state = transition(state, OrderState.ROUTED)

state = transition(state, OrderState.PARTIALLY_FILLED)

state = transition(state, OrderState.FILLED)

print("最終状態:", state.value)

このように許可遷移を明示すれば、たとえば「すでに決済済みの注文を再ルーティングする」といった不可能な状態移動を、コードレベルで防げます。終端状態(FILLED、CANCELLED、REJECTED)からはそれ以上の遷移がない点も重要です。

執行・約定メッセージのスキーマ

注文と約定はシステム間をメッセージで行き交います。業界標準はFIXプロトコルですが、内部のイベントバスではJSONのような形式で表すこともあります。以下は約定(execution report)メッセージを概念的に表した例です。

{

"message_type": "execution_report",

"order_id": "ORD-2026-0007781",

"client_order_id": "PM-ALPHA-4412",

"exec_id": "EXC-99381",

"symbol": "AAPL",

"side": "buy",

"order_qty": 10000,

"cum_qty": 6000,

"leaves_qty": 4000,

"last_qty": 2000,

"last_price": 231.45,

"avg_price": 231.10,

"currency": "USD",

"exec_type": "partial_fill",

"order_status": "partially_filled",

"venue": "XNAS",

"transact_time": "2026-07-01T14:32:05.123Z",

"settlement_date": "2026-07-02"

}

ここでcum_qty(累積約定)、leaves_qty(残量)、avg_price(平均約定価格)は、部分約定を扱う際の核心フィールドです。settlement_dateが取引日(transact_time)の翌営業日として押されている点に注目してください。これが後で扱うT+1決済サイクルです。

リスクと限度の管理

取引が増えるほど、統制がなければリスクは瞬く間に膨らみます。そこでミドルオフィスは限度(limit)を設定し、取引の前後でこれを監視します。ここでプレトレード限度(pre-trade limit)とポストトレード限度(post-trade limit)を区別することが重要です。

┌──────────────────────────────────────┐

注文生成 ────▶ │ PRE-TRADE 限度点検 │

│ - 注文単位の最大数量/金額 │

│ - 銘柄・セクター・通貨別のエクスポージャ │

│ - 信用限度(カウンターパーティ) │

│ 判定: 通過 → 執行 / 違反 → 拒否・警告 │

└──────────────────┬───────────────────┘

│ 通過

▼

執行・約定

│

┌──────────────────▼───────────────────┐

ポジション更新 ─▶│ POST-TRADE 限度監視 │

│ - 累積ポジション・VaR・損失限度 │

│ - 日中/日末エクスポージャ │

│ 判定: 超過 → 通知・ヘッジ・強制手仕舞い │

└──────────────────────────────────────┘

- プレトレード限度は、注文が市場に出る前に止める「予防的」統制です。遅延に敏感で、非常に速く(通常ミリ秒単位で)判定する必要があります。そのため限度データはメモリにキャッシュして点検することが多いです。

- ポストトレード限度は、約定後に累積したポジション・損益を監視する「検知的」統制です。VaR(Value at Risk)などのリスク指標を再計算し、限度超過時に通知を送り、ヘッジや削減を検討させます。

限度管理でよくある落とし穴は「限度の二重計上」問題です。プレトレード限度で予約(reserve)したエクスポージャと、実際に約定後に反映されたエクスポージャがずれると、限度を実際より大きくまたは小さく認識してしまうことがあります。そこで、注文生成時に限度を予約し、約定・取消・拒否時に正確に戻す整合性管理が不可欠です。具体的な限度の種類や算式は、機関・規定によって異なる場合があります。

決済と清算 — T+1の世界

取引が約定したら終わり、ではありません。買った人は代金を払わねばならず、売った人は証券を渡さねばなりません。この「現金と証券の実際の交換」が決済(settlement)であり、その間で債務を相殺・保証する過程が清算(clearing)です。

まず核心となる三つの概念を整理します。

- 決済サイクル(settlement cycle): 取引日(T)から何日後に決済するか。T+1は取引日の翌営業日決済を意味します。多くの市場がかつてのT+2からT+1へ移行してきました。ただし商品・市場・管轄によって異なる場合があります。

- CCP(Central Counterparty、中央清算機関): 買い手と売り手の間に入り、それぞれの取引相手方になる機関です。これにより「相手が履行しなかったらどうしよう」というカウンターパーティリスクをCCPが吸収します。

- DVP(Delivery versus Payment、証券・代金の同時決済): 証券の引渡しと代金の支払いを原子的に結び、片方だけが履行される状況を防ぐ原則です。「代金は受け取ったのに証券を受け取れない」という事故を防ぎます。

約定から決済までの流れをシーケンスで描くと、次のようになります。

トレーディング CCP(清算) CSD(振替決済) 現金決済

(取引の約定) (支払/銀行)

│ │ │ │

T │ 約定(match) │ │ │

│────────────────▶│ │ │

│ │ ノベーション(novation) │

│ │ 買い/売りの相手方 │ │

│ │ としてCCPが介入 │ │

│ │ ネッティングで │ │

│ │ 決済件数を削減 │ │

│ │ │ │

T │ 確認(confirm) │ │ │

│ および指示(instruct)│────────────────▶│ │

│ │ │ 決済指示の照合 │

│ │ │ │

T+1│ │ DVP決済の実行 │ │

│ │ 証券引渡し ◀──────▶│ 代金支払 │

│ │ │◀───────────────▶│

│ │ │ (同時・原子的) │

▼ ▼ ▼ ▼

ポジション確定リスク消滅保有の移転資金の移動

T+2からT+1へ決済サイクルが短くなる流れは、システムに相当な負担を与えます。なぜなら「確認・指示・資金準備」を一日以内に終えなければならないからです。二つの方式のシステム的な含意を比較すると、次のようになります。

| 観点 | T+2(伝統) | T+1(短縮) |

| --- | --- | --- |

| 決済の余裕 | 二日 | 一日 |

| 後方処理 | 夜間バッチでも可能 | 当日締め・自動化の要求が強まる |

| 誤り訂正 | 相対的に余裕 | 訂正時間が切迫、STP必須 |

| 資金・証券の準備 | 余裕あり | 事前確保・予測が重要 |

| カウンターパーティリスク | 露出期間が長い | 露出期間が短い(改善) |

| システム要求 | バッチ許容 | 準実時間・イベント駆動が望ましい |

ここから得られる教訓は、決済サイクルの短縮が単なるルール変更ではなく、後方システムをバッチから準実時間へ押し出す圧力だという点です。確認が遅れると決済失敗(settlement fail)につながり、これはコストと規制リスクを生みます。具体的な決済サイクルや清算ルールは市場・商品・管轄によって異なる場合があるため、必ず確認が必要です。

データ層 — 時価、参照、ポジション

IBシステムを支えているのは、結局データです。データは性格によって大きく三種類に分かれ、それぞれ異なる保存・更新・整合性の要求を持ちます。

┌──────────────────────────────────────────────────────────────┐

│ MARKET DATA(時価) │

│ - リアルタイムの気配・約定・指数。毎秒数千〜数百万ティック │

│ - 特性: 超高頻度、時系列、遅延に敏感 │

│ - 保存: インメモリ・時系列DB、ストリーミング │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ REFERENCE DATA(参照) │

│ - 銘柄マスタ、発行体、カレンダー、通貨、格付、識別子(ISIN等) │

│ - 特性: 低頻度変更、整合性最優先、全社共有 │

│ - 保存: リレーショナルなマスタDB、ゴールデンソース(MDM) │

└──────────────────────────────────────────────────────────────┘

┌──────────────────────────────────────────────────────────────┐

│ POSITION DATA(ポジション) │

│ - 保有数量、平均単価、損益、エクスポージャ │

│ - 特性: 取引で更新、照合が必要、監査の対象 │

│ - 保存: 元帳・ポジションストア、イベントソーシングと相性良し │

└──────────────────────────────────────────────────────────────┘

│

時価 + 参照 + ポジション ──▶ リスク・P&L・限度算出の入力

この三つのデータの性格を比較すると、次のようになります。

| --- | --- | --- | --- |

参照データは静かですが、最も危険です。銘柄識別子が一つ間違うと、その誤りがフロントからバックまで全システムへ広がるからです。そこで「ゴールデンソース(golden source)」を一つ定め、マスタデータ管理(MDM)で一元化するのが定石です。

ポジションテーブルの例

ポジションは照合と監査の対象なので、スキーマを明確に定めることが重要です。以下は概念を示すSQLの例です。

CREATE TABLE positions (

position_id BIGINT PRIMARY KEY,

account_id VARCHAR(32) NOT NULL,

instrument_id VARCHAR(32) NOT NULL, -- 参照ゴールデンソースを参照

quantity DECIMAL(20, 4) NOT NULL, -- 負ならショートポジション

avg_cost DECIMAL(20, 6) NOT NULL,

currency CHAR(3) NOT NULL,

market_value DECIMAL(20, 4), -- 時価で再評価

unrealized_pnl DECIMAL(20, 4),

as_of_date DATE NOT NULL,

last_updated TIMESTAMP NOT NULL,

CONSTRAINT uq_position UNIQUE (account_id, instrument_id, as_of_date)

);

-- 特定口座の当日ポジション照会

SELECT instrument_id, quantity, avg_cost, market_value, unrealized_pnl

FROM positions

WHERE account_id = 'ACC-ALPHA-01'

AND as_of_date = CURRENT_DATE

ORDER BY market_value DESC;

instrument_idが参照データのゴールデンソースを指す点、そして(account_id, instrument_id, as_of_date)の組み合わせに唯一性制約を置いた点が核心です。こうすれば、同じ口座・銘柄・日付についてポジションが重複記録される事故を防げます。

規制と監査

IBシステムは規制の真ん中にあります。取引は監督当局に報告されねばならず、すべての活動は事後に追跡・再現できねばなりません。システムの観点では、これは二つの要求につながります。

- 取引報告(trade reporting): 約定した取引の詳細を、定められた期限内に規制機関・取引情報蓄積機関へ報告する必要があります。報告の形式や項目は市場・商品・管轄によって異なる場合があります。

- 監査証跡(audit trail): 誰が、いつ、何を、なぜ行ったかを変更不能に記録する必要があります。一つの注文が生成され、約定し、決済されるまでのすべての状態変化を再現できねばなりません。

監査の観点で特に重要なのが不変ログ(immutable log)です。状態を上書きする代わりに、すべての変更をappend-onlyで積み上げておけば、いつでも特定時点の状態を辿り直せます。この発想は、後で扱うイベントソーシングと自然につながります。

[注文生成]──▶[限度通過]──▶[ルーティング]──▶[部分約定]──▶[全量約定]──▶[決済]

▲ ▲ ▲ ▲ ▲ ▲

└───────────┴─────────────┴────────────┴────────────┴───────────┘

すべての遷移がタイムスタンプ・行為者とともに不変ログに記録

→ いつでも特定注文の全履歴を再現可能(監査・規制対応)

ここで強調すべきは、監査の要求がアーキテクチャを規定するという点です。「後でログを付けよう」ではなく、最初からすべての状態変化をイベントとして記録するよう設計する方が、はるかに安全です。具体的な報告義務や保存期間は規定・機関によって異なる場合があるため、コンプライアンス部門との確認が必要です。

レガシーと現代化

多くのIBシステムの根は、数十年前のメインフレームと夜間バッチにあります。理由があります。安定していて、正確で、大量トランザクションに強いからです。しかしT+1決済、リアルタイムリスク、イベント駆動統合の時代には、バッチ中心の構造がボトルネックになります。

[過去: バッチ中心] [現在: イベント駆動]

昼: 取引捕捉(ファイルに蓄積) 取引発生の瞬間に

───────────────────── イベント発行(ストリーミング)

夜: 夜間バッチの実行 │

- ポジション再計算 ├─▶ リアルタイムポジション更新

- リスク算出 ├─▶ リアルタイムリスク・限度

- 決済指示の生成 ├─▶ 準実時間の決済指示

───────────────────── └─▶ 即時の監査ログ

翌日: 結果確認、誤り訂正 (遅延最小化、STP強化)

問題: 誤りが翌日にしか発見されない利点: 即時の反映・検知

決済サイクル短縮に弱い決済サイクル短縮に適合

バッチとストリーミングの特性を比較すると、次のようになります。

| 観点 | バッチ(レガシー) | ストリーミング(現代化) |

| --- | --- | --- |

| 処理時点 | 定められた時刻(主に夜間) | イベント発生の瞬間 |

| 遅延 | 時間単位 | 秒・ミリ秒単位 |

| 誤りの発見 | 次の処理サイクル | ほぼリアルタイム |

| T+1適合性 | 切迫・危険 | 適合 |

| 監査 | スナップショット中心 | イベント履歴を自然に確保 |

| 移行の難度 | 安定だが硬直 | 初期は複雑、長期は柔軟 |

現代化の方向は、たいてい「ビッグバン置換」ではなく漸進的です。レガシー元帳をそのまま残しつつ、その前段にイベントバスを置いて新しい消費者を付けていくストラングラーパターン(strangler pattern)がよく使われます。イベントソーシングを導入すると、監査証跡と再現性が自然についてくる利点もあります。ただし「バッチが悪くストリーミングが良い」という二分法は危険です。夜間精算・照合のように、バッチが依然として適した領域も多くあります。現代化は目的ではなく手段であり、どの部分をイベント化するかは機関の状況によって異なる場合があります。

よくある落とし穴

全体の流れを設計する際に、繰り返し出会う落とし穴を整理します。

- 層の境界を曖昧にする: フロントが決済ロジックを、バックがトレーディングロジックを抱えると、責務が混ざって統制が崩れます。層の境界は統制の境界です。

- 参照データの放置: 銘柄マスタの些細な誤りが全社に広がります。ゴールデンソースとMDMなしで始めると、後で手に負えなくなります。

- 限度整合性の欠落: 予約と反映がずれると、限度を誤って認識します。約定・取消・拒否時に予約を正確に戻す必要があります。

- 決済失敗の過小評価: 確認・指示の遅れは決済失敗につながり、これはコストと規制リスクを生みます。T+1には余裕がありません。

- 監査の後付け設計: ログを後で付けようとすると、再現が不可能になります。最初から状態変化をイベントとして残しましょう。

- 無分別な現代化: よく動くバッチを無理にストリーミングへ変えて、安定性を失うことがあります。目的に合わせて選びましょう。

- 時刻同期の無視: 複数システムのタイムスタンプがずれると、監査・照合がずれます。時刻同期は些細に見えて重要です。

おわりに

IBシステムは、ディールを発掘する最初の瞬間から、現金と証券が行き交う最後の決済まで、一本の長いパイプラインとしてつながっています。フロントオフィスが取引を作り、ミドルオフィスが守り、バックオフィスが完結させます。その上を、OMSとEMSを流れる注文、プレトレード・ポストトレード限度が監視するリスク、T+1とCCPが支える決済、そして時価・参照・ポジションというデータが支えています。

この全体像を理解すれば、どれか一つのシステムに手を入れるときも、その変化がパイプライン全体にどんな波紋を起こすかを見積もれます。レガシーを現代化するときも、「何を、なぜ変えるのか」を層とデータの観点で判断できます。

改めて強調しますが、本記事は一般的なアーキテクチャの教育的解説です。決済サイクル、清算ルール、報告義務といった具体的な事項は、管轄や機関によって異なる場合があります(may vary by jurisdiction and firm)ので、実際の適用の前には必ず所属機関のコンプライアンス部門および関連する専門家にご確認ください。

参考資料

- ISO 20022 金融メッセージング標準: https://www.iso20022.org/

- SWIFT(グローバル金融メッセージング): https://www.swift.com/

- DTCC(米国の清算・決済、T+1資料): https://www.dtcc.com/

- FIX Trading Community(FIXプロトコル): https://www.fixtrading.org/

- Investopedia — T+1決済の解説: https://www.investopedia.com/terms/t/t1.asp

- Central counterparty clearing (Wikipedia): https://en.wikipedia.org/wiki/Central_counterparty_clearing

- Apache Kafka ドキュメント(イベントストリーミング): https://kafka.apache.org/documentation/

- Martin Fowler — Event Sourcing: https://martinfowler.com/eaaDev/EventSourcing.html

- Delivery versus payment (Wikipedia): https://en.wikipedia.org/wiki/Delivery_versus_payment