> 継続的なプロセス改善 > KYC顧客オンボーディング > LexisNexis Risk Solutions > データテンプレート

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

LexisNexis Risk Solutions

KYC顧客オンボーディングの属性 (20) KYC顧客オンボーディングアクティビティ (14) 抽出ガイド (1)

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

このテンプレートでは、KYC顧客オンボーディングプロセスを分析するために必要なデータを収集する方法を詳しく説明します。収集すべき属性、追跡すべき主要なアクティビティ、ソースシステムから情報を抽出する方法をまとめています。この資料を使って信頼性の高いイベントログを作成し、オンボーディングプロセスを詳しく分析できます。

収集を推奨する属性
追跡すべき主要なアクティビティ
抽出方法のガイド

イベントログを初めて扱いますか。学ぶプロセスマイニングのイベントログを作成する方法.

テンプレートをダウンロード

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

KYC顧客オンボーディングの分析とプロセス発見を詳細に行うために、イベントログに含めることを推奨するデータ項目です。

3 必須 6 推奨 11 任意

	名前	説明
	アクティビティ名 ActivityName	オンボーディングプロセスの途中で、特定の時点に発生したタスクまたはイベントの名称です。
説明アクティビティ名は、「申請受付」、「書類レビュー実施」、「申請承認」など、KYCオンボーディングのワークフローにおける各ステップを示します。それぞれのアクティビティは、プロセス上の個別のアクションまたはマイルストーンを表します。この属性は、アクティビティの流れを視覚的に表すプロセスマップの作成に欠かせません。プロセスのバリアント、特定のステップ間にあるボトルネック、手戻りループの発生頻度を分析できます。アクティビティを分析することは、プロセスで何が起きているかを把握するうえで重要です。重要な理由この属性はプロセスマップの基盤となり、顧客オンボーディングの流れにおけるイベントの順序を可視化して分析できます。入手先通常、プロセスのステップを記録するLexisNexis Risk Solutions内のイベントログまたは監査証跡テーブルにあります。例申請を提出初期スクリーニングを実施書類を依頼コンプライアンスレビューを完了
	イベントタイムスタンプ EventTimestamp	特定のアクティビティが開始された正確な日付と時刻です。
説明このタイムスタンプはアクティビティの開始時点を示し、ケース内のすべてのイベントを時系列に並べるために使われます。プロセスマイニングにおける時間ベースの分析の基盤となる情報です。イベントタイムスタンプを使うと、アクティビティの所要時間、アクティビティ間の待ち時間、オンボーディングプロセス全体のエンドツーエンドのサイクルタイムを計算できます。ボトルネックの特定、SLA遵守状況の監視、プロセス効率の把握にも欠かせません。重要な理由イベントを時系列に並べ、サイクルタイムやボトルネックなど、時間に基づくすべての指標を計算するために欠かせないタイムスタンプです。入手先アクティビティ名とともに、イベントログまたは監査証跡テーブルにあります。例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:15:00Z
	顧客申請 CustomerApplication	各顧客オンボーディング申請を一意に識別する識別子であり、主要なケースIDとして機能します。
説明顧客申請は、1人の顧客のオンボーディング過程に関連するすべてのアクティビティとデータを結び付ける中心的な識別子です。申請が送信された時点から始まり、完了または却下されるまで案件を追跡します。プロセスマイニングでは、この属性によってすべてのイベントを1つの一貫したケースにまとめられるため、オンボーディングのライフサイクルをエンドツーエンドで分析できます。申請者ごとのプロセスフロー全体を再構築でき、サイクルタイムの計算、プロセスバリアントの分析、申請ステータスの経時的な追跡に欠かせません。重要な理由これは基本となるケースIDです。これがないと、顧客申請のエンドツーエンドの流れを追跡できず、プロセス分析ができません。入手先 LexisNexis Risk Solutionsのケース管理モジュール内で使用される、主要なケース識別子です。例 APP-2023-001234APP-2023-005678APP-2024-009101
	SLA目標日 SlaTargetDate	顧客オンボーディングプロセスを完了する予定の日付です。
説明 SLA目標日は、申請を完了するためのサービスレベル合意を定めます。この日付は、申請の種類、顧客セグメント、管轄区域などの要因に基づいて決まることがよくあります。「SLA目標遵守状況モニタリング」ダッシュボードと「SLA遵守率」KPIに欠かせない属性です。実際の完了日とSLA目標日を比較することで、合意した基準に対するパフォーマンスを測定し、SLA違反のリスクがあるケースを特定し、遅延の根本原因を調査できます。重要な理由サービスレベル合意に対するパフォーマンスを測定でき、SLA違反につながるプロセスの非効率を明らかにします。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。ケースに保存されているか、業務ルールに基づいて算出される場合があります。例 2023-11-10T17:00:00Z2023-11-15T17:00:00Z2023-12-01T17:00:00Z
	リスクレベル RiskLevel	顧客申請について算出されたリスクレベルです。例として、低、中、高があります。
