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

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

Pega KYC

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

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

このテンプレートは、KYC顧客オンボーディングプロセスの分析に必要なデータを収集するための明確な道筋を示します。イベントログに含める重要な属性と、追跡すべき主要なアクティビティを整理しています。さらに、データを効率的に抽出するための具体的な手順も確認できるため、プロセスマイニングをスムーズに始められます。

イベントログに推奨される属性
プロセス全体で追跡すべき主要なアクティビティ
データ抽出の具体的な手順

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

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

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

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

3 必須 7 推奨 11 任意

	名前	説明
	アクティビティ ActivityName	オンボーディングプロセス内で発生した特定のイベントまたはタスクの名称です。
説明この属性には、業務アクティビティまたはシステムイベントの名称が記録されます。たとえば、「申請提出済み」、「コンプライアンスレビュー開始」、「申請却下」などです。全体的な顧客オンボーディングプロセスにおける1つのステップを表します。アクティビティの分析は、プロセスマイニングの中心です。この属性を使ってプロセスマップを作成し、各ステップ間の流れを示します。イベントの順序や各アクティビティの発生頻度を確認し、特に多く発生するタスクや時間のかかるタスクを特定できます。重要な理由この属性によってプロセスマップの各ステップが定義され、プロセスの流れを可視化、分析、理解できます。入手先通常、Pegaの監査証跡（履歴テーブル）に記録されるか、ケースのステータス変更から導出できます。例初期スクリーニング完了コンプライアンスレビュー完了申請承認
	開始時刻 EventTime	アクティビティまたはイベントが開始された時点を示すタイムスタンプです。
説明この属性には、アクティビティが開始された正確な日付と時刻が記録されます。1つの顧客申請ケース内にあるすべてのイベントの時系列を示します。タイムスタンプは、パフォーマンスに関するプロセス分析の基礎です。アクティビティの所要時間、ステップ間の待ち時間、オンボーディングプロセス全体のサイクルタイムを計算するために使います。ボトルネックの特定、SLA遵守状況の測定、プロセス効率の把握に欠かせないデータです。重要な理由タイムスタンプによって、所要時間の計算、プロセスパフォーマンスの分析、遅延の特定に必要な時系列情報を確認できます。入手先 Pegaの監査証跡に標準的に含まれる項目で、各イベントの履歴テーブルではpxTimeCreatedとして記録されることが多いです。例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
	顧客申請 CustomerApplication	顧客オンボーディング申請ケースごとの一意の識別子です。
説明顧客申請は、1人の顧客のオンボーディングに関連するすべてのアクティビティとイベントをまとめる主要なケース識別子です。各申請は、提出から承認・口座有効化、または却下までの経路をたどります。プロセスマイニングでは、この属性が各申請のエンドツーエンドの経路を再構成するために欠かせません。申請ごとのイベントの全体的な順序を確認し、ステータスを追跡し、異なる経路を比較できます。IDに基づいてケースを分析すると、代表的なプロセスバリアント、ボトルネック、標準手順からの逸脱を特定できます。重要な理由このIDはプロセスマイニングの基盤です。個々のイベントをつなぎ合わせ、分析可能な一貫したエンドツーエンドのプロセスインスタンスにします。入手先通常、Pegaにおける主要なケースIDです。メインのケースタイプのワークオブジェクトでは、pzInsKeyまたは業務向けの同等項目として参照できることが多いです。例 APP-2023-00123APP-2023-00124APP-2023-00125
	SLA目標日 SlaTargetDate	顧客オンボーディングケースの完了予定日です。
説明この属性には、サービスレベル合意（SLA）で定められた申請の目標完了日が記録されます。SLAは、顧客タイプ、リスクレベル、商品などによって異なる場合があります。この日付は、「SLA遵守状況追跡」ダッシュボードと関連KPIに欠かせません。実際の完了日と比較する基準になります。SLA目標を達成できなかったケースを分析すると、構造的な遅延を特定し、サービス上の約束を守るための改善を優先できます。重要な理由期限内のパフォーマンスを測定する基準となり、顧客満足度と業務管理に重要な役割を果たします。入手先 PegaにはSLA管理のフレームワークが組み込まれています。この日付は通常、pySLAGoalなどのプロパティ、またはケースに定義したカスタムSLAプロパティに保存されます。例 2023-11-10T17:00:00Z2023-11-15T17:00:00Z
	ユーザー OperatorId	アクティビティを実行したユーザーの一意の識別子です。
説明この属性には、KYCプロセスで特定のタスクを完了した従業員またはシステムユーザーのIDが記録されます。たとえば、コンプライアンス担当者や自動スクリーニングボットなどです。自動ステップでは、システムまたはサービスアカウントのIDになる場合があります。ユーザー単位で分析すると、業務量の分布、個人のパフォーマンス、トレーニングの必要性を把握できます。また、標準外のプロセスフローに関与したユーザーやチームを特定し、プロセスの逸脱を調査することもできます。重要な理由プロセスアクティビティを特定の個人またはチームに関連付け、業務量の分析、パフォーマンス評価、コンプライアンスチェックを可能にします。入手先 Pegaの監査証跡に標準的に含まれる項目で、履歴テーブルでは通常pxUpdateOperatorまたは類似のプロパティに保存されます。例 j.doe@acmebank.comkyc_analyst_04system_auto_agent
	リスクレベル RiskLevel	顧客申請について算出されたリスクレベルです。
説明この属性は顧客に関連する評価済みのリスクを表し、通常は「低」、「中」、「高」に分類されます。リスクレベルは、顧客データとスクリーニング結果に基づき、自動スコアリングエンジンが判定することが多いです。リスクレベルはプロセスの分岐を左右する重要な要素です。高リスクの申請では、強化されたコンプライアンスレビューなど、追加のデューデリジェンスが必要になることが多く、サイクルタイムが長くなります。リスクレベル別にプロセスを分析すると、こうした違いの妥当性を確認し、過度な遅延を招くことなくリスク管理が機能しているかを評価できます。重要な理由リスクレベルによって必要なデューデリジェンスの水準が決まることが多いため、プロセス経路や所要時間の違いを説明できます。入手先通常、Pegaの意思決定ルールまたはスコアリングモデルによって入力される、ケース上の算出プロパティです。Pega KYCのドキュメントを確認してください。例低中高
	却下理由 RejectionReason	申請が却下された理由を示します。
