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

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

はじめに

銀行ITについて語られるとき、ほとんどの資料はリテールバンキング(預金・貸出・勘定系)に集中しています。しかし投資銀行(IB)部門のシステムはまったく異なる姿をしています。数百万の口座ではなく数十件のディール(案件)を扱い、毎秒数千件の取引ではなく数か月にわたるワークフローを扱います。トランザクション量は小さいものの、1件のディールの金額は数百億円から数兆円に達し、未公開重要情報(MNPI)が流れる場所であるため、統制の失敗コストは計り知れません。

本記事は、IB部門のシステムを初めて設計・保守するエンジニアのために、業務ドメインマップからディールのライフサイクル、コンフリクトチェック、チャイニーズウォール(情報遮断壁)のシステム的実装、ブックビルディング、シンジケートローン管理、ドキュメント管理、規制報告までを一枚の絵として整理します。韓国資本市場(資本市場法、金融投資業規定)の文脈も併せて扱います。

なお、本記事はシステム設計の観点からの技術資料であり、投資助言や法律助言ではありません。規制に関する内容は必ず所属機関のコンプライアンス部門にご確認ください。

IB業務ドメインマップ

IB部門は大きく5つのドメインに分けられます。

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

| Investment Banking Division |

| |

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

| | ECM | | DCM | | M&A | |

| | 市場 | | 市場 | | アドバイザリ| |

| | /CB | | /MTN | | フェアネス | |

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

| |

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

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

| |

| 共通基盤: ディールパイプライン / コンフリクトチェック / |

| チャイニーズウォール / ドキュメント管理 / |

| インサイダーリスト / 規制報告 / CRM |

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

各ドメインのシステム要件を比較すると次のとおりです。

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

| ECM | IPO、公募増資、転換社債 | ブックビルディング、需要予測、配分 | 3〜12か月 |

| DCM | 社債、ABS、MTNプログラム | 発行日程管理、プライシング、需要把握 | 1〜6か月 |

| M&A | 売手/買手アドバイザリ、バリュエーション | ディールルーム(VDR)、文書管理、コンフリクトチェック | 6〜18か月 |

リテールとの最大の違いは、**すべてのドメインがディール単位で動く**点です。システムの第一級オブジェクトは口座ではなくディールであり、チーム、文書、承認、情報アクセス権限のすべてがディールにぶら下がります。

ディールのライフサイクルとパイプライン管理

ディールは通常、次の段階を経ます。

[Origination] [Execution] [Closing] [Post-Close]

| | | |

アイデア/ピッチ --> マンデート獲得 --> デューデリ --> マーケティング/ --> プライシング

| | | ブックビルディング |

v v v | v

コンフリクトエンゲージメントディールルームインサイダー配分・決済・

チェックレター締結開設(VDR) リスト拡大手数料精算

(事前審査) |

事後管理/リーグテーブル

ディールパイプライン管理システムの中核要件は次のとおりです。

- **ステージベースの状態管理**: 各ディールは正確に1つのステージにあり、ステージ遷移は承認イベントによってのみ発生します。

- **確率加重パイプライン**: ステージ別の成約確率を掛け合わせて期待手数料収益を集計します。経営ダッシュボードの中心指標です。

- **チームメンバーシップと情報アクセスの結合**: ディールチームに追加された瞬間、チャイニーズウォール統制の対象となり、インサイダーリストの候補になります。

- **監査証跡(audit trail)**: 誰がいつどのディール情報を閲覧・変更したかをすべて残す必要があります。規制検査で最初に要求される資料です。

ステージ遷移をコードで強制することが重要です。スプレッドシートでパイプラインを管理すると、コンフリクトチェックを迂回したディールが必ず生まれます。

コンフリクトチェック — 案件を受ける前に止める

コンフリクトチェックは、新規案件を受任する前に、既存のディール・顧客関係と利益相反がないかを確認する手続きです。たとえばA社の売却アドバイザリを受任しようとしているのに、すでにB社によるA社買収のアドバイザリを担当している場合、両方を同時に受任することはできません。

