reference-data

参照データ

中核概念

1. セキュリティマスター

セキュリティマスターは、金融商品のレベルの参照データを管理する権威あるリポジトリであり、ポートフォリオ管理、取引、パフォーマンス、レポーティング、コンプライアンスの各システムの基盤となります。

主なフィールド： 識別子（CUSIP、ISIN、SEDOL、FIGI、ティッカー、内部 ID）、分類（資産クラス、サブクラス、GICS セクター、国、通貨）、発行体情報（名称、LEI、格付け）、契約条件（資産クラス固有の契約属性）、価格計算要素（乗数、日数計算方法、決済慣行）。

資産クラス固有の属性： 株式（発行済み株式数、時価総額、セクター、取引所、配当頻度）。債券（クーポン、満期、コールスケジュール、信用格付け、優先順位、日数計算方法）。ファンド（NAV、経費率、シェアクラス、分配頻度、販売手数料体系）。ETF（NAV、参考価格、経費率、連動対象インデックス）。オプション（原資産、権利行使価格、満期日、種類、乗数、権利行使方式）。オルタナティブ（戦略の種類、ビンテージ年、コミットメント、キャピタルコールのスケジュール、評価頻度）。

証券のライフサイクルイベント： IPO／上場（必要な全フィールドを含む新規レコードの作成）、コーポレートアクション（株式分割、合併、スピンオフ、名称／ティッカー／取引所の変更 — セキュリティマスターのデータ品質問題の最大の原因）、上場廃止／満期（非アクティブとしてフラグを付け、パフォーマンスと監査のために過去のレコードを保持）。

ゴールデンソースの指定： セキュリティマスターは、金融商品参照データに関する自社のゴールデンソースである必要があります。すべての下流システムは、独立したコピーを保持するのではなく、セキュリティ属性をセキュリティマスターから取得します。

2. 識別子体系

金融商品には、複数の重複する識別子が付与されています。どの単一の体系も、あらゆる用途に普遍的に十分とはいえません。

• CUSIP — 9 文字（発行体コード 6 文字＋銘柄コード 2 文字＋チェックディジット 1 文字）。米国／カナダの証券に使用され、CUSIP Global Services（FactSet）が管理します。基本的な条件の変更（合併、再編）に伴い変更されます。
• ISIN — 12 文字（国コード 2 文字＋国内 ID 9 文字＋チェックディジット 1 文字）。ISO 6166 に準拠し、世界中で一意です。MiFID II、EMIR の報告に必要です。国内識別子（米国では CUSIP、英国では SEDOL）を内包します。
• SEDOL — 7 文字。LSE および英国／アイルランド上場銘柄向けに、ロンドン証券取引所が割り当てます。同じ証券でも、上場先の取引所ごとに異なる SEDOL が付与される場合があります。
• FIGI — 12 文字。OMG 標準に基づき Bloomberg が開発しました。CUSIP／SEDOL と異なり、オープンソースで無料で利用できます。金融商品レベル、コンポジットレベル、取引所レベルの識別子を区別します。
• ティッカーシンボル — 取引所が割り当てるもので、世界共通ではなく、頻繁に変更されます。プライマリー識別子としては決して使用せず、表示や取引上の便宜に限って使用してください。
• 内部識別子 — 企業が生成する識別子（UUID または連番の整数）で、証券の存続期間を通じて変更されません。すべての外部識別子を結び付ける安定したキーとして機能します。

識別子のマッピング： セキュリティマスターには、証券ごとにすべての識別子を関連付けるクロスリファレンステーブルが必要です。課題には、1 対多の関係（1 つの ISIN に複数の SEDOL が対応する）、コーポレートアクションによる時間的な変更（特定時点の検索に対応するバージョン管理されたマッピング）、競合の解決が必要となるベンダー間の不一致などがあります。

3. クライアントマスター

クライアントマスターは、オンボーディング、アカウント管理、KYC/AML コンプライアンス、レポート作成、顧客関係管理を支える、クライアント単位の参照データの信頼できる一元管理先です。

データモデル： 個人（法的氏名、生年月日、SSN/TIN、住所、電話番号、メールアドレス、市民権、職業）。法人（法的名称、EIN、設立州／国、法人形態、設立日）。信託（信託名、種類、委託者、受託者、受益者、準拠法）。

ID 管理： 各クライアントには、保有するアカウントや役割の数にかかわらず、単一の一意な識別子を割り当てる必要があります。データの重複排除は、規制報告、世帯単位の請求、アカウント間のコンプライアンス（ウォッシュセール）、一元的なサービス提供において重要です。

