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

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

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

このテンプレートは、プロセスを効果的に分析できるよう、Fenergoのデータを準備するためのものです。KYC顧客オンボーディング全体で収集する必要があるデータ属性と、追跡すべき主要なアクティビティをまとめています。データの抽出方法も説明しているため、業務改善に向けてスムーズに取り組みを始められます。
  • 収集を推奨する属性
  • 追跡すべき主要なアクティビティ
  • データ抽出の手引き
イベントログを初めて作成する方はこちら: プロセスマイニング用イベントログの作成方法.

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

FenergoでKYC顧客オンボーディングを詳しく分析するため、イベントログに含めることを推奨するデータ項目です。プロセスを深く理解するために役立ちます。
5 必須 6 推奨 10 任意
名前 説明
アクティビティ名
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顧客オンボーディングのアクティビティ

プロセスの正確な発見と分析に向けて、イベントログに記録すべき主要なステップと節目を示します。
8 推奨 6 任意
アクティビティ 説明
ケース作成
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からデータを取得する方法

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

このデータテンプレートを使えば、FenergoのKYC顧客オンボーディングにおける非効率を見つけ、プロセスを効率化する準備が整います。業務の改善と顧客満足度の向上に向けて、今日から取り組みを始めましょう。

KYC顧客オンボーディングを効率化し、承認を迅速化

オンボーディングをわずか24時間に短縮している企業に続きましょう。

無料トライアルを開始

クレジットカードは不要です。数分で利用を開始できます。