システムの観点では、コンフリクトチェックは**ディール作成ワークフローのゲート**です。

-- コンフリクトチェックの中核クエリ: 同一・関連対象企業について

-- アクティブなディールが存在するかを検出

SELECT d.deal_id,

d.deal_type,

d.stage,

c.company_name,

r.relation_type -- TARGET / ACQUIRER / ISSUER / SPONSOR

FROM deal d

JOIN deal_company_rel r ON r.deal_id = d.deal_id

JOIN company c ON c.company_id = r.company_id

WHERE d.stage NOT IN ('CLOSED', 'DEAD')

AND c.company_group_id IN (

-- 新規ディール対象企業と同じ企業グループまで拡張

SELECT company_group_id FROM company

WHERE company_id = :new_deal_target_id

);

実務上の注意点:

- **企業グループ(系列会社)単位に拡張**する必要があります。対象会社だけを見ると、同一グループの系列会社ディールとの衝突を見逃します。

- 検索は**法人識別子ベース**であるべきです。社名の文字列マッチングは誤字や略称のため信頼できません。LEI(取引主体識別子)や事業者登録番号をマスターデータとして管理してください。

- 結果は自動承認ではなく**コンプライアンス担当者の判断キュー**に入ります。システムが候補を検出し、人が判断し、判断根拠が記録されます。

チャイニーズウォール(情報遮断壁)のシステム的実装

チャイニーズウォールは、IB部門(プライベートサイド、MNPI保有)とリサーチ・セールス&トレーディング部門(パブリックサイド)の間の情報の流れを遮断する統制です。韓国では資本市場法上の情報交流遮断(利益相反防止)規制として実装が義務付けられています。システム的には3つのレイヤーで実装します。

レイヤー1 — 権限(アクセス制御)

ディール情報はデフォルトでdeny-allとし、ディールチームのメンバーシップによってのみ開放します。

ディール単位アクセスポリシーの例(ポリシーエンジン入力)

policy:

resource: deal/PRJ-FALCON

default: deny

rules:

- effect: allow

subjects:

- group: deal-team/PRJ-FALCON # ディールチームメンバー

- group: compliance-surveillance # コンプライアンス(常時閲覧権)

actions: [read, write]

- effect: allow

subjects:

- group: ib-management # 部門経営陣

actions: [read-summary] # 要約のみ、文書アクセス不可

- effect: deny

subjects:

- group: research # リサーチ部門は明示的に遮断

- group: sales-trading

actions: [read, write, read-summary]

override: true # allowより優先

中核となる設計原則:

- **プロジェクトコードネーム**を使用します。ディール一覧画面でも、権限のないユーザーには実際の社名ではなくコードネームのみが見えるか、ディールの存在自体が見えないようにします。

- **ウォールクロッシング(wall crossing)**手続きをシステム化します。パブリックサイドの社員がディールに一時参加する必要がある場合、コンプライアンス承認 → インサイダーリスト登録 → 期間限定の権限付与 → 期限到来時の自動回収が1つのワークフローとして束ねられるべきです。

- 権限の付与・回収はすべてイベントとして残し、権限保有者リストの**時点照会(point-in-time query)**を可能にします。「3月15日にこのディール情報にアクセスできた人」を即座に抽出できなければ、規制検査に対応できません。

レイヤー2 — ウォーターマーク(透かし)

ディール文書は流出時に出所を追跡できる必要があります。ダウンロード・閲覧時点でユーザーごとの透かしを動的に付与します。

文書閲覧時の動的ウォーターマーク適用(概念例)

from pypdf import PdfReader, PdfWriter

from reportlab.pdfgen import canvas

from io import BytesIO

def apply_watermark(src_pdf: bytes, user_id: str, deal_code: str) -> bytes:

stamp_buf = BytesIO()

c = canvas.Canvas(stamp_buf)

text = f"{deal_code} / {user_id} / {datetime.datetime.utcnow().isoformat()}"

c.setFont("Helvetica", 7)

c.setFillColorRGB(0.6, 0.6, 0.6, alpha=0.4)