説明申請の最終ステータスが「却下」の場合、この属性に具体的な理由が記録されます。たとえば、「バックグラウンドチェック不合格」、「書類不備」、「高リスクプロファイル」などです。この属性は、「申請却下分析」ダッシュボードの主要な分析軸です。却下されたケースを理由別に分類すると、オンボーディングプロセスで最も多い失敗点を特定できます。却下率の低減、顧客体験の向上、業務効率の改善に向けた対策を実施するために重要な情報です。重要な理由申請が失敗した理由を具体的に把握でき、成功率を高めるための的を絞ったプロセス改善につながります。入手先通常、「却下」ステータスへ移行した際にケースへ設定される特定のプロパティです。標準的な却下理由フィールドについては、Pega KYCのドキュメントを確認してください。例制裁対象者該当書類内容の不一致PEP該当情報不足
	申請ステータス ApplicationStatus	顧客申請の最終結果または現在のステータスです。
説明この属性は、プロセス終了時点の申請全体のステータスを示します。たとえば、「承認済み」、「却下」、「取り下げ」などです。進行中のケースでは、最後に確認されたステータスを示す場合もあります。これは結果分析における重要な切り口です。「申請却下分析」ダッシュボードでケースを分類し、特定の結果に至った理由を把握するために直接使います。異なるステータスに至るプロセスフローを分析すると、承認されたケースのベストプラクティスや、却下の根本原因を特定できます。重要な理由ケースの業務上の結果を定義し、成功した経路と成功しなかった経路を比較する分析を可能にします。入手先通常、Pegaのケースワークオブジェクトにおける最終ステータス（pyStatusWork）です。例承認済み却下コンプライアンス確認待ち顧客による取り下げ
	終了時刻 EndTime	アクティビティまたはイベントが完了した時点を示すタイムスタンプです。
説明この属性には、アクティビティが終了した正確な日付と時刻が記録されます。開始時刻と組み合わせて、個々のアクティビティの処理時間を計算します。終了時刻を個別に記録すると、パフォーマンスをより正確に分析できます。アクティブな処理時間（開始時刻から終了時刻まで）と待ち時間（あるアクティビティの終了時刻から次のアクティビティの開始時刻まで）を区別できます。真のボトルネックと待ち行列を見分けるために重要です。重要な理由アクティビティの処理時間を正確に計算できるため、詳細なパフォーマンス分析とボトルネックの特定に役立ちます。入手先 Pegaの監査証跡に記録されている場合があります。記録されていない場合は、後続イベントの開始時刻を現在のイベントの終了時刻として導出する必要があります。例 2023-10-26T10:15:00Z2023-10-26T18:05:20Z2023-10-27T11:00:00Z
	部門 WorkGroup	アクティビティを担当する部門または機能チームです。
説明この属性には、実行ユーザーが所属する組織単位またはチームが記録されます。たとえば、「スクリーニングチーム」、「コンプライアンス」、「オンボーディング業務」などです。部門別のプロセス分析は、「部門別業務量分布」ダッシュボードに欠かせません。異なるチーム間で業務がどのように移動するかを把握し、部門横断のボトルネックを特定し、オンボーディングプロセス全体のリソース配分を評価できます。引き継ぎの効率化と業務量の平準化にも役立ちます。重要な理由異なる事業部門間のプロセスフローとボトルネックを分析でき、リソース管理と組織の最適化を支援します。入手先通常、Pegaのユーザープロファイル（Operator IDレコード）に関連付けられ、イベントデータと結合できます。プロパティ名はpyWorkGroupの場合があります。例初期審査コンプライアンス審査口座有効化
	SLAステータス SlaStatus	ケースがSLA目標内に完了したかどうかを示します。
説明この属性は、実際の完了タイムスタンプと「SLA目標日」を比較し、完了したケースを「期限内」または「遅延」に分類します。「SLA遵守状況追跡」ダッシュボードと「SLA遵守率」KPIの中心となる指標です。サービスレベルの約束に対するパフォーマンスを一目で確認できます。遅延したケースの特徴を分析すると、遅延の根本原因を特定し、今後のSLA違反リスクを抑えられます。重要な理由約束した水準に対するパフォーマンスを直接測定でき、業務管理、コンプライアンス、顧客満足度に欠かせません。入手先ケースの最終アクティビティのタイムスタンプとSlaTargetDateフィールドを比較して導出します。完了時刻が目標日より後の場合、ステータスは「遅延」になります。例期限内遅延リスクあり
	ケースタイプ CaseType	KYCオンボーディングケースの具体的なタイプです。
説明この属性はオンボーディング申請を分類します。たとえば、「個人顧客」、「法人顧客」、「富裕層個人」などです。ケースタイプによって、異なるステップ、SLA、リスクプロファイルを持つ別々のプロセスバリエーションに従うことがあります。ケースタイプ別にプロセスを分析すると、パフォーマンスをより適切に比較できます。特定のオンボーディングタイプで遅延や却下が発生しやすいかを把握できます。異なる顧客の経路に合わせてプロセスを改善するために欠かせない分類です。重要な理由プロセスデータを異なるカテゴリーに分け、より正確で関連性の高いパフォーマンス分析を可能にします。入手先通常、Pegaにおけるケースインスタンスのクラス名、またはケースタイプを定義する専用プロパティです。例個人向けオンボーディング法人向けオンボーディング簡易デューデリジェンス
	サイクルタイム CycleTime	申請の提出から最終的な解決までに経過した合計時間です。
説明この算出指標は、最初のイベントから最後のイベントまで、顧客申請ごとのエンドツーエンドの所要時間を測定します。通常、対象ケースの最終アクティビティのタイムスタンプと最初のアクティビティのタイムスタンプの差として計算します。サイクルタイムは、プロセス効率と顧客体験を測る主要なKPIです。「オンボーディング全体のサイクルタイム分析」ダッシュボードで平均処理時間を監視し、長期化しているケースを特定し、プロセス改善施策の効果を時系列で追跡するために使います。重要な理由顧客の視点からオンボーディングプロセス全体の速度と効率を直接測定する重要なKPIです。入手先プロセスマイニングツールで、ケースIDごとの最大タイムスタンプと最小タイムスタンプの差として算出されます。例 5日4時間12日1時間2日8時間
	ソースシステム SourceSystem	データの取得元となったシステムを示します。
説明この属性には、イベントが記録されたソースアプリケーションが指定されます。このプロセスでは、値は一貫して「Pega KYC」になります。すべてのデータが1つのシステムから取得される場合は不要に見えるかもしれませんが、データガバナンスに欠かせない属性です。複数のシステムからデータを統合する場合には特に重要で、データの出所を明確にし、データ統合の問題を調査しやすくします。重要な理由データの出所に関する重要な情報を提供し、データガバナンスを支えます。また、複数のソースシステムにまたがる分析を可能にします。入手先通常、データ抽出・変換の工程でデータセットの出所を示す静的な値として追加されます。例 Pega KYCPega CLM
	最終データ更新 LastDataUpdate	最後にデータを更新または抽出した時点のタイムスタンプです。
