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

アクティビティ名は、「申請提出済み」、「書類レビュー実施済み」、「申請承認済み」など、KYCオンボーディングワークフローのステップを説明します。各活動は、プロセス内の個別の行動またはマイルストーンを表します。\n\nこの属性は、活動の流れを視覚的に表現するプロセスマップを構築するために不可欠です。これにより、プロセスバリアント、特定のステップ間のボトルネック、および手戻りループの頻度を分析できます。活動を分析することは、プロセスで何が起こっているかを理解する上で鍵となります。

この属性はプロセスマップの基盤を形成し、顧客オンボーディングジャーニーにおけるイベントの順序を視覚化および分析することを可能にします。

通常、LexisNexis Risk Solutions内のプロセスステップを追跡するイベントログまたは監査証跡テーブルで確認されます。

このタイムスタンプは、活動の開始を示し、ケース内のすべてのイベントの時系列順序を提供します。これは、プロセスマイニングにおけるすべての時間ベース分析の基盤となります。\n\nイベントタイムスタンプを使用することで、活動の期間、活動間の待機時間、およびオンボーディングプロセスのエンドツーエンドの総サイクルタイムを計算することが可能です。このデータは、ボトルネックの特定、SLA遵守の監視、およびプロセス効率の理解に不可欠です。

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

イベントログまたは監査証跡テーブル内のアクティビティ名とともに配置されます。

顧客申請は、単一顧客のオンボーディングジャーニーに関連するすべての活動とデータポイントを結びつける中心的な識別子です。申請が提出されたときに開始され、完了または却下されるまでケースを追跡します。\n\nプロセスマイニングにおいて、この属性はすべてのイベントを一貫したケースにグループ化するために不可欠であり、オンボーディングライフサイクルのエンドツーエンド分析を可能にします。各申請者のプロセスフロー全体を再構築することを可能にし、サイクルタイムの計算、プロセスバリアントの分析、時間の経過に伴う申請のステータスの追跡の基礎となります。

これは基本的なケースIDです。これがないと、顧客申請のエンドツーエンドジャーニーを追跡できず、プロセス分析が不可能になります。

これは、LexisNexis Risk Solutionsケース管理モジュール内の主要なケース識別子です。

SLA目標期日は、申請を完了するためのサービスレベル合意を定義します。この期日は、申請タイプ、顧客セグメント、管轄区域などの要因に基づいて決定されることがよくあります。\n\nこの属性は、「SLA目標遵守監視」ダッシュボードおよび「SLA遵守率」KPIにとって不可欠です。実際の完了日とSLA目標期日を比較することで、組織はコミットメントに対するパフォーマンスを測定し、SLA違反のリスクがあるケースを特定し、遅延の根本原因を調査することができます。

サービスレベル契約に対するパフォーマンス測定を可能にし、SLA違反を引き起こすプロセス非効率性を強調表示します。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これはケースに保存されるか、ビジネスルールに基づいて計算される場合があります。

LexisNexis Risk Solutionsはリスク評価を専門としています。この属性は、その評価結果を表し、各申請書を潜在的なリスクプロファイルに基づいて分類します。リスクレベルは多くの場合、デューデリジェンスプロセスの必要な厳密さと期間を決定します。\n\nこの属性は「リスクレベル vs オンボーディング期間」ダッシュボードの中核となるディメンションです。リスクレベル別にプロセスを分析することで、高リスクの申請書が予想通り著しく長い時間がかかっているか、あるいは低リスクの申請書が不必要に遅延しているかを明らかにできます。これにより、リスクベースのオンボーディング戦略を検証し、洗練させるのに役立ちます。

リスクベースの分析に不可欠であり、顧客のリスクプロファイルがプロセスの複雑さ、期間、および経路にどのように影響するかを理解するのに役立ちます。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これはリスク評価モジュールの主要な出力です。