斜め方向の繰り返しウォーターマーク

c.saveState()

c.translate(300, 400)

c.rotate(45)

for y in range(-400, 400, 60):

c.drawString(-250, y, text)

c.restoreState()

c.save()

stamp_buf.seek(0)

stamp = PdfReader(stamp_buf).pages[0]

reader = PdfReader(BytesIO(src_pdf))

writer = PdfWriter()

for page in reader.pages:

page.merge_page(stamp)

writer.add_page(page)

out = BytesIO()

writer.write(out)

return out.getvalue()

可視的な透かしに加えて、メタデータやステガノグラフィーに基づく不可視の透かしを併用する機関もあります。重要なのは、透かし適用イベント自体がアクセスログと結び付いていることです。

レイヤー3 — ロギングと監視

- ディール文書の閲覧・ダウンロード・印刷・共有はすべて構造化ログとして残します(誰が、いつ、何を、どこから)。

- コンプライアンス部門が使用する**異常アクセス検知**バッチ: ディールチーム外のユーザーによるアクセス試行、短時間の大量ダウンロード、退職予定者のアクセスパターン変化などをルールで検知します。

- ログは改ざん防止のためappend-onlyストレージ(WORMストレージまたはハッシュチェーン)に保管します。適用される記録保存義務の期間を確認し、保存ポリシーを設定します。

MNPI管理とインサイダーリスト

インサイダーリストは、特定のディールの未公開重要情報にアクセスした人の名簿です。EUのMAR(市場濫用規制)は発行体とアドバイザーにインサイダーリストの作成を明示的に義務付けており、韓国でも未公開重要情報利用行為規制(資本市場法第174条)への対応のため同様の統制を運用します。

CREATE TABLE insider_list_entry (

entry_id BIGINT PRIMARY KEY,

deal_id BIGINT NOT NULL REFERENCES deal(deal_id),

person_id BIGINT NOT NULL REFERENCES person(person_id),

reason VARCHAR(200) NOT NULL, -- 登録事由(チーム、ウォールクロス、外部アドバイザー等)

obtained_at TIMESTAMP NOT NULL, -- MNPIアクセス開始時刻

notified_at TIMESTAMP, -- 本人への通知時刻(義務的告知)

removed_at TIMESTAMP, -- リスト除外時刻

removed_reason VARCHAR(200),

created_by VARCHAR(50) NOT NULL,

created_at TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP

);

-- インサイダーリストは訂正履歴まで保存する必要があるためUPDATE禁止、

-- 変更は新規row + 旧rowの無効化で処理(バイテンポラルパターン)

CREATE INDEX idx_insider_deal ON insider_list_entry (deal_id, obtained_at);

CREATE INDEX idx_insider_person ON insider_list_entry (person_id, obtained_at);

運用ポイント:

- インサイダーリストは**ディールチームのメンバーシップと自動同期**しつつ、外部者(法律事務所、会計事務所、印刷会社まで)には手動登録の経路を提供します。

- 登録時に本人へ義務的告知(MNPI保有の事実、取引制限、法的責任)を送付し、受領確認を記録します。

- 自己勘定取引の事前承認システム(PA dealing)と連携し、インサイダーリストに載っている社員が該当銘柄の取引を申請すると自動的にブロックします。

ブックビルディングシステム — 需要予測と配分

ECM/DCMディールのハイライトはブックビルディングです。機関投資家から需要(価格、数量)を受け付けて需要曲線を作り、発行価格を決定した後、物量を配分します。韓国のIPOでは機関投資家の需要予測が金融投資協会の規定に従って運営されます。

ブックビルディングシステムの中核モデルは注文(order)と配分(allocation)です。

単純化した配分エンジンの概念例

実際の配分は定性評価(アンカー投資家、長期保有性向)が組み合わさる

審査プロセスであり、以下は比例配分の骨格のみを示す。

from dataclasses import dataclass

@dataclass

class Order:

investor_id: str

quantity: int # 申込数量

limit_price: int # 希望価格、成行はレンジ上限として処理

