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

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

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

このテンプレートは、KYC顧客オンボーディングプロセスを分析するために必要な不可欠なデータを収集するための明確なロードマップを提供します。イベントログ内で収集すべき重要な属性と追跡すべき主要な活動を概説しています。さらに、このデータを効果的に抽出し、プロセスマイニングジャーニーをスムーズに開始するための実践的なガイダンスも記載されています。
  • イベントログに推奨される属性
  • プロセス全体で追跡する主要な活動
  • 実践的なデータ抽出ガイド
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

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

これらは、KYC顧客オンボーディングプロセスの包括的な分析に不可欠な詳細を提供する、イベントログに含めることが推奨されるデータフィールドです。
3 必須 7 推奨 12 任意
名前 説明
アクティビティ
ActivityName
オンボーディングプロセス内で発生した特定のイベントまたはタスクの名前。
説明

この属性は、「申請提出済み」、「コンプライアンスレビュー開始」、「申請却下済み」などのビジネス活動またはシステムイベントの名前を記録します。これは、顧客オンボーディングプロセス全体の単一のステップを表します。

活動の分析はプロセスマイニングの核です。この属性は、異なるステップ間のフローを示すプロセスマップを構築するために使用されます。これにより、イベントの順序を特定し、各活動の頻度を測定し、どのタスクが最も一般的または時間のかかるものかを特定するのに役立ちます。

その重要性

この属性はプロセスマップのステップを定義し、プロセスフローの可視化、分析、理解を可能にします。

取得元

この情報は通常、Pegaの監査証跡(履歴テーブル)にキャプチャされるか、ケースのステータス変更から派生できます。

初回スクリーニング実行済みコンプライアンスレビュー完了申請承認済み
開始時刻
EventTime
アクティビティ/イベントの開始を示すタイムスタンプ。
説明

この属性は、活動が開始された正確な日時をキャプチャします。これにより、単一の顧客申請ケース内のすべてのイベントの時系列順序が提供されます。

タイムスタンプは、パフォーマンス関連のプロセス分析の基本です。活動の期間、ステップ間の待機時間、およびオンボーディングプロセスのエンドツーエンドの合計サイクルタイムを計算するために使用されます。このデータは、ボトルネックの特定、SLA遵守の測定、およびプロセス効率の理解のために不可欠です。

その重要性

タイムスタンプは、期間の計算、プロセスパフォーマンスの分析、遅延の特定に必要な時系列コンテキストを提供します。

取得元

これはPegaの監査証跡の標準的な一部であり、各イベントの履歴テーブルでpxTimeCreatedとしてよく見られます。

2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:05:00Z
顧客申請
CustomerApplication
各顧客オンボーディング申請ケースの一意な識別子。
説明

顧客申請は、単一顧客のオンボーディングジャーニーにおけるすべての関連活動とイベントをグループ化する主要なケース識別子です。各申請は提出から承認とアカウント有効化、または却下のいずれかのパスをたどります。

プロセスマイニングにおいて、この属性はすべての申請のエンドツーエンドのジャーニーを再構築するために不可欠です。これにより、アナリストはイベントの完全なシーケンスを閲覧し、各申請のステータスを追跡し、異なるパスを比較できます。この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のユーザープロファイル(オペレーターIDレコード)に関連付けられており、イベントデータと結合できます。プロパティはpyWorkGroupである可能性があります。

初回スクリーニングコンプライアンスレビューアカウント有効化
SLAステータス
SlaStatus
ケースがSLA目標内に完了したかどうかを示します。
説明

この属性は、完了した各ケースを、実際の完了タイムスタンプと「SLA目標日」の比較に基づいて「期限内」または「遅延」に分類します。

これは「SLA遵守状況追跡」ダッシュボードおよび「SLA遵守率」KPIのコアメトリックです。サービスレベルコミットメントに対するパフォーマンスの明確な一目瞭然のビューを提供します。遅延ケースの特性を分析することは、遅延の根本原因を特定し、将来のSLA違反のリスクを軽減するのに役立ちます。

