Compliance Data Lab --Making Compliance Closer

＜講師＞
JDMC会員
コンプライアンス・データラボ株式会社 CTO兼CDO
ウオリック・マセウス(Warwick Matthews

＜アジェンダ＞
1. データマネジメントの進化
- 企業や行政に必要なもの
- データマネジメントの進化
- ツールやニーズがどのように変化しているのか
2. ケーススタディ– 米国大手企業におけるDM, DQ 及びIDR について
- 背景、出発点
- 「スピードの必要性」vs 適切なDM
- データフリクション vs 一貫性
- アジャイルデータ
- 高度なエッジデータマネジメント
3. アイデンティティ・レゾリューション
- どこで活用され、その重要性について
- IDR: 神話と現実
- 予測性とデータ量（多 vs 少）
4. アジア言語・IDR
- 課題、アプローチ
- 翻字
- ベストプラクティ

＜関連サイト＞
※研究会ページ
https://japan-dmc.org/?p=21771
※JDMC「MDMとデータガバナンス研究会」主催のオープン研究会にて発表
https://jdmc.connpass.com/event/284036/

Transcript

1. JDMC Presentation
   2 0 2 3 年 0 5 月 2 6 日
   Compliance Data Lab
   Making Compliance Closer
   © C D L . C O M M E R C I A L I N C O N F I D E N C E . D O N O T R E D I S T R I B U T E . V1
   CDL WWW
   COMPLIANCE STATION
   

   View Slide

2. agenda
   1. データマネジメントの進化
   - 企業や行政に必要なもの
   - データマネジメントの進化
   - ツールやニーズがどのように変化しているのか
   2. ケーススタディ– 米国大手企業におけるDM, DQ 及びIDR について
   - 背景、出発点
   - 「スピードの必要性」vs 適切なDM
   - データフリクション vs 一貫性
   - アジャイルデータ
   - 高度なエッジデータマネジメント
   3. アイデンティティ・レゾリューション
   - どこで活用され、その重要性について
   - IDR: 神話と現実
   - 予測性とデータ量（多 vs 少）
   4. アジア言語・IDR
   - 課題、アプローチ
   - 翻字
   - ベストプラクティス
   

   View Slide

3. 1. はじめに
   DM（データマネジメント）の進化に関して
   

   View Slide

4. 視点を保つ – 我々がここにいる理由
   企業や政府は、より良いIDRやより多くのデータを必要とするのではなく、データに
   よって推進されるより良い結果が必要なのです。
   我々はデータに溺れてしまっています-
   より速くより多くのデータで仕事を行う必要があります。
   People don't want to buy a quarter-inch drill.
   They want a quarter-inch hole!
   “
   ”
   THEODORE LEAVITT, HARVARD BUSINESS SCHOOL
   人々は四分の一インチのドリルを買いたいわけではありません。彼らは四分の一インチの穴が欲しいのです！
   

   View Slide

5. データとアナリティクスの進化
   1995 2000 2005 2010 2015 2020 次は?
   データ
   ウェアハウジング
   MDM
   の台頭
   データレーク “エッジデータ”
   “データ
   ファブリック”
   ナレッジ
   グラフ
   クラウド
   データサイエンスとアナリティクスの台頭
   ビッグ
   データ
   2023
   

   View Slide

6. リレーショナル NOSQL (ドキュメント) グラフ バーチャル
   - 冗長なデータを避けることができる
   - 伝統的なテクノロジー
   - ACID
   - 長い歴史がある
   - 設計とメンテナンスが複雑
   - オペレーショナル・オーバーヘッド
   • 柔軟
   • 拡張性が高い
   • ACIDではない (通常)
   • 高速 in/out
   • 複雑な統合には不向き
   • 殆どの物を接続可能
   • 高度なグラフクエリやアナリティクス
   をサポート
   • 全く異なるパラダイム
   • 大規模なデータの「ペイロード」に対
   して最適ではない（「膨張」のリスクが
   ある）
   • 大規模運用ではコストが嵩む可能性
   がある
   • ETLなしでデータの恩恵を受けられる
   • ベンダーのエコシステム手動になる
   傾向がある
   • 複雑なセキュリティ体制を必要とする
   場合がある (e.g. VPC ピアリング等).
   e.g. PostgreSQL, MSSQL e.g. MongoDB, DynamoDB e.g. Neo4J, TigerGraph, Neptune e.g. Snowflake
   データ処理、キュレーション、および統合のオプション
   { ☰ }
   MSSQL
   MONGODB
   NEO4J / AWS NEPTUNE
   AMPERITY
   SAP GIGYA
   ACXIOM
   SNOWFLAKE
   注意: これは非常に簡
   略化されたリストで
   す！
   

   View Slide

7. ケーススタディの前に…チャタムハウスルールについて
   When a meeting, or part thereof, is held under the Chatham
   House Rule, participants are free to use the information
   received, but neither the identity nor the affiliation of the
   speaker(s), nor that of any other participant, may be revealed.
   このルールの目的は、会議室の壁の内側で話をする人々に匿名性を保証し、より良い国際関係が達成されることにある。現在、
   このルールは国際的に使用され自由な議論を支援している。1927年当初の規則は、1992年10月と2002年に改訂された。
   チャタムハウスルールに基づいて会合が開催された場合、参
   加者は受け取った情報を自由に使用することができますが、
   発言者や他の参加者の身元や所属を明らかにすることはで
   きません。.
   

   View Slide

8. 2. ケーススタディ
   北米の有名なスポーツリーグの事例
   

   View Slide

9. ケーススタディ：スポーツリーグ
   • 北米の主要スポーツリーグ
   • 倶楽部、リーグ、スポンサー、パートナーとの複雑なステークホルダー関係
   • 1億4千万人以上のファン/顧客
   • 3-4千万件の更新/日（~20億件の更新/月）12か月で10倍の増加
   • データは日次フルファイル、差分、重複が混在
   • 20以上のサプライヤー、10以上のフォーマット
   • 非常に急速な有機的成長
   • 常に、より多くのデータを追い求めている（特にサードパーティ）
   • 日々、データの種類、信ぴょう性、量が大きく変化する
   • 短期的成果のみ追い求める 「今日は何をしてくれたの？」という思考
   • 2022年までデータ戦略がない
   • 大規模なサイロ式文化
   • アップグレードする余地がない：まるで走行中のバスのタイヤを交換するような感覚
   課題：
   

   View Slide

10. • ファイルベースのアーキテクチャ
    • 100以上の S3 Bucket
    • 1000以上のフォルダ
    • 何度もコピーされたデータ
    • 「真実の情報源」がない(MDM)
    • ガバナンスがない
    • 一貫性がない
    • ドキュメント化されていない
    ケーススタディ：出発点
    

    View Slide

11. 次のスライド：ケーススタディーからさらに戦略的な学びを得る
    1. スタンダードビューの作成及び
    ドキュメント化
    2. MDMの導入 3. 柔軟なユースケースビュー
    • データサイロの競合は、品質を低下させ、
    信頼性を損なわせる
    • 情報の順位付け
    • 最適なものを選択する
    • それらをスタンダードビューとして使用
    • 素早く実装でき、優先順位ルールも不要
    • 「箱から出してすぐ使える」MDM ソリューション
    の導入
    • 構築は推奨せず：技術的能力がないため
    • 完全に搭載する必要がなく、データのクラスタリ
    ングが可能なシステムを利用する
    • 主要なステークホルダ（デジタルチーム、クラブ、マー
    ケティングチーム）と実際に何が必要かを検討する
    • 完全なレコードは必要ない：通常はSuper 6（主
    要6項目）で対応可
    • ソース及びキュレーションデータを使用し、「目的に
    合った」ビューを作成
    • 標準的な品質ルールとフィードバックサイクルについて、
    上流ソースと連携
    ケーススタディ：段階的な解決策
    

    View Slide

12. リーグの主な課題: スピードの必要性 vs. 適切な DM
    どのようにしてボリュームを指数関数的に増やし、同時にレイテンシーを削減するか、一貫性のないデータが不統一
    なデータサイロに流れ込むことなく、制御された状態を保つことができますか？
    データフリクションはデータを迅速に使用可能な状態にすることを妨げます。しかし、データ処理には障壁が存在し
    なければならない理由があります：
    • Identity Resolution（アイデンティティの解決）
    • 標準化/データクリーニング
    • コンプライアンスの必要性
    • 構造的課題 （例：データサプライチェーンを通じた複数の手続きや再設計を必要とする、複雑なデータ処理）
    If you need to be able to action data daily, you can’t have a data
    supply chain that takes 72 hours to deliver it.
    日次でデータ処理をする必要がある場合、72時間かけてデー
    タを届けるようなサプライチェーンはありえない
    

    View Slide

13. スピードの必要性 – リスク: データフリクションvs一貫性
    • データフリクションを減らすとデータはより簡
    単に、より速く流れるようになります。
    • しかし、矛盾が増える危険性があります。
    • つまり、データが無秩序に環境内で拡散し
    てしまうのです。
    • 結果、企業の様々な場所で、同一企業の
    一貫性のないビューが多く存在することに
    なります。
    リスク: フリクションが減っても、不整合が増える…
    フリクション
    不整合
    

    View Slide

14. スピードの必要性 – アジャイルデータ
    「データレイク」や「レイクハウス」は非常にトレンディなバズワードですが、従来のデータウェハウスを新しいクラウド
    技術で構築しただけのものであることがあります。
    しかし、アジャイルデータ処理はリアルで非常に価値のあるものです。このアプローチは以下のことを保証しま
    す：
    • データを残しません（すべてがレイクハウスに流れます）
    • 処理（フリクション）はユースケースに見合ったものです（例：目的に合ったDM）
    • DM チームは、ユースケース（ステークホルダ）毎に異なるSLAを提供できます
    FRAUD
    CUSTOMER SERVICE
    MARKETING
    IDR
    “データレイクハウ
    ス”
    利用可能になるまでの時間➔
    データクリーニング
    

    View Slide

15. ソリューション：中央集権ではなく接続に重点を置く
    “データレイクハウス”
    IDRで接続
    Match システムはアイデンティティのブローカーとして機能します。データは一
    元的に取り込まれ、管理されますが、IDが一貫して提供され、アイデンティティ
    システムによって記録される限り、組織内のどこでも管理することができます。
    アイデンティティのリクエストはどこからもで可能です。
    クライアントシステムは、
    玲クアハウスや互いに接
    続するためのIDを要求す
    ることができます。
    

    View Slide

16. 将来：エッジデータマネジメント
    データの事前準備とクリーニングはここ
    で（ソースの近く）で行われる。エッジコ
    ンピューティング/IoTの進化の一部。
    課題：DMの「真実のポイント」に至
    る経路に、複数のタッチポイントとハ
    ンドオフがあること。
    課題：エッジDQをここからどのよう
    に管理すべきか？
    

    View Slide

17. 3. アイデンティティ・レゾリューション(IDR)
    1. コンセプトとアイデア
    

    View Slide

18. なぜ、今、IDRが重要なのか
    1:1 大規模な範囲での関与
    • 消費者は、マーケティングとエンゲージメントが高
    度にパーソナライズされ、適切であることを期待し
    ます。
    • .最適なリーチを保証するため、消費者が誰なの
    か知る必要があります。
    コンプライアンス、同意、プライバシー
    • 消費者規制の体制が「プライバシーファーストになりつつ
    あります：GDPR（EU)、CCPA（カリフォルニア）、CPA
    （コロラド）」等。
    • 対象者が誰なのかわからなければ、データを適切に管
    理することはできません。
    • 法律は、消費者の視点から（受動的に）書かれてい
    ます。企業が、その人が誰であるかを知っていると仮定
    します。
    • 積極的なコンプライアンスには、効果的なIDRだけでなく、
    継続的な活動関しが必要です。
    

    View Slide

