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

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

Refinitiv World-Check

KYC顧客オンボーディングの属性 (20) KYC顧客オンボーディングのActivity (14) 抽出ガイド (2)

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

このテンプレートは、KYC顧客オンボーディングプロセスを分析するために不可欠なデータの収集をガイドします。捕捉すべき重要な属性、追跡すべき主要なActivityを概説し、ソースシステムからこの情報を抽出する方法に関するガイダンスを提供します。このリソースを活用して、効果的なプロセス分析と改善に必要なすべてのデータを確実に取得してください。

収集を推奨する項目
追跡すべき主要アクティビティ
抽出の手引き

イベントログについて初めての方へ：プロセスマイニングのイベントログ作成方法.

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

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

これらは、包括的なKYC顧客オンボーディング分析のためにイベントログに含めることを推奨するデータフィールドです。

3 必須 5 推奨 12 任意

	名前	説明
	アクティビティ名 ActivityName	KYCオンボーディングプロセス内で発生した特定のビジネスイベントまたはタスクの名称です。
説明 Activity Nameは、顧客オンボーディングプロセスにおける単一のステップまたはイベントを記述します。例えば、「申請提出済み」、「アナリスト審査開始」、「スクリーニング完了 - クリア」などです。これらのActivityはプロセスマップのノードを形成し、エンドツーエンドのワークフローの詳細な内訳を提供します。 Activityの分析はプロセスマイニングの核です。異なるActivityの順序と頻度を追跡することで、アナリストは実際のプロセスフローを発見し、共通のパスを特定し、標準手順からの逸脱を検出し、遅延や手戻りの原因となる特定のステップを特定できます。この属性は、プロセスマップの構築とActivityレベルのメトリクスの計算に不可欠です。その重要性この属性は、プロセスの個々のステップを定義します。これは、プロセスフローの発見と視覚化、およびボトルネックの特定に不可欠です。取得元この情報は通常、イベントログまたは監査証跡テーブルにあり、多くの場合、ケース管理エンティティのステータス変更に関連付けられています。例潜在的な合致を特定アナリストレビュー開始誤検知確定済み申請承認済み
	イベント日時 EventTime	特定のアクティビティまたはイベントが発生した時刻を示すタイムスタンプ。
説明イベントタイムは、アクティビティが記録された正確な日時を提供します。このタイムスタンプはプロセスの時系列的な基盤であり、イベントを正しく順序付けてケース履歴を再構築することを可能にします。この属性は、プロセスマイニング (katakana) におけるすべての時間ベースの分析にとって重要です。アクティビティ間の期間（サイクルタイムと待機時間）を計算し、全体的なケース期間を測定し、時間の経過に伴うプロセスパフォーマンスを分析し、サービスレベル契約（SLA）への遵守を確認するために使用されます。正確なタイムスタンプがなければ、プロセスパフォーマンスを理解し、時間的なボトルネックを特定することは不可能です。その重要性各Activityのtimestampは、すべての期間ベースのメトリクス計算、プロセスシーケンスの発見、およびボトルネック分析のために不可欠です。取得元これは、あらゆるイベントログまたは監査証跡テーブルの標準フィールドであり、多くの場合、「Timestamp」、「EventDate」、または「CreationDate」と名付けられています。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:22:15Z
	顧客申請 CustomerApplication	単一顧客のオンボーディング申請の一意の識別子で、主要なケース識別子として機能します。
