KYC顧客オンボーディング用データテンプレート
KYC顧客オンボーディング用データテンプレート
- 収集を推奨する属性
- 追跡する主要なアクティビティ
- ACTICOからのデータ抽出ガイド
KYC顧客オンボーディングの属性
| 名前 | 説明 | ||
|---|---|---|---|
| アクティビティ名 ActivityName | 顧客オンボーディングプロセスで実行された、個々の業務イベントまたはタスクの名前です。 | ||
| 説明 この属性には、KYCプロセスで発生する各ステップやアクティビティの名前が記録されます。たとえば、「申請を提出」「リスク評価を実施」「申請を承認」などです。これらがプロセスマップを構成する順序立った要素になります。 アクティビティ名を分析すると、プロセスの流れを可視化し、頻繁またはまれに発生するアクティビティを特定して、ボトルネックや手戻りのループを検出できます。どのような作業がどの順序で行われているかを把握するための基礎となり、バリアント分析やコンプライアンスチェックに欠かせません。 重要な理由 プロセスマップの各ステップを定義する属性です。プロセスの流れを可視化し、逸脱を特定するとともに、アクティビティの頻度や順序を分析できます。 入手先 通常、ACTICO内のイベントログテーブルにあり、イベントまたはタスクの種類を示すフィールドに記録されています。詳細はACTICOの文書を確認してください。 例 申請を提出リスク評価を実施コンプライアンス審査を完了申請を却下 | |||
| イベント時刻 EventTime | 特定のアクティビティが開始または発生した時刻を示すタイムスタンプです。 | ||
| 説明 イベント時刻は、アクティビティがシステムに記録された正確な日時です。顧客申請案件内のすべてのイベントを時系列に並べ、オンボーディングの流れを示します。 この属性は、時間に基づくあらゆる分析に欠かせません。アクティビティ間のサイクルタイムの算出、遅延や待ち時間の特定、案件全体の所要時間の測定、サービスレベル契約(SLA)への準拠状況の確認に使われます。案件ごとのタイムスタンプの順序から、プロセスマイニングツールは実際に発生したプロセスの流れを再構成できます。 重要な理由 イベントを時系列に並べるための属性です。所要時間の算出、ボトルネックの発見、プロセスの時間経過の分析に欠かせません。 入手先 ACTICOのイベントログテーブルにある、記録された各アクティビティに対応するタイムスタンプです。詳細はACTICOの文書を確認してください。 例 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T15:45:10Z | |||
| 顧客申請 CustomerApplication | 個々の顧客オンボーディング申請を一意に識別するIDで、プロセス分析におけるケースIDとして使われます。 | ||
| 説明 顧客申請は、1人の顧客のオンボーディングに関するすべてのイベントとアクティビティをまとめる主要なケース識別子です。初回の申請から承認または却下の最終判断まで、KYCプロセスの一連の実行を表します。 プロセスマイニングでは、この属性を使って各申請の開始から完了までの流れを再構成します。アナリストはアクティビティの順序を追跡し、サイクルタイム全体を測定し、申請ごとに異なるプロセス経路やバリアントを比較できます。同じ顧客申請IDを持つイベントは、すべて同じ案件の一部として扱われます。 重要な理由 これはプロセスマイニングの基本となる属性です。関連するすべてのイベントを1つのプロセス実行にまとめ、顧客ごとのオンボーディング体験を開始から完了まで分析できます。 入手先 ACTICOの主要な申請テーブルまたは案件管理テーブルにある主キーです。テーブル名とフィールド名については、ACTICOの文書を確認してください。 例 APP-2023-001234APP-2023-001235APP-2024-000001 | |||
| ソースシステム SourceSystem | イベントデータの取得元となる記録システムです。 | ||
| 説明 この属性は、データが生成された情報システムを示します。このプロセスでは常に「ACTICO」ですが、複数のシステムを対象とする分析では、データの取得元を区別するために役立ちます。 プロセスマイニングでは、データガバナンスと検証に欠かせない属性です。データの取得元を正しく特定できるため、複数のシステムのデータを統合してプロセス全体を把握する際に重要です。また、データ品質の問題が発生した場合に、原因を元のシステムまでたどって調査できます。 重要な理由 データの取得元に関する重要なコンテキストを示し、データリネージとガバナンスを確保します。複数のソースからデータを統合する際に欠かせません。 入手先 通常は、データの抽出・変換時にデータセットを識別するため、「ACTICO」という固定値を付与します。 例 ACTICOACTICOプラットフォームActico KYCモジュール | |||
| 最終データ更新日時 LastDataUpdate | ソースシステムのデータが最後に更新または抽出された日時です。 | ||
| 説明 この属性には、ACTICOからデータを最後に取得した日時が記録されます。個々のイベントではなくデータセット全体に適用されるメタデータで、分析対象データの鮮度を把握するために使います。 ダッシュボードやレポートでは、データがどの時点のものかを把握するうえで重要な情報です。インサイトの鮮度に関する期待値を調整できるほか、ほぼリアルタイムのデータが必要な業務のモニタリングにも欠かせません。この日時を表示することで、提示するデータの透明性と信頼性を高められます。 重要な理由 データの鮮度を示すため、最新の情報に基づいて分析しているかを確認できます。業務上の意思決定に欠かせない情報です。 入手先 この値は、データの抽出・変換・ロード(ETL)処理中に生成、保存されます。ETLジョブが正常に完了した日時を示します。 例 2024-05-20T08:00:00Z2024-05-21T08:00:00Z | |||
| SLA目標日 SlaTargetDate | 顧客のオンボーディングプロセスを完了する予定日です。 | ||
| 説明 SLA目標日は、社内のサービスレベル合意に基づく顧客オンボーディングの完了期限です。申請日と標準処理期間をもとに算出する場合があります。 この属性は、SLAの遵守状況を監視するうえで欠かせません。ケースの実際の完了日とSLA目標日を比較することで、期限内に完了したか、SLAに違反したかを判定できます。「オンボーディングSLAパフォーマンス」ダッシュボードの基礎となり、「オンボーディングSLA遵守率」KPIの算出にも使います。 重要な理由 期限内に処理できたかを測る基準となり、SLAの遵守状況を直接監視、報告できます。 入手先 ACTICOのメインケーステーブルの項目として保存されている場合と、業務ルール(例:申請日から5営業日後)に基づいて算出する場合があります。 例 2023-11-01T17:00:00Z2023-11-02T17:00:00Z2023-11-03T17:00:00Z | |||
| リスクレベル RiskLevel | 顧客申請の算定リスクレベルです。「低」「中」「高」などで示します。 | ||
| 説明 この属性は、顧客の評価済みリスク区分を示します。リスク区分によって、その後のKYCプロセスの複雑さや確認の厳格さが変わることがあります。高リスクの顧客には、低リスクの顧客よりも追加の確認や承認が必要になる場合があります。 プロセスマイニングでは、リスクレベルを比較分析の軸として利用できます。リスクに応じて、想定どおりにプロセスが異なる経路をたどっているかを確認できます。たとえば、高リスクの顧客全員に対して強化された顧客管理が行われているかを検証できます。「リスク評価プロセスの流れ」ダッシュボードの重要な属性です。 重要な理由 リスクに基づいてケースを分類し、コンプライアンス方針に沿って、リスク特性に応じたプロセスになっているかを分析できます。 入手先 ACTICOのメイン申請テーブルにケース単位で保存される重要なデータ項目です。 例 低中高 | |||
| 却下理由 RejectionReason | 顧客の申請が却下された具体的な理由です。 | ||
| 説明 申請の最終ステータスが「却下」の場合、この属性にその理由が記録されます。例として、「文書の不備」「本人確認に失敗」「高リスク判定」などがあります。 根本原因分析に欠かせない属性です。却下理由ごとの件数を分析すると、プロセスや顧客からの申請における構造的な問題を特定できます。たとえば、文書の不備による却下が多い場合、申請手順の説明が分かりにくい可能性があります。この属性は、「申請却下率と理由」ダッシュボードを支えます。 重要な理由 申請が却下された理由を示し、根本原因の分析を通じて却下率の低減とプロセスの効率化に役立ちます。 入手先 通常はACTICOのメインケーステーブルまたは申請テーブルにあり、「申請ステータス」が「却下」の場合にのみ値が設定されます。 例 文書の不備本人確認に失敗制裁対象者との一致高リスクスコア | |||
| 実行ユーザー InitiatingUser | アクティビティを実行した従業員のユーザーIDまたは名前です。 | ||
| 説明 この属性は、アクティビティを実行したユーザーまたはシステムエージェントを特定します。プロセスの各ステップと、実行した個人やチームを関連付けます。 ユーザー別のパフォーマンス分析は、一般的な分析要件の1つです。この属性を使うと、作業負荷の分布、個々の処理時間、ユーザー間やチーム間のパフォーマンス比較を示すダッシュボードを作成できます。高い成果を上げている担当者や、追加のトレーニングが必要な担当者を把握できるほか、リソースの配置や利用状況の分析にも役立ちます。 重要な理由 プロセスのアクティビティを特定のユーザーに関連付けます。個人やチームごとのパフォーマンス分析に役立ち、トレーニングの必要性やリソースの偏りを把握できます。 入手先 通常は、ACTICOのイベントログまたはトランザクション履歴テーブルで各イベントとともに保存されています。詳しくはACTICOの文書をご確認ください。 例 山田太郎鈴木花子SYSTEM_USER | |||
| 申請ステータス ApplicationStatus | 顧客のオンボーディング申請の最終結果または現在の状態です。 | ||
| 説明 この属性は、通常「承認済み」または「却下」となるケースの最終結果を示します。処理中のケースの状態を示すこともできます。結果に基づく分析に欠かせない属性です。 申請が承認または却下された理由を把握することは、KYCプロセスマイニングの主な目的の1つです。この属性でプロセスマップを絞り込み、承認された申請と却下された申請の一般的な流れを比較することで、望ましくない結果につながるパターンを特定できます。また、「申請却下率」KPIの算出にも使います。 重要な理由 各ケースの結果を示し、成功したプロセスと成功しなかったプロセスの比較や、却下率の算出を可能にします。 入手先 ケース単位の属性で、通常はACTICOのメインケーステーブルまたは申請テーブルにあります。申請の最終ステータスを示します。 例 承認済み却下処理中情報待ち | |||
| 終了時刻 EndTime | 特定のアクティビティが完了した日時です。 | ||
| 説明 終了時刻は、アクティビティの完了時点を示します。開始時刻(EventTime)と組み合わせることで、各タスクの正確な所要時間(処理時間)を算出できます。イベントによっては、即時に完了するため、明確な終了時刻が記録されない場合もあります。 この属性は、各ステップにかかる時間を測定するなど、パフォーマンス分析の基本となります。詳細なパフォーマンスダッシュボードの作成や、時間のかかるアクティビティの特定に役立ち、「文書レビューの平均時間」などのKPIの算出にも必要です。 重要な理由 アクティビティの正確な所要時間(処理時間)を算出できます。パフォーマンスのボトルネックを特定し、リソースの効率を分析するうえで重要です。 入手先 開始時刻と同様、通常はACTICOのイベントログテーブルに記録されています。システムによっては、1つのイベントレコードの開始時刻と終了時刻を別々の列に保存します。詳しくはACTICOの文書をご確認ください。 例 2023-10-26T10:15:00Z2023-10-26T12:00:00Z2023-10-27T16:00:15Z | |||
| 部門 Department | アクティビティを実行する事業部門またはチームです。 | ||
| 説明 この属性は、アクティビティを「コンプライアンス」「オンボーディングチーム」「顧客対応」などの組織単位に割り当て、プロセスの流れを組織の観点から把握できるようにします。 部門別の分析は、組織内の各部門間でどのように業務が引き継がれているかを理解するうえで重要です。部門間のボトルネックの特定、部門ごとの効率の測定、チーム間のリソース配分の分析に役立ちます。ダッシュボードを部門で絞り込めば、管理者はチーム固有のパフォーマンスを確認できます。 重要な理由 組織の観点から分析できるため、部門をまたぐ遅延の特定や、チーム単位のパフォーマンス評価に役立ちます。 入手先 イベントデータに直接保存されている場合と、ユーザーと部門の対応を示す人事マスターデータテーブルをユーザーデータに結合して取得する場合があります。詳しくはACTICOの文書をご確認ください。 例 Complianceオンボーディングチームカスタマーサービス | |||
| SLAステータス SlaState | ケースがSLAを達成したか、違反したか、違反するリスクがあるかを示す算定済みのステータスです。 | ||
| 説明 この属性は、サービスレベル合意に対するケースの状況を分類して示します。ケースの完了時刻(未完了の場合は現在時刻)を「SlaTargetDate」と比較して算出します。 日付の比較結果を分かりやすいステータスに置き換えることで、SLAの報告を簡潔にできます。ダッシュボードでは、円グラフやゲージを使って「達成」と「違反」のケースの割合を明確に表示できます。「オンボーディングSLAパフォーマンス」ダッシュボードの重要な要素であり、「オンボーディングSLA遵守率」KPIにも直接役立ちます。 重要な理由 各ケースのSLA遵守状況を明確に分類して示します。報告を簡潔にし、目標に対するパフォーマンスを分かりやすく表示できます。 入手先 ケースの完了日時と「SlaTargetDate」を業務ロジックで比較して算出する属性です。 例 達成違反リスクあり | |||
| 国 Country | オンボーディングを申請した顧客の居住国です。 | ||
| 説明 この属性は顧客の国を示し、KYCプロセスに大きく影響する場合があります。法域によって規制要件が異なるため、追加のステップや別の手順が必要になることがあります。 国別にプロセスを分析すると、地域間のパフォーマンスを比較できます。特定の国でサイクルタイムが長い、または却下率が高い状態が続いている場合、規制上の制約や市場固有の課題が考えられます。グローバルに事業を展開する組織が、各地域のコンプライアンス要件を守りながらプロセスを標準化するうえでも重要な視点です。 重要な理由 地域の観点から分析できるため、異なる規制法域におけるプロセスの違いやパフォーマンスの差を把握できます。 入手先 ACTICOシステムのケースまたは顧客単位で保存される、顧客情報の基本項目です。 例 USADEUGBRSGP | |||
| 手戻りかどうか IsRework | アクティビティが繰り返されたステップ、または手戻りループの一部かを示す算定済みフラグです。 | ||
| 説明 この真偽値属性は、追加情報の依頼後に「文書レビュー」を再度行う場合など、同じケース内で2回目以降に実行されたアクティビティを示します。手戻りは、プロセスの非効率につながることが多いため、特定が必要です。 手戻りの特定は、プロセスマイニングの主な目的の1つです。このフラグを使うと、「文書の手戻り率」KPIなどを算出し、手戻りを定量化できます。プロセスマップで手戻りループを強調表示すれば、プロセスがどこで前のステップに戻っているかを確認できます。これにより、品質上の問題や、一度で正しく完了できていない箇所を特定できます。 重要な理由 作業の繰り返しを明らかにし、プロセスの非効率を直接測定できます。品質や説明の明確さに問題があるアクティビティの特定にも役立ちます。 入手先 算定属性です。同じケース内で繰り返されたアクティビティを検出するロジックを、プロセスマイニングツール内またはデータ変換時に定義します。 例 truefalse | |||
| 自動処理かどうか IsAutomated | アクティビティがシステムによって自動で実行されたか、ユーザーが手動で実行したかを示すフラグです。 | ||
| 説明 この真偽値属性は、ユーザーが実行したタスクと、自動バックグラウンドチェックやリスクスコア算出など、システムが自動で実行したタスクを区別します。 この属性を分析すると、自動化施策の効果を評価できます。自動処理と手動処理の時間を比較し、手作業が多く残るプロセスの箇所を特定できます。また、効率の向上や運用コストの削減に向けて、さらなる自動化の余地を見つけるのにも役立ちます。 重要な理由 人が行うタスクとシステムが行うタスクを区別できます。自動化の効果測定や、今後の効率向上につながる箇所の特定に欠かせません。 入手先 「実行ユーザー」属性から判定できる場合があります(ユーザーが「SYSTEM」の場合など)。イベントログに専用のフラグがある場合もあります。詳しくはACTICOの文書をご確認ください。 例 truefalse | |||
| 顧客種別 CustomerType | 個人や法人など、顧客の分類です。 | ||
| 説明 この属性は、申請者を個人や法人などに分類します。KYCプロセスは顧客種別によって大きく異なることがあり、法人のオンボーディングは個人よりも複雑になる傾向があります。 顧客種別を分析軸にすると、同じデータセット内で異なるプロセスを明確に分けて比較できます。たとえば、プロセスマップを「法人」に絞り込むことで、個人顧客のより単純なプロセスに分析結果が左右されることなく、法人特有の課題、ボトルネック、サイクルタイムを把握できます。 重要な理由 顧客区分ごとにプロセスを分けて分析できます。プロセスの流れや複雑さが大きく異なる場合でも、より正確な分析が可能です。 入手先 ACTICOのケースまたは顧客単位で保存される基本的な属性です。 例 個人法人小規模事業者 | |||
KYC顧客オンボーディングのアクティビティ
| アクティビティ | 説明 | ||
|---|---|---|---|
| コンプライアンス審査を完了 | コンプライアンス部門による手動審査の終了を示し、承認、却下、または追加対応の依頼が決定されます。案件のステータスが「コンプライアンス審査待ち」から「コンプライアンス承認済み」などの次の状態に変わった時点から推定されます。 | ||
| 重要な理由 コンプライアンス審査段階の終了イベントです。審査全体の所要時間の算出やチームの処理量の分析に欠かせません。 入手先 申請のステータス履歴ログから推定します。案件が「コンプライアンス審査中」の状態を抜け、判断が下されたことを示すタイムスタンプを確認してください。 記録 案件のステータスが「コンプライアンス審査待ち」から「コンプライアンス承認済み」などに変わった時点から推定します。 イベントタイプ inferred | |||
| コンプライアンス審査を開始 | コンプライアンス部門による手動審査の開始を示します。高リスクまたは要確認の申請が対象となることがよくあります。通常、案件のステータスが「コンプライアンス審査待ち」に変わった時点や、コンプライアンス担当者の作業キューに案件が割り当てられた時点から推定されます。 | ||
| 重要な理由 このアクティビティは、コンプライアンス審査のボトルネックを測定する起点です。「コンプライアンス審査を完了」するまでの時間は、この重要な段階の遅延を特定するための重要業績評価指標です。 入手先 申請のステータス履歴または監査証跡から推定します。「コンプライアンス審査中」へのステータス変更、またはコンプライアンス関連のユーザーグループへの割り当てに対応するタイムスタンプを確認してください。 記録 案件のステータスが「コンプライアンス審査待ち」に変わった時点、またはコンプライアンスチームに割り当てられた時点から推定します。 イベントタイプ inferred | |||
| リスク評価を実施 | ACTICOの意思決定エンジンを実行し、顧客申請のリスクスコアまたは評価を算出するアクティビティです。システムの主要機能の一つであり、リスク評価ルールセットの実行時に明示的なイベントとして記録されます。 | ||
| 重要な理由 リスク評価は、その後のプロセス経路を左右する重要な意思決定ポイントです。このアクティビティを分析すると、リスクレベルがプロセスのバリアントや所要時間にどう影響するかを把握できます。 入手先 ACTICOの主要なイベントであり、意思決定ログまたは実行ログに記録されるはずです。通常、これらのログにはケースID、実行されたルール、算出されたリスクスコアが含まれます。 記録 リスクスコアの算出完了時に、ACTICOの意思決定エンジンが記録するイベントです。 イベントタイプ explicit | |||
| 申請を却下 | 顧客の申請を却下し、オンボーディングプロセスを終了する最終判断を示します。申請レコードの最終ステータス変更として記録される、重要な終了状態です。 | ||
| 重要な理由 主要な失敗終了イベントです。このアクティビティで終了した案件を分析すると、却下率や却下理由を把握し、プロセス全体の成果を改善できます。 入手先 主要な申請テーブルまたは案件テーブルの最終ステータス項目から推定します。「却下」「不承認」「終了・却下」などの最終ステータスを確認してください。 記録 案件マスターデータで、案件の最終ステータスが「却下」に更新されます。 イベントタイプ inferred | |||
| 申請を承認 | 顧客のオンボーディング申請を承認する最終的な業務判断を示すアクティビティです。申請のライフサイクルにおける明確な最終ステータス変更として記録される、重要な節目です。 | ||
| 重要な理由 この節目は口座作成に先立つもので、申請が成功したことを示します。ここに到達するまでの時間を分析することは、理想経路の所要時間を把握するうえで重要です。 入手先 主要な申請テーブルまたは案件テーブルの最終ステータス項目から推定します。「承認済み」「承認完了」など、同様の最終的な肯定ステータスを確認してください。 記録 案件マスターデータで、案件の最終ステータスが「承認済み」に更新されます。 イベントタイプ inferred | |||
| 申請を提出 | 新規顧客の申請がACTICOシステムに正式に届いた時点で、KYCオンボーディングプロセスが始まります。このアクティビティは明示的なイベントとして記録され、通常、新しい案件または申請レコードの作成時に正確なタイムスタンプが付与されます。 | ||
| 重要な理由 主要な開始イベントであるこのアクティビティは、オンボーディング全体のサイクルタイムの算出と申請件数の追跡に欠かせません。以降のプロセスパフォーマンスを測定する際のベースラインとなるタイムスタンプです。 入手先 通常、ACTICO内の申請または案件の作成ログに明示的に記録されています。申請提出イベントに関するテーブルや、主要な案件レコードの作成タイムスタンプを確認してください。 記録 新しい申請案件の作成時に記録されるイベントです。 イベントタイプ explicit | |||
| 顧客オンボーディングを完了 | 顧客のオンボーディングが完了し、申請案件が終了したことを示す、プロセスの最終アクティビティです。案件に「オンボーディング完了」や「終了・承認済み」などの最終ステータスが設定された時点から推定されます。 | ||
| 重要な理由 主要な成功終了イベントであるこのアクティビティは、オンボーディングが完了したすべての顧客について、開始から完了までのサイクルタイムを算出するために欠かせません。理想経路の分析に使う最終タイムスタンプとなります。 入手先 顧客申請案件の最終ステータス項目から推定します。案件が最終的な成功ステータスに移行した時刻を確認してください。 記録 案件の最終ステータスが「完了」または「終了」に更新された時点から推定します。 イベントタイプ inferred | |||
| 顧客が文書をアップロード | 顧客がACTICOと連携したポータルなどのチャネルを通じて、必要な本人確認書類や補足書類を提出した時点で発生するアクティビティです。通常、各文書のアップロードは、システムの文書管理ログまたは案件ログに個別の明示的なイベントとして記録されます。 | ||
| 重要な理由 顧客側の対応に関わる重要な節目です。このイベントを追跡することで、顧客の応答時間を測定し、その後の文書審査にかかる時間を分析できます。 入手先 文書の処理や案件への添付に関するイベントログを確認してください。ACTICOのデータベースでは、専用の文書管理テーブルや証跡管理テーブルに記録されていることがよくあります。 記録 文書が案件に添付された際にシステムが記録するイベントです。 イベントタイプ explicit | |||
| バックグラウンドチェックを開始 | AMLチェックや信用履歴の審査など、自動または手動のバックグラウンドチェックを開始した時点を示します。外部サービス事業者が関わる場合もあり、システムがチェックを開始した際に明示的なイベントとして記録されることがよくあります。 | ||
| 重要な理由 バックグラウンドチェックの開始は、デューデリジェンスにおける重要な節目です。これを追跡すると、外部データ提供者への依存関係やデータ取得にかかる時間を把握できます。 入手先 バックグラウンド審査の開始を示すシステムログまたは監査証跡の記録を確認してください。多くの場合、主要な申請案件IDに関連付けられています。 記録 ワークフローエンジンがバックグラウンドチェックサービスへの呼び出しを開始した際に記録されるイベントです。 イベントタイプ explicit | |||
| 口座を作成 | 承認後、コアバンキングシステムまたはユーザー管理システムに顧客の口座を技術的に作成するアクティビティです。通常、下流システムから成功応答を受け取った後、ACTICOによって明示的なイベントとして記録されます。 | ||
| 重要な理由 このアクティビティは、プロセスが具体的な業務成果につながったことを示します。「申請を承認」してから「口座を作成」するまでの時間から、連携の遅延や最終的な口座設定手順の非効率を把握できます。 入手先 口座設定のために外部システムを呼び出した結果を記録する、ACTICO内の連携ログまたはシステムインターフェースログにあると考えられます。 記録 コア口座システムからAPIの成功応答を受信した際に記録されるイベントです。 イベントタイプ explicit | |||
| 文書審査を完了 | 担当者が顧客から提出された文書の審査を終えたことを示すアクティビティです。文書または案件全体のステータスが「文書確認済み」や「審査完了」に変わった時点などから推定されます。 | ||
| 重要な理由 文書処理の効率を測る重要な節目です。「顧客が文書をアップロード」してからこのアクティビティまでの時間は、手作業による処理の遅延を特定するための重要業績評価指標です。 入手先 申請案件または個々の文書のステータス履歴ログから推定します。文書のステータスが「審査待ち」から「承認済み」または「審査済み」に変わった場合、このアクティビティに該当します。 記録 文書のステータスが「確認済み」または「審査済み」に変わったことから推定します。 イベントタイプ inferred | |||
| 本人確認を実施 | 外部または内部のデータソースと照合して顧客の本人確認を行う、自動または手動のチェックです。第三者の本人確認サービスへのAPI呼び出しと応答の受信が、明示的なイベントとして記録されることがよくあります。 | ||
| 重要な理由 このアクティビティは、コンプライアンス上の重要な手順です。所要時間と結果を分析すると、外部サービスへの依存関係や本人確認プロセスのボトルネックを特定できます。 入手先 通常、案件に関連付けられた自動チェックや第三者サービスの呼び出し結果を記録する連携ログまたは専用のイベントテーブルにあります。 記録 第三者の本人確認サービスへの連携呼び出しで記録されるイベントです。 イベントタイプ explicit | |||
| 申請の初期審査 | 提出された申請について、必要事項がそろっているか、基本的な適格条件を満たしているかを、自動ルールまたは担当者が最初に確認するアクティビティです。申請のステータスが「提出済み」から「審査中」に変わった時点などから推定されることがよくあります。 | ||
| 重要な理由 初回審査の所要時間を分析すると、処理の初期段階で発生する遅延を特定できます。また、問題なく最初のゲートウェイを通過した申請の数も把握できます。 入手先 顧客申請案件に関連するステータス履歴テーブルや監査ログから推定します。ステータスが「新規」または「提出済み」から「審査」に変わった時刻を確認してください。 記録 案件履歴ログで、ステータスが「提出済み」から「レビュー中」に変わったことを検出します。 イベントタイプ inferred | |||
| 追加情報を依頼 | コンプライアンス担当者や引受担当者などの審査担当者が、顧客に追加情報や文書を求めたことを示すイベントです。顧客への通知送信や案件の一時停止を伴うことが多いため、通常は明示的に記録されます。 | ||
| 重要な理由 このアクティビティは、手戻りやサイクルタイムの長期化につながる主な要因です。発生頻度と影響を追跡することで、初期のデータ収集を改善できる箇所を特定できます。 入手先 案件履歴または連絡ログに明示的なイベントとして記録されている可能性があります。「情報提供依頼を送信」などのイベントや、「顧客情報待ち」へのステータス変更を確認してください。 記録 「情報提供依頼を送信」など、ユーザーが明示的に実行したイベントが案件の監査証跡に記録されます。 イベントタイプ explicit | |||
データ抽出ガイド
ステップ
- 管理者アクセス権の取得:データエクスポートへのアクセスと設定に必要な権限を持つ認証情報を使い、Visual Modelerや専用の管理コンソールなど、ACTICOのプラットフォームにログインします。
- エクスポート機能の確認:システムの管理または設定画面に移動し、監査証跡、ログ、データエクスポートを管理するセクションを探します。「監査エクスポート」や「ビジネスオブジェクトのエクスポート」などの名称が使われている場合があります。
- 新しいエクスポート設定の作成:新しいエクスポート定義の作成を開始します。設定名には、たとえば「KYC_Onboarding_ProcessMind_Export」のように、内容がわかる名前を付けます。
- データソースの指定:エクスポートする主要なビジネスオブジェクトとして、
CustomerApplicationを指定します。ファイルサイズと処理性能を適切に保つため、直近6か月などの期間を指定する日付範囲フィルターを必ず設定します。 - 出力ファイルの設定:出力形式にCSVを指定します。ファイル名(例:
kyc_event_log.csv)と区切り文字(通常はカンマ)を設定します。特殊文字を正しく処理できるよう、テキスト項目が引用符で囲まれることも確認します。 - ケース識別子のマッピング:
CustomerApplicationビジネスオブジェクトの一意の識別子を、プロセスマイニング分析で使うケースIDに指定します。これにより、関連するすべてのイベントが1つのオンボーディングケースに紐づきます。 - 属性のマッピング:イベントログに必要な各列を、ACTICOのビジネスオブジェクトモデル内の対応する属性にマッピングします。ケースID、アクティビティ名、タイムスタンプのほか、ステータスやリスクレベルなどの推奨属性も含めます。
- イベントのマッピング:ここが最も重要なステップです。14種類のビジネスアクティビティそれぞれに、個別のルールまたはマッピングを作成します。「申請提出済み」にはオブジェクトの作成、「申請承認済み」などのワークフローのステップにはステータス変更、「本人確認実施済み」などの技術イベントには特定の監査ログメッセージパターンといった、システムのトリガーを使います。
- 設定の保存と検証:すべてのマッピングを定義したら、設定ファイルを保存します。ACTICOで利用できる検証ツールを使い、構文エラーや属性パスの誤りがないか確認します。
- エクスポートの実行と監視:エクスポートジョブを実行します。システムのジョブスケジューラーまたは監視画面で進行状況を確認し、完了後にログでエラーの有無を調べます。
- ファイルの取得と準備:サーバー上の指定された出力先から、生成されたCSVファイルをダウンロードします。ProcessMindにアップロードする前にファイルを開き、構成を確認します。タイムスタンプと日付の形式が統一され、正しく読み取られることも確認してください。
設定
- 監査ログのレベル:システム全体の監査ログレベルを、INFOやFINEなどの詳細な設定にします。WARNINGやERRORなど詳細度の低いレベルでは、プロセスマイニングに必要なステータス変更やルール実行が記録されません。
- エクスポートのデータソース:主要なデータソースには、
CustomerApplicationビジネスオブジェクトを設定します。関連するイベントをすべて取得するため、CustomerDocumentなどの関連オブジェクトを結合または参照する必要がある場合があります。 - 日付範囲フィルター:抽出するデータ量を調整するため、必ず日付範囲フィルターを設定します。初回の分析では、3~6か月の期間を推奨します。本番環境では、業務上のニーズやシステムの処理性能に応じて調整できます。
- イベントのマッピングロジック:抽出データの正確性は、イベントのマッピング方法に大きく左右されます。業務上のステップを推定するには、ステータス変更(
on="StatusChange")がよく使われます。技術イベントやサービス呼び出しには明示的なログエントリ(on="LogEntry")、意思決定のステップにはルール実行(on="RuleExecution")が適しています。 - 出力形式:幅広い用途に対応できるCSVを選択します。データの解析エラーを防ぐため、区切り文字とテキストの引用符に関する設定が正しいことを確認します。
- 前提条件:この方法を利用するには、ACTICOのプラットフォームに対する管理者権限が必要です。正確に設定するには、関連するすべてのステータス項目や属性名を含むKYCビジネスオブジェクトモデルを十分に理解している必要があります。
クエリの例 xml
<!-- This is a representative ACTICO export configuration in XML format. -->
<!-- Actual syntax may vary based on your ACTICO version. -->
<AuditExportConfiguration name="KYC_ProcessMind_Export">
<DataSource type="BusinessObject">
<ObjectName>CustomerApplication</ObjectName>
<DateRange from="[Start Date YYYY-MM-DD]" to="[End Date YYYY-MM-DD]"/>
</DataSource>
<OutputFile format="CSV" name="kyc_event_log.csv" delimiter=","/>
<CaseId mapping="customerApplication.id"/>
<Attributes>
<Attribute name="CustomerApplication" mapping="customerApplication.id"/>
<Attribute name="ActivityName" mapping="[generated_activity_name]"/>
<Attribute name="EventTime" mapping="[event_timestamp]"/>
<Attribute name="SourceSystem" value="ACTICO"/>
<Attribute name="LastDataUpdate" value="[CURRENT_TIMESTAMP]"/>
<Attribute name="EndTime" mapping="[event_timestamp]"/>
<Attribute name="InitiatingUser" mapping="event.user"/>
<Attribute name="Department" mapping="event.user.department"/>
<Attribute name="ApplicationStatus" mapping="customerApplication.status"/>
<Attribute name="RejectionReason" mapping="customerApplication.rejectionDetails.reasonCode"/>
<Attribute name="RiskLevel" mapping="customerApplication.risk.level"/>
<Attribute name="SlaTargetDate" mapping="customerApplication.slaDate"/>
</Attributes>
<EventMappings>
<Event on="Create" object="CustomerApplication">
<Set name="[generated_activity_name]" value="Application Submitted"/>
<Set name="[event_timestamp]" mapping="customerApplication.creationDate"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Submitted" to="In Review">
<Set name="[generated_activity_name]" value="Initial Application Review"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="Create" object="CustomerDocument">
<Set name="[generated_activity_name]" value="Customer Documents Uploaded"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
<CaseId mapping="event.relatedObject.customerApplication.id"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="IDV Service Call Completed.*">
<Set name="[generated_activity_name]" value="Identity Verification Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Documents Verified">
<Set name="[generated_activity_name]" value="Document Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Background Check Initiated.*">
<Set name="[generated_activity_name]" value="Background Checks Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="RuleExecution" object="CustomerApplication" ruleSet="KYC Risk Assessment">
<Set name="[generated_activity_name]" value="Risk Assessment Performed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Compliance Review">
<Set name="[generated_activity_name]" value="Compliance Review Initiated"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Pending Customer Information">
<Set name="[generated_activity_name]" value="Additional Information Requested"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" from="Pending Compliance Review" to="Compliance Approved">
<Set name="[generated_activity_name]" value="Compliance Review Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Approved">
<Set name="[generated_activity_name]" value="Application Approved"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="LogEntry" object="CustomerApplication" messagePattern="Account successfully created.*">
<Set name="[generated_activity_name]" value="Account Created"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Closed - Approved">
<Set name="[generated_activity_name]" value="Customer Onboarding Completed"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
<Event on="StatusChange" object="CustomerApplication" to="Rejected">
<Set name="[generated_activity_name]" value="Application Rejected"/>
<Set name="[event_timestamp]" mapping="event.timestamp"/>
</Event>
</EventMappings>
</AuditExportConfiguration> 始める準備はできていますか?
このテンプレートを使ってデータを効率よく準備し、ACTICOでのKYC顧客オンボーディングの最適化を進めましょう。
KYC顧客オンボーディングを最適化し、所要時間を24時間に短縮
顧客の離脱や誤検知をなくし、スムーズなオンボーディングを実現します。
クレジットカードは不要です。今すぐ最適化を始めましょう。