あなたのKYC顧客オンボーディングデータテンプレート

Fenergo
あなたのKYC顧客オンボーディングデータテンプレート

あなたのKYC顧客オンボーディングデータテンプレート

このテンプレートは、Fenergoデータを効果的なプロセス分析のために準備するのに役立つように設計されています。KYC顧客オンボーディングプロセス全体で収集する必要がある必須データ属性と追跡すべき主要な活動を概説しています。さらに、このデータを抽出するための実用的なガイダンスも提供されており、運用最適化を円滑に開始できます。
  • 収集を推奨する項目
  • 追跡すべき主要アクティビティ
  • データ抽出のガイダンス
イベントログについて初めての方へ: プロセスマイニングのイベントログ作成方法.

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

これらは、Fenergo内での包括的なKYC顧客オンボーディング分析のためにイベントログに含めることが推奨されるデータフィールドであり、プロセスへの深い洞察を可能にします。
5 必須 6 推奨 11 任意
名前 説明
アクティビティ名
ActivityName
オンボーディングプロセス内の特定の時点で発生したビジネスイベントまたはタスクの名前。
説明

Activity Name(活動名)は、「初期スクリーニング実施済み」や「申請承認済み」など、顧客オンボーディングジャーニーにおける単一のステップまたはマイルストーンを記述します。この活動のシーケンスがプロセスマップの基礎となります。

この属性を分析することで、プロセスフローの可視化、一般的および代替パスの特定、各ステップの頻度の測定が可能になります。どのようなアクションがどのような順序で実行されているかを理解するために不可欠です。

その重要性

この属性はプロセスのステップを定義し、プロセスマップの作成やプロセスフローとバリエーションの分析を可能にします。

取得元

この情報は通常、Fenergoのワークフローまたは監査ログテーブルに、ケースステートの遷移やタスク完了に関連付けられて見つかります。

データと書類を要求済みコンプライアンス審査開始申請承認済み
開始時刻
EventStartTime
活動またはイベントが正式に開始されたことを示すタイムスタンプ。
説明

この属性は、特定の活動が開始された正確な日時を記録します。プロセスフローを再構築するために必要な時系列順序を提供し、すべての時間ベースの分析に不可欠です。

プロセスマイニングでは、開始時刻は活動の期間、活動間の待機時間、およびケース全体のサイクルタイムを計算するために使用されます。これはイベントログの時間的な基盤を形成し、パフォーマンスとボトルネック分析にとって極めて重要です。

その重要性

このタイムスタンプは、イベントを時系列順に並べ、サイクルタイムや期間などのすべての時間ベースのメトリックを計算するために不可欠です。

取得元

Fenergoの監査証跡、イベントログ、またはワークフロー履歴テーブルにあり、しばしば「タイムスタンプ」、「開始日」、または「作成日」とラベル付けされています。

2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z
顧客申請
CustomerApplication
単一の顧客オンボーディングジャーニーの一意の識別子であり、主要なケース識別子として機能します。
説明

Customer Application(顧客申請)は、単一の顧客のKYCオンボーディングプロセスに関連するすべての活動とイベントをグループ化する中心的な識別子です。これにより、最初の提出から最終的な解決(承認、却下、または終了)までの申請のエンドツーエンドの追跡が可能になります。

プロセスマイニングにおいて、この属性は各申請の完全なジャーニーを再構築するための基本的なものです。これにより、申請ごとのプロセスフロー、サイクルタイム、バリエーション、およびボトルネックの分析が可能になり、個々のケースがどのように処理されているかを明確に把握できます。

その重要性

これは、関連するすべてのイベントを接続する不可欠なケースIDであり、エンドツーエンドの顧客オンボーディングプロセスを分析することを可能にします。

取得元

これは通常、Fenergoのコアケース管理またはクライアントライフサイクル管理エンティティにおける主キーです。