説明この属性は、ソースシステムからデータが最後に抽出された時刻を示します。通常、1回のデータロードに含まれるすべてのレコードで同じ値になります。このタイムスタンプは、分析対象データの鮮度を把握するために重要です。プロセス分析がどの時点の情報を反映しているか、次回のデータ更新がいつ予定されているかを確認できます。運用監視用ダッシュボードに欠かせない情報です。重要な理由データの適時性を示し、分析が現在の状態を反映しているのか、過去の期間を対象としているのかを確認できるようにします。入手先通常、データ抽出・変換・ロード（ETL）の工程で生成され、データセットに付与されます。例 2023-11-01T02:00:00Z2023-11-02T02:00:00Z
	手戻りフラグ IsRework	アクティビティが手戻りループの一部かどうかを示すフラグです。
説明このブール型属性は、「書類レビュー」などの特定のアクティビティが同じケース内で複数回発生した場合にtrueになります。「追加情報の依頼」などのイベントによって発生することが多いです。手戻りを特定すると、プロセスの非効率や顧客が感じる負担を把握できます。「プロセスの手戻りとループ」ダッシュボードでは、この属性を使って手戻りの頻度と影響を定量化します。手戻りを減らすと、処理の迅速化、業務コストの削減、顧客体験の向上につながります。重要な理由プロセスの非効率、重複タスク、ループを明らかにし、プロセス改善の主な対象を特定できます。入手先同じケースID内でアクティビティ名が繰り返されているかを確認し、データ分析の段階で導出します。たとえば、「書類レビュー完了」が2回目に現れた場合です。例 truefalse
	書類ステータス DocumentStatus	顧客から提出された書類の現在のステータスです。
説明この属性は、KYCプロセスで必要な書類の状態を追跡します。値には、「顧客提出待ち」、「受領済み」、「検証済み」、「却下」などがあります。1つのケースの中で複数回変わる場合があります。「オンボーディング処理量とステータス」ダッシュボードや「書類検証速度」分析における重要な属性です。代表的なボトルネック領域の1つを詳細に確認できます。書類が各ステータスにとどまった時間を追跡すると、顧客による提出の遅れや社内レビューの遅延を特定できます。重要な理由書類処理のサブプロセスを可視化し、書類検証で発生しやすい遅延の特定と解消に役立ちます。入手先通常、メインケースに関連付けられたデータオブジェクトまたはページリストのプロパティとして、必要な各書類を追跡します。Pega KYCのドキュメントを確認してください。例アップロード待ち受領済み：審査待ち承認済み却下：追加情報が必要
	申請商品 OnboardedProduct	顧客が申請する金融商品です。
説明この属性には、顧客がオンボーディングを受ける商品またはサービスが指定されます。たとえば、「個人向け銀行口座」、「法人向け融資」、「投資サービス」などです。商品によって規制要件や複雑さが異なるため、オンボーディングプロセスにも影響します。商品別にプロセスを分析すると、特定の商品ラインでサイクルタイムが長い、または却下率が高いといった傾向を特定でき、商品ごとのプロセス改善に役立ちます。重要な理由商品ライン別にプロセスを分析し、パフォーマンスの違いと改善機会を明らかにします。入手先通常、申請プロセスの開始時に選択されるケース上のプロパティです。例普通預金口座ウェルスマネジメントビジネス信用枠
	自動実行フラグ IsAutomated	アクティビティがシステムによって実行されたか、人が実行したかを示すフラグです。
説明このブール型属性は、スクリーニングエンジンやシステムルールなどの自動エージェントがアクティビティを実行した場合はtrue、人が実行した場合はfalseになります。自動アクティビティと手動アクティビティを区別することは、自動化分析に欠かせません。既存の自動化の効果を測定し、今後の自動化に適した手動タスクを特定し、プロセスにおける人とシステムの連携を把握できます。重要な理由人が実行するアクティビティとシステムが実行するアクティビティを分けるため、自動化の取り組みや分析の基礎になります。入手先イベントに関連付けられたユーザーIDから導出できます。OperatorIdが既知のシステムまたはエージェントアカウントに該当する場合、このフラグはtrueに設定されます。例 truefalse
	顧客ID CustomerId	オンボーディング対象の顧客を一意に識別するIDです。
説明この属性は、申請とマスターデータシステムの顧客レコードを結び付ける一意のIDです。個人または組織など、KYCプロセスの対象となるエンティティを表します。申請IDがプロセスを追跡するのに対し、顧客IDを使うと、同じ顧客による複数の申請を横断して分析できます。また、顧客セグメントや履歴など、顧客固有の属性をプロセスデータに付加できます。これにより、顧客を中心としたオンボーディング分析が可能になります。重要な理由プロセスデータと顧客マスターデータを結び付け、顧客の属性や履歴に基づく詳細な分析を可能にします。入手先通常、KYCケースの主要プロパティとして、Pega内または外部CRMの顧客データモデルに関連付けられます。例 CUST-98765CUST-98766CUST-98767
	顧客所在国 CustomerCountry	顧客の居住国または設立国です。
説明この属性には、オンボーディング対象の顧客に関連する国が記録されます。リスク評価や必要なデューデリジェンスの水準を決める重要な入力情報です。分析では、顧客の所在国から重要な傾向を把握できます。特定の法域は高リスクとみなされ、オンボーディングがより長く複雑になる場合があります。この切り口によって地域別のパフォーマンスを分析し、地域ごとのコンプライアンス要件が効率的に満たされているかを確認できます。重要な理由プロセスを地理的に分析できます。地域は規制の複雑さやリスクレベルと関連することが多い要素です。入手先通常、ケースに関連付けられた顧客データオブジェクトのプロパティです。例 USADEUSGPGBR

必須推奨任意

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

正確なプロセス発見とKYC顧客オンボーディングに関する深いインサイトを得るために、イベントログに記録すべき主要なプロセス手順とマイルストーンです。

8 推奨 6 任意

	アクティビティ	説明
	オンボーディング完了	KYCオンボーディングプロセス全体が正常に終了したことを示します。Pegaケースが正常完了を示す最終解決ステータスに到達し、下流のすべての処理が完了した時点で記録します。
重要な理由プロセスの主要な成功終了イベントです。オンボーディングに成功したすべての顧客について、エンドツーエンドの処理時間を計算するために欠かせません。入手先ケースの解決ステータス（pyStatusWork）が「Resolved-Completed」など、最終的な成功値に設定された時点のタイムスタンプから推定します。取得 History-Workテーブルで、最終的な「Resolved-Completed」ステータスのタイムスタンプを特定します。イベントタイプ inferred
	コンプライアンスレビュー完了	コンプライアンスチームがレビューを完了し、推奨事項を決定したことを示します。ケースがコンプライアンス段階を抜けるステータスに変わったことから取得します。