説明 LexisNexis Risk Solutionsはリスク評価を専門としています。この属性はその評価結果を示し、潜在的なリスクプロファイルに基づいて各申請を分類します。リスクレベルによって、デューデリジェンスに必要な強度や期間が決まることがよくあります。この属性は、「リスクレベルとオンボーディング期間」ダッシュボードの中心的な分析軸です。リスクレベル別にプロセスを分析すると、高リスクの申請に想定どおり長い時間がかかっているか、低リスクの申請に不要な遅延が発生していないかを確認できます。リスクベースのオンボーディング戦略の検証と改善にも役立ちます。重要な理由リスクに基づく分析に欠かせない属性です。顧客のリスクプロファイルがプロセスの複雑さ、所要時間、経路に与える影響を把握できます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、リスク評価モジュールが出力する主要な項目です。例低中高制裁対象
	割り当てユーザー AssignedUser	アクティビティの実行を担当したユーザーまたはエージェントの一意の識別子です。
説明この属性は、書類レビューを行うコンプライアンス担当者など、タスクを実行した個人を特定します。作業負荷の分布や個人のパフォーマンスを分析するために役立ちます。分析では、「リソース配分と作業負荷」ダッシュボードの主要な項目です。ユーザー別にプロセスマップを絞り込み、チームメンバー間のパフォーマンスを比較し、トレーニングや作業負荷の再配分の機会を特定できます。特定のユーザーグループが原因となるボトルネックの把握にも役立ちます。重要な理由リソースのパフォーマンスや作業負荷の分布を分析し、自動化やリソース配分を見直す機会を特定するために欠かせない属性です。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、監査証跡またはタスク管理テーブルにあります。例 j.doem.smithk.chen
	申請ステータス ApplicationStatus	顧客申請の現在または最終的なステータスです。
説明この属性は、特定時点におけるケース全体のステータス、または最終結果を示します。一般的なステータスには、「処理中」、「承認済み」、「却下」、「情報待ち」などがあります。申請ステータスは、オンボーディングプロセスの結果を追跡するために欠かせません。「申請却下の理由とステージ」および「日次処理件数と申請ステータス」ダッシュボードで、成功率や業務の流れを監視するために使われます。ステータスの経時変化を分析すると、ケースのライフサイクルを把握できます。重要な理由各申請の結果を追跡でき、申請却下率などの主要KPIの計算や処理件数の監視に欠かせません。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、主要なケースまたは申請オブジェクトの重要なフィールドです。例進行中承認済み却下顧客情報待ち
	終了時刻 EndTime	アクティビティが完了した正確な日付と時刻です。
説明このタイムスタンプはアクティビティの完了時点を示します。イベントの終了時刻と開始時刻の差が、そのイベントの処理時間になります。終了時刻は、各ステップにかかった時間を正確に計算するために欠かせません。「アクティビティの処理時間と待ち時間」ダッシュボードの主要な入力データでもあります。担当者がタスクに実際に取り組んだ時間と、次のステップの開始をケースが待っていた時間を区別できます。重要な理由アクティビティの処理時間を正確に計算できるため、非効率なステップの特定や担当者の負荷分析に役立ちます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。開始イベントと終了イベントの両方を記録するイベントログで確認できる場合があります。例 2023-10-26T10:45:10Z2023-10-26T11:55:30Z2023-10-28T09:05:00Z
	部門 Department	割り当てられたユーザーが所属する事業部門またはチームです。
説明部門属性は、アクティビティを担当する機能グループを示します。例として、「コンプライアンス」、「オンボーディング業務」、「不正防止」などがあります。この属性を使うと、部門の視点からプロセスを分析し、異なるチーム間の引き継ぎを把握できます。「リソース配分と作業負荷」ダッシュボードの主要な分析軸であり、部門横断の非効率や、部門間のコミュニケーションによる遅延の特定にも役立ちます。重要な理由機能領域ごとのプロセスの引き継ぎやパフォーマンスを分析でき、部門間のボトルネックの特定に役立ちます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。ユーザーまたは人事マスターデータのテーブルから結合する必要がある場合があります。例 ComplianceオンボーディングチームKYCアナリストカスタマーサポート
	SLAステータス SlaStatus	完了した申請がSLA目標を達成したかどうかを示します。
説明この属性は、「SlaTargetDate」への遵守状況に基づいて、完了した各ケースを分類します。一般的な値は「達成」または「違反」です。この計算フィールドは、「SLA目標遵守状況モニタリング」ダッシュボードと「SLA遵守率」KPIの基盤となります。サービス上の合意事項に対するパフォーマンスを明確に把握でき、SLAに違反したケースの共通点をドリルダウン分析できます。重要な理由 SLAに対するパフォーマンスを達成または違反の2値で明確に示すため、サービスレベル目標の遵守状況を追跡、報告、分析しやすくなります。入手先計算によって求める属性です。各ケースについて、最終アクティビティのタイムスタンプと「SlaTargetDate」を比較して算出します。例達成違反リスクあり
	コンプライアンス審査担当者 ComplianceReviewer	コンプライアンス審査のアクティビティを担当するユーザーまたはエージェントです。