APP-2023-00123APP-2023-00124APP-2023-00125
ソースシステム
SourceSystem
`データ`が抽出された記録システム。
説明

この属性は、イベントデータの発生元システムを識別します。このプロセスでは常にFenergoですが、結合されたデータセットではデータソースの区別を助けます。

分析における主な用途は、特定のシステムからのデータをフィルタリングしたり、データの出所を検証したりすることです。複数のシステムからのデータが統合され、全体的なプロセスビューが求められる環境で、明確性を確保します。

その重要性

データの出所を特定します。これはデータガバナンス、検証、そして分析が正しいソースに基づいていることを保証するために不可欠です。

取得元

これは通常、データ抽出プロセス中に、レコードの出所を示すために追加される静的な値です。

FenergoFenergo CLM
最終データ更新
LastDataUpdate
この`プロセス`の`データ`が最後に更新または抽出された日時を示す`タイムスタンプ`。
説明

この属性は、最も新しいデータ更新の日時を記録します。分析されているデータの鮮度に関するコンテキストを提供し、洞察の適時性を理解するために重要です。

ダッシュボードやレポートでは、この情報はユーザーにデータの最新性について通知するために使用されます。分析がリアルタイムの運用を反映しているのか、それとも過去のスナップショットであるのかについて、期待値を管理するのに役立ちます。

その重要性

データの鮮度に関する重要なコンテキストを提供し、ユーザーがプロセスの分析がどれだけ最新であるかを理解できるようにします。

取得元

この値は、データ抽出およびロード(ETL)プロセス中にデータセットに生成され、スタンプされます。

2024-05-21T02:00:00Z2024-05-22T02:00:00Z
`ユーザー部署`
UserDepartment
開始ユーザーが所属する部署またはビジネスユニット。
説明

この属性は、「コンプライアンス」、「オンボーディング業務」、「営業」など、活動を実行したユーザーの組織的コンテキストを提供します。多くの場合、ユーザープロファイル情報から派生します。

このディメンションは、異なる部門間のプロセス引き渡しを分析し、部門横断的なボトルネックを特定するために重要です。チームまたは部門レベルでの作業の集計を可能にすることで、「スタッフ活動分布」ダッシュボードを直接サポートします。

その重要性

部門ごとのプロセスパフォーマンス分析を可能にし、部門間の引き継ぎ、遅延、ワークロードの分散を明確にします。

取得元

これは、「InitiatingUser」IDを使用して別のユーザーまたは人事マスターデータテーブルから結合する必要がある場合があります。Fenergoは、これをユーザーのプロファイルの一部として保存することもあります。

Compliance顧客オンボーディング品質保証
SLA目標日
SlaTargetDate
顧客オンボーディングケースが完了する予定日。
説明

SLA Target Date(SLA目標日)は、顧客申請のオンボーディングプロセス全体を完了するための合意された期限を表します。これは、実際のパフォーマンスを測定するための重要なベンチマークです。

この属性は、「SLAコンプライアンス監視」ダッシュボードと「SLA達成率」KPIの計算に不可欠です。SLA違反のリスクがあるケースをプロアクティブに管理し、作業の優先順位付けに役立ちます。

その重要性

SLA遵守の監視と期限切れケースの優先順位付けに不可欠な、目標完了日を定義します。

取得元

この日付は、多くの場合、申請提出日とFenergoのSLA管理モジュール内で設定されたビジネスルールに基づいて計算されます。

2023-11-15T23:59:59Z2023-12-01T23:59:59Z
リスクスコア
RiskScore
顧客の計算されたリスクレベルを表す数値スコアです。
説明

Risk Score(リスクスコア)は、管轄区域、業界、スクリーニング結果など、さまざまな要因に基づいて計算される顧客に関連する潜在的リスクの定量的尺度です。Fenergoのルールエンジンが通常このスコアを計算します。

