data-quality

データ品質

基本概念

1. 金融データの品質ディメンション

データ品質は6つのディメンションで定義されます。それぞれ、金融サービスにおける固有の意味があります。

正確性 — データ値が、記述対象の実世界のエンティティやイベントを正しく表していることです。証券価格が、指定された情報源の実際の市場終値または評価額を反映していれば、正確です。クライアントの住所が、現在の法的な登録住所と一致していれば、正確です。正確性の問題は連鎖します。不正確な価格は、評価額、パフォーマンス、請求、規制報告の不正確さにつながります。正確性は、独立した権威ある情報源とデータを比較して測定します。たとえば、ベンダー間の価格比較、カストディアンとPMSの照合、個人データに関するクライアントの確認などです。実務上、正確性は比較用の独立した参照先が必要となるため、測定が最も難しいディメンションです。

完全性 — すべてのレコードに、必須のデータ要素がすべて含まれていることです。ISIN、資産クラスの分類、価格情報源の指定が欠けている証券マスターレコードは不完全です。法人アカウントの実質的所有者情報が欠けているクライアントのオンボーディングレコードも不完全です。完全性は、必須フィールドがすべて入力されているレコードの割合として測定します。金融データの完全性要件は、多くの場合、規制に基づいています。FinCENは完全な実質的所有者データを求め、GIPSはコンポジットへのポートフォリオの完全な組み入れを求め、SEC Rule 17a-4は完全な取引記録を求めています。完全性の要件はレコードの種類ごとに定義する必要があります。法人アカウントの必須フィールド（実質的所有者情報）は、個人アカウントの必須フィールド（雇用状況）とは異なります。

適時性 — データが、意図された用途に必要なタイミングで利用できることです。日次終値データは、夜間の評価バッチの実行前に到着する必要があります。取引確認は、SEC Rule 10b-10の期限内に生成する必要があります。NAVの計算は、ファンド会社の期限前に完了する必要があります。適時性は、イベントの発生から利用システムでデータが利用可能になるまでの遅延として測定します。処理時間枠が終了した後に届く遅延データは、機能上、欠損データと同じです。適時性の要件はユースケースによって大きく異なります。リアルタイム市場データはミリ秒単位、EOD価格データは数時間以内、四半期ごとの規制報告は数週間以内に届く必要があります。

一貫性 — 同じ事実が、すべてのシステムと期間を通じて同一に表現されていることです。クライアントの正式名称は、CRM、カストディアン、PMS、請求システム間で一致している必要があります。証券のセクター分類は、ポートフォリオ管理システムとコンプライアンス監視システムで同じである必要があります。一貫性の欠如は通常、信頼できる唯一の情報源の指定漏れ、または同期プロセスの破損を示しています。一貫性は、同じエンティティ属性をシステム間で比較して測定します。時間的な一貫性も重要です。証券の分類を、文書化された正当な理由と下流への影響評価なしに遡及的に変更してはなりません。

妥当性 — データが、定義された形式、範囲、ビジネスルールに準拠していることです。CUSIPは、正しいチェックディジットを持つ正確に9文字の値である必要があります。口座の登録種別は、会社が定義した値のいずれかである必要があります（従来型債券の）クーポンレートは、負の値であってはなりません。取引の決済日は、取引日より前の日付であってはなりません。妥当性は、スキーマ制約、フィールド単位の検証、ビジネスルールエンジンによって適用されます。無効なデータが本番環境に入り込む場合は、入力検証が不十分であることを示しています。妥当性ルールは、正式なカタログとしてバージョン管理し、維持する必要があります。ルールを変更する場合は、適用日と根拠を記録する必要があります。 一意性 — 現実世界の各エンティティが正確に一度だけ表現されます。CRM にクライアントが 2 件のレコードとして登録されている場合（名前の表記揺れやデータ入力ミスによる重複）、レポートが分断され、世帯単位の請求割引を受けられず、コンプライアンス違反につながる可能性があります（口座をまたいだウォッシュセールの検出には、クライアントを統合したビューが必要です）。カストディアンごとに有価証券が 2 件のマスターレコードとして登録されると、保有ポジションが重複します。一意性は、データ取り込み時の重複排除と、定期的な重複検出スキャンによって確保されます。一般的な重複排除手法には、識別子（SSN、CUSIP）による完全一致、名前と住所のあいまい一致（Jaro-Winkler、Levenshtein 距離）、複数の信頼性の低い識別子を組み合わせて信頼度スコアを算出する確率的マッチングがあります。

ディメンション	測定方法	典型的な目標値	未達成の場合の主なリスク
正確性	ソース間の比較、照合	価格は >99.5%、クライアントデータは >99%	評価額、請求、提出書類の誤り
完全性	必須フィールドが入力済みの割合	重要フィールドで >98%	規制当局からの指摘、不完全なレポート
適時性	イベント発生からシステムで利用可能になるまでの遅延	処理時間枠内	古い評価額、期限の超過
一貫性	システム間の属性比較	一致率 >99%	レポートの不一致、監査の失敗
妥当性	形式およびビジネスルールの合格率	>99.9%	処理の失敗、レコードの破損
一意性	重複検出率	重複率 <0.1%	レポートの分断、コンプライアンスの欠落

2. ゴールデンソースアーキテクチャ

ゴールデンソースの指定（データドメインごとにどのシステムを正式な情報源とするか）、MDM パターン（レジストリ、統合、共存、トランザクションハブ）、競合解決と存続のルール、および価格情報ソースの階層は、reference-data スキル（data-integration プラグイン）が担当します。指定表と各パターンのトレードオフについては、そちらを参照してください。ここで重要なのは、比較対象となる正式な情報源が指定されていなければ正確性を測定できないという点です。そのため、以下のすべての検証ルールと正確性の指標は、ゴールデンソースが指定されていることを前提としています。

3. データリネージとプロベナンス