世帯と関係性： 世帯グループを作成して、関連するクライアントを請求、レポート作成、プランニングのために紐付けます。関係の種類には、配偶者、親子、受託者／受益者、取引権限者、信頼できる連絡先があります。アドバイザーの割り当て（主担当、副担当、サービスチーム）もここで追跡します。

KYC/AML データ： 確認ステータス、確認方法、リスク評価、PEP ステータス、OFAC 審査結果、実質的所有者（法人）、資金／資産の出所、EDD フラグ。

クライアントの設定： コミュニケーションチャネル、明細書の送付方法、言語、投資に関する設定（ESG に基づく除外、セクター制限）、税務ロットの選好方式。

ゴールデンソース： 通常、CRM は関係性およびアドバイザリーのデータに関するゴールデンソースであり、カストディアンは規制上の本人確認データ（法的氏名、SSN、登録住所）に関するゴールデンソースです。クライアントマスターは両者を統合し、同期を徹底します。

4. アカウントマスター

アカウントマスターは、すべてのクライアントアカウントの属性と設定を保存し、アカウントをクライアントに紐付けて、取引、請求、レポート作成、コンプライアンスを支えます。

属性： 登録形態（個人、共同、信託、IRA、Roth、SEP、401(k)、法人、遺産、UGMA/UTMA）、アカウントの種類（アドバイザリー、証券仲介、ラップ、退職、教育、慈善）、税務上の区分（課税対象、課税繰延、非課税）、カストディアン、アドバイザー、モデルの割り当て、機能（信用取引、オプションのレベル、DRIP、取得価額の方式）。

アカウントとクライアントの関係： 所有者、権限を付与された当事者（POA、取引権限）、受益者、受託者、カストディアン（UGMA/UTMA の場合）。

ステータス管理： 有効、制限付き（規制上の保留、死亡通知、法的紛争）、閉鎖済み（帳簿・記録の要件に従い履歴データを保持）、休眠（エサチメント／未請求資産のリスク）。

システム間の識別： カストディアンのアカウント番号、PMS アカウント ID、CRM アカウント ID、請求アカウント ID は、それぞれ異なる場合があります。アカウントマスターはこれらの対応関係を管理し、システム間のキーとして正規の内部 ID を提供します。

5. 価格データ

価格データは、最も更新頻度の高い参照データのカテゴリです。価格が誤っていると、評価、パフォーマンス、請求、コンプライアンスに直ちに影響が及びます。

日次終値： 取引所の公式終値（米国株式は東部時間午後4時）、ミューチュアルファンドのNAV（東部時間午後6時〜7時に利用可能）、取引頻度の低い債券の評価価格（Bloomberg、ICE、Refinitivのモデル）。

価格の優先順位： 証券の種類ごとに優先するソースを定め、自動的にフォールバックするようにします。例：米国株式 — 取引所終値、次にBloomberg、次にRefinitiv。社債 — ICEの評価価格、次にBloomberg BVAL、次にRefinitiv。オルタナティブ資産 — 運用会社／GPによる評価、次に第三者による査定、次に内部モデル。

公正価値評価： 外国の取引所が米国市場の終値より数時間前に閉場する場合、海外証券の終値を、その後の市場動向、為替、ニュースを踏まえて調整します。これにより、ミューチュアルファンドでの古い価格を利用した裁定取引を防ぎます。

価格の検証と古い価格の検出： 検証ルールの設計と実行（変動幅チェック、ゼロ／マイナス価格の検出、価格の鮮度確認期間、複数ソース間の比較、しきい値の調整）は、data-quality スキル（data-integration プラグイン）が担当します。reference-data は、これらのルールが照合するソースの優先順位を管理します。

手動での上書き： 権限を持つユーザーに限定し、理由とソースを記録して監査証跡に残します。ベンダーによる修正が保留されている間のみ有効とします。

6. 参照データのガバナンス

ガバナンスでは、参照データの正確性、完全性、適時性、一貫性を確保するための体制、ポリシー、プロセスを定めます。

データオーナーシップ： 各ドメインに担当オーナーを指定します。例：証券マスター（投資運用業務）、顧客マスター（コンプライアンス部門とアドバイザリー業務部門が共同で所有）、口座マスター（オペレーション／顧客サービス）、価格設定（ポートフォリオ会計／評価）。オーナーは品質に責任を持ち、定義やソースの変更を承認します。

データスチュワードシップ： スチュワードは、品質ダッシュボードの監視、例外の解決、ベンダーとの調整、上書きの承認、データ辞書の保守を日々実行し、ガバナンスを担います。