重要な理由コンプライアンスレビュー処理時間KPIの終了イベントです。この時点までにかかった時間を分析することは、コンプライアンス業務の効率化に欠かせません。入手先ケースステータス（pyStatusWork）が「Pending-Compliance」から「Pending-Final-Decision」や「Resolved-Approved」などに変わったことから推定します。取得ケース履歴で、コンプライアンスレビューの段階または割り当てが完了した時点のタイムスタンプを特定します。イベントタイプ inferred
	コンプライアンスレビュー開始	コンプライアンスチームによる正式なレビューが始まったことを示します。プロセスの中でも重要で、時間がかかることの多い段階です。ケースがコンプライアンスの作業キューに割り当てられた時点、またはステータスが更新された時点で記録します。
重要な理由コンプライアンスレビュー処理時間KPIの開始イベントです。重要で手作業が多いこのレビュー段階のボトルネックを測定し、特定するのに役立ちます。入手先ケースステータス（pyStatusWork）が「Pending-Compliance」に変わったこと、またはコンプライアンスのワークバスケットで割り当てが作成されたことから推定します。取得ケースがコンプライアンスのワークバスケットに割り当てられた時点、またはレビュー開始を示すステータスに変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	リスク評価完了	申請データと確認データに基づく顧客のリスク評価とスコアリングが完了したことを示します。通常、Pegaケースのリスク評価ステージまたはステップが解決された時点で記録される重要なマイルストーンです。
重要な理由コンプライアンスに関する重要なマイルストーンです。このアクティビティの所要時間と結果を分析することで、リスク管理の効率とプロセス経路への影響を把握できます。入手先 Pegaケースモデル内の特定のステージまたはフローが完了し、監査証跡にステータス変更が記録されたことから推定します。取得リスク評価ステージ後のpyStatusWorkの変更から推定します。たとえば、「Pending-Compliance-Review」への移行が該当します。イベントタイプ inferred
	書類受領	顧客が依頼されたすべての書類をシステムにアップロードまたは提出した時点を示します。通常、Pegaのケースに新しい添付ファイルが紐付けられた時点の明示的なイベントとして記録されます。
重要な理由書類レビューと確認のSLAの計測を開始する重要なマイルストーンです。この時点までの遅延は顧客側の要因によるものですが、その後の遅延は社内要因によるものです。入手先新しい書類がケースに関連付けられた時点で、Pegaの添付ファイルテーブル（pc_link_attachmentまたはpc_data_workattach）に明示的に記録されます。取得ケースに紐付けられた該当する添付ファイルオブジェクトの作成タイムスタンプがイベントになります。イベントタイプ explicit
	申請却下	顧客の申請を却下し、オンボーディングプロセスを終了する最終決定を示します。ケースが最終的な失敗解決ステータスに移行したことから推定します。
重要な理由主要な失敗終了イベントです。申請却下率を分析し、「Rejection Reason」などの属性を通じて失敗理由を把握するうえで重要です。入手先ケースの解決ステータス（pyStatusWork）が「Resolved-Rejected」など、終端の失敗値に設定された時点のタイムスタンプから推定します。取得ケースの監査証跡で、却下ステータスを示すpyStatusWorkの最終更新を特定します。イベントタイプ inferred
	申請承認	顧客のオンボーディング申請を承認する最終決定を示します。ケースステータスが最終的な成功解決の状態に更新されたことから推定する、重要な業務上のマイルストーンです。
重要な理由成功したケースと失敗したケースを分ける重要なマイルストーンです。最終的な口座有効化ステップの前段にあたり、意思決定にかかった時間を測定する一般的なポイントです。入手先ケースの解決ステータス（pyStatusWork）が「Resolved-Completed」や「Resolved-Approved」など、終端の成功値に設定された時点のタイムスタンプから推定します。取得ケースの監査証跡で、成功した解決を示すpyStatusWorkの最終更新を特定します。イベントタイプ inferred
	申請提出	このアクティビティは、Pegaシステムで新しい顧客オンボーディング案件が作成されたことを示します。顧客ポータル、社内ユーザー、自動データフィードのいずれかを通じて、顧客申請の新しいケースインスタンスが正式に開始された時点で記録されます。
重要な理由オンボーディングプロセス全体の主要な開始イベントです。エンドツーエンドの処理時間を測定し、申請件数とそのパターンを分析するために欠かせません。入手先 Pegaの監査証跡に記録される明示的なイベントです。新しいワークオブジェクト（ケース）が作成された時点で記録されます。ケースIDに対応するpc_history_workテーブルの最初のエントリを確認します。取得 pc_workテーブルのケース作成タイムスタンプ、または監査証跡の最初のエントリから取得します。イベントタイプ explicit
	バックグラウンドチェック開始	顧客に対する外部または内部のバックグラウンドチェックが開始されたことを示します。第三者サービスとの連携が含まれる場合があります。通常、ケースがチェック結果を待っていることを示すステータス変更から推定します。
重要な理由外部依存先の応答を待つ時間を切り分けるのに役立ちます。第三者サービスのパフォーマンスと、オンボーディング全体の所要時間への影響を分析できます。入手先 PegaのHistory-Workテーブルに記録された、ケースステータス（pyStatusWork）が「Pending-Background-Check」などに変わったことから推定します。取得バックグラウンドチェックが開始されたことを示すpyStatusWorkの更新時刻を特定します。イベントタイプ inferred
	初期スクリーニング完了	申請データの完全性と基本的な適格性について、初期の、多くの場合は自動化された確認が完了したことを示します。通常、「New」から「Pending-Documents」への移行など、ケースのステータス変更から推定します。
重要な理由この初期段階にかかった時間を分析すると、データ検証や自動ルール実行における早期のボトルネックを特定できます。こうしたボトルネックは、プロセス全体を遅らせる可能性があります。入手先 Pegaの監査証跡（History-Workテーブル）に記録されたケースステータスプロパティ（pyStatusWork）の変更から推定します。取得 pyStatusWorkが「New」または「Submitted」から「ScreeningComplete」などの状態に変わった時点のタイムスタンプを特定します。イベントタイプ inferred
	口座有効化	顧客の口座が基幹銀行システムまたは関連する下流システムで正常に作成され、有効化されたことを示します。通常、承認後にPegaケースの最終ステータスが更新されたことから推定します。
重要な理由顧客と企業にとって価値が実現する瞬間です。「申請承認」からこのイベントまでの時間により、システム間の引き継ぎ効率を測定できます。入手先「Resolved-AccountActive」などのケースステータス（pyStatusWork）、または連携によってケースに設定されたフラグから推定します。監査証跡に記録された情報を使用します。取得下流の口座が有効になったことを示すケースプロパティの更新時刻を特定します。イベントタイプ inferred
	書類レビュー完了	コンプライアンス担当者または自動処理が、顧客から提出された書類のレビューを完了したことを示します。レビュー工程が完了したことを示すケースまたは書類ステータスの変更から推定します。
