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

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

Pega KYC

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

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

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

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

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

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

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

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

3 必須 7 推奨 11 任意

	名前	説明
	アクティビティ ActivityName	オンボーディングプロセスで発生した特定のイベントまたはタスクの名前です。
説明この属性には、「申請提出」「コンプライアンス審査開始」「申請却下」など、業務アクティビティやシステムイベントの名前が記録されます。顧客のオンボーディングプロセスを構成する個々のステップを表します。アクティビティの分析は、プロセスマイニングの中核です。この属性を使ってプロセスマップを作成し、各ステップ間の流れを示します。イベントの順序や各アクティビティの発生頻度を確認し、頻度が高いタスクや時間のかかるタスクを特定できます。重要な理由この属性によってプロセスマップの各ステップが定まり、プロセスの流れを可視化、分析し、理解できます。入手先この情報は通常、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つのケース内で何度も変わることがあります。「オンボーディングの処理量とステータス」ダッシュボードや「書類確認の所要時間」分析に欠かせない属性です。よくボトルネックになる領域を詳しく把握できます。書類が各ステータスにとどまる時間を追跡すると、顧客による提出や社内審査の遅れを特定できます。重要な理由書類処理のサブプロセスを可視化し、書類確認でよく発生する遅延の特定と解消に役立ちます。入手先通常、メインケースに関連付けられたデータオブジェクトまたはページリストのプロパティとして、必要書類ごとに管理されます。詳しくは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
	申請を却下	顧客の申請を却下する最終決定を示し、オンボーディングプロセスを終了します。ケースが最終的な不成立ステータスに移行したことから推定します。
重要な理由主な失敗終了イベントです。申請却下率の分析や、「却下理由」などの属性を使った失敗理由の把握に欠かせません。入手先ケースの解決ステータス（pyStatusWork）が「Resolved-Rejected」などの最終的な失敗値に設定されたタイムスタンプから推定します。記録ケースの監査証跡で、却下ステータスを示すpyStatusWorkの最後の更新を特定します。イベントタイプ inferred
	申請を承認	顧客のオンボーディング申請を承認する最終決定を示します。ケースのステータスが最終的な成功状態に更新されたことから推定する、重要な業務上の節目です。
重要な理由成功したケースと不成立のケースを分ける重要な節目です。最終的なアカウント有効化の前段階にあたり、意思決定にかかる時間を測定する際によく使われます。入手先ケースの解決ステータス（pyStatusWork）が「Resolved-Completed」や「Resolved-Approved」などの最終的な成功値に設定されたタイムスタンプから推定します。記録ケースの監査証跡で、正常な解決を示すpyStatusWorkの最終更新を特定します。イベントタイプ inferred
	申請を提出	このアクティビティは、Pegaシステムで新しい顧客オンボーディング案件が作成されたことを示します。顧客ポータル、社内ユーザー、自動データ連携のいずれかを通じて、顧客申請の新しいケースが正式に開始された時点で記録されます。
重要な理由オンボーディングプロセス全体の開始イベントです。最初から最後までのサイクルタイムを測定し、申請件数や提出パターンを分析するうえで欠かせません。入手先新しい作業オブジェクト（ケース）が作成されたときに、Pegaの監査証跡に明示的に記録されるイベントです。ケースIDに対応するpc_history_workテーブルの最初のレコードを確認してください。記録 pc_workテーブルのケース作成タイムスタンプ、または監査証跡の最初のレコードから取得します。イベントタイプ explicit
	アカウントを有効化	顧客のアカウントが基幹銀行システムまたは関連する後続システムで正常に作成され、有効化されたことを示します。承認後にPegaのケースが最終ステータスに更新されたことから推定する場合が多くあります。
重要な理由顧客と事業にとって価値が実現する時点です。「申請を承認」からこのイベントまでの時間を測定すると、システム間の引き継ぎの効率を把握できます。入手先監査証跡に記録された「Resolved-AccountActive」などのケースステータス（pyStatusWork）、または連携によってケースに設定されたフラグから推定します。記録後続システムのアカウントが有効になったことを示す、ケース属性の更新タイムスタンプを特定します。イベントタイプ inferred
	バックグラウンドチェックを開始	顧客に対する社内または外部のバックグラウンドチェックの開始を示します。第三者サービスとの連携が必要になる場合があります。通常、チェック結果待ちを示すステータス変更から推定します。
重要な理由このアクティビティにより、外部の依存先からの応答を待つ時間を切り分けられます。第三者サービスのパフォーマンスと、オンボーディング全体の所要時間への影響を分析できます。入手先 PegaのHistory-Workテーブルに記録されたケースのステータス（pyStatusWork）が「Pending-Background-Check」などに変わったことから推定します。記録バックグラウンドチェックの開始を示すpyStatusWorkの更新タイムスタンプを特定します。イベントタイプ inferred
	初期審査を実施	申請データの完全性と基本的な適格性について、初期審査（多くの場合は自動処理）が完了したことを示します。通常、「新規」から「書類待ち」への移行など、ケースのステータス変更から推定します。
重要な理由この初期段階にかかる時間を分析すると、データ検証や自動ルールの実行における早期のボトルネックを特定できます。こうした遅れは、プロセス全体に影響する可能性があります。入手先 Pegaの監査証跡（History-Workテーブル）に記録されたケースのステータス属性（pyStatusWork）の変更から推定します。記録 pyStatusWorkが「New」または「Submitted」から「ScreeningComplete」などに変わったタイムスタンプを特定します。イベントタイプ inferred
	文書の審査を完了	コンプライアンス担当者または自動処理による、顧客提出文書の審査が完了したことを示します。ケースまたは文書のステータス変更から、審査ステップの完了を推定します。