19. 神話：企業は我々の事を全て知っている
    19
    • 企業や政府は、対象者のことを何でも知っているという認識があ
    るようです。
    • 確かに、多くのデータを収集しているのは事実です
    • しかし、それを実際に繋げることはできているのでしょうか？
    • 法的に、倫理的にどうでしょうか？
    

    View Slide

20. アイデンティティ・レゾリューションの本当の姿とは…
    20
    

    View Slide

21. View Slide

22. 実証主義
    vs
    建設主義
    アイデンティティモデル（と現実）
    22
    

    View Slide

23. 2. コンセプトと用語の一致
    3. アイデンティティ・レゾリューション(IDR)
    

    View Slide

24. データポイントの「スープ」からのIDR
    ? ?
    does something with
    

    View Slide

25. データポイントの「スープ」からのIDR
    ? ?
    does something with
    

    View Slide

26. データポイントの「スープ」からのIDR
    ? ?
    does something with
    

    View Slide

27. マッチング の「パイ」
    マッチ環境
    参照ファイル
    入力データ
    

    View Slide

28. マッチ率
    マッチ率と正確性は同じものではありません。
    マッチ率は、アルゴリズムによって生成されたケースの数を示しています。
    「信頼度」は正確性の測定に基づいて、どの程度の割合の「一致」が正しい可能性が高いかを示しています。
    「90%のマッチ率を達成しました...
    …しかし全ての一致は誤りでした」
    

    View Slide

