KYC顧客オンボーディングのデータテンプレート
KYC顧客オンボーディングのデータテンプレート
- 収集を推奨する属性
- 追跡すべき主要なアクティビティ
- データ抽出の手引き
KYC顧客オンボーディングの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | オンボーディングプロセスの特定の時点で発生した業務イベントまたはタスクの名前です。 | ||
| 説明 アクティビティ名は、顧客のオンボーディングにおける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コンプライアンス監視」ダッシュボードや、「SLA遵守率」の重要業績評価指標(KPI)の算出に欠かせません。SLA違反のおそれがあるケースを事前に把握し、作業の優先順位を付けられます。 重要な理由 目標完了日を示す属性です。SLAの遵守状況の監視や、期限を過ぎたケースの優先順位付けに役立ちます。 入手先 FenergoのSLA管理モジュールで設定された業務ルールに基づき、申請提出日から算出されることがよくあります。 例 2023-11-15T23:59:59Z2023-12-01T23:59:59Z | |||
| ユーザーの所属部門 UserDepartment | 実行ユーザーが所属する部門または事業部門です。 | ||
| 説明 この属性は、アクティビティを実行したユーザーの組織上の所属を示します。「コンプライアンス」「オンボーディング業務」「営業」などが該当し、ユーザープロフィールの情報から取得することがよくあります。 部門間のプロセスの引き継ぎを分析し、部門横断のボトルネックを特定するうえで重要です。チームまたは部門単位で業務を集計できるため、「スタッフのアクティビティ分布」ダッシュボードにも役立ちます。 重要な理由 部門別にプロセスのパフォーマンスを分析し、部門間の引き継ぎ、遅延、業務量の分布を把握できます。 入手先 「InitiatingUser」IDを使って、別のユーザーまたは人事マスターデータのテーブルから結合する必要がある場合があります。Fenergoのユーザープロフィールに保存されていることもあります。 例 Compliance顧客オンボーディング品質保証 | |||
| リスクスコア RiskScore | 顧客のリスクレベルを数値で示したスコアです。 | ||
| 説明 リスクスコアは、管轄区域、業種、スクリーニング結果などの要因に基づいて算出される、顧客に伴う潜在的なリスクの定量的な指標です。通常はFenergoのルールエンジンが算出します。 この属性を使うと、リスクレベルとプロセスの進み方の関係を分析できます。たとえば、高リスクの顧客はサイクルタイムが長いのか、手作業での対応が多く必要なのかを把握できます。「リスクとコンプライアンス確認の詳細分析」ダッシュボードにも役立ちます。 重要な理由 顧客のリスクを数値化し、リスクレベルがプロセスの所要時間、手戻り、結果に与える影響を分析できます。 入手先 Fenergoの顧客リスク評価モジュールが出力する主要な値です。ケースまたはクライアントのエンティティに保存されています。 例 154585 | |||
| 実行ユーザー InitiatingUser | アクティビティを実行した担当者のユーザーIDまたは名前です。 | ||
| 説明 この属性は、タスクやイベントを実行した従業員またはシステムユーザーを特定します。一意のユーザーID、名前、役割などが記録されます。 ユーザー別に分析すると、業務量の分布や個人のパフォーマンスを把握し、トレーニングの必要性を特定できます。「スタッフのアクティビティ分布」ダッシュボードや、特定の担当者またはチームが実行したアクティビティのドリルダウンにも役立ちます。 重要な理由 アクションを実行したユーザーを追跡し、業務量の分布、チームのパフォーマンス、リソース配分を分析できます。 入手先 通常は、イベントの詳細とともにFenergoの監査ログまたはタスク履歴のテーブルに保存され、「UserID」「UserName」「ModifiedBy」などの名前が付いています。 例 j.doea.smithSYSTEM | |||
| 申請ステータス ApplicationStatus | 顧客申請の現在または最終的な結果です。 | ||
| 説明 この属性は、プロセス終了時の申請結果、または処理中の場合は現在の状態を示します。一般的な値には「承認済み」「却下」「処理中」などがあります。 結果分析に欠かせない属性です。最終結果に基づいてプロセスフローを絞り込み、比較できます。「申請の手戻りと却下」ダッシュボードや、申請却下率などの重要業績評価指標(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)の算出や、SLAを遵守できなかったケースの絞り込みに役立ちます。 入手先 最終ケースアクティビティ(「申請承認」「申請却下」など)のタイムスタンプを「SlaTargetDate」と比較して算出します。 例 truefalse | |||
| ケース担当者 CaseOwner | 申請のライフサイクル全体を通じて管理を担う主担当者またはチームです。 | ||
| 説明 ケース担当者は、オンボーディングケースの主な責任を割り当てられた個人またはグループです。通常、期限内にケースを適切に完了させる責任を負います。 この属性を使うと、ケース管理者単位で業務量やパフォーマンスを分析できます。特定の担当者のサイクルタイムが長い、または却下率が高い場合に、トレーニングの必要性やリソースの偏りを把握できます。 重要な理由 ケースの責任者または担当チームを特定し、ケース管理者のパフォーマンスを分析できます。 入手先 通常は、Fenergoの主要なケースエンティティにあるケースの割り当てを示すフィールドです。 例 s.jonesonboarding_team_am.chen | |||
| 却下理由 RejectionReason | 申請が却下された理由を説明するコードまたは説明文です。 | ||
| 説明 申請の最終ステータスが「却下」の場合、この属性に具体的な理由が記録されます。「バックグラウンドチェック不合格」「文書不備」「高リスク」などが例です。 申請が不成立となった根本原因の分析に欠かせない属性です。「申請の手戻りと却下」ダッシュボードで却下理由を分類し、よくある問題を特定して是正措置を講じることで、初回での合格率向上につなげられます。 重要な理由 申請が不成立となる理由を把握し、根本原因を分析して却下率の低減につなげられます。 入手先 通常は、Fenergoのケースワークフローで最終的な却下ステータスに関連付けられた理由コードまたはメモのフィールドに記録されています。 例 制裁対象者との一致無効な文書ポリシー違反顧客による取り下げ | |||
| 国 Country | 顧客申請に関連する居住国または管轄区域です。 | ||
| 説明 この属性は顧客に関連する国を示します。国によって、オンボーディングプロセスに適用される規制やリスク要因が異なることがあります。 国別にプロセスを分析すると、サイクルタイム、リスクレベル、プロセスの複雑さを管轄区域ごとに比較できます。地域ごとの違いが業務パフォーマンスに与える影響を把握し、現地の規制へのコンプライアンスを確認するのに役立ちます。 重要な理由 地域別にプロセスを分類でき、規制の影響や地域ごとのパフォーマンス分析に役立ちます。 入手先 申請時に取得する顧客の基本データの一部で、Fenergoのクライアントエンティティに保存されています。 例 USAGBRSGPDEU | |||
| 手戻りかどうか IsRework | アクティビティが手戻りのループに含まれるかどうかを示す真偽値です。 | ||
| 説明 この属性は、「コンプライアンス確認」の開始後に「文書確認」に戻る場合や、「追加情報を依頼」が発生する場合など、プロセスが前の段階に戻ったことを示すアクティビティを特定します。 手戻りの特定は、プロセスの非効率や滞りを把握するうえで重要です。このフラグを使うと、「手戻りループ率」という重要業績評価指標(KPI)を直接算出でき、プロセスフローにおける無駄な反復作業の影響を可視化して定量化できます。 重要な理由 非効率な手戻りループを明らかにし、無駄を定量化して改善箇所を特定することで、初回での正確な処理の割合を高められます。 入手先 アクティビティの順序を分析するプロセスマイニングの手法を使って、このフラグを算出します。たとえば、同じケースで「アクティビティA」の後に「アクティビティB」が続き、その後再び「アクティビティA」が現れた場合、2回目の「アクティビティA」は手戻りです。 例 truefalse | |||
| 申請チャネル ApplicationChannel | 顧客申請が提出されたチャネルです。 | ||
| 説明 この属性は、オンラインポータル、実店舗の支店、リレーションシップマネージャー経由など、申請の提出元を示します。提出元によって、データ品質や処理要件が異なる場合があります。 「申請元と種別別の効率」ダッシュボードで、チャネルごとのパフォーマンスを比較するために使います。効率の高いチャネルや、プロセスの改善が必要なチャネルを把握できます。 重要な理由 申請の提出元を特定し、チャネルの効率、コスト、顧客体験を分析できます。 入手先 Fenergoの初期データ入力フォームで取得するか、上流システムから渡される場合があります。 例 オンラインポータル支店リレーションシップマネージャーモバイルアプリ | |||
| 自動実行かどうか IsAutomated | アクティビティが人ではなくシステムによって実行されたかどうかを示す真偽値です。 | ||
| 説明 この属性は、初期スクリーニングやシステムチェックなど、システムが自動実行したタスクと、ユーザーが手動で実行したタスクを区別します。実行ユーザーがシステムアカウントまたはサービスアカウントかどうかで判定することがよくあります。 このフラグを分析すると、プロセスの自動化の度合いを把握できます。自動化が効率、コスト、処理速度に与える影響を測定し、さらなる自動化の余地を特定できます。 重要な理由 人が実行したアクティビティとシステムが実行したアクティビティを区別でき、自動化分析やリソースコストの把握に役立ちます。 入手先 通常は「InitiatingUser」フィールドから判定します。既知のシステムユーザーIDの一覧を使い、該当する場合にこのフラグをtrueに設定します。 例 truefalse | |||
| 追加情報依頼回数 AdditionalInfoRequestCount | 申請について追加情報を依頼した合計回数です。 | ||
| 説明 この指標は、ケースごとに「追加情報を依頼」アクティビティの発生回数を数えます。回数が多いほど、やり取りが増えてプロセスが遅れ、顧客体験が損なわれる可能性があります。 この属性は、「追加情報の依頼があったケース」という重要業績評価指標(KPI)に直接役立ちます。依頼が過剰な申請を特定し、初期のデータ収集や複雑なケース要件に問題がないかを確認できます。分析結果をもとに、情報収集の手順を効率化できます。 重要な理由 初期情報の不足による顧客の負担やプロセスの遅延を定量化し、データ収集の改善に役立てられます。 入手先 計算指標です。「CustomerApplication」IDごとに「追加情報を依頼」イベントの数を数えて算出します。 例 013 | |||
| 顧客ID CustomerId | オンボーディング対象の顧客または法人を識別する一意のIDです。 | ||
| 説明 顧客IDは、マスターデータシステムにおけるクライアントエンティティの一意の識別子です。申請番号がプロセスのケースIDであるのに対し、顧客IDはオンボーディングのアクティビティを特定のクライアントに結び付けます。 この属性を使うと、同じ顧客が過去に複数回オンボーディングを受けている場合など、顧客ごとのオンボーディング履歴を分析できます。また、プロセスデータを他の顧客関連データと結合し、業務全体をより詳しく把握できます。 重要な理由 オンボーディングプロセスを一意の顧客エンティティに結び付け、顧客単位の分析やデータの補完を可能にします。 入手先 このIDはFenergoのクライアントまたは法人のレコードに保存され、オンボーディングケースに関連付けられています。 例 CUST-98765CUST-98766CUST-98767 | |||
| 顧客種別 CustomerType | オンボーディング対象の顧客の分類です。個人、法人、信託などがあります。 | ||
| 説明 この属性は、法的な形態や金融機関との関係に基づいて顧客を分類します。顧客種別によって、オンボーディングの経路や複雑さ、デューデリジェンスの要件が異なることがあります。 顧客種別ごとにプロセスを分析すると、セグメント間のパフォーマンスの違いを特定できます。「申請元と種別別の効率」ダッシュボードでサイクルタイムや承認率を比較し、各セグメントに合わせたプロセス改善につなげられます。 重要な理由 複雑さやSLAが異なる顧客セグメント間で、プロセスのパフォーマンスを比較できます。 入手先 通常はFenergoの顧客またはクライアントのエンティティに保存され、申請ケースに関連付けられています。 例 個人法人信託パートナーシップ | |||
KYC顧客オンボーディングのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| ケース作成 | Fenergoで新規顧客の申請が正式に作成された時点を示すアクティビティです。通常、ケースレコードが最初に保存された日時を示す明示的なイベントとして記録されます。 | ||
| 重要な理由 開始イベントとして、オンボーディング全体のサイクルタイムや処理量を分析するために欠かせません。以降のすべてのプロセス測定とSLA追跡のベースラインになります。 入手先 通常は、Fenergoの主要なケースエンティティの作成日時から取得します。顧客オンボーディングのケースやワークフローに関連するテーブルに記録されていることがよくあります。 記録 オンボーディングのケースレコードの作成日時を使用します。 イベントタイプ explicit | |||
| ケース終了 | これは最終アクティビティで、Fenergo上でオンボーディングケースが事務的に終了し、以降の対応が予定されていないことを示します。承認された申請と却下された申請の両方が対象で、最終ステータスが「終了」になったことから推定できます。 | ||
| 重要な理由 このアクティビティは、プロセス全体の確定的な終了点となります。結果にかかわらず、すべてのケースのサイクルタイムを正確に算出でき、プロセスが完了したことを確認できます。 入手先 Fenergoのケース監査ログで、ケースステータスが「終了」「完了」などの最終状態に設定された時刻を特定して推定します。 記録 最終ステータスが「終了」または「完了」に変更された時刻を特定します。 イベントタイプ inferred | |||
| コンプライアンス審査完了 | コンプライアンス部門が正式に承認し、すべての規制要件が満たされたことを示します。タスクの完了、またはステータスが「コンプライアンス承認済み」に変わった時点から推定します。 | ||
| 重要な理由 全体のサイクルタイムを把握するうえで、完了日時が重要となる大きな節目です。「コンプライアンス審査の平均時間」の測定終了点となり、コンプライアンス部門のボトルネック特定にも役立ちます。 入手先 Fenergoのワークフロー内にある「コンプライアンス審査」タスクの完了日時、またはケース履歴のステータス更新イベントから推定します。 記録 コンプライアンス審査タスクの完了日時、またはステータス更新日時を使用します。 イベントタイプ inferred | |||
| コンプライアンス審査開始 | 重要で、時間がかかることも多いコンプライアンス部門の審査が始まった時点を示します。ケースがコンプライアンスの作業キューに割り当てられた時点、またはステータスが「コンプライアンス審査待ち」に変わった時点から推定します。 | ||
| 重要な理由 「コンプライアンス審査の平均時間」を測定するための重要業績評価指標(KPI)の起点です。コンプライアンスチームが実際に対応を始めるまで、ケースがどのくらい待機しているかを特定できます。 入手先 Fenergoのケース監査ログから、ステータスが「コンプライアンス審査中」に変わった日時、またはケースがコンプライアンス担当者やチームに割り当てられた日時を取得します。 記録 「コンプライアンス審査中」へのステータス変更日時、または割り当てイベントの日時を特定します。 イベントタイプ inferred | |||
| リスク評価完了 | さまざまな要素に基づいて顧客のリスク評価を割り当てる、社内のリスク分類プロセスが完了したことを示します。ステータス変更やリスク評価フィールドへの値の入力から推定します。 | ||
| 重要な理由 後続のワークフローの経路を左右することが多い、重要な意思決定の節目です。所要時間を分析すると、重要なコンプライアンス手順を効率化し、リスク評価の一貫性を保つのに役立ちます。 入手先 ケース履歴ログから、ステータスが「リスク評価済み」などに変わった日時、または最終的な「顧客リスク評価」フィールドに値が入力された日時を特定します。 記録 リスク評価フィールドが確定した日時、または関連するステータスが設定された日時を使用します。 イベントタイプ inferred | |||
| 書類審査完了 | 提出された顧客書類の真正性と正確性を確認する、手動または自動の処理が完了したことを示します。通常、ワークフロータスクの完了やFenergoのステータス変更から推定します。 | ||
| 重要な理由 遅延が多く発生する重要な節目です。このアクティビティの所要時間と結果を分析すると、書類処理のボトルネックを特定でき、「初回合格率」などの重要業績評価指標(KPI)の確認にも役立ちます。 入手先 ケースワークフローの「書類確認」タスクの完了日時、またはケース履歴ログでステータスが「書類承認済み」に更新された日時から推定します。 記録 書類審査タスクの完了日時、または関連するステータス変更の日時を使用します。 イベントタイプ inferred | |||
| 申請却下 | 顧客の申請を却下する最終判断を示す、プロセスの終了イベントです。ケースのステータスが最終状態の「却下」または「不承認」に変わった時点から推定します。 | ||
| 重要な理由 プロセスの重要な終了点として、「申請却下率」の算出や却下理由の分析に欠かせません。よくある却下の発生箇所を特定し、申請の品質向上に役立ちます。 入手先 ケースの監査ログから、最終ステータスが「却下」に変わった日時を取得します。却下理由は、関連するフィールドに保存されていることがよくあります。 記録 最終ステータスが「却下」に変わった日時を特定します。 イベントタイプ inferred | |||
| 申請承認 | 顧客のオンボーディング申請を承認する最終判断を示します。ケースのステータスが最終状態の「承認済み」または「オンボーディング承認済み」に変わった時点から推定します。 | ||
| 重要な理由 口座の有効化に向けた最終手順の前に、申請が承認されたことを示す重要な節目です。承認率の算出や、オンボーディングが完了した顧客の特性分析に欠かせません。 入手先 ケース履歴または監査ログから、最終ステータスが「承認済み」または同様の肯定的な終了状態に変わった日時を特定します。 記録 最終ステータスが「承認済み」に変わった日時を特定します。 イベントタイプ inferred | |||
| データと書類を依頼 | システムまたはオンボーディング担当者が、必要な情報や文書を顧客に正式に依頼したことを示すイベントです。標準の連絡用テンプレートを送信した際に、明示的なイベントとして記録されることがよくあります。 | ||
| 重要な理由 このアクティビティは、顧客の対応が必要な段階の開始を示します。この時点から書類を受領するまでの時間を測定すると、顧客の手続きの流れを分析し、連絡の遅れを特定できます。 入手先 顧客との連絡に関するイベントログ、または「書類を依頼」タスクの完了ログから取得します。「顧客情報待ち」へのステータス変更から推定できる場合もあります。 記録 顧客への連絡イベント、またはタスクの完了記録を確認します。 イベントタイプ explicit | |||
| バックグラウンドチェック開始 | 外部のバックグラウンドチェック、AMLチェック、信用調査が開始された時点を示します。多くの場合、サードパーティサービスとの連携が呼び出された際に、明示的なイベントとして記録されます。 | ||
| 重要な理由 これらのチェックの開始と完了を追跡することは、外部依存による遅延を把握するうえで重要です。社内プロセスの所要時間と、外部からの応答待ち時間を分けて確認できます。 入手先 通常、外部スクリーニングサービスへのAPI呼び出しを記録したシステムログ、またはFenergoのケース内に特定の「バックグラウンドチェック」タスクが作成された記録から取得します。 記録 外部サービスとの連携ログ、または「スクリーニング」タスクの作成記録を確認します。 イベントタイプ explicit | |||
| 初期スクリーニング完了 | 基本的なデータ検証や制裁リストとの照合など、初期の自動または手動チェックが完了したことを示します。Fenergoのケースワークフローでステータスが「新規」から「スクリーニング完了」に変わった時点などから推定することがよくあります。 | ||
| 重要な理由 この初期段階の節目を追跡すると、事前審査段階でのデータ品質の問題やボトルネックを特定できます。初期の自動処理と、より時間のかかる手動審査を分けて把握できます。 入手先 ケース履歴または監査ログから、ケースのステータスが「スクリーニング合格」や「書類待ち」など、スクリーニング完了を示す状態に変わった日時を特定します。 記録 ケース履歴から「スクリーニング完了」または同様のステータスへの変更を特定します。 イベントタイプ inferred | |||
| 口座有効化 | 承認後、コアバンキングシステムまたは関連する後続システムで顧客口座が正常に作成され、有効化されたことを示します。承認後にFenergoで記録された最終ステータスの更新から推定できる場合があります。 | ||
| 重要な理由 このアクティビティは、オンボーディングプロセスから顧客のアクティブ状態への引き継ぎが正常に完了したことを示します。承認から有効化までの時間を測定すると、業務上の設定に伴う遅延を把握できます。 入手先 「口座アクティブ」や「オンボーディング完了」などのケースステータスから推定できます。また、後続システムとの連携によって明示的なイベントとして記録される場合もあります。 記録 承認後のステータス変更、または連携成功を示すログイベントを確認します。 イベントタイプ inferred | |||
| 書類受領 | 顧客が必要な書類をアップロードまたは提出し、Fenergoで審査できる状態になったことを示します。通常、ケースのステータスが「書類受領」または「審査待ち」に更新された時点から推定します。 | ||
| 重要な理由 顧客の待機期間の終了と、社内審査サイクルの開始を示します。顧客の応答時間と社内処理キューでの待ち時間を測定するうえで重要です。 入手先 ケースの監査証跡から、「書類受領」または同様の状態へのステータス変更日時を取得します。書類のアップロードイベントと関連付けられている場合もあります。 記録 「書類受領」または「審査準備完了」へのステータス変更日時を特定します。 イベントタイプ inferred | |||
| 追加情報を依頼 | オンボーディングチームが、確認事項や不足書類について顧客に再度問い合わせる手戻りのループを示します。通常、顧客に連絡を送信した際に明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティは、プロセスの非効率や顧客体験の悪化を示す主な指標です。発生頻度を追跡すると、手戻りの根本原因を特定し、「手戻りループ率」の重要業績評価指標(KPI)を確認できます。 入手先 顧客との連絡に関するイベントログ、または「追加情報待ち」へのステータス変更から取得します。正確な依頼時点を把握するには、前者がより適しています。 記録 記録された連絡イベント、または「顧客の回答待ち」へのステータス変更を確認します。 イベントタイプ explicit | |||
データ抽出ガイド
ステップ
- レポーティングモジュールにアクセス:レポーティング&分析モジュールを利用する権限を持つユーザーアカウントで、Fenergoアプリケーションにログインします。通常はメインメニューから該当モジュールを開きます。
- 新しいレポートを作成:カスタムレポートの作成を開始します。用途が明確にわかる名前と説明を設定します。例:「プロセスマイニング用KYCオンボーディングイベントログ」
- 主要データソースを定義:ケースのライフサイクル情報を記録する主要なデータオブジェクトまたはビューを選択します。多くの場合、
[CaseWorkflowHistory]や[LifecycleEventsView]などの事前設定済みビューを使います。このオブジェクトには、ケース識別子、イベント名またはステータス、タイムスタンプが含まれている必要があります。 - レポート列(属性)を設定:レポート作成画面で列を追加します。Fenergoのデータモデルにあるソースフィールドを、必要なイベントログ属性に対応付けます。たとえば、Fenergoの
CaseIDをCustomerApplicationに、EventTimestampをEventStartTimeに、EventPerformerをInitiatingUserに対応付けます。 - アクティビティのロジックを構築:最も重要な手順です。必要な14種類のアクティビティそれぞれについて、個別の行が生成されるようレポートを設定します。各アクティビティ用の論理ブロックまたはフィルター済みデータセットを作成し、レポート作成画面でUNIONまたは同等の機能を使って結合します。
- 「ケース作成」ロジックを定義:最初のブロックを作成します。データソースを、ケースの初回作成イベントで絞り込みます。ケースに関連付けられた最も早いタイムスタンプ、または「Case Created」というイベントタイプを基準にするのが一般的です。
CreationDateをEventStartTimeに対応付けます。 - ステータスに基づくアクティビティのロジックを定義:「書類受領」や「申請承認」など、ステータス変更から推定するアクティビティ用に個別のブロックを作成します。特定の「ステータス」フィールドの値でデータソースを絞り込み、
StatusChangeDateをEventStartTimeとして使用します。 - タスクに基づくアクティビティのロジックを定義:「コンプライアンス審査完了」など、ワークフロータスクに関連するアクティビティ用のブロックを作成し、
TaskNameとTaskCompletionDateで絞り込みます。完了日をEventStartTimeとして使用します。 - レポート全体に適用するフィルターを設定:データの範囲を指定するため、レポートレベルのフィルターを適用します。過度に大きなエクスポートを避けるため、
EventStartTimeに特定のDate Rangeを設定します。最初の分析では、3~6か月の期間を推奨します。「KYC顧客オンボーディング」など、対象のケースタイプで絞り込みます。 - レポートを実行してプレビュー:Fenergoの画面でレポートを実行します。最初の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フィールドなどに対する具体的なフィルター条件で定義する必要があります。これらのフィールドを使うことで、プロセス内の個々のイベントを正確に特定できます。 - パフォーマンスに関する考慮事項:多数のデータソースを結合するレポートや、広い日付範囲を対象とするレポートは、処理に時間がかかる場合があります。可能であれば、利用が少ない時間帯に実行するようスケジュールを設定してください。処理時間が長くなるため、エクスポートには不要な列を含めないでください。
クエリの例 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時間に短縮している企業に続きましょう。
クレジットカードは不要です。数分で利用を開始できます。