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

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

はじめに

トレーディングシステムというと、普通は華やかなフロントオフィス — 注文執行、アルゴトレーディング、板情報 — を思い浮かべます。しかし約定1件が資金と証券の実際の移動として完結するまでには、その後ろにはるかに長い旅があります。ポジション反映、損益計算、コンファメーション(取引確認)、清算、決済指図、元帳記帳、照合まで。この旅を担うのがミドルオフィスとバックオフィスのシステムです。

バックオフィスは華やかではありませんが、**障害がそのまま金融事故になる**領域です。決済が1日遅れれば取引相手リスクとペナルティが発生し、照合のブレークを放置すれば会計監査と規制検査で問題になります。本記事では、株式・債券・デリバティブのトレード1件が約定後にどのシステムを経て最終決済と会計記帳に至るのか、その過程でどんな統制とバッチが動いているのかを、システム設計の観点でたどります。韓国の市場インフラ(韓国取引所、韓国預託決済院、韓国銀行BOK-Wire+)の文脈も併せて扱います。

本記事は技術資料であり、投資助言ではありません。

FO/MO/BOの区分とシステムマップ

証券会社・銀行のトレーディング部門のシステムは、伝統的に3つのゾーンに分けられます。

+--------------------------------------------------------------------+

| FRONT OFFICE (FO) 「取引を作る」 |

| - OMS(注文管理) / EMS(執行管理) / アルゴエンジン |

| - プライシング、気配提示、マーケットデータ |

| - トレーダーブロッター(当日取引状況) |

+---------------------------+----------------------------------------+

| 約定(execution)イベント

+--------------------------------------------------------------------+

| MIDDLE OFFICE (MO) 「取引を統制する」 |

| - トレードキャプチャ/エンリッチメント - 口座、手数料、決済情報の付与 |

| - 限度モニタリング(ポジション/与信/VaR)、リスクレポーティング |

| - リアルタイムPnL、日中ポジション管理 |

| - コンファメーション、アファメーション(機関投資家顧客) |

+---------------------------+----------------------------------------+

| 確定したトレード(confirmed trade)

+--------------------------------------------------------------------+

| BACK OFFICE (BO) 「取引を終わらせる」 |

| - 清算・決済指図の生成、決済機関連携(KSD/KRX清算/グローバルカストディ) |

| - 元帳記帳、会計連携、手数料・税金の精算 |

| - 照合(ポジション/現金/取引)、ブレーク管理 |

| - コーポレートアクション、報告書、規制報告 |

+--------------------------------------------------------------------+

中核となる原則は**職務分離(segregation of duties)**です。取引を起こす人(FO)と取引を検証・精算する人(MO/BO)は、組織図でもシステム権限でも分離されるべきです。FOのトレーダーがバックオフィスシステムの決済データを修正できる構造は、それ自体が監査の指摘事項です。

注文 → 約定 → 清算 → 決済: 商品別フロー

全体の流れをシーケンスで見ると次のとおりです。