説明顧客申請は、単一顧客のオンボーディングプロセスに関連するすべてのイベントとActivityをグループ化する中心的なケース識別子です。これにより、各顧客が最初の提出から最終決定までのKYCプロセス全体を完全に時系列で追跡できます。プロセスマイニング分析において、この属性は各申請のエンドツーエンドのプロセスを再構築するための基本です。プロセスフローの視覚化、総サイクルタイムの計算、およびバリアントの特定を可能にします。この識別子でグループ化されたケースを分析することにより、組織は申請がたどる可能性のある異なるパスを理解し、ボトルネックを特定し、様々なオンボーディングプロセスの効率性を比較することができます。その重要性これは、関連するすべてのActivityを接続する不可欠なケース識別子であり、エンドツーエンドの顧客オンボーディングプロセスを分析することを可能にします。取得元この識別子は、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	特定のアクティビティ／イベントが完了したタイムスタンプ。
説明 Event End TimeはActivityの完了を示します。多くのイベントは瞬時（StartTimeがEndTimeと同じ）としてモデル化できますが、「アナリスト審査開始」や「アナリスト審査完了」のように測定可能な期間を持つActivityもあります。開始時刻と終了時刻の両方を持つことで、処理時間を正確に測定できます。プロセス分析において、終了時刻を持つことは、待機時間を含むサイクルタイムとは異なり、Activityの正確な処理時間を計算するために不可欠です。これにより、ケースが実際に作業されている時間とキューでアイドル状態にある時間を区別するのに役立ちます。これはリソース最適化と効率分析の鍵となります。その重要性アクティビティ処理時間の正確な計算を可能にし、アクティブな作業時間とアイドル待機時間を分離することで、より正確なパフォーマンス分析に役立ちます。取得元期間を持つアクティビティの場合、これはイベントログまたは監査証跡テーブルの「CompletionDate」や「EndDate」のような別のフィールドに保存される場合があります。例 2023-10-26T10:45:00Z2023-10-26T12:00:00Z2023-10-27T15:00:00Z
	リスクレベル RiskLevel	顧客申請の算出されたリスク分類で、低、中、高などがあります。
説明リスクレベルはKYCプロセスにおいて重要な情報であり、必要なデューデリジェンスのレベルを決定します。これは通常、顧客タイプ、地域、ビジネスの性質などの要因に基づいて決定されます。この分類は、申請がたどるプロセスパスに大きく影響する可能性があります。プロセス分析では、リスクレベル別にケースをセグメント化することが不可欠です。これにより、サイクルタイムやプロセスフローのばらつきを説明するのに役立ちます。例えば、高リスクの申請はより多くのステップを必要とし、時間がかかる場合があります。この属性は、「申請却下率と理由」および「バックグラウンドチェック開始サイクルタイム」ダッシュボードにとって重要であり、リスクが結果と効率性にどのように影響するかを理解するために役立ちます。その重要性リスクレベルごとにプロセスをセグメント化することは、特定のケースに時間がかかったり、異なるパスをたどったりする理由を理解し、却下率を分析するために不可欠です。取得元これは、顧客申請またはケースレコード上のコアデータポイントです。Refinitiv World-Checkのケース管理モジュールを参照してください。例低中高
	審査担当者ID ReviewerId	Activityを実行したユーザー、アナリスト、または自動化エージェントの識別子です。
説明審査担当者ID（またはユーザー）は、KYCプロセスで特定のタスクを実行した人物を示します。これはコンプライアンスアナリスト、オンボーディングスペシャリスト、または自動化されたActivityのシステムアカウントである可能性があります。この情報を追跡することで、ワークロードの配分と個人のパフォーマンスに関する可視性が得られます。この属性は、リソースベースの分析に不可欠です。ユーザーやチーム間のパフォーマンスの違いを理解し、トレーニングの必要性を特定し、ワークロードのバランス調整を最適化するのに役立ちます。また、引き継ぎ、ソーシャルネットワーク、コンプライアンスリソースの利用状況を分析するための重要な要素でもあります。その重要性ワークロードの分散、ユーザーパフォーマンス、部門間の引き継ぎの分析を可能にし、リソース最適化に不可欠です。取得元通常、イベントログや監査証跡に「UserID」「PerformedBy」「Owner」などの名前で記録されています。例 analyst_jdoesystem_auto_screenermanager_bsmith
	部署 DepartmentName	Activityの実行を担当する部門または機能チームです。
説明この属性は、ユーザーが所属する「オンボーディング」、「コンプライアンス」、「品質保証」などのビジネスユニットまたはチームを指定します。これにより、個々のユーザーよりも高い組織レベルでの分析が可能になります。部門別の分析は、部門間のボトルネックを特定し、引き継ぎ時間を測定するために不可欠です。異なるチーム間でどのように作業が流れ、これらの移行でどこに遅延が発生するかを視覚化するのに役立ちます。この視点は、部門横断的なコラボレーションを合理化し、プロセス全体の効率を向上させる上で非常に貴重です。その重要性部門別のプロセスパフォーマンス分析を可能にし、異なるチーム間の引き継ぎにおける遅延を特定するために不可欠です。取得元この情報は、システム内のユーザープロファイルまたは関連する人事システムに保存される場合があります。ユーザーIDを使用してイベントデータと結合する必要がある場合があります。例オンボーディングチームコンプライアンスレビュー経営層
	SLA違反 SlaBreached	オンボーディングケースがSLA目標日後に完了したかどうかを示すブール値のフラグです。