この属性により、リスクレベルとプロセス動作の相関関係を分析できます。例えば、高リスクの顧客がより長いサイクルタイムを経験したり、より多くの手動介入を必要としたりするかどうかを分析で明らかにでき、「リスク&コンプライアンスレビュー深掘り」ダッシュボードに役立ちます。

その重要性

顧客のリスクを定量化し、リスクレベルがプロセス期間、手戻り、結果にどのように影響するかを分析できるようにします。

取得元

これはFenergoのクライアントリスク評価モジュールの主要な出力です。ケースまたはクライアントエンティティに保存されます。

154585
申請ステータス
ApplicationStatus
顧客申請の現在または最終的な結果。
説明

この属性は、プロセスの終了時における申請の処理結果、または進行中の場合は現在の状態を示します。一般的な値には、「承認済み」、「却下済み」、または「進行中」が含まれます。

これは結果分析にとって重要なディメンションです。最終結果に基づいてプロセスフローをフィルタリングおよび比較することを可能にし、「申請手戻りおよび却下」ダッシュボードや申請却下率などのKPI計算に不可欠です。

その重要性

ケースの結末を定義し、承認された申請と却下された申請の経路を比較し、成功率を理解するための強力な分析を可能にします。

取得元

これは通常、Fenergoのケース管理システムにおけるケースエンティティに記録される最終ステータスです。

承認済み却下コンプライアンス待ちクローズ
終了日時
EventEndTime
アクティビティまたはイベントが完了した時点を示すタイムスタンプ。
説明

この属性は、特定の活動が完了した正確な日時を記録します。これは開始時刻を補完し、タスクのアクティブな期間を定義します。

プロセスマイニングでは、終了時刻は開始時刻とともに使用され、各活動の処理時間を計算します。これは、プロセス内のどのステップが最も時間を消費しているかを特定し、リソース効率を分析するために不可欠です。

その重要性

アクティビティの処理時間の計算を可能にし、実行時間の長いタスクやパフォーマンスのボトルネックを特定するための基本的な情報となります。

取得元

Fenergoの監査証跡またはワークフロー履歴テーブルにあり、しばしば「EndDate」、「CompletionDate」とラベル付けされているか、後続イベントの開始時間から派生します。

2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z
開始ユーザー
InitiatingUser
そのアクティビティを実行した担当者のユーザーIDまたは氏名を示します。
説明

この属性は、特定のタスクまたはイベントを実行する責任のある特定の従業員またはシステムユーザーを識別します。一意のユーザーID、名前、または役割である場合があります。

ユーザーによる分析は、ワークロードの分散、個人のパフォーマンス、およびトレーニングニーズの特定を理解するのに役立ちます。これは「スタッフ活動分布」ダッシュボードにとって重要であり、特定の個人やチームによって実行された活動をドリルダウンするために不可欠です。

その重要性

どのユーザーがアクションを実行したかを追跡し、ワークロードの分散、チームのパフォーマンス、リソースの割り当ての分析を可能にします。

取得元

この情報は通常、Fenergoの監査ログまたはタスク履歴テーブルにイベント詳細とともに保存され、多くの場合「UserID」、「UserName」、または「ModifiedBy」として記録されます。

j.doea.smithSYSTEM
SLA準拠
IsSlaCompliant
ケースがSLA目標日内に完了したかどうかを示すブール値フラグです。
説明

この属性は、完了したケースのSLAパフォーマンスを示すバイナリインジケータです。最終的なクローズ活動のタイムスタンプがSlaTargetDate以前である場合は「true」に、それ以外の場合は「false」に設定されます。

この計算フィールドは、SLAの監視とレポート作成を簡素化します。全体の「SLA達成率」KPIを簡単に集計し、準拠ケースと非準拠ケースのプロセス特性を分析するためのフィルタリングを可能にします。

その重要性

SLAパフォーマンスを直接測定し、SLA遵守率KPIの簡単な計算と、非準拠ケースのフィルタリングを可能にします。

取得元