説明「AssignedUser」はあらゆるアクティビティの担当者を記録しますが、この属性は重要な審査ステップに関わるコンプライアンス専門担当者を特定します。コンプライアンス機能に絞った分析が可能になります。「コンプライアンス審査の所要時間と滞留」ダッシュボードの主要な項目です。コンプライアンスチームの作業負荷やパフォーマンスを分析し、特定の審査担当者がボトルネックになっていないか、チーム全体の人員が不足していないかを確認できます。重要な理由コンプライアンス機能を詳しく把握でき、遅延が発生しやすい重要なプロセス段階について、審査担当者の作業負荷やパフォーマンスを詳細に分析できます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。コンプライアンス関連のアクティビティに絞り込み、「AssignedUser」から導出できる場合があります。例 c.joness.patelsystem_escalation
	サイクルタイム CycleTime	顧客申請を提出してから最終判断に至るまでの、エンドツーエンドの総所要時間です。
説明サイクルタイムは、1つのケースにおける最初のイベント（例：「申請受付」）から最後のイベント（例：「顧客オンボーディング完了」または「申請却下」）までの経過時間を測定します。プロセス全体の健全性を測る主要KPIであり、「オンボーディングのエンドツーエンドサイクルタイム」ダッシュボードで可視化されます。平均サイクルタイムを追跡すると、プロセス改善の効果を監視し、リスクレベルや申請タイプなどの要因が顧客体験全体に与える影響を把握できます。重要な理由顧客が価値を得るまでの総時間を測る主要なパフォーマンス指標であり、顧客満足度と業務効率に直接影響します。入手先計算によって求める指標です。各ケースについて、最後のイベントのタイムスタンプから最初のイベントのタイムスタンプを差し引いて算出します。例 5日4時間22日8時間1日2時間
	ソースシステム SourceSystem	イベントデータの生成元となるシステムまたはアプリケーションです。
説明この属性は、LexisNexis Risk Solutionsや連携されたサードパーティ製ツールなど、イベントデータを生成したソースシステムを識別します。複雑な環境では、1つのプロセスのデータが複数のシステムから取得される場合があります。ソースシステムを把握すると、データの検証やトラブルシューティング、特定のシステムに起因するプロセスの違いの分析に役立ちます。また、データの整合性を確保し、アクティビティがどのシステムでどのように記録されたかを理解するための背景情報にもなります。重要な理由データの出所を特定します。データガバナンスや検証、異なるITシステムにまたがるプロセス実行の把握に欠かせません。入手先この情報は、データエクスポートまたはAPIレスポンス内の固定値や特定のフィールドとして保存される場合があります。例 LexisNexis Risk SolutionsThreatMetrixBridger Insight XG
	チャネル Channel	申請が提出された経路です。例として、「Web」、「モバイル」、「支店」があります。
説明チャネル属性は、申請の提出元を示します。チャネルによって、データ品質、顧客の行動、オンボーディング中に発生する問題の種類が異なる場合があります。この属性を使うと、チャネルごとにプロセスのパフォーマンスを比較できます。たとえば、「オンボーディングファネルのコンバージョン率」ダッシュボードをチャネルで絞り込み、Web申請者よりもモバイル申請者の離脱率が高いかを確認できます。チャネルごとのプロセス改善にも役立ちます。重要な理由申請チャネル別にプロセスのパフォーマンスを分析でき、チャネル戦略やユーザー体験の改善につながる違いを特定できます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、申請プロセスの開始時に取得されます。例 Webポータルモバイルアプリ支店窓口API
	最終データ更新日時 LastDataUpdate	ソースシステムからデータが最後に更新または抽出された時点を示すタイムスタンプです。
説明この属性は、データセットが最後に更新された日時を示します。通常、データの抽出・読み込み処理の際に、データセット全体へ付与されます。分析対象のデータがどの程度新しいかをダッシュボード利用者が把握するために欠かせない情報です。必要な最新性を備えたデータに基づいて意思決定できるようにし、分析結果がいつ時点の情報であるかを明確にします。重要な理由データの最新性を把握するための重要な背景情報となり、分析の妥当性を保ち、古い情報に基づく意思決定を防ぎます。入手先通常、ETL（Extract、Transform、Load）処理の中で生成され、データセットに付与されます。例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	却下理由 RejectionReason	申請が却下された理由を説明するコードまたは説明文です。
説明申請の最終ステータスが「却下」の場合、この属性に具体的な理由が記録されます。例として、「本人確認失敗」、「制裁対象者との一致」、「書類不備」などがあります。このデータは、「申請却下の理由とステージ」ダッシュボードの主要な入力データです。却下理由を分析すると、プロセス内で頻発する失敗箇所を特定できます。その結果、申請ガイドライン、顧客への案内、社内の審査基準を改善できます。申請が却下される理由を把握することは、全体の承認率を高めるうえで重要です。重要な理由オンボーディングが失敗する理由を直接把握でき、申請の承認率を高めるための的を絞った改善につなげられます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、申請ステータスが「却下」に設定されたときに入力されるフィールドにあります。例制裁リストとの一致書類不備本人確認失敗高リスクプロファイル
	手戻りかどうか IsRework	手戻りループの一部であるアクティビティを識別するフラグです。
