> 継続的なプロセス改善 > KYC顧客オンボーディング > Refinitiv World Check > データテンプレート

KYC顧客オンボーディングのデータテンプレート

Refinitiv World-Check

KYC顧客オンボーディングの属性(19) KYC顧客オンボーディングのアクティビティ(14) データ抽出ガイド(2)

KYC顧客オンボーディングのデータテンプレート

このテンプレートでは、KYC顧客オンボーディングのプロセス分析に必要なデータの収集方法をご案内します。記録すべき属性や追跡する主要なアクティビティを示し、ソースシステムから情報を抽出する方法も説明します。プロセスを効果的に分析し、改善するために必要なデータを揃える際にお役立てください。

収集を推奨する属性
追跡する主要なアクティビティ
データ抽出ガイド

イベントログを初めて作成する方はこちら：プロセスマイニング用イベントログの作成方法.

テンプレートをダウンロード

KYC顧客オンボーディングの属性

KYC顧客オンボーディングを詳しく分析するために、イベントログに含めることを推奨するデータ項目です。

3 必須 5 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	KYCオンボーディングプロセスで発生した、特定の業務イベントまたはタスクの名称です。
説明アクティビティ名は、顧客のオンボーディングにおける個々の工程やイベントを表します。たとえば、「申請提出」「アナリストによる確認を開始」「スクリーニング完了：該当なし」などです。これらのアクティビティがプロセスマップのノードとなり、ワークフロー全体を細かく示します。アクティビティの分析は、プロセスマイニングの中核です。アクティビティの順序や発生頻度を追跡すると、実際のプロセスフローを把握し、よくある経路を特定し、標準手順からの逸脱を検出して、遅延や手戻りの原因となる工程を見つけられます。この属性は、プロセスマップの作成やアクティビティ単位の指標の計算に欠かせません。重要な理由この属性はプロセスの個々の工程を定義します。プロセスフローの把握と可視化、ボトルネックの特定に欠かせません。入手先通常、イベントログや監査証跡のテーブルに記録され、ケース管理エンティティのステータス変更と関連付けられています。例一致候補を検出アナリストによる確認を開始誤検知を確認申請を承認
	イベント時刻 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプです。
説明イベント時刻には、アクティビティが記録された正確な日時が示されます。このタイムスタンプを基準にイベントを正しい順序に並べ、ケースの履歴を再構成できます。この属性は、プロセスマイニングにおける時間ベースの分析すべてに欠かせません。アクティビティ間の所要時間（サイクルタイムや待ち時間）の計算、ケース全体の所要時間の測定、時間の経過に伴うプロセスのパフォーマンス分析、サービスレベル合意（SLA）の遵守状況の確認に使います。タイムスタンプが正確でなければ、プロセスのパフォーマンスを把握し、時間に関するボトルネックを特定することはできません。重要な理由各アクティビティのタイムスタンプは、所要時間に基づく指標の計算、プロセスの順序の把握、ボトルネック分析に欠かせません。入手先イベントログや監査証跡のテーブルにある標準的な項目です。「Timestamp」「EventDate」「CreationDate」などの名前が使われます。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	顧客申請 CustomerApplication	顧客1人分のオンボーディング申請を一意に識別するIDで、主なケース識別子として使用します。
説明顧客申請は、1人の顧客のオンボーディングに関するすべてのイベントとアクティビティをまとめる、中心的なケース識別子です。これにより、最初の申請から最終判断まで、顧客ごとの進捗をKYC（顧客確認）プロセス全体にわたって時系列で追跡できます。プロセスマイニング分析では、この属性を使って各申請のエンドツーエンドの流れを再構成します。プロセスフローの可視化、総サイクルタイムの計算、バリアントの特定が可能になります。この識別子でケースをグループ化して分析すると、申請がたどるさまざまな経路を把握し、ボトルネックを特定して、オンボーディングプロセスごとの効率を比較できます。重要な理由関連するすべてのアクティビティを結び付ける基本的なケース識別子です。顧客のオンボーディングプロセスをエンドツーエンドで分析できます。入手先通常、Refinitiv World-Checkシステムまたは連携するCRMの、申請テーブルやケース管理テーブルの主キーです。例 APP-2023-00123APP-2023-00124APP-2023-00125
	SLA目標日 SlaTargetDate	顧客のオンボーディングプロセスを完了する目標日です。
説明 SLA目標日は、顧客とのサービスレベル合意または社内方針で定められた、ケース全体の完了期限です。実際の完了時間を測る基準となります。この属性は、「SLA遵守状況と未達分析」ダッシュボードの基礎となります。ケースが期限内に完了したかどうかの計算に使います。SLA未達を分析すると、遅れの原因となるプロセス上の問題を特定し、適時性の改善やコンプライアンス要件の遵守に向けた是正措置を講じられます。重要な理由期限内の処理状況を測る基準です。SLA遵守率の計算や未達の分析に欠かせません。入手先申請日と業務ルールに基づいて算出されることが多く、ケース記録の項目として保存される場合があります。例 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-11-20T17:00:00Z
	イベント終了時刻 EventEndTime	特定のアクティビティまたはイベントが完了した時刻を示すタイムスタンプです。
説明イベント終了時刻は、アクティビティの完了時刻を示します。開始時刻と終了時刻が同じで、瞬時に完了するイベントもありますが、「アナリストによる確認を開始」から「アナリストによる確認を完了」までのように、所要時間を測定できるアクティビティもあります。開始時刻と終了時刻の両方があれば、処理時間を正確に測定できます。プロセス分析では、待ち時間を含むサイクルタイムではなく、アクティビティの正確な処理時間を計算するために終了時刻が欠かせません。ケースが実際に処理されている時間と、待ち行列で止まっている時間を区別できます。リソースの最適化や効率分析に役立ちます。重要な理由アクティビティの処理時間を正確に計算し、作業中の時間と待機時間を分けて分析できるため、パフォーマンスをより正確に把握できます。入手先所要時間のあるアクティビティでは、イベントログや監査証跡のテーブルにある「CompletionDate」や「EndDate」などの別項目に記録されている場合があります。例 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	リスクレベル RiskLevel	顧客申請のリスク分類です。「低」「中」「高」などで示されます。
説明リスクレベルはKYCプロセスにおける重要な情報で、必要なデューデリジェンスの水準を決めます。顧客の種類、地域、事業内容などの要因に基づいて判定されることが一般的です。この分類によって、申請がたどるプロセス経路が大きく変わる場合があります。プロセス分析では、リスクレベルごとにケースを分けて見ることが欠かせません。サイクルタイムやプロセスフローに違いが生じる理由を把握できます。たとえば、高リスクの申請では工程が増え、処理に時間がかかることがあります。この属性は、「申請の却下率と理由」や「バックグラウンドチェック開始までのサイクルタイム」のダッシュボードで、リスクが結果や効率に与える影響を把握する際に重要です。重要な理由リスクレベルごとにプロセスを分けて分析すると、特定のケースに時間がかかる理由や異なる経路をたどる理由を把握し、却下率を分析できます。入手先顧客申請またはケースの記録にある基本データです。Refinitiv World-Checkのケース管理モジュールを確認してください。例低中高
	確認担当者ID ReviewerId	アクティビティを実行したユーザー、アナリスト、または自動処理エージェントの識別子です。
説明確認担当者IDは、KYCプロセスで特定のタスクを実行したユーザーを示します。コンプライアンス担当のアナリストやオンボーディング担当者のほか、自動処理を行うシステムアカウントの場合もあります。この情報を追跡すると、業務量の配分や個人ごとのパフォーマンスを把握できます。この属性は、リソースに関する分析に欠かせません。ユーザーやチーム間のパフォーマンスの違いを把握し、研修の必要性を特定して、業務量の配分を最適化できます。また、引き継ぎ、ソーシャルネットワーク、コンプライアンス業務におけるリソースの利用状況を分析する際にも重要です。重要な理由業務量の配分、ユーザーのパフォーマンス、部門間の引き継ぎを分析できます。リソースの最適化に欠かせない情報です。入手先通常、イベントログや監査証跡に記録され、「UserID」「PerformedBy」「Owner」などの名前が使われます。例アナリスト_jdoe自動スクリーニング_システムマネージャー_bsmith
	部門 DepartmentName	アクティビティを実行する部門または機能別チームです。
説明この属性は、ユーザーが所属する事業部門やチームを示します。たとえば、「オンボーディング」「コンプライアンス」「品質保証」などです。個人より上位の組織単位で分析できます。部門別の分析は、部門間のボトルネックの特定や引き継ぎ時間の測定に欠かせません。チーム間で業務がどのように進み、引き継ぎのどこで遅れが生じているかを可視化できます。部門横断の連携を円滑にし、プロセス全体の効率を高めるうえで役立ちます。重要な理由部門別にプロセスのパフォーマンスを分析でき、チーム間の引き継ぎにおける遅れの特定に役立ちます。入手先この情報は、システム内のユーザープロフィールや連携する人事システムに保存されている場合があります。ユーザーIDを使ってイベントデータと結合する必要があることもあります。例オンボーディングチームコンプライアンス確認上級管理職
	SLA違反 SlaBreached	オンボーディング案件がSLA目標日を過ぎて完了したかどうかを示す真偽値フラグです。
説明この属性は、サービスレベル契約（SLA）に違反した案件を示す計算フラグです。案件の最終完了アクティビティ（「申請を承認」または「申請を却下」など）のタイムスタンプと、その案件の「SlaTargetDate」を比較して判定します。このフラグは、「SLA遵守状況と違反の分析」ダッシュボードと「SLA遵守率」KPIの基礎となります。違反した案件をすべてすばやく絞り込めるため、分析が容易になります。違反案件のプロセス特性を分析することで、組織は遅延の根本原因を特定し、改善に向けた取り組みの優先順位を適切に決められます。重要な理由サービスレベル契約の遵守状況を直接測定できるため、遅延案件の絞り込みや根本原因の分析が容易になります。入手先データ変換時に、案件の最終アクティビティのタイムスタンプと「SlaTargetDate」フィールドを比較して算出します。例 truefalse
	ソースシステム SourceSystem	イベントデータの抽出元となるシステムです。この場合はRefinitiv World-Checkです。
説明この属性は、プロセスデータの取得元を示します。単一のシステムからデータを抽出する場合は固定値になることがありますが、CRMやWorld-Checkなど複数のシステムのデータを組み合わせてプロセス全体を把握する場合に重要です。分析では、データガバナンスやトラブルシューティング、データのコンテキストの把握に役立ちます。たとえば、スクリーニングの基幹システムに記録されたアクティビティは、周辺システムのものと比べて、特性や詳細度が異なる場合があります。データの来歴を明確にし、監査できる状態に保つうえでも役立ちます。重要な理由データの取得元を特定します。データガバナンスや検証、複数のソースからのデータ統合に欠かせません。入手先データの抽出、変換、読み込み（ETL）の際に、データセットを識別するために追加される固定値であることが一般的です。例 Refinitiv World-CheckWorldCheckOne
	一致ID MatchId	World-Checkのスクリーニングで見つかった一致候補を一意に識別するIDです。
説明自動スクリーニングで制裁リスト、PEPリスト、またはネガティブ報道に該当する可能性が見つかると、該当内容を追跡するために照合IDが生成されることがあります。このIDにより、申請案件と、アラートの原因となったWorld-Checkデータベース内のレコードが結び付けられます。この属性は、コンプライアンスを詳しく分析する際に役立ちます。アナリストは照合内容を調査し、個々のアラートの対応状況（誤検知または実際の一致の確認など）を追跡できます。また、どの種類のアラートが多いか、解決に時間がかかるかを把握できます。「一致の可能性を検出」アクティビティを、より詳しく分析するための情報を提供します。重要な理由個々のスクリーニング結果との詳細な関連付けにより、照合の解決にかかる時間やアラートの種類を詳しく分析できます。入手先一致の可能性が見つかった際に、World-CheckのスクリーニングエンジンがこのIDを生成し、申請案件に記録します。例 WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	最終データ更新日時 LastDataUpdate	このイベントのデータがソースシステムから最後に更新または抽出された時刻です。
説明この属性は、データの鮮度を示します。Refinitiv World-Checkから最後にデータを取得した日時を記録します。プロセスマイニングのダッシュボードや分析が、どの程度最新のデータに基づいているかを把握するうえで重要です。分析する際に、ほぼリアルタイムのデータを見ているのか、特定時点のスナップショットを見ているのかを確認できます。データガバナンスを支え、提示されるインサイトの最新性について利用者の認識をそろえるためにも欠かせません。重要な理由データの鮮度に関する重要なコンテキストを示し、プロセス分析がどの時点までのデータに基づいているかを把握できます。入手先このタイムスタンプは、データ抽出（ETL）の際に生成、追加されます。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	却下理由 RejectionReason	顧客申請を却下した際に記録される具体的な理由です。
説明申請を却下した場合、その理由を却下理由として記録します。「制裁対象者との一致」「文書の不備」「高リスク」などが考えられます。これにより、申請内容の品質やスクリーニングプロセスの有効性について、構造化された情報を得られます。この属性は、「申請の却下率と理由」ダッシュボードの主な分析項目です。理由を分析すると、却下の根本原因を特定し、プロセスの改善や申請者への説明の明確化、不要な却下の削減につなげられます。却下率という定量的な重要業績評価指標（KPI）に、定性的な背景を加える情報です。重要な理由申請が却下される根本原因を把握できます。却下率を下げるために、オンボーディングプロセスの改善点を特定するうえで欠かせません。入手先「申請を却下」イベントの発生時に記録されます。ケースまたは申請の記録にある項目として保存されることが一般的です。例 PEPとの一致制裁リストへの該当文書確認に不合格ネガティブ報道
	手戻りかどうか IsRework	同じ案件内で、アクティビティが2回目以降に実行されたことを示すフラグです。
説明 IsReworkは、顧客の申請案件内でアクティビティが繰り返されたことを示す、計算された真偽値属性です。たとえば、1件の申請で「リスク評価を実施」が複数回行われた場合、2回目以降は手戻りとして記録されます。この属性は、プロセスの非効率な部分やループ、不要な繰り返しを特定するうえで重要です。「リスク評価の手戻りと効率」ダッシュボードと「リスク評価の手戻り率」KPIの分析に役立ちます。手戻りを分析すると、品質、情報の明確さ、意思決定に関する問題を見つけられます。こうした問題は、無駄な作業やサイクルタイムの長期化につながります。重要な理由繰り返されたアクティビティをフラグで示し、手戻りのループを分析できます。品質の向上とサイクルタイムの短縮に役立ちます。入手先データ変換時に、各案件内のアクティビティの順序を分析し、最初の実行以降に繰り返されたアクティビティにフラグを付けて算出します。例 truefalse
	申請チャネル ApplicationChannel	顧客が申請を提出した経路です。「オンラインポータル」「支店窓口」「モバイルアプリ」などがあります。
説明申請チャネルは、顧客申請がどの経路から提出されたかを示します。チャネルによってデータの充足度や品質、顧客層が異なり、その後のプロセスに影響する場合があります。この属性は、「チャネル別申請処理件数」ダッシュボードに欠かせません。チャネルごとの申請件数、サイクルタイム、結果を分析すると、効率の高いチャネルや改善が必要なチャネルを特定できます。この分析は、リソース配分やチャネルへの投資に関する戦略的な判断に役立ちます。重要な理由申請経路ごとのパフォーマンスと効率を分析し、テクノロジーや顧客体験に関する戦略的な判断に役立てられます。入手先通常、プロセスの開始時に取得され、申請記録の属性として保存されます。例オンラインポータルモバイルアプリ支店窓口リレーションシップマネージャー
	自動処理かどうか IsAutomated	アクティビティがシステム（true）によって実行されたか、人（false）によって実行されたかを示すフラグです。
説明この真偽値属性は、システムによる自動処理とユーザーによる手作業を区別します。たとえば、「自動スクリーニングを実施」は自動処理、「アナリストによる確認を開始」は手作業として記録されます。この区別は、自動化分析に欠かせません。自動化がプロセス効率に与える影響を測定し、今後自動化できる手作業を特定するとともに、人とシステムの処理の関係を把握できます。また、システムの処理時間と手作業の対応時間を明確に分けて分析できます。重要な理由システムによる処理と人による作業を区別することで、自動化の効果を測定し、新たな自動化の候補を特定できます。入手先通常は、アクティビティ名またはイベントに関連付けられたユーザーID（ユーザーが「system」アカウントの場合など）を基に判定します。例 truefalse
	顧客ID CustomerId	オンボーディング対象の顧客を一意に識別するIDです。
説明顧客IDは、顧客プロフィールを一意に識別するIDです。顧客申請IDとは異なり、同じ顧客が複数回申請する場合があります。この属性を使って、オンボーディングプロセスを顧客マスターレコードに関連付けます。分析では、顧客IDを使って同じ顧客からの再申請を追跡できます。また、CRMやマスターデータシステムにある顧客属性をプロセスデータに追加することもできます。これにより、1回のオンボーディングにとどまらず、顧客の全体的な経過を把握できます。重要な理由オンボーディングケースを特定の顧客に関連付け、再申請の分析や顧客マスターデータの追加を可能にします。入手先申請またはケースの記録にある重要な項目で、顧客マスターデータとの関連付けに使います。例 CUST-98765CUST-98766CUST-98767
	顧客の国 CustomerCountry	顧客の居住国または設立国です。
説明この属性は、顧客の所在地を示します。KYCプロセスでは、国がリスク評価や規制要件に大きく影響します。法域によって規則が異なり、プロセスの流れや所要時間が変わることがあります。国別にプロセスを分析すると、地域間のパフォーマンスを比較し、地域特有のボトルネックを特定して、現地の規制へのコンプライアンスを確認できます。プロセス分析に地理的な視点を加えることで、業務上の重要な違いを明らかにできます。重要な理由地理的な視点からプロセスを分析し、地域ごとのパフォーマンス、リスク、コンプライアンス要件の違いを特定できます。入手先顧客プロフィールまたは申請フォームにある標準的な項目です。例 USAGBRSGPDEU
	顧客種別 CustomerType	「個人」「法人」「信託」など、顧客の分類です。
説明顧客種別は、オンボーディングの対象となる顧客を分類します。顧客の種類によって、オンボーディングの要件、リスク、規制上の義務が異なることがあります。たとえば、法人のオンボーディングは、個人の場合より複雑になるのが一般的です。この属性は、特に「KYC顧客種別別パフォーマンス」ダッシュボードで、顧客を分類して分析するために使います。顧客セグメントごとに、プロセスの効率、サイクルタイム、却下率を比較できます。組織はこの分析をもとに、顧客種別に応じてオンボーディングの進め方を調整、改善できます。重要な理由顧客セグメントごとのパフォーマンスを比較し、顧客種別に応じたオンボーディングプロセスの調整や改善に役立ちます。入手先通常、ソースシステムの顧客記録または申請記録に保存される基本的な属性です。例個人法人非営利団体信託

必須推奨任意

KYC顧客オンボーディングのアクティビティ

プロセスを正確に把握するために、イベントログに記録する主要なステップとマイルストーンです。

8 推奨 6 任意

	アクティビティ	説明
	アナリストによる確認を開始	コンプライアンス担当のアナリストが、顧客の申請に関する一致候補の手動調査を開始します。一致候補の詳細を顧客情報と照合し、関連性を判断します。
重要な理由手動でのコンプライアンス確認が始まったことを示します。この工程はボトルネックになりやすく、「一致候補を検出」からこのアクティビティまでの時間を測ると、待ち行列による遅れが分かります。また、確認にかかる時間からアナリストの処理効率を把握できます。入手先アナリストが確認待ちのケースを「引き受ける」か、開いた時点から推定できます。ケースのステータスが「確認中」に変わったときや、特定のユーザーに割り当てられたときに、監査証跡へ明示的に記録される場合もあります。記録ケースのステータスが「レビュー中」に変わったこと、またはケースがアナリストに割り当てられたことから推定します。イベントタイプ inferred
	スクリーニング依頼の作成	Refinitiv World-Checkシステムで、顧客申請に対する新しいスクリーニングケースが正式に作成されます。上流システムからのAPI呼び出し、または手動入力によって開始され、リスク情報の確認が始まったことを示します。
重要な理由これは、スクリーニングのサブプロセスが正式に開始されたことを示します。「申請提出」からこのアクティビティまでの時間から、業務システムとコンプライアンス部門の間で引き継ぎに遅れが生じているかを把握できます。入手先 World-Checkのケース管理ログまたは監査証跡に記録されます。対象のケースIDまたはエンティティIDについて、作成イベントとそのタイムスタンプを使用します。記録システムで新しいスクリーニングケースが作成されると、自動的に記録されます。イベントタイプ explicit
	スクリーニング完了：一致あり	スクリーニングケースが「一致あり」の結果で正式に終了した状態です。確認済みのリスクが特定されたことを示します。この判断を受けて、追加のデューデリジェンスや申請の却下など、後続の別プロセスが開始されます。
重要な理由これは、スクリーニングプロセスで主に想定される問題発生時の終点です。該当ケースを分析すると、リスクの傾向やスクリーニング管理策の有効性を把握できます。入手先最終的なケースのステータスが「一致あり」「リスクを特定」「終了：一致」などに変わったことから推定します。最終ステータスの変更時刻を使用します。記録一致が確認されたことを示す最終的なケースステータスのタイムスタンプから判定します。イベントタイプ inferred
	スクリーニング完了：該当なし	スクリーニングケースが「該当なし」の結果で正式に終了した状態です。一致が確認されなかったことを意味します。この判断は申請元のシステムに通知され、オンボーディングを続行できます。
重要な理由スクリーニングプロセスが問題なく完了したことを示す、標準的な経路の終点です。標準的な低リスク申請のサイクルタイムを測る際の重要な終点となります。入手先最終的なケースのステータスが「該当なし」「完了」「終了：一致なし」などに変わったことから推定します。最終ステータスの変更時刻を使用します。記録該当なしを示す最終的なケースステータスのタイムスタンプから判定します。イベントタイプ inferred
	一致を確認	アナリストが、一致候補はスクリーニング対象の顧客本人であると確認し、潜在的なリスクを特定します。通常、この重要な節目を受けて、追加のデューデリジェンスや申請の却下が行われます。
重要な理由これはリスク低減に直結する重要な結果であり、プロセスの大きな転換点です。顧客の申請に対する最終判断に直接影響し、コンプライアンス報告や分析にも欠かせません。入手先アナリストが特定の一致候補を「一致」または「一致を確認」と判定する、明示的なユーザー操作です。このイベントはケースの監査証跡に記録されます。記録アナリストがシステム上で一致を正式に確認した時点で記録されます。イベントタイプ explicit
	口座を有効化	基幹システムで顧客の口座が作成され、有効化されます。これによりオンボーディングが完了し、口座を利用できる状態になります。申請の最終承認後に行われます。
重要な理由プロセスの最後に行われ、顧客への価値提供につながる工程です。申請の提出から口座の有効化までの時間は、業務効率と顧客満足度を測る重要な指標です。入手先このイベントはWorld-Checkには記録されません。銀行の基幹システムまたは顧客口座システムに記録され、顧客申請IDを使って関連付ける必要があります。記録口座の有効化時に、基幹口座システムで記録されるイベントです。イベントタイプ explicit
	申請を却下	顧客の申請が正式に却下された状態です。World-Checkで「一致あり」と判定された場合や、その他のリスク要因がある場合などに発生します。オンボーディングプロセスにおける最終的な否決結果です。
重要な理由これは、プロセスが不成立となる主な終点です。却下イベント、特にその理由や直前のアクティビティを分析することは、プロセスの改善や不要な却下の削減に欠かせません。入手先この最終的な業務判断は、World-Check自体ではなく、上流のCRMまたは基幹申請システムに記録されます。そのシステムからデータを取得する必要があります。記録申請元のシステムで記録されるイベントです。却下理由コードが併せて記録される場合もあります。イベントタイプ explicit
	申請提出	顧客が申請を提出した時点で、KYCオンボーディングが始まります。このイベントは通常、CRMまたは基幹申請システムに記録され、その後Refinitiv World-Checkでのスクリーニングが開始されます。
重要な理由これは、顧客のオンボーディング全体における主な開始イベントです。この時点から完了までの時間を分析すると、オンボーディング全体のサイクルタイムが分かります。顧客体験やSLAの遵守状況を測るうえで重要な指標です。入手先このイベントはWorld-Checkに標準で記録されるものではありません。CRMや顧客口座管理プラットフォームなどの上流システムから取得し、顧客申請IDを使って関連付ける必要があります。記録申請の初回提出時に、元の申請システムに記録されるイベント。イベントタイプ explicit
	ケースを確認のためにエスカレーション	一次担当のアナリストが、複雑なケースやリスクの高いケースを、最終判断のために上級アナリストまたはマネージャーへエスカレーションします。コンプライアンスチーム内で重要な引き継ぎが発生する工程です。
重要な理由エスカレーションはボトルネックを生み、サイクルタイムを延ばすことがあります。発生頻度や理由を分析すると、経験の浅いアナリストに必要な研修や、確認方針の曖昧さを特定できます。入手先ケースのワークフローまたは監査証跡に、明示的な操作として記録されます。ケースの担当ユーザーが変更されたことから推定することもできます。特に、より高い権限を持つユーザーへの変更が手がかりになります。記録ケース内の専用の「エスカレーション」ボタン、またはワークフロー操作を通じて記録されます。イベントタイプ explicit
	一致候補を検出	自動スクリーニングで1件以上の一致候補が見つかり、アナリストによる手動確認が必要になった状態です。このイベントを境に、ケースは自動処理の状態から手動調査の待ち行列に移ります。
重要な理由このアクティビティは、プロセスの重要な分岐点です。一致候補があるケースは、より長く複雑な経路をたどります。この状況を追跡することで、確認チームの人員計画やボトルネック分析に役立ちます。入手先 World-Checkのケース管理モジュールで、ケースのステータスが「確認が必要」「一致候補」などに変わったことから推定します。記録手動確認が必要になったことを示すケースのステータス変更から判定します。イベントタイプ inferred
	申請を承認	KYCスクリーニングと必要なその他の確認が完了し、顧客の申請が正式に承認された状態です。通常、World-Checkから「該当なし」の結果を受け取った後、ソースシステムでこのイベントが発生します。
重要な理由オンボーディングが正常に完了したことを示します。申請の提出からこの時点までの時間を追跡すると、新規顧客の獲得にかかる全体の期間を把握できます。入手先このイベントはWorld-Check固有のものではありません。最終的な業務判断を行う上流のCRMまたは基幹申請システムから取得する必要があります。記録最終承認時に、申請元のシステムで記録されるイベントです。イベントタイプ explicit
	自動スクリーニングの実施	World-Checkが、顧客情報をリスク情報データベースと自動照合します。このアクティビティはシステムによって実行され、候補となる一致や該当なしなど、初期結果が出力されます。
重要な理由このアクティビティは、スクリーニングプロセスで最初に付加価値を生む工程です。ここに至るまでの遅れは、システムやデータの準備状況に問題があることを示します。また、結果によって、その後に必要となる手作業の量が決まります。入手先このイベントは、ケースの監査証跡に明示的に記録される場合があります。または、ケースの初期スクリーニング結果が利用可能になった時刻から推定できます。記録自動データベーススキャンの完了時に生成されるシステムログの記録です。イベントタイプ explicit
	誤検知を確認	アナリストが、一致候補はスクリーニング対象の顧客本人ではないと判断します。一致候補は却下され、そのアラートに関するスクリーニングが完了します。
重要な理由これは、確認プロセスでよく見られる結果です。誤検知の処理にかかる時間を把握すると、アナリストの処理効率や自動スクリーニングの判定精度を測定できます。入手先アナリストが特定の一致候補を「誤検知」または「一致なし」と判定する、明示的なユーザー操作です。通常、この操作はケース履歴に記録されます。記録アナリストがシステム上で一致候補を正式に却下した時点で記録されます。イベントタイプ explicit
	追加情報を依頼	アナリストが、一致候補の判断に追加情報が必要だと判断し、事業部門に情報を依頼します。情報が提供されるまで、ケースは保留状態になります。
重要な理由このアクティビティが頻繁に発生する場合、スクリーニングに提供される初期データの品質に問題がある可能性があります。外部チームからの情報提供を待つため、大幅な遅れが生じ、サイクルタイムが長くなる主な要因となります。入手先ケースのメモや監査ログに記録されたユーザー操作から確認できます。または、ケースのステータスが「情報待ち」や「追加情報依頼」に変わったことから推定できます。記録アナリストが、追加情報が必要であることを示す機能を使った時点で記録されます。イベントタイプ explicit

推奨任意

データ抽出ガイド

Refinitiv World-Checkからデータを取得する方法

ステップ

World-Check Oneにログイン：認証情報を使ってRefinitiv World-Check Oneポータルにアクセスします。
案件管理に移動：スクリーニング案件が保存、管理されている「案件管理」セクションを開きます。
案件レポートのエクスポートを準備：「案件管理」内のレポートまたはエクスポート機能に移動します。「案件をエクスポート」や「案件レポート」と表示されている場合があります。
案件レポートを設定：エクスポートに含める列を選択します。ケースID（CustomerApplication）、作成日、解決日、案件ステータス（「問題なし」「一致あり」など）、リスクレベルに対応するフィールドを選択してください。
案件管理データをエクスポート：通常は直近3～6か月を対象に、日付範囲を指定します。必要に応じて、ユーザーグループや案件種別などで絞り込みます。データをCSVファイルとしてエクスポートし、case_report.csvという名前で保存します。
監査証跡のエクスポートを準備：World-Check Oneの監査証跡または監査ログのレポートセクションに移動します。ここには各案件の詳細なイベント履歴が含まれています。
監査証跡を設定してエクスポート：ケースID、イベント名または説明、イベントのタイムスタンプ、操作を実行したユーザーなど、関連する列をすべて選択します。案件レポートと同じ日付範囲のデータをエクスポートし、audit_trail.csvとして保存します。
外部プロセスのステップを取得：Application Submitted、Application Approved、Account Activated、Application Rejectedなど、World-Check以外で発生するアクティビティのデータを取得します。通常、このデータはCRMまたは基幹銀行システムから取得します。CustomerApplication IDと関連するタイムスタンプを含めてエクスポートします。
データを結合して変換：エクスポートしたCSVファイル（case_report.csv、audit_trail.csv、外部システムのデータ）を、データ準備ツールまたはスクリプトに読み込みます。
監査イベントをアクティビティに対応付け：audit_trail.csvを処理します。監査ログの生のイベント説明を、標準化されたActivityNameの値に対応付けます。たとえば、「案件をアナリストに割り当て」という監査ログの記録を「アナリストによる確認を開始」に変換します。
案件ステータスの変更をアクティビティに対応付け：case_report.csvを処理し、ステータスの変更に基づいてアクティビティを作成します。案件の解決日と最終ステータスを使って、「スクリーニング完了：問題なし」または「スクリーニング完了：一致あり」のイベントを作成します。
最終イベントログを作成：各ソースファイルから処理したデータを1つのCSVファイルにまとめます。最終ファイルに必須列のCustomerApplication、ActivityName、EventTimeと、推奨属性が含まれていることを確認します。このファイルをプロセスマイニングツールにアップロードします。

設定

レポートの種類：少なくとも2種類のレポートを作成します。案件管理の概要レポートと、詳細な監査証跡レポートです。
日付範囲：初回の分析では、完了済み案件と進行中案件を十分に含めるため、少なくとも3～6か月の範囲を選択します。エクスポートするすべてのファイルで日付範囲を統一してください。
エクスポート形式：処理しやすいCSV（カンマ区切り値）を選択します。
主要列（案件レポート）：案件データのエクスポートに、ケースID、作成タイムスタンプ、解決タイムスタンプ、最終ステータス、割り当てられたアナリスト、リスクレベルが含まれていることを確認します。
主要列（監査証跡レポート）：監査ログのエクスポートに、ケースID、イベントの説明、イベントのタイムスタンプ、ユーザーIDが含まれていることを確認します。
前提条件：案件管理データと監査ログデータの閲覧およびエクスポートが許可されたユーザー権限で、World-Check Oneポータルにアクセスできる必要があります。標準的なアナリストの役割より高い権限が必要な場合があります。

クエリの例 sql

/*
This is a configuration and mapping guide, not an executable script. 
The process relies on manually exporting two reports from World-Check One and combining them with data from an upstream system (e.g., CRM).
*/

-- Step 1: Export 'Case Management Report' as case_report.csv
-- Step 2: Export 'Audit Trail Report' as audit_trail.csv
-- Step 3: Export relevant events from CRM/core system as source_system_events.csv

-- Step 4: Combine and map the files using a script or ETL tool to create the final event log.

-- Mapping logic for final_event_log.csv

-- Part A: Data from source_system_events.csv
SELECT
  ApplicationID AS CustomerApplication,
  'Application Submitted' AS ActivityName,
  SubmissionTimestamp AS EventTime,
  NULL AS EventEndTime,
  OriginatorID AS ReviewerId,
  OriginatingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Submission'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Approved' AS ActivityName,
  ApprovalTimestamp AS EventTime,
  NULL AS EventEndTime,
  ApproverID AS ReviewerId,
  ApprovingDept AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Approval'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Account Activated' AS ActivityName,
  ActivationTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Operations' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Activation'

UNION ALL

SELECT
  ApplicationID AS CustomerApplication,
  'Application Rejected' AS ActivityName,
  RejectionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ReviewerID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskRating AS RiskLevel,
  SlaDate AS SlaTargetDate
FROM source_system_events.csv
WHERE EventType = 'Rejection'

-- Part B: Data from World-Check audit_trail.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Request Created' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Created%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Automated Screening Performed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Automated Screening Completed%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Potential Match Identified' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  'SYSTEM' AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Potential Match Found%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Analyst Review Started' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Assigned%' OR EventDescription LIKE '%Review Started%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Additional Information Requested' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Information Requested%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Case Escalated for Review' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Case Escalated%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'False Positive Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Dismissed as False Positive%'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'True Match Confirmed' AS ActivityName,
  EventTimestamp AS EventTime,
  NULL AS EventEndTime,
  UserID AS ReviewerId,
  'Compliance' AS DepartmentName,
  NULL AS RiskLevel,
  NULL AS SlaTargetDate
FROM audit_trail.csv
WHERE EventDescription LIKE '%Match Confirmed as True%'

-- Part C: Data from World-Check case_report.csv
UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Clear' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Clear'

UNION ALL

SELECT
  CaseID AS CustomerApplication,
  'Screening Completed - Match Found' AS ActivityName,
  ResolutionTimestamp AS EventTime,
  NULL AS EventEndTime,
  ResolverID AS ReviewerId,
  'Compliance' AS DepartmentName,
  RiskLevel AS RiskLevel,
  NULL AS SlaTargetDate
FROM case_report.csv
WHERE FinalStatus = 'Match Found'

ステップ

前提条件とセットアップ：Python 3.6以降をインストールし、requestsとpandasライブラリを用意します。Refinitivの担当者または開発者ポータルからWorld-Check OneのAPIキーとAPIシークレットを取得し、安全に保管します。
認証処理を作成：Pythonスクリプトに、World-Check Oneの認証エンドポイントへPOSTリクエストを送信する関数を作成します。APIキーとシークレットを使って、一時的なベアラートークンを取得します。このトークンは以降のAPI呼び出しに必要です。
ソースシステムのデータを特定：プロセスはWorld-Checkの外部で開始し、終了します。初期申請データを保存しているCRMや基幹銀行システムなどのソースシステムを特定します。そこからApplication Submitted、Application Approved、Account Activated、Application Rejectedなどのイベントを抽出します。データベースクエリまたは別のAPIで取得できます。
World-Checkの案件を取得：認証済みトークンを使い、World-Check One APIの/casesエンドポイントにGETリクエストを送信します。クエリパラメーターで、作成日や変更日などに基づく日付範囲を指定して案件を絞り込みます。
APIのページネーションを処理：World-Check APIの応答はページ分割されています。スクリプトで応答内のページネーション情報を確認し、指定した日付範囲の案件をすべて取得するまで各ページを順に処理します。
案件の詳細と履歴を取得：取得した各案件IDについて、/cases/{case_system_id}や/cases/{case_system_id}/audit-trailなどのエンドポイントにGETリクエストを送信します。これらのエンドポイントから、案件に関連する詳細なステータス変更、解決内容、ユーザー操作を取得できます。
生のデータをアクティビティに対応付け：この変換工程は重要です。各案件のAPI応答データ（案件の詳細、監査証跡）を順に処理するロジックを作成します。特定のステータス変更、結果コード、監査イベントを、必要な業務アクティビティに対応付けます。たとえば、案件の作成イベントをScreening Request Createdに、結果が「False Positive」と判定された記録をFalse Positive Confirmedに変換します。
データソースを結合：World-Checkから抽出したデータを、手順3で取得したソースシステムのデータと結合します。共通キーとしてCustomerApplication IDを使い、顧客ごとのエンドツーエンドのイベントログを作成します。
データを構成して補完：対応付けたすべてのイベントを1つのレコードリストにまとめます。各レコードに必須属性（CustomerApplication、ActivityName、EventTime）と推奨属性が設定されていることを確認します。可能であれば、同じ案件の次のイベントのタイムスタンプを使うなどしてEventEndTimeを算出します。
CSVにエクスポート：最終的なイベントレコードのリストをpandasのDataFrameに変換します。列を必要な形式に並べ替えてCSVファイルにエクスポートします。ProcessMindで使用できるよう、UTF-8エンコーディングで保存してください。

設定

API認証情報：World-Check OneスクリーニングAPIの有効なAPIキーとAPIシークレットが必要です。案件データと監査データを読み取るために必要な権限を付与してください。
APIベースURL：World-Check API環境に対応する正しいベースURLをスクリプトに設定します。例：https://api.world-check.com/v2/。
日付範囲：抽出期間を指定するstart_dateとend_dateのパラメーターをスクリプトに実装します。初回の分析では3～6か月の範囲を推奨します。継続的に監視する場合は、前日や前週など、より短い期間を対象にスクリプトを定期実行します。
ソースシステムへの接続：スクリーニング以外のイベントを取得するには、上流・下流システム（CRM、基幹銀行システムなど）の接続情報が必要です。データベース接続文字列、または別のAPIエンドポイントと認証情報を用意します。
ページネーションの処理：案件一覧のAPI呼び出し時に、limitと呼ばれるページサイズを指定します。通常は50～100が効率的です。すべてのページを正しく取得できるよう、処理ロジックを実装してください。

クエリの例 python

import requests
import pandas as pd
from datetime import datetime, timedelta

class=class="hl-string">"hl-comment"># --- Configuration and Placeholders ---
WC_API_KEY = class="hl-string">'[Your World-Check API Key]'
WC_API_SECRET = class="hl-string">'[Your World-Check API Secret]'
WC_API_BASE_URL = class="hl-string">'https://api.world-check.com/v2' class=class="hl-string">"hl-comment"># Use correct URL for your environment

class=class="hl-string">"hl-comment"># Date range for the extraction
START_DATE = (datetime.now() - timedelta(days=90)).strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
END_DATE = datetime.now().strftime(class="hl-string">'%Y-%m-%dT%H:%M:%SZ')

class=class="hl-string">"hl-comment"># --- MOCK FUNCTIONS (Replace with actual data source connections) ---

def get_source_system_events(application_ids):
    class="hl-string">"""Simulates fetching pre- and post-screening events from a CRM or core system."""
    print(fclass="hl-string">'Fetching source system events for {len(application_ids)} applications...')
    mock_events = []
    for i, app_id in enumerate(application_ids):
        class=class="hl-string">"hl-comment"># Simulate initial application events
        mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Submitted', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i+5)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Sales'})
        class=class="hl-string">"hl-comment"># Simulate final outcome events
        if i % 3 == 0:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Approved', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Onboarding'})
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Account Activated', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i-1)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Operations'})
        else:
            mock_events.append({class="hl-string">'CustomerApplication': app_id, class="hl-string">'ActivityName': class="hl-string">'Application Rejected', class="hl-string">'EventTime': (datetime.now() - timedelta(days=i)).isoformat() + class="hl-string">'Z', class="hl-string">'DepartmentName': class="hl-string">'Compliance'})
    return mock_events

def get_worldcheck_cases(token):
    class="hl-string">"""Simulates fetching a list of cases from the World-Check API."""
    print(class="hl-string">'Fetching World-Check cases...')
    class=class="hl-string">"hl-comment"># In a real implementation, you would call GET /cases with date filters and handle pagination
    mock_case_list = [
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-001', class="hl-string">'name': class="hl-string">'John Doe', class="hl-string">'caseSystemId': class="hl-string">'WC-001', class="hl-string">'customReference': class="hl-string">'APP-1001', class="hl-string">'creationDate': class="hl-string">'2023-10-01T10:00:00Z', class="hl-string">'riskLevel': class="hl-string">'Medium'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-002', class="hl-string">'name': class="hl-string">'Jane Smith', class="hl-string">'caseSystemId': class="hl-string">'WC-002', class="hl-string">'customReference': class="hl-string">'APP-1002', class="hl-string">'creationDate': class="hl-string">'2023-10-02T11:30:00Z', class="hl-string">'riskLevel': class="hl-string">'Low'},
        {class="hl-string">'caseId': class="hl-string">'0a1b2c3d-case-003', class="hl-string">'name': class="hl-string">'Peter Jones', class="hl-string">'caseSystemId': class="hl-string">'WC-003', class="hl-string">'customReference': class="hl-string">'APP-1003', class="hl-string">'creationDate': class="hl-string">'2023-10-03T09:05:00Z', class="hl-string">'riskLevel': class="hl-string">'High'}
    ]
    return mock_case_list

def get_worldcheck_case_details(case_system_id, token):
    class="hl-string">"""Simulates fetching the audit trail and results for a single World-Check case."""
    print(fclass="hl-string">'Fetching details for case {case_system_id}...')
    class=class="hl-string">"hl-comment"># This mock data simulates a complex history for one case to generate multiple activities
    if case_system_id == class="hl-string">'WC-001':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:05:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-01T10:06:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T14:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T15:30:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as False Positive', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T11:00:00Z', class="hl-string">'event': class="hl-string">'ESCALATED', class="hl-string">'details': class="hl-string">'Case escalated to senior analyst', class="hl-string">'user': class="hl-string">'analyst1'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T09:00:00Z', class="hl-string">'event': class="hl-string">'INFORMATION_REQUESTED', class="hl-string">'details': class="hl-string">'Additional documents requested', class="hl-string">'user': class="hl-string">'senior_analyst'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-05T16:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'senior_analyst'}
            ]
        }
    elif case_system_id == class="hl-string">'WC-003':
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:10:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-03T09:11:00Z', class="hl-string">'event': class="hl-string">'MATCH_FOUND', class="hl-string">'details': class="hl-string">'Potential match identified', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T10:00:00Z', class="hl-string">'event': class="hl-string">'REVIEW_STARTED', class="hl-string">'details': class="hl-string">'Case assigned', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T11:25:00Z', class="hl-string">'event': class="hl-string">'MATCH_RESOLVED', class="hl-string">'details': class="hl-string">'Match resolved as True Positive', class="hl-string">'user': class="hl-string">'analyst2'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-04T12:00:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed with matches', class="hl-string">'user': class="hl-string">'analyst2'}
            ]
        }
    else: class=class="hl-string">"hl-comment"># Simple class="hl-string">'Clear' case
        return {
            class="hl-string">'auditTrail': [
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:35:00Z', class="hl-string">'event': class="hl-string">'AUTOMATED_SCREENING', class="hl-string">'details': class="hl-string">'Screening performed', class="hl-string">'user': class="hl-string">'SYSTEM'},
                {class="hl-string">'timestamp': class="hl-string">'2023-10-02T11:36:00Z', class="hl-string">'event': class="hl-string">'CASE_CLOSED', class="hl-string">'details': class="hl-string">'Case closed as Clear', class="hl-string">'user': class="hl-string">'SYSTEM'}
            ]
        }

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def main():
    class="hl-string">"""Main function to run the extraction process."""
    class=class="hl-string">"hl-comment"># 1. Authenticate (real implementation)
    class=class="hl-string">"hl-comment"># token = get_wc_auth_token()
    token = class="hl-string">'mock_token' class=class="hl-string">"hl-comment"># Using a mock token for this example

    class=class="hl-string">"hl-comment"># 2. Get list of cases from World-Check
    cases = get_worldcheck_cases(token)
    if not cases:
        print(class="hl-string">'No cases found for the specified period.')
        return

    event_log = []

    class=class="hl-string">"hl-comment"># 3. Process each case from World-Check
    for case in cases:
        app_id = case.get(class="hl-string">'customReference')
        if not app_id:
            continue

        class=class="hl-string">"hl-comment"># Add class="hl-string">'Screening Request Created' event
        event_log.append({
            class="hl-string">'CustomerApplication': app_id,
            class="hl-string">'ActivityName': class="hl-string">'Screening Request Created',
            class="hl-string">'EventTime': case[class="hl-string">'creationDate'],
            class="hl-string">'ReviewerId': class="hl-string">'SYSTEM',
            class="hl-string">'DepartmentName': class="hl-string">'Compliance',
            class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
        })

        details = get_worldcheck_case_details(case[class="hl-string">'caseSystemId'], token)
        for event in details.get(class="hl-string">'auditTrail', []):
            activity = None
            user = event.get(class="hl-string">'user', class="hl-string">'SYSTEM')
            department = class="hl-string">'Compliance' if user != class="hl-string">'SYSTEM' else class="hl-string">'System'
            
            class=class="hl-string">"hl-comment"># 4. Map audit trail events to activities
            if event[class="hl-string">'event'] == class="hl-string">'AUTOMATED_SCREENING':
                activity = class="hl-string">'Automated Screening Performed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_FOUND':
                activity = class="hl-string">'Potential Match Identified'
            elif event[class="hl-string">'event'] == class="hl-string">'REVIEW_STARTED':
                activity = class="hl-string">'Analyst Review Started'
            elif event[class="hl-string">'event'] == class="hl-string">'INFORMATION_REQUESTED':
                activity = class="hl-string">'Additional Information Requested'
            elif event[class="hl-string">'event'] == class="hl-string">'ESCALATED':
                activity = class="hl-string">'Case Escalated for Review'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'False Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'False Positive Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'MATCH_RESOLVED' and class="hl-string">'True Positive' in event[class="hl-string">'details']:
                activity = class="hl-string">'True Match Confirmed'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'Clear' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Clear'
            elif event[class="hl-string">'event'] == class="hl-string">'CASE_CLOSED' and class="hl-string">'matches' in event[class="hl-string">'details']:
                activity = class="hl-string">'Screening Completed - Match Found'

            if activity:
                event_log.append({
                    class="hl-string">'CustomerApplication': app_id,
                    class="hl-string">'ActivityName': activity,
                    class="hl-string">'EventTime': event[class="hl-string">'timestamp'],
                    class="hl-string">'ReviewerId': user,
                    class="hl-string">'DepartmentName': department,
                    class="hl-string">'RiskLevel': case.get(class="hl-string">'riskLevel')
                })
    
    class=class="hl-string">"hl-comment"># 5. Get events from source system
    application_ids = [case[class="hl-string">'customReference'] for case in cases if case.get(class="hl-string">'customReference')]
    source_events = get_source_system_events(application_ids)
    event_log.extend(source_events)

    class=class="hl-string">"hl-comment"># 6. Create and format DataFrame
    if not event_log:
        print(class="hl-string">'No events were generated.')
        return

    df = pd.DataFrame(event_log)
    df[class="hl-string">'EventTime'] = pd.to_datetime(df[class="hl-string">'EventTime'])
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'])

    class=class="hl-string">"hl-comment"># Add EventEndTime by shifting the EventTime of the next event
    df[class="hl-string">'EventEndTime'] = df.groupby(class="hl-string">'CustomerApplication')[class="hl-string">'EventTime'].shift(-1)
    
    class=class="hl-string">"hl-comment"># Add placeholder for non-extractable attribute
    df[class="hl-string">'SlaTargetDate'] = pd.NaT

    class=class="hl-string">"hl-comment"># 7. Finalize and Export
    output_columns = [
        class="hl-string">'CustomerApplication',
        class="hl-string">'ActivityName',
        class="hl-string">'EventTime',
        class="hl-string">'EventEndTime',
        class="hl-string">'ReviewerId',
        class="hl-string">'DepartmentName',
        class="hl-string">'RiskLevel',
        class="hl-string">'SlaTargetDate'
    ]
    class=class="hl-string">"hl-comment"># Ensure all required columns exist, even if empty
    for col in output_columns:
        if col not in df.columns:
            df[col] = None
    
    df = df[output_columns]

    output_filename = class="hl-string">'event_log_worldcheck.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%fZ')
    print(fclass="hl-string">'Successfully exported event log to {output_filename}')

if __name__ == class="hl-string">'__main__':
    main()

準備はできましたか？

このデータテンプレートを使って、KYC顧客オンボーディングのプロセスマイニングを始めましょう。ガイドに沿って分析を進めることで、価値あるインサイトを見つけ、業務の大幅な改善につなげられます。

改善ガイドに戻る

テンプレートをダウンロード

KYC顧客オンボーディングを今すぐ最適化し、コンプライアンスを強化

顧客のオンボーディングをスムーズに進め、所要時間をわずか24時間に短縮しましょう。

無料トライアルを開始

クレジットカードは不要です。14日間無料でお試しいただけます。

KYC顧客オンボーディングのデータテンプレート

KYC顧客オンボーディングのデータテンプレート

KYC顧客オンボーディングの属性

KYC顧客オンボーディングのアクティビティ

データ抽出ガイド

Refinitiv World-Check Oneの案件データと監査ログのエクスポート

ステップ

設定

クエリの例 sql

World-Check OneスクリーニングAPIを使ったPythonスクリプト

ステップ

設定

クエリの例 python

準備はできましたか？

KYC顧客オンボーディングを今すぐ最適化し、コンプライアンスを強化