これは、最終ケース活動(例:「申請承認済み」、「申請却下済み」)のタイムスタンプとSlaTargetDateを比較することで導出されます。

truefalse
ケース所有者
CaseOwner
アプリケーションのライフサイクルを通じて管理する主要なユーザーまたはチーム。
説明

Case Owner(ケースオーナー)は、オンボーディングケースの主要な責任を割り当てられた個人またはグループです。通常、この担当者はケースの期限内での完了と成功に責任を負います。

この属性は、ケースマネージャーレベルでのワークロードとパフォーマンスを分析するのに役立ちます。特定のケースオーナーがより長いサイクルタイムや高い却下率を持っているかどうかを確認するために使用でき、トレーニングの必要性やリソースの不均衡を示している可能性があります。

その重要性

ケースの担当者またはチームを特定し、ケースマネージャーのパフォーマンス分析を可能にします。

取得元

これは通常、Fenergoの主要なケースエンティティ上の特定のフィールドであり、ケースの割り当てを示します。

s.jonesオンボーディングチームAm.chen
処理時間
ProcessingTime
アクティビティに実作業として費やした時間。
説明

処理時間(アクティブタイムとも呼ばれる)は、単一のアクティビティの開始タイムスタンプと終了タイムスタンプの間の計算された期間です。これは、リソースがタスクに積極的に従事していた時間を表します。

この指標はパフォーマンス分析の基礎となります。ボトルネック分析ダッシュボードで使用され、どの特定のアクティビティが最も時間を消費しているかを正確に特定し、最大の効果が得られる改善努力に焦点を当てるのに役立ちます。

その重要性

この計算メトリックは、各活動のアクティブな作業時間を測定し、パフォーマンスのボトルネックを特定するのに不可欠です。

取得元

「EventEndTime」と「EventStartTime」の差(EndTime - StartTime)として計算されます。

86400000360000018000000
却下理由
RejectionReason
申請が却下された理由を説明するコードまたは説明文です。
説明

申請の最終ステータスが「却下」の場合、この属性は具体的な理由を提供します。例としては、「バックグラウンドチェック失敗」、「書類不備」、または「高リスクプロファイル」などが挙げられます。

これは、失敗した申請の根本原因分析にとって不可欠な属性です。「申請手戻りおよび却下」ダッシュボードを直接サポートし、失敗を分類することで、ビジネスが共通の問題を特定し、初回パス率を向上させるための是正措置を実施するのに役立ちます。

その重要性

申請が失敗する理由に関する重要な洞察を提供し、却下率を削減するための根本原因分析を可能にします。

取得元

通常、Fenergoのケースワークフローにおける最終的な却下ステータスに関連付けられた理由コードまたは備考フィールドに見つかります。

制裁対象一致無効な書類ポリシー違反顧客が取り下げた
Country
顧客申請の居住国または管轄国。
説明

この属性は、顧客に関連付けられた国を指定します。これは多くの場合、オンボーディングプロセスに適用される特定の規制ルールとリスク要因を決定します。

国別にプロセスを分析することで、サイクルタイム、リスクレベル、プロセス複雑性の管轄区域ごとの比較が可能になります。これにより、地域差が運用パフォーマンスにどのように影響するかを理解し、現地の規制へのコンプライアンスを確保するのに役立ちます。

その重要性

地理に基づいたプロセスセグメンテーションを可能にし、規制の影響と地域ごとのパフォーマンスを分析するための鍵となります。

取得元

この情報は、申請プロセス中に取得され、Fenergoのクライアントエンティティに保存される顧客コアデータの一部です。

米国GBRSGPDEU
手戻り
IsRework
アクティビティが手戻りループの一部であるかを示すブール値フラグです。
説明

この属性は、「コンプライアンスレビュー」が既に開始された後に「書類レビュー」に戻るなど、プロセスにおける後戻りを表す活動、または「追加情報要請」の発生を特定します。