investor_grade: str # 内部格付: ANCHOR / LONG_ONLY / HEDGE / RETAIL_INST

GRADE_WEIGHT = {"ANCHOR": 1.5, "LONG_ONLY": 1.2, "HEDGE": 0.8, "RETAIL_INST": 1.0}

def build_demand_curve(orders, price_grid):

"""価格帯別の累積需要曲線: その価格以上を提示した注文の合計"""

return {

p: sum(o.quantity for o in orders if o.limit_price >= p)

for p in price_grid

}

def allocate(orders, final_price, total_shares):

eligible = [o for o in orders if o.limit_price >= final_price]

weighted = sum(o.quantity * GRADE_WEIGHT[o.investor_grade] for o in eligible)

allocations = {}

remaining = total_shares

for o in sorted(eligible, key=lambda x: GRADE_WEIGHT[x.investor_grade], reverse=True):

share = int(total_shares * o.quantity * GRADE_WEIGHT[o.investor_grade] / weighted)

share = min(share, o.quantity, remaining)

allocations[o.investor_id] = share

remaining -= share

残余物量は端数補正ルールで再配分(省略)

return allocations, remaining

システム設計で重要な点:

- **注文の修正履歴**: ブックビルディング期間中、投資家は注文を修正・取消します。すべてのバージョンが保存されるべきで、締切時刻以降の注文はシステムが拒否しなければなりません。

- **需要曲線のリアルタイム集計**: シンジケートデスクはブックカバレッジ(需要÷供給の倍率)をリアルタイムで見ます。イベントソーシングで注文ストリームを蓄積し、マテリアライズドビューで集計する構造が適しています。

- **配分結果の説明可能性**: 配分は紛争と規制上の論点が多い領域です。配分ロジックの入力(格付、ウェイト)と手動調整の内容がすべて記録され、手動調整には理由の入力が強制されるべきです。

- **利益相反統制**: 自社運用ファンドや系列会社への配分は別の承認経路を通すか遮断します。

シンジケートローン管理 — 数年がかりの運用システム

シンジケートローンは、複数の金融機関が1つの借入人に共同で融資する構造です。アレンジャー(主幹事)がディールを組成し、エージェント銀行が融資期間を通じて利息計算、元利金の配分、借入人と参加機関の間の通知を担当します。LMA(欧州)/LSTA(米国)の標準契約が事実上の業界標準です。

システムが管理すべき中核データ:

| 領域 | 内容 |

| --- | --- |

| ファシリティ構造 | Term Loan A/B、RCFなどのトランシェ構造と限度額 |

| 参加機関の持分 | 機関別コミットメント金額、譲渡(assignment)履歴 |

| 引出・返済 | 引出依頼、利息期間、返済スケジュール |

| 利息・手数料 | 基準金利+マージン、コミットメントフィー、アレンジメントフィー、エージェントフィー |

| 配分 | 利息・元本・手数料の参加機関別按分計算と支払 |

手数料配分計算の例:

利息期間終了時の参加機関別配分計算(概念例)

from decimal import Decimal, ROUND_HALF_UP

def distribute_interest(total_interest: Decimal, participations: dict) -> dict:

"""participations: {institution_id: outstanding_amount}"""

total_outstanding = sum(participations.values())

result = {}

allocated = Decimal("0")

items = sorted(participations.items())

for inst, amount in items[:-1]:

share = (total_interest * amount / total_outstanding).quantize(

Decimal("0.01"), rounding=ROUND_HALF_UP)

result[inst] = share

allocated += share

最後の機関が端数を吸収 — 合計は必ず一致しなければならない

last_inst = items[-1][0]

result[last_inst] = total_interest - allocated

assert sum(result.values()) == total_interest

return result

運用上もっとも厄介な部分:

- **持分譲渡(セカンダリー取引)**: 参加機関が持分を他の機関に譲渡すると、その時点以降の利息・元本の配分基準が変わります。譲渡効力発生日を基準とした時点別の持分元帳が必要です。