その重要性

コミットメントに対するパフォーマンスを直接測定し、運用管理、コンプライアンス、顧客満足度にとって不可欠です。

取得元

これは、最終ケース活動のタイムスタンプとSlaTargetDateフィールドを比較することで導き出されます。完了時刻が目標よりも遅い場合、ステータスは「遅延」となります。

期日どおり遅延リスクあり
オンボーディング済み製品
OnboardedProduct
顧客が申請している金融商品。
説明

この属性は、顧客がオンボーディングされる製品またはサービス(「リテール銀行口座」、「法人ローン」、「投資サービス」など)を指定します。

製品はオンボーディングプロセスに影響を与える可能性があり、異なる製品は異なる規制要件と複雑さを持つ場合があります。製品別にプロセスを分析することは、特定の製品ラインがより長いサイクルタイムや高い却下率を持つかどうかを特定するのに役立ち、製品固有のプロセス最適化のための洞察を提供します。

その重要性

プロセス分析を製品ライン別にセグメント化し、パフォーマンスの違いと最適化の機会を明らかにできます。

取得元

これはケース上のプロパティで、申請プロセスの開始時に選択されます。

当座預金口座ウェルスマネジメント事業信用枠
ケース種別
CaseType
KYCオンボーディングケースの特定のタイプ。
説明

この属性は、オンボーディング申請を、例えば「個人顧客」、「法人顧客」、または「富裕層個人」のように分類します。異なるケースタイプは、しばしば異なるステップ、SLA、およびリスクプロファイルを持つ独自のプロセスバリエーションに従います。

ケースタイプ別にプロセスを分析することで、より意味のあるパフォーマンス比較が可能になります。特定のタイプのオンボーディングが遅延や却下に陥りやすいかどうかを理解するのに役立ちます。このセグメンテーションは、異なる顧客ジャーニーの特定のニーズに合わせてプロセス改善を調整するために不可欠です。

その重要性

プロセスデータを明確なカテゴリに分割することができ、より正確で関連性の高いパフォーマンス分析を可能にします。

取得元

これは通常、Pegaにおけるケースインスタンスのクラス名、またはそのタイプを定義するケース上の専用プロパティです。

個人オンボーディング法人オンボーディング簡易デューデリジェンス
サイクルタイム
CycleTime
申請提出から最終解決までの経過時間。
説明

この計算メトリックは、各顧客申請のエンドツーエンドの期間を、最初のイベントから最後のイベントまで測定します。通常、特定のケースの最終活動のタイムスタンプと初期活動のタイムスタンプの差として計算されます。

サイクルタイムは、プロセス効率と顧客体験の主要業績評価指標(KPI)です。「全体オンボーディングサイクルタイム分析」ダッシュボードで使用され、平均処理時間を監視し、長期実行中のケースを特定し、時間の経過とともにプロセス改善イニシアチブの影響を追跡します。

その重要性

これは、顧客の視点からオンボーディングプロセス全体の速度と効率を直接測定する重要なKPIです。

取得元

このメトリックは、各ケースIDの最大タイムスタンプと最小タイムスタンプの差を取ることにより、プロセスマイニングツールで計算されます。

5日4時間12日1時間2日8時間
ソースシステム
SourceSystem
`データ`の出所となった`システム`を特定します。
説明

この属性は、イベントが記録されたソースアプリケーションを指定します。このプロセスの場合、値は常に「Pega KYC」となります。

すべてのデータが1つのシステムから来る場合、冗長に思えるかもしれませんが、この属性はデータガバナンスにとって重要であり、複数のシステムからデータを統合する際に不可欠となります。データの出所を明確にし、データ統合の問題のトラブルシューティングに役立ちます。

その重要性