手戻りの特定は、プロセスの非効率性や摩擦を理解するために不可欠です。このフラグにより、「手戻りループ率」KPIを直接計算でき、プロセスフローにおける無駄な反復ステップの影響を可視化し、定量化するのに役立ちます。

その重要性

プロセス内の非効率な手戻りループを明らかにし、無駄を定量化し、初回正確率を高めるための改善領域を特定するのに役立ちます。

取得元

このフラグは、活動のシーケンスを分析するプロセスマイニング技術を使用して導出されます。例えば、「活動A」の後に「活動B」が続き、その後同じケースで再び「活動A」が現れる場合、2番目の「活動A」は手戻りです。

truefalse
申請チャネル
ApplicationChannel
顧客の申請が提出されたチャネル。
説明

この属性は、オンラインポータル、支店、またはリレーションシップマネージャーを介してなど、申請の提出元を識別します。提出元は、データ品質と処理要件に影響を与える可能性があります。

このディメンションは、「申請元と種類別の効率性」ダッシュボードで使用され、異なるチャネルのパフォーマンスを比較します。これにより、企業はどのチャネルが最も効率的であるか、そしてどのチャネルがプロセス最適化を必要とするかを理解するのに役立ちます。

その重要性

申請の出所を特定し、チャネルの効率性、コスト、顧客体験の分析を可能にします。

取得元

この情報は、Fenergo内の初期データ入力フォームで取得されるか、または上流システムから渡される場合があります。

オンラインポータル拠点リレーションシップマネージャーモバイルアプリ
自動化
IsAutomated
アクティビティが人間ではなくシステムによって実行されたかどうかを示すブール値フラグです。
説明

この属性は、システムによって自動的に実行されるタスク(例:初期スクリーニング、システムチェック)と、ユーザーによって手動で実行されるタスクを区別します。これは多くの場合、実行ユーザーがシステムアカウントかサービスアカウントかをチェックすることで決定されます。

このフラグの分析は、プロセスにおける自動化のレベルを理解するために非常に重要です。自動化が効率、コスト、速度に与える影響を定量化し、さらなる自動化の機会を特定するのに役立ちます。

その重要性

人間による活動とシステムによる活動を区別することで、自動化分析とリソースコストの理解に不可欠です。

取得元

これは通常、「InitiatingUser」フィールドに基づいて導出されます。既知のシステムユーザーIDのリストを使用して、このフラグをtrueに設定します。

truefalse
追加情報要求回数
AdditionalInfoRequestCount
申請に対して追加情報が要求された合計回数。
説明

このメトリックは、各ケースにおける「追加情報要求」活動の発生回数をカウントします。カウントが高いほど、より多くのやり取りが発生し、プロセスを遅延させ、劣悪な顧客体験につながる可能性があります。

この属性は、「追加情報要求のあるケース」KPIを直接サポートします。過剰な要求のある申請を特定するために使用され、初期データ収集の問題や複雑なケース要件を示す可能性があります。これを分析することで、情報収集の合理化に役立ちます。

その重要性

初期情報の不備によって生じる顧客の負担やプロセス遅延を定量化し、データ収集ステップの改善を支援します。

取得元

これは、「CustomerApplication」IDごとの「追加情報要求」イベントの数をカウントして導出される計算メトリックです。

013
顧客ID
CustomerId
オンボーディングされる顧客または法人を表す固有の識別子です。
説明

Customer ID(顧客ID)は、マスターデータシステムにおけるクライアントエンティティの一意の参照です。申請番号がプロセスのケースIDである一方、顧客IDはオンボーディング活動を特定のクライアントにリンクさせます。

この属性は、単一の顧客のオンボーディング履歴を分析するのに役立ちます。例えば、顧客が時間の経過とともに複数のオンボーディングプロセスを経験している場合などです。また、プロセスデータと他の顧客関連データを結合して、より包括的なビジネスビューを実現することも可能です。

その重要性