説明この属性は、ケースがサービスレベルアグリーメントに違反しているかどうかを示す計算されたフラグです。最終完了Activity（例：「申請承認済み」または「申請却下済み」）のtimestampを、そのケースの「SlaTargetDate」と比較することによって決定されます。このフラグは、「SLA遵守と違反分析」ダッシュボードおよび「SLA遵守率」KPIの基礎となります。違反したすべてのケースを迅速にフィルタリングできるようにすることで、分析を簡素化します。違反したケースのプロセス特性を分析することにより、組織は遅延の根本原因を特定し、改善の取り組みを効果的に集中させることができます。その重要性サービスレベル契約（SLA）への遵守を直接測定し、遅延したケースの容易なフィルタリングと根本原因分析を可能にします。取得元これは、データ変換中に、ケースの最終ActivityのtimestampをSlaTargetDateフィールドと比較することによって計算されます。例 truefalse
	アクティビティ処理時間 ActivityProcessingTime	アクティビティに実作業として費やした時間。
説明このメトリクスは、Activityが開始から終了までにかかった実際の時間を計算します。EventEndTimeとEventTimeの差として計算されます。これにより、タスクの「タッチタイム」または実際の作業時間が測定されます。この計算された属性は、パフォーマンス分析に不可欠であり、「平均文書審査サイクルタイム」や「平均コンプライアンス審査サイクルタイム」を含む多くのKPIで使用されます。タスクが積極的に処理されている時間とキューで待機している時間を区別するのに役立ちます。これは、真の処理非効率性を特定し、キャパシティプランニングを行う上で基本的です。その重要性 Activityの実際の作業時間を測定し、待機時間とは別に、どの特定のタスクが完了までに最も時間がかかっているかを特定するのに役立ちます。取得元これは、データ変換中にActivityの終了timestampから開始timestampを引くことによって計算されます（例：EndTime - StartTime）。例 PT1H30MP2DT4H15MPT25M
	ソースシステム SourceSystem	イベントデータが抽出されたシステムで、この場合はRefinitiv World-Checkです。
説明この属性は、プロセスデータの発生源を識別します。単一ソースからの抽出では一定の値であるかもしれませんが、複数のシステム（CRMやWorld-Checkなど）からのデータを組み合わせて全体的なプロセスビューを作成する際には重要になります。分析において、これはデータガバナンス、トラブルシューティング、およびデータのコンテキスト理解に役立ちます。例えば、コアスクリーニングシステムにログされたActivityは、周辺システムからのActivityとは異なるプロパティや詳細レベルを持つ場合があります。これにより、データリネージが明確で監査可能であることが保証されます。その重要性データの発生源を特定します。これは、データガバナンス、検証、および複数のソースからのデータを統合する際に非常に重要です。取得元これは、データセットにラベルを付けるために、データ抽出、変換、ロード（ETL）プロセス中にしばしば追加される静的な値です。例 Refinitiv World-CheckWorld-Check One
	最終データ更新 LastDataUpdate	このイベントのデータがソースシステムから最後に更新または抽出されたtimestampです。
説明この属性はデータの鮮度を示します。Refinitiv World-Checkからの最終データ取得日時を記録します。これは、プロセスマイニングのダッシュボードや分析の適時性を理解するために重要です。分析目的では、これによりユーザーはリアルタイムに近いデータを見ているのか、特定の時点のスナップショットを見ているのかを知ることができます。これはデータガバナンスと、提供されるインサイトの最新性に関するユーザーの期待を管理するために不可欠です。その重要性データの鮮度に関する重要なコンテキストを提供し、ユーザーがプロセス分析の最新性を理解できるようにします。取得元このtimestampは、データ抽出（ETL）プロセス中に生成され、追加されます。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	却下理由 RejectionReason	顧客申請が却下された際に提供される特定の理由です。
説明申請が却下された際、その決定理由が「却下理由」として記録されます。理由には「制裁対象との一致」「書類不備」「高リスクプロファイル」などが挙げられます。これは、着信申請の品質とスクリーニングプロセスの有効性に関する貴重で構造化されたフィードバックを提供します。この属性は、「申請却下率と理由」ダッシュボードの主要な推進要因となります。これらの理由を分析することで、却下の根本原因を特定し、プロセス改善、申請者とのより明確なコミュニケーション、そして不必要な却下の潜在的な削減につながります。これにより、定量的な却下率KPIに定性的なコンテキストが提供されます。その重要性申請却下の根本原因を提供します。これは、オンボーディングプロセスにおける改善領域を特定し、却下率を低減するために不可欠です。取得元これは、「申請却下」イベントが発生した際に、ケースまたは申請記録のフィールドとして記録されます。例 PEP合致制裁リストにヒットドキュメント検証失敗不利な報道
	合致ID MatchId	World-Checkスクリーニング中に検出された潜在的な合致の一意の識別子です。