データ発生源に関する不可欠なコンテキストを提供し、データガバナンスを確保し、複数のソースシステム間での分析を可能にします。

取得元

データ抽出・変換の過程で付与する固定値で、データセットのソースを示すラベルとして利用します。

Pega KYCPega CLM
伝票ステータス
DocumentStatus
顧客が提供した書類の現在のステータス。
説明

この属性は、KYCプロセスに必要な書類のステータスを追跡し、「顧客保留中」、「受領済み」、「検証済み」、「却下済み」などの値を取ります。このステータスは、単一のケース内で複数回変更される可能性があります。

これは「オンボーディングスループットとステータス」ダッシュボードおよび「書類確認速度」分析にとって重要な属性です。最も一般的なボトルネック領域の1つを詳細に把握できます。書類が各ステータスに留まる期間を追跡することで、顧客提出または内部レビューにおける遅延を特定できます。

その重要性

文書処理のサブプロセスを可視化し、文書確認における一般的な遅延を特定・解決するのに役立ちます。

取得元

これは、メインケースに関連付けられた関連データオブジェクトまたはページリストのプロパティであり、必要な各書類を追跡します。Pega KYCのドキュメントを参照してください。

アップロード保留中受領済み - レビュー保留中承認済み却下 - 詳細情報が必要
最終データ更新
LastDataUpdate
最終データ更新または抽出のタイムスタンプ。
説明

この属性は、データがソースシステムから抽出された最新の時刻を示します。通常、単一のデータロード内のすべてのレコードで同じです。

このタイムスタンプは、分析されているデータの鮮度を理解するために重要です。これにより、ユーザーはプロセス分析がどれだけ最新であるか、および次のデータ更新がいつ予定されているかを知ることができ、運用監視ダッシュボードにとって不可欠です。

その重要性

データの適時性についてユーザーに通知し、分析が現在の状態を反映しているか、過去の期間を反映しているかを確実に理解させます。

取得元

この値は、データ抽出、変換、ロード(ETL)プロセス中に生成され、データセットに付与されます。

2023-11-01T02:00:00Z2023-11-02T02:00:00Z
処理時間
ProcessingTime
待機時間を除いた、単一の活動の期間。
説明

このメトリックは、イベントのアクティブな作業時間を、終了時刻と開始時刻の差として測定します。これは、リソースがタスクに積極的に従事していた時間を表します。

処理時間(アクティビティのサイクルタイムとしても知られる)は、詳細なパフォーマンス分析に不可欠です。これにより、長いタスク(高い処理時間)と長いキュー(高い待機時間)を区別するのに役立ちます。これにより、タスクを高速化するためのより良いツールを提供したり、キューを削減するためにリソースを再割り当てしたりするなど、より的を絞った改善努力が可能になります。

その重要性

活動のアクティブな作業期間を測定し、非効率なタスクとリソースまたはキューイングの問題を区別するのに役立ちます。

取得元

このメトリックは各イベントに対して(終了時刻 - 開始時刻)として計算されます。両方のタイムスタンプフィールドが利用可能である必要があります。

15分4時間30分2日
手戻り
IsRework
アクティビティが手戻りループの一部であるかを示すフラグ。
説明

このブール属性は、「書類レビュー」などの特定の活動が同じケース内で複数回発生した場合にtrueとなります。これは「追加情報要求」のようなイベントによってトリガーされることがよくあります。

手戻りを特定することは、プロセス非効率性や顧客にとっての摩擦点を特定するために不可欠です。「プロセス手戻りおよびループ」ダッシュボードは、この属性を使用して手戻りの頻度と影響を定量化します。手戻りを削減することは、処理の高速化、運用コストの削減、顧客体験の向上につながるため、重要な目標となることがよくあります。

その重要性

プロセスの非効率性、重複するタスク、およびループを強調します。これらはプロセス改善の主要なターゲットです。

取得元