オンボーディングプロセスを固有の顧客エンティティにリンクさせ、顧客中心の分析とデータエンリッチメントを可能にします。

取得元

このIDは、Fenergo内のクライアントまたは法人エンティティレコードに保存され、オンボーディングケースに関連付けられています。

CUST-98765CUST-98766CUST-98767
顧客タイプ
CustomerType
オンボーディングされる顧客の分類。例:個人、法人、信託。
説明

この属性は、顧客を法的構造や金融機関との関係に基づいて異なるカテゴリに分類します。顧客タイプが異なると、オンボーディングパスも異なり、複雑さやデューデリジェンスの要件も様々です。

顧客タイプ別にプロセスを分析することで、セグメント間のパフォーマンスの違いを特定できます。これは「申請元と種類別の効率性」ダッシュボードにとって重要であり、サイクルタイムと承認率を比較して、個別のプロセス改善につながります。

その重要性

異なる顧客セグメント間でのプロセスパフォーマンスの比較を可能にします。これは、複雑さやSLAが異なることが多いため重要です。

取得元

この情報は通常、Fenergo内の顧客またはクライアントエンティティに保存され、申請ケースにリンクされます。

個人法人信託提携
必須 推奨 任意

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

これらは、正確な`プロセス`ディスカバリと分析のために`イベントログ`に記録すべき主要な`プロセス``ステップ`と`マイルストーン`です。
8 推奨 6 任意
アクティビティ 説明
コンプライアンス審査完了
コンプライアンス部門による正式な承認を示し、すべての規制要件が満たされたことを意味します。これはタスク完了、または「コンプライアンス承認済み」へのステータス変更から推測されます。
その重要性

主要なマイルストーンとして、このアクティビティの完了は全体のサイクルタイムにとって非常に重要です。「平均コンプライアンス審査時間」を測定し、コンプライアンス機能内のボトルネックを特定するための終点となります。

取得元

Fenergoワークフロー内の「コンプライアンス審査」タスクの完了タイムスタンプ、またはケース履歴内のステータス更新イベントから推測されます。

取得

コンプライアンスレビュータスクの完了またはステータス更新のタイムスタンプを使用します。

イベントタイプ inferred
コンプライアンス審査開始
この活動は、コンプライアンス部門によるレビューの開始を示します。これは重要でしばしば長期間にわたる段階です。ケースがコンプライアンスワークキューに割り当てられたり、そのステータスが「コンプライアンスレビュー保留中」に変わったりしたときに推測されます。
その重要性

この活動は、「平均コンプライアンスレビュー時間」KPIを測定するための出発点です。コンプライアンスチームが実際に作業を開始するまでにケースがどれだけ待機するかを特定するのに役立ちます。

取得元

Fenergoケース監査ログから、「コンプライアンス審査中」へのステータス変更、またはケースがコンプライアンス担当者やチームに割り当てられた際のタイムスタンプをキャプチャして推測されます。

取得

「コンプライアンス審査中」へのステータス変更、または割り当てイベントのタイムスタンプを特定します。

イベントタイプ inferred
リスク評価完了
顧客にさまざまな要因に基づいてリスク評価が割り当てられる、内部リスク分類プロセスの完了を表します。これはステータス変更またはリスク評価フィールドへの入力から推測されます。
その重要性

これは、その後のワークフローパスを決定することが多い重要な意思決定マイルストーンです。その期間を分析することで、重要なコンプライアンスステップを合理化し、リスク評価の一貫性を確保するのに役立ちます。

取得元

ケース履歴ログから、ケースが「リスク評価済み」のようなステータスに移行した時、または最終的な「顧客リスク評価」フィールドに値が入力された時を特定して推測されます。

取得

リスク評価フィールドが確定された、または関連するステータスが設定されたタイムスタンプを使用します。

イベントタイプ inferred
書類審査完了
提出されたすべての顧客書類の真偽と正確性を検証する手動または自動プロセスの完了を示します。このイベントは通常、ワークフロータスクの完了またはFenergoでのステータス変更から推測されます。
その重要性