説明このブール型フラグは、同じケース内でアクティビティが繰り返された場合にtrueになります。たとえば、「追加情報の依頼」の後に「書類レビュー実施」が2回目に行われた場合です。プロセスが後戻りしたことを示します。「手戻りかどうか」は「手戻りと繰り返しの分析」ダッシュボードと「手戻りループ比率」KPIに欠かせません。無駄な作業量を定量化し、手戻りの根本原因（不明確な指示やデータ品質の問題など）を特定して、的を絞った改善につなげられます。重要な理由プロセスの非効率や無駄な作業を直接定量化し、頻繁に繰り返されるアクティビティや、コストとサイクルタイムを増加させる要因を明らかにします。入手先計算によって求める属性です。通常、ケース内でアクティビティの繰り返しが発生しているかを検出し、プロセスマイニングツール内で算出します。例 truefalse
	申請タイプ ApplicationType	顧客申請の種類です。例として、「個人」または「法人」があります。
説明この属性は、オンボーディングの対象となる事業体の種類に基づいて申請を分類します。申請の種類によって、異なるプロセス経路、リスクプロファイル、SLA目標が設定されることがよくあります。申請タイプ別にプロセスを分析すると、データを分けて、異なる種類の顧客に対するオンボーディングの効率や複雑さを比較できます。多くのダッシュボードで使われる一般的なフィルターであり、パフォーマンスをより詳細に把握できます。重要な理由プロセスを詳細にセグメント化でき、申請の種類ごとの処理方法や固有のボトルネックを明らかにします。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、申請またはケースオブジェクトの主要フィールドです。例個人事業者富裕層個人信託
	自動処理かどうか IsAutomated	アクティビティがシステムによって自動的に実行されたか、ユーザーが手動で実行したかを示すフラグです。
説明このブール型属性は、システムによる自動化で実行されたタスク（初回スクリーニングチェックなど）と、人の介入が必要なタスク（手動での書類レビューなど）を区別します。「自動処理かどうか」は「手動アクティビティ比率」KPIの計算や、自動化施策の効果分析に使われます。プロセスマップ上で自動ステップと手動ステップの接点を示し、コストや処理時間を削減するために、さらなる自動化の機会を特定できます。重要な理由手動タスクと自動タスクを区別でき、自動化の機会を特定し、その効果を測定するために重要です。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。イベントログ内のフラグであるか、「AssignedUser」（例：「system」ユーザー）に基づいて推定される場合があります。例 truefalse
	顧客所在国 CustomerCountry	顧客の居住国または設立国です。
説明この属性は顧客の所在国を示します。国や管轄区域によって国際規制やリスクレベルが異なるため、KYCにおける重要な要素です。顧客所在国別にプロセスを分析すると、サイクルタイムやプロセスの複雑さに大きな違いがあるかを確認できます。たとえば、高リスクの管轄区域からの申請では追加のコンプライアンスチェックが必要となり、所要時間が長くなる場合があります。この分析は、リソース計画や地域ごとの現実的なSLA設定に役立ちます。重要な理由管轄区域別の分析が可能になり、地域の規制やリスク要因がプロセスのパフォーマンスに与える影響を把握できます。入手先 LexisNexis Risk Solutionsのドキュメントまたはシステム管理者にご確認ください。通常、顧客マスターデータの標準フィールドです。例 USAGBRDEUSGP

必須推奨任意

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

正確なプロセス発見とパフォーマンス分析のために、イベントログに記録すべき主要なプロセス手順とマイルストーンです。

8 推奨 6 任意

	アクティビティ	説明
	コンプライアンスレビューを完了	コンプライアンス担当者がレビューを完了して推奨判断を行い、案件を次の段階へ進めます。タスクが「完了」と登録された時点で明示的に取得できるほか、「コンプライアンス待ち」から別の状態へのステータス変更から推定できます。
重要な理由重要で、手作業が多い工程の完了を示す重要な節目です。コンプライアンスレビューの所要時間を測定する終点になります。入手先コンプライアンスタスクの完了時刻、または「コンプライアンスレビュー中」からのステータス変更から取得します。取得「承認済み」「却下」または「最終判断」など、レビュー完了を示すステータス変更から推定します。イベントタイプ inferred
	コンプライアンスレビューを開始	通常は高リスク申請について、案件がコンプライアンス担当者またはチームに割り当てられ、手動レビューが行われます。「コンプライアンスレビュー待ち」へのステータス変更、またはタスク割り当てログから推定できます。