重要な理由文書確認の所要時間に関する重要業績評価指標（KPI）の計測を完了するイベントです。このステップの完了までにかかる時間を分析すると、手作業または自動審査の非効率を特定できます。入手先監査証跡で、ケースのステータス（pyStatusWork）が「Pending-Review」から「Review-Complete」または「Pending-Checks」に変わったことから推定します。記録ケースのステータス（pyStatusWork）が変わったタイムスタンプを特定します。これにより、文書確認のサブプロセスが完了したことを把握できます。イベントタイプ inferred
	書類を依頼	手続きを進めるために顧客から特定の書類が必要だと、システムまたは担当者が判断したときに発生します。連絡記録の作成、またはケースのステータスが「顧客書類待ち」などに変わったことから特定します。
重要な理由このアクティビティを追跡すると、顧客の回答にかかる時間を測定し、文書化を待つ間にプロセスが頻繁に滞っていないかを確認できます。文書確認の所要時間に関する重要業績評価指標（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を右クリックして作成を選択します。ルールにわかりやすい名前を付けます。例：ExtractCustomerOnboardingHistory。アプリケーションのルールセットを選び、抽出元のクラスを指定します。イベントログを作成するには、ケースタイプの履歴クラスを使う必要があります。通常は[Your-FW-KYC-History-Work]の形式です。
Definitionタブを設定：Extract Ruleフォームで、Class Nameに前の手順で確認した履歴クラスを指定します。ケースの概要ではなくイベントログを作成するために、この設定が重要です。
フィルター条件を設定：Filter Criteriaタブに移動し、ケース作成日時のフィルターを追加して、データ量を制限します。プロパティpxCreateDateTimeを使い、たとえば過去3か月より前の日付を指定します。必要に応じて、ケースのステータスやタイプで絞り込む条件も追加できます。
抽出するプロパティを指定：Dataタブで、Pegaのプロパティを出力ファイルの列に割り当てます。必要な属性ごとに行を追加します。例：
- CustomerApplication：.pzInsKey（ケースの一意のキー）を割り当てます。
- EventTime：.pxTimeCreated（履歴イベントのタイムスタンプ）を割り当てます。
- RawActivity：.pyMessageKey（イベントを示すPega内部メッセージコード）を割り当てます。
- ステータス：.pyHistoryType（例：'フィールドレベル監査'、'割り当て'、'ステータス変更'）を割り当てます。
- OperatorId：.pxPerformerを割り当てます。
- .pyAssignedToWorkgroupなどのプロパティや、.RiskLevel、.RejectionReasonなどケース固有のデータも追加します。ケースレベルのデータにアクセスするには、ケースインスタンスを参照するページプロパティ（pxHistoryForReferenceなど）を介する必要があります。
出力ファイルを指定：File Specificationタブで出力形式を設定します。File TypeにCSVを選びます。出力ファイル名を指定します。例：kyc_event_log.csv。Pegaサーバー上の保存先ディレクトリーも設定できます。
抽出をスケジュール：Extractルールを保存します。テストする場合は、Actions > Runメニューから手動で実行できます。本番環境では、pxExtractDataWithArgsアクティビティを呼び出してBIX抽出を定期実行するJob Schedulerルールを作成します。たとえば、毎晩実行するよう設定できます。
生イベントを変換：.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抽出を利用の少ない時間帯に実行することを検討してください。前回の正常終了時刻を基準にした増分抽出を設定すると、2回目以降の処理性能を高められます。

クエリの例 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のクライアントクレデンシャル付与タイプを設定し、認証に必要なクライアントIDとクライアントシークレットを記録します。
スクリプトを設定：提示された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が必要な場合があります。
認証：スクリプトはクライアントIDとシークレットを使ったOAuth 2.0により、サーバー間通信を安全に行います。PegaのAPIクライアントには、指定したKYCケースタイプと関連データへの読み取りアクセス権を持つロールを付与する必要があります。
日付範囲フィルター：スクリプトではSTART_DATEとEND_DATEを設定します。タイムアウトを避け、メモリー使用量を適切に保つため、たとえば3～6か月ごとに分けて抽出することを推奨します。これらの日付は、処理対象となるケースの初期一覧を絞り込むために使われます。
ケースタイプのフィルター：重要なパラメーターはCASE_TYPEです。Pega KYC顧客オンボーディングの特定のクラス名（例：YourOrg-App-Work-KYC）を設定する必要があります。これにより、対象プロセスのデータだけを抽出できます。
パフォーマンスに関する考慮事項：ケースデータと監査履歴を1件ずつ取得する方法は、大量のデータを処理する場合に時間がかかることがあります。スクリプトには、最初のケース一覧を取得する際のページ分割処理が含まれています。5万件を超えるケースを抽出する場合は、利用の少ない時間帯にスクリプトを実行するか、Pega環境で利用できる一括抽出方法を検討してください。

クエリの例 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）によるエクスポート

ステップ

設定

クエリの例 sql

Pegaケース管理REST APIを使ったPythonスクリプト

ステップ

設定

クエリの例 python

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

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