これは多くの遅延が発生する重要なマイルストーンです。この活動の期間と結果を分析することで、書類処理におけるボトルネックを特定し、「初回パス率」などのKPIをサポートするのに役立ちます。

取得元

ケースワークフローにおける「書類確認」タスクの完了タイムスタンプ、またはケース履歴ログにおける「書類承認済み」へのステータス更新から推測されます。

取得

書類レビュータスクの完了タイムスタンプまたは関連するステータス変更を使用します。

イベントタイプ inferred
案件クローズ
これは最終活動であり、オンボーディングケースがFenergoで事務的にクローズされ、それ以上の措置は不要であることを示します。承認済みおよび却下済みの両方の申請に適用され、最終的な「クローズ済み」ステータスから推測されます。
その重要性

この活動は、プロセス全体の決定的な終点として機能します。結果に関係なく、すべてのケースの正確なサイクルタイム計算を保証し、プロセスが完了したことを確認します。

取得元

Fenergoケース監査ログから、ケースステータスが「クローズ済み」、「完了済み」、またはその他の最終状態に設定された際のタイムスタンプを特定して推測されます。

取得

最終ステータスの「クローズ済み」または「完了済み」への変更タイムスタンプを特定します。

イベントタイプ inferred
案件作成
この活動は、Fenergoで新規顧客申請が正式に作成された際にKYCオンボーディングプロセスの開始を示します。通常、ケースレコードが最初に保存されたときに特定のタイムスタンプとともに記録される明示的なイベントです。
その重要性

開始イベントとして、このアクティビティは全体のオンボーディングサイクルタイムの計算とスループット分析に不可欠です。これは、その後のすべてのプロセス測定とSLA追跡のベースラインを提供します。

取得元

これは通常、Fenergoの主要なケースエンティティの作成タイムスタンプから取得され、多くの場合、クライアントオンボーディングケースまたはワークフローに関連するテーブルで見つかります。

取得

オンボーディングケースレコードの作成タイムスタンプを使用します。

イベントタイプ explicit
申請却下済み
この活動は、顧客の申請を却下するという最終決定を表す終端イベントです。ケースステータスが最終的な「却下」または「拒否」状態に変化することから推測されます。
その重要性

主要なプロセス終点として、このアクティビティは「申請却下率」の計算と失敗理由の分析に不可欠です。これにより、一般的な却下ポイントを特定し、申請の品質を向上させるのに役立ちます。

取得元

ケース監査ログから、最終ステータスが「却下済み」に変わった際のタイムスタンプをキャプチャして推測されます。却下理由は関連フィールドに保存されていることが多いです。

取得

最終ステータスの「却下済み」への変更タイムスタンプを特定します。

イベントタイプ inferred
申請承認済み
この活動は、顧客のオンボーディング申請を承認するという最終決定を表します。ケースステータスが最終的な「承認済み」または「オンボーディング承認済み」状態に変化することから推測されます。
その重要性

この重要なマイルストーンは、最終的なアカウントアクティベーションステップの前の成功した結果を示します。承認率を計算し、正常にオンボーディングされた顧客の特性を分析するために不可欠です。

取得元

ケース履歴または監査ログから、「承認済み」または同様の最終的な肯定的なステータスへの変更のタイムスタンプを見つけることで推測されます。

取得

最終ステータスの「承認済み」への変更タイムスタンプを特定します。

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

この活動は、オンボーディングプロセスから顧客のアクティブステータスへの引き渡しが成功したことを確認します。承認からアクティベーションまでの時間を測定することで、運用設定の遅延が明らかになることがあります。

取得元

これは、「アカウント有効」や「オンボーディング完了」などのケースステータスから推測できます。また、ダウンストリームシステムとの連携によってログに記録された明示的なイベントである可能性もあります。

取得

承認後のステータス変更、または統合成功ログイベントを探します。