データリネージは、データの発生元から、利用システムに届けられるまでに行われるすべての変換、拡充、集計を経たデータの全経路を追跡します。プロベナンスは、各段階で誰が、または何がデータを作成、変更、承認したかを記録します。

リネージメタデータ： 各データ要素について、リネージにはソースシステムと元のフィールド、抽出方法とタイミング、適用されたすべての変換（マッピング、変換、計算、拡充、集計）、中間ステージングの保存場所、宛先システムとフィールド、各段階のタイムスタンプとプロセス識別情報が記録されます。

金融分野でリネージが重要な理由： パフォーマンスレポートに予期しないリターンが表示された場合、リネージを使うと、計算エンジンから、その計算に使用された価格データ、ベンダーのソース、抽出タイムスタンプまで結果をたどり、エラーがどこで発生したかを正確に特定できます。リネージがなければ、根本原因の分析は手作業となり、時間がかかるうえ、信頼性にも欠けます。

影響分析： リネージにより、下流への影響分析が可能になります。データソースがスキーマや配信形式を変更した場合、影響を受けるすべての下流システム、計算、レポートを特定できます。これは、ベンダーの移行、システムのアップグレード、規制報告の変更において特に重要です。

規制要件： BCBS 239（実効的なリスクデータ集計とリスク報告のための原則）は、銀行に対し、リスクデータの包括的なデータリネージを維持し、あらゆるリスクレポートの値をソースデータと適用されたすべての変換までたどれるようにすることを求めています。BCBS 239は、グローバルなシステム上重要な銀行（G-SIB）に適用されますが、その原則はベストプラクティスとして、小規模な金融機関やノンバンクの金融会社にも広く採用されつつあります。MiFID IIは、投資会社に対し、取引レポートの正確性と完全性を示す記録の維持を求めており、実質的に取引執行から報告までのリネージが必要になります。SECの検査では、報告された数値がソースデータからどのように導き出されたかを示すよう、会社に求めるケースが増えています。

実装方法： 手作業によるリネージの文書化（スプレッドシート、データディクショナリ）は一般的ですが、システムの進化に伴ってすぐに古くなります。自動リネージツールは、ETLコード、SQLクエリ、データパイプラインの構成を解析して、リネージを自動的に抽出します。主要なプラットフォームには、Collibra、Alation、Informatica、Apache Atlasなどがあります。ハイブリッド方式では、自動抽出にビジネスコンテキストの手動注釈を組み合わせます。小規模な会社では、重要なプロセス（価格設定、パフォーマンス、請求、規制報告）ごとにデータフロー図を手動で維持するだけでも、リネージ文書がまったくない場合と比べて大きな価値があります。

リネージの粒度レベル： 粗粒度のリネージは、システム間のデータフロー（例：「カストディアンのフィードがPMSのポジションに取り込まれる」）を追跡します。細粒度のリネージは、フィールド間の変換（例：「カストディアンのフィールドACCT_BALが、東部時間午後4時時点のBloombergのFXレートを使用した通貨換算を経て、PMSのフィールドmarket_valueにマッピングされる」）を追跡します。規制関連のユースケース（BCBS 239、SEC検査への対応）では、重要なデータ要素について、細粒度のリネージがますます求められています。

4. 金融データの検証ルール

検証ルールは、本番システムにデータを読み込んだり、下流処理に使用したりする前に、定義済みの基準に照らしてデータを評価する自動チェックです。ルールは複数のレベルで機能します。

フィールドレベルの検証： 各フィールドに個別に適用される、フィールドごとの形式および範囲のチェック。

• CUSIP： 英数字9文字である必要があり、チェックデジットはLuhnアルゴリズムの変種で検証します。
• ISIN： 12文字である必要があり、先頭の2文字はISO 3166-1の国コード、チェックデジットはダブルアド・ダブルアルゴリズムで検証します。
• 価格： 正の数値である必要があります（一部のデリバティブには例外があります）。小数点以下の桁数は資産クラスごとに適切な範囲とします（株式は小数点以下2桁、債券は6桁、FXレートは8桁）。
• 日付： 有効な暦日であり、想定範囲内（遠い過去や未来ではない）である必要があります。
• 口座番号： カストディアンごとに想定される形式と一致する必要があります（Schwab：8文字、Fidelity：9文字など）。
• 通貨コード： ISO 4217の有効な3文字コードである必要があります。

フィールド間の検証： 単一のレコード内にあるフィールド間の関係を検証します。

• 取引の決済日は、適切な決済サイクルに従って取引日より後である必要があります（2024年5月以降の米国株式はT+1、多くの市場における国際株式はT+2）。
• 債券の満期日は発行日より後である必要があります。
• オプションの満期日は取引日より後である必要があります。
• 非課税口座（Roth IRA）で非課税の地方債を保有することは有効ですが、非効率です。適合性審査の対象としてフラグを設定します。
• マージン取引が可能な口座には、マージン契約書が登録されている必要があります。
• 口座開設日は最初の取引日より前である必要があります。

レコード間の検証： 単一システム内のレコード間の関係を検証します。

• すべての口座における証券の保有数量の合計が、カストディアンの合計と一致する必要があります。
• コンポジット内のポートフォリオ比率の合計は100％である必要があります。
• アドバイザーに割り当てられたすべての口座が、アドバイザーマスター内の有効なアドバイザーレコードを参照している必要があります。
• 取引で参照される証券は、証券マスターに存在する必要があります（参照整合性）。
• 同一世帯内のすべての口座で、一貫した請求ティアの割り当てを共有する必要があります。

システム間の検証： 重複するデータを保持するシステム間の整合性を検証します。

• PMSの保有数量がカストディアンの保有数量と一致する必要があります（毎日の照合）。
• CRMの顧客名と住所がカストディアンの情報と一致する必要があります（四半期ごとの整合性チェック）。
• OMSの取引記録が、執行ブローカーからの確認情報と一致する必要があります。
• 請求対象のAUMが、定義された許容範囲内でPMSの評価額と一致する必要があります。
• 内部で算出したパフォーマンスリターンが、カストディアンの報告リターンと一致する必要があります。