29. マッチ率 vs 信頼度/正確性
    マッチ率は数学的に導き出されており、結果を計算します。
    信頼度は経験的に導かれるもので、品質を測定します。
    （正確には、正確性はサンプルに対し測定したもので、信頼度はその測定値から導き出した結論となります）
    

    View Slide

30. IDRの成果を表現する
    良いアプローチ:
    「80%の信頼度で、60%のマッチ率を得ることができた」
    これにより、より強力で有用なステートメントを作成することができるようになります
    例：
    次のような「マッチ率」を受け取りました：
    「次のようなマッチ率を受け取りました：
    • ファイルの25%を100%の信頼度で算出しました – これらを「A」マッチと呼びます
    • ファイルの25%を70%の信頼度で算出しました – これらを「B」マッチと呼びます
    • ファイルの40%を50%の信頼度で算出しました – これらを「D｝マッチと呼びます
    - 実際に欲しい結果はどれだけありますか？ A B D
    0% 25% 50% 75% 100%
    

    View Slide

31. 「ゴールデンレコード」が必ずしもゴールデンでない理由
    • 「ゴールデンレコード」や「ベストビュー」の作成はごく当たり前の事です。
    • 多くのMDMシステムがこれを実現しています。
    • 進化するDMの世界では、最適な方法とは言えなくなってきています
    – 多くの異なるソースに基づくスーパーセットのレコードを維持することは非
    常に困難です（複雑な優先順位ルール）
    – ゴールデンレコード制度は、サードパーティデータを試金石として最適に機
    能することが多く、このデータの取得が問題になってきています（同意とプ
    ライバシー規制）
    – 高速（低摩擦）なデータサプライチェーン（DSC）のニーズは、非常に
    迅速に処理する必要があります。複数の「目的に適した」ビューは単一
    のゴールデンレコードに代わる、実用的な選択肢です。
    – つまり、ユースケースごとに異なるビューを作成することです。
    

    View Slide