重要な理由書類確認時間KPIの終了イベントです。このステップの完了までにかかった時間を分析すると、手作業または自動化されたレビュー工程の非効率を特定できます。入手先監査証跡で、ケースステータス（pyStatusWork）が「Pending-Review」から「Review-Complete」または「Pending-Checks」などに変わったことから推定します。取得書類確認サブプロセスが解決されたことを示す、ケースステータス（pyStatusWork）の変更時刻を特定します。イベントタイプ inferred
	書類依頼	システムまたは担当者が、処理を進めるために顧客から特定の書類を提出してもらう必要があると判断した時点で発生します。通信記録の作成や、ケースステータスが「Pending-Customer-Docs」などに変わったことから取得します。
重要な理由このイベントを追跡すると、顧客の回答にかかる時間を測定し、書類待ちでプロセスが頻繁に停滞しているかどうかを確認できます。書類確認時間KPIの前段となるイベントです。入手先明示的な通信イベント（pc_link_attachment）として記録される場合と、監査証跡に記録されたケースステータス（pyStatusWork）の変更から推定する場合があります。取得 pyStatusWorkが「Pending-Documents」などに変わったことから推定します。「Send Correspondence」の明示的なイベントと紐付けることもできます。イベントタイプ inferred
	追加情報依頼	通常はコンプライアンス担当のレビュー担当者が、顧客に追加情報や説明を求めた時点で発生します。ケースから担当者が特定の通信を送信した時点で記録される、明示的なイベントであることが多いです。
重要な理由プロセスの手戻りとループを示す主要な指標です。発生頻度を追跡することで、初回処理完了率を測定し、要件が不明確な箇所を特定できます。入手先監査証跡に記録された「Send Correspondence」の明示的なイベントとして取得できます。または、ステータスが「Pending-Customer-Info」に変わったことから推定できます。取得特定の通信オブジェクトの作成、またはケース担当者が開始したフローアクションから取得します。イベントタイプ explicit

推奨任意

抽出ガイド

Pega KYCからデータを取得する方法

ステップ

Pega Designer Studioにアクセス：開発者またはBIX管理者の権限でPega環境にログインします。Recordsエクスプローラーを開き、SysAdminカテゴリーを展開します。
BIX Extract Ruleを作成：Extractを右クリックしてCreateを選択します。ExtractCustomerOnboardingHistoryなど、内容が分かるラベルを付けます。アプリケーションのルールセットを選択し、抽出元のクラスを指定します。イベントログを作成する場合は、ケースタイプの履歴クラスを使う必要があります。通常は[Your-FW-KYC-History-Work]の形式です。
Definitionタブを設定：Extract Ruleフォームで、Class Nameに前の手順で特定した履歴クラスを設定します。ケースの概要ではなくイベントログを生成するために必要な設定です。
フィルター条件を設定：Filter Criteriaタブを開きます。データ量を抑えるため、ケース作成日時のフィルターを追加します。プロパティpxCreateDateTimeを使い、例えば3か月前より後の期間を設定します。必要に応じて、ケースのステータスやタイプで絞り込む条件も追加できます。
抽出するプロパティを定義：Dataタブを開きます。ここでPegaのプロパティを出力ファイルの列に対応付けます。必要な属性ごとに行を追加します。例：
- CustomerApplication：.pzInsKey（ケースの一意のキー）に対応付けます。
- EventTime：.pxTimeCreated（履歴イベントのタイムスタンプ）に対応付けます。
- RawActivity：.pyMessageKey（イベントを示すPega内部メッセージコード）に対応付けます。
- Status：.pyHistoryType（例：Field-Level Auditing、Assignment、Status Change）に対応付けます。
- OperatorId：.pxPerformerに対応付けます。
- .pyAssignedToWorkgroupなどのプロパティや、.RiskLevel、.RejectionReasonなどケース固有のデータも追加します。ケースレベルのデータには、pxHistoryForReferenceのようにケースインスタンスを参照するページプロパティを介してアクセスする必要があります。
ファイル出力を指定：File Specificationタブで出力形式を定義します。File TypeにCSVを選択します。出力ファイル名（例：kyc_event_log.csv）を指定します。Pegaサーバー上の保存先ディレクトリも設定できます。
抽出をスケジュール：Extract Ruleを保存します。テスト時はActions > Runメニューから手動で実行できます。本番環境では、pxExtractDataWithArgsアクティビティを呼び出すJob Schedulerルールを作成し、例えば毎晩BIX抽出を実行します。
生のイベントを変換：.pyMessageKeyと.pyHistoryTypeを使ってPegaの履歴テーブルから抽出した生のデータは、技術的な形式です。これらのイベントを必要な業務アクティビティに対応付ける変換レイヤーを適用する必要があります。BIXのCSV出力をステージングデータベースまたはデータ変換ツールに読み込みます。
業務ロジックを適用：SQLスクリプトまたは変換ジョブを実行し、CASE文で生のPegaイベントを業務で使いやすいActivityNameの値に変換します。提供されているクエリに、このロジックの完全な例があります。
最終イベントログを生成：変換後、データはイベントログとして正しい構造になります。変換済みデータをCSVファイルに出力し、列見出しがProcessMindの要件（CustomerApplication、ActivityName、EventTimeなど）と一致していることを確認します。
ProcessMindにアップロード：整形済みのCSVファイルをProcessMindプロジェクトにアップロードします。

設定

抽出対象のPegaクラス：最も重要な設定は、KYCケースタイプに関連付けられた履歴クラスから抽出することです。例：[Your-FW-KYC-History-Work]。作業クラス（[Your-FW-KYC-Work]）から抽出すると、ケースごとに1行しか生成されず、イベントログにはなりません。
フィルター条件：データ量を管理するため、必ずpxCreateDateTimeに期間フィルターを設定します。初回分析では、過去3～6か月の範囲を推奨します。pyStatusWorkで追加のフィルターを設定し、すぐに取り下げられたケースなど、不要なケースを除外することもできます。
主要なPegaプロパティ：抽出では、Pegaの主要プロパティを使用します。.pzInsKeyはケースの一意の識別子です。履歴クラスのインスタンスにある.pxTimeCreatedはイベントのタイムスタンプを示します。.pyMessageKeyと.pyHistoryTypeは、業務アクティビティを特定するために必要な情報を提供します。
出力形式：BIXがマニフェスト付きのCSVファイルを出力するよう設定します。マニフェストファイル（.xml）には抽出実行に関するメタデータが含まれており、監査やトラブルシューティングに役立ちます。
前提条件：Pega-BIXルールセットをアプリケーションにインストールし、有効にしておく必要があります。抽出を実行するユーザーにはPegaRULES:BIXAdminsロールが必要です。BIXはライセンスが必要なPega製品です。
パフォーマンス：数百万件のケースを含む大規模なデータセットでは、BIX抽出を負荷の低い時間帯に実行することを検討してください。以降の実行では、前回の正常終了時刻に基づく増分抽出を設定すると、パフォーマンスを改善できます。

