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

アクティビティ名は、顧客のオンボーディングにおける「申請提出」「コンプライアンスレビュー開始」「申請承認」など、個別のステップや節目を表します。各アクティビティは、ユーザーまたはシステムが申請を進めるために行った具体的な処理を示します。

この属性は、プロセスマイニングの中核となるプロセスマップを可視化するうえで基本となります。アクティビティの順序や頻度を分析すると、実際のプロセスの流れを把握し、よくある経路やプロセス逸脱を見つけ、手戻りや繰り返しが発生している箇所を特定できます。意味のある分かりやすいプロセスモデルを作成するには、アクティビティ名が明確で一貫していることが重要です。

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

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

イベント開始時刻は、アクティビティの開始日時を正確に示します。ケースID、アクティビティ名と並び、プロセスマイニングに欠かせない3つの要素の1つです。このタイムスタンプにより、ケースごとにイベントを時系列で並べられるため、実際に起きたプロセスの流れを再構成できます。

この属性は、時間に関する分析の基礎となります。終了時刻がある場合はアクティビティの所要時間を、アクティビティ間の待ち時間（引き継ぎ時間）や、オンボーディングプロセス全体のサイクルタイムを算出できます。所要時間を分析することで、ボトルネックの特定、SLAの遵守状況の測定、プロセス全体のパフォーマンスの把握が可能になります。

イベントを時系列に並べるために必要な情報であり、プロセスモデルの発見や時間に関するパフォーマンス指標の算出に欠かせません。

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

顧客申請IDは、新規顧客のオンボーディング申請ごとに割り当てられる一意のキーです。申請の開始から完了または中止まで、同じIDが使われます。このIDによって、1件のオンボーディングに関する個々のアクティビティ、イベント、データポイントが結び付けられるため、プロセスマイニングで最も重要な属性です。

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

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

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

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

ソースシステム別にプロセスを分析すると、システム環境と、それがプロセスに与える影響を把握できます。システム間の連携の問題、データの遅延、記録方法の違いなどが明らかになることがあります。この分析は、オンボーディングを支えるシステムアーキテクチャの効率化を目指すIT部門やプロセス改善チームに役立ちます。

各プロセスのステップがどのシステムで行われるかを把握でき、システム間の非効率やデータ連携の課題を特定しやすくなります。

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

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

プロセス分析では、最終データ更新日時を把握することで、インサイトがどの時点のデータに基づいているかを確認できます。データの鮮度が分かるため、分析結果への信頼につながり、古い情報に基づく誤解を防げます。継続的なモニタリングでは、データ更新の遅延や失敗を検知するアラートの設定にも利用でき、プロセスマイニングのダッシュボードの信頼性維持に役立ちます。

データセットの鮮度を示してデータの透明性を保ち、分析の妥当性と正確性を支えます。

データの抽出、変換、読み込み（ETL）の過程で生成され、データセットのメタデータに含まれていることがよくあります。

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

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

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

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

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

この属性を使うと、プロセスを人の視点から分析できます。業務量の配分、個人やチームのパフォーマンス、リソースの割り当てを分析するうえで欠かせません。プロセスマップをユーザーIDで絞り込むと、担当者ごとのタスク処理状況を把握し、研修の機会を見つけ、業務量の偏りを確認できます。また、担当者間の引き継ぎを明らかにし、連携状況を分析する際にも役立ちます。

業務量、リソースパフォーマンス、連携状況を分析できるため、リソース管理や研修の改善につながります。

システムの監査証跡や取引ログで確認できます。多くの場合、レコードを作成または最後に変更したユーザーに関連付けられています。

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

部門別のプロセス分析は、部門をまたぐ連携や組織全体に共通するボトルネックを理解するうえで重要です。チーム間の引き継ぎを可視化できます。引き継ぎは、遅延や非効率の主な原因となることが少なくありません。この情報は、チーム構成の見直し、責任範囲の明確化、コミュニケーション経路の改善を通じて、オンボーディングをスムーズにするために役立ちます。

チーム間のプロセスパフォーマンスや引き継ぎを分析し、部門をまたぐ連携を改善できる箇所を見つけられます。

ユーザーIDに関連付けられたユーザープロフィールのデータに含まれていることがよくあります。取引データに直接記録される場合もあります。

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

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

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

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