32. MDM-IDR のアプローチ
    従来のMDMは、ETLとデータモデルを使用して、あらゆるユースケースを
    サポートするように設計された「ゴールデンレコード」にデータをまとめます。
    別のアプローチとしては、データをより緩やかに接続し、文脈に応じた複数のビューを作
    成することです。
    ロード ➔ 変換 ➔ 識別 ➔ 保存 ➔ 利用
    段階 ➔ 接続 ➔ 結合 ➔ 利用
    GOLDEN RECORD
    

    View Slide

33. 3. 参照 VS 非参照クラスタリング及びマッチング
    3. アイデンティティ・レゾリューション(IDR)
    

    View Slide

34. 非参照クラスタリング
    FILE 1
    F1-1 WILLIAM SMITH
    F1-2 RICHIE DAVIES
    F1-3 DAVID SMITH
    F1-4 SARAFINA NICKELBY
    F1-5 DR RAJIV SUBRAMANIAN
    F1-6 DAVE SMITH
    FILE 2
    F2-1 WILLIAM SMITH
    F2-2 RISHI DAVE
    F2-3 SMITH DAVID
    F2-4 JOHN GLEESON
    F2-5 RAJIV SUBRAMANIAN
    MATCHED FILE
    F1-1 WILLIAM SMITH
    F2-1 WILLIAM SMITH
    F1-3 DAVID SMITH
    F1-6 DAVE SMITH
    F2-3 SMITH DAVID
    F1-4 SARAFINA NICKELBY
    F2-4 JOHN GLEESON
    F1-5 DR RAJIV SUBRAMANIAN
    F2-5 RAJ SUBRAMANIAN
    一致
    一致
    ?? 不一致??
    F2-2 RISHI DAVE
    F1-2 RICHIE DAVIE
    34
    孤立レコード??
    孤立レコード??
    

    View Slide