時間的検証： 時代錯誤や時間的に矛盾するデータを検出します。

• 満期日が過去の社債は、証券マスターで有効になっていてはなりません。
• 生年月日から算出した年齢が120歳を超える（またはマイナスになる）顧客がいる場合、データに誤りがあります。
• 想定されるサイクルの範囲を超える将来の決済日を持つ取引は、調査が必要です。
• 取引所で取引される証券について、週末または市場休業日の価格が存在してはなりません。
• 顧客の死亡日（記録されている場合）より後に開設された口座は、データエラーまたは不正行為を示しています。

ドメイン固有の検証例：

• 証券価格 — 前日比の差異チェック（資産クラスごとの基準値を超える変動を検出：株式は15％、投資適格債券は5％、ハイイールド債券は10％）、ゼロ価格の検出、負の価格の検出、価格の陳腐化の検出（祝日や取引カレンダーを考慮した想定期間を超えて価格が変わっていない場合）、複数ベンダー間での比較、証券マスターとの通貨の照合。
• 顧客データ — 住所の標準化とUSPSによる配達可能性の確認、SSN/TINの形式とチェックディジットの検証（mod-9アルゴリズム）、電話番号とメールアドレスの形式検証、OFAC SDNリストとの照合によるPEPおよび制裁対象者のスクリーニング、生年月日に基づく年齢の妥当性確認、口座種別と雇用状況の整合性確認（例：退職口座への拠出には勤労所得が必要）。
• 取引データ — 証券種別に応じた通常の範囲内にある取引数量と価格、取引規模および証券に応じた想定範囲内の手数料、決済指図の完全性（DTC参加者、口座番号）、承認済み取引相手リストとの照合による取引相手の検証、重複取引の検出（同一の証券、数量、価格、日付）。
• ポジションデータ — ロング専用口座で数量がマイナスになっていないこと、課税口座のすべてのロットに取得原価が記録されていること、カストディアンとの設定来のポジション照合、口座規模および投資方針に照らしたポジション総額の妥当性。

5. データプロファイリングとモニタリング

データプロファイリングとは、データの構造、内容、品質特性、統計的性質を把握するために、データを体系的に分析することです。モニタリングでは、プロファイリングを継続的かつ自動的な観測へと拡張します。

統計的プロファイリング： 各フィールドについて、以下の情報を取得します。

• 完全性率 — null 値でもデフォルト値でもない値を持つレコードの割合です。
• 個別値の数と分布 — カーディナリティと頻度を分析します。カーディナリティが高いと予想されるフィールド（顧客の SSN）のカーディナリティが低い場合は、重複やデフォルト値を示している可能性があります。
• 最小値／最大値／平均値／中央値／標準偏差 — 数値フィールドに対して分析します。価格フィールドの最小値が不自然に低い場合、価格がゼロのデータが混入している可能性があります。
• パターン分析 — 文字列フィールドの形式のばらつきを特定します（市外局番の有無が混在する電話番号、MM/DD と DD/MM が混在する日付形式など）。
• null 値とデフォルト値の割合 — 実際に欠損しているデータと、実データのように見えるシステムのデフォルト値（例：「1/1/1900」のデフォルト日付）を区別します。
• 外れ値の特定 — 想定される統計的範囲から外れる値を特定します。

金融データでは、プロファイリングによって、スポットチェックでは見つからない問題を明らかにできます。たとえば、価格フィールドの完全性が 99.8% でも、欠損している 0.2% が流動性の低い債券に集中している場合があります。まさに価格エラーの影響が最も大きい領域です。

ドリフト検出： データ特性のベースラインを確立し、変化があったときにアラートを発します。通常 2,000 件のレコードを含む日次価格ファイルに、今日 1,200 件しか含まれていない場合、個々のレコードがすべて検証に合格していても、レコード数のドリフトは上流の問題を示している可能性があります。古い価格の証券の割合が、ベースラインの 0.5% から 3% に増えた場合、その傾向はベンダーのデータ配信に問題があることを示しています。

異常検出： 統計的手法とルールベースの手法を用いて、通常とは異なるデータを特定します。大規模な対象集合における価格の外れ値検出には、アイソレーションフォレストや z スコアの手法を使用します。データ分布の急激な変化（過去には個別値が 11 種類だったセクター分類フィールドが、突然 15 種類になるなど）。取引量の異常（単一口座の取引が 10 倍に急増するなど）。

モニタリングダッシュボード： 運用データ品質ダッシュボードでは、完全性の割合、検証の合格率、重大度別の例外件数、古いデータの件数、システム間の照合状況、傾向グラフなど、各種指標にわたるリアルタイムの品質メトリクスを表示します。ダッシュボードは、解決すべき問題を特定する運用担当者と、全体的なデータの健全性を評価する経営陣の双方に役立ちます。

アラートのしきい値： 重大なアラートは、活発に取引されている証券の価格がゼロ件読み込まれた場合、価格ファイルが欠落している場合、照合差異が重要性のしきい値を超えた場合など、即時の対応が必要な状況に対して発します。警告アラートは、古い価格の件数の増加、完全性の低下傾向、異常な例外件数など、定められた期間内の調査が必要な状況に対して発します。アラート疲れ（誤検知が多すぎる状態）を避けながら、重要な問題を決して見逃さないよう、しきい値を調整する必要があります。一般的な調整方法として、検証ルールを 30 日間、監視モードで実行し、フラグが立った項目の分布を分析して、最初のしきい値を 95 パーセンタイルに設定し、その後、データ品質の向上に合わせて四半期ごとにしきい値を厳しくしていきます。