重要な理由手動で行われることが多く、時間もかかるレビュー工程の開始を示します。この時点から完了までの時間を測定することで、コンプライアンス関連のボトルネックを定量化できます。入手先タスク割り当てログ、案件所有者のコンプライアンスチームへの変更、または案件履歴のステータス更新から取得します。取得「コンプライアンスレビュー中」などへのステータス変更、または案件がコンプライアンス関連のユーザーキューに割り当てられた時点から推定します。イベントタイプ inferred
	リスク評価を実施	収集した情報と実施したチェックに基づき、システムが顧客のリスクスコアを計算します。これはLexisNexisの中核機能であり、通常は案件履歴に明示的な自動イベントとして記録されます。
重要な理由この評価結果によって、その後のプロセス経路が決まることがあります。たとえば、強化された顧客管理が必要になる場合があります。ワークフローにおける重要な判断ポイントです。入手先リスクスコアリングまたは評価モジュールの完了を記録する、申請の監査ログまたはワークフロー履歴内のイベントを確認します。取得リスクエンジンが分析を完了し、リスクプロファイルまたはスコアを割り当てた時点で、特定のイベントが記録されます。イベントタイプ explicit
	書類を受領	顧客が必要な書類をシステムにアップロードまたは提出したことを確認します。通常は、書類提出ポータルが生成する明示的なイベント、または担当者による手動入力として記録されます。
重要な理由このアクティビティによって待機時間が終わり、その後の確認作業が開始されます。データ収集段階における重要な節目です。入手先書類管理システムのログ、または新しい書類が添付された際の申請案件ファイル内のタイムスタンプ付き記録から取得します。取得書類が正常にアップロードされた時点、またはシステム上で受領済みと手動登録された時点でイベントが記録されます。イベントタイプ explicit
	申請を却下	顧客申請を却下する最終判断が記録されます。終了イベントであり、システム上の確定的なステータス変更によって取得されます。
重要な理由これは失敗状態を示す主要な終了イベントです。却下が発生した段階とその理由を分析することは、プロセス改善に欠かせません。入手先申請レコードの最終ステータスが「却下」「不承認」または同様の終了状態に設定されたことから取得します。取得主要な申請テーブルまたは案件テーブルにおける、最終的かつ確定的なステータス変更として記録されます。イベントタイプ explicit
	申請を承認	顧客申請を承認する最終判断が行われ、システムに記録されます。重要な業務成果であり、ほぼ必ず明示的なステータス変更として記録されます。
重要な理由この節目は、判断プロセスが正常に完了したことを示します。承認に至った経路を分析することで、ベストプラクティスを特定できます。入手先申請案件レコードの最終ステータスが「承認済み」または同様の終了状態に設定されたことを示す更新を確認します。取得主要な申請テーブルまたは案件テーブルにおける、最終的かつ確定的なステータス変更として記録されます。イベントタイプ explicit
	申請を提出	顧客の申請がシステムで最初に受け付けられた時点で、KYCオンボーディングプロセスの開始を示します。通常は、LexisNexisと連携した顧客ポータルまたは社内のデータ入力システムから申請フォームが送信された際に、明示的なイベントとして記録されます。
重要な理由これはプロセスの主要な開始イベントです。このアクティビティから完了までの時間を分析することは、エンドツーエンドのサイクルタイムとSLA遵守状況を測定するうえで重要です。入手先システムログ、または新しい顧客申請レコードの初回作成時刻を記録する申請テーブルから取得します。取得新しい申請案件または主要な申請テーブルのレコードが作成された時点でイベントが記録されます。イベントタイプ explicit
	顧客オンボーディングを完了	オンボーディングプロセス全体が正常に終了し、顧客が完全に有効な状態になったことを示します。明示的な最終ステータスとして記録される場合や、「アカウント有効化」イベントから推定される場合があります。
重要な理由これは成功状態を示す主要な終了イベントです。オンボーディングに成功したすべての顧客について、エンドツーエンドのサイクルタイムを計算するために欠かせません。入手先「アカウント有効化」のタイムスタンプ、または案件ファイル内の「オンボーディング完了」など、最終的な終了ステータスから推定します。取得アカウントの有効化など、最後に発生した重要な成功イベント、または最終ステータスの更新から推定します。イベントタイプ inferred
	アカウントを有効化	承認後、顧客のアカウントが基幹バンキングまたはサービスプラットフォーム上で正式に作成され、有効化されます。このアクティビティは監査証跡に記録されるか、アカウント作成日から推定できます。