説明自動スクリーニングプロセスが制裁リスト、PEPリスト、またはネガティブメディアに対して潜在的な一致を検出すると、特定の発見を追跡するためにマッチIDが生成されることがよくあります。このIDは、申請ケースとアラートをトリガーしたWorld-Checkデータベース内の特定の記録をリンクします。この属性は、詳細なコンプライアンス分析に役立ちます。アナリストは、一致の性質を調査し、特定のアラートの解決（例：誤検知または真の一致の確認）を追跡し、どのような種類のアラートが最も一般的であるか、または解決に最も時間がかかるかを理解できます。これにより、「潜在的な一致が特定された」アクティビティに、より深いレベルの詳細が提供されます。その重要性特定のスクリーニング結果への詳細なリンクを提供し、合致解決時間とアラートの種類の詳細な分析を可能にします。取得元このIDはWorld-Checkスクリーニングエンジンによって生成され、潜在的な合致が検出された際に申請ケースに記録されます。例 WC-MATCH-459021WC-MATCH-459022WC-MATCH-459023
	手戻り IsRework	あるアクティビティが、同一ケース内で2回目以降に実行されているかどうかを示すフラグです。
説明 IsReworkは、同一の顧客申請ケース内でActivityが繰り返された場合にそれを識別する算出されたboolean属性です。例えば、「リスク評価実施済み」が1つの申請に対して複数回発生した場合、それ以降の発生は手戻りとしてマークされます。この属性は、プロセスの非効率性、ループ、不要な繰り返しを特定するために重要です。「リスク評価の手戻りと効率性」ダッシュボードおよび「リスク評価の手戻り率」KPIを直接サポートします。手戻りの分析は、品質、情報明確性、または意思決定に関する問題、すなわち無駄な労力とサイクルタイムの延長につながる問題を発見するのに役立ちます。その重要性繰り返し行われるActivityを特定することでプロセスの非効率性を浮き彫りにし、手戻りループの分析を通じて品質向上とサイクルタイム短縮を実現します。取得元これは、データ変換中に、各ケース内のActivityのシーケンスを分析し、Activityの初期以外の発生にフラグを立てることによって計算されます。例 truefalse
	申請チャネル ApplicationChannel	オンラインポータル、支店、モバイルアプリなど、顧客申請が提出されたチャネルです。
説明申請チャネルは、顧客申請の提出元を示します。異なるチャネルは、データの完全性、品質、顧客層のレベルが異なる可能性があり、これがダウンストリームプロセスに影響を与えることがあります。この属性は、「チャネル別申請処理量」ダッシュボードにとって不可欠です。異なるチャネルからの申請量、サイクルタイム、および結果を分析することで、組織は最も効率的なチャネルとプロセス改善が必要なチャネルを特定できます。この分析は、リソース配分とチャネル投資に関する戦略的決定をサポートします。その重要性異なる申請チャネルのパフォーマンスと効率を分析し、テクノロジーと顧客体験に関する戦略的決定に役立てます。取得元この情報は通常、プロセスの開始時に捕捉され、申請レコードの属性として保存されます。例オンラインポータルモバイルアプリ支店リレーションシップマネージャー
	自動化 IsAutomated	アクティビティがシステム（真）によって実行されたか、人間（偽）によって実行されたかを示すフラグです。
説明このboolean属性は、自動化されたシステムタスクとユーザーによって実行される手動Activityを区別します。例えば、「自動スクリーニング実行済み」は自動としてマークされ、「アナリスト審査開始」は手動となります。この区別は、自動化分析にとって非常に重要です。これにより、プロセス効率に対する自動化の影響を測定し、将来の自動化候補となる手動タスクを特定し、人間とシステムアクター間の相互作用を理解するのに役立ちます。システム処理時間と手動処理時間を明確に分離できます。その重要性システムアクティビティと人間によるアクティビティを区別し、自動化の影響を測定し、新たな自動化の機会を特定するための鍵となります。取得元これは通常、Activity名またはイベントに関連付けられたユーザーID（例：ユーザーが「システム」アカウントの場合）に基づいて導き出されます。例 truefalse
	顧客ID CustomerId	オンボーディングされる顧客エンティティのための一意の識別子です。