傾向分析： 傾向分析では、ある時点のモニタリングにとどまらず、データ品質が時間の経過とともに改善しているか、悪化しているかを明らかにします。週次および月次の傾向レポートでは、領域と重大度別の例外件数、平均解決時間、完全性と正確性の割合、ベンダーのパフォーマンスメトリクス（ファイル配信の適時性、エラー率）を追跡します。個々のメトリクスが許容範囲内にとどまっていても、傾向が悪化している場合は調査が必要です。

6. 例外管理

例外とは、検証に失敗し、調査と解決が必要となるデータ品質イベントです。効果的な例外管理により、その場しのぎの対応を、体系的で測定可能なプロセスへと変えられます。

例外の分類： 重要度レベルによって、対応期限とエスカレーションが決まります。Critical — 未解決の場合、重大な財務的影響を引き起こすデータ品質問題（NAV の価格設定誤り、規制当局への届出に必要なデータの欠落、しきい値を超える照合差異など）。影響を受けるプロセスの実行前に解決する必要があります。High — レポートや計算の正確性に影響するものの、直ちに財務的損害を引き起こすものではないデータ品質問題（少額のポジションの価格情報が古い、今後の規制レポートに必要な顧客フィールドが未入力など）。同じ営業日中に解決します。Medium — データ品質を低下させるものの、直ちに及ぼす影響が限定的なデータ品質問題（任意の分類フィールドの欠落、システム間の軽微な不整合など）。定められた SLA（通常は 3〜5 営業日）以内に解決します。Low — 表示上または軽微な問題（書式の不整合、希望する名前の不一致など）。定期メンテナンスサイクル中に解決します。

例外のワークフロー： 体系的なライフサイクルにより、例外が見失われたり、無視されたりすることを防ぎます。

1. 検出 — 自動検証によって問題が検出されるか、ユーザーが手動で報告します。
2. 分類 — 事前定義されたルール（データドメイン、影響を受けるシステム、財務的影響）に基づいて重要度を割り当てます。
3. 振り分け — データドメインのオーナーシップに基づいて、担当データスチュワードまたはオペレーションチームに振り分けます。
4. 調査 — 根本原因を特定します。原因としては、ベンダーのエラー、変換処理のバグ、手入力の誤り、上流システムの変更、ビジネスルールの不足などがあります。
5. 解決 — データソースでデータを修正するか、文書化と有効期限の設定を伴う一時的な上書きを適用するか、文書による根拠を示して受け入れるか、データオーナーに判断を仰ぐためにエスカレーションします。
6. クローズ — 解決の詳細を記録し、根本原因の追跡データベースを更新し、下流への影響が解消されたことを確認して、利用システムに修正済みデータが反映されていることを確かめます。

根本原因分析： 例外の根本原因を追跡すると、全体に影響する問題が明らかになります。価格設定の例外の 40% が、あるベンダーの社債カバレッジに起因している場合、これはエスカレーションまたはベンダー変更が必要なベンダー品質の問題です。顧客データの例外が特定のオンボーディングワークフローに集中している場合、そのワークフローの再設計が必要です。根本原因のカテゴリ：ベンダーデータの品質、社内処理エラー、手入力エラー、システム連携の失敗、上流ソースの変更、ビジネスルールの不足。

例外の指標： 例外管理の主なパフォーマンス指標は次のとおりです。

• 件数 — 重要度とデータドメイン別の日次例外件数です。ベースラインを確立し、急増を明らかにします。
• 平均解決時間（MTTR） — 検出からクローズまでの平均時間で、重要度別に追跡します。目標：critical は 2 時間未満、high は 8 時間未満、medium は 3 営業日未満です。
• 滞留状況 — SLA を超えて未解決の例外件数です。例外の滞留は、対応能力の問題やプロセスの不備を示します。
• 根本原因の内訳 — 原因カテゴリ別の割合です。構造的な修正が可能な、全体に影響する問題を明らかにします。
• 再発率 — 解決後 30 日以内に再発した例外の割合です。再発率が高い場合、根本原因ではなく症状に対処している可能性があります。
• 例外率 — 処理された全レコードに占める例外の割合です。データ品質全体の健全性を示す主要な傾向指標です。

7. データ品質ガバナンス

ガバナンスは、個々の取り組みを超えてデータ品質を維持するための組織構造、ポリシー、説明責任の枠組みを提供します。

データ品質ポリシー： データドメインごとの品質基準を正式に文書化したものです。許容可能な完全性のしきい値、正確性の目標、適時性に関する SLA、検証ルールのカタログ、例外処理手順、上書き権限のレベルなどを定めます。ポリシーは毎年見直し、業務プロセス、規制要件、システム構成に変更があった場合は更新する必要があります。

データスチュワードシップの役割： データオーナー（担当ドメインのデータ品質に責任を負う上級ビジネスリーダー。たとえば、CCO はクライアントの本人確認データ品質、オペレーション責任者は取引データ品質を担当）、データスチュワード（ダッシュボードの監視、例外の解決、ベンダーとの調整、データ辞書の保守など、日々の品質プロセスを実行する運用担当者）、データカストディアン（検証エンジン、プロファイリングツール、監視システム、リネージの取得など、技術インフラを実装・保守する技術担当者）で構成されます。

品質スコアカード： ドメイン、ディメンション、システム別のデータ品質指標を報告する月次または四半期ごとのスコアカードです。完全性、正確性、適時性、一貫性の各割合を集計し、ドメインごとの総合品質スコアを算出します。傾向線は改善または悪化を示します。赤・黄・緑のステータス表示により、対応が必要なドメインを明確にします。スコアカードは運用委員会や経営幹部のスポンサーに提示し、組織全体の関心を維持します。