a サンプルクエリ sql

/*
 Part 1: BIX Rule-Admin-Extract Configuration (XML Representation)
 This XML defines the BIX rule. You would configure this using the Pega UI.
 The key is extracting from the History-Work class and including the raw event fields.
*/

<?xml version="1.0"?>
<pagedata>
    <pxObjClass>Rule-Admin-Extract</pxObjClass>
    <pyClassName>[Your-FW-KYC-History-Work]</pyClassName>
    <pyExtractName>ExtractCustomerOnboardingHistory</pyExtractName>
    <pyOutputFormat>CSV</pyOutputFormat>
    <pyDelimiter>,</pyDelimiter>
    <pyTargetFile>kyc_event_log.csv</pyTargetFile>
    <!-- Filter Criteria: Filter for cases created in the last 180 days -->
    <pyFilterCriteria>
        <rowdata REPEATINGTYPE="PageList">
            <row RIX="1">
                <pyFilterProperty>pxHistoryForReference.pxCreateDateTime</pyFilterProperty>
                <pyCondition>IS GREATER THAN</pyCondition>
                <pyFilterValue>CurrentDate-180</pyFilterValue>
            </row>
        </rowdata>
    </pyFilterCriteria>
    <!-- Properties to Extract -->
    <pyExtractProperties>
        <rowdata REPEATINGTYPE="PageList">
            <row RIX="1"><pyTargetProperty>CustomerApplication</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pyID</pySourceProperty></row>
            <row RIX="2"><pyTargetProperty>EventTime</pyTargetProperty><pySourceProperty>.pxTimeCreated</pySourceProperty></row>
            <row RIX="3"><pyTargetProperty>RawActivity</pyTargetProperty><pySourceProperty>.pyMessageKey</pySourceProperty></row>
            <row RIX="4"><pyTargetProperty>HistoryType</pyTargetProperty><pySourceProperty>.pyHistoryType</pySourceProperty></row>
            <row RIX="5"><pyTargetProperty>OperatorId</pyTargetProperty><pySourceProperty>.pxPerformer</pySourceProperty></row>
            <row RIX="6"><pyTargetProperty>WorkGroup</pyTargetProperty><pySourceProperty>.pyAssignedToWorkgroup</pySourceProperty></row>
            <row RIX="7"><pyTargetProperty>ApplicationStatus</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pyStatusWork</pySourceProperty></row>
            <row RIX="8"><pyTargetProperty>SlaTargetDate</pyTargetProperty><pySourceProperty>.pxHistoryForReference.pxGoalTime</pySourceProperty></row>
            <row RIX="9"><pyTargetProperty>RiskLevel</pyTargetProperty><pySourceProperty>.pxHistoryForReference.[YourRiskLevelProperty]</pySourceProperty></row>
            <row RIX="10"><pyTargetProperty>RejectionReason</pyTargetProperty><pySourceProperty>.pxHistoryForReference.[YourRejectionReasonProperty]</pySourceProperty></row>
        </rowdata>
    </pyExtractProperties>
</pagedata>

/*
 Part 2: SQL Transformation Query
 This script is run after BIX exports the raw data. It translates the technical
 Pega history events into the required business-friendly activity names.
 Assumes the BIX output has been loaded into a staging table named 'bix_raw_history'.
*/

SELECT
    b.CustomerApplication,
    CASE
        WHEN b.HistoryType = 'New' THEN 'Application Submitted'
        WHEN b.RawActivity = 'workitem new' THEN 'Application Submitted'
        WHEN b.RawActivity LIKE 'Status changed from New to Pending-Documents' THEN 'Initial Screening Performed'
        WHEN b.RawActivity LIKE 'Correspondence generated for document request' THEN 'Documents Requested'
        WHEN b.RawActivity LIKE 'Attachment added' THEN 'Documents Received'
        WHEN b.RawActivity = 'Flow Action: CompleteDocumentReview' THEN 'Document Review Completed'
        WHEN b.RawActivity LIKE '%BackgroundCheck%' AND b.HistoryType = 'Status Change' THEN 'Background Check Initiated'
        WHEN b.RawActivity = 'StageCompleted: RiskAssessment' THEN 'Risk Assessment Performed'
        WHEN b.RawActivity = 'AssignmentCreated: ComplianceQueue' THEN 'Compliance Review Initiated'
        WHEN b.RawActivity LIKE 'Correspondence sent to customer for info' THEN 'Additional Information Requested'
        WHEN b.RawActivity = 'StageCompleted: ComplianceReview' THEN 'Compliance Review Completed'
        WHEN b.RawActivity = 'Resolved-Completed' AND b.ApplicationStatus LIKE 'Approved%' THEN 'Application Approved'
        WHEN b.RawActivity = 'Status changed from Approved to Active' THEN 'Account Activated'
        WHEN b.RawActivity = 'Resolved-Completed' THEN 'Onboarding Completed'
        WHEN b.RawActivity = 'Resolved-Rejected' THEN 'Application Rejected'
        ELSE NULL -- Exclude rows that do not map to a required activity
    END AS ActivityName,
    b.EventTime,
    NULL AS EndTime, -- EndTime is not directly available from Pega history
    b.OperatorId,
    b.WorkGroup,
    b.ApplicationStatus,
    b.RejectionReason,
    b.SlaTargetDate,
    b.RiskLevel
FROM
    bix_raw_history AS b
WHERE
    CASE
        WHEN b.HistoryType = 'New' THEN 'Application Submitted'
        WHEN b.RawActivity = 'workitem new' THEN 'Application Submitted'
        WHEN b.RawActivity LIKE 'Status changed from New to Pending-Documents' THEN 'Initial Screening Performed'
        WHEN b.RawActivity LIKE 'Correspondence generated for document request' THEN 'Documents Requested'
        WHEN b.RawActivity LIKE 'Attachment added' THEN 'Documents Received'
        WHEN b.RawActivity = 'Flow Action: CompleteDocumentReview' THEN 'Document Review Completed'
        WHEN b.RawActivity LIKE '%BackgroundCheck%' AND b.HistoryType = 'Status Change' THEN 'Background Check Initiated'
        WHEN b.RawActivity = 'StageCompleted: RiskAssessment' THEN 'Risk Assessment Performed'
        WHEN b.RawActivity = 'AssignmentCreated: ComplianceQueue' THEN 'Compliance Review Initiated'
        WHEN b.RawActivity LIKE 'Correspondence sent to customer for info' THEN 'Additional Information Requested'
        WHEN b.RawActivity = 'StageCompleted: ComplianceReview' THEN 'Compliance Review Completed'
        WHEN b.RawActivity = 'Resolved-Completed' AND b.ApplicationStatus LIKE 'Approved%' THEN 'Application Approved'
        WHEN b.RawActivity = 'Status changed from Approved to Active' THEN 'Account Activated'
        WHEN b.RawActivity = 'Resolved-Completed' THEN 'Onboarding Completed'
        WHEN b.RawActivity = 'Resolved-Rejected' THEN 'Application Rejected'
        ELSE NULL
    END IS NOT NULL;