重要な理由顧客に価値を届ける最後のステップです。「申請承認」からこのステップまでの遅延は、システム連携の問題を示している可能性があります。入手先アカウント作成ログ、別システムへのAPI呼び出し、またはアカウントレコード自体の作成時刻から取得します。取得承認後の独立したイベントとして記録されるか、顧客レコードに有効化時刻が存在することで特定できます。イベントタイプ explicit
	初期スクリーニングを実施	申請直後にシステムが実行する自動チェックで、基本データの完全性を確認し、予備チェックを行います。このアクティビティは、プロセスワークフロー履歴に明示的な自動ステップとして記録されることがよくあります。
重要な理由最も早い段階で失敗する申請を特定し、データ品質の問題を把握するのに役立ちます。また、プロセスにおける最初の自動化された付加価値ステップを示します。入手先自動ルールの実行ログ、または初期スクリーニングの完了を示す申請ワークフロー履歴のステータス変更を確認します。取得完了した自動タスク、またはケース履歴内の特定のステータス更新として記録されます。イベントタイプ explicit
	書類レビューを実施	担当者または自動ツールが、提出された書類の真正性、有効性、完全性を確認します。「書類受領」から「レビュー完了」へのステータス変更、または明示的なログ記録から推定できます。
重要な理由これはボトルネックや手戻りが発生しやすい箇所です。処理時間と繰り返し回数を分析することが、効率改善と自動化の機会を特定する鍵になります。入手先「書類受領」ステータスから「検証合格」や「追加情報が必要」などの後続ステータスまでの時間を追跡して推定します。取得書類受領イベントからレビュー完了を示すイベントまでの時間として計算します。イベントタイプ inferred
	書類を依頼	システムまたは担当者が、運転免許証や公共料金の請求書など、特定の書類を顧客に依頼します。システムが生成した連絡ログ、または書類待ちを示すステータス変更から取得できます。
重要な理由このアクティビティによって、プロセスに大きな待機時間が生じることがあります。頻度と所要時間を分析することで、顧客の回答時間による遅延を特定できます。入手先顧客に送信した連絡ログのイベント、または申請のステータス変更を確認します。例として「顧客書類待ち」などがあります。取得「書類待ち」へのステータス変更、または送信した連絡ログのタイムスタンプから推定します。イベントタイプ inferred
	本人確認を開始	LexisNexisのサービスを利用して、データベースとの照合など、本人確認の中核プロセスをシステムが開始する時点を示します。通常は、本人確認サービスが呼び出された際に明示的なイベントログとして記録されます。
重要な理由このアクティビティは、重要で時間のかかるサブプロセスの開始を示します。所要時間を追跡することで、本人確認に関するボトルネックを切り分けられます。入手先本人確認モジュールへのAPI呼び出しログ、または本人確認タスクの開始を示す監査証跡から取得します。取得システムの本人確認モジュールまたはAPIが申請に対して起動された時点でイベントが記録されます。イベントタイプ explicit
	追加情報を依頼	コンプライアンス担当者またはレビュアーが、顧客に追加情報や説明を求めます。このイベントは手戻りの主な原因であり、通常は明示的なステータス変更または連絡ログとして記録されます。
重要な理由このアクティビティによって手戻りのループが発生し、オンボーディングのサイクルタイムが長くなります。頻度を追跡することで、不明確な要件や申請上のよくある不備を特定できます。入手先「顧客情報待ち」へのステータス変更、または送信した連絡イベントのログを確認します。多くの場合、担当者が起点となる操作です。取得担当者が「情報を依頼」機能を使用すると記録されます。これにより案件のステータスが変わり、連絡イベントが記録される場合があります。イベントタイプ explicit

推奨任意

抽出ガイド

LexisNexis Risk Solutionsからデータを取得する方法

ステップ

Python環境を準備します：システムにPython 3.8以降をインストールします。ターミナルまたはコマンドプロンプトを開き、pip install requests pandasを実行して必要なライブラリをインストールします。
API認証情報を取得します：LexisNexis Risk Solutionsの管理者または担当者に連絡し、API認証情報を取得します。API Key、API Secret、APIエンドポイントのBase URLが必要です。
Pythonスクリプトを設定します：提供されたPythonスクリプトをテキストエディターで開きます。先頭付近の設定セクションを探し、API_KEY、API_SECRET、BASE_URLのプレースホルダーを実際の認証情報に置き換えます。
抽出パラメーターを設定します：同じ設定セクションで、START_DATEおよびEND_DATE変数にデータ抽出期間を指定します。日付は「YYYY-MM-DD」形式で入力します。抽出をテストするため、まずは1か月など、短い期間から始めることを推奨します。
アクティビティの対応付けを確認します：スクリプト内のACTIVITY_MAP辞書を確認します。この辞書は、LexisNexis APIのレスポンスに含まれるイベントタイプを、イベントログで必要な標準アクティビティ名に対応付けます。LexisNexisの設定で使用しているイベント名に応じて、左側のキーを調整する必要がある場合があります。これらの名前は、APIレスポンスのサンプルを確認して特定できます。
スクリプトを実行します：ターミナルでpython your_script_name.pyコマンドを使用してスクリプトを実行します。スクリプトは認証を行い、指定した日付範囲内の顧客申請一覧を取得した後、それぞれのイベント履歴を取得します。
スクリプトの進行状況を確認します：スクリプトは、処理中の申請数などの進行状況をコンソールに表示します。認証情報、APIエンドポイント、レート制限に関する問題を示すエラーメッセージがないか確認してください。
出力ファイルを取得します：スクリプトが正常に完了すると、同じディレクトリにlexisnexis_event_log.csvというファイルが生成されます。このファイルには抽出したイベントログが含まれます。
アップロードの準備をします：プロセスマイニングツールにアップロードする前に、CSVファイルを開き、CustomerApplication、ActivityName、EventTimestampなど、想定される列が含まれていることを確認します。データが正しく、一貫していることも確認してください。
ProcessMindにアップロードします：生成されたlexisnexis_event_log.csvファイルをプロセスマイニングアプリケーションにアップロードし、列を対応するケースID、アクティビティ、タイムスタンプのフィールドに割り当てます。