是正対応の優先順位付け： すべてのデータ品質問題に同等の投資が必要なわけではありません。次の観点から優先順位を付けます。規制上の影響（届出、コンプライアンス監視、検査への対応準備に影響する問題）、財務上の影響（請求、パフォーマンス、評価に影響する問題）、クライアントへの影響（クライアントへの報告やサービス提供に影響する問題）、件数（多くのレコードに影響するシステム上の問題と、個別の例外）。体系的な優先順位付けの枠組みにより、重大な問題が残る一方で、影響の小さい問題に是正リソースが費やされる事態を防ぎます。

説明責任の枠組み： データ品質の目標（例：価格の正確性 99.5％、クライアントデータの完全性 98％）をデータオーナーに割り当て、業績目標に含めます。品質低下時のエスカレーション経路を定めます。ガバナンス委員会（運用、技術、コンプライアンス、ビジネスリーダーシップの代表者で構成される月次データ品質会議）は、スコアカードを確認し、是正対応の優先順位を承認し、ドメイン横断の問題を解決します。

定期的な品質監査： 継続的な監視に加えて、予定を定めて実施する詳細な評価です。

• 年次の包括的なプロファイリング： すべての重要なデータドメインを対象に統計的なプロファイリングを全面的に実施し、ベースラインからの乖離を検出して、新たな品質問題を特定します。
• サンプリングに基づく正確性の検証： レコードを無作為に抽出し、独立した信頼できる情報源と照合します（例：証券価格 100 件を第 2 のベンダーに照会して確認、クライアントレコード 50 件をカストディアンの原資料と照合して確認）。
• プロセス監査： データ入力、変換、配信のワークフローを確認し、管理上の不備、無許可アクセス、文書化されていない手作業を調べます。
• ギャップ分析： 現在のデータ品質対策を、規制上の期待（SEC の検査重点項目、FINRA のガイダンス）および業界フレームワーク（BCBS 239、DAMA DMBOK）と比較します。
• 監査での指摘事項は、担当者、目標期日、追跡対象となる完了状況を割り当てたうえで、是正対応のバックログに反映します。

8. 規制の観点から見たデータ品質

金融規制当局が具体的なデータ品質基準を定めることは一般的ではありませんが、規制対象業務の基盤となるデータの正確性と完全性について、企業に説明責任を求めています。 BCBS 239 — リスクデータの集約とリスク報告に関する実効的な原則： 2013 年にバーゼル委員会が公表したこの 14 の原則は、リスクデータのアーキテクチャ、集約能力、報告慣行に関する期待を定めています。データ品質に関する主な原則は次のとおりです。原則 3（正確性と完全性）— リスクデータは正確かつ信頼できるものであり、適時に作成されなければなりません。原則 4（網羅性）— リスクデータは、企業全体の重要なリスクをすべて捉えなければなりません。原則 5（適時性）— リスクデータは、求められる期間内に利用可能でなければなりません。原則 6（適応性）— リスクデータシステムは、ストレス時にアドホックな報告書を作成できるだけの柔軟性を備えていなければなりません。正式には G-SIBs に適用されますが、BCBS 239 の原則は、金融業界全体におけるデータ品質ガバナンスの事実上のフレームワークとなっています。

データの正確性に関する SEC の期待： SEC Rule 17a-4 は、ブローカーディーラーに正確な帳簿および記録の維持を義務付けています。SEC による投資顧問業者の検査（Investment Advisers Act に基づく）では、開示を裏付ける顧客データ、ポートフォリオデータ、パフォーマンスデータが正確かどうかが評価されます。データ品質の不備に起因する Form ADV、Form PF、または顧客向けレポートの誤りは、詐欺防止規定への違反に該当する可能性があります。SEC の検査局は、検査上の優先事項としてデータの完全性を繰り返し挙げています。

パフォーマンスデータ品質に関する GIPS 要件： GIPS 準拠を主張する企業は、次の点を確保するデータ品質管理を維持しなければなりません。実際に運用され、報酬を受け取り、裁量運用されるポートフォリオがすべてコンポジットに含まれること（網羅性）、正確な評価額とキャッシュフローを用いてリターンが計算されること（正確性）、ポートフォリオ単位のリターンが適切な評価頻度で時間加重されること（妥当性）、コンポジットの構築が長期にわたり一貫して適用されること（一貫性）。GIPS の検証では、検証手続きの一環としてデータ品質管理のテストが含まれます。

AML/KYC におけるデータ正確性要件： FinCEN の顧客識別プログラム（CIP）規則は、企業に顧客の本人確認情報の検証を義務付けています。顧客デューデリジェンス（CDD）規則は、法人顧客の実質的支配者を特定し、確認することを求めています。継続的なモニタリングには、最新かつ正確な顧客データが必要です。古い、または不完全な顧客データでは、取引モニタリングや制裁対象者のスクリーニングの有効性が損なわれます。FinCEN の投資顧問業者向け AML/CFT プログラム規則は、これらの義務を SEC 登録投資顧問業者にも適用します。当初 2026 年 1 月 1 日に設定されていた施行日は、FinCEN により 2028 年 1 月 1 日に延期されました（2026 年 6 月時点の状況 — FinCEN は、施行前に規則をさらに調整する意向を示しています。最新状況を確認してください）。

リスクデータの集約： BCBS 239 に加え、健全性規制当局（OCC、Fed、PRA）は、リスク計算（VaR、ストレステスト、自己資本充足度）が、出所を文書化した正確で網羅的かつ適時なデータに基づいていることを企業が示すよう求めています。監督上のストレステスト（CCAR、DFAST）では、事業部門や法人をまたいでエクスポージャーデータを集約し、その正確性を実証することが企業に求められます。ストレステスト演習中のデータ品質の不備は、監督上の指摘や是正命令につながっています。