ステップ

前提条件と環境設定：Python 3.6以降がインストールされていることを確認します。ターミナルで次のコマンドを実行し、データ操作に使うpandasとAPI呼び出しに使うrequestsをインストールします：pip install pandas requests。
API認証情報を取得：PegaでRESTサービスクライアントの登録を作成します。OAuth 2.0のClient Credentialsグラントタイプを設定し、認証に必要なClient IDとClient Secretを記録します。
スクリプトを設定：提供されたPythonスクリプトを開きます。先頭の設定セクションで、PEGA_BASE_URL、CLIENT_ID、CLIENT_SECRET、CASE_TYPEのプレースホルダーを、使用するPega環境の情報に置き換えます。
抽出パラメーターを設定：スクリプト内のSTART_DATEとEND_DATEを調整し、抽出するケースデータの期間を指定します。これにより、イベントログに含める顧客申請を制御します。
Pythonスクリプトを実行：ターミナルでpython extract_pega_kyc_data.pyを実行します。スクリプトはまずPega APIで認証し、アクセストークンを取得してから、対象ケースの識別子の取得を開始します。
ケースと監査データを取得：取得した各ケース識別子について、スクリプトは主に2つのAPI呼び出しを行います。1つ目ではステータスやリスクレベルなどの属性を取得するため、ケースの基本情報を取得します。2つ目では、イベントの順序、ステータス変更、ユーザー操作を含むケースの監査履歴を取得します。
監査イベントをアクティビティに対応付け：スクリプトの中心的な処理では、各ケースの監査履歴を処理します。Pegaの特定のステータス変更（例：pyStatusWorkの変更）と監査メモを、「申請受付」や「コンプライアンス審査完了」など、定義済みの業務アクティビティに対応付けます。
データを構造化して変換：各イベントを処理しながら、特定したアクティビティごとに1行を作成し、データを標準形式に整えます。CustomerApplication、ActivityName、EventTimeおよび推奨属性の列に値を設定します。
イベントログファイルを生成：期間内のすべてのケースの処理が完了したら、データを統合し、pandasを使ってpega_kyc_event_log.csvという名前のCSVファイルにイベントログ全体を出力します。

設定

APIエンドポイント：スクリプトは標準的なPega REST APIを使用します。主なエンドポイントには、認証用の/token、ケース識別子の検索用の/cases、詳細なケースデータと監査履歴の取得用の/cases/{ID}があります。ケース一覧の取得に使う正確なエンドポイントは、Pega Report Definitionを公開するカスタムAPIの場合があります。
認証：スクリプトはClient IDとSecretを使うOAuth 2.0で、安全なサーバー間通信を行います。PegaのAPIクライアントには、指定したKYCケースタイプと関連データへの読み取りアクセス権を持つロールを付与する必要があります。
期間フィルター：スクリプトにはSTART_DATEとEND_DATEのパラメーターが設定されています。タイムアウトを避け、メモリ使用量を適切に管理するため、例えば3～6か月ずつデータを抽出することを推奨します。これらの日付で、処理対象となるケースの初期一覧を絞り込みます。
ケースタイプのフィルター：重要なパラメーターはCASE_TYPEです。例としてYourOrg-App-Work-KYCのように、Pega KYC顧客オンボーディングのケースに対応するクラス名を設定する必要があります。これにより、対象プロセスのデータだけを抽出できます。
パフォーマンスに関する考慮事項：ケースデータと監査履歴を1件ずつ取得するため、大量データでは時間がかかる場合があります。スクリプトには、最初のケース一覧取得にページングが含まれています。5万件を超えるケースを抽出する場合は、負荷の低い時間帯に実行するか、Pega環境で利用できる場合は一括抽出の代替手段を検討してください。

a サンプルクエリ python

import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your Pega environment details
PEGA_BASE_URL = class="hl-string">"https://[your-pega-server]/prweb/api/v1"
CLIENT_ID = class="hl-string">"[your_client_id]"
CLIENT_SECRET = class="hl-string">"[your_client_secret]"

class=class="hl-string">"hl-comment"># Pega Case Type for KYC Customer Onboarding
CASE_TYPE = class="hl-string">"[Your-KYC-Case-Type]"

class=class="hl-string">"hl-comment"># Date range for extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># Mapping from Pega statuses/audit notes to standard Activity Names
class=class="hl-string">"hl-comment"># This section requires customization based on your specific Pega application configuration.
ACTIVITY_MAPPING = {
    class="hl-string">'Pending-InitialScreening': class="hl-string">'Initial Screening Performed',
    class="hl-string">'Pending-Customer-Docs': class="hl-string">'Documents Requested',
    class="hl-string">'Attachment-Added': class="hl-string">'Documents Received',
    class="hl-string">'Pending-DocReview': class="hl-string">'Document Review Completed',
    class="hl-string">'Pending-BackgroundCheck': class="hl-string">'Background Check Initiated',
    class="hl-string">'Pending-RiskAssessment': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'Pending-ComplianceReview': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'Correspondence-Sent-InfoRequest': class="hl-string">'Additional Information Requested',
    class="hl-string">'Pending-FinalDecision': class="hl-string">'Compliance Review Completed',
    class="hl-string">'Resolved-Completed': class="hl-string">'Application Approved',
    class="hl-string">'Status-AccountActivated': class="hl-string">'Account Activated',
    class="hl-string">'Resolved-Onboarded': class="hl-string">'Onboarding Completed',
    class="hl-string">'Resolved-Rejected': class="hl-string">'Application Rejected'
}

class=class="hl-string">"hl-comment"># --- Script Logic --- #