説明顧客IDは、顧客プロファイルの一意の識別子です。これは顧客申請IDとは異なり、一人の顧客が時間の経過とともに複数の申請を提出する可能性があるためです。この属性は、オンボーディングプロセスを顧客マスターレコードにリンクします。分析では、顧客IDにより同一顧客からの再申請を追跡でき、CRMやマスターデータシステムからの他の顧客属性でプロセスデータを補強するために使用できます。これにより、単一のオンボーディングインスタンスを超えた顧客ジャーニーのより全体的な視点が可能になります。その重要性オンボーディングケースを特定の顧客に紐付け、再申請の分析や顧客マスターデータとの連携を可能にします。取得元これは、申請またはケース記録上の重要なフィールドとなり、顧客マスターデータと連携します。例 CUST-98765CUST-98766CUST-98767
	顧客タイプ CustomerType	個人、法人、信託など、顧客の分類です。
説明顧客タイプは、オンボーディングされるエンティティを分類します。異なる種類の顧客は、多くの場合、異なるオンボーディング要件、リスクプロファイル、および規制上の義務を持っています。例えば、法人をオンボーディングする方が、個人をオンボーディングするよりも一般的に複雑です。この属性は、セグメンテーション分析、特に「KYC顧客タイプ別パフォーマンス」ダッシュボードで使用されます。これにより、異なる顧客セグメント間でのプロセス効率、サイクルタイム、および却下率の比較が可能になります。これは、組織が特定の顧客タイプに合わせてオンボーディング体験を調整し、最適化するのに役立ちます。その重要性異なる顧客セグメント間のパフォーマンス比較を可能にし、各タイプに合わせてオンボーディングプロセスを調整・最適化するのに役立ちます。取得元これは、ソースシステム内の顧客または申請レコードに保存される基本的な属性です。例個人法人非営利団体信頼
	顧客国 CustomerCountry	顧客の居住国または設立国。
説明この属性は顧客の地理的位置を示します。国は、KYCプロセスにおけるリスク評価および規制要件の重要な要素です。異なる管轄区域には異なる規則があり、プロセスフローと期間に影響を与える可能性があります。国別にプロセスを分析することで、組織は異なる地域間でのパフォーマンスを比較し、地域固有のボトルネックを特定し、現地規制へのコンプライアンスを確保できます。これにより、プロセス分析に地理的側面が提供され、重要な運用上の違いが明らかになることがあります。その重要性プロセスの地理的分析を可能にし、パフォーマンス、リスク、コンプライアンス要件における地域差を特定するのに役立ちます。取得元これは、顧客プロファイルまたは申請フォームの標準フィールドです。例米国GBRSGPDEU

必須推奨任意

KYC顧客オンボーディングのActivity

これらは、正確なプロセスディスカバリーのために`イベントログ`に記録すべき主要なプロセス`ステップ`と`マイルストーン`です。

8 推奨 6 任意

	アクティビティ	説明
	アカウント有効化済み	顧客のアカウントはコアシステムで作成・有効化され、オンボーディングプロセスが完了します。これは最終的な申請承認に続き、アカウントが使用可能な状態になります。
その重要性これはプロセスにおける最終的で価値を提供するステップです。申請提出からアカウント有効化までの期間は、運用効率と顧客満足度の主要な指標となります。取得元このイベントはWorld-Checkでは捕捉されません。コアバンキングシステムまたは顧客アカウントシステムに記録され、顧客申請IDによって関連付けられる必要があります。取得口座有効化時に基幹口座システムにログ記録されたイベントです。イベントタイプ explicit
	アナリストレビュー開始	コンプライアンスアナリストが、顧客申請の潜在的な一致候補について手動調査を開始します。これには、顧客情報と潜在的な一致の詳細を照合し、関連性を判断する作業が含まれます。