ノンバンク金融機関への実務的な影響： BCBS 239 および CCAR/DFAST は正式には銀行に適用されますが、SEC と FINRA はブローカーディーラーや投資顧問業者にもデータ品質管理をますます求めています。SEC の検査担当者は、顧客向けレポート、規制当局への提出書類、手数料計算の正確性を企業が実証できるかを評価します。FINRA Rule 4370（事業継続計画）と FINRA Rule 3110（監督）は、どちらも暗黙のうちにデータの完全性に依存しています。特定の規制上の義務がなくても、先を見越してデータ品質ガバナンスを導入する企業は、検査への備えを強化し、オペレーショナルリスクへのエクスポージャーを大幅に低減できます。

具体例

例1：ウェルスマネジメントプラットフォーム向けデータ品質モニタリングフレームワークの導入

シナリオ： Orion PMSを運用し、SchwabとFidelityをカストディアンとして利用する、運用資産50億ドルのRIAが、Salesforce CRMと独自のクライアントポータルを使っています。同社では、四半期ごとの運用実績レポートで15人のクライアントのリターンに誤りがあり、原因は古い債券価格だったこと、カストディアンのデータ反映の遅れにより、すでに移管済みのポジションに基づいて計算された請求書を3人のクライアントが受け取っていたこと、さらに、年次レビューを義務付ける社内方針があるにもかかわらず、クライアント記録の8％で適合性確認アンケートが更新されていないことをコンプライアンスチームが発見しました。体系的なデータ品質モニタリングは存在せず、問題が表面化するのはクライアントやアドバイザーから苦情があったときだけです。

設計上の考慮事項： 同社は4つのデータドメインにわたるデータ品質モニタリングフレームワークを構築します。価格データについては、毎日の自動検証でベンダー価格を前日価格と比較し（債券は5％超、株式は15％超の変動を検出）、価格の更新停止（株式は2営業日超、債券は5営業日超の変動なし。祝日を考慮）を検出します。また、SchwabとFidelityの価格をプライマリベンダーと照合し、夜間の評価バッチ処理前に運用部門が確認する価格例外ダッシュボードを生成します。ポジションデータについては、証券識別子、数量、市場価値による自動照合（許容差：市場価値の0.01％）を行う、カストディアンからPMSへの日次照合を実施します。また、あるカストディアンの口座でポジションがゼロになり、別のカストディアンで新たなポジションが発生した場合にフラグを立てる移管検出ロジックと、深刻度別に分類するポジション差異（1万ドル超は重大、1,000ドル超は高、1,000ドル未満は中）を導入します。クライアントデータについては、必須項目（SSN、住所、適合性確認アンケートの日付、受益者指定、信頼できる連絡先）を確認する週次の入力状況スキャン、13か月を超えて更新されていない適合性確認アンケートにフラグを立てる月次の適時性チェック、正式な氏名、住所、口座登録についてCRMとカストディアンのデータを照合する四半期ごとの整合性チェックを実施します。請求データについては、請求前の検証で請求対象AUMとPMS評価額を比較し（0.5％超の差異にフラグを立てる）、口座単位の報酬体系を検証し（アドバイザリー報酬が契約範囲内か確認）、解約済み口座を検出します（閉鎖から30日を超えた口座には請求しない）。ゴールデンソースの指定を正式化します。ポジションと法的本人確認情報はSchwab／Fidelity、リレーションシップと適合性データはSalesforce、運用実績はOrion、証券評価額は価格ベンダーを情報源とします。週次のデータ品質スコアカードを作成し、月曜日の運用会議で確認します。

分析： このフレームワークにより、当初の3つの問題すべてに体系的に対処できます。債券価格の更新停止は、運用実績の計算に反映される前に、毎日の価格検証で検出されます。移管済みのポジションは、請求処理の実行前にポジション照合で検出されます。更新されていない適合性データは、アドバイザーが余裕をもって連絡できるよう、入力状況スキャンでフラグが立てられます。継続的なコストは、運用アナリストの業務時間約0.5 FTEとモニタリングツールのライセンス費用です。同社は6か月以内に、価格精度99.5％、金額ベースのポジション差異0.1％未満、クライアントデータの入力率95％を目標としています。週次スコアカードによって組織としての説明責任が生まれます。COOが価格例外率の上昇傾向を確認すると、議論は事後対応の火消しから、ベンダー管理やプロセス改善への先を見越した取り組みに移ります。

例 2：証券価格算定パイプラインの検証ルールの構築

シナリオ： ある資産運用会社は、50 の機関投資家向けセパレートアカウントと 8 つの合同運用ファンドで保有する、米国株式・国際株式、社債、地方債、ストラクチャード商品、オルタナティブ投資の 3,500 銘柄について、毎晩評価額を算定しています。現在の価格算定プロセスでは、検証を行わずに単一のベンダーファイルを読み込み、運用チームが毎晩 50 件の価格を手作業でサンプル確認しています。最近発生した問題は、ベンダーがカバレッジを終了した後も、ストラクチャード商品が 2 週間にわたって額面価格で評価されていたこと（ファイルには最終確認価格がフラグなしで含まれていました）、国際株式が誤った通貨（USD ではなく GBP）で評価されたことで 1 つのファンドに 30％の評価誤差が生じたこと、そして地方債の小数点位置の誤り（105.00 ではなく 10.50）により重大な NAV 誤差が生じ、株主からの苦情で初めて発覚したことです。