設定

API認証情報：認証には有効なAPI KeyとSecretが必要です。これらはLexisNexisの管理者から取得し、機密情報として管理してください。
APIエンドポイント：スクリプトには、LexisNexis REST APIの正しいBase URLを設定する必要があります。申請とイベント履歴を取得するための具体的なエンドポイントは、スクリプトコード内で定義されています。
期間：START_DATEとEND_DATEパラメーターで抽出期間を指定します。処理性能を維持し、APIのレート制限を避けるため、3～6か月単位でデータを抽出することを推奨します。
アクティビティマッピング：ACTIVITY_MAP辞書は重要な設定項目です。APIから取得するソースイベント名が、辞書のキーとしてシステムの生成する名称と一致していることを確認してください。マッピングされていないイベントは無視されます。
レート制限：スクリプトには、想定されるレート制限に対応するため、API呼び出し間に基本的な待機時間が設定されています。非常に大規模なデータセットでは、API_CALL_DELAY_SECONDSの値を調整するか、より高度なバックオフ処理を実装する必要があります。
前提条件：この方法では、requestsとpandasライブラリを含むPython 3.xがインストールされたシステムが必要です。スクリプトを実行するユーザーまたはサービスアカウントには、LexisNexis APIにアクセスする十分な権限が必要です。

a サンプルクエリ python

import requests
import pandas as pd
import time
import json
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration Section --- #
class=class="hl-string">"hl-comment"># Replace with your actual LexisNexis API credentials and endpoints
API_KEY = class="hl-string">'[Your_API_Key]'
API_SECRET = class="hl-string">'[Your_API_Secret]'
BASE_URL = class="hl-string">'[https://api.example.lexisnexis.com/v1]' class=class="hl-string">"hl-comment"># e.g., your specific API gateway URL

class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">'2023-01-01'
END_DATE = class="hl-string">'2023-06-30'

class=class="hl-string">"hl-comment"># Delay between API calls to avoid rate limiting
API_CALL_DELAY_SECONDS = 0.5

class=class="hl-string">"hl-comment"># Mapping from LexisNexis event types to standard activity names
class=class="hl-string">"hl-comment"># CRITICAL: The keys of this dictionary must be adjusted to match the event names
class=class="hl-string">"hl-comment"># returned by your specific LexisNexis API endpoint.
ACTIVITY_MAP = {
    class="hl-string">'application.submitted': class="hl-string">'Application Submitted',
    class="hl-string">'screening.initial.performed': class="hl-string">'Initial Screening Performed',
    class="hl-string">'verification.identity.initiated': class="hl-string">'Identity Verification Initiated',
    class="hl-string">'documents.requested': class="hl-string">'Documents Requested',
    class="hl-string">'documents.received': class="hl-string">'Documents Received',
    class="hl-string">'review.document.performed': class="hl-string">'Document Review Performed',
    class="hl-string">'assessment.risk.performed': class="hl-string">'Risk Assessment Performed',
    class="hl-string">'review.compliance.initiated': class="hl-string">'Compliance Review Initiated',
    class="hl-string">'information.additional.requested': class="hl-string">'Additional Information Requested',
    class="hl-string">'review.compliance.completed': class="hl-string">'Compliance Review Completed',
    class="hl-string">'application.approved': class="hl-string">'Application Approved',
    class="hl-string">'account.activated': class="hl-string">'Account Activated',
    class="hl-string">'onboarding.completed': class="hl-string">'Customer Onboarding Completed',
    class="hl-string">'application.rejected': class="hl-string">'Application Rejected'
}