- **端数処理ポリシー**: 配分の合計は1円単位まで元本と一致しなければなりません。端数吸収ルールを明示的に定義し、テストしてください。

- **エージェント業務の通知義務**: 金利確定、引出通知、デフォルトイベントなどには期限内の通知義務があります。ワークフローエンジンのタイマー・エスカレーション機能が必須です。

買収金融の限度とエクスポージャー管理

買収金融(LBOファイナンス、ブリッジローン)は銀行の自己資本が直接さらされる領域であり、限度管理が中核です。

- **借入人・企業グループ単位の限度**: 同一人・同一借入人への信用供与限度規制に従い、企業グループ単位でエクスポージャーを合算します。

- **引受限度 vs 保有限度**: 引受(underwriting)時点の一時的な大量エクスポージャーと、セルダウン(sell-down)後の最終保有分を区別し、それぞれに限度を設けます。セルダウンが計画どおりに進まない場合(hung deal)、保有限度を超過する状況が生じるため、システムはセルダウン計画と実績を追跡する必要があります。

- **パイプラインエクスポージャー**: まだ実行されていないコミットメント(承認済みだが未引出)も潜在エクスポージャーとして集計します。

エクスポージャー集計の概念:

総エクスポージャー(企業グループG)

= Σ 実行残高(グループ内の全借入人)

+ Σ 未引出コミットメント × 信用換算率(CCF)

+ Σ 引受ポジション(セルダウン未完了分)

限度チェックは新規ディール承認時点 + 日次バッチの両方で実行

ディールドキュメント管理 — バージョンと署名

M&Aとシンジケーションでは、文書が成果物のほぼすべてです。要件:

- **バージョン管理**: 契約書のドラフトは数十回往復します。バージョンツリー(誰がどのバージョンから分岐したか)、比較(redline)生成、最終版(execution version)の指定が必要です。

- **VDR(バーチャルデータルーム)**: デューデリジェンス段階で売手側が資料をアップロードし、買収候補が閲覧します。候補別のアクセス範囲の差別化、閲覧ログ、Q&Aワークフローが標準機能です。

- **電子署名の統合**: 署名パッケージの構成(署名者、署名位置、順序)→ 送付 → 署名完了の追跡 → 最終版の保管庫への格納までをワークフローとして束ねます。署名完了イベントがディールのステージ遷移(例: 契約締結)をトリガーするように接続すると、パイプラインのデータ品質が向上します。

- **保存とリーガルホールド**: ディールに関する紛争が発生した場合、関連文書一式に削除禁止(legal hold)をかけられる必要があります。

規制報告と韓国資本市場の文脈

韓国においてIB業務は、資本市場と金融投資業に関する法律(資本市場法)および金融投資業規定の適用を受けます。システムの観点でよく出会う報告・開示義務は次のとおりです(正確な要件は時点・機関類型によって異なるため、コンプライアンス部門への確認が必須です)。

- **証券届出書・投資説明書**: ECM/DCM発行時に金融委員会の電子開示(DART)へ提出。発行システムのディールデータが届出書作成の源泉データになります。

- **需要予測関連資料の保存**: IPO需要予測の注文・配分内訳には協会規定に基づく保存義務があります。

- **大株主・系列会社取引の報告、利益相反記録の維持**: 情報交流遮断装置の運用記録、ウォールクロッシング承認記録などが検査対象です。

- **金融監督院の検査対応**: アクセスログ、インサイダーリスト、コンフリクトチェック記録の時点照会が迅速にできる必要があります。

設計上の示唆は明確です。規制報告を別システムの仕事として後回しにせず、**ディールシステムのデータモデル自体を報告可能な形(不変履歴、時点照会)**で作るべきです。

CRMとの統合

IBのCRMは営業CRMとは性質が異なります。カバレッジバンカーが顧客企業の経営陣とのミーティング、ピッチ履歴、ディール機会を管理します。統合ポイント:

- コンフリクトチェックはCRMの関係データ(誰がどの会社をカバーしているか、過去のディール履歴)を入力として使用します。