このフラグは、データ分析中に、同じケースID内で繰り返される活動名がないかをチェックすることで派生されます。例えば、「書類レビュー完了」が2回目に現れた場合などです。

truefalse
自動化
IsAutomated
アクティビティがシステムまたは人間によって実行されたかを示すフラグ。
説明

このブール属性は、活動がスクリーニングエンジンやシステムルールなどの自動エージェントによって実行された場合はtrueとなり、人間ユーザーによって実行された場合はfalseとなります。

自動化された活動と手動活動を区別することは、自動化分析にとって重要です。既存の自動化の効果を測定し、将来の自動化に適した手動タスクを特定し、プロセスにおける人間とシステムアクター間の相互作用を理解するのに役立ちます。

その重要性

人間主導の活動とシステム主導の活動を分離します。これは、あらゆる自動化イニシアチブや分析の基本です。

取得元

これはイベントに関連付けられたユーザーIDから派生できます。OperatorIdが既知のシステムまたはエージェントアカウントに対応する場合、このフラグはtrueに設定されます。

truefalse
顧客ID
CustomerId
オンボーディング対象の顧客の一意な識別子。
説明

この属性は、申請をマスターデータシステム内の顧客レコードにリンクする一意のIDです。個人または組織のいずれであっても、KYCプロセスの対象となるエンティティを表します。

申請IDがプロセスを追跡する一方で、顧客IDは同じ顧客からの複数の申請にわたる分析を可能にし、またはセグメントや履歴のような顧客固有の属性でプロセスデータを充実させることができます。これにより、オンボーディングプロセスの顧客中心のビューが可能になります。

その重要性

プロセスデータを顧客マスターデータに接続し、顧客属性と履歴に基づいたより詳細な分析を可能にします。

取得元

これはKYCケースのコアプロパティであり、Pega内の顧客データモデルまたは外部CRMにリンクします。

CUST-98765CUST-98766CUST-98767
顧客国
CustomerCountry
顧客の居住国または設立国。
説明

この属性は、オンボーディング対象の顧客に関連する国を格納します。この情報は、リスク評価および必要なデューデリジェンスレベルの決定における重要な入力です。

分析において、顧客の国は重要なパターンを明らかにすることができます。特定の管轄区域は、より高いリスクに関連付けられている可能性があり、より長く複雑なオンボーディングプロセスにつながります。この側面は、地理ベースのパフォーマンス分析を可能にし、地域のコンプライアンス要件が効率的に満たされていることを保証するのに役立ちます。

その重要性

プロセスの地理的分析を可能にし、これはしばしば規制の複雑さやリスクレベルと関連しています。

取得元

これはケースに関連付けられた顧客データオブジェクトのプロパティです。

米国DEUSGPGBR
必須 推奨 任意

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システムで新しい顧客オンボーディングケースが作成されたことを示します。顧客ポータル、内部ユーザー、または自動データフィードを通じて、顧客申請の新しいケースインスタンスが正式に開始されたときにキャプチャされます。
その重要性

これはオンボーディングプロセス全体の主要な開始イベントです。エンドツーエンドのサイクルタイムを測定し、申請提出の量とパターンを分析するために不可欠です。

取得元

これは、新しいワークオブジェクト(ケース)が作成されたときにPegaの監査証跡でキャプチャされる明示的なイベントです。ケースIDについては、pc_history_workテーブルの最初の項目を確認してください。

取得

pc_workテーブルのケース作成タイムスタンプまたは監査履歴の最初の項目から取得されます。

イベントタイプ explicit
書類受領
顧客が要求されたすべての書類をシステムにアップロードまたは提供した時点を示します。これは通常、新しい添付ファイルがPegaケースにリンクされた際の明示的なイベントとして捕捉されます。
その重要性

これは、書類レビューと検証のSLAの開始を告げる重要なマイルストーンです。この時点より前の遅延は顧客に依存し、この時点より後の遅延は内部的なものです。