データ品質指標： 標準的な品質の側面（完全性、正確性、適時性、一貫性）に基づいて参照データを測定します。各側面の定義、検証ルールの設計、プロファイリング、例外管理、しきい値の調整は、data-quality スキル（data-integration プラグイン）が担当します。

MDMパターン： レジストリ（リンクのみで、競合は解決しない）、統合（ソースから集約した読み取り専用のゴールデンレコード）、共存（MDMとソース間の双方向同期）、トランザクション／ハブ（すべての参照データを一元入力するシステム）。

変更管理： 変更前の影響分析、本番以外の環境でのテスト、下流システムへの通知、ロールバック手順、変更後の検証を実施します。

監査証跡： 変更のたびに、変更前の値、変更後の値、タイムスタンプ、ユーザー／プロセス、理由を記録します。規制当局による検査、紛争解決、根本原因分析に必要です。

7. 参照データの配信

マスター化された参照データは、すべての利用システムに確実に配信する必要があります。

配信モデル： イベント駆動型／プッシュ型（メッセージバスまたはイベントストリームを利用した、ほぼリアルタイムの伝播）、ポーリング／プル型（スケジュールされたクエリ。よりシンプルですが、遅延が発生します）、一括配信／ファイル（EOD スナップショット向けの SFTP または S3 経由の CSV／XML／JSON）、API／オンデマンド型（必要な時点で取得するため、キャッシュの陳腐化を解消できますが、実行時の依存関係が生じます）。

差分配信： 前回の配信以降に変更されたレコードのみを送信します。変更の追跡、順序付け、全件更新へのフォールバック機能が必要です。

キャッシュ： 利用システムでローカルキャッシュを使用すると遅延を減らせますが、データが古くなるリスクがあります。TTL ポリシー、イベント駆動型のキャッシュ無効化、バージョン番号を利用して対処します。

特定時点のデータ取得： 指定した日付時点のレコードの状態を照会できるようにします。過去のパフォーマンス、規制報告、監査に必要です。適用日／失効日カラムまたは全履歴テーブルを使用して実装します。

8. ベンダー管理

データベンダーは、証券参照データ、価格、格付け、識別子を提供する主要な外部ソースです。

主要ベンダー： Bloomberg（幅広いカバレッジ、FIGI、リアルタイム価格）、Refinitiv/LSEG（グローバルなカバレッジ、評価価格）、ICE Data Services（債券価格、指数）、S&P Global（格付け、CUSIP、ファンダメンタルデータ）、Moody's（信用格付け、リスクデータ）、FactSet（複数ソースの集約、CUSIP Global Services）、MSCI（ESG 格付け、ファクターデータ、指数）。

評価基準： カバレッジ（資産クラス、地域）、品質（正確性、完全性、エラー修正）、適時性（処理期限に対する提供タイミング）、形式／配信（API、ファイル、スキーマの安定性）、ライセンス条件（再配布権、ユーザーごとの料金）、コスト（総所有コスト）、サポートの品質。

複数ベンダー戦略： 重要なデータは少なくとも 2 社のベンダーから取得します。主ベンダー、バックアップ、意見が一致しない場合の裁定ルールを定めます。

ベンダーの監視： ファイルの到着時刻を追跡し、レコード数が予期せず減少していないか監視し、独立したソースと比較し、四半期ごとのベンダースコアカードを作成し、品質上の問題が継続する場合はエスカレーションします。

実例

例 1：複数カストディアンを利用するアドバイザリー会社向けセキュリティマスターの設計

シナリオ： RIA は、Schwab と Fidelity の 1,500 口座にわたる 12 億ドルの資産を管理し、米国株式・国際株式、ETF、投資信託、社債、地方債を取引しています。各カストディアンのフィードは個別の証券テーブルにデータを取り込み、統合されたセキュリティマスターは存在しません。繰り返し発生している問題として、同じ投資信託がカストディアンごとに異なる名称で表示されること、社債に一貫した信用格付けがないこと、そしてコーポレートアクションが個別に処理されていたため、Schwab では株式分割が処理されたものの Fidelity では見落とされたことが挙げられます。

設計上の考慮事項： 会社は、不変の内部 UUID、すべての外部識別子（CUSIP、ISIN、SEDOL、FIGI、ティッカー、カストディアン固有 ID）、分類フィールド（資産クラス、GICS セクター、信用ティア）、発行体データ（名称、LEI、国）、資産クラス固有の条件、価格フィールド、ステータスを含むセキュリティマスターレコードを定義します。クロスリファレンステーブルでは、ポイントインタイム参照に対応する有効期間とともに、各内部 ID をすべての外部識別子に関連付けます。参照データと価格データの主なベンダーは Bloomberg、債券については ICE を副次ベンダーとし、カストディアンのフィードは照合チェックに利用します。CUSIP Global Services は識別子の変更通知を提供します。すべてのコーポレートアクションは、まずセキュリティマスターを通じて処理され、その後両方のカストディアンに反映されるため、不整合な処理がなくなります。データ品質管理には、毎日の完全性チェックと価格検証、ベンダー間の価格比較を毎週実施すること、分類監査を毎月実施することが含まれます。