- ディールがマンデート段階に進むと、CRMの商談(opportunity)がディールパイプラインのディールに昇格し、双方のIDが相互参照されます。

- ただし、**チャイニーズウォールはCRMにも適用**されます。ディールの詳細情報がCRMを通じてパブリックサイドに露出すると、統制全体が崩壊します。CRMにはディールの存在とコードネームのレベルのみを同期するのが安全です。

データモデルの例

中核エンティティの関係をERDで整理すると次のとおりです。

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

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

| company_id PK|---+ | deal_id PK | +---| person_id PK |

| lei | +--<-| deal_type | | | side (pub/pr)|

+--------------+ | expected_fee | |

^ | probability | |

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

| | | | |

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

| DEAL_COMPANY_ |---------+ | | |

| REL | +--------+-----+ +-----+------+ +-+----------+

| ACQUIRER/ | +--------------+ +------------+ | LIST_ENTRY |

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

| order_id PK |

| deal_id FK | +-----------------+ +----------------------+

| qty / price | +-----------------+ +----------------------+

| superseded_by | | facility_id PK |---| facility_id FK |

+---------------+ | deal_id FK | | institution_id |

| tranche_type | | commitment_amt |

+---------------+ | limit_amt | | effective_from/to |

| ALLOCATION | | margin_bps | +----------------------+

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

| order_id FK |

| alloc_qty |

| adjusted_by |

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

モデリング原則:

- **履歴は不変**: 注文、配分、チームメンバーシップ、インサイダーリストはUPDATEの代わりに、新規行 + 有効期間(effective_from/to)パターンを使います。

- **文書はハッシュで完全性を保証**: 最終版のSHA-256を記録し、事後の改ざんを検知します。

- **すべての金額は通貨とともに**: クロスボーダーディールが一般的なので、amount + currencyのペアを基本とします。

ワークフローエンジン設計

ディールのライフサイクル、ウォールクロッシング、与信承認、署名追跡はすべてワークフローです。自作するにせよエンジン(Camunda、Temporalなど)を使うにせよ、IBドメインで要求される特性は次のとおりです。

ディールのステージ遷移を明示的な状態機械で強制する例

from enum import Enum

class Stage(Enum):

PITCH = "PITCH"

CONFLICT_CHECK = "CONFLICT_CHECK"

MANDATED = "MANDATED"

DUE_DILIGENCE = "DUE_DILIGENCE"

MARKETING = "MARKETING"

PRICING = "PRICING"

CLOSED = "CLOSED"

DEAD = "DEAD"

TRANSITIONS = {

Stage.PITCH: {Stage.CONFLICT_CHECK, Stage.DEAD},

Stage.CONFLICT_CHECK: {Stage.MANDATED, Stage.DEAD},

Stage.MANDATED: {Stage.DUE_DILIGENCE, Stage.DEAD},

Stage.DUE_DILIGENCE: {Stage.MARKETING, Stage.DEAD},

Stage.MARKETING: {Stage.PRICING, Stage.DEAD},

Stage.PRICING: {Stage.CLOSED, Stage.DEAD},

}

REQUIRED_APPROVALS = {

(Stage.PITCH, Stage.CONFLICT_CHECK): ["team_head"],

(Stage.CONFLICT_CHECK, Stage.MANDATED): ["compliance", "business_head"],

(Stage.MARKETING, Stage.PRICING): ["syndicate_head", "compliance"],

}

def transition(deal, target: Stage, approvals: set, actor: str):

if target not in TRANSITIONS[deal.stage]:

raise ValueError(f"illegal transition {deal.stage} -> {target}")

needed = set(REQUIRED_APPROVALS.get((deal.stage, target), []))

if not needed.issubset(approvals):

raise PermissionError(f"missing approvals: {needed - approvals}")

audit_log(deal.deal_id, deal.stage, target, actor, approvals)

deal.stage = target

加えて必要なもの:

- **タイマーとエスカレーション**: 通知期限、承認SLAの超過時に上位者へアラート。