35. 参照マッチング
    IDR 環境
    マッチ参照ファイル
    FanID 1 WILLIAM SMITH
    FanID 2 JOHN GLEESON
    FanID 3
    SMITH, DAVID ★
    DAVE SMITH
    FanID 4 DAVID SMITH
    FanID 5 SARAFINA NICKELBY
    FanID 6
    RICHIE DAVIES ★
    RISHI DAVE
    FanID 7 RAJIV SUBRAMANIAN
    F1-1 FanID 1 WILLIAM SMITH
    F2-1 FanID 1 WILLIAM SMITH
    F2-3 FanID 3 SMITH DAVID
    F1-6 FanID 3 DAVE SMITH
    F1-2 FanID 6 RICHIE DAVIES
    F2-2 FanID 6 RISHI DAVE
    !
    F2-5 FANID 7 RAJIV SUBRAMAN
    F1-5 FANID 7 DR RAJIV SUBRAMANIAN
    F1-3 FanID 4 DAVID SMITH !
    • 独立してキュレーションされている
    • 独立した更新プロセス
    FILE 1
    F1-1 WILLIAM SMITH
    F1-2 RICHIE DAVIES
    F1-3 DAVID SMITH
    F1-4 SARAFINA NICKELBY
    F1-5 DR RAJIV SUBRAMANIAN
    F1-6 DAVE SMITH
    FILE 2
    F2-1 WILLIAM SMITH
    F2-2 RISHI DAVE
    F2-3 SMITH DAVID
    F2-4 JOHN GLEESON
    F2-5 RAJIV SUBRAMAN
    36
    

    View Slide

36. 4. 予測性と、より多くのデータ VS より少ないデータ
    3. アイデンティティ・レゾリューション(IDR)
    

    View Slide

37. 郵便番号は非常に興味深く、汎用性の高いデータです。郵便番号と他のデータ
    も収集することで人口密度の指標として使用することができます。
    例えば、モンタナ州の小さな町で同じ生年月日の二人の「ジョン・スミス」が別人
    である可能性は、ニューヨーク州の都市部と比べると、はるかに低いと考えられま
    す。
    このようなデータポイントは、アイデンティティがユニークでないという、リスクを示すス
    コアを作成するのに役立ちます。
    Flushing NY
    面積 2.17 mi²
    人口 54,878
    人口密度スコア 25324
    Beaverhead County, MT
    面積 2,169,78 mi²
    人口 7,963
    人口密度スコア 4
    予測性：郵便番号の事例
    39
    11354
    59725
    https://www.unitedstateszipcodes.org/59725/
    

    View Slide