設計上の考慮事項： 同社は多層の検証パイプラインを導入します。レイヤー 1（ファイルレベル）：想定時刻（EOD 価格算定の場合は米国東部時間午後 6 時 30 分）までにファイルが到着したことを確認し、レコード数が想定範囲（3,400～3,600 件）内であることを検証します（3,300 件未満または 3,700 件超の場合にフラグを設定）。また、ファイル形式の整合性（ヘッダー、区切り文字、エンコーディング）も確認します。レイヤー 2（フィールドレベル）：すべての価格が正の数値であること、通貨コードが有効な ISO 4217 コードであり証券マスターの想定通貨と一致すること、価格日が想定営業日と一致すること、識別子（CUSIP／ISIN）が証券マスターに存在することを確認します。レイヤー 3（フィールド間）：価格と数量の積が各ポジションの妥当な時価となることを確認します（分散投資戦略では、単一ポジションがファンド NAV の 20％を超える場合にフラグを設定）。債券価格は標準的な慣行に従って表示されている必要があります（大半は額面に対する割合、転換社債はドル価格。証券種別に基づいて検証します）。レイヤー 4（時系列）：前日との変動を資産クラス別のしきい値で確認します（株式 15％、投資適格債 3％、ハイイールド債 8％、ストラクチャード商品 10％、地方債 5％）。また、資産クラスごとの期間に基づいて価格の陳腐化を検出します（株式 2 日、流動性の高い債券 5 日、ストラクチャード商品 15 日、オルタナティブ 45 日）。さらに、価格に変化がない状態と真の陳腐化を区別します（マネー・マーケット・ファンドの NAV が 1.0000 のまま何カ月も変わらないのは正しく、陳腐化ではありません）。レイヤー 5（情報源間）：総エクスポージャーが 100 万ドルを超えるすべての証券について、第 2 ベンダーの価格と比較し、差異がしきい値を超えた場合にフラグを設定します（株式 2％、債券 5％）。例外の振り分け：重大な例外（価格がゼロ、通貨の誤り、ファイルの欠落、NAV に影響する変動）が発生した場合、価格算定担当者にただちに通知し、評価バッチをブロックします。重要な例外（価格の陳腐化、中程度の変動）はバッチ処理の前に解決する必要がありますが、ただちに通知する必要はありません。価格算定担当者は、定義された優先順位に従って例外を解決します。優先ベンダーの価格を採用する、第 2 ベンダーの価格に差し替える、ブローカーの気配値を取得する、または手動で上書きする（監督者の承認と監査証跡への根拠の記録が必要）という方法があります。

分析： この 5 層のパイプラインにより、過去に発生した 3 種類すべての問題を検出できます。カバレッジが終了したストラクチャード商品は、レイヤー 4 の価格陳腐化検出で検出されます。通貨の不一致は、レイヤー 2 の証券マスターとの通貨コード検証で検出されます。小数点位置の誤りは、レイヤー 4 の変動チェックとレイヤー 5 の情報源間比較で検出されます。同社は、価格算定担当者の業務量を管理可能な範囲に保つため、毎晩、対象全体に対する誤検知率を 3％未満に抑えることを目指します。ブロック動作を有効化する前に、30 日間のベースライン期間を設けてしきい値を調整します。最も重要な設計上の判断は、重大な例外によって評価バッチをブロックすることです。これにより、不正確なデータが NAV 計算や顧客レポートに到達するのを防ぎ、市場開始前に解決できる社内の運用上の問題へと変えることができます。

例 3：規制報告の準備に向けたデータ品質評価の実施

シナリオ： 中規模のブローカー・ディーラー兼 RIA（両方の登録を受け、運用資産は 80 億ドル、従業員は 200 人）が、SEC による検査の可能性に備えています。CCO は規制報告をリスク領域として特定しています。同社は Form ADV、Form CRS、13F 報告書、FOCUS 報告書（ブローカー・ディーラー）を提出し、機関投資家の見込み顧客に GIPS 準拠の運用実績資料を提供しています。CCO は、検査前に不備を特定して是正するため、データ品質評価を実施したいと考えています。

設計上の考慮事項： 評価は規制上の義務ごとに構成し、各提出書類のソースデータについて、6 つのすべての観点からデータ品質を評価します。Form ADV：AUM の計算が、照合済みの入力データを用いた文書化されたプロセスを通じて、カストディアンのポジションデータまで追跡できることを確認します（正確性、系譜）。顧客数が CRM と一致し、計数方法が文書化されていることを確認します（完全性）。ADV Part 2A の手数料体系が請求システムの設定と一致することを確認します（一貫性）。懲戒歴の開示内容を FINRA BrokerCheck および社内記録と照合します（正確性）。13F 報告書：報告書に含まれる証券の範囲が、すべての口座で保有する 13(f) 証券と一致することを検証します（完全性）。報告日時点の株式数がカストディアンの記録と照合されていることを確認します（正確性）。証券の分類を SEC の Section 13(f) Securities Official List と照合します（妥当性）。カストディアンのポジションデータから集計を経て提出済み報告書に至るデータフローを文書化します（系譜）。FOCUS 報告書：各項目を、計算方法を文書化したうえでソース元帳の記帳まで追跡します（系譜、正確性）。純資本計算の入力値を試算表と照合して検証します（正確性、一貫性）。顧客準備金の計算（Rule 15c3-3）に、照合済みのポジションデータと現金データが使われていることを確認します（正確性）。GIPS 運用実績資料：複合運用の構成銘柄リストを、社内の組み入れ・除外基準と照合し、裁量による除外があればその記録を確認します（完全性、妥当性）。リターンの計算に、カストディアンとの照合済み評価額が使われていることを確認します（正確性）。資料に必要な開示事項がすべて含まれ、文書化された誤り訂正手順による場合を除いて、過去のリターンが遡及的に変更されていないことを検証します（一貫性、妥当性）。横断的な評価：報告データのすべての要素を信頼できる唯一の情報源に対応付け、指定されていない情報源を記録します。報告に重要なすべてのフィールドについて完全性と妥当性のプロファイリングを行い、実際のデータ利用可能時期を提出期限および余裕期間と比較して適時性を検証します。また、過去に提出した報告書を、アーカイブされたソースデータから再現できることを確認します（SEC 検査でよく求められます）。是正対応には優先順位を付けます。重大な指摘（誤った報告書につながるデータ）は 30 日以内、高優先度の指摘（系譜の文書化不足、信頼できる唯一の情報源の指定漏れ）は 60 日以内、中優先度の指摘（プロセス文書の不足、モニタリング強化）は 90 日以内の解決を目指します。