取得元

新しいドキュメントがケースに関連付けられたときに、Pegaの添付ファイルテーブル(pc_link_attachmentまたはpc_data_workattach)に明示的に記録されます。

取得

イベントは、ケースにリンクされた関連する添付オブジェクトの作成タイムスタンプです。

イベントタイプ explicit
申請却下
顧客の申請を却下し、オンボーディングプロセスを終了する最終決定を表します。このイベントは、ケースが最終的な失敗解決ステータスに移行したことから推測されます。
その重要性

これは主要な失敗終了イベントです。申請却下率を分析し、「却下理由」などの属性を通じて失敗の原因を理解するために重要です。

取得元

ケース解決ステータス(pyStatusWork)が「Resolved-Rejected」などの最終的な失敗値に設定されたタイムスタンプから推測されます。

取得

ケースの監査履歴において却下ステータスを反映するpyStatusWorkの最終更新を特定します。

イベントタイプ inferred
申請承認済み
顧客のオンボーディング申請を承認する最終決定を表します。これは重要なビジネスのマイルストーンであり、ケースのステータスが最終的な成功解決状態に更新されたことから推測されます。
その重要性

これは、成功したケースと失敗したケースを分ける重要なマイルストーンです。最終的なアカウント有効化ステップの前段階であり、意思決定時間を測定する一般的なポイントです。

取得元

ケース解決ステータス(pyStatusWork)が「Resolved-Completed」または「Resolved-Approved」などの最終的な成功値に設定されたタイムスタンプから推測されます。

取得

ケースの監査履歴において成功した解決を反映するpyStatusWorkの最終更新を特定します。

イベントタイプ inferred
アカウント有効化済み
この活動は、顧客のアカウントがコアバンキングまたは関連する下流システムで正常に作成および有効化されたことを示します。これは、承認成功後のPegaケースにおける最終ステータス更新から推測されることがよくあります。
その重要性

顧客とビジネスにとっての「価値」が生まれる瞬間を表します。「申請承認済み」からこのイベントまでの時間は、システム連携の効率性を測ります。

取得元

監査履歴に記録されているように、「Resolved-AccountActive」のような特定のケースステータス(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」または類似の状態に変わったことから推測されます。明示的な「連絡送信」イベントに関連付けられることもあります。

イベントタイプ inferred
身元調査を開始しました
顧客に対する外部または内部のバックグラウンドチェックの開始を表します。これには第三者サービスとの連携が含まれる場合があります。これは通常、ケースがこれらのチェック結果を待っていることを示すステータス変更から推測されます。
その重要性

この活動は、外部依存関係に対する待機時間を分離するのに役立ちます。これにより、第三者サービスのパフォーマンスとそれがオンボーディング時間全体に与える影響の分析が可能になります。

取得元

PegaのHistory-Workテーブルに記録されているように、ケースステータス(pyStatusWork)が「Pending-Background-Check」または同様の状態に変化したことから推測されます。

取得

バックグラウンドチェックプロセスが開始されたことを示すようにpyStatusWorkが更新されたタイムスタンプを特定します。

イベントタイプ inferred
追加情報の依頼
通常、コンプライアンス担当者であるレビュー担当者が、顧客からより多くの情報や説明を必要とする場合に発生します。このイベントは多くの場合明示的であり、ユーザーがケースから特定の通信を送信したときに記録されます。
その重要性

この活動は、プロセス手戻りやループの主要な指標です。その頻度を追跡することは、初回通過処理率を測定し、不明確な要件を特定するために不可欠です。

取得元

監査証跡に記録された明示的な「連絡の送信」イベントである可能性があります。あるいは、「Pending-Customer-Info」へのステータス変更から推測することもできます。

取得

ケースワーカーによって開始された特定の通信オブジェクトまたはフローアクションの作成から取得されます。

イベントタイプ explicit
推奨 任意

抽出ガイド

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