イベントタイプ inferred
データと書類を要求済み
このイベントは、システムまたはオンボーディングエージェントが顧客から必要な情報と書類を正式に要求したことを示します。通常、標準化されたコミュニケーションテンプレートが送信された際に明示的なイベントとしてキャプチャされます。
その重要性

この活動は、顧客に依存するフェーズの開始を示します。この時点から書類が受領されるまでの時間を測定することは、顧客ジャーニーを分析し、コミュニケーションの遅延を特定するために重要です。

取得元

顧客とのコミュニケーションに関連するイベントログ、または「書類請求」のタスク完了ログから取得されます。「顧客情報待ち」へのステータス変更から推測される場合もあります。

取得

顧客コミュニケーションまたはタスク完了のログイベントを探します。

イベントタイプ explicit
バックグラウンドチェック開始済み
この活動は、外部のバックグラウンド、AML、または信用調査がトリガーされる時点を示します。これは多くの場合、サードパーティサービスとの連携が呼び出されたときに記録される明示的なイベントです。
その重要性

これらのチェックの開始と完了を追跡することは、外部依存関係によって引き起こされる遅延を理解するために不可欠です。これにより、内部プロセス時間と外部待機時間を分離するのに役立ちます。

取得元

通常、外部スクリーニングプロバイダーへのAPI呼び出しを記録するシステムログ、またはFenergoケース内で特定の「バックグラウンドチェック」タスクが作成された際に取得されます。

取得

外部サービス連携のログ、または「スクリーニング」タスクの作成ログを探します。

イベントタイプ explicit
初期スクリーニング実施済み
基本的なデータ検証や制裁リストスクリーニングなど、事前の自動または手動チェックの完了を表します。これは多くの場合、Fenergoのケースワークフロー内でのステータス変更、例えば「新規」から「スクリーニング完了」への移行から推測されます。
その重要性

この初期のマイルストーンを追跡することで、事前資格認定段階における初期のデータ品質問題やボトルネックを特定するのに役立ちます。これにより、最初の自動化されたフェーズを、より集中的な手動レビュープロセスから分離します。

取得元

ケース履歴または監査ログから、ケースステータスが「スクリーニング完了」を示す状態、例えば「スクリーニング通過」や「書類待ち」に移行した際のタイムスタンプを特定して推測されます。

取得

ケース履歴から「スクリーニング完了」またはそれに類するステータス変更を特定します。

イベントタイプ inferred
書類受領
この活動は、顧客が必要な書類をアップロードまたは提出し、現在Fenergoでレビュー可能になっていることを示します。これは通常、ケースステータスが「書類受領済み」または「レビュー保留中」に更新されたときに推測されます。
その重要性

これは顧客の待機期間の終了と内部レビューサイクルの開始を示します。顧客の応答時間と内部処理キュー時間を測定するために不可欠です。

取得元

ケース監査証跡から、「書類受領済み」または同様のステータスへの変更のタイムスタンプを記録して推測されます。書類アップロードイベントに関連付けられる場合もあります。

取得

「書類受領済み」または「審査準備完了」へのステータス変更のタイムスタンプを特定します。

イベントタイプ inferred
追加情報の依頼
オンボーディングチームが顧客に説明や不足書類の確認のため再度連絡を取る手戻りのループを表します。これは通常、顧客へ連絡が送信された際に記録される明示的なイベントです。
その重要性

この活動は、プロセスの非効率性と劣悪な顧客体験の主要な指標です。その頻度を追跡することで、手戻りの根本原因を特定し、「手戻りループ率」KPIをサポートするのに役立ちます。

取得元

顧客コミュニケーションのイベントログ、または「追加情報待ち」へのステータス変更から取得されます。前者は正確なリクエストの瞬間を捉える上でより精密です。

取得

記録された顧客コミュニケーションイベントまたは「顧客返答待ち」へのステータス変更を探します。

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

抽出ガイド

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