分析： セキュリティマスターを一元化することで、根本原因である、分散し照合されていない証券データを解消できます。内部 UUID はコーポレートアクション、識別子の変更、カストディアンの移行後も変わりません。継続的に発生するコストで最も大きいのはコーポレートアクションのワークフローであり、セキュリティマスターの管理担当者として専任のデータオペレーションアナリストが必要です。

例 2：検証と例外処理を備えた価格データ管理の導入

シナリオ： 資産運用会社は、2,000 銘柄（米国株式・国際株式、社債・地方債、MBS）を保有する個別口座 30 件と合同運用ファンド 5 件について、毎晩評価を実施しています。価格データは単一のベンダー（Refinitiv）から取得しています。過去には、地方債の価格が 3 日間ゼロのまま気付かれなかったこと、現地の祝日の間、国際株式の価格が 1 週間更新されなかったこと、ベンダーのエラーにより社債の評価価格が 15％ずれていたことがありました。

設計上の考慮事項： 会社は、資産クラスごとに段階的な価格データの優先順位を設定し、自動的なフォールバックを用意します（例：社債の場合、ICE の評価価格、次に Refinitiv、次に Bloomberg BVAL）。データの読み込み前に自動検証を実行します。検証には、変動幅チェック（株式は 15％、債券は 5％）、ゼロ価格チェック、価格の陳腐化チェック（株式は 2 日、債券は 5 日。現地の祝日を考慮）、ベンダー間比較（債券で乖離が 2％を超えた場合にフラグを設定）、通貨確認、妥当性範囲チェックが含まれます。例外は重要度（重大・高・中・低）で分類され、価格ダッシュボードに表示されます。重大な例外が発生すると即時アラートが送信されます。価格アナリストが調査して、文書を残して承認する、バックアップベンダーのデータに差し替える、または手動で上書きするといった方法で解決し、すべての対応を記録します。未解決の例外は、定められた時間が経過するとエスカレーションされます。国際株式については、米国市場の動向、為替変動、セクター ETF のデータを使って海外の終値を調整するフェアバリューモデルを利用します。

分析： このフレームワークにより、価格データの運用は受動的な受け取りから、積極的な品質管理へと変わります。複数ベンダーによる優先順位付けによって、単一ベンダーへの依存を解消できます。自動検証により、過去に発生した 3 種類すべての問題を検出できます。適切に運用される価格管理業務では、1 日あたりの対象銘柄全体に対する例外率を 2％未満に抑え、重大および重要度の高い例外を当日中に解決することを目指します。

例3：規制遵守に向けたクライアントマスターデータガバナンスの構築

シナリオ： 3,000世帯にサービスを提供するウェルスマネジメント会社が、クライアントデータの品質に問題があることを発見しました。住所が12％未入力、雇用情報が8％古い（退職したと把握しているクライアントが、引き続き就業中として登録されている）、法人クライアントの5％で実質的支配者に関する書類が不足しているほか、世帯のグループ分けに一貫性がなく、請求エラー（ブレークポイント割引の適用漏れ）が発生しています。クライアントデータは3つのシステム（Salesforce CRM、Schwab custodian、Orion PMS）に存在していますが、正式なゴールデンソースが指定されておらず、記録に食い違いがあります。同社は、FinCENの投資顧問業者向けAML/CFTプログラム要件が施行される前に、データを修正し、ガバナンスを確立する必要があります。当初の施行日は2026年1月1日でしたが、FinCENにより2028年1月1日に延期されました（2026年6月時点の状況。最新情報をご確認ください）。