その重要性これは、一般的なボトルネックである手動コンプライアンス審査の開始を示します。「潜在的な合致を特定」からこのActivityまでの時間を測定することで、キューイング遅延が明らかになり、審査の期間はアナリストの効率性を示します。取得元これは、アナリストが審査キューからケースを「引き受ける」または開いたときに推測できます。システムは、ケースステータスが「審査中」に変更された場合、または特定のユーザーに割り当てられた場合に、このイベントを監査証跡に明示的にログする可能性があります。取得ケースステータスが「審査中」に変更された場合、またはアナリストにケースが割り当てられた場合から推測されます。イベントタイプ inferred
	スクリーニングリクエスト作成済み	Refinitiv World-Checkシステム内で、顧客申請のために新しいスクリーニングケースが正式に作成されます。これはアップストリームシステムからのAPI呼び出しまたは手動入力によってトリガーされ、リスクインテリジェンスチェックの開始を示します。
その重要性これはスクリーニングサブプロセスの正式な開始を示します。申請提出とこのActivityの間の時間は、基幹業務システムとコンプライアンス機能間の引き継ぎの遅延を明らかにします。取得元 World-Checkのケース管理ログまたは監査証跡に記録されます。特定のケースまたはエンティティIDの作成イベントとそのtimestampが使用されます。取得システムで新しいスクリーニングケースが作成されたときに自動的にログされます。イベントタイプ explicit
	スクリーニング完了 - クリア	スクリーニングケースは「クリア」の結果で正式にクローズされ、真の合致は検出されなかったことを意味します。この決定は元のシステムに伝えられ、オンボーディングプロセスを続行できます。
その重要性このActivityは、スクリーニングプロセスの成功した「ハッピーパス」での完了を表します。これは、標準的な低リスク申請のサイクルタイムを測定するための主要な終点として機能します。取得元最終的なケースステータスが「クリア」「完了」「一致なしでクローズ」に変更された場合から推測されます。この最終ステータス変更のtimestampが使用されます。取得クリアな結果を示す最終ケースステータスのタイムスタンプから派生します。イベントタイプ inferred
	スクリーニング完了 - 一致検出	スクリーニングケースは「一致検出」の結果で正式にクローズされ、確認されたリスクが特定されたことを示します。この決定は、強化されたデューデリジェンスや却下など、異なるダウンストリームプロセスをトリガーします。
その重要性これは、スクリーニングプロセスにおける主要な「アンハッピーパス」の終点です。これらのケースを分析することで、リスクプロファイルとスクリーニングコントロールの有効性を理解するのに役立ちます。取得元最終的なケースステータスが「一致検出」「リスク特定」「ポジティブクローズ」に変更された場合から推測されます。この最終ステータス変更のtimestampが使用されます。取得確認された一致を示す最終ケースステータスのタイムスタンプから派生します。イベントタイプ inferred
	応募が提出されました	このActivityは、顧客が申請を提出したときにKYCオンボーディングプロセスの開始を示します。このイベントは通常、CRMまたはコアアプリケーションシステムで捕捉され、その後Refinitiv World-Checkでのスクリーニングプロセスをトリガーします。
その重要性これは、エンドツーエンドの顧客オンボーディングプロセスにおける主要な開始イベントです。この時点から完了までの時間を分析することで、顧客体験とSLA遵守を測定するために不可欠な全体のオンボーディングサイクルタイムが提供されます。取得元このイベントはWorld-Check固有のものではありません。CRMや顧客アカウント管理プラットフォームのような上流システムから取得し、顧客申請IDによって関連付けられる必要があります。取得初期提出時にソースアプリケーションシステムにログ記録されたイベントです。イベントタイプ explicit
	本人確認一致	アナリストが、潜在的な一致が実際にスクリーニング対象の顧客であることを確認し、潜在的なリスクを特定します。これは、通常、さらなるデューデリジェンスや申請却下を引き起こす重要なマイルストーンです。
その重要性これは主要なリスク軽減の結果であり、プロセスにおける極めて重要な瞬間です。顧客申請に関する最終決定に直接影響を与え、コンプライアンス報告と分析にとって重要です。取得元これは、アナリストが特定の合致を「真の合致」または「確認済み合致」として処理する明示的なユーザーアクションです。このイベントはケース監査証跡にログされます。取得アナリストがシステム内で合致を正式に確認したときにログされます。イベントタイプ explicit
	申請却下済み	顧客申請は正式に却下されます。これはWorld-Checkでの「一致検出」やその他のリスク要因の結果として行われることがよくあります。このイベントは、オンボーディングプロセスの最終的な負の結果です。