申請ステータスは、「承認済み」「却下」「取り下げ」など、申請の最終的な結果を示します。プロセスの業務上の成果を表し、パフォーマンス測定に欠かせない分析軸です。

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

各ケースの業務上の結果を示すため、申請が却下される理由を分析し、承認率を高める方法を検討できます。

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

顧客種別は、申請者を「個人」「法人」「信託」「非営利団体」などに分類します。顧客の種類によって、オンボーディングに必要な手順やプロセスの複雑さは大きく異なります。

分析では、顧客種別が重要なセグメント属性となります。プロセスマップやKPIを顧客種別で絞り込むと、大きな違いを見つけられます。たとえば、法人顧客のオンボーディングでは、個人の場合には不要な実質的支配者の確認など、より複雑なステップが必要になることがあります。この分析により、顧客層ごとにプロセスを効率化し、適切な改善策を検討できます。

顧客の種類ごとにプロセスを分けて比較し、それぞれのオンボーディングを最適化できます。

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

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

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

パフォーマンスを測る基準となり、SLAの遵守状況や遅延リスクのあるケースを把握できます。

ケースの作成時に、申請の種類などの条件に基づいて算出され、メインの申請レコードに保存されることがよくあります。

申請ステータスが「却下」の場合、却下理由には「文書の不備」「リスクが高い」「制裁対象との一致」など、具体的な原因が記録されます。この属性により、プロセスが失敗した背景を把握できます。

却下理由の分析は、「申請却下分析」ダッシュボードの基礎となります。オンボーディングプロセスでよく発生する問題を理解するための根本原因分析に役立ちます。理由を分類して件数を把握することで、組織は改善の優先順位を決められます。たとえば「文書の不備」が主な理由であれば、顧客向けの案内を分かりやすくしたり、文書提出ポータルを改善したりすることが考えられます。

申請が却下された根本原因を把握できるため、却下率の低減と顧客体験の向上に向けた改善策を検討できます。

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

この属性は、顧客が申請を提出した方法を示します。「ウェブポータル」「モバイルアプリ」「支店窓口」などが該当します。チャネルによって、データの取得方法や顧客体験が異なる場合があります。

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

ウェブ、モバイル、対面など、申請チャネルごとにプロセスの効率と顧客体験を比較できます。

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

この真偽値属性は、ソフトウェアやボットが実行したタスクと、人が実行したタスクを区別します。自動処理の例として、初期データの検証、制裁対象のスクリーニング、定型メールの送信などがあります。

自動化の取り組みがどの程度効果を上げているかを評価するうえで、この属性の分析が役立ちます。自動処理と手動処理の速度や結果を比較することで、コストやサイクルタイムを減らすために、さらに自動化できる箇所を見つけられます。また、自動システムのパフォーマンスを監視し、プロセス全体で想定どおりに動作しているかを確認できます。

プロセスにおける自動化の効果と効率を測定し、ロボットやシステムによる改善をさらに進められる箇所を見つけられます。

イベントログの専用フィールドに記録されている場合があります。また、ユーザーIDが「SYSTEM」や「BOT」の場合など、ユーザーIDから判定することもできます。

顧客IDは、複数のやり取りや申請を通じて同じ顧客を識別する一意のIDです。顧客申請IDが1件のオンボーディングを追跡するのに対し、顧客IDを使うと、同じ顧客による複数回の申請や他のプロセスを関連付けられます。

この属性を使うと、単一のケースにとどまらず、顧客を軸に分析できます。再申請の状況や顧客との長期的な関係を把握したり、オンボーディングを「ローン申請」や「アカウント管理」などの他のプロセスと結び付けたりする際に役立ちます。単一プロセスの分析には必須ではありませんが、オブジェクト中心のプロセスマイニングを行う場合にデータを充実させます。

顧客を軸に分析し、同じ顧客による複数回のオンボーディングや関連する別のプロセスを結び付けられます。

通常、顧客のマスターデータを管理する中央システムにあり、申請レコードに関連付けられています。

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

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

地域ごとのプロセスの違いやパフォーマンスを分析でき、現地の規制への準拠状況を確認するうえで役立ちます。

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