この属性は、コンプライアンス担当者が書類レビューを行うなど、タスクを実行した特定の個人を識別します。作業負荷の分散と個々のパフォーマンスの分析に役立ちます。\n\n分析において、割り当てられたユーザーは「リソース配分と作業負荷」ダッシュボードの鍵となります。これにより、ユーザー別にプロセスマップをフィルタリングし、チームメンバー間のパフォーマンスを比較し、トレーニングまたは作業負荷の再調整の機会を特定できます。また、特定のユーザーグループによって引き起こされるボトルネックを正確に特定するのにも役立ちます。

この属性は、リソースのパフォーマンス、作業負荷の分散を分析し、自動化やリソース最適化の機会を特定するために不可欠です。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。通常、監査証跡またはタスク管理テーブルで見られます。

この属性は、特定の時点におけるケースの全体的なステータスまたは最終結果を反映します。一般的なステータスには、「進行中」、「承認済み」、「却下済み」、「情報保留中」などがあります。\n\n申請ステータスは、オンボーディングプロセスの結果を追跡するために不可欠です。「申請却下理由と段階」および「日次スループットと申請ステータス」ダッシュボードで使用され、成功率と運用フローを監視します。時間の経過とともにステータスがどのように変化するかを分析することで、ケースのライフサイクルに関する洞察が得られます。

各申請の結果を追跡し、申請却下率やスループットの監視など、主要なKPIの計算に不可欠です。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これは通常、主要なケースまたは申請オブジェクトのキーフィールドです。

このタイムスタンプは、活動の完了を示します。イベントの終了時刻と開始時刻の差が、その処理時間を表します。\n\n終了時刻は、各ステップにかかる時間を正確に計算するために不可欠であり、「活動処理および待機時間」ダッシュボードの主要な入力です。これにより、リソースがタスクに積極的に取り組んでいた時間と、ケースが次のステップを開始するのを待っていた時間とを区別するのに役立ちます。

活動処理時間の正確な計算を可能にし、非効率なステップを特定し、リソースのワークロードを分析するために不可欠です。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。開始イベントと終了イベントの両方を記録するイベントログで利用できることが多いです。

部門属性は、「コンプライアンス」、「オンボーディング運用」、「不正防止」など、活動に責任を持つ機能グループを指定します。\n\nこの属性は、部門の視点からプロセスを分析するために使用され、異なるチーム間の引き継ぎの分析を可能にします。「リソース配分と作業負荷」ダッシュボードの主要なディメンションであり、部門間の部門横断的な非効率性やコミュニケーションの遅延を特定するのに役立ちます。

プロセスハンドオフと機能領域ごとのパフォーマンス分析を可能にし、部門横断的なボトルネックの特定を支援します。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。ユーザーまたは人事マスターデータテーブルから結合する必要がある場合があります。

この属性は、「SlaTargetDate」への遵守度に基づいて、完了した各ケースを分類します。典型的な値は「達成」または「違反」です。\n\nこの計算フィールドは、「SLA目標遵守監視」ダッシュボードおよび「SLA遵守率」KPIの基盤となります。サービスコミットメントに対するパフォーマンスの明確な高レベルビューを提供し、SLAを違反するケースの一般的な特性を理解するためのドリルダウン分析を可能にします。

SLAパフォーマンスに関する明確な二者択一の結果を提供し、サービスレベル目標に対するコンプライアンスを容易に追跡、報告、分析できるようにします。

これは、各ケースの最終アクティビティのタイムスタンプを「SlaTargetDate」と比較して導き出される算出属性です。

「AssignedUser」があらゆる活動のユーザーを捕捉する一方で、この属性は重要なレビュー段階に関与するコンプライアンススペシャリストを特に識別します。これにより、コンプライアンス機能のより焦点を絞った分析が可能になります。\n\nこの属性は「コンプライアンスレビュー期間とバックログ」ダッシュボードにとって重要です。コンプライアンスチームの作業負荷とパフォーマンスを分析し、特定のレビュー担当者がボトルネックであるか、チーム全体がリソース不足であるかを特定するのに役立ちます。