その重要性これは、プロセスの主要な失敗終点です。却下イベント、特にその理由と先行するActivityを分析することは、プロセス改善と不必要な却下の削減のために不可欠です。取得元この最終的なビジネス決定は、World-Check自体ではなく、上流のCRMまたはコアアプリケーションシステムに記録されます。データはそのシステムから取得する必要があります。取得ソースアプリケーションシステムにログ記録されたイベントで、多くの場合、対応する却下理由コードとともに記録されます。イベントタイプ explicit
	レビューのためにケースがエスカレート済み	初級アナリストが、複雑なケースや高リスクのケースを上級アナリストまたはマネージャーにエスカレートし、最終的な決定を仰ぎます。これはコンプライアンスチーム内での重要な引き継ぎポイントです。
その重要性エスカレーションはしばしばボトルネックを生み出し、サイクルタイムを増加させます。エスカレーションの頻度と理由を分析することで、初級アナリストのトレーニングニーズやレビューポリシーの不明確さを浮き彫りにすることができます。取得元ケースワークフローまたは監査証跡内の明示的なアクションとして記録されます。また、ケースに割り当てられたユーザー、特に高権限を持つユーザーへの変更から推測することもできます。取得ケース内の専用の「エスカレート」ボタンまたはワークフローアクションを介してログされます。イベントタイプ explicit
	潜在的な合致を特定	自動スクリーニングプロセスにより、アナリストによる手動審査を必要とする1つ以上の潜在的な合致が検出されました。このイベントにより、ケースは自動処理状態から手動調査キューに移行します。
その重要性このActivityはプロセスにおける重要な分岐点です。潜在的な合致があるケースは、より長く複雑なパスをたどり、これを追跡することで審査チームのリソース計画とボトルネック分析に役立ちます。取得元 World-Checkのケース管理モジュール内で、ケースステータスが「要審査」「潜在的な合致」または類似のステータスに変更された場合から推測されます。取得手動レビューが必要であることを示すケースステータスの変更から派生します。イベントタイプ inferred
	申請承認済み	KYCスクリーニングとその他の必要なチェックが成功した後、顧客申請が完全に承認されました。このイベントは通常、World-Checkからの「クリア」結果を受信した後、ソースシステムで発生します。
その重要性これは、オンボーディングプロセスの成功したビジネス結果を示します。提出からこの時点までの時間を追跡することで、新規顧客の完全な「time-to-yes」が明らかになります。取得元このイベントはWorld-Check固有のものではありません。最終的なビジネス決定を行う上流のCRMまたはコアアプリケーションシステムから取得する必要があります。取得最終承認時にソースアプリケーションシステムにログ記録されたイベントです。イベントタイプ explicit
	自動スクリーニング実施済み	World-Checkシステムは、顧客の詳細情報をリスクインテリジェンスデータベースと照合して自動的にスクリーニングします。これは、潜在的な合致やクリアなステータスなどの初期結果を生成する、システム主導のActivityです。
その重要性このActivityはスクリーニングプロセス内の最初の付加価値ステップです。この時点までの遅延はシステムまたはデータの準備状況の問題を示し、その結果はその後の手動作業量を決定します。取得元このイベントは、ケース監査証跡に明示的にログされるか、初期スクリーニング結果がケースで利用可能になったtimestampから推測される場合があります。取得自動データベーススキャンの完了時に生成されるシステムログエントリです。イベントタイプ explicit
	誤検知確定済み	アナリストは、潜在的な合致がスクリーニング対象の顧客とは同一ではないと結論付けます。合致は却下され、その特定のアラートに対するスクリーニングプロセスは解決されます。
その重要性これは審査プロセスの一般的な結果を表します。誤検知を処理するのにかかる時間を理解することは、アナリストの効率性と自動スクリーニングロジックの正確性を測定するのに役立ちます。取得元これは、アナリストが特定の合致を「誤検知」または「一致なし」として処理する明示的なユーザーアクションです。このアクションは通常、ケース履歴にログされます。取得アナリストがシステム内で潜在的な合致を正式に却下したときにログされます。イベントタイプ explicit
	追加情報の依頼	アナリストは、潜在的な合致を解決するためにより多くの情報が必要であると判断し、事業部門に情報を要求します。これにより、情報が提供されるまでケースは保留状態になります。
