KYC顧客オンボーディング用データテンプレート
KYC顧客オンボーディング用データテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- データ抽出の手順
KYC顧客オンボーディングの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | オンボーディングプロセスのある時点で発生した、特定の業務イベントまたはタスクの名称です。 | ||
| 説明 アクティビティ名は、「Initial Screening Performed」や「Application Approved」など、顧客オンボーディングの流れにおける1つのステップまたはマイルストーンを表します。これらのアクティビティの順序がプロセスマップの基盤になります。 この属性を分析すると、プロセスフロー、一般的な経路と代替経路を可視化し、各ステップの発生頻度を測定できます。どのアクションがどの順序で実行されているかを理解するうえで欠かせません。 重要な理由 プロセス内のステップを定義する属性であり、プロセスマップの作成、プロセスフローとばらつきの分析に利用できます。 入手先 通常は、ケースの状態遷移またはタスク完了に関連するFenergoのワークフローまたは監査ログのテーブルに保存されています。 例 データと書類の依頼コンプライアンス審査開始申請承認 | |||
| 開始時刻 EventStartTime | アクティビティまたはイベントが正式に開始された時刻を示すタイムスタンプです。 | ||
| 説明 特定のアクティビティが開始された正確な日時を記録する属性です。プロセスフローを再構成するために必要な時系列を提供し、時間に基づくすべての分析に欠かせません。 プロセスマイニングでは、開始時刻を使ってアクティビティの所要時間、アクティビティ間の待機時間、ケース全体のサイクルタイムを計算します。イベントログの時間軸を構成し、パフォーマンスとボトルネックの分析に重要な役割を果たします。 重要な理由 イベントを時系列に並べ、サイクルタイムや所要時間など、時間に基づくすべての指標を計算するうえで重要なタイムスタンプです。 入手先 Fenergoの監査証跡、イベントログ、またはワークフロー履歴のテーブルに保存されています。「Timestamp」、「StartDate」、「CreationDate」などの名称が使われます。 例 2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-10-27T09:15:00Z | |||
| 顧客申請 CustomerApplication | 1件の顧客オンボーディングの流れを一意に識別するIDであり、主要なケース識別子として機能します。 | ||
| 説明 顧客申請は、1人の顧客の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 | |||
| SLA目標日 SlaTargetDate | 顧客オンボーディングのケースを完了する予定日です。 | ||
| 説明 SLA目標日は、顧客申請のオンボーディングプロセス全体を完了するために合意された期限です。実績を測定するための重要な基準になります。 「SLA Compliance Monitoring」ダッシュボードや「SLA Adherence Rate」KPIの計算に欠かせません。SLA違反のリスクがあるケースを事前に管理し、作業の優先順位を付けられます。 重要な理由 目標完了日を定義する属性であり、SLA遵守状況の監視や期限超過ケースの優先順位付けに欠かせません。 入手先 通常は、申請提出日とFenergoのSLA管理モジュールに設定された業務ルールに基づいて計算されます。 例 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| ユーザー部門 UserDepartment | 実行ユーザーが所属する部門または事業部門です。 | ||
| 説明 アクティビティを実行したユーザーの組織上の所属を示す属性です。「Compliance」、「Onboarding Operations」、「Sales」などが該当し、ユーザープロファイルの情報から取得することが多いです。 このディメンションは、部門間のプロセスの引き継ぎを分析し、部門横断のボトルネックを特定するうえで重要です。チームまたは部門単位で業務を集計できるため、「Staff Activity Distribution」ダッシュボードにも直接役立ちます。 重要な理由 部門別にプロセスのパフォーマンスを分析し、部門間の引き継ぎ、遅延、業務量の分布を明らかにできます。 入手先 「InitiatingUser」IDを使い、別のユーザーマスタまたは人事マスタのテーブルと結合する必要がある場合があります。Fenergoのユーザープロファイルに保存されていることもあります。 例 Compliance顧客オンボーディング品質保証 | |||
| リスクスコア RiskScore | 顧客の算定リスクレベルを数値で表したスコアです。 | ||
| 説明 リスクスコアは、管轄区域、業種、スクリーニング結果などのさまざまな要因に基づいて算出される、顧客に関連する潜在的なリスクの定量的な指標です。通常はFenergoのルールエンジンが計算します。 この属性により、リスクレベルとプロセスの動きを関連付けて分析できます。たとえば、高リスク顧客のサイクルタイムが長いか、手動対応が多いかを確認できます。「Risk & Compliance Review Deep Dive」ダッシュボードにも役立ちます。 重要な理由 顧客のリスクを数値化し、リスクレベルがプロセスの所要時間、手戻り、結果に与える影響を分析できます。 入手先 これは、FenergoのClient Risk Assessmentモジュールが生成する主要な出力です。ケースまたは顧客エンティティに保存されます。 例 154585 | |||
| 実行ユーザー InitiatingUser | アクティビティを実行した担当者のユーザーIDまたは氏名です。 | ||
| 説明 特定のタスクまたはイベントを実行した従業員やシステムユーザーを識別する属性です。一意のユーザーID、氏名、または役割が使われます。 ユーザー単位で分析すると、業務量の分布、個人のパフォーマンス、トレーニングの必要性を把握できます。「Staff Activity Distribution」ダッシュボードや、特定の担当者・チームが実行したアクティビティの詳細分析にも役立ちます。 重要な理由 アクションを実行したユーザーを追跡し、業務量の分布、チームのパフォーマンス、リソース配分を分析できます。 入手先 通常は、イベントの詳細とともにFenergoの監査ログまたはタスク履歴のテーブルに保存されています。「UserID」、「UserName」、「ModifiedBy」などの項目名が使われます。 例 j.doea.smithSYSTEM | |||
| 申請ステータス ApplicationStatus | 顧客申請の現在または最終的な結果です。 | ||
| 説明 プロセス終了時の申請結果、または処理中の場合は現在の状態を示す属性です。一般的な値には「Approved」、「Rejected」、「In Progress」などがあります。 結果分析に欠かせないディメンションです。最終結果に基づいてプロセスフローを絞り込み、比較できます。「Application Rework and Rejection」ダッシュボードや、Application Rejection RateなどのKPIの計算にも利用します。 重要な理由 ケースの結果を定義し、承認された申請と却下された申請の経路を比較し、成功率を把握する分析を可能にします。 入手先 通常は、Fenergoのケース管理システムにあるケースエンティティへ記録された最終ステータスです。 例 承認却下コンプライアンス確認待ちクローズ済み | |||
| 終了時刻 EventEndTime | アクティビティまたはイベントが完了した時刻を示すタイムスタンプです。 | ||
| 説明 特定のアクティビティが完了した正確な日時を記録する属性です。開始時刻と組み合わせることで、タスクの実行時間を定義できます。 プロセスマイニングでは、終了時刻と開始時刻を使って各アクティビティの処理時間を計算します。プロセス内で時間を要しているステップや、リソースの効率を分析するうえで欠かせません。 重要な理由 アクティビティの処理時間を計算できるため、長時間を要するタスクやパフォーマンス上のボトルネックを特定する基盤になります。 入手先 Fenergoの監査証跡またはワークフロー履歴のテーブルに保存されています。「EndDate」、「CompletionDate」などの名称が使われるほか、後続イベントの開始時刻から算出する場合もあります。 例 2023-10-26T11:30:00Z2023-10-26T15:00:10Z2023-10-27T11:45:00Z | |||
| SLA準拠 IsSlaCompliant | ケースがSLAの目標日までに完了したかどうかを示すブール型フラグです。 | ||
| 説明 この属性は、完了したケースのSLA達成状況を二値で示します。最終完了アクティビティのタイムスタンプが「SlaTargetDate」以前であれば「true」、それ以外は「false」に設定されます。 この計算フィールドにより、SLAの監視とレポート作成が簡単になります。全体の「SLA遵守率」KPIを集計したり、SLA準拠ケースと非準拠ケースのプロセス特性を比較するためにフィルタリングしたりできます。 重要な理由 SLAの達成状況を直接測定し、SLA遵守率KPIの計算や非準拠ケースの抽出を容易にします。 入手先 最終ケースアクティビティ(「Application Approved」や「Application Rejected」など)のタイムスタンプと「SlaTargetDate」を比較して算出します。 例 truefalse | |||
| ケース担当者 CaseOwner | 申請のライフサイクル全体を管理する主担当のユーザーまたはチームです。 | ||
| 説明 ケース担当者は、オンボーディングケースの主な責任を担う個人またはグループです。通常、この担当者がケースを期限内に完了させる責任を負います。 この属性を使うと、ケースマネージャー単位で業務量とパフォーマンスを分析できます。特定のケース担当者の処理期間が長い、または却下率が高いといった傾向を確認し、トレーニングの必要性やリソース配分の偏りを把握できます。 重要な理由 ケースの責任者または担当チームを特定し、ケースマネージャーのパフォーマンス分析を可能にします。 入手先 通常は、Fenergoの主要なケースエンティティにある、ケースの割り当てを示す専用フィールドです。 例 s.jonesonboarding_team_am.chen | |||
| 却下理由 RejectionReason | 申請が却下された理由を説明するコードまたは説明文です。 | ||
| 説明 申請の最終ステータスが「Rejected」の場合に、具体的な理由を示す属性です。「Failed Background Check」、「Incomplete Documentation」、「High Risk Profile」などがあります。 不承認となった申請の根本原因分析に欠かせない属性です。「Application Rework and Rejection」ダッシュボードで失敗を分類し、共通する問題を特定して是正措置を講じ、初回承認率を高めるために役立ちます。 重要な理由 申請が失敗した理由を把握できるため、根本原因を分析し、却下率を下げることにつながります。 入手先 通常は、Fenergoのケースワークフローで最終却下ステータスに関連付けられた理由コードまたはメモのフィールドに保存されています。 例 制裁対象者との一致無効な書類ポリシー違反顧客による取り下げ | |||
| 国 Country | 顧客申請における居住国または管轄区域です。 | ||
| 説明 顧客に関連する国を示す属性です。オンボーディングプロセスに適用される規制やリスク要因を決めることが多いです。 国別にプロセスを分析すると、管轄区域ごとのサイクルタイム、リスクレベル、プロセスの複雑さを比較できます。地域差が業務パフォーマンスに与える影響を把握し、現地規制へのコンプライアンスを確保するうえで役立ちます。 重要な理由 地域別にプロセスを分類できるため、規制の影響や地域ごとのパフォーマンスを分析するうえで重要です。 入手先 通常は申請プロセスで取得する顧客の基本データの一部であり、Fenergoのクライアントエンティティに保存されています。 例 USAGBRSGPDEU | |||
| 手戻り IsRework | アクティビティが手戻りループの一部かどうかを示すブール型フラグです。 | ||
| 説明 この属性は、「Compliance Review」の開始後に「Document Review」へ戻る場合や、「Additional Information Requested」が発生した場合など、プロセスが後戻りしたことを示すアクティビティを特定します。 手戻りを特定すると、プロセスの非効率や滞留要因を把握できます。このフラグを使えば、「手戻りループ率」KPIを直接計算でき、プロセスフロー内の無駄な反復ステップが与える影響を可視化・定量化できます。 重要な理由 プロセス内の非効率な手戻りループを明らかにし、無駄を定量化するとともに、初回で正しく完了する割合を高める改善領域を特定します。 入手先 アクティビティの順序を分析するプロセスマイニングの手法を使って算出します。たとえば、同じケースで「Activity A」の後に「Activity B」が続き、その後に再び「Activity A」が現れた場合、2回目の「Activity A」が手戻りに該当します。 例 truefalse | |||
| 申請チャネル ApplicationChannel | 顧客申請が提出されたチャネルです。 | ||
| 説明 オンラインポータル、実店舗、リレーションシップマネージャー経由など、申請の提出元を示す属性です。提出元によって、データ品質や処理要件が異なる場合があります。 「Application Source & Type Efficiency」ダッシュボードで、チャネルごとのパフォーマンスを比較するために使います。どのチャネルが効率的で、どのチャネルにプロセス改善が必要かを把握できます。 重要な理由 申請の提出元を示し、チャネルの効率、コスト、顧客体験を分析できます。 入手先 通常はFenergoの初期入力フォームに記録されるか、上流システムから渡されます。 例 オンラインポータル支店リレーションシップマネージャーモバイルアプリ | |||
| 自動実行 IsAutomated | アクティビティが人間のユーザーではなくシステムによって実行されたかどうかを示すブール型フラグです。 | ||
| 説明 この属性は、システムによって自動実行されたタスク(初期スクリーニングやシステムチェックなど)と、ユーザーが手動で実行したタスクを区別します。通常は、実行ユーザーがシステムアカウントまたはサービスアカウントかどうかを確認して判定します。 このフラグを分析すると、プロセスの自動化レベルを把握できます。自動化が効率、コスト、処理速度に与える影響を定量化し、さらなる自動化の機会を特定するのに役立ちます。 重要な理由 人によるアクティビティとシステムによるアクティビティを区別します。自動化の分析やリソースコストの把握に欠かせません。 入手先 通常は「InitiatingUser」フィールドを基に判定します。既知のシステムユーザーIDの一覧を使い、このフラグをtrueに設定します。 例 truefalse | |||
| 追加情報依頼回数 AdditionalInfoRequestCount | 申請について追加情報を依頼した回数の合計です。 | ||
| 説明 この指標は、ケースごとに「Additional Information Requested」アクティビティの発生回数を数えます。回数が多いほど、やり取りが増えてプロセスが遅れ、顧客体験が悪化する可能性があります。 この属性は、「追加情報依頼のあるケース」KPIを直接支えます。依頼が過剰な申請を特定し、初期データ収集の問題やケース要件の複雑さを把握するために使います。分析結果は、情報収集の効率化に役立ちます。 重要な理由 初期情報の不足による顧客側の負担とプロセス遅延を定量化し、データ収集ステップの改善に役立てます。 入手先 計算指標です。「CustomerApplication」IDごとに「Additional Information Requested」イベントの件数を数えて算出します。 例 013 | |||
| 顧客ID CustomerId | オンボーディングの対象となる顧客または法人を一意に識別するIDです。 | ||
| 説明 Customer IDは、マスターデータシステムにおける顧客エンティティの一意の参照値です。申請番号がプロセス上のケースIDであるのに対し、Customer IDはオンボーディングのアクティビティを特定の顧客に紐付けます。 この属性を使うと、1人の顧客について、過去に複数回オンボーディングを実施したかどうかなど、オンボーディング履歴を分析できます。また、プロセスデータを他の顧客関連データと結合し、より詳細な業務分析を行うこともできます。 重要な理由 オンボーディングプロセスを一意の顧客エンティティに紐付け、顧客単位の分析とデータの補完を可能にします。 入手先 このIDはFenergo内の顧客または法人エンティティのレコードに保存され、オンボーディングケースに関連付けられます。 例 CUST-98765CUST-98766CUST-98767 | |||
| 顧客タイプ CustomerType | オンボーディング対象となる顧客の分類です。個人、法人、信託などがあります。 | ||
| 説明 顧客の法的形態や金融機関との関係に基づいて、顧客を複数のカテゴリーに分類する属性です。顧客タイプによって、オンボーディングの経路、複雑さ、デューデリジェンス要件が異なることがあります。 顧客タイプ別にプロセスを分析すると、セグメント間のパフォーマンスの違いを特定できます。「Application Source & Type Efficiency」ダッシュボードでサイクルタイムや承認率を比較し、顧客タイプに応じた改善につなげるうえで重要です。 重要な理由 複雑さやSLAが異なることの多い顧客セグメント間で、プロセスのパフォーマンスを比較できます。 入手先 通常はFenergoの顧客またはクライアントエンティティに保存され、申請ケースと関連付けられています。 例 個人法人信託パートナーシップ | |||
KYC顧客オンボーディングアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ケース作成 | このアクティビティは、Fenergoで新規顧客の申請が正式に作成された時点で、KYCオンボーディングプロセスの開始を示します。通常は、ケースレコードが初めて保存された時刻を記録する明示的なイベントです。 | ||
| 重要な理由 開始イベントであるこのアクティビティは、オンボーディング全体のサイクルタイムと処理量を計算するうえで欠かせません。以降のすべてのプロセス測定とSLA追跡の基準になります。 入手先 通常は、Fenergoの主要なケースエンティティの作成時刻から取得します。多くの場合、Client Onboardingのケースまたはワークフローに関連するテーブルに保存されています。 取得 オンボーディングのケースレコードにある作成時刻を使用します。 イベントタイプ explicit | |||
| ケース終了 | オンボーディングケースがFenergo上で管理上クローズされ、追加対応が不要になったことを示す最終アクティビティです。承認された申請と却下された申請の両方に適用され、最終的な「Closed」ステータスから推定します。 | ||
| 重要な理由 プロセス全体の確定した終点です。結果にかかわらずすべてのケースで正確なサイクルタイムを計算でき、プロセスが完了したことを確認できます。 入手先 Fenergoのケース監査ログから、ケースのステータスが「Closed」、「Completed」、または別の終端状態に設定された時刻を特定して推定します。 取得 最終的に「Closed」または「Completed」へ変更された時刻を特定します。 イベントタイプ inferred | |||
| コンプライアンス審査完了 | コンプライアンス部門による正式な承認を示し、すべての規制要件が満たされたことを表します。タスクの完了、または「Compliance Approved」へのステータス変更から推定します。 | ||
| 重要な理由 主要なマイルストーンであり、完了時刻は全体のサイクルタイムに大きく影響します。「Average Compliance Review Time」の終点として測定し、コンプライアンス機能内のボトルネックを特定するうえで重要です。 入手先 Fenergoのワークフロー内にある「Compliance Review」タスクの完了時刻、またはケース履歴のステータス更新イベントから推定します。 取得 コンプライアンス審査タスクの完了時刻、またはステータス更新時刻を使用します。 イベントタイプ inferred | |||
| コンプライアンス審査開始 | 重要で時間のかかることが多い、コンプライアンス部門による審査の開始を示します。ケースがコンプライアンスの作業キューに割り当てられた時点、またはステータスが「Pending Compliance Review」に変更された時点から推定します。 | ||
| 重要な理由 「Average Compliance Review Time」KPIの測定開始点です。コンプライアンスチームが実際に対応を始めるまで、ケースがどの程度待機しているかを特定できます。 入手先 Fenergoのケース監査ログから、「In Compliance Review」へのステータス変更時刻、またはケースがコンプライアンス担当者やチームに割り当てられた時刻を取得して推定します。 取得 「Under Compliance Review」へのステータス変更時刻、または割り当てイベントを特定します。 イベントタイプ inferred | |||
| リスク評価完了 | 顧客にさまざまな要因に基づくリスク評価を割り当てる、社内のリスク分類プロセスが完了したことを示します。ステータス変更またはリスク評価フィールドへの値の入力から推定します。 | ||
| 重要な理由 後続のワークフローを左右する重要な意思決定のマイルストーンです。所要時間を分析すると、重要なコンプライアンス手順を効率化し、リスク評価の一貫性を確保できます。 入手先 ケース履歴ログから、「Risk Assessed」などのステータスへ移行した時刻、または最終的な「Customer Risk Rating」フィールドに値が入力された時刻を特定します。 取得 リスク評価フィールドが確定した時刻、または関連するステータスが設定された時刻を使用します。 イベントタイプ inferred | |||
| 書類審査完了 | 提出された顧客書類の真正性と正確性を確認する手動または自動のプロセスが完了したことを示します。通常は、ワークフロータスクの完了またはFenergo内のステータス変更から推定します。 | ||
| 重要な理由 多くの遅延が発生する重要なマイルストーンです。このアクティビティの所要時間と結果を分析すると、書類処理のボトルネックを特定し、「First-Time Pass Rate」などのKPIを管理できます。 入手先 ケースワークフロー内の「Document Verification」タスクの完了時刻、またはケース履歴ログの「Documents Approved」へのステータス更新から推定します。 取得 書類審査タスクの完了時刻、または関連するステータス変更を使用します。 イベントタイプ inferred | |||
| 申請却下 | 顧客の申請を却下する最終判断を示す終端イベントです。ケースのステータスが最終的な「Rejected」または「Declined」に変更された時点から推定します。 | ||
| 重要な理由 主要なプロセス終点として、「Application Rejection Rate」の計算と失敗理由の分析に欠かせません。却下が集中する箇所を特定し、申請品質の改善に役立ちます。 入手先 ケース監査ログから、最終ステータスが「Rejected」に変更された時刻を取得して推定します。却下理由は、関連するフィールドに保存されていることが多いです。 取得 最終的に「Rejected」へ変更された時刻を特定します。 イベントタイプ inferred | |||
| 申請承認 | 顧客のオンボーディング申請を承認する最終判断を示します。ケースのステータスが最終的な「Approved」または「Onboarding Approved」に変更された時点から推定します。 | ||
| 重要な理由 最終的な口座有効化の前に、承認という成功結果に至ったことを示す重要なマイルストーンです。承認率の計算や、オンボーディングに成功した顧客の特性分析に欠かせません。 入手先 ケース履歴または監査ログから、最終的に「Approved」または同等の肯定的な終端状態へ変更された時刻を特定します。 取得 最終的に「Approved」へ変更された時刻を特定します。 イベントタイプ inferred | |||
| データと書類の依頼 | このイベントは、システムまたはオンボーディング担当者が、必要な情報と書類を顧客に正式に依頼したことを示します。通常は、標準化されたコミュニケーションテンプレートを送信した時点で、明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティは、顧客の対応が必要な段階の開始を示します。この時点から書類を受領するまでの時間を測定することは、顧客体験を分析し、コミュニケーションの遅延を特定するうえで重要です。 入手先 顧客とのコミュニケーションに関連するイベントログ、または「Request Documents」タスクの完了ログから取得します。「Awaiting Customer Information」へのステータス変更から推定することもできます。 取得 顧客とのコミュニケーションイベント、またはタスクの完了記録を確認します。 イベントタイプ explicit | |||
| バックグラウンドチェック開始 | 外部のバックグラウンドチェック、AMLチェック、または信用調査が開始された時点を示します。通常は、外部サービスとの連携が呼び出された際に記録される明示的なイベントです。 | ||
| 重要な理由 これらのチェックの開始と完了を追跡すると、外部依存による遅延を把握できます。社内プロセスの時間と、外部サービスの待機時間を切り分けることも可能です。 入手先 外部スクリーニングプロバイダーへのAPI呼び出しを記録したシステムログ、またはFenergoのケース内で特定の「Background Check」タスクが作成された記録から取得します。 取得 外部サービス連携のログ、または「Screening」タスクの作成記録を確認します。 イベントタイプ explicit | |||
| 初期スクリーニング完了 | 基本的なデータ検証や制裁リストのスクリーニングなど、予備的な自動チェックまたは手動チェックの完了を示します。通常は、Fenergoのケースワークフロー内で「New」から「Screening Complete」へ移行するなど、ステータス変更から推定します。 | ||
| 重要な理由 この初期マイルストーンを追跡すると、事前審査段階における初期データ品質の問題やボトルネックを特定できます。初期の自動処理と、より負荷の高い手動審査を区別することも可能です。 入手先 ケース履歴または監査ログから、スクリーニング完了を示す状態へケースのステータスが移行した時刻を特定します。たとえば「Screening Passed」や「Awaiting Documents」などです。 取得 ケース履歴から「Screening Complete」または同等のステータスへの変更を特定します。 イベントタイプ inferred | |||
| 口座有効化 | 承認後、コアバンキングシステムまたは関連する後続システムで顧客口座が正常に作成され、有効化されたことを示します。承認後のFenergoにおける最終ステータス更新から推定できます。 | ||
| 重要な理由 オンボーディングプロセスから有効な顧客ステータスへの引き継ぎが正常に完了したことを確認します。承認から有効化までの時間を測定すると、運用設定の遅延を把握できます。 入手先 「Account Active」や「Onboarding Complete」などのケースステータスから推定できます。後続システムとの連携が成功したことを示す明示的なイベントとして記録される場合もあります。 取得 承認後のステータス変更、または連携成功のログイベントを確認します。 イベントタイプ inferred | |||
| 書類受領 | このアクティビティは、顧客が必要な書類をアップロードまたは提出し、Fenergoで審査できる状態になったことを示します。通常は、ケースのステータスが「Documents Received」または「Pending Review」に更新された時点から推定します。 | ||
| 重要な理由 顧客の待機期間が終了し、社内審査サイクルが始まる時点です。顧客の対応時間と、社内の処理待ち時間を測定するうえで重要です。 入手先 ケースの監査証跡から、「Documents Received」または同等の状態へのステータス変更時刻を取得します。書類のアップロードイベントと紐づけることもできます。 取得 「Documents Received」または「Ready for Review」へのステータス変更時刻を特定します。 イベントタイプ inferred | |||
| 追加情報の依頼 | オンボーディングチームが顧客に確認や不足書類を求めるため、プロセスを顧客側へ戻す手戻りループを示します。通常は、顧客へのコミュニケーションが送信された時点で明示的なイベントとして記録されます。 | ||
| 重要な理由 プロセスの非効率さと顧客体験の低下を示す主要な指標です。発生頻度を追跡すると、手戻りの根本原因を特定し、「Rework Loop Rate」KPIを管理できます。 入手先 顧客とのコミュニケーションのイベントログ、または「Awaiting Additional Information」へのステータス変更から取得します。正確な依頼時点を記録するには、前者のほうが適しています。 取得 記録されたコミュニケーションイベント、または「Pending Customer Response」へのステータス変更を確認します。 イベントタイプ explicit | |||
抽出ガイド
ステップ
- Reportingモジュールにアクセス:Reporting & Analyticsモジュールを利用するための十分な権限を持つユーザーアカウントでFenergoアプリケーションにログインします。通常は、メインアプリケーションメニューからモジュールを開きます。
- 新しいレポートを作成:新しいカスタムレポートの作成を開始します。目的が明確に伝わる名前と説明を設定します。例:「KYC Onboarding Event Log for Process Mining」
- 主要データソースを定義:ケースのライフサイクル情報を取得する中核データオブジェクトまたはビューを選択します。通常は「[CaseWorkflowHistory]」や「[LifecycleEventsView]」など、あらかじめ設定されたビューです。このオブジェクトには、ケース識別子、イベント名またはステータス、タイムスタンプが含まれている必要があります。
- レポート列(属性)を設定:レポートビルダーで列を追加します。Fenergoのデータモデルにあるソースフィールドを、必要なイベントログ属性に対応付けます。たとえば、Fenergoの「CaseID」を「CustomerApplication」に、「EventTimestamp」を「EventStartTime」に、「EventPerformer」を「InitiatingUser」に対応付けます。
- アクティビティのロジックを構築:最も重要なステップです。レポートが、必要な14種類のアクティビティごとに個別の行を生成するよう設定します。各アクティビティ用に論理ブロックまたはフィルタリング済みデータセットを作成し、レポートビルダー内でUNIONまたは同等の関数を使って結合します。
- 「Case Created」のロジックを定義:最初のブロックを作成します。初回のケース作成イベントをデータソースから抽出します。通常は、ケースに関連付けられた最も早いタイムスタンプ、または「Case Created」というイベントタイプを基準にします。「CreationDate」を「EventStartTime」に対応付けます。
- ステータスベースのアクティビティロジックを定義:「Documents Received」や「Application Approved」など、ステータス変更から推定するアクティビティについて、個別のブロックを作成します。特定の「Status」フィールド値でデータソースをフィルタリングし、「StatusChangeDate」を「EventStartTime」として使います。
- タスクベースのアクティビティロジックを定義:「Compliance Review Completed」など、ワークフロータスクに紐付くアクティビティについて、「TaskName」と「TaskCompletionDate」でフィルタリングするブロックを作成します。完了日を「EventStartTime」として使います。
- レポート全体のフィルターを設定:データ範囲を限定するため、レポートレベルのフィルターを適用します。「EventStartTime」に特定の「Date Range」を設定し、過度に大きなエクスポートを避けます。初回分析では3~6か月の期間を推奨します。「KYC Customer Onboarding」など、特定のケースタイプでもフィルタリングします。
- レポートを実行してプレビュー:FenergoのUIでレポートを実行します。最初の100~200行をプレビューし、データ構造が正しいこと、すべての列に想定どおり値が入っていること、複数のアクティビティが含まれていることを確認します。
- データをエクスポート:レポート結果全体をCSVまたはExcelファイルにエクスポートします。これが生のイベントログファイルです。
- 最終的なデータ準備:エクスポートしたCSVファイルを開きます。レポートで「SourceSystem」と「LastDataUpdate」列を直接生成できなかった場合は、手動で追加します。すべての行の「SourceSystem」に「Fenergo」を設定し、「LastDataUpdate」にはエクスポート時刻を設定します。
設定
- 前提条件:ユーザーには、カスタムレポートを作成・実行する権限を含む、Fenergo Reporting & Analyticsモジュールへのアクセス権が必要です。
- 主要なデータソース:レポートは主に、Fenergoのケース管理オブジェクトとワークフロー履歴オブジェクトを基に作成します。一般的なデータソースには、
[CaseDetails]、[CaseStatusHistory]、[WorkflowTaskHistory]などがあります。正確な名前は、Fenergoの設定によって異なる場合があります。 - 日付範囲:パフォーマンスを維持するため、イベントのタイムスタンプに日付範囲フィルターを設定することが重要です。まずは直近3~6か月の期間から始めてください。過去の分析では、レポートを四半期単位や年単位などのバッチに分けて実行してください。
- 主要なフィルター:無関係なデータを除外するため、「KYC Customer Onboarding」など、特定のプロセスまたはケースタイプで必ずフィルターしてください。分析の目的によっては、法人種別や管轄区域でのフィルターも必要です。
- アクティビティの定義:各アクティビティは、
ステータス、TaskName、専用のEventTypeフィールドなどに対する具体的なフィルター条件で定義する必要があります。これらのフィールドを使うことで、プロセス内の各イベントを正確に切り分けられます。 - パフォーマンスに関する考慮事項:多数のデータソースを結合したり、広い日付範囲をスキャンしたりするレポートは、処理に時間がかかる場合があります。可能であれば、業務の繁忙時間帯を避けてレポートを実行するようスケジュールしてください。エクスポートに不要な列を含めると処理時間が長くなるため、含めないでください。
a サンプルクエリ sql
/*
This is a logical representation of the configuration needed in the Fenergo Reporting & Analytics module.
The module uses a graphical interface, but this query structure illustrates the required data sources, filters, and unions.
Fields like [CaseLifecycleData].[CaseID] are placeholders for actual Fenergo fields selected in the UI.
*/
-- Base data selection for common attributes
WITH CaseAttributes AS (
SELECT
C.CaseID AS CustomerApplication,
C.SlaTargetDate AS SlaTargetDate,
C.FinalRiskScore AS RiskScore,
C.CurrentStatus AS ApplicationStatus
FROM [CaseDetails] C
WHERE C.CaseType = 'KYC Customer Onboarding'
)
-- 1. Case Created
SELECT
A.CustomerApplication,
'Case Created' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
L.CompletionTimestamp AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CASE_CREATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 2. Initial Screening Performed
SELECT
A.CustomerApplication,
'Initial Screening Performed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Initial Screening' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 3. Data & Documents Requested
SELECT
A.CustomerApplication,
'Data & Documents Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Initial Document Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 4. Documents Received
SELECT
A.CustomerApplication,
'Documents Received' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 5. Document Review Completed
SELECT
A.CustomerApplication,
'Document Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Document Verification' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 6. Background Checks Initiated
SELECT
A.CustomerApplication,
'Background Checks Initiated' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'EXTERNAL_CHECK_INITIATED'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 7. Risk Assessment Completed
SELECT
A.CustomerApplication,
'Risk Assessment Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Risk Assessment' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 8. Compliance Review Initiated
SELECT
A.CustomerApplication,
'Compliance Review Initiated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Pending Compliance Review'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 9. Additional Information Requested
SELECT
A.CustomerApplication,
'Additional Information Requested' AS ActivityName,
L.CreationTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.EventType = 'CUSTOMER_COMMUNICATION' AND L.TemplateName = 'Additional Information Request'
AND L.CreationTimestamp >= '[StartDate]' AND L.CreationTimestamp <= '[EndDate]'
UNION ALL
-- 10. Compliance Review Completed
SELECT
A.CustomerApplication,
'Compliance Review Completed' AS ActivityName,
L.CompletionTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseLifecycleEvents] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.TaskName = 'Compliance Review' AND L.TaskStatus = 'Completed'
AND L.CompletionTimestamp >= '[StartDate]' AND L.CompletionTimestamp <= '[EndDate]'
UNION ALL
-- 11. Application Approved
SELECT
A.CustomerApplication,
'Application Approved' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Approved'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 12. Application Rejected
SELECT
A.CustomerApplication,
'Application Rejected' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Rejected'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 13. Account Activated
SELECT
A.CustomerApplication,
'Account Activated' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Active'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]'
UNION ALL
-- 14. Case Closed
SELECT
A.CustomerApplication,
'Case Closed' AS ActivityName,
L.StatusChangeTimestamp AS EventStartTime,
NULL AS EventEndTime,
L.EventUser AS InitiatingUser,
U.Department AS UserDepartment,
A.ApplicationStatus,
A.SlaTargetDate,
A.RiskScore,
'Fenergo' AS SourceSystem,
GETDATE() AS LastDataUpdate
FROM [CaseStatusHistory] L
JOIN CaseAttributes A ON L.CaseID = A.CustomerApplication
LEFT JOIN [Users] U ON L.EventUser = U.UserID
WHERE L.NewStatus = 'Closed'
AND L.StatusChangeTimestamp >= '[StartDate]' AND L.StatusChangeTimestamp <= '[EndDate]' 準備はできましたか
このデータテンプレートを使えば、FenergoのKYC顧客オンボーディングプロセスに潜む非効率を見つけ、業務を効率化する準備が整います。業務の最適化と顧客満足度の向上に向けた取り組みを、今すぐ始めてください。
KYC顧客オンボーディングを効率化し、今すぐ承認を迅速化
オンボーディング期間をわずか24時間まで短縮している企業に続きましょう。
クレジットカードは不要です。数分で始められます。