def get_access_token():
    class="hl-string">"""Authenticates with Pega and returns an access token."""
    token_url = fclass="hl-string">"{PEGA_BASE_URL.replace('/api/v1', '')}/PRRestService/oauth2/v1/token"
    auth_payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials'
    }
    try:
        response = requests.post(token_url, auth=(CLIENT_ID, CLIENT_SECRET), data=auth_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def get_case_ids(token):
    class="hl-string">"""Retrieves a list of case IDs for the specified date range and case type."""
    case_ids = []
    page = 1
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}'}
    
    while True:
        query_params = {
            class="hl-string">'caseTypeID': CASE_TYPE,
            class="hl-string">'query': fclass="hl-string">'.pxCreateDateTime > "{START_DATE}T00:00:00.000Z" AND .pxCreateDateTime < "{END_DATE}T23:59:59.000Z"',
            class="hl-string">'page': page,
            class="hl-string">'pageSize': 1000  class=class="hl-string">"hl-comment"># Adjust page size as needed
        }
        try:
            response = requests.get(fclass="hl-string">"{PEGA_BASE_URL}/cases", headers=headers, params=query_params)
            response.raise_for_status()
            data = response.json()
            cases_on_page = data.get(class="hl-string">'cases', [])
            if not cases_on_page:
                break class=class="hl-string">"hl-comment"># Exit loop if no more cases are returned
            
            for case in cases_on_page:
                case_ids.append(case.get(class="hl-string">'ID'))
            
            page += 1
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching case IDs on page {page}: {e}")
            break
    return case_ids

def main():
    class="hl-string">"""Main function to extract, process, and save event data."""
    print(class="hl-string">"Starting Pega KYC data extraction...")
    access_token = get_access_token()
    if not access_token:
        return

    print(fclass="hl-string">"Successfully authenticated. Fetching case IDs between {START_DATE} and {END_DATE}...")
    case_ids = get_case_ids(access_token)
    print(fclass="hl-string">"Found {len(case_ids)} cases to process.")

    event_log = []
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}'}

    for i, case_id in enumerate(case_ids):
        print(fclass="hl-string">"Processing case {i+1}/{len(case_ids)}: {case_id}")
        try:
            case_response = requests.get(fclass="hl-string">"{PEGA_BASE_URL}/cases/{case_id}", headers=headers)
            case_response.raise_for_status()
            case_data = case_response.json()

            class=class="hl-string">"hl-comment"># Extract case-level attributes
            case_info = case_data.get(class="hl-string">'content', {})
            rejection_reason = case_info.get(class="hl-string">'RejectionReason', None)
            sla_date = case_info.get(class="hl-string">'pySLADeadline', None)
            risk_level = case_info.get(class="hl-string">'RiskLevel', None)

            class=class="hl-string">"hl-comment"># 1. Application Submitted Event (from case creation time)
            event_log.append({
                class="hl-string">'CustomerApplication': case_id,
                class="hl-string">'ActivityName': class="hl-string">'Application Submitted',
                class="hl-string">'EventTime': case_info.get(class="hl-string">'pxCreateDateTime'),
                class="hl-string">'EndTime': None, class=class="hl-string">"hl-comment"># EndTime can be derived in post-processing if needed
                class="hl-string">'OperatorId': case_info.get(class="hl-string">'pxCreateOperator'),
                class="hl-string">'WorkGroup': case_info.get(class="hl-string">'pxCreateOpWorkgroup', None),
                class="hl-string">'ApplicationStatus': case_info.get(class="hl-string">'pyStatusWork'),
                class="hl-string">'RejectionReason': rejection_reason,
                class="hl-string">'SlaTargetDate': sla_date,
                class="hl-string">'RiskLevel': risk_level
            })

            class=class="hl-string">"hl-comment"># 2. Process Audit History for other events
            audit_history = case_data.get(class="hl-string">'audit', [])
            for audit_entry in audit_history:
                timestamp = audit_entry.get(class="hl-string">'timeStamp')
                operator = audit_entry.get(class="hl-string">'performedBy', {}).get(class="hl-string">'userID')
                message = audit_entry.get(class="hl-string">'message')
                
                class=class="hl-string">"hl-comment"># Map status changes and specific messages to activities
                activity_name = None
                if class="hl-string">'changed status to' in message:
                    new_status = message.split(class="hl-string">' to ')[-1].strip()
                    activity_name = ACTIVITY_MAPPING.get(new_status)
                elif class="hl-string">'Created attachment' in message:
                    class=class="hl-string">"hl-comment"># This is a generic mapping, may need refinement
                    activity_name = ACTIVITY_MAPPING.get(class="hl-string">'Attachment-Added')
                elif class="hl-string">'Sent correspondence' in message and class="hl-string">'Request for Information' in message:
                     activity_name = ACTIVITY_MAPPING.get(class="hl-string">'Correspondence-Sent-InfoRequest')
                
                if activity_name:
                    event_log.append({
                        class="hl-string">'CustomerApplication': case_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTime': timestamp,
                        class="hl-string">'EndTime': None,
                        class="hl-string">'OperatorId': operator,
                        class="hl-string">'WorkGroup': None, class=class="hl-string">"hl-comment"># Workgroup is not always available in audit trail
                        class="hl-string">'ApplicationStatus': case_info.get(class="hl-string">'pyStatusWork'),
                        class="hl-string">'RejectionReason': rejection_reason,
                        class="hl-string">'SlaTargetDate': sla_date,
                        class="hl-string">'RiskLevel': risk_level
                    })

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not process case {case_id}: {e}")
        except Exception as ex:
            print(fclass="hl-string">"An unexpected error occurred processing case {case_id}: {ex}")

    print(class="hl-string">"Processing complete. Generating CSV file...")
    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTime'], ascending=[True, True])
    df.to_csv(class="hl-string">'pega_kyc_event_log.csv', index=False)
    print(class="hl-string">"Event log saved to pega_kyc_event_log.csv")

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

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

このデータテンプレートを使えば、KYC顧客オンボーディングプロセスの最適化を始めるための確かな基盤を整えられます。今日から非効率を見つけ出し、コンプライアンス対応を強化しましょう。

改善ガイドに戻るテンプレートをダウンロード

今すぐKYCオンボーディングを効率化し、遅延をなくす

スムーズなKYC対応を実現し、オンボーディングを24時間以内に短縮して、コンプライアンスを強化します。

無料トライアルを開始

クレジットカード不要。数分で設定できます

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

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

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

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

抽出ガイド

Pega Business Intelligence Exchange（BIX）エクスポート

ステップ

設定

a サンプルクエリ sql

Pega Case Management REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

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

今すぐKYCオンボーディングを効率化し、遅延をなくす

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

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

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

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

抽出ガイド

Pega Business Intelligence Exchange（BIX）エクスポート

ステップ

設定

a サンプルクエリ sql

Pega Case Management REST APIを使ったPythonスクリプト

ステップ

設定

a サンプルクエリ python

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

今すぐKYCオンボーディングを効率化し、遅延をなくす

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