分析： この評価により、規制報告は定期的な事務作業から、継続的に品質管理されるプロセスへと変わります。この領域で検査時に最もよく指摘されるのは、提出済みの数値を再現できないことです。13F のポジション数や ADV の AUM 数値をソースデータまで追跡できない企業は、不利な指摘を受ける可能性があります。評価によって通常明らかになる最大の不備は系譜の文書化であり（正しい報告書を作成できても、その作成過程を証明できない企業が多くあります）、次に提出頻度の低い書類における完全性の問題が続きます。是正対応には相当な作業が必要ですが（コンプライアンス、オペレーション、テクノロジー部門を合わせて推定 200～400 時間）、検査リスクを大幅に低減できます。

よくある落とし穴

• データ要素ごとに正本となるソースを指定していない。 正本となるソースを明示的に指定しないと、複数のシステムで同じデータの異なるバージョンが管理され、解消できない競合が発生し、紛争や検査の際に信頼できる回答が得られなくなります。
• 読み込み後にデータを検証している。 無効なデータが本番環境に入ると、修正を適用する前に下流システムへ伝播します。検証は読み込み後ではなく、読み込みプロセスの条件として実施する必要があります。
• データ品質をビジネスプログラムではなく、テクノロジープロジェクトとして扱っている。 テクノロジーは品質を実現しますが、ガバナンスにはビジネス部門によるオーナーシップ、データスチュワードの説明責任、経営幹部の支援が必要です。テクノロジーだけの取り組みでは、継続的に定着しないツールが生み出されます。
• 検証のしきい値が厳しすぎる、または緩すぎる。 しきい値が厳しすぎると誤検知が過剰に発生し、アラート疲れを招いて例外が無視されます。緩すぎると重大なエラーを見逃します。過去のデータを使って調整し、四半期ごとに見直してください。
• 頻度の低いプロセスのデータ品質を軽視している。 四半期または年次のプロセス（規制当局への提出書類、税務報告、GIPSプレゼンテーション）は、日次のプロセスほど運用上の注意を払われませんが、そこでのデータ品質の不備は、規制面や評判に不釣り合いなほど大きな影響を及ぼします。
• データ品質を測定しても、その測定結果に基づいて行動していない。 スコアカードやダッシュボードは、明確に定義された修正ワークフロー、担当者の割り当て、改善への説明責任がなければ意味がありません。行動を伴わない測定は、ガバナンスが機能しているという誤った安心感を生みます。
• ベンダーのデータは正しいと思い込んでいる。 ベンダーのデータも、他のソースと同じように検証する必要があります。ベンダーにはエラー、カバレッジの不足、配信の失敗があります。複数のベンダー間で比較することは重要な品質管理であり、任意ではありません。
• 規制当局に求められるまでデータリネージを整備していない。 データリネージを事後的に構築するには、費用がかかり、エラーも発生しやすくなります。データパイプラインの構築当初からリネージを組み込めば、検査の圧力の下で後付けする場合と比べて、費用を大幅に抑えられます。
• ワークフローツールを使わずに例外を手作業で管理している。 メールやスプレッドシートで例外を追跡すると、例外の見落とし、一貫性のない解決、指標の欠如、監査証跡の欠落につながります。例外管理には、割り当て、SLAの追跡、レポート機能を備えた専用ワークフローが必要です。
• データ品質とデータ量を混同している。 データソースを増やしても品質は向上せず、複雑さが増すだけです。ソースを追加するたびに、統合、検証、競合の解決が必要になります。適切な検証を備えた、より少数で高品質なソースのほうが、管理が不十分な多数のソースよりも優れています。
• 検証ルールをバージョン管理していない。 検証ルールが変更されると、過去の例外データとの比較ができなくなります。傾向分析と監査に対応できるよう、検証ルールセットをバージョン管理し、変更内容を文書化してください。
• 市場データに比べて、顧客データの品質への投資が不足している。 企業は通常、価格検証を堅牢に構築する一方、顧客データの品質を軽視しています。顧客データのエラーは、AMLスクリーニングの失敗、請求に関する紛争、規制当局からの指摘、サービス提供の不備を引き起こし、顧客に直接影響します。

相互参照

• reference-data（data-integration プラグイン）— 参照データ（証券マスター、顧客マスター、口座マスター）は、データ品質ガバナンスが適用される主要な領域です。参照データの品質が、すべての下流プロセスの品質を左右します。
• market-data（data-integration プラグイン）— 市場データの価格品質は重要なデータ品質領域です。リアルタイムおよび EOD の価格検証ルールは、データ品質の原則を適用する中核となります。
• integration-patterns（data-integration プラグイン）— 統合の失敗（ファイル配信の問題、API エラー、変換の不具合）は、データ品質問題の主な原因です。統合アーキテクチャによって、データリネージを取得できる範囲が決まります。
• reconciliation（client-operations プラグイン）— 照合はデータ品質を検知する主要な統制です。システム間でポジション、取引、現金を比較し、データ品質の不備によって生じた差異を特定します。
• gips-compliance（compliance プラグイン）— GIPS では、コンポジットの完全性、評価の正確性、リターン計算の完全性など、パフォーマンスデータに関するデータ品質統制の文書化が求められます。
• books-and-records（compliance プラグイン）— データ品質は、規制上の記録保持義務に直接影響します。不正確または不完全な記録は、SEC Rule 17a-4 および Investment Advisers Act の要件に違反します。
• regulatory-reporting（compliance プラグイン）— 規制当局への提出書類（Form ADV、13F、FOCUS、Form PF）は、正確で完全なソースデータに依存します。報告データの品質不備は、規制上の直接的なリスクにつながります。
• operational-risk（trading-operations プラグイン）— データ品質の不備はオペレーショナルリスクの一種です。重大なデータエラーは、金銭的損失、規制上の制裁、評判の毀損を招く可能性があります。