その重要性このアクティビティが頻繁に発生することは、スクリーニングのために提供された初期データの品質に問題があることを示します。これは外部チームに依存するため大幅な遅延を引き起こし、長いサイクルタイムの主な原因となります。取得元これは、ケースノートまたは監査ログに記録された明示的なユーザーアクションである可能性があります。あるいは、ケースステータスが「情報保留中」または「RFI」に変更されたことから推測することもできます。取得アナリストがケースに追加情報が必要であるとフラグを立てる機能を使用したときにログされます。イベントタイプ 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として保存してください。
外部プロセスステップのデータソース化: 申請提出済み、申請承認済み、アカウント有効化済み、申請却下済みなど、World-Check以外で発生するアクティビティのデータを取得してください。このデータは通常、CRMまたは基幹銀行システムから取得されます。このデータをCustomerApplication IDと関連するタイムスタンプとともにエクスポートしてください。
データの結合と変換: エクスポートされたCSVファイル（case_report.csv、audit_trail.csv、および外部システムデータ）をデータ準備ツールまたはスクリプトにロードしてください。
監査イベントのアクティビティへのマッピング: audit_trail.csvファイルを処理してください。監査ログの生イベント説明を、標準化されたActivityName値にマッピングしてください。例えば、「アナリストにケース割り当て」という監査ログエントリは「アナリストレビュー開始」となります。
ケースステータス変更のアクティビティへのマッピング: case_report.csvファイルを処理し、ステータス変更に基づいてアクティビティを生成してください。ケースの解決日と最終ステータスを使用して、「スクリーニング完了 - クリア」または「スクリーニング完了 - 一致検出」イベントを作成してください。
最終イベントログの作成: 異なるソースファイルから処理されたすべてのデータを単一のCSVファイルに統合してください。最終ファイルに、必須列：CustomerApplication、ActivityName、EventTime、および推奨される属性が含まれていることを確認してください。このファイルをプロセスマイニングツールへのアップロード用に保存してください。

設定

レポートの種類: 少なくとも2種類のレポートを生成する必要があります。ケース管理サマリーレポートと詳細な監査証跡レポートです。
期間: 初期分析のためには、完了済みおよび進行中のケースを十分に取得できるよう、少なくとも3～6か月の期間を選択してください。すべてのエクスポートファイルで期間の一貫性を確保してください。
エクスポート形式: 処理を容易にするため、CSV（カンマ区切り値）をエクスポート形式として選択してください。
主要な列（ケースレポート）: ケースのエクスポートには、ケースID、作成日時、解決日時、最終ステータス、担当アナリスト、リスクレベルを含めてください。
主要な列（監査証跡レポート）: 監査ログのエクスポートには、ケースID、イベント説明、イベント日時、ユーザーIDを含めてください。
前提条件: World-Check Oneポータルへのアクセスと、ケース管理および監査ログデータの閲覧・エクスポートを許可するユーザー権限が必要です。これには、標準的なアナリストの役割を超える上位の権限が必要となる場合があります。

a クエリ例 config

/*
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や基幹銀行プラットフォームなどのソースシステムを特定してください。このソースから申請提出済み、申請承認済み、アカウント有効化済み、申請却下済みといったイベントを抽出する必要があります。これはデータベースクエリまたは別の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応答データ（ケース詳細、監査証跡）を反復処理するロジックを記述してください。特定のステータス変更、結果コード、および監査イベントを、必要なビジネスアクティビティにマッピングしてください。例えば、ケース作成イベントはスクリーニングリクエスト作成済みとなり、False Positiveの解決結果は誤検知確定済みとなります。
データソースの結合: World-Checkから抽出されたデータと、ソースシステム（ステップ3から）からのデータをマージしてください。CustomerApplication IDを共通キーとして使用し、各顧客の完全なエンドツーエンドのイベントログを作成してください。
データの構造化とエンリッチ: マッピングされたすべてのイベントを単一のレコードリストにまとめます。各レコードについて、必須属性（CustomerApplication、ActivityName、EventTime）および推奨属性がすべて入力されていることを確認してください。可能であればEventEndTimeを計算します。おそらく、そのケースの次のイベントのタイムスタンプを使用します。
CSVへのエクスポート: イベントレコードの最終リストをpandas DataFrameに変換してください。列を必要な形式に並べ替え、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の間の値が効率的です。ロジックはすべてのページを適切に取得できるように処理する必要があります。

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顧客オンボーディングデータテンプレート

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

KYC顧客オンボーディングのActivity

抽出ガイド

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

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

今すぐ始めますか？

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

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

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

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

KYC顧客オンボーディングのActivity

抽出ガイド

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

ステップ

設定

a クエリ例 config

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

ステップ

設定

a クエリ例 python

お客様のプライバシーを大切にしています

今すぐ始めますか？

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