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

アクティビティ名は、顧客のオンボーディングにおける個別のステップやマイルストーンを表します。たとえば、「申請提出」、「コンプライアンスレビュー開始」、「申請承認」などです。各アクティビティは、ユーザーまたはシステムが実行し、申請をプロセスの先へ進める具体的なアクションを表します。

この属性は、プロセスマイニングの中核となるプロセスマップを可視化するための基本要素です。さまざまなアクティビティの順序と頻度を分析すると、実際のプロセスフローを把握し、一般的な経路を特定し、プロセスからの逸脱を見つけ、手戻りや繰り返しが発生する箇所を特定できます。意味のある分かりやすいプロセスモデルを構築するには、アクティビティ名が明確で一貫していることが欠かせません。

プロセスのステップを定義し、プロセスフロー、ボトルネック、ばらつきを可視化・分析できるようにします。

業務プロセスのステップを記録するイベントログ、監査証跡、または取引テーブルにあります。

イベント開始時刻は、アクティビティの開始を示す正確な日時です。ケースID、アクティビティ名と並ぶ、プロセスマイニングの3つの基本要素の1つです。このタイムスタンプ付きデータによって、各ケース内のイベントを時系列に並べ、実際に発生したプロセスフローを再構成できます。

この属性は、時間に関するすべての分析の基礎となります。アクティビティの所要時間、アクティビティ間の待ち時間（引き継ぎ時間）、オンボーディングプロセス全体のサイクルタイムの算出に使用します。これらの時間を分析すると、ボトルネックの特定、SLA遵守状況の測定、プロセス全体のパフォーマンス監視が可能になります。

イベントの時系列を示します。プロセスモデルの発見や、時間に基づくすべてのパフォーマンス指標の算出に欠かせません。

イベントログ、申請の監査証跡、または取引テーブルにあり、「タイムスタンプ」、「作成日」、「開始時刻」などの名称が付いていることがよくあります。

顧客申請IDは、新しい顧客のオンボーディング依頼が開始されてから完了または終了するまで、各依頼に割り当てられる一意のキーです。この識別子は、1件のオンボーディングに関係するすべての個別のアクティビティ、イベント、データポイントを結び付ける中心的な軸であり、プロセスマイニングにおいて最も重要な属性です。

分析では、このIDによって顧客ごとのエンドツーエンドプロセスを再構成できます。申請の進捗を追跡し、合計サイクルタイムを算出し、他の申請と経路を比較できます。すべてのプロセスバリアント、ボトルネック、パフォーマンス指標は申請単位で分析されます。これは、この属性を正しく特定し、ケースIDとして使用することで初めて可能になります。

関連するすべてのイベントを1つのエンドツーエンドプロセスにまとめるために不可欠であり、プロセスマイニング分析の基盤となります。

通常、顧客申請システムまたはケース管理システムのヘッダーや主要テーブルにあります。

ソースシステム属性は、特定のアクティビティのデータを生成したアプリケーションまたはプラットフォームを示します。複雑な環境では、KYCプロセスが複数のシステムにまたがることがあります。たとえば、申請提出にはCRM、リスク評価には専用のKYCプラットフォーム、アカウント作成にはコアバンキングシステムを使用します。

ソースシステム別にプロセスを分析すると、技術環境と、それがプロセスに与える影響を把握できます。システム間の連携問題、システム間のデータ遅延、異なるシステムによる記録方法の違いを明らかにできます。この視点は、オンボーディングを支えるシステム構成を効率化したいITチームやプロセス改善チームに役立ちます。

各プロセスステップがどこで発生したかを把握できるため、システム間の非効率やデータ連携の課題を特定できます。

複数のシステムが連携する環境では、データ抽出結果やイベントログに含まれていることがよくあります。

この属性は、直近のデータ抽出または更新の日時を記録します。業務プロセスそのものの一部ではありませんが、データ検証とデータガバナンスに欠かせないメタデータです。分析対象データがどの程度新しいかを明確にします。

プロセス分析では、最終データ更新時刻を把握することが、生成された分析結果の適時性を理解するうえで重要です。データがいつ時点のものかを確認できるため、データへの信頼性が高まり、古い情報に基づく誤解を防げます。継続的な監視では、データ更新の遅延や失敗を検知するアラートの設定に利用でき、プロセスマイニングのダッシュボードを安定して運用できます。

データセットの新しさを示してデータの透明性を確保します。分析結果の有効性と正確性に欠かせません。

データの抽出、変換、ロード（ETL）処理中に生成され、データセットのメタデータに含まれていることがよくあります。

イベント終了時刻は、アクティビティが終了した正確な日時を示します。イベント開始時刻と組み合わせると、個々のタスクの処理時間を正確に算出できます。すべてのシステムが開始時刻と終了時刻の両方を提供するわけではなく、完了を示す単一の時刻だけを提供する場合もあります。