38. ?
    ?
    ?
    ?
    ?
    Allison Bojanski
    Ally Bojarski
    Allison Bojarski
    Alison Bojarski
    A L Bojarski
    ?
    名前には何があるのか？
    Q: 名前のデータしかなく、「 Allison Bojarski 」に似た名
    前を持つ人物が他にいた場合、同一人物であるか特
    定できますか？
    A: NOです!
    © 2022 WARWICK MATTHEWS. ALL RIGHTS RESERVED. 40
    予測性：名前のみ
    

    View Slide

39. Geekタイム：名前
    X
    X
    ✓
    ✓
    !
    Allison Bojanski
    Paul Ballew
    Ally Bojarski
    Caleb Bojarski
    Allison Bojarski
    Paul Ballew
    Joseph Ruggiero
    Alison Bojarski
    Joe Ruggiero
    A L Bojarski
    ?
    隣接する名前も見てみるとどうでしょうか？
    一つの名前だけでは不十分でも、いくつかの共通で隣接する名前を
    見ることでリンクが生まれます…
    © 2022 WARWICK MATTHEWS. ALL RIGHTS RESERVED. 41
    名前には何かあるのか？
    Q:名前のデータしかなく、「 Allison Bojarski 」に似た名
    前を持つ人物が他にいた場合、同一人物であるか特
    定できますか？
    

    View Slide

40. 4. アジアの言語とIDR
    課題とベストプラクティス
    

    View Slide

41. 表意文字の一致に関する課題
    全てのマッチングにおけるカギは「類似性」です。
    日本 vs 豪州
    EASY
    DIFFERENT
    鈴木 vs 鐸木
    DIFFICULT
    ???
    日本 vs ニッポン
    EASY
    SAME
    ローマ字 vs Romanji
    DIFFICULT
    ???
    

    View Slide

42. 表意文字の一致に関するアプローチ
    従来のIDRシステムの中には、日本語に不向きなものもあります：
    • レーベンシュタイン (編集距離)
    • ジャロウ・ウィンクラー / メタフォン （同音異義語多し）
    代わりとして以下を使えます:
    • 画数
    • カナベースの音声比較
    – m:m 比較内臓で
    • 表音文字 （部首）
    • 意味論
    効果的なイデオグラムマッチングは、アルファベットベースのマッチ
    ング（アルゴリズムに基づく傾向あり）よりも、辞書に基づくこと
    が多いです。
    辞書はファジー検索をサポートすることができます：
    • 地域データ：道路、近隣地域、都道府県
    • 名前：苗字、名前
    • 種類：役職、業種
    

    View Slide

43. 音訳 – 大きな課題
    「日本」
    • Japan
    • Nippon
    • Japon (🇫🇷)
    • Japón / Japona (🇪🇸)
    • Riben (transliteration from Chinese)
    「和牛」
    • “Wagyu Beef” （tautological)
    • “Japanese-style Beef”
    • 和牛ビーフ
    「Chris」➔ 「 クリス 」
    • Chris (男, 女)
    • Christopher (男)
    • Kris (男, 女)
    • Chrissy (女)
    • Christina (女)
    「Matthews, Warwick」
    • ワーウィック・マシューズ
    • ウオリック・マセウス
    • ワリク・マテウス
    ファーストネームは
    どっち？
    

    View Slide