def get_auth_token():
    class="hl-string">"""Handles authentication and returns an access token."""
    class=class="hl-string">"hl-comment"># This is a placeholder for the actual authentication mechanism.
    class=class="hl-string">"hl-comment"># Adjust according to LexisNexis API documentation (e.g., OAuth2).
    class=class="hl-string">"hl-comment"># For simplicity, we assume the API Key can be used directly in a header.
    class=class="hl-string">"hl-comment"># In a real scenario, you might POST to a token endpoint.
    print(class="hl-string">"Authentication successful (simulated).")
    return fclass="hl-string">'Bearer {API_KEY}' class=class="hl-string">"hl-comment"># Simplified for example purposes

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    auth_token = get_auth_token()
    if not auth_token:
        print(class="hl-string">"Failed to authenticate. Exiting.")
        return

    headers = {
        class="hl-string">'Authorization': auth_token,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    print(fclass="hl-string">"Fetching applications from {START_DATE} to {END_DATE}...")
    
    class=class="hl-string">"hl-comment"># 1. Fetch all application IDs within the date range
    try:
        applications_endpoint = fclass="hl-string">'{BASE_URL}/applications'
        params = {class="hl-string">'startDate': START_DATE, class="hl-string">'endDate': END_DATE}
        response = requests.get(applications_endpoint, headers=headers, params=params)
        response.raise_for_status()
        applications = response.json().get(class="hl-string">'applications', [])
        print(fclass="hl-string">"Found {len(applications)} applications to process.")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error fetching applications: {e}")
        return

    all_events = []

    class=class="hl-string">"hl-comment"># 2. For each application, fetch its detailed event history
    for i, app in enumerate(applications):
        app_id = app.get(class="hl-string">'customerApplicationId')
        if not app_id:
            continue

        print(fclass="hl-string">"Processing application {i+1}/{len(applications)}: {app_id}")
        try:
            events_endpoint = fclass="hl-string">'{BASE_URL}/applications/{app_id}/events'
            event_response = requests.get(events_endpoint, headers=headers)
            event_response.raise_for_status()
            events_data = event_response.json().get(class="hl-string">'events', [])
            
            class=class="hl-string">"hl-comment"># 3. Parse events and map them to the event log format
            for event in events_data:
                event_type = event.get(class="hl-string">'eventType')
                if event_type in ACTIVITY_MAP:
                    activity_name = ACTIVITY_MAP[event_type]
                    
                    class=class="hl-string">"hl-comment"># Extract attributes, using .get() to handle missing data gracefully
                    record = {
                        class="hl-string">'CustomerApplication': app_id,
                        class="hl-string">'ActivityName': activity_name,
                        class="hl-string">'EventTimestamp': event.get(class="hl-string">'eventTimestamp'),
                        class="hl-string">'EndTime': event.get(class="hl-string">'eventCompletionTimestamp', None), class=class="hl-string">"hl-comment"># Optional
                        class="hl-string">'AssignedUser': event.get(class="hl-string">'userId', class="hl-string">'System'),
                        class="hl-string">'Department': event.get(class="hl-string">'userDepartment', None),
                        class="hl-string">'ApplicationStatus': event.get(class="hl-string">'applicationStatusAfterEvent'),
                        class="hl-string">'RiskLevel': event.get(class="hl-string">'riskAssessment', {}).get(class="hl-string">'level', None),
                        class="hl-string">'SlaTargetDate': app.get(class="hl-string">'slaTargetDate', None)
                    }
                    all_events.append(record)

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Could not fetch events for application {app_id}: {e}")
        
        time.sleep(API_CALL_DELAY_SECONDS)

    if not all_events:
        print(class="hl-string">"No events were extracted. The output file will be empty.")
        return

    class=class="hl-string">"hl-comment"># 4. Create a DataFrame and save to CSV
    df = pd.DataFrame(all_events)
    df[class="hl-string">'EventTimestamp'] = pd.to_datetime(df[class="hl-string">'EventTimestamp'])
    df.sort_values(by=[class="hl-string">'CustomerApplication', class="hl-string">'EventTimestamp'], inplace=True)
    
    output_filename = class="hl-string">'lexisnexis_event_log.csv'
    df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%d %H:%M:%S')
    print(fclass="hl-string">"Extraction complete. Event log saved to {output_filename}")

if __name__ == class="hl-string">"__main__":
    main()

準備はできましたか？

このテンプレートを使って、KYC顧客オンボーディングのプロセスマイニングを始めましょう。今すぐデータを具体的な改善案につなげてください。

改善ガイドに戻るテンプレートをダウンロード

KYCオンボーディングを最適化し、離脱を今すぐ削減

オンボーディングをスムーズに進め、所要時間をわずか24時間まで短縮します。

無料トライアルを開始

クレジットカードは不要です。今日から最適化を始められます。

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

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

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

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

抽出ガイド

Pythonスクリプトを使ったLexisNexis APIデータ抽出

ステップ

設定

a サンプルクエリ python

準備はできましたか？

KYCオンボーディングを最適化し、離脱を今すぐ削減

プライバシーを大切にしています