コンプライアンス機能に焦点を絞ったインサイトを提供し、この重要でしばしば遅延するプロセス段階におけるレビュー担当者の作業負荷とパフォーマンスの詳細な分析を可能にします。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。「AssignedUser」をコンプライアンス関連のアクティビティでフィルターすることにより、これを導出できます。

サイクルタイムは、単一のケースについて、最初のイベント（例：「申請提出」）から最後のイベント（例：「顧客オンボーディング完了」または「申請却下」）までの経過時間を測定します。

これは、全体的なプロセス健全性を測定するための主要なKPIであり、「オンボーディングエンドツーエンドサイクルタイム」ダッシュボードで可視化されます。平均サイクルタイムを追跡することで、組織はプロセス改善の影響を監視し、リスクレベルや申請タイプなどの異なる要因が全体的な顧客体験にどのように影響するかを特定できます。

これは、顧客にとっての価値実現までの総時間を測定する主要業績評価指標（KPI）であり、顧客満足度と運用効率に直接影響を与えます。

これは、各ケースの最初のイベントのタイムスタンプを最後のイベントのタイムスタンプから減算することによって導き出される算出メトリクスです。

この属性は、LexisNexis Risk Solutionsや統合されたサードパーティツールなど、イベントデータを生成したソースシステムを識別します。複雑な環境では、単一のプロセスに関するデータが複数のシステムから供給される場合があります。\n\nソースシステムを理解することは、データ検証、トラブルシューティング、および特定のシステムに固有のプロセスバリエーションの分析に役立ちます。データの整合性を確保し、活動がどのようにどこで記録されたかに関するコンテキストを提供します。

データの出所を特定します。これは、データガバナンス、検証、および異なるITシステム間でのプロセス実行を理解するために不可欠です。

この情報は、静的値として、またはデータエクスポートやAPIレスポンス内の特定のフィールドに保存される場合があります。

チャネル属性は、申請の提出元を識別します。チャネルは、データ品質、顧客行動、およびオンボーディング中に発生する問題の種類に影響を与える可能性があります。\n\nこの属性は、異なるチャネル間のプロセスパフォーマンスを比較するために使用されます。例えば、「オンボーディングファネル変換率」ダッシュボードはチャネルでフィルタリングでき、モバイルからの申請者がウェブからの申請者よりも高い割合で離脱しているかどうかを確認し、チャネル固有のプロセス改善に役立てられます。

提出チャネルごとのプロセスパフォーマンスを分析するのに役立ち、チャネル戦略とユーザー体験の改善に情報を提供する可能性のあるバリエーションを特定します。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。この情報は通常、申請プロセスの開始時に取得されます。

この属性は、データセットが最後に更新された際のタイムスタンプを提供します。通常、データ抽出およびロードプロセス中にデータセット全体に適用されます。\n\nこの情報は、ダッシュボードユーザーが分析しているデータの鮮度を理解するために不可欠です。これにより、意思決定が必要なだけ最新のデータに基づいていることが保証され、インサイトのタイムリー性に関する期待値を管理するのに役立ちます。

データの鮮度に関する重要なコンテキストを提供し、分析が関連性を持ち、意思決定が古くなった情報に基づかないことを保証します。

これは通常、ETL（抽出、変換、ロード）プロセス中に生成され、データセットにタイムスタンプとして付与されます。

処理時間とは、アクティビティの開始および終了タイムスタンプ（終了時刻 - 開始時刻）から算出される期間です。これは、リソースがタスクに積極的に従事していた時間を表し、待機時間とは対照的です。\n\nこの算出された指標は、パフォーマンス分析の基礎であり、「アクティビティ処理および待機時間」ダッシュボードに直接反映されます。どの特定の活動が最も時間を要しているかを正確に特定し、プロセス改善、トレーニング、または自動化のターゲットを示します。例えば、「平均書類レビュー処理時間」KPIの算出に役立ちます。

活動のアクティブな作業時間を測定し、付加価値のある時間と無駄な待機時間を区別することで、真のボトルネックを特定するのに役立ちます。