- **補償処理**: ディールがDEADになったら、インサイダーリストの整理、権限の回収、VDRの閉鎖が連鎖的に実行されるべきです。この後処理が手動だと必ず漏れます。

- **ワークフロー履歴自体が監査資料**: 誰が承認し、どの根拠文書が添付されたかが遷移イベントに紐付くべきです。

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

- **スプレッドシートのパイプライン**: もっとも一般的で、もっとも危険です。コンフリクトチェックと権限統制が迂回されます。移行期にはスプレッドシートのインポート機能を提供してでも、システムに引き込んでください。

- **社名の文字列マッチングに基づくコンフリクトチェック**: 法人識別子マスターなしで始めると、結果を信頼できません。

- **権限回収の漏れ**: ディール終了・チーム離脱時に権限が残っているアカウントは、検査での定番指摘事項です。期限付き付与(grant with expiry)設計でデフォルトを安全にしてください。

- **配分ロジックのブラックボックス化**: 説明不能な配分は規制リスクです。入力と手動調整をすべて記録してください。

- **シンジケートローンの端数残差の放置**: 1円の差が数年間蓄積して照合のブレークを生みます。

- **ディールシステムとCRMの無差別な双方向同期**: チャイニーズウォールに穴を開けます。同期範囲を明示的に定義してください。

- **ログは残すが照会できない構造**: 時点照会ができない監査ログは検査対応では役に立ちません。

構築チェックリスト

- [ ] 法人マスター(グループ・系列関係を含む)とLEIベースの識別体系があるか

- [ ] ディール作成前のコンフリクトチェックがワークフローのゲートとして強制されるか

- [ ] ディール情報のデフォルトポリシーがdeny-allで、チームメンバーシップによってのみ開放されるか

- [ ] 権限のない画面ではコードネームが実名を代替しているか

- [ ] ウォールクロッシングが承認-登録-期間限定権限-自動回収の単一ワークフローか

- [ ] インサイダーリストが不変履歴 + 時点照会をサポートしているか

- [ ] 文書の閲覧・ダウンロードにユーザー別の透かしとアクセスログが残るか

- [ ] ブックビルディング注文の全修正履歴が保存され、締切後の注文が遮断されるか

- [ ] 配分ロジックの入力・ウェイト・手動調整がすべて記録されるか

- [ ] シンジケートローン持分の時点別元帳と端数処理ルールがあるか

- [ ] エクスポージャーが企業グループ単位で合算され、未引出コミットメントが含まれるか

- [ ] ディール終了時に権限回収・VDR閉鎖・リスト整理が自動的に連鎖するか

- [ ] 監査ログがappend-onlyで保存され、保存期間ポリシーが規定と整合しているか

おわりに

IBシステムの本質は取引処理ではなく**統制された協業**です。少数の高額ディールを取り巻く情報アクセス、承認、記録が正確に統制されることがシステムの存在理由です。機能要件(パイプライン、ブックビルディング、ローン管理)は比較的平易ですが、非機能要件 — 不変履歴、時点照会、デフォルト遮断の権限、自動回収 — が設計の成否を分けます。新しくシステムを作るなら、画面よりも先にデータモデルと権限モデルから設計することをお勧めします。

繰り返しになりますが、本記事は技術資料であり、投資・法律助言ではありません。

参考資料

- 資本市場と金融投資業に関する法律(韓国法令情報センター): https://www.law.go.kr

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

- 韓国金融投資協会(需要予測関連規定): https://www.kofia.or.kr

- 韓国取引所の上場規定: https://www.krx.co.kr

- 電子開示システムDART: https://dart.fss.or.kr

- ICMA (International Capital Market Association): https://www.icmagroup.org

- LSTA (Loan Syndications and Trading Association): https://www.lsta.org

- LMA (Loan Market Association): https://www.lma.eu.com

- ESMA — 市場濫用規制(MAR)資料: https://www.esma.europa.eu

- BIS(国際決済銀行): https://www.bis.org

- IOSCO(証券監督者国際機構): https://www.iosco.org

- GLEIF(LEI財団): https://www.gleif.org