44. グローバルデータ - ベストプラクティス
    • 全てをユニコードに
    • タイプを明示的に設定します！（UTF8 BOM 等）
    • ビジネスデータの受渡では、エクセルやノートパッドは避けましょう！
    • 「受領した状態」で保存、マッチ (低摩擦 / データレイクハウスコンセプト）
    • 可能な限り辞書を整備する
    • データモデルが複数のバリアントを扱えるようにする
    • 優先的な名前、受領した名前、推定された名前等に分類
    • 言語にとらわれない、またはアジア言語に最適化されたIDR/MDMシステムを
    使用する
    • ベンダーにフィードバックについて確認 – Yes/Noだけではない
    • 実際に使用されるアルゴリズムについて確認
    • Soundex ❌
    • Levenshtein ❌
    • Metaphone 🔶
    • Fellegi-Sunter🔶
    • 文字カウント🔶
    • ローカルウェブサービス検索✅ ✅
    

    View Slide

45. APPENDICES
    Extra Slides
    Compliance Data Lab
    Making Compliance Closer
    

    View Slide

46. MEASURED ACCURACY
    MATCH SCORE
    Monotonic: Good
    MEASURED ACCURACY
    MATCH SCORE
    Multimodal: VERY VERY BAD
    What % of the time
    the matched answer
    is correct
    Confidence score
    returned by the
    system
    “Accuracy” in Identity Resolution.
    

    View Slide

47. MEASURED ACCURACY
    MATCH SCORE
    ① False
    negative
    ② False
    positive
    “Accuracy” in Identity Resolution (2)
    ①
    ②
    

    View Slide

48. 0 25 50 75 100
    COUNT
    SCORE
    Should quality be expected to fit a normal
    distribution (bell curve)? ?
    A B
    C D
    Quality Distribution in Matching
    

    View Slide

49. Indicia-level
    Scores
    Match Score
    “Right / Wrong”
    IDR Feedback Maturity Pyramid
    

    View Slide

50. Indicia-level
    Scores
    Match Score
    “YES / NO”
    IDR Feedback Maturity Pyramid
    Easy,
    Simplistic
    MATCH FEEDBACK:
    

    View Slide

51. Indicia-level
    Scores
    Match Score
    “YES / NO”
    IDR Feedback Maturity Pyramid
    MATCH FEEDBACK:
    

    View Slide

52. Indicia-level
    Scores
    Match Score
    “YES / NO”
    IDR Feedback Maturity Pyramid
    MATCH FEEDBACK:
    

    View Slide

53. IDR Feedback Maturity Pyramid
    Indicia-level
    Scores
    Match Score
    “YES / NO”
    Custom
    Rules
    MATCH FEEDBACK: Advanced,
    Powerful
    

    View Slide

54. Indicia-level
    Scores
    Match Score
    “YES / NO”
    IDR Feedback Maturity Pyramid
    Custom
    Rules
    Easy,
    Simplistic
    Advanced,
    Powerful
    MATCH FEEDBACK:
    

    View Slide

55. “Planetary Accretion Model”
    of Data Clustering.
    

    View Slide

56. Planetary accretion model of clustering.
    The indicia that we bring together
    to make a “person” ...
    …come together and generate their
    own kind of “gravity”, like a planet…
    SPOUSE
    NAME
    TITLE DOB
    ADDRESS ZIP
    PHONE
    WWW SOCIAL MEDIA
    EMAIL
    

    View Slide

57. Planetary accretion model of clustering.
    The more “mass” (indicia) the planet
    accretes, the bigger it gets…
    …and the bigger it gets the more mass it
    attracts…
    

    View Slide

58. Planetary accretion model of clustering.
    Eventually our “planet” gets so big (has so
    many indicia)
    that it can eat up just about anything (because
    anything will match to it).
    This is runaway accretion, and something
    we have to watch out for.
    

    View Slide

59. Thank You
    J D M C 2 0 2 3 年 0 5 月 2 6 日
    Compliance Data Lab
    Making Compliance Closer
    【お問合せ先】
    コンプライアンス・データラボ株式会社
    東京都千代田区丸の内3-2-2 丸の内二重橋ビル2F
    E-mail: info@c-datalab.com
    Tel: 03-6837-9665
    Web: https://www.c-datalab.com
    

    View Slide