これは、「終了時刻」と「イベントタイムスタンプ」（開始時刻）属性間の差から導き出される算出フィールドです。

申請の最終ステータスが「却下済み」の場合、この属性は具体的な理由を提供します。例として、「本人確認失敗」、「制裁リストとの照合」、「書類不備」などがあります。\n\nこのデータは、「申請却下理由と段階」ダッシュボードの主要な入力です。却下理由を分析することで、プロセスにおける一般的な失敗箇所を特定でき、申請ガイドライン、顧客コミュニケーション、または内部レビュー基準の改善に役立てられます。申請が却下される理由を理解することは、全体の承認率を向上させる上で鍵となります。

オンボーディングが失敗する理由への直接的な洞察を提供し、申請承認率を高めるための的を絞った改善を可能にします。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。申請ステータスが「Rejected」（却下）に設定されたときに値が入力されるフィールドでよく見られます。

このブールフラグは、同じケース内で活動が繰り返される場合にtrueに設定されます。例えば、「追加情報リクエスト済み」の後に「書類レビュー実施済み」が2回目に発生する場合などです。これは、プロセスが後退したことを示します。\n\n「手戻り」は、「手戻りおよび繰り返し分析」ダッシュボードと「手戻りループ率」KPIにとって重要です。これにより、無駄な労力を定量化し、不明確な指示やデータ品質の低さなどの手戻りの根本原因を特定し、的を絞ったプロセス改善を可能にします。

プロセスにおける非効率性と無駄な労力を直接定量化し、頻繁に繰り返され、コストとサイクルタイムを増加させている活動を強調表示します。

これは、通常、プロセスマイニングツール内で、ケース内の活動の繰り返しシーケンスを検出することによって導き出される算出属性です。

この属性は、オンボーディングされるエンティティのタイプに基づいて申請を分類します。異なる申請タイプは、しばしば異なるプロセスパスをたどり、異なるリスクプロファイルとSLA目標を持っています。\n\n申請タイプ別にプロセスを分析することで、データのセグメンテーションが可能になり、異なる種類の顧客のオンボーディングの効率と複雑さを比較できます。これは、ほとんどのダッシュボードでパフォーマンスのより詳細なビューを提供するために使用される一般的なフィルターです。

プロセスの強力なセグメンテーションを可能にし、異なる種類のアプリケーションがどのように処理され、各タイプに特定のボトルネックがどこに存在するかを明らかにします。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これは通常、申請またはケースオブジェクトのコアフィールドです。

このブール属性は、システム自動化によって実行されるタスク（例：初期スクリーニングチェック）と、人間による介入を必要とするタスク（例：手動書類レビュー）を区別します。\n\n「自動化済み」は、「手動活動比率」KPIの計算と自動化イニシアチブの有効性の分析に使用されます。プロセスマップでは、自動化されたステップと手動ステップの間のインターフェースを強調表示し、コストと処理時間を削減するためのさらなる自動化の機会を特定するのに役立ちます。

手動タスクと自動化タスクを区別し、自動化の機会を特定し、その影響を測定するための鍵となります。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これはイベントログ内のフラグであるか、「AssignedUser」（例：「system」ユーザー）に基づいて推測される場合があります。

この属性は顧客の国を指定します。これは、国際的な規制や異なる管轄区域に関連するリスクレベルが異なるため、KYCにおいて重要な要素です。\n\n顧客国別にプロセスを分析することで、サイクルタイムとプロセスの複雑さに大きな違いがあることが明らかになります。例えば、高リスク管轄区域からの申請は追加のコンプライアンスチェックが必要となり、期間が長くなる可能性があります。この分析は、リソース計画と異なる地域に対する現実的なSLA設定に役立ちます。

管轄区域分析を可能にし、地域の規制やリスク要因がプロセスパフォーマンスにどのように影響するかを理解する上で重要です。

LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご相談ください。これは顧客マスターデータの標準フィールドです。