> 継続的なプロセス改善 > 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
	最終データ更新日時 LastDataUpdate	ソースシステムのデータが最後に更新または抽出された日時を示すタイムスタンプです。
説明この属性は、データセットが最後に更新された日時を示します。通常、データの抽出と読み込みの際に、データセット全体に設定されます。ダッシュボードの利用者が、分析対象のデータがどの程度新しいかを把握するうえで重要な情報です。必要な鮮度を満たすデータに基づいて判断できるようにし、インサイトの提供時期に関する期待値の調整にも役立ちます。重要な理由データの鮮度を把握するための重要な情報です。分析の妥当性を保ち、古い情報に基づく判断を防ぎます。入手先通常、ETL（抽出、変換、読み込み）処理の際に生成され、データセットに記録されます。例 2024-01-15T02:00:00Z2024-01-16T02:00:00Z2024-01-17T02:00:00Z
	却下理由 RejectionReason	申請が却下された理由を説明するコードまたは説明文です。
説明申請の最終ステータスが「却下」の場合、この属性に具体的な理由が記録されます。例として、「本人確認に失敗」「制裁リストに該当」「文書の不備」などがあります。このデータは、「申請の却下理由と段階」ダッシュボードの主要な入力データです。却下理由を分析すると、プロセスで問題が起きやすい箇所を特定できます。その結果を、申請ガイドラインや顧客とのコミュニケーション、社内の審査基準の改善に役立てられます。申請が却下される理由を把握することは、承認率の向上につながります。重要な理由オンボーディングがうまくいかない理由を直接把握でき、申請の承認率を高めるための改善策を検討できます。入手先 LexisNexis Risk Solutionsの文書またはシステム管理者にご確認ください。通常、申請ステータスが「却下」に設定されたときに値が入力されるフィールドに記録されています。例制裁リストへの該当文書の不備本人確認に失敗高リスクプロファイル
	手戻りかどうか IsRework	手戻りのループに含まれるアクティビティを特定するフラグです。
説明この真偽値フラグは、同じケース内でアクティビティが繰り返された場合にtrueになります。たとえば、「追加情報を依頼」の後に「文書レビューを実施」が再度行われた場合です。プロセスが前の段階に戻ったことを示します。「手戻りと繰り返しの分析」ダッシュボードと「手戻りループの割合」重要業績評価指標（KPI）に欠かせない属性です。無駄な作業を定量化し、指示の不明確さやデータ品質の低さなど、手戻りの根本原因を特定して、対象を絞ったプロセス改善につなげられます。重要な理由プロセス内の非効率や無駄な作業を直接定量化します。頻繁に繰り返され、コストやサイクルタイムを増加させているアクティビティを明らかにします。入手先算出属性です。通常、プロセスマイニングツールでケース内のアクティビティの繰り返しを検出して算出します。例 truefalse
	申請チャネル Channel	申請の提出に使われたチャネルです。「ウェブ」「モバイル」「支店窓口」などがあります。
説明申請チャネル属性は、申請の提出元を示します。チャネルによって、データ品質や顧客の行動、オンボーディング中に発生する問題の種類が異なる場合があります。この属性を使うと、チャネルごとにプロセスのパフォーマンスを比較できます。たとえば、「オンボーディングファネルのコンバージョン率」ダッシュボードをチャネルで絞り込み、ウェブよりモバイルの申請で離脱率が高いかを確認できます。結果をチャネルごとのプロセス改善に役立てられます。重要な理由申請チャネル別にプロセスのパフォーマンスを分析し、チャネル戦略やユーザー体験の改善につながる違いを特定できます。入手先 LexisNexis Risk Solutionsの文書またはシステム管理者にご確認ください。通常、申請プロセスの開始時に記録されます。例ウェブポータルモバイルアプリ支店窓口API
	申請種別 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
	申請を受領	顧客の申請をシステムが最初に受け付けた時点を示し、KYCオンボーディングプロセスの開始となります。通常、顧客ポータルから申請フォームが送信されたとき、またはLexisNexisと連携した社内データ入力システムに登録されたときに、このイベントが記録されます。
重要な理由このイベントは、プロセスの主な開始イベントです。このアクティビティから完了までの時間を分析することで、開始から完了までのサイクルタイムとSLAの遵守状況を測定できます。入手先システムログ、または新しい顧客申請レコードの作成日時を記録する申請テーブルから取得します。記録新しい申請案件または中核となる申請テーブルのレコードが作成された時点で、イベントが記録されます。イベントタイプ explicit
	申請を承認	顧客の申請を承認する最終判断が行われ、システムに記録されます。これは重要な業務上の結果であり、ほとんどの場合、ステータス変更として明示的に記録されます。
重要な理由この節目は、判断プロセスが無事に完了したことを示します。承認に至る経路を分析すると、効果的な進め方を特定できます。入手先申請案件レコードの最終ステータスが「承認済み」または同様の終了ステータスに設定されているか確認します。記録メインの申請テーブルまたは案件テーブルに、最終的なステータス変更として記録されます。イベントタイプ explicit
	顧客オンボーディングを完了	このイベントはオンボーディングプロセス全体の正常な終了を示し、顧客が完全に有効な状態になったことを確認します。最終ステータスとして明示的に記録される場合と、「口座を有効化」イベントから推定される場合があります。
重要な理由これは、プロセスが正常に完了したことを示す主な終了イベントです。オンボーディングが完了したすべての顧客について、開始から完了までのサイクルタイムを算出するために欠かせません。入手先「口座を有効化」のタイムスタンプ、または案件ファイルの「オンボーディング完了」などの最終終了ステータスから推定します。記録口座の有効化など、最後に発生した重要な肯定的イベント、または最終ステータスの更新から推定します。イベントタイプ inferred
	初期スクリーニングを実施	申請直後にシステムが自動で行う確認です。基本データがそろっているかを検証し、初期チェックを実施します。このアクティビティは、プロセスのワークフロー履歴に自動処理のステップとして記録されることがよくあります。
重要な理由最初の段階で不備が見つかった申請を特定し、データ品質の問題を把握するのに役立ちます。また、プロセスで最初に自動処理による価値が加わるステップでもあります。入手先初期スクリーニングの完了を示す自動ルールの実行ログ、または申請のワークフロー履歴におけるステータス変更を確認します。記録完了した自動タスク、または案件履歴の特定のステータス更新として記録されます。イベントタイプ explicit
	口座を有効化	承認後、顧客の口座が銀行の基幹システムまたはサービスプラットフォーム上で正式に作成され、有効化されます。このアクティビティは監査証跡に記録されることが多く、口座の作成日から推定できる場合もあります。
重要な理由顧客に価値を届ける最後のステップです。「申請承認」からこのステップまでに遅延がある場合、システム連携に問題がある可能性があります。入手先口座作成ログ、別のシステムへのAPI呼び出し、または口座レコード自体の作成タイムスタンプから取得します。記録承認後の独立したイベントとして記録されるか、顧客レコードに有効化のタイムスタンプがあることで特定できます。イベントタイプ 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とAPI Secretが必要です。LexisNexisの管理者から取得し、機密情報として適切に管理してください。
APIエンドポイント：LexisNexis REST APIの正しいBase URLをスクリプトに設定する必要があります。申請とイベント履歴を取得するための具体的なエンドポイントは、スクリプト内に定義されています。
期間：START_DATEとEND_DATEのパラメーターで、データを抽出する期間を指定します。処理性能を保ち、APIのリクエスト制限を避けるため、3～6か月ごとにデータを抽出することをおすすめします。
アクティビティの対応付け：ACTIVITY_MAP辞書は重要な設定項目です。辞書のキーに指定するAPIのイベント名が、システムで実際に生成される名前と一致していることを確認してください。対応付けられていないイベントは無視されます。
リクエスト制限：スクリプトには、リクエスト制限に配慮してAPI呼び出しの間に基本的な待機時間が設定されています。非常に大きなデータセットを扱う場合は、API_CALL_DELAY_SECONDSの値を調整するか、より高度なバックオフ処理を実装する必要があります。
前提条件：この方法では、Python 3.xとrequestsおよびpandasライブラリがインストールされたシステムが必要です。スクリプトを実行するユーザーまたはサービスアカウントには、LexisNexis APIへのアクセス権限が必要です。

クエリの例 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からのデータ抽出

ステップ

設定

クエリの例 python

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

KYCオンボーディングを改善し、申請の離脱を減らしましょう