トレーダー OMS/EMS 取引所/OTC MO(キャプチャ/ 清算機関 BO(決済) 預託/口座

|--注文------>|--執行------>| | | | |

商品ごとに清算・決済の構造が異なります。

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

設計上の示唆: トレードモデルは商品共通コア(取引識別子、当事者、数量、金額、各種日付)と商品別拡張(デリバティブの原資産・満期・証拠金、債券の経過利息など)に分離するのが保守に有利です。特に**日付の区別** — 約定日(trade date)、決済予定日(settlement date)、実際の決済日 — を最初から分けておかないと、後で収拾がつかなくなります。

ポジションと損益管理 — リアルタイムPnLとEOD評価

ポジション管理の基本は単純です。約定イベントを口座・銘柄単位で累積すればポジションになります。難しいのは損益(PnL)です。損益は2種類に分かれます。

実現損益(realized PnL)

= 売却時点で確定する損益

= (売却単価 - 保有原価単価) x 売却数量 [原価算定: 移動平均法など]

評価損益(unrealized PnL)

= 保有中ポジションの帳簿上の損益

= (現在の評価単価 - 保有原価単価) x 保有数量

日中PnL(intraday)

= 前日評価基準に対する当日変動

= 当日実現損益 + (当日評価単価 - 前日評価単価) x 保有数量 + 当日新規分の損益

リアルタイムPnLはMOの領域です。約定ストリームと相場ストリームを結合し、トレーダー・デスク・ブック単位で集計します。一方、**EOD(日次マカン)評価**はBO・リスクの公式数値です。終値(公正価値評価基準)で全ポジションを再評価し、この数値が会計元帳と規制報告の源泉になります。

EOD評価バッチの骨格(概念例)

from decimal import Decimal

def eod_valuation(positions, closing_prices, fx_rates, base_ccy="KRW"):

results = []

for pos in positions:

price = closing_prices.get(pos.instrument_id)

if price is None:

評価不能銘柄は必ず例外キューへ — ゼロで埋めてはいけない

results.append(valuation_exception(pos, reason="NO_PRICE"))

continue

mv_local = Decimal(pos.quantity) * price.clean_price

if pos.instrument_type == "BOND":

mv_local += Decimal(pos.quantity) * price.accrued_interest

fx = fx_rates.get((pos.currency, base_ccy), Decimal("1"))

mv_base = mv_local * fx

unrealized = mv_base - pos.cost_basis_base

results.append(make_valuation(pos, mv_local, mv_base, unrealized,

price_source=price.source))

return results

運用ポイント:

- **相場ソースの優先順位とフォールバック**: 終値のない銘柄(非流動の債券、非上場)には評価モデルや前日価格フォールバックのルールが必要で、どのソースで評価したかが記録されるべきです。

- **FO推定PnLとBO公式PnLの差異説明**: 2つの数値は異なり得ます(相場の時点、手数料反映の差)。差異が閾値を超えたら、締め前に説明されなければなりません。これをPnL explainプロセスと呼びます。

- **締め後の訂正(late adjustment)**: 締め後に発見されたエラーは前日データを直すのではなく、当日の訂正仕訳で反映します。締め済みの日付のデータは不変であるべきです。

リスクミドルオフィス — 限度とVaR

ミドルオフィスのもう1つの柱はリスク統制です。

- **限度モニタリング**: ポジション限度(銘柄・セクター・ブック単位)、損失限度(日中・累積の損失制限)、与信限度(取引相手別エクスポージャー)をリアルタイムまたは準リアルタイムで監視します。限度超過時の手続き(警報 → 説明 → 強制解消の有無)がシステムワークフローとして定義されるべきです。

- **VaR(Value at Risk)**: 一定の信頼水準(例: 99%)で一定の保有期間(例: 1日)に発生し得る最大損失の推定値です。ヒストリカルシミュレーション、分散共分散、モンテカルロ方式があり、いずれの方式でもポジションデータとマーケットデータの品質が結果を左右します。VaR計算自体はリスクエンジンの仕事ですが、**入力となるポジションスナップショットの正確性と適時性**はバックオフィスのデータ品質の問題です。

- **バックテスティング**: VaR推定値と実際の損益を比較してモデルを検証します。バーゼルの市場リスク規制(FRTBを含む)で要求される手続きです。

確認と照合 — コンファーム、アファーム、ブレーク管理

約定直後にもっとも重要な統制は**取引確認(confirmation)**です。自社システムの取引記録と相手方の記録が一致するかを確認する手続きです。

- 上場取引は取引所の約定データが基準になるため比較的単純です。

- OTC取引(債券、OTCデリバティブ)は両当事者がそれぞれ記録した条件を突き合わせる必要があります。電子コンファメーションプラットフォームを使うか、SWIFTメッセージで交換するか、最悪の場合はファックス・メールの手作業になります。

- 機関投資家顧客の取引には、運用会社側の確認(affirmation)と決済指図の配分(allocation: ブロック約定を複数のファンド口座に分けること)が加わります。

確認・照合で不一致が発見されると**ブレーク(break)**として登録され、解消されるまで追跡されます。

ブレークのライフサイクル:

検知(detected) --> 割当(assigned: 担当者指定)

--> 調査(investigating: 原因コード分類)

--> 解消(resolved: 訂正仕訳/相手方修正/価格訂正 ...)

--> 終結(closed: 承認者確認)

主要メトリクス: 未解消ブレーク件数 x 経過日数(aging) x 金額

3日以上経過した高額ブレークは自動エスカレーション

決済システム — DVP、韓国預託決済院、BOK-Wire+

決済(settlement)は証券と代金が実際に移動する瞬間です。中核概念は**DVP(Delivery versus Payment、同時決済)**: 証券の引渡しと代金の支払いを相互条件付きで結び、一方だけが履行される元本リスクを除去する方式です。BIS CPMIの基準ではDVPは3つのモデルに分類されます。

| モデル | 証券 | 代金 | 特徴 |

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

韓国の市場インフラ:

- **韓国取引所(KRX)**: 上場売買のマッチングと清算(CCP)。上場株式・デリバティブの中央清算機関として決済履行を保証します。

- **韓国預託決済院(KSD)**: 証券の中央預託機関(CSD)。証券の口座振替(電子登録)により証券の引渡しが行われます。株式は電子証券制度に基づき電子登録方式で管理されます。

- **韓国銀行BOK-Wire+(韓銀金融網)**: ウォンの大口決済システム(RTGS)。決済代金の最終振替が韓国銀行の当座勘定間で行われ、証券代金同時決済(DVP)がKSDと連携して処理されます。

- **決済サイクル**: KRX株式市場はT+2決済です(約定日から2営業日後)。

バックオフィスシステムの観点では、決済処理は次のステップで構成されます。

確定トレード

--> 決済指図の生成(settlement instruction)

- 相手方の決済情報(SSI: Standing Settlement Instructions)を適用

--> 指図送信(KSD連携 / グローバルはカストディアン経由のSWIFT)

--> マッチング状態の追跡(相手方指図とのマッチング有無)

--> 決済日のモニタリング(予定 vs 実際)

--> 決済完了の確認 --> 元帳記帳の確定

--> フェイル時: 決済フェイル対応フロー(後述)

SSIマスターデータの品質が決済のSTP(straight-through processing)率を決定します。相手方・通貨・商品別の決済口座情報が間違っていれば、その取引は必ず手作業になります。

SWIFTメッセージフロー — MTとMX

クロスボーダー決済とグローバルカストディ連携にはSWIFTメッセージが標準です。証券決済でよく使うメッセージ:

| 用途 | MT(従来) | MX(ISO 20022) |

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

| 証券受領指図(代金支払) | MT541 | sese.023 (RvP) |

| 証券引渡指図(代金受領) | MT543 | sese.023 (DvP) |

| 決済確認 | MT545 / MT547 | sese.025 |

| 状態・処理通知 | MT548 | sese.024 |

| 残高報告 | MT535 | semt.002 |

| 取引明細報告 | MT536 | semt.017 |

| 顧客送金 | MT103 | pacs.008 |

| 銀行間資金移動 | MT202 | pacs.009 |

フロー例 — 外貨債券をグローバルカストディアン経由で受領(RvP)する場合:

運用会社/証券会社BO グローバルカストディアン現地CSD/サブカストディアン

| | |

|--- MT541 (受領指図) --->| |

| |--- 現地指図への変換 ------>|

| |<-- マッチング/決済状態 ----|

|<-- MT548 (状態通知) ----| |

|<-- MT545 (決済確認) ----| (決済完了時) |

| | |

|<-- MT535 (残高報告 EOD)| |

運用ポイント: MTメッセージはフィールドが緩く、機関ごとに慣行が異なります。同じMT548でもステータスコードの使い方がカストディアンごとに違うため、相手機関別のパースルール(オンボーディング時に合意)が必要です。ISO 20022への移行(証券分野は進行中)は、この問題を構造化されたコードで緩和します。

元帳記帳と会計連携

すべてのトレードは最終的に会計仕訳になります。バックオフィスシステムは取引イベントを会計イベントに変換する**ポスティングルールエンジン**を持ちます。

イベント別仕訳の例(株式買い、単純化):

約定日(T): (借) 未収証券 xxx (貸) 未払金 xxx

決済日(T+2): (借) 保有証券 xxx (貸) 未収証券 xxx

(借) 未払金 xxx (貸) 現金(預け金) xxx

EOD評価: (借/貸) 評価損益 xxx (貸/借) 証券評価調整 xxx

設計原則:

- **取引システムのトレードと会計仕訳は1:Nのマッピング**であり、すべての仕訳には源泉取引の識別子が残るべきです(ドリルダウン可能)。

- **ポスティングルールはデータとして管理**: 商品・イベント・勘定のマッピングをコードにハードコーディングすると、新商品のたびにデプロイが必要になります。ルールテーブル + バージョン管理が標準的アプローチです。

- **日次マカンと総勘定元帳(GL)インターフェース**: バックオフィスの補助元帳(sub-ledger)の日計表がGLへ渡り、補助元帳とGLの残高照合が日次バッチで回るべきです。

コーポレートアクション処理

配当、無償増資、株式分割、合併、コール・プット行使 — コーポレートアクション(CA)はバックオフィスでもっともエラーが多い領域です。

- **イベント受信**: KSD・カストディアン・データベンダーからCA通知を受け取ります(SWIFT MT564系)。同じイベントが複数ソースから異なる形で届くため、**ゴールデンレコードの生成(ソース間照合)**が最初の関門です。

- **権利計算**: 基準日(record date)時点の保有数量に比率を適用します。基準日ポジションスナップショットの正確性がすべてです。貸借(貸した株・借りた株)ポジションの権利帰属の処理も必要です。

- **選択型イベント(voluntary CA)**: 株主が選択すべきイベント(有償申込、転換など)は、顧客の意思収集 → 締切 → 指図送信のワークフローと締切期限の管理が必要です。**締切を逃すと回復不能になる**代表的な業務であり、アラートとエスカレーションが必須です。

障害がそのまま事故 — 決済フェイル対応runbook

決済フェイル(settlement fail)は、予定日に証券または代金が移動できなかった状態です。原因は証券不足(売り手側)、資金不足、指図の不一致、SSIエラーなどさまざまです。

決済フェイル対応runbook(要約):

1. 検知(決済日当日、可能な限り早い時刻)

- 決済予定 vs マッチング/完了状態のモニタリングダッシュボード

- 未マッチング指図は決済日前から警報(T+1時点の未マッチング = 危険信号)

2. 分類(原因コード)

- 指図不一致(UNMATCHED) / 証券不足(LACK) / 資金不足(MONY)

- 相手方事由 / 自社事由の区別 — 責任の所在がペナルティに直結

3. 即時対応

- 指図不一致: 相手方と条件を再確認、訂正指図を送信

- 証券不足: 貸借(借入)の可能性打診、部分決済(partial)の協議

- 資金不足: 資金部署へエスカレーション、日中流動性の調達

4. 利害関係者への通知

- 顧客(機関投資家) / トレーディングデスク / コンプライアンス・リスク

- フェイルが連鎖(チェーン)を作る場合、後続決済への影響分析

5. 事後処理

- フェイルコスト/ペナルティ精算の記録

- 原因分析 → SSI整備、プロセス改善項目の登録

- 反復相手方/反復原因のレポート(月次)

欧州CSDRの決済規律(ペナルティ)制度のように決済フェイルに金銭ペナルティを課す規制が広がってきたため、フェイルのモニタリングはコスト削減に直結します。

整合性照合バッチの設計

バックオフィスの心臓は照合(reconciliation)です。最低でも3種類が日次バッチで回るべきです。

1. **ポジション照合**: 内部帳簿 vs 預託機関・カストディアン残高(MT535)

2. **現金照合**: 内部現金元帳 vs 銀行・カストディアン口座明細(MT940/camt.053)

3. **取引照合**: FOシステム vs BOシステムの当日取引(内部システム間)

ポジション照合バッチの骨格(概念例)

from collections import defaultdict

from decimal import Decimal

KEY = ("account_id", "instrument_id") # 照合キー

TOLERANCE = Decimal("0") # ポジションは許容誤差ゼロが原則

def reconcile(internal_rows, external_rows, as_of_date):

internal = aggregate(internal_rows) # key -> quantity

external = aggregate(external_rows)

breaks = []

for key in internal.keys() | external.keys():

iq = internal.get(key, Decimal("0"))

eq = external.get(key, Decimal("0"))

if abs(iq - eq) > TOLERANCE:

breaks.append({

"as_of": as_of_date,

"key": key,

"internal_qty": iq,

"external_qty": eq,

"diff": iq - eq,

"classification": classify(key, iq, eq), # 自動原因推定

})

return breaks

def classify(key, iq, eq):

自動分類ヒューリスティック: 未決済取引分、CA処理の時差、

貸借の未反映など

分類不能はUNKNOWNのまま残し、人が調査する

...

設計原則:

- **照合はスナップショット基準**: 両側のデータの基準時点(as-of)が一致すべきです。内部は締め後、外部は前日残高報告なら、その時差から偽のブレークが量産されます。

- **自動分類と自動解消**: 既知のパターン(未決済分の時差など)は自動分類・自動マッチングし、人は未知のブレークに集中させます。ただし自動解消ルール自体が監査対象なので、ルール変更の履歴を残します。

- **ブレークはデータとして管理**: 上記のブレークライフサイクル(検知→割当→調査→解消→終結)をテーブルとして持ち、エイジングレポートを自動化します。

データモデルのスケッチ

+----------------+ +------------------+ +-------------------+

+----------------+ | INSTRUCTION | +-------------------+

| trade_id PK |--+ +------------------+ | account_id |

| settle_date | | matched_status | +-------------------+

| status | | settled_at |

| version | +------------------+ +-------------------+

+----------------+ | RECON_BREAK |

| +------------------+ +-------------------+

+-------------> | POSTING (仕訳) | | break_id PK |

+------------------+ | recon_type |

| posting_id PK | | as_of_date |

| trade_id FK | | key (acct/instr) |

| event_type | | diff_amount |

| debit_account | | status / aging |

| credit_account | | assigned_to |

| amount / ccy | | resolution_code |

| posted_at | +-------------------+

+------------------+

トレードテーブルで重要なのは**バージョン管理**です。訂正(amend)・取消(cancel)は既存行の修正ではなく新バージョン行として積み上げ、常に最新有効バージョンを指すビューを置きます。決済指図・仕訳がどのトレードバージョンから生成されたかを追跡できることが、訂正処理の整合性を保証します。

落とし穴とアンチパターン

- **約定日/決済日の混同**: ポジションを「どの基準で」見るか(trade-date position vs settle-date position)が画面ごとに異なると、すべての照合が混乱に陥ります。基準を明示し、両方のビューを意図的に提供してください。

- **締め済みデータの修正**: 締め済みの日付のデータを直接UPDATEする運用慣行は、会計監査で致命的です。訂正は常に当日の反対仕訳 + 再記帳で。

- **手作業のSSI管理**: 決済フェイルの定番原因。SSI変更には4-eyes承認と有効期間を設けてください。

- **照合許容誤差の濫用**: ブレークを減らすために許容誤差を広げると照合の意味が消えます。ポジションは誤差ゼロが原則です。

- **ステータスコードの自由入力**: ブレーク原因、決済フェイル事由を自由テキストで受け取ると、統計と自動化が不可能になります。コード体系を先に設計してください。

- **CA締切期限の手動管理**: 選択型CAの締切をカレンダーと人の記憶に頼る構造は、いつか必ず事故を起こします。

- **バッチ依存チェーンの暗黙化**: 相場受信 → 評価 → 仕訳 → GL転送 → 照合の順序依存性がドキュメントにだけあってスケジューラにない場合、遅延時に部分実行で汚染されたデータが生まれます。

構築チェックリスト

- [ ] FO/MO/BOのシステム権限が職務分離の原則に従って分離されているか

- [ ] トレードモデルが訂正・取消をバージョンとして管理しているか

- [ ] 約定日基準/決済日基準のポジションが明確に区別されているか

- [ ] EOD評価の相場ソース優先順位と評価不能の例外キューがあるか

- [ ] FO推定PnLとBO公式PnLの差異説明プロセスがあるか

- [ ] コンファーム/アファームが電子化され、未確認取引のエイジングが監視されているか

- [ ] SSIがマスターデータとして管理され、変更に承認手続きがあるか

- [ ] 決済指図のマッチング状態が決済日前から追跡されているか

- [ ] 決済フェイルのrunbookと原因コード体系、エスカレーション経路があるか

- [ ] ポジション/現金/取引の照合が日次で回り、ブレークがライフサイクルで管理されているか

- [ ] 仕訳が源泉取引へドリルダウン可能で、ポスティングルールがデータとして管理されているか

- [ ] 補助元帳とGLの残高照合が自動化されているか

- [ ] CAイベントのソース間照合と選択型締切のアラートがあるか

- [ ] バッチ依存性がスケジューラ(DAG)に明示されているか

おわりに

バックオフィスシステムの価値は、普段は見えません。すべてがSTPで流れる日には、誰もバックオフィスの話をしません。しかし決済がフェイルした日、照合が崩れた日、監査が入った日 — その日に組織を守るのは、よく設計されたデータモデル、不変の履歴、自動化された照合、そして準備されたrunbookです。トレーディングシステムを作るなら、華やかなフロントと同じくらい、いやそれ以上に、データの最後の区間を堅牢に作ることをお勧めします。

参考資料

- BIS CPMI — Principles for Financial Market Infrastructures (PFMI): https://www.bis.org/cpmi/publ/d101.htm

- BIS CPMI — Delivery versus Payment in Securities Settlement Systems: https://www.bis.org/cpmi/publ/d06.htm

- 韓国預託決済院: https://www.ksd.or.kr

- 韓国銀行(BOK-Wire+): https://www.bok.or.kr

- 韓国取引所(清算決済): https://www.krx.co.kr

- 韓国金融監督院: https://www.fss.or.kr

- SWIFT — Standards (MT/MX): https://www.swift.com/standards

- ISO 20022: https://www.iso20022.org

- DTCC(米国の清算決済インフラ): https://www.dtcc.com

- ESMA — CSDR(決済規律制度): https://www.esma.europa.eu

- バーゼル委員会 — Minimum capital requirements for market risk (FRTB): https://www.bis.org/bcbs/publ/d457.htm