設計上の考慮事項： データドメインごとにデータオーナーを割り当てます。クライアントの本人確認情報はCCO（規制上の重要性）、クライアントとの関係はHead of Client Services（サービス提供と請求）、クライアントの財務プロフィールはCIO（適合性）が担当します。ゴールデンソースは、法的な本人確認情報についてはSchwab（CIPによる確認済みで、1099に使用）、関係・アドバイザリー情報についてはSalesforceとし、Orionは他の2つのシステムから同期される参照先としてのみ使用し、直接編集しません。データ修正では、CRMとカストディアンの情報を照合し、不足があればクライアントに連絡して未入力の住所を補完します（90日以内に100％を目標）。2年以上更新されていない60歳以上のクライアントの古い雇用情報にフラグを設定し、定期的な引き出しが始まった際に自動的に通知します。FinCENの書式を使用して不足している実質的支配者情報を収集し、口座規模の大きい順に優先対応します（60日以内に100％を目標）。共通の住所・電話番号・氏名から世帯のグループ分けを特定し、アドバイザーが確認したうえで、過剰請求分を返金します。継続的なガバナンスとして、例外ダッシュボードを用いた毎日の自動品質チェック、傾向に関するスチュワードの週次レビュー、運営委員会への月次指標報告、データオーナーとの四半期ごとのガバナンスレビュー、非アクティブなクライアントを対象とした年次の包括的なデータ更新を実施します。

分析： このプログラムは、当面の不足と構造的な原因の両方に対処します。ゴールデンソースを指定することで、システム間の曖昧さを解消できます。データ修正にはアドバイザーの積極的な関与が必要ですが、クライアントサービスの向上として位置付けるのが最適です。FinCENの施行日（延期後の2028年1月1日）までにはまだ時間がありますが、早期に修正を進める必要があります。完全で検証済みのクライアント本人確認情報を整備するには、何年もかかるためです。

よくある落とし穴

1. 主要な識別子としてティッカーシンボルを使用すること。 ティッカーはグローバルに一意ではなく、頻繁に変更され、再利用されます。ティッカーをキーとするシステムは、コーポレートアクションの際に破綻します。
2. カストディアンごとに別々の証券レコードを維持すること。 同じ金融商品が複数の証券として登録されるため、ポジションが重複し、コーポレートアクションの処理に一貫性がなくなります。
3. 価格データを受動的に受け取るだけにすること。 検証せずにベンダー価格を読み込むと、ゼロ価格、古い価格、ベンダーのエラーが評価額や請求に反映されます。
4. クライアントデータの指定された信頼できる情報源がないこと。 階層を設けずに複数のシステムでクライアントデータを管理すると、データの乖離や競合が起き、正規の記録が定まりません。
5. 時間軸に沿ったバージョン管理を無視すること。 履歴を保持せずに現在の状態を上書きすると、特定時点のレポート、過去のパフォーマンス、監査への対応ができなくなります。
6. コーポレートアクション処理への投資が不十分であること。 コーポレートアクションは証券マスターの障害の主な原因です。優先度の低い事務作業として扱うと、照合の不一致が継続的に発生します。
7. 価格データを単一ベンダーに依存すること。 バックアップの情報源がないと、ベンダーの遅延、欠落、誤りが発生した際に手作業で価格を設定する必要があり、規模を拡大できません。
8. データ品質指標を軽視すること。 完全性、正確性、適時性、一貫性を測定しなければ、問題が後続処理の障害を引き起こすまで見えません。
9. 集中管理型の参照データサービスではなく、ポイントツーポイントの連携を使うこと。 各利用システムがベンダーに直接接続すると、品質上の問題を個別に抱えた冗長なコピーがN個作られます。
10. コーポレートアクションに伴う識別子の変更に備えていないこと。 CUSIP／ISIN／ティッカーの変更を適切に処理できないシステムでは、ポジション履歴が失われ、パフォーマンスの連続性が崩れます。

相互参照

• market-data（data-integration プラグイン） — マーケットデータはリアルタイムの価格データと取引データを扱います。参照データは、マーケットデータが参照する金融商品のマスターを提供します。
• data-quality（data-integration プラグイン） — 一般的なデータ品質の原則（プロファイリング、検証、モニタリング）を、ここでは金融参照データに適用します。
• integration-patterns（data-integration プラグイン） — 連携パターン（イベント駆動、バッチ、API）は、参照データを配信するための仕組みです。
• portfolio-management-systems（advisory-practice プラグイン） — PMS は、証券マスター、価格データ、口座マスターデータの主要な利用者です。
• reconciliation（client-operations プラグイン） — 参照データの不一致（識別子、古い価格）は、照合不一致の主な原因です。
• corporate-actions（client-operations プラグイン） — コーポレートアクションによって証券マスターが変更されます。このスキルでは、その結果として必要になる参照データの更新を扱います。
• know-your-customer（compliance プラグイン） — KYC 要件によって収集すべきクライアントデータが定義され、クライアントマスターがその保存と管理を担います。
• books-and-records（compliance プラグイン） — 参照データの記録は、保存および検査の要件が適用される帳簿・記録に該当します。