終了時刻があると、パフォーマンス分析の精度が高まります。たとえば、「平均コンプライアンスレビュー時間」のような詳細な指標を作成し、従業員がタスクに実際に取り組んだ時間（処理時間）と、タスクがキューで待機していた時間（待ち時間）を区別できます。この詳細さは、ボトルネックを正確に特定し、リソース容量とプロセスの引き継ぎのどちらに改善が必要かを判断するうえで重要です。

アクティビティの処理時間を正確に算出できるため、実作業時間と待機時間を区別できます。

開始時刻とともにイベントログや取引テーブルにあります。「終了時刻」、「完了日」、「変更日時」などの名称が付いている場合があります。

ユーザーIDは、プロセス内の特定のアクティビティを実行した担当者またはシステムボットを識別します。コンプライアンス担当者、データ入力担当者、自動リスクスコアリングエンジンなどが該当します。正確なリソース分析には、ユーザー識別情報の一貫性が欠かせません。

この属性によって、プロセスを人の視点から分析できます。作業量の分布、個人やチームのパフォーマンス、リソース配分を分析するために必要です。ユーザーIDでプロセスマップを絞り込むと、担当者ごとのタスク処理方法、トレーニングの機会、作業配分の偏りを把握できます。また、異なる担当者間での作業の引き継ぎを明らかにし、協働状況の分析にも役立ちます。

作業量、リソースのパフォーマンス、協働パターンを分析できるため、リソース管理とトレーニングの改善につながります。

システムの監査証跡や取引ログにあり、レコードを作成または最後に変更したユーザーに紐付いていることがよくあります。

ユーザー部門は、アクティビティを実行したユーザーが所属する機能グループまたはチームを示します。たとえば、「コンプライアンス」、「顧客オンボーディング」、「オペレーション」などです。個人を示すユーザーIDよりも上位の組織情報を提供します。

部門の視点でプロセスを分析すると、部門横断の協働を理解し、組織全体のボトルネックを特定できます。チーム間の引き継ぎを可視化できるため、遅延や非効率の主な要因を把握できます。この情報は、チーム構成の見直し、責任範囲の明確化、コミュニケーション経路の改善に役立ち、よりスムーズなオンボーディングにつながります。

プロセスのパフォーマンスとチーム間の引き継ぎを分析し、部門横断の協働を改善する機会を明らかにできます。

通常、ユーザーIDに紐付くユーザープロファイルデータに含まれているか、取引に直接記録されています。

リスクレベルはKYCプロセスの重要な出力であり、業種、地域、取引パターンなどの要素に基づいて顧客を分類します。この分類によって、申請に必要な確認やデューデリジェンスの水準が決まります。

プロセスマイニングでは、コンフォーマンス分析やバリアント分析に使える重要な軸です。設計上、高リスク顧客のプロセスは低リスク顧客よりも異なり、厳格であるべきです。リスクレベルごとの実際のプロセスフローを想定手順と比較すると、組織内の方針や規制への適合状況を確認できます。「高リスク顧客には必ず強化されたデューデリジェンスを実施しているか」「低リスク顧客に時間をかけすぎていないか」といった問いにも答えられます。

コンプライアンスとリスク管理に欠かせない属性であり、リスクプロファイルに応じてデューデリジェンスのプロセスが適切に変わっているかを分析できます。

リスクエンジンが算出するか、コンプライアンス担当者が手動で割り当てます。顧客または申請の主要レコードに保存されます。

申請ステータスは、「承認済み」、「却下」、「取り下げ」など、申請の最終的な処理結果を示します。プロセスの業務上の結果を表し、パフォーマンス測定における重要な軸です。

この属性は、結果に基づく分析に欠かせません。成功した結果につながるプロセス経路と、却下に至る経路を比較できます。アナリストは、却下率の高いプロセスパターンを特定し、「申請却下率」などのKPIを算出し、「オンボーディングファネル分析」を作成して、申請者がどの段階で離脱するかを確認できます。申請が失敗する理由を理解することが、成功率を高めるプロセス改善の第一歩です。

各ケースの業務上の結果を定義し、申請が却下される理由や承認率を改善する方法を分析できます。

通常、ケースまたは申請の主要テーブルにあり、レコードの最終状態を示します。

顧客タイプは、申請者を「個人」、「法人」、「信託」、「非営利団体」などのカテゴリーに分類します。顧客タイプによって、オンボーディングの要件やプロセスの複雑さが大きく異なることがあります。

分析における重要なセグメント属性です。顧客タイプでプロセスマップやKPIを絞り込むと、大きな違いを明らかにできます。たとえば、法人顧客のオンボーディングでは、個人には必要ない実質的所有者の確認など、より複雑なステップが通常必要です。この分析によって、各セグメントのプロセスバリアントをできるだけ効率的にし、改善内容を調整できます。

プロセスを顧客タイプ別に分けて分析し、それぞれのオンボーディングを比較・改善できます。

通常、申請プロセスの開始時に取得され、顧客または申請の主要テーブルに保存されます。

サービスレベル合意（SLA）目標日は、顧客のオンボーディングプロセスを完了するために設定された期限です。社内方針や契約上の義務に基づいて決まることが多く、処理の適時性を測る基準になります。

この属性は、「SLAパフォーマンス監視」ダッシュボードの基盤です。申請の実際の完了日とSLA目標日を比較すると、「SLA遵守率」を算出できます。SLAを超過したケースを分析すれば、遅延の原因となっている具体的なアクティビティや部門を特定できます。作業キューとリソース配分を先回りして管理し、SLA違反を減らし、顧客満足度を高められます。

パフォーマンスの基準となり、SLA遵守状況の測定や遅延リスクのあるケースの特定に役立ちます。

通常、申請の種類やその他の条件に基づいてケース作成時に算出され、申請の主要レコードに保存されます。

申請ステータスが「却下」の場合、却下理由には「ドキュメント不備」、「高リスクプロファイル」、「制裁対象者との一致」など、具体的な原因が記録されます。この属性によって、失敗したプロセスの背景を把握できます。

却下理由の分析は、「申請却下分析」ダッシュボードの基盤です。オンボーディングプロセスで頻発する失敗要因を理解するための根本原因分析に役立ちます。理由を分類して件数を把握すると、改善の優先順位を付けられます。たとえば「ドキュメント不備」が主な理由であれば、顧客向けの案内を分かりやすくしたり、ドキュメント提出ポータルを改善したりできます。

申請が失敗した根本原因を示し、却下率の低減と顧客体験の改善に向けた対策を講じられます。

通常、申請またはケースの主要テーブルに保存され、ステータスが「却下」に設定された際に入力されます。

この属性は、顧客が申請を提出する際に使用した方法を示します。たとえば、「Webポータル」、「モバイルアプリ」、「支店窓口」などです。チャネルによって、データ取得の手順や顧客体験が異なる場合があります。

チャネル別にプロセスを分析すると、各顧客接点のパフォーマンスと効率を評価できます。「モバイルからの申請はWebからの申請より早く処理されるか」「支店窓口で提出された申請は手戻り率が高いか」といった問いにも答えられます。こうした発見は、すべてのチャネルにおける顧客体験の最適化や、リソースの効果的な配分に役立ちます。

Web、モバイル、対面など、異なる申請チャネル間でプロセス効率と顧客体験を比較できます。

通常、申請が最初に作成されたプロセスの開始時点で記録されます。

この真偽値属性によって、ソフトウェアやボットが実行したタスクと、人のユーザーが実行したタスクを区別できます。自動化されたアクティビティには、初期データ検証、制裁審査、定型的な通知の送信などがあります。

この属性を分析すると、自動化施策の効果を評価できます。自動化されたステップと手動のステップの速度や結果を比較することで、コストやサイクルタイムを削減するために、さらに自動化できる箇所を特定できます。また、自動化システムのパフォーマンスを監視し、エンドツーエンドプロセス内で想定どおりに機能しているかを確認できます。

プロセスにおける自動化の効果と効率を測定し、ロボット化やシステム化をさらに進める機会を特定できます。

イベントログの専用項目として記録されるか、ユーザーIDに基づいて導出できます。たとえば、IDが「SYSTEM」や「BOT」の場合です。

Customer IDは、複数のやり取りや申請にわたって維持される顧客の一意の識別子です。Customer Application IDが1回のオンボーディングの流れを追跡するのに対し、Customer IDは同じ顧客による複数回のオンボーディング申請や、その他のプロセスを関連付けることができます。

この属性を使うと、単一のケースを超えた顧客中心の分析が可能になります。再申請者の把握、顧客との長期的な関係の分析、「Loan Application」や「Account Maintenance」などの他のプロセスとのオンボーディングプロセスの関連付けに役立ちます。単一プロセスの分析には必須ではありませんが、より複雑なオブジェクト中心のプロセスマイニングではデータを豊かにします。

顧客中心の視点から、同じ顧客に関する複数回のオンボーディングや異なるプロセスを関連付けられます。

通常、中央の顧客マスターデータシステムに保存され、申請レコードに関連付けられています。

顧客所在国は、申請者の地理的な所在地を示します。国によって規制やリスク要因が大きく異なるため、KYCプロセスにおいて重要な情報です。

地理的な分析によって、さらに重要な視点が得られます。オンボーディングプロセスは、国ごとの法的要件によって異なる場合があります。顧客所在国で絞り込むと、管轄区域ごとのプロセスバリアントが正しく実行されているか確認できます。また、リスクの高い国からの申請では、強化されたデューデリジェンスが必要なため、サイクルタイムが長くなるといったパフォーマンスの違いも明らかにできます。

地理的条件に基づくプロセスの違いやパフォーマンスを分析できます。現地の規制へのコンプライアンスを確保するうえで欠かせません。

申請プロセス中に顧客から取得し、顧客レコードまたは申請レコードに保存されます。