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

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

Refinitiv World-Check

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

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

このテンプレートでは、KYC顧客オンボーディングプロセスの分析に必要なデータを収集する手順を説明します。取得すべき重要な属性、追跡すべき主要なアクティビティ、ソースシステムから情報を抽出する方法をまとめています。このリソースを使って、効果的なプロセス分析と改善に必要なデータを揃えてください。

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

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

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

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

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

3 必須 5 推奨 11 任意

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

必須推奨任意

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

正確なプロセス発見のために、イベントログに記録すべき主要なプロセス手順とマイルストーンです。

8 推奨 6 任意

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

推奨任意

抽出ガイド

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

ステップ

World-Check Oneにログイン：認証情報を使ってRefinitiv World-Check Oneポータルにアクセスします。
Case Managementへ移動：すべてのスクリーニング案件が保存・管理されているCase Managementセクションを開きます。
案件レポートのエクスポートを準備：Case Management内のレポートまたはエクスポート機能へ移動します。「Export Cases」または「Case Report」と表示されている場合があります。
案件レポートを設定：エクスポートに含める列を選択します。Case ID（CustomerApplication）、作成日、解決日、案件ステータス（Clear、Match Foundなど）、リスクレベルに対応するフィールドを必ず選択してください。
Case Managementデータをエクスポート：通常は直近3～6か月のアクティビティを対象に、日付範囲を指定します。必要に応じて、ユーザーグループや案件タイプなどのフィルターを適用します。データをCSVファイルとしてエクスポートし、case_report.csvという名前で保存します。
監査証跡のエクスポートを準備：World-Check Oneの監査証跡または監査ログのレポートセクションへ移動します。ここには各案件の詳細なイベント履歴が含まれています。
監査証跡を設定してエクスポート：Case 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 Assigned to Analyst」という監査ログのエントリを「Analyst Review Started」に変換します。
案件ステータスの変更をアクティビティにマッピング：case_report.csvを処理し、ステータス変更に基づいてアクティビティを生成します。案件の解決日と最終ステータスを使って、「Screening Completed - Clear」または「Screening Completed - Match Found」イベントを作成します。
最終イベントログを作成：各ソースファイルから処理したデータを1つのCSVファイルに統合します。最終ファイルには、必須列であるCustomerApplication、ActivityName、EventTimeと、推奨属性が含まれていることを確認します。このファイルをプロセスマイニングツールへのアップロード用に保存します。

設定

レポートの種類：少なくとも2つの個別レポートを作成する必要があります。Case Managementのサマリーレポートと、詳細なAudit Trailレポートです。
日付範囲：初回分析では、完了済み案件と進行中の案件を十分に含めるため、少なくとも3～6か月の日付範囲を選択します。すべてのエクスポートファイルで日付範囲を統一してください。
エクスポート形式：処理しやすいCSV（Comma Separated Values）を選択します。
主要列（案件レポート）：案件のエクスポートに、Case ID、作成タイムスタンプ、解決タイムスタンプ、最終ステータス、担当アナリスト、リスクレベルが含まれていることを確認します。
主要列（監査証跡レポート）：監査ログのエクスポートに、Case ID、イベント説明、イベントタイムスタンプ、ユーザーIDが含まれていることを確認します。
前提条件：Case Managementと監査ログのデータを表示・エクスポートできるユーザー権限を持つWorld-Check Oneポータルへのアクセスが必要です。通常のアナリスト権限より高い権限が必要になる場合があります。

a サンプルクエリ 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'

ステップ

前提条件とセットアップ：requestsおよびpandasライブラリとともにPython 3.6以降がインストールされていることを確認します。Refinitivの担当者または開発者ポータルからWorld-Check One API KeyとAPI Secretを取得し、安全に保管します。
認証ロジックを開発：Pythonスクリプトで、World-Check One認証エンドポイントへPOSTリクエストを送信する関数を作成します。API KeyとSecretを使って、後続の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に変換します。列を必要な形式に並べ替え、DataFrameをCSVファイルにエクスポートします。ProcessMindで互換性を確保するため、UTF-8エンコーディングで保存してください。

設定

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

a サンプルクエリ 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の案件および監査ログのエクスポート

ステップ

設定

a サンプルクエリ sql

World-Check One Screening APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

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

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

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

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

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

抽出ガイド

Refinitiv World-Check Oneの案件および監査ログのエクスポート

ステップ

設定

a サンプルクエリ sql

World-Check One Screening APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

始める準備はできていますか